On Sat, Feb 15, 2025 at 10:02 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> 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?
Let's say this code hunk exists in foo-init.c
and it is compiled by CONFIG_FOO.
obj-$(CONFIG_FOO) += foo-init.o
If you see the top Makefile, 'MODULE' is defined only when
this code is compiled as a module.
KBUILD_CFLAGS_MODULE := -DMODULE
For the combination of CONFIG_FOO=y and CONFIG_BAZ=m,
IS_BUILTIN(CONFIG_BAZ) is 0
IS_MODULE(CONFIG_BAZ) is 1
__is_defined(MODULE) is 0
Hence, IS_REACHABLE(CONFIG_BAZ) is 0
This code becomes
if (0)
baz_register(&foo);
and the compiler will optimize out this function call.
--
Best Regards
Masahiro Yamada
