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+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
