Commit cd238eff authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by Jonathan Corbet
Browse files

docs: kbuild: convert docs to ReST and rename to *.rst



The kbuild documentation clearly shows that the documents
there are written at different times: some use markdown,
some use their own peculiar logic to split sections.

Convert everything to ReST without affecting too much
the author's style and avoiding adding uneeded markups.

The conversion is actually:
  - add blank lines and identation in order to identify paragraphs;
  - fix tables markups;
  - add some lists markups;
  - mark literal blocks;
  - adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent d7b461c5
......@@ -227,7 +227,7 @@ Configuring the kernel
"make tinyconfig" Configure the tiniest possible kernel.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
in Documentation/kbuild/kconfig.rst.
- NOTES on ``make config``:
......
=============================================
Exporting kernel headers for use by userspace
=============================================
......@@ -22,14 +23,14 @@ older kernel.
The "make headers_install" command can be run in the top level directory of the
kernel source code (or using a standard out-of-tree build). It takes two
optional arguments:
optional arguments::
make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr
ARCH indicates which architecture to produce headers for, and defaults to the
current architecture. The linux/asm directory of the exported kernel headers
is platform-specific, to see a complete list of supported architectures use
the command:
the command::
ls -d include/asm-* | sed 's/.*-//'
......
:orphan:
===================
Kernel Build System
===================
.. toctree::
:maxdepth: 1
kconfig-language
kconfig-macro-language
kbuild
kconfig
makefiles
modules
headers_install
issues
.. only:: subproject and html
Indices
=======
* :ref:`genindex`
Recursion issue #1
------------------
.. include:: Kconfig.recursion-issue-01
:literal:
Recursion issue #2
------------------
.. include:: Kconfig.recursion-issue-02
:literal:
======
Kbuild
======
Output files
============
modules.order
--------------------------------------------------
-------------
This file records the order in which modules appear in Makefiles. This
is used by modprobe to deterministically resolve aliases that match
multiple modules.
modules.builtin
--------------------------------------------------
---------------
This file lists all modules that are built into the kernel. This is used
by modprobe to not fail when trying to load something builtin.
......@@ -18,84 +24,90 @@ Unlike modinfo of a separate module, all fields are prefixed with module name.
Environment variables
=====================
KCPPFLAGS
--------------------------------------------------
---------
Additional options to pass when preprocessing. The preprocessing options
will be used in all cases where kbuild does preprocessing including
building C files and assembler files.
KAFLAGS
--------------------------------------------------
-------
Additional options to the assembler (for built-in and modules).
AFLAGS_MODULE
--------------------------------------------------
-------------
Additional module specific options to use for $(AS).
AFLAGS_KERNEL
--------------------------------------------------
-------------
Additional options for $(AS) when used for assembler
code for code that is compiled as built-in.
KCFLAGS
--------------------------------------------------
-------
Additional options to the C compiler (for built-in and modules).
CFLAGS_KERNEL
--------------------------------------------------
-------------
Additional options for $(CC) when used to compile
code that is compiled as built-in.
CFLAGS_MODULE
--------------------------------------------------
-------------
Additional module specific options to use for $(CC).
LDFLAGS_MODULE
--------------------------------------------------
--------------
Additional options used for $(LD) when linking modules.
HOSTCFLAGS
--------------------------------------------------
----------
Additional flags to be passed to $(HOSTCC) when building host programs.
HOSTCXXFLAGS
--------------------------------------------------
------------
Additional flags to be passed to $(HOSTCXX) when building host programs.
HOSTLDFLAGS
--------------------------------------------------
-----------
Additional flags to be passed when linking host programs.
HOSTLDLIBS
--------------------------------------------------
----------
Additional libraries to link against when building host programs.
KBUILD_KCONFIG
--------------------------------------------------
--------------
Set the top-level Kconfig file to the value of this environment
variable. The default name is "Kconfig".
KBUILD_VERBOSE
--------------------------------------------------
--------------
Set the kbuild verbosity. Can be assigned same values as "V=...".
See make help for the full list.
Setting "V=..." takes precedence over KBUILD_VERBOSE.
KBUILD_EXTMOD
--------------------------------------------------
-------------
Set the directory to look for the kernel source when building external
modules.
Setting "M=..." takes precedence over KBUILD_EXTMOD.
KBUILD_OUTPUT
--------------------------------------------------
-------------
Specify the output directory when building the kernel.
The output directory can also be specified using "O=...".
Setting "O=..." takes precedence over KBUILD_OUTPUT.
KBUILD_DEBARCH
--------------------------------------------------
--------------
For the deb-pkg target, allows overriding the normal heuristics deployed by
deb-pkg. Normally deb-pkg attempts to guess the right architecture based on
the UTS_MACHINE variable, and on some architectures also the kernel config.
......@@ -103,44 +115,48 @@ The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian
architecture.
ARCH
--------------------------------------------------
----
Set ARCH to the architecture to be built.
In most cases the name of the architecture is the same as the
directory name found in the arch/ directory.
But some architectures such as x86 and sparc have aliases.
x86: i386 for 32 bit, x86_64 for 64 bit
sh: sh for 32 bit, sh64 for 64 bit
sparc: sparc32 for 32 bit, sparc64 for 64 bit
- x86: i386 for 32 bit, x86_64 for 64 bit
- sh: sh for 32 bit, sh64 for 64 bit
- sparc: sparc32 for 32 bit, sparc64 for 64 bit
CROSS_COMPILE
--------------------------------------------------
-------------
Specify an optional fixed part of the binutils filename.
CROSS_COMPILE can be a part of the filename or the full path.
CROSS_COMPILE is also used for ccache in some setups.
CF
--------------------------------------------------
--
Additional options for sparse.
CF is often used on the command-line like this:
CF is often used on the command-line like this::
make CF=-Wbitwise C=2
INSTALL_PATH
--------------------------------------------------
------------
INSTALL_PATH specifies where to place the updated kernel and system map
images. Default is /boot, but you can set it to other values.
INSTALLKERNEL
--------------------------------------------------
-------------
Install script called when using "make install".
The default name is "installkernel".
The script will be called with the following arguments:
$1 - kernel version
$2 - kernel image file
$3 - kernel map file
$4 - default install path (use root directory if blank)
- $1 - kernel version
- $2 - kernel image file
- $3 - kernel map file
- $4 - default install path (use root directory if blank)
The implementation of "make install" is architecture specific
and it may differ from the above.
......@@ -149,32 +165,33 @@ INSTALLKERNEL is provided to enable the possibility to
specify a custom installer when cross compiling a kernel.
MODLIB
--------------------------------------------------
------
Specify where to install modules.
The default value is:
The default value is::
$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
The value can be overridden in which case the default value is ignored.
INSTALL_MOD_PATH
--------------------------------------------------
----------------
INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
relocations required by build roots. This is not defined in the
makefile but the argument can be passed to make if needed.
INSTALL_MOD_STRIP
--------------------------------------------------
-----------------
INSTALL_MOD_STRIP, if defined, will cause modules to be
stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
the default option --strip-debug will be used. Otherwise,
INSTALL_MOD_STRIP value will be used as the options to the strip command.
INSTALL_HDR_PATH
--------------------------------------------------
----------------
INSTALL_HDR_PATH specifies where to install user space headers when
executing "make headers_*".
The default value is:
The default value is::
$(objtree)/usr
......@@ -184,65 +201,65 @@ The output directory is often set using "O=..." on the commandline.
The value can be overridden in which case the default value is ignored.
KBUILD_SIGN_PIN
--------------------------------------------------
---------------
This variable allows a passphrase or PIN to be passed to the sign-file
utility when signing kernel modules, if the private key requires such.
KBUILD_MODPOST_WARN
--------------------------------------------------
-------------------
KBUILD_MODPOST_WARN can be set to avoid errors in case of undefined
symbols in the final module linking stage. It changes such errors
into warnings.
KBUILD_MODPOST_NOFINAL
--------------------------------------------------
----------------------
KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
This is solely useful to speed up test compiles.
KBUILD_EXTRA_SYMBOLS
--------------------------------------------------
--------------------
For modules that use symbols from other modules.
See more details in modules.txt.
ALLSOURCE_ARCHS
--------------------------------------------------
---------------
For tags/TAGS/cscope targets, you can specify more than one arch
to be included in the databases, separated by blank space. E.g.:
to be included in the databases, separated by blank space. E.g.::
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
To get all available archs you can also specify all. E.g.:
To get all available archs you can also specify all. E.g.::
$ make ALLSOURCE_ARCHS=all tags
KBUILD_ENABLE_EXTRA_GCC_CHECKS
--------------------------------------------------
------------------------------
If enabled over the make command line with "W=1", it turns on additional
gcc -W... options for more extensive build-time checking.
KBUILD_BUILD_TIMESTAMP
--------------------------------------------------
----------------------
Setting this to a date string overrides the timestamp used in the
UTS_VERSION definition (uname -v in the running kernel). The value has to
be a string that can be passed to date -d. The default value
is the output of the date command at one point during build.
KBUILD_BUILD_USER, KBUILD_BUILD_HOST
--------------------------------------------------
------------------------------------
These two variables allow to override the user@host string displayed during
boot and in /proc/version. The default value is the output of the commands
whoami and host, respectively.
KBUILD_LDS
--------------------------------------------------
----------
The linker script with full path. Assigned by the top-level Makefile.
KBUILD_VMLINUX_OBJS
--------------------------------------------------
-------------------
All object files for vmlinux. They are linked to vmlinux in the same
order as listed in KBUILD_VMLINUX_OBJS.
KBUILD_VMLINUX_LIBS
--------------------------------------------------
-------------------
All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and KBUILD_VMLINUX_LIBS
together specify all the object files used to link vmlinux.
================
Kconfig Language
================
Introduction
------------
The configuration database is a collection of configuration options
organized in a tree structure:
organized in a tree structure::
+- Code maturity level options
| +- Prompt for development and/or incomplete code/drivers
......@@ -25,9 +29,9 @@ Menu entries
------------
Most entries define a config option; all other entries help to organize
them. A single configuration option is defined like this:
them. A single configuration option is defined like this::
config MODVERSIONS
config MODVERSIONS
bool "Set version information on all module symbols"
depends on MODULES
help
......@@ -52,10 +56,12 @@ applicable everywhere (see syntax).
Every config option must have a type. There are only two basic types:
tristate and string; the other types are based on these two. The type
definition optionally accepts an input prompt, so these two examples
are equivalent:
are equivalent::
bool "Networking support"
and
and::
bool
prompt "Networking support"
......@@ -98,8 +104,10 @@ applicable everywhere (see syntax).
d) Hardware or infrastructure that everybody expects, such as CONFIG_NET
or CONFIG_BLOCK. These are rare exceptions.
- type definition + default value:
- type definition + default value::
"def_bool"/"def_tristate" <expr> ["if" <expr>]
This is a shorthand notation for a type definition plus a value.
Optionally dependencies for this default value can be added with "if".
......@@ -107,11 +115,13 @@ applicable everywhere (see syntax).
This defines a dependency for this menu entry. If multiple
dependencies are defined, they are connected with '&&'. Dependencies
are applied to all other options within this menu entry (which also
accept an "if" expression), so these two examples are equivalent:
accept an "if" expression), so these two examples are equivalent::
bool "foo" if BAR
default y if BAR
and
and::
depends on BAR
bool "foo"
default y
......@@ -124,6 +134,7 @@ applicable everywhere (see syntax).
times, the limit is set to the largest selection.
Reverse dependencies can only be used with boolean or tristate
symbols.
Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
......@@ -139,24 +150,26 @@ applicable everywhere (see syntax).
symbol except that the "implied" symbol's value may still be set to n
from a direct dependency or with a visible prompt.
Given the following example:
Given the following example::
config FOO
config FOO
tristate
imply BAZ
config BAZ
config BAZ
tristate
depends on BAR
The following values are possible:
=== === ============= ==============
FOO BAR BAZ's default choice for BAZ
--- --- ------------- --------------
=== === ============= ==============
n y n N/m/y
m y m M/y/n
y y y Y/n
y n * N
=== === ============= ==============
This is useful e.g. with multiple drivers that want to indicate their
ability to hook into a secondary subsystem while allowing the user to
......@@ -208,9 +221,9 @@ Menu dependencies
Dependencies define the visibility of a menu entry and can also reduce
the input range of tristate symbols. The tristate logic used in the
expressions uses one more state than normal boolean logic to express the
module state. Dependency expressions have the following syntax:
module state. Dependency expressions have the following syntax::
<expr> ::= <symbol> (1)
<expr> ::= <symbol> (1)
<symbol> '=' <symbol> (2)
<symbol> '!=' <symbol> (3)
<symbol1> '<' <symbol2> (4)
......@@ -222,7 +235,7 @@ module state. Dependency expressions have the following syntax:
<expr> '&&' <expr> (7)
<expr> '||' <expr> (8)
Expressions are listed in decreasing order of precedence.
Expressions are listed in decreasing order of precedence.
(1) Convert the symbol into an expression. Boolean and tristate symbols
are simply converted into the respective expression values. All
......@@ -255,15 +268,15 @@ Menu structure
--------------
The position of a menu entry in the tree is determined in two ways. First
it can be specified explicitly:
it can be specified explicitly::
menu "Network device support"
menu "Network device support"
depends on NET
config NETDEVICES
config NETDEVICES
...
endmenu
endmenu
All entries within the "menu" ... "endmenu" block become a submenu of
"Network device support". All subentries inherit the dependencies from
......@@ -275,17 +288,18 @@ dependencies. If a menu entry somehow depends on the previous entry, it
can be made a submenu of it. First, the previous (parent) symbol must
be part of the dependency list and then one of these two conditions
must be true:
- the child entry must become invisible, if the parent is set to 'n'
- the child entry must only be visible, if the parent is visible
- the child entry must only be visible, if the parent is visible::
config MODULES
config MODULES
bool "Enable loadable module support"
config MODVERSIONS
config MODVERSIONS
bool "Set version information on all module symbols"
depends on MODULES
comment "module support disabled"
comment "module support disabled"
depends on !MODULES
MODVERSIONS directly depends on MODULES, this means it's only visible if
......@@ -299,6 +313,7 @@ Kconfig syntax
The configuration file describes a series of menu entries, where every
line starts with a keyword (except help texts). The following keywords
end a menu entry:
- config
- menuconfig
- choice/endchoice
......@@ -306,17 +321,17 @@ end a menu entry:
- menu/endmenu
- if/endif
- source
The first five also start the definition of a menu entry.
config:
The first five also start the definition of a menu entry.
config::
"config" <symbol>
<config options>
This defines a config symbol <symbol> and accepts any of above
attributes as options.
menuconfig:
menuconfig::
"menuconfig" <symbol>
<config options>
......@@ -325,43 +340,43 @@ hint to front ends, that all suboptions should be displayed as a
separate list of options. To make sure all the suboptions will really
show up under the menuconfig entry and not outside of it, every item
from the <config options> list must depend on the menuconfig symbol.
In practice, this is achieved by using one of the next two constructs:
(1):
menuconfig M
if M
config C1
config C2
endif
(2):
menuconfig M
config C1
depends on M
config C2
depends on M
In practice, this is achieved by using one of the next two constructs::
(1):
menuconfig M
if M
config C1
config C2
endif
(2):
menuconfig M
config C1
depends on M
config C2
depends on M
In the following examples (3) and (4), C1 and C2 still have the M
dependency, but will not appear under menuconfig M anymore, because
of C0, which doesn't depend on M:
(3):
menuconfig M
config C0
if M
config C1
config C2
endif
(4):
menuconfig M
config C0
config C1
depends on M
config C2
depends on M
choices:
of C0, which doesn't depend on M::
(3):
menuconfig M
config C0
if M
config C1
config C2
endif
(4):
menuconfig M
config C0
config C1
depends on M
config C2