Documentation/kbuild: Document platform dependency practises

Document best practises for using architecture and platform dependencies.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This commit is contained in:
Geert Uytterhoeven 2020-12-08 16:28:57 +01:00 committed by Masahiro Yamada
parent c613583b6a
commit 18084e435f
1 changed files with 24 additions and 0 deletions

View File

@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~