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” <prompt> [“if” <expr>]

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

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

默认值故意默认为“n”，以避免构建膨胀。除少数例外，新的配置选项不应更改此设置。其目的是让“make oldconfig”尽可能少地将配置从一个版本添加到另一个版本。

注意
值得“default y/m”的事项包括

用于过去总是构建的内容的新 Kconfig 选项应为“default y”。

隐藏/显示其他 Kconfig 选项（但不生成任何自己的代码）的新 gatekeeping Kconfig 选项应为“default y”，以便人们可以看到那些其他选项。

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

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

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

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

虽然普通依赖关系会降低符号的上限（请参阅下文），但反向依赖关系可用于强制另一个符号的下限。当前菜单符号的值用作可以设置为的最小值的 <symbol>。如果多次选择 <symbol>，则限制设置为最大的选择。反向依赖关系只能用于布尔或 tristate 符号。

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

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

这类似于“select”，因为它对另一个符号强制执行下限，只不过“implied”符号的值仍然可以从直接依赖项或使用可见提示设置为 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
例如，这在使用想要指示其连接到辅助子系统的能力的多个驱动程序时很有用，同时允许用户配置该子系统，而无需取消设置这些驱动程序。

注意：如果 BAZ 提供的功能对于 FOO 而言非常理想，则 FOO 不仅应 imply BAZ，还应 imply 其依赖项 BAR
```
config FOO
    tristate "foo"
    imply BAR
    imply BAZ
```
注意：如果“imply” <symbol> 后跟“if” <expr>，则 <symbol> 的默认值将是当前菜单符号的值和 <expr> 的逻辑与。（此行为的未来尚未决定。）
限制菜单显示：“visible if” <expr>

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

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

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

菜单依赖关系¶

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

<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)

表达式按优先级降序列出。

将符号转换为表达式。布尔和 tristate 符号只需转换为相应的表达式值。所有其他符号类型都导致“n”。
如果两个符号的值相等，则返回“y”，否则返回“n”。
如果两个符号的值相等，则返回“n”，否则返回“y”。
如果 <symbol1> 的值分别低于、高于、低于或等于或大于或等于 <symbol2> 的值，则返回“y”，否则返回“n”。
返回表达式的值。用于覆盖优先级。
返回 (2-/expr/) 的结果。
返回 min(/expr/, /expr/) 的结果。
返回 max(/expr/, /expr/) 的结果。

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

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

菜单结构¶

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

menu "Network device support"
      depends on NET

config NETDEVICES
      ...

endmenu

“menu” ... “endmenu” 块中的所有条目都成为“Network device support”的子菜单。所有子条目都继承菜单条目的依赖关系，例如，这意味着依赖关系“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>

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

menuconfig

"menuconfig" <symbol>
<config options>

这与上面的简单 config 条目类似，但它也向前端提供提示，即所有子选项应显示为单独的选项列表。为了确保所有子选项都将真正显示在 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_* 的 config 变量，该变量在常见的 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 ...

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

注意：使用内部 config 变量 HAVE_GENERIC_IOMAP，引入它是为了克服 select 的限制，无论依赖关系如何，它都会强制 config 选项为“y”。依赖关系已移至符号 GENERIC_IOMAP，我们避免了 select 强制符号等于“y”的情况。

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

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

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

如果您需要公开编译器功能以进行 makefile 和/或 C 源文件，则 CC_HAS_ 是 config 选项的推荐前缀

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

仅作为模块构建¶

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

config FOO
      depends on BAR && m

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

编译测试¶

如果一个 config 符号具有依赖关系，但如果未满足依赖关系，则仍可以编译由 config 符号控制的代码，则鼓励通过将“|| 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 完全被禁用。 BAR 模块必须为 !BAR 情况提供所有存根。

如果存在具有相同依赖关系的多个驱动程序，则可以使用辅助符号来获得更正式的方法，例如

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

config BAR_OPTIONAL
      def_tristate BAR || !BAR

表达可选依赖性的一种不太受欢迎的方式是在模块代码中使用 IS_REACHABLE()，例如，当模块 BAR 不提供 !BAR 存根时很有用

foo_init()
{
        if (IS_REACHABLE(CONFIG_BAR))
                bar_register(&foo);
        ...
}

通常不鼓励使用 IS_REACHABLE()，因为当 CONFIG_BAR=m 并且此代码是内置时，代码将被静默丢弃。这不是用户在将 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”来使用示例 Kconfig 文件 Documentation/kbuild/Kconfig.recursion-issue-01 测试 a) 的解决方案，因为 CORE_BELL_A 依赖于 CORE，因此这已经是隐含的。有时可能无法删除某些依赖关系标准，对于这种情况，可以使用解决方案 b)。

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

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

commit	修复
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 工作¶

欢迎在 Kconfig 上进行工作，包括澄清语义和评估使用完整的 SAT 求解器。完整的 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 节：对有效性的威胁）。 kismet 工具基于 [10] 中的语义，发现了对反向依赖关系的滥用，并导致对 Linux Kconfig 文件进行了数十次提交修复[11]。

确认这一点可能很有用，因为 Kconfig 是领先的工业可变性建模语言之一[1] [2]。对其的研究将有助于评估此类语言的实际用途，它们的用途仅是理论性的，并且对实际世界的要求的理解还不够。但是，只有反向工程技术被用来从可变性建模语言（如 Kconfig）中推断语义[3]。

Kconfig 的完整 SAT 求解器¶

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

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

Linux 内核

目录

本页