All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Arnd Bergmann <arnd@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation: kbuild: explain handling optional dependencies
Date: Thu, 14 Sep 2023 16:42:55 +0300	[thread overview]
Message-ID: <874jjwx44g.fsf@intel.com> (raw)
In-Reply-To: <20230913113801.1901152-1-arnd@kernel.org>

On Wed, 13 Sep 2023, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This problem frequently comes up in randconfig testing, with
> drivers failing to link because of a dependency on an optional
> feature.
>
> The Kconfig language for this is very confusing, so try to
> document it in "Kconfig hints" section.

Thanks for doing this.

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  Documentation/kbuild/kconfig-language.rst | 26 +++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index 858ed5d80defe..89dea587a469a 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -573,6 +573,32 @@ above, leading to:
>  	bool "Support for foo hardware"
>  	depends on ARCH_FOO_VENDOR || COMPILE_TEST
>  
> +Optional dependencies
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +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 slighly counterintuitive
> +
> +  config FOO
> +	bool "Support for foo hardware"
> +	depends on BAR || !BAR

	depends on BAR || BAR=n

seems to be an alternative that's about as common:

$ git grep "depends on \([A-Z0-9_]\+\) || \!\1" | wc -l
109
$ git grep "depends on \([A-Z0-9_]\+\) || \1=n" | wc -l
107

Maybe worth mentioning both?


BR,
Jani.


> +
> +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.
> +For a more formalized approach if there are multiple drivers that have
> +the same dependency, a helper symbol can be used, like
> +
> +  config FOO
> +	bool "Support for foo hardware"
> +	depends on BAR_OPTIONAL
> +
> +  config BAR_OPTIONAL
> +	def_tristate BAR || !BAR
> +
>  Kconfig recursive dependency limitations
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2023-09-14 13:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 11:37 [PATCH] Documentation: kbuild: explain handling optional dependencies Arnd Bergmann
2023-09-13 14:25 ` Javier Martinez Canillas
2023-09-13 16:11 ` Sakari Ailus
2023-09-13 19:48 ` Nicolas Schier
2023-09-13 19:55   ` Arnd Bergmann
2023-09-13 20:34     ` Nicolas Schier
2023-09-13 21:16       ` Arnd Bergmann
2023-09-14  3:51         ` Nicolas Schier
2023-09-14  5:05           ` Arnd Bergmann
2023-09-14  3:56         ` Javier Martinez Canillas
2023-09-14 17:07       ` Masahiro Yamada
2023-09-14 13:42 ` Jani Nikula [this message]
2023-09-14 14:57   ` Arnd Bergmann
2023-09-14 15:56     ` Jani Nikula
2023-09-14 17:23     ` Masahiro Yamada
2023-09-15  5:26       ` Arnd Bergmann
2023-09-15  7:34         ` Jani Nikula
2023-09-15  7:44           ` Arnd Bergmann
2023-09-15 15:48             ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jjwx44g.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=corbet@lwn.net \
    --cc=javierm@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.