docs/devel/kconfig.rst

16 Each QEMU target enables a subset of the boards, devices and buses that
18 only links a small subset of the files that form QEMU's source code;
19 anything that is not needed to support a particular target is culled.
27   include all the required dependencies and all the devices that the
28   user can add to that board;
30 * users can easily build reduced versions of QEMU that support only a subset
32   all emulated PCI devices that QEMU supports, but the build process is
36 This domain-specific language is based on the Kconfig language that
44 QEMU; the default configuration that QEMU ships with should be okay in
51 Note that configurable components are _not_ visible in C code as preprocessor
99   Note that unlike Linux's Kconfig implementation, QEMU will detect
167   of directives that cooperate so that a default configuration includes
168   all the devices that can be accessed from QEMU.
170   Devices *depend on* the bus that they lie on, for example a PCI
173   that the device provides, for example a SCSI adapter would specify
178   Devices also select any optional subsystem that they use; for example
201   that users might reasonably want to plug in to an i2c bus on any
202   board (and not ones which are very board-specific or that need
203   to be wired up in a way that can't be done on the command line).
204   ``TEST_DEVICES`` instead is used for devices that are rarely used on
237   Other symbols that are commonly used as dependencies for boards
252   Internal elements group code that is useful in several boards or
306 Right now there is no single place that lists all the optional devices
308 we expect that ``.mak`` files will be automatically generated, so that
315 that are detected by QEMU's configure or ``meson.build`` scripts; for