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
