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:
parent
c613583b6a
commit
18084e435f
@ -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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user