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

[Elliott Mitchell]

On Sat, Nov 25, 2023 at 07:08:20AM +0100, Felix Fietkau wrote:
> On 25.11.23 03:28, Elliott Mitchell wrote:
> > 
> > All of these are plausible.  I think modules selected in device
> > configurations should get built and installed into the root filesystem.
> > Otherwise setting a device kernel configuration option to =m is broken.
> > 
> > Whereas forcing the explicit creation of packages for each and every
> > kernel module forces duplication of Kconfig functionality.

> The duplication you wish to avoid is there for a reason. The way the 
> kernel build system is set up, it makes it easy to build a highly 
> customized build for one target, or make a distribution build with 
> pretty much everything built as module. What it offers no solution for 
> is to maintain and keep in sync kernel configurations for a wide array 
> of different (often storage constrained) targets, while keeping a lot of 
> extra features/drivers optionally installable.
> That's exactly what our packaging around kernel modules + our kernel 
> config handling scripts were made for.

What needs to catch the attention of the core of the Linux kernel
developers is Linux is no longer a niche OS.  1.5GB of *source* and
producing 400MB of modules.

Providing individual descriptions of each and every module is really a
task for the kernel developers.  The descriptions in Kconfig files don't
readily convert to individually packaged modules.  I hope other Linux
distributions are also concerned about how large the package for all
built modules has become.


> Since there is no perfect solution, there are always some trade-offs 
> involved. One of these trade-offs was our choice to not support adding 
> kernel modules in the device kernel config by selecting them as =m 
> there. I didn't consider that feature useful enough to justify the cost 
> of dealing with all the corner cases.
> 
> I still don't fully understand your motivation for adding this feature. 
> Is it just because you're bothered by having to write some extra 
> boilerplate code for adding kernel modules? Are there some cases where 
> the existing system cannot work for what you're trying to do?
> Or is there some other reason why you need this?
> 
> Just to be clear, I'm not opposed to the feature you're proposing in any 
> way. What I want to avoid is adding something that works for your 
> special case but quickly breaks in weird ways when other people start 
> using it.

I've already stated a concern.  Having things configured =m in device
kernel configurations simply getting dropped is wrong.

The kernel configurations for bmips/bcm6318 and bmips/bcm6328 set
CONFIG_HW_RANDOM=n.  Turns out despite this, KernelPackage/b43 overrides
the value and those device kernels actually have CONFIG_HW_RANDOM=y.
This is a very unpleasant surprise if you're trying work with one of
these devices.

x86 really demonstrates the need for better module handling.  Every
single Intel pinctrl driver is present in the kernel.  If you need the
functionality then this is valuable.  Alas there are >15 drivers you
don't need.  Further, these would work well as modules since they could
readily be loaded from /.  On top of this, what about someone whose
system has the feature, but doesn't want to use it?



I've got what seems a workable approach, but it isn't yet finished.
While there are some differences between building an in-tree module
versus building an out-of-tree module, the differences are quite small.

I've presently got a PoC of building in-tree modules using the out of
tree system.  This present method I've got is roughly:
`make -C <kbuild_dir> M=<module directory> CONFIG_<SOME-MODULE>=m <module>.ko`

Where <kbuild_dir> is a copy of the Kbuild system.  The list of files
can be extracted from `scripts/package/build<foo>`.  This really needs
a "kbuild_install" so those can share it, and various other uses can
come from it.

Presently I hope the approach of simply specifying all the package
CONFIG_* values on the Make command-line will work.  Alas what may
instead be needed is to generate a variant of the .config file.


Right now I'm seeing two issues.  First, this ends up bypassing the
kernel handling of dependencies.  Due to the impressive nature of
OpenWRT's Makefiles (I'm no slouch, but these are impressive) I'm still
trying to figure out how targets are named for dependency use.
Specifically, what dependency is needed to cause Make to try building
the "compile" target for "package/kernel/linux" before proceeding?
(external modules can depend on an in-tree ones)

Second, this ends up needing slightly different handling between in-tree
modules and out-of-tree.  In particular there is a need to specify each
.ko on Kbuild/Make's command-line.  An ideal differentiator is whether
the package sets KCONFIG.

The result is presently rather more sensitive to package setup and
several OpenWRT packages are less than wonderful.  KernelPackage/b43 had
been abusing KCONFIG, resulting in confusion and would break this.
KernelPackage/fs-nfs-v3 was relying on CONFIG_NFS_V3 to defaulting to
module and the CI system was noticing.
Several the lantiq modules are also violating this and presently I've
got no idea what is going on.  This needs fixing, but I'm presently
unsure of how to fix.


Felix Fietkau, we were having e-mail fun.  In theory this got taken care
of, but lacking confirmation of resolution I'm unsure.  Welcome to the
present day and what spam has done to e-mail.  Interestingly if OpenWRT
had a default to reject all packats to port 25 that might have a
noticable impact.


-- 
(\___(\___(\______          --=> 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