On 15/02/2025 13:54, Masahiro Yamada wrote:
> On Sat, Feb 15, 2025 at 8:42 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@xxxxxxxxxx> 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@xxxxxxxxxx>
>> Cc: Arnd Bergmann <arnd@xxxxxxxx>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
>> ---
>> 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
