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.

But what I mean is that you will hit exactly same problem with the
common BAR || BAR=n pattern.

Practical example:

 linux-5.15.80$ head net/dsa/Kconfig 
 # SPDX-License-Identifier: GPL-2.0-only
 
 menuconfig NET_DSA
         tristate "Distributed Switch Architecture"
         depends on BRIDGE || BRIDGE=n
         depends on HSR || HSR=n
         depends on INET && NETDEVICES
         select GRO_CELLS
         select NET_SWITCHDEV
         select PHYLINK
 linux-5.15.80$ grep -E 'CONFIG_(HSR|NET_DSA)[ =]' .config
 CONFIG_NET_DSA=y
 # CONFIG_HSR is not set
 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.


Bjørn

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to