lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ