On Sat, Dec 3, 2022, at 18:02, Bjørn Mork wrote: > Petr Štetiar <yn...@true.cz> writes: > >> No, lets take a look at that PTP_1588_CLOCK_OPTIONAL: >> >> config PTP_1588_CLOCK_OPTIONAL >> tristate >> default y if PTP_1588_CLOCK=n >> default PTP_1588_CLOCK >> help >> Drivers that can optionally use the PTP_1588_CLOCK framework >> should depend on this symbol to prevent them from being built >> into vmlinux while the PTP support itself is in a loadable >> module. >> If PTP support is disabled, this dependency will still be >> met, and drivers refer to dummy helpers. >> >> From help text description it looks to me, that it's not tristate symbol at >> all, it's boolean symbol and certainly shouldn't have `default >> PTP_1588_CLOCK` >> as otherwise it's not doing what it's described on the box. > > Yes, that's obfuscated.
I don't understand what problem you see with the logic or the help text. Obviously this cannot work as a 'bool' symbol, it has to be 'tristate' for the logic to work. > But what I mean is that you will hit exactly same problem with the > common BAR || BAR=n pattern. It's the same pattern, the only reason we introduced the PTP_1588_CLOCK_OPTIONAL symbol is that too many people got confused by the meaning of 'depends on PTP_1588_CLOCK || PTP_1588_CLOCK=n', which looks like it has no effect in boolean logic though it does in tristate symbols. > linux-5.15.80$ echo "CONFIG_HSR=m" >>.config > linux-5.15.80$ make olddefconfig > .config:4543:warning: override: reassigning to symbol HSR > # > # configuration written to .config > # > $ grep -E 'CONFIG_(HSR|NET_DSA)[ =]' .config > CONFIG_NET_DSA=m > CONFIG_HSR=m > > We can't unconditionally enable any modules without considering the > effect on their reverse dependencies. > > 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. Arnd _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel