[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNAR9Jt0FQNRidcxY-OxMh7N238Xs33Tyj+dpTZ5wGow0wQ@mail.gmail.com>
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
Powered by blists - more mailing lists