X-Git-Url: http://pileus.org/git/?a=blobdiff_plain;f=Documentation%2Fkbuild%2Fkconfig-language.txt;h=c412c245848f9116fb05361bb78e5189b43cfd51;hb=7c51d57e9d7fbce89f79c41dc8da383101dbe9c6;hp=53ca12f7999fdaf2137336584adead3c5adeb6e9;hpb=0486bc9098f4556a0aa90d57f717d08164b7647e;p=~andy%2Flinux diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index 53ca12f7999..c412c245848 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -104,14 +104,15 @@ applicable everywhere (see syntax). Reverse dependencies can only be used with boolean or tristate symbols. Note: - select is evil.... select will by brute force set a symbol - equal to 'y' without visiting the dependencies. So abusing - select you are able to select a symbol FOO even if FOO depends - on BAR that is not set. In general use select only for - non-visible symbols (no prompts anywhere) and for symbols with - no dependencies. That will limit the usefulness but on the - other hand avoid the illegal configurations all over. kconfig - should one day warn about such things. + select should be used with care. select will force + a symbol to a value without visiting the dependencies. + By abusing select you are able to select a symbol FOO even + if FOO depends on BAR that is not set. + In general use select only for non-visible symbols + (no prompts anywhere) and for symbols with no dependencies. + That will limit the usefulness but on the other hand avoid + the illegal configurations all over. + kconfig should one day warn about such things. - numerical ranges: "range" ["if" ] This allows to limit the range of possible input values for int @@ -127,6 +128,27 @@ applicable everywhere (see syntax). used to help visually separate configuration logic from help within the file as an aid to developers. +- misc options: "option" [=] + Various less common options can be defined via this option syntax, + which can modify the behaviour of the menu entry and its config + symbol. These options are currently possible: + + - "defconfig_list" + This declares a list of default entries which can be used when + looking for the default configuration (which is used when the main + .config doesn't exists yet.) + + - "modules" + This declares the symbol to be used as the MODULES symbol, which + enables the third modular state for all config symbols. + + - "env"= + This imports the environment variable into Kconfig. It behaves like + a default, except that the value comes from the environment, this + also means that the behaviour when mixing it with normal defaults is + undefined at this point. The symbol is currently not exported back + to the build environment (if this is desired, it can be done via + another symbol). Menu dependencies ----------------- @@ -309,37 +331,49 @@ This is a collection of Kconfig tips, most of which aren't obvious at first glance and most of which have become idioms in several Kconfig files. -Build as module only -~~~~~~~~~~~~~~~~~~~~ -To restrict a component build to module-only, qualify its config symbol -with "depends on m". E.g.: +Adding common features and make the usage configurable +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +It is a common idiom to implement a feature/functionality that are +relevant for some architectures but not all. +The recommended way to do so is to use a config variable named HAVE_* +that is defined in a common Kconfig file and selected by the relevant +architectures. +An example is the generic IOMAP functionality. -config FOO - depends on BAR && m +We would in lib/Kconfig see: -limits FOO to module (=m) or disabled (=n). +# Generic IOMAP is used to ... +config HAVE_GENERIC_IOMAP +config GENERIC_IOMAP + depends on HAVE_GENERIC_IOMAP && FOO -Build limited by a third config symbol which may be =y or =m -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A common idiom that we see (and sometimes have problems with) is this: +And in lib/Makefile we would see: +obj-$(CONFIG_GENERIC_IOMAP) += iomap.o -When option C in B (module or subsystem) uses interfaces from A (module -or subsystem), and both A and B are tristate (could be =y or =m if they -were independent of each other, but they aren't), then we need to limit -C such that it cannot be built statically if A is built as a loadable -module. (C already depends on B, so there is no dependency issue to -take care of here.) +For each architecture using the generic IOMAP functionality we would see: -If A is linked statically into the kernel image, C can be built -statically or as loadable module(s). However, if A is built as loadable -module(s), then C must be restricted to loadable module(s) also. This -can be expressed in kconfig language as: +config X86 + select ... + select HAVE_GENERIC_IOMAP + select ... -config C - depends on A = y || A = B +Note: we use the existing config option and avoid creating a new +config variable to select HAVE_GENERIC_IOMAP. -or for real examples, use this command in a kernel tree: +Note: the use of the internal config variable HAVE_GENERIC_IOMAP, it is +introduced to overcome the limitation of select which will force a +config option to 'y' no matter the dependencies. +The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the +situation where select forces a symbol equals to 'y'. -$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig +Build as module only +~~~~~~~~~~~~~~~~~~~~ +To restrict a component build to module-only, qualify its config symbol +with "depends on m". E.g.: + +config FOO + depends on BAR && m + +limits FOO to module (=m) or disabled (=n).