linux-kernel - Re: [PATCH] Documentation: kbuild: explain handling optional dependencies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Sep 2023 02:23:25 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Arnd Bergmann <arnd@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Sakari Ailus <sakari.ailus@....fi>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nicolas Schier <nicolas@...sle.eu>,
        linux-kbuild@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation: kbuild: explain handling optional dependencies

On Thu, Sep 14, 2023 at 11:57 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Thu, Sep 14, 2023, at 15:42, Jani Nikula wrote:
> > On Wed, 13 Sep 2023, Arnd Bergmann <arnd@...nel.org> wrote:
> >> From: Arnd Bergmann <arnd@...db.de>
> >>
> >> +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