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: <a09b2636-dc15-4970-81dd-a16b5a166464@linaro.org>
Date: Sat, 15 Feb 2025 14:06:01 +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 14:01, Krzysztof Kozlowski wrote:
>> 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.
I hope I got your intention right below:



@@ -580,15 +570,31 @@ Some drivers are able to optionally use a feature from another module
-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 BAR does not
+   provide !BAR stubs then call can be guarded with IS_REACHABLE()::
+
+       foo_init()
+       {
+               if (IS_REACHABLE(CONFIG_BAR))
+                       bar_register(&foo);
+               ...
+       }
+
+   Drawback: this might lead to run-time debugging, when looking why
+   bar_register() was not called.
+
+2. Otherwise (and module BAR must provide all !BAR stubs) use the slightly
+   counterintuitive Kconfig syntax::
+
+     config FOO
        tristate "Support for foo hardware"
        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.  Unlike
+IS_REACHABLE(), this option favors configuration-time debugging.
 For a more formalized approach if there are multiple drivers that have
 the same dependency, a helper symbol can be used, like::




Best regards,
Krzysztof