Kconfig 语言¶

简介¶

配置数据库是组织成树状结构的配置选项的集合

+- Code maturity level options
|  +- Prompt for development and/or incomplete code/drivers
+- General setup
|  +- Networking support
|  +- System V IPC
|  +- BSD Process Accounting
|  +- Sysctl support
+- Loadable module support
|  +- Enable loadable module support
|     +- Set version information on all module symbols
|     +- Kernel module loader
+- ...

每个条目都有其自己的依赖关系。这些依赖关系用于确定条目的可见性。只有当其父条目也可见时，任何子条目才可见。

菜单项¶

大多数条目定义一个配置选项；所有其他条目帮助组织它们。单个配置选项定义如下

config MODVERSIONS
      bool "Set version information on all module symbols"
      depends on MODULES
      help
        Usually, modules have to be recompiled whenever you switch to a new
        kernel.  ...

每一行都以关键字开头，后跟多个参数。“config”开始一个新的配置条目。以下行定义此配置选项的属性。属性可以是配置选项的类型、输入提示、依赖关系、帮助文本和默认值。一个配置选项可以多次定义为相同的名称，但每个定义只能有一个输入提示，并且类型不能冲突。

菜单属性¶

菜单项可以有许多属性。并非所有属性都适用于所有地方（请参阅语法）。

类型定义：“bool”/“tristate”/“string”/“hex”/“int”

每个配置选项都必须有一个类型。只有两个基本类型：tristate 和 string；其他类型基于这两个类型。类型定义可以选择接受输入提示，因此这两个示例是等效的
```
bool "Networking support"
```
和
```
bool
prompt "Networking support"
```
输入提示：“prompt” <提示> [“if” <表达式>]

每个菜单项最多可以有一个提示，用于向用户显示。可以选择使用“if”添加仅针对此提示的依赖关系。如果不存在提示，则配置选项是不可见的符号，这意味着用户无法直接更改其值（例如，更改 .config 中的值），并且该选项不会出现在任何配置菜单中。其值只能通过“default”和“select”（见下文）设置。
默认值：“default” <表达式> [“if” <表达式>]

一个配置选项可以有任意数量的默认值。如果多个默认值可见，则只有第一个定义的默认值处于活动状态。默认值不限于定义它们的菜单项。这意味着可以在其他地方定义默认值，或者被较早的定义覆盖。仅当用户（通过上面的输入提示）未设置任何其他值时，默认值才会分配给配置符号。如果输入提示可见，则会向用户显示默认值，并且用户可以覆盖它。可以选择使用“if”添加仅针对此默认值的依赖关系。

默认值故意默认为“n”，以避免构建膨胀。除了少数例外，新的配置选项不应更改此设置。目的是让“make oldconfig”在版本之间尽可能少地向配置添加内容。

注意
值得使用“default y/m”的情况包括

以前总是构建的新功能的 Kconfig 选项应为“default y”。

隐藏/显示其他 Kconfig 选项（但不生成任何代码本身）的新门控 Kconfig 选项应为“default y”，以便人们会看到这些其他选项。

“default n”的驱动程序的子驱动程序行为或类似选项。这使您可以提供合理的默认值。

每个人都期望的硬件或基础设施，例如 CONFIG_NET 或 CONFIG_BLOCK。这些是罕见的例外。

类型定义 + 默认值
```
"def_bool"/"def_tristate" <expr> ["if" <expr>]
```
这是类型定义和值的简写表示法。可以选择使用“if”添加此默认值的依赖关系。
依赖关系：“depends on” <表达式>

这定义了此菜单项的依赖关系。如果定义了多个依赖关系，则它们使用“&&”连接。依赖关系应用于此菜单项中的所有其他选项（也接受“if”表达式），因此以下两个示例是等效的
```
bool "foo" if BAR
default y if BAR
```
和
```
depends on BAR
bool "foo"
default y
```
反向依赖关系：“select” <符号> [“if” <表达式>]

虽然正常的依赖关系会降低符号的上限（见下文），但可以使用反向依赖关系来强制其他符号的下限。当前菜单符号的值用作可以设置 <符号> 的最小值。如果多次选择 <符号>，则限制设置为最大的选择。反向依赖关系只能用于布尔值或三态符号。

注意
应谨慎使用 select。select 将强制符号设置为值，而无需访问依赖关系。通过滥用 select，您可以选择一个符号 FOO，即使 FOO 依赖于未设置的 BAR。通常，select 仅用于不可见的符号（任何地方都没有提示）和没有依赖关系的符号。这将限制其有用性，但另一方面，可以避免所有非法配置。

如果“select” <符号> 后跟“if” <表达式>，则 <符号> 将通过当前菜单符号的值和 <表达式> 的逻辑 AND 选择。这意味着，由于存在“if” <表达式>，下限可以被降低。此行为可能看起来很奇怪，但我们依赖于它。（此行为的未来尚未决定。）
弱反向依赖关系：“imply” <符号> [“if” <表达式>]

这类似于“select”，因为它对另一个符号强制下限，只是“暗示”的符号的值仍然可以通过直接依赖关系或可见提示设置为 n。

给定以下示例
```
config FOO
    tristate "foo"
    imply BAZ

config BAZ
    tristate "baz"
    depends on BAR
```
以下值是可能的
FOO

BAR

BAZ 的默认值

BAZ 的选择
n

y

n

N/m/y

m

y

m

M/y/n

y

y

y

Y/m/n

n

m

n

N/m

m

m

m

M/n

y

m

m

M/n

y

n

N
这很有用，例如，当多个驱动程序想要指示它们能够挂接到辅助子系统中，同时允许用户配置该子系统而无需取消设置这些驱动程序时。

注意：如果 FOO=y 和 BAZ=m 的组合导致链接错误，则可以使用 IS_REACHABLE() 保护函数调用
```
foo_init()
{
        if (IS_REACHABLE(CONFIG_BAZ))
                baz_register(&foo);
        ...
}
```
注意：如果 BAZ 提供的功能对于 FOO 非常理想，则 FOO 不仅应暗示 BAZ，还应暗示其依赖项 BAR
```
config FOO
    tristate "foo"
    imply BAR
    imply BAZ
```
注意：如果“imply” <符号> 后跟“if” <表达式>，则 <符号> 的默认值将是当前菜单符号的值和 <表达式> 的逻辑 AND。（此行为的未来尚未决定。）
限制菜单显示：“visible if” <表达式>

此属性仅适用于菜单块，如果条件为假，则不会向用户显示该菜单块（但其中包含的符号仍然可以被其他符号选择）。它类似于单个菜单项的条件“prompt”属性。“visible”的默认值为 true。
数值范围：“range” <符号> <符号> [“if” <表达式>]

这允许限制 int 和 hex 符号的可能输入值的范围。用户只能输入大于或等于第一个符号且小于或等于第二个符号的值。
帮助文本：“help”

这定义了帮助文本。帮助文本的结尾由缩进级别确定，这意味着它在第一行缩进小于帮助文本第一行的缩进时结束。
模块属性：“modules” 这声明该符号用作 MODULES 符号，这将为所有配置符号启用第三个模块化状态。最多只能有一个符号设置了“modules”选项。

菜单依赖¶

依赖关系定义了菜单项的可见性，并且还可以减小三态符号的输入范围。表达式中使用的三态逻辑比普通布尔逻辑多使用一个状态来表示模块状态。依赖表达式具有以下语法

<expr> ::= <symbol>                           (1)
         <symbol> '=' <symbol>                (2)
         <symbol> '!=' <symbol>               (3)
         <symbol1> '<' <symbol2>              (4)
         <symbol1> '>' <symbol2>              (4)
         <symbol1> '<=' <symbol2>             (4)
         <symbol1> '>=' <symbol2>             (4)
         '(' <expr> ')'                       (5)
         '!' <expr>                           (6)
         <expr> '&&' <expr>                   (7)
         <expr> '||' <expr>                   (8)

表达式按优先级递减顺序列出。

将符号转换为表达式。布尔值和三态符号只是简单地转换为各自的表达式值。所有其他符号类型都产生“n”。
如果两个符号的值相等，则返回“y”，否则返回“n”。
如果两个符号的值相等，则返回“n”，否则返回“y”。
如果 <符号 1> 的值分别小于、大于、小于等于或大于等于 <符号 2> 的值，则返回“y”，否则返回“n”。
返回表达式的值。用于覆盖优先级。
返回 (2-/表达式/) 的结果。
返回 min(/表达式/, /表达式/) 的结果。
返回 max(/表达式/, /表达式/) 的结果。

表达式的值可以是“n”、“m”或“y”（或对于计算分别为 0、1、2）。当菜单项的表达式计算结果为“m”或“y”时，该菜单项变为可见。

有两种类型的符号：常量符号和非常量符号。非常量符号是最常见的，并且使用“config”语句定义。非常量符号完全由字母数字字符或下划线组成。常量符号只是表达式的一部分。常量符号始终用单引号或双引号括起来。在引号内，允许使用任何其他字符，并且可以使用“'”转义引号。

菜单结构¶

菜单项在树中的位置以两种方式确定。首先可以显式指定

menu "Network device support"
      depends on NET

config NETDEVICES
      ...

endmenu

“menu”...“endmenu”块中的所有条目都成为“网络设备支持”的子菜单。所有子条目都继承菜单项的依赖关系，例如，这意味着依赖关系“NET”被添加到配置选项 NETDEVICES 的依赖关系列表中。

生成菜单结构的另一种方法是通过分析依赖关系来完成的。如果菜单项以某种方式依赖于前一个条目，则可以将其设为其子菜单。首先，前一个（父）符号必须是依赖列表的一部分，然后必须满足以下两个条件之一

如果父项设置为“n”，则子条目必须变为不可见

只有当父项可见时，子条目才必须可见

config MODULES
    bool "Enable loadable module support"

config MODVERSIONS
    bool "Set version information on all module symbols"
    depends on MODULES

comment "module support disabled"
    depends on !MODULES

MODVERSIONS 直接依赖于 MODULES，这意味着只有当 MODULES 与“n”不同时才可见。另一方面，注释只有当 MODULES 设置为“n”时才可见。

Kconfig 语法¶

配置文件描述了一系列菜单项，其中每一行都以关键字开头（帮助文本除外）。以下关键字结束菜单项

config
menuconfig
choice/endchoice
comment
menu/endmenu
if/endif
source

前五个关键字也开始定义菜单项。

config

"config" <symbol>
<config options>

这定义了一个配置符号 <符号>，并接受上述任何属性作为选项。

menuconfig

"menuconfig" <symbol>
<config options>

这与上面的简单配置条目类似，但它也给前端一个提示，即所有子选项应显示为单独的选项列表。为了确保所有子选项都将真正显示在 menuconfig 条目下，而不是在它之外，<config options> 列表中的每个项目都必须依赖于 menuconfig 符号。在实践中，这可以通过使用以下两种构造之一来实现。

(1):
menuconfig M
if M
    config C1
    config C2
endif

(2):
menuconfig M
config C1
    depends on M
config C2
    depends on M

在以下示例 (3) 和 (4) 中，C1 和 C2 仍然具有 M 依赖项，但由于 C0 不依赖于 M，它们将不再出现在 menuconfig 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

"choice"
<choice options>
<choice block>
"endchoice"

这定义了一个选择组，并接受 “prompt”、“default”、“depends on” 和 “help” 属性作为选项。

一个选择只允许选择一个配置条目。

comment

"comment" <prompt>
<comment options>

这定义了一个注释，该注释在配置过程中显示给用户，并且还会回显到输出文件中。唯一可能的选项是依赖项。

menu

"menu" <prompt>
<menu options>
<menu block>
"endmenu"

这定义了一个菜单块，有关更多信息，请参见上面的“菜单结构”。唯一可能的选项是依赖项和“visible”属性。

if

"if" <expr>
<if block>
"endif"

这定义了一个 if 块。依赖表达式 <expr> 被附加到所有封闭的菜单条目。

source

"source" <prompt>

这将读取指定的配置文件。此文件始终会被解析。

mainmenu

"mainmenu" <prompt>

如果配置程序选择使用它，这将设置配置程序的标题栏。它应该放置在配置的顶部，在任何其他语句之前。

‘#’ Kconfig 源文件注释

源文件行中任何位置的未加引号的 ‘#’ 字符表示源文件注释的开始。该行的其余部分是注释。

Kconfig 提示¶

这是一组 Kconfig 技巧，其中大多数技巧乍一看并不明显，并且大多数技巧已成为多个 Kconfig 文件中的惯用语。

添加通用功能并使用法可配置¶

实现某些架构相关但不适用于所有架构的功能/特性是一种常见的惯用语。推荐的方法是使用一个名为 HAVE_* 的配置变量，该变量在通用的 Kconfig 文件中定义，并由相关的架构选择。一个例子是通用的 IOMAP 功能。

我们会在 lib/Kconfig 中看到

# Generic IOMAP is used to ...
config HAVE_GENERIC_IOMAP

config GENERIC_IOMAP
      depends on HAVE_GENERIC_IOMAP && FOO

在 lib/Makefile 中，我们会看到

obj-$(CONFIG_GENERIC_IOMAP) += iomap.o

对于每个使用通用 IOMAP 功能的架构，我们会看到

config X86
      select ...
      select HAVE_GENERIC_IOMAP
      select ...

注意：我们使用现有的配置选项，并避免创建新的配置变量来选择 HAVE_GENERIC_IOMAP。

注意：使用内部配置变量 HAVE_GENERIC_IOMAP，引入它是为了克服 select 的限制，这将强制配置选项为 ‘y’，而不管依赖关系如何。依赖关系被移动到符号 GENERIC_IOMAP，我们避免了 select 强制符号等于 ‘y’ 的情况。

添加需要编译器支持的功能¶

有几个功能需要编译器支持。描述对编译器功能的依赖关系的推荐方法是使用 “depends on”，后跟一个测试宏。

config STACKPROTECTOR
      bool "Stack Protector buffer overflow detection"
      depends on $(cc-option,-fstack-protector)
      ...

如果您需要将编译器功能公开给 makefiles 和/或 C 源文件，则 CC_HAS_ 是配置选项的推荐前缀。

config CC_HAS_FOO
      def_bool $(success,$(srctree)/scripts/cc-check-foo.sh $(CC))

仅作为模块构建¶

要将组件构建限制为仅模块，请使用 “depends on m” 限定其配置符号。例如：

config FOO
      depends on BAR && m

将 FOO 限制为模块 (=m) 或禁用 (=n)。

编译测试¶

如果配置符号具有依赖关系，但如果未满足该依赖关系，则仍可以编译由配置符号控制的代码，则建议通过向依赖项添加“|| COMPILE_TEST”子句来增加构建覆盖率。这对于更奇特的硬件驱动程序尤其有用，因为它允许持续集成系统在更常见的系统上编译测试代码，并以这种方式检测错误。请注意，在未满足依赖关系的系统上运行时，经过编译测试的代码应避免崩溃。

架构和平台依赖项¶

由于存根的存在，现在大多数驱动程序都可以在大多数架构上编译。但是，这并不意味着在所有地方都有所有驱动程序都有意义，因为实际硬件可能只存在于特定的架构和平台上。对于片上 SoC IP 核来说尤其如此，这些 IP 核可能仅限于特定的供应商或 SoC 系列。

为了防止询问用户关于用户正在为其编译内核的系统上无法使用的驱动程序，并且如果这有意义，则控制驱动程序编译的配置符号应包含适当的依赖关系，从而将符号的可见性限制为（平台子集）驱动程序可以使用的平台。依赖关系可以是架构（例如 ARM）或平台（例如 ARCH_OMAP4）依赖关系。这不仅使发行版配置所有者，而且使配置内核的每个开发人员或用户的生活更简单。

可以通过将其与上面的编译测试规则组合来放宽这种依赖关系，从而导致：

config FOO
bool “支持 foo 硬件” depends on ARCH_FOO_VENDOR || COMPILE_TEST

可选依赖项¶

某些驱动程序可以选择使用另一个模块的功能，或者在禁用该模块的情况下干净地构建，但是在尝试从内置驱动程序使用该可加载模块时会导致链接失败。

在 Kconfig 逻辑中表达此可选依赖关系的最常见方法是使用稍微违反直觉的方式：

config FOO
      tristate "Support for foo hardware"
      depends on BAR || !BAR

这意味着要么对 BAR 有依赖关系，该依赖关系不允许 FOO=y 与 BAR=m 的组合，要么 BAR 被完全禁用。如果有多个驱动程序具有相同的依赖关系，则可以使用一个辅助符号，例如：

config FOO
      tristate "Support for foo hardware"
      depends on BAR_OPTIONAL

config BAR_OPTIONAL
      def_tristate BAR || !BAR

Kconfig 递归依赖关系限制¶

如果您遇到了 Kconfig 错误：“检测到递归依赖关系”，则您遇到了 Kconfig 的递归依赖关系问题，递归依赖关系可以概括为循环依赖关系。kconfig 工具需要确保 Kconfig 文件符合指定的配置要求。为了做到这一点，kconfig 必须确定所有 Kconfig 符号的可能值，如果两个或多个 Kconfig 符号之间存在循环关系，则目前无法做到这一点。有关更多详细信息，请参阅下面的“简单的 Kconfig 递归问题”小节。Kconfig 不执行递归依赖关系解析；这对 Kconfig 文件编写者有一些影响。我们将首先解释为什么会出现此问题，然后提供一个示例技术限制，该限制给 Kconfig 开发人员带来了影响。希望尝试解决此限制的急切开发人员应阅读以下小节。

简单的 Kconfig 递归问题¶

请阅读：Documentation/kbuild/Kconfig.recursion-issue-01

使用以下命令测试：

make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig

累积的 Kconfig 递归问题¶

请阅读：Documentation/kbuild/Kconfig.recursion-issue-02

使用以下命令测试：

make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig

解决 kconfig 递归问题的实用方法¶

遇到递归 Kconfig 问题的开发人员可以选择两种方法。我们在下面记录了它们，还提供了一个通过这些不同解决方案解决的历史问题列表。

删除任何多余的 “select FOO” 或 “depends on FOO”

匹配依赖关系语义

b1) 将所有 “select FOO” 交换为 “depends on FOO”，或

b2) 将所有 “depends on FOO” 交换为 “select FOO”

可以通过从 CORE_BELL_A_ADVANCED 中删除 “select CORE” 来测试 a) 的解决方法，因为 CORE_BELL_A 依赖于 CORE，这已经是隐含的了。有时可能无法删除某些依赖关系标准，对于这种情况，您可以使用解决方案 b)。

可以在示例 Kconfig 文件 Documentation/kbuild/Kconfig.recursion-issue-02 中测试 b) 的两种不同的解决方法。

以下是先前针对这些类型的递归问题进行修复的示例列表；所有错误似乎都涉及一个或多个 “select” 语句和一个或多个 “depends on”。

commit	fix
06b718c01208	select A -> depends on A
c22eacfe82f9	depends on A -> depends on B
6a91e854442c	select A -> depends on A
118c565a8f2e	select A -> select B
f004e5594705	select A -> depends on A
c7861f37b4c6	depends on A -> (null)
80c69915e5fb	select A -> (null) (1)
c2218e26c0d0	select A -> depends on A (1)
d6ae99d04e1c	select A -> depends on A
95ca19cf8cbf	select A -> depends on A
8f057d7bca54	depends on A -> (null)
8f057d7bca54	depends on A -> select A
a0701f04846e	select A -> depends on A
0c8b92f7f259	depends on A -> (null)
e4e9e0540928	select A -> depends on A (2)
7453ea886e87	depends on A > (null) (1)
7b1fff7e4fdf	select A -> depends on A
86c747d2a4f0	select A -> depends on A
d9f9ab51e55e	select A -> depends on A
0c51a4d8abd6	depends on A -> select A (3)
e98062ed6dc4	select A -> depends on A (3)
91e5d284a7f1	select A -> (null)

部分（或无）引用错误。
这似乎是该修复的要点。
相同的错误。

未来的 kconfig 工作¶

欢迎在澄清语义和评估使用完整 SAT 求解器方面进行 kconfig 工作。为了支持更复杂的依赖关系映射和/或查询，可以使用完整 SAT 求解器，例如，SAT 求解器的一个可能的用例可能是处理当前已知的递归依赖关系问题。尚不清楚这是否会解决此类问题，但有必要进行此类评估。如果对完整 SAT 求解器的支持过于复杂，或者它无法解决递归依赖关系问题，则 Kconfig 至少应具有清晰且定义明确的语义，其中还应解决并记录诸如处理递归依赖关系之类的限制或要求。

欢迎在 Kconfig 的这两个领域开展进一步的工作。我们将在接下来的两个小节中详细阐述这两者。

Kconfig 的语义¶

Kconfig 的使用范围很广，Linux 现在只是 Kconfig 的用户之一：一项研究已经完成了对 12 个项目中使用 Kconfig 的广泛分析 [0]。尽管 Kconfig 应用广泛，并且尽管本文档在记录基本的 Kconfig 语法方面做得不错，但我们仍然欢迎对 Kconfig 语义进行更精确的定义。一个项目通过使用 xconfig 配置器推导出了 Kconfig 语义 [1]。应该进行工作以确认推导出的语义是否与我们预期的 Kconfig 设计目标相符。另一个项目形式化了 Kconfig 语言核心子集的指称语义 [10]。

拥有定义良好的语义对于工具进行依赖关系的实际评估非常有用。例如，一个这样的案例是将 Kconfig 推断的语义表达为布尔抽象，将 Kconfig 逻辑转换为布尔公式，并在此基础上运行 SAT 求解器，以查找死代码/功能（始终处于非活动状态）。使用这种方法在 Linux 中发现了 114 个死功能 [1] (第 8 节：对有效性的威胁)。基于 [10] 中语义的 kismet 工具可以发现对反向依赖关系的滥用，并导致了对 Linux Kconfig 文件的数十次提交修复 [11]。

证实这一点可能很有用，因为 Kconfig 是主要的工业可变性建模语言之一 [1] [2]。对它的研究将有助于评估此类语言的实际用途，此前其应用仅限于理论层面，而对现实世界的需求了解不足。目前，只有反向工程技术被用来推断 Kconfig 等可变性建模语言的语义 [3]。

Kconfig 的完整 SAT 求解器¶

虽然 SAT 求解器 [4] 尚未被 Kconfig 直接使用，正如上一小节中提到的，但是已经有人将 Kconfig 推断的语义表达为布尔抽象，将 Kconfig 逻辑转换为布尔公式，并在其上运行 SAT 求解器 [5]。另一个相关的已知项目是 CADOS [6]（前身为 VAMOS [7]）以及相关的工具，主要是 undertaker [8]，最初在 [9] 中被介绍。undertaker 的基本概念是从 Kconfig 中提取可变性模型，并将它们与从 CPP #ifdef 和构建规则中提取的命题公式一起放入 SAT 求解器中，以便查找死代码、死文件和死符号。如果希望在 Kconfig 上使用 SAT 求解器，一种方法是评估如何将这些工作重新利用到 Kconfig 上。现有项目的指导者有足够的兴趣，不仅可以帮助指导如何将这项工作集成到上游，还可以帮助长期维护它。有兴趣的开发人员应该访问

https://kernelnewbies.org/KernelProjects/kconfig-sat

Linux 内核

目录

本页