Re: [PATCH] Documentation: kbuild: explain handling optional dependencies

[Masahiro Yamada]

On Thu, Sep 14, 2023 at 11:57 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Thu, Sep 14, 2023, at 15:42, Jani Nikula wrote:
> > On Wed, 13 Sep 2023, Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> >> From: Arnd Bergmann <arnd@xxxxxxxx>
> >>
> >> +Optional dependencies
> >> +~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +Some drivers are able to optionally use a feature from another module
> >> +or build cleanly with that module disabled, but cause a link failure
> >> +when trying to use that loadable module from a built-in driver.
> >> +
> >> +The most common way to express this optional dependency in Kconfig logic
> >> +uses the slighly counterintuitive
> >> +
> >> +  config FOO
> >> +    bool "Support for foo hardware"
> >> +    depends on BAR || !BAR
> >
> >       depends on BAR || BAR=n
> >
> > seems to be an alternative that's about as common:
> >
> > $ git grep "depends on \([A-Z0-9_]\+\) || \!\1" | wc -l
> > 109
> > $ git grep "depends on \([A-Z0-9_]\+\) || \1=n" | wc -l
> > 107
> >
> > Maybe worth mentioning both?
>
> I fear that would add more confusion than it avoids:
> "!BAR" is actually different from "BAR=n", but
> "BAR || !BAR" is the same as "BAR || BAR=n" here, and
> trying to explain this in the documentation would either
> make it incorrect or unhelpfully complicated.



The rules are already explained in line 231-278
of Documentation/kbuild/kconfig-language.rst


y, m, n are internally 2, 1, 0.

!A returns (2 - A).
A=B returns 2 if the equation is true, 0 otherwise.
A||B returns max(A,B)


Given those in my mind, this is simple math.

For each case of BAR=y, =m, =n,

BAR               2       1       0
!BAR              0       1       2
BAR=n             0       0       2
BAR||!BAR         2       1       2
BAR||BAR=n        2       1       2
BAR!=m||m         2       1       2


So, the last three are equivalent.
They are equally complicated and confusing, though.


After all, what we are doing is to create this matrix:

          |   WIREGUARD
          |   y     m     n
----------------------------
        y |   O     O     O
IPV6    m |   X     O     O
        n |   O     O     O



It is unclear why WIREGUARD must be entirely disabled
just because of the optional feature being modular.



My preference is to use IS_REACHABLE(CONFIG_IPV6)
instead of IS_ENABLED(CONFIG_IPV6)
under drivers/net/wireguard, then
get rid of "depends on IPV6 || !IPV6)




If you want to make it clearer on the Kconfig level,
perhaps the following is also possible.


config WIREGUARD
       tristate "WireGuard"

config WIREGUARD_IPV6
       def_bool y
       depends on WIREGUARD
       depends on IPV6 >= WIREGUARD

config IPV6
       tristate "IPV6"



-- 
Best Regards
Masahiro Yamada