On Sat, Nov 25, 2023 at 09:36:33AM -0800, Elliott Mitchell wrote: > On Sat, Nov 25, 2023 at 07:08:20AM +0100, Felix Fietkau wrote: > > On 25.11.23 03:28, Elliott Mitchell wrote: > > > > 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 should also add, I rather dislike package building modifying kernel configuration. Due to this you can't be sure the kernel specified by configuration is the one you're actually building. > > 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. > > That is quite reasonable. I've pushed this later in my queue since I > concluded the aim of the later patches will make a more acceptable > approach possible. > > Hopefully I'll be able to resend the series in a few days, just need > some build testing to ensure I didn't break anything. The first two > patches are going to remain unchanged as there simply isn't anything > which can be done to them. Famous last words. Took rather longer than expected since I went fairly far with an approach which towards the end became clear would not be accepted. Then I tried an alternative and ran into a major weakness of Kbuild. Hopefully I've brought the issue to the attention of the right person and it will be fixed in the kernel soon. Alas I've no idea how long that will take to fix. In the mean time I've got a suboptimal workaround. I seem to have about 3 patch series going. First patch series is a VM oriented build (smallest kernel to boot in multiple VMs). Second patch series is trying to split kernel source/build/module directories apart and implementing better handling of modules. Third series is misc build system cleanup which I've run into while fighting these issues. First two have been partially sent, their later stages are still in flux. Would be helpful to start getting some of the earlier patches committed. I need a lot of reviewer and committer time... -- (\___(\___(\______ --=> 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