On 25.11.23 03:28, Elliott Mitchell wrote:
On Fri, Nov 24, 2023 at 01:53:01PM +0100, Jonas Gorski wrote:
> > 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.
Maybe instead of putting them into the rootfs, we could wrap them in a
special package? Then you can select it if you want to include them in
your image or not. No idea what to name it, kmod-remaining?
kmod-unaccounted-for? kmod-not-appearing-in-the-definitions?
We could also try to wrap any unexpected .kos into autogenerated kmod
packages based in their names (e.g. if we find a foo.ko, we
autogenerate a kmod-foo.ipk for it), but these wouldn't be selectable
then in menuconfig. Also not sure how well the build system would
handle dynamic package generation.
Also going the other way around, maybe the build system should
warn/complain about any .ko found that isn't wrapped in a kmod-*
package.
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.
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.
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
