[PATCH 07/20] kernel: copy all built kernel modules to root filesystem image

[Elliott Mitchell]

On Sat, Nov 18, 2023 at 07:57:35AM +0100, Felix Fietkau wrote:
> On 17.11.23 22:31, Elliott Mitchell wrote:
> > On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote:
> >> On 11.11.23 01:21, Elliott Mitchell wrote:
> >> > This removes the requirement for to create a package for all modules.
> >> > Now devices can simply specify in-tree drivers/other to be built as
> >> > modules and they will be present in the resultant image.
> >> > 
> >> > Signed-off-by: Elliott Mitchell <ehem+openwrt at m5p.com>
> >> 
> >> It seems to me that this completely ignores the use case of having 
> >> release builds that ship a lot of kernel modules as installable 
> >> packages. Did I misread something?
> >> If not, this gets a strong NACK from me.
> > 
> > Should be completely orthogonal, though it could have bugs.
> > 
> > Using `cp -l` has two valuable effects:  First, it reduces storage space
> > usage.  Second, it serves to mark module files as belonging to a package.
> > 
> > My goal is previously setting a kernel option to "m" in a configuration
> > file, but not having a package causes it to be built, then ignored.  I
> > want this to do something sensible, not simply waste electricity
> > building a module and then tossing it in the garbage.
> > 
> > Hmm, come to think of it, that should be $(XARGS) (fix on commit?).
> 
> Thanks for the explanation, it makes more sense to me now.
> That said, I see a few pitfalls here:
> 
> 1. If you select kernel modules that depend on other modules selected 
> via kmod packages, you end up with non-functional modules with missing 
> dependencies in the rootfs.

Is this actually that much of a problem?  From what I've seen most kmod
packages handled during image build get preinstalled onto the root fs
image.  As such these would nominally function as long as the packages
weren't removed.

Wouldn't this also indicate breakage in the module package anyway?

> 2. If the kmod package selection accidentally ends up selecting extra 
> modules that aren't stored in the package, you end up with rootfs bloat.

Eww, that would be gross.  As with the above, wouldn't this be indicating
breakage in the module packaging anyway?

> I'm fine with the cp -l change, but I think adding all remaining modules 
> to the rootfs is not something we should do by default (maybe opt-in?)

Perhaps.  This could also be handled by the approach the series as a
whole is aiming for.  If kernel module building used a separate object
directory from the kernel build, then modules selected in the device
configuration could be isolated.

> By the way, I still get bounces when replying to you, because your mail 
> server is refusing my mail.

Ick.  Welcome to the world of 2023 and what spam has done to e-mail.
Alas, this is due to extreme measures being taken by the person who
handles this system.  We're at a point where small mailservers cannot
exist due to the shear amount of spam being generated.

I suppose OpenWRT might help by having a default rule to filter out port
25.  There is also that yet to be written kernel patch which disables
the interfering 2.45GHz channels.  There is also the default egress
filtering...   All those things I could get done if I ruled the world.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445