linux-kernel - Re: [PATCH v3] docs: kconfig: Mention IS_REACHABLE as way for optional dependency

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] [day] [month] [year] [list]

Message-ID: <CAK7LNASHmbeYya5fPdktBtdJiXGWHeVRq00qRFMOhseKir=yvQ@mail.gmail.com>
Date: Mon, 3 Mar 2025 01:55:08 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, 
	Jonathan Corbet <corbet@....net>, linux-kbuild@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v3] docs: kconfig: Mention IS_REACHABLE as way for
 optional dependency

On Mon, Feb 17, 2025 at 8:32 PM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> Several drivers express optional Kconfig dependency with FOO || !FOO,
> but for many choices this is not suitable: lack of stubs for !FOO
> like in HWMON.  Describe the second, less favorable way of optional
> dependency with IS_REACHABLE by moving the code from "imply" chapter to
> "Optional dependencies".
>
> Cc: Masahiro Yamada <masahiroy@...nel.org>
> Cc: Arnd Bergmann <arnd@...db.de>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>

Applied to linux-kbuild. Thanks.

For consistency with the existing documentation,
I replaced two spaces between sentences.


> ---
>
> Changes in v3:
> 1. Significant rewrite to mark IS_REACHABLE as less favorable.
>
> Changes in v2:
> 1. Replace FOO->BAR
> 2. Instead of referencing earlier "imply", move the code here and add
>    more text (Masahiro)
> ---
>  Documentation/kbuild/kconfig-language.rst | 29 ++++++++++++++---------
>  1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index 2619fdf56e68..c8c20a34525e 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -194,16 +194,6 @@ applicable everywhere (see syntax).
>    ability to hook into a secondary subsystem while allowing the user to
>    configure that subsystem out without also having to unset these drivers.
>
> -  Note: If the combination of FOO=y and BAZ=m causes a link error,
> -  you can guard the function call with IS_REACHABLE()::
> -
> -       foo_init()
> -       {
> -               if (IS_REACHABLE(CONFIG_BAZ))
> -                       baz_register(&foo);
> -               ...
> -       }
> -
>    Note: If the feature provided by BAZ is highly desirable for FOO,
>    FOO should imply not only BAZ, but also its dependency BAR::
>
> @@ -588,7 +578,9 @@ uses the slightly counterintuitive::
>         depends on BAR || !BAR
>
>  This means that there is either a dependency on BAR that disallows
> -the combination of FOO=y with BAR=m, or BAR is completely disabled.
> +the combination of FOO=y with BAR=m, or BAR is completely disabled.  The BAR
> +module must provide all the stubs for !BAR case.
> +
>  For a more formalized approach if there are multiple drivers that have
>  the same dependency, a helper symbol can be used, like::
>
> @@ -599,6 +591,21 @@ the same dependency, a helper symbol can be used, like::
>    config BAR_OPTIONAL
>         def_tristate BAR || !BAR
>
> +Much less favorable way to express optional dependency is IS_REACHABLE() within
> +the module code, useful for example when the module BAR does not provide
> +!BAR stubs::
> +
> +       foo_init()
> +       {
> +               if (IS_REACHABLE(CONFIG_BAR))
> +                       bar_register(&foo);
> +               ...
> +       }
> +
> +IS_REACHABLE() is generally discouraged, because the code will be silently
> +discarded, when CONFIG_BAR=m and this code is built-in.  This is not what users
> +usually expect when enabling BAR as module.
> +
>  Kconfig recursive dependency limitations
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> --
> 2.43.0
>


-- 
Best Regards
Masahiro Yamada