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

Reply via email to