On Sat, Dec 3, 2022, at 23:59, Bjørn Mork wrote:
> "Arnd Bergmann" <a...@arndb.de> writes:
>> On Sat, Dec 3, 2022, at 18:02, Bjørn Mork wrote:
>>
>>> Yes, I realize that ALL_KMODS only changes a small subset of symbols
>>> related to kmod packages. And I'm pretty sure HSR isn't part of that
>>> set. But I don't think that changes anything. This is a bug waiting to
>>> happen again.
>>
>> Do you have any alternative suggestions? Changing the dependency logic
>> would just cause runtime failures, and turning the dependencies all
>> into 'bool' symbols would cause a significant increase in kernel size
>> for distro builds that usually rely on things being in loadable modules.
>
> I was referring to the ALL_KMODS feature in OpenWrt, not to the
> PTP_1588_CLOCK_OPTIONAL symbol. As noted, there are many similar
> constructs in the kernel. Personally I think
> PTP_1588_CLOCK || PTP_1588_CLOCK=n would have been better, but I
> see your point and am definitely not going to argue about that ;-)
>
> Should have made it clearer that I believe the bug is in OpenWrt, not in
> the kernel. Just didn't notice that you were CC'ed into the discussion.
> Thought we were having an OpenWrt conversation... Sorry about the
> confusion.
Ok, got it. Indeed this is a general problem for anyone wanting
to enable all kernel modules. I don't know how ALL_KMODS works
in OpenWRT, but there are other related problems that make this
a hard problem, which means you need a whitelist or blacklist
of some sort anyway:
- Some modules are only visible depending on some other 'bool'
symbol, so you have to know which of those symbols to turn
on first
- Some 'tristate' symbols not only control whether a module
is built but also impact the rest of the kernel.
- Some modules are related to 'choice' statement or other
options that have mutually incompatible settings.
Arnd
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
