[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2viBG-dVQQwRfc9aP=dbdyTypgMJycONu2g4jcnfuFKg@mail.gmail.com>
Date: Tue, 8 Dec 2020 16:43:17 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Geert Uytterhoeven <geert+renesas@...der.be>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Jonathan Corbet <corbet@....net>,
Arnd Bergmann <arnd@...db.de>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] Documentation/kbuild: Document platform dependency practises
On Tue, Dec 8, 2020 at 4:28 PM Geert Uytterhoeven
<geert+renesas@...der.be> wrote:
>
> Document best practises for using architecture and platform dependencies.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> ---
> Documentation/kbuild/kconfig-language.rst | 24 +++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index 2b746332d8aa6bce..87e9bbe14a21ce83 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -564,6 +564,30 @@ common system, and detect bugs that way.
> Note that compile-tested code should avoid crashing when run on a system where
> the dependency is not met.
>
> +Architecture and platform dependencies
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +Due to the presence of stubs, most drivers can now be compiled on most
> +architectures. However, this does not mean it makes sense to have all drivers
> +available everywhere, as the actual hardware may only exist on specific
> +architectures and platforms. This is especially true for on-SoC IP cores,
> +which may be limited to a specific vendor or SoC family.
> +
> +To prevent asking the user about drivers that cannot be used on the system(s)
> +the user is compiling a kernel for, and if it makes sense, config symbols
> +controlling the compilation of a driver should contain proper dependencies,
> +limiting the visibility of the symbol to (a superset of) the platform(s) the
> +driver can be used on. The dependency can be an architecture (e.g. ARM) or
> +platform (e.g. ARCH_OMAP4) dependency. This makes life simpler not only for
> +distro config owners, but also for every single developer or user who
> +configures a kernel.
> +
> +Such a dependency can be relaxed by combining it with the compile-testing rule
> +above, leading to:
> +
> + config FOO
> + bool "Support for foo hardware"
> + depends on ARCH_FOO_VENDOR || COMPILE_TEST
> +
> Kconfig recursive dependency limitations
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The addition seems useful, but I wonder if we should mention more
patterns here.:
- Some drivers are turned on implicitly for a platform, like
config FOO
bool "Support for foo hardware"
depends on ARCH_FOO_VENDOR || COMPILE_TEST
default ARCH_FOO_VENDOR
- some drivers can use a feature that may be a loadable module
itself, or can compile if that feature is disabled, but the driver
itself must not be built-in if the feature is in a loadable module, e.g.
config FOO
tristate "Foo device"
depends on HWSPINLOCK || (COMPILE_TEST && !HWSPINLOCK)
Arnd
Powered by blists - more mailing lists