"Arnd Bergmann" <arnd@xxxxxxxx> writes: Hello Nicolas, > On Wed, Sep 13, 2023, at 22:34, Nicolas Schier wrote: >> On Wed, Sep 13, 2023 at 09:55:36PM +0200 Arnd Bergmann wrote: > [...] >> I can choose between: >> >> BAR=y => FOO={N/m/y} >> BAR=m => FOO is not selectable >> BAR=n => FOO={N/m/y} > > That is indeed the point: if BAR=m, we want to be able to pick FOO=m > here, otherwise it is impossible to enabled everything as modules. > > Another correct way to express the same thing as the first would > be > > config FOO > tristate "Support for foo hardware" > depends on !BAR=m || m > > which I find even more confusing than the 'BAR || !BAR' > convention, though we have that in a couple of places. > > I just found another variant that I had not seen before: > >> (Re-checked with BAR=IPV6 and FOO=WIREGUARD; CONFIG_WIREGUARD as 'depends on >> IPV6 || !IPV6' in its kconfig definition, and both are tristate kconfig >> symbols.) >> Which is correct because WIREGUARD can be built with IPV6 disabled, but if both options are enabled then WIREGUARD can only be built-in if the IPV6 option is also built-in. WIREGUARD must be a module if IPV6 is also a module, but can still be a module if IPV6 is built-in. In other words, what this idiom express is that the following configs are possible: IPV6=n => WIREGUARD=y IPV6=n => WIREGUARD=m IPV6=y => WIREGUARD=y IPV6=y => WIREGUARD=m IPV6=m => WIREGUARD=m but the following option is not possible: IPV6=m => WIREGUARD=y -- Best regards, Javier Martinez Canillas Core Platforms Red Hat