linux-kernel - Re: [PATCH] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <886cb4b9-9d95-4346-9c38-923cb7c69036@linaro.org>
Date: Sat, 15 Feb 2025 14:01:59 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Masahiro Yamada <masahiroy@...nel.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] docs: kconfig: Mention IS_REACHABLE as way for optional
 dependency

On 15/02/2025 13:54, Masahiro Yamada wrote:
> On Sat, Feb 15, 2025 at 8:42 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> Several drivers express optional Kconfig dependency with FOO || !FOO,
>> but for many choices this is neither suitable (lack of stubs for !FOO
>> like in HWMON) nor really needed and driver can be built in even if FOO
>> is the module.  This is achieved with IS_REACHABLE, so provide cross
>> reference to it.
>>
>> Cc: Masahiro Yamada <masahiroy@...nel.org>
>> Cc: Arnd Bergmann <arnd@...db.de>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>> ---
>>  Documentation/kbuild/kconfig-language.rst | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
>> index 2619fdf56e68..66248294a552 100644
>> --- a/Documentation/kbuild/kconfig-language.rst
>> +++ b/Documentation/kbuild/kconfig-language.rst
>> @@ -194,6 +194,8 @@ 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.
>>
>> +.. _is_reachable:
> 
> Instead of this, could you move this hunk below ?
> 

Ack

> 
> 
> 
> 
>>    Note: If the combination of FOO=y and BAZ=m causes a link error,
>>    you can guard the function call with IS_REACHABLE()::
>>
>> @@ -580,10 +582,15 @@ 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 slightly counterintuitive::
>> +There are two ways to express this optional dependency:
>>
>> -  config FOO
>> +1. If pre-processor can discard entire optional code or module FOO does not
>> +   provide !FOO stubs then in the C code :ref:`IS_REACHABLE<is_reachable>`
> 
> Instead of the link, please move the code example at line 200 to here.
> 
> The note at line 197 is not strongly related to the 'imply' keyword.
> 
> 
> One more thing, please document the drawback of IS_REACHABLE.

Ack

> 
> It is true that IS_REACHABLE() resolves the link error, but we
> will end up with run-time debugging.
> 
> foo_init()
> {
>         if (IS_REACHABLE(CONFIG_BAZ))
>                 baz_register(&foo);
>         ...
> }
> 
> Even if CONFIG_BAZ is enabled, baz_register() may get discarded.

Hm, why would that happen? For compiler this would be "if(true)", so
what case would lead to discarding?

> Users may scratch their head why baz_register() does not work.
> Due to this reason, IS_REACHABLE() tends to be avoided.

I would rather say IS_REACHABLE should be avoided if someone really
wants to document the dependency, not optional feature.

> 
> 
> "depends on BAR || !BAR" is configuration-time debugging.
> 



Best regards,
Krzysztof