我拆开了 Kconfig: 从一个选项到 U-Boot 和 Linux 的条件编译

先纠正一个名字#

Kconfig 不是完整的构建系统。

我更愿意把整个过程分成 3 层：

1. Kconfig 描述有哪些配置符号、它们的类型、默认值和约束，并求出一份合法配置。
2. Kbuild/Makefile 读取配置，决定哪些目录和 .o 文件参加编译，以及传递哪些编译选项。
3. 编译器和链接器 根据宏继续裁剪 C 代码，最后生成内核或 U-Boot 镜像。

Kconfig 像配电柜：它决定哪些回路通电，但并不亲自制造电器。make menuconfig 只是配电柜的一块操作面板，不是配电柜本身，更不是发电厂。

这张图是本文最重要的地图。后面的每个文件都只是在这条数据流上承担一个角色。

我先造一个口袋大小的配置系统#

我使用 Linux 6.18 自带的 scripts/kconfig/，因为 U-Boot 的 Kconfig 语言源自 Linux，而 Linux 版本还保留了 m 这个最容易暴露三值逻辑的状态。先取得源码：

1
git clone --depth 1 --branch v6.18 \
2
  https://github.com/torvalds/linux.git linux-6.18
3
cd linux-6.18
4
mkdir -p lab/drivers

Kconfig 前端需要主机上的 C 编译器、GNU Make、Flex 和 Bison。menuconfig 还需要 ncurses 开发文件。这里只运行非交互的 alldefconfig，所以先不碰 ncurses。

根配置 lab/Kconfig 如下：

1
mainmenu "Pocket Board Configuration"
2

3
config MODULES
4
  bool "Enable loadable modules"
5
  modules
6
  default y
7

8
menu "Board"
9

10
config SOC_ALPHA
11
  bool "Alpha SoC"
12
  default y
13

14
config HAS_I2C
15
  bool
16
  default y if SOC_ALPHA
17

18
config LOG_LEVEL
19
  int "Log level"
20
  range 0 4
21
  default 2
22

23
endmenu
24

25
source "lab/drivers/Kconfig"

驱动配置放在 lab/drivers/Kconfig：

1
menu "Drivers"
2

3
config SENSOR
4
  tristate "Temperature sensor"
5
  depends on HAS_I2C
6
  default m
7

8
config SENSOR_DEBUG
9
  bool "Verbose sensor debugging"
10
  depends on SENSOR
11

12
config APP
13
  bool "Sensor application"
14
  select SENSOR_CORE
15

16
config SENSOR_CORE
17
  bool
18
  depends on HAS_I2C
19

20
endmenu

现在让 Linux 的构建入口编译 Kconfig 前端，并用所有符号的默认值求解一次：

1
make O="$PWD/out" KBUILD_KCONFIG=lab/Kconfig alldefconfig

O= 把生成物放进 out/，KBUILD_KCONFIG 把入口从内核根目录的 Kconfig 换成我的实验文件。第一次运行还会把 conf.c、解析器和词法分析器编译成主机程序 out/scripts/kconfig/conf。换句话说，配置 Linux 之前，Linux 先在我的电脑上编译了一个小型配置求解器（构建系统也要先构建自己，乌龟下面还是乌龟）。

我得到的 out/.config 核心部分是：

1
CONFIG_MODULES=y
2
CONFIG_SOC_ALPHA=y
3
CONFIG_HAS_I2C=y
4
CONFIG_LOG_LEVEL=2
5
CONFIG_SENSOR=m
6
# CONFIG_SENSOR_DEBUG is not set
7
# CONFIG_APP is not set

这里已经发生了几件值得追踪的事：

• 我没有直接设置 HAS_I2C，它从 SOC_ALPHA=y 的条件默认值得到 y。
• SENSOR 的上限允许到 y，默认值把它设成 m。
• SENSOR_DEBUG 没有显式 default，所以默认为 n。
• APP 同样默认为 n，因此它还没有触发 select。

Kconfig 文件不是按顺序执行的 Shell 脚本。解析器先收集符号与关系，再计算值、可见性和取值上下限。把它当成一个受约束的配置数据库，比把它当成一串赋值语句准确得多。

一个 config 到底定义了什么？#

最常见的条目是：

1
config SENSOR
2
  tristate "Temperature sensor"
3
  depends on HAS_I2C
4
  default m
5
  help
6
    Build support for the temperature sensor.

SENSOR 是符号名。写入配置文件时，前端通常给它加上 CONFIG_ 前缀，于是得到 CONFIG_SENSOR。Kconfig 源码中的依赖表达式仍然写 SENSOR，不要写 CONFIG_SENSOR。

一个符号常见的属性包括：

类型后的提示文字其实是 prompt 的简写：

1
bool "Alpha SoC"

等价于：

1
bool
2
prompt "Alpha SoC"

这解释了一个常见现象：符号存在，不代表它会出现在 menuconfig。 HAS_I2C 和 SENSOR_CORE 没有 prompt，它们是内部符号。用户不能直接操作它们，只能让 default、select 等关系计算出值。编辑 .config 强塞一个值也不会把内部符号变成公开开关；下一次解析时，Kconfig 仍按它的定义处理。

menu、comment 和 mainmenu 主要组织界面。source 把另一份 Kconfig 文件读入同一棵配置树。它们不会因为排版漂亮就自动让任何 .c 文件参加编译。

n、m、y 不是 3 个字符串#

Linux 的 tristate 使用三值逻辑：

表达式中的 && 取较小值，|| 取较大值，! 则做 $2-x$：

1
m && y = m
2
m || n = m
3
!m = m

这不是普通布尔代数中随手多塞了一个字母。它让依赖能够表达一个关键约束：内建代码不能依赖只在运行时才加载的模块。例如 FOO=y 且 BAR=m 时，FOO depends on BAR 会把 FOO 的上限压到 m，因此 FOO 不能保持 y。

modules 属性指定哪一个符号负责开启模块状态。Linux 使用它让大量 tristate 真正拥有 m。U-Boot v2026.07 没有 Linux 那样的可加载内核模块体系，也没有定义全局 MODULES 符号。它的树中仍能看到一些 tristate 声明，但日常板级裁剪应把 U-Boot 配置理解为主要在 n/y 之间选择，不要看到 tristate 就期待生成 .ko。

depends on 是上限，不是自动开关#

假设：

1
config SENSOR
2
  tristate "Temperature sensor"
3
  depends on HAS_I2C

当 HAS_I2C=n 时，SENSOR 的最大值是 n，界面也会把它隐藏或禁用。当 HAS_I2C=y 时，Kconfig 只是允许 SENSOR 取 n、m 或 y，并不会替用户启用它。

所以 depends on 的读法不是：

选择 SENSOR 时，顺便打开 HAS_I2C。

而是：

只有 HAS_I2C 足够可用时，SENSOR 才允许达到相应状态。

菜单也会传递依赖：

1
menu "I2C drivers"
2
  depends on HAS_I2C
3

4
config SENSOR_A
5
  tristate "Sensor A"
6

7
config SENSOR_B
8
  tristate "Sensor B"
9

10
endmenu

这里 SENSOR_A 和 SENSOR_B 都继承 HAS_I2C 依赖。if ... endif 也会把表达式附加到内部条目。它们不只是界面折叠工具。

default 只在用户没有决定时说话#

Kconfig 允许一个符号出现多个 default：

1
config BUFFER_SIZE
2
  int "Buffer size"
3
  default 4096 if ARCH_64BIT
4
  default 1024

如果多个默认值的条件都成立，源码中第一个可见的默认值生效。但默认值只在用户没有提供值时使用。用户已经通过配置界面或已有 .config 选过 2048，default 4096 不会每次构建都把它夺回来。

这也解释了为什么新增配置通常保持 default n。旧配置升级到新源码时，make olddefconfig 会替新符号采用默认值；如果每个新驱动都 default y，一次版本升级就会把内核悄悄养胖。Linux 文档只为保留旧行为、纯粹打开下级菜单的 gatekeeper，以及少数用户普遍预期的基础设施等情况建议 default y。

select 很方便，也很锋利#

实验中的 APP 写成：

1
config APP
2
  bool "Sensor application"
3
  select SENSOR_CORE
4

5
config SENSOR_CORE
6
  bool
7
  depends on HAS_I2C

我又准备了一份故意不合法的输入：

1
# CONFIG_SOC_ALPHA is not set
2
CONFIG_APP=y

此时 HAS_I2C=n。我把它交给同一个 Linux 6.18 conf，得到：

1
WARNING: unmet direct dependencies detected for SENSOR_CORE
2
  Depends on [n]: HAS_I2C [=n]
3
  Selected by [y]:
4
  - APP [=y]

select 强制抬高目标符号的值，不会沿着目标符号的 depends on 继续解决依赖。于是 APP 可以把 SENSOR_CORE 推到 y，同时留下 HAS_I2C=n 这个自相矛盾的组合。

这不是求解器忘了帮忙，而是 select 的定义。Linux 文档明确建议谨慎使用它，最好只选择没有 prompt、也没有依赖的内部符号。若用户应该理解并控制前置条件，使用 depends on；若只是希望另一个功能通常随当前功能开启，但仍允许用户关闭，考虑 imply。

一个无聊但安全的重构通常是把能力和实现拆开：

1
config HAVE_SENSOR_CORE
2
  bool
3

4
config SENSOR_CORE
5
  bool "Sensor core"
6
  depends on HAVE_SENSOR_CORE && HAS_I2C

平台可以 select HAVE_SENSOR_CORE，却不绕过 SENSOR_CORE 自己的运行条件。多写一个内部符号，比得到一份能通过配置但不能链接的组合便宜得多。

defconfig、.config 到底谁是谁？#

这是我以前最容易混淆的部分。

1
arch/<arch>/configs/<name>_defconfig

1
configs/<board>_defconfig

1
make O=/tmp/uboot-out sandbox_defconfig

1
# CONFIG_SENSOR_DEBUG is not set

1
make savedefconfig

1
make my_board_defconfig
2
make menuconfig
3
make savedefconfig
4
cp defconfig configs/my_board_defconfig

一次配置命令实际经过什么？#

以 U-Boot 为例：

1
make O=build my_board_defconfig

可以拆成下面几步：

1. 顶层 Makefile 识别 <board>_defconfig 配置目标。
2. 构建主机程序 scripts/kconfig/conf。这里用的是主机编译器 HOSTCC，不是给目标板生成代码的交叉编译器。
3. conf 从根 Kconfig 开始，递归解析 source 引入的文件，建立符号、菜单和依赖图。
4. conf 读取 configs/my_board_defconfig 作为输入，补齐默认值并施加约束。
5. 完整结果写入 build/.config。
6. 后续同步生成 Makefile 和 C 代码需要的配置文件。

menuconfig、nconfig、xconfig 和 gconfig 共享同一套解析与求值核心，只是前端不同：

menuconfig 并不拥有特殊的求值能力。它只是让人类更容易编辑同一张配置图。自动化构建通常更偏爱 olddefconfig，因为 CI 不太擅长在蓝色菜单里按空格键（至少目前如此）。

配置怎样进入 Makefile？#

同步配置后，Linux 和 U-Boot 都会生成：

1
include/config/auto.conf

内容类似：

1
CONFIG_HAS_I2C=y
2
CONFIG_LOG_LEVEL=3
3
CONFIG_SENSOR=y

顶层构建系统把它当作 Makefile 片段包含进来。子目录 Makefile 就可以写：

1
obj-$(CONFIG_SENSOR) += sensor.o

展开过程非常直接：

• CONFIG_SENSOR=y 得到 obj-y += sensor.o，对象内建。
• CONFIG_SENSOR=m 得到 obj-m += sensor.o，Linux 把对象送入模块构建路径。
• CONFIG_SENSOR 未定义时得到 obj- += sensor.o，正常的 obj-y / obj-m 收集逻辑不会选择它。

目录也能用同样方式裁剪：

1
obj-$(CONFIG_HAS_I2C) += i2c/

所以关闭一个驱动最彻底的效果不是给整份 C 文件套上 #if 0，而是让它根本不进入编译输入。编译器少工作，链接器也不必期待稍后用 section garbage collection 擦屁股。

U-Boot 还要处理 SPL、TPL、VPL 等不同阶段，因此源码中常见：

1
obj-$(CONFIG_$(PHASE_)ADC) += adc-uclass.o

PHASE_ 会让构建阶段选择 CONFIG_ADC、CONFIG_SPL_ADC、CONFIG_TPL_ADC 等对应符号。裁剪 U-Boot 时必须问清楚一个功能属于完整 U-Boot 还是早期阶段；只关 CONFIG_FOO，不代表 CONFIG_SPL_FOO 自动消失。

1
build := -f $(srctree)/scripts/Makefile.build obj

1
$(Q)$(MAKE) $(build)=drivers/i2c

1
make -f scripts/Makefile.build obj=drivers/i2c

配置怎样进入 C 代码？#

另一份关键生成物是：

1
include/generated/autoconf.h

我的实验配置生成了：

1
#define CONFIG_LOG_LEVEL 3
2
#define CONFIG_HAS_I2C 1
3
#define CONFIG_APP 1
4
#define CONFIG_MODULES 1
5
#define CONFIG_SOC_ALPHA 1
6
#define CONFIG_SENSOR_CORE 1
7
#define CONFIG_SENSOR 1

C 代码因此可以做更细粒度的选择：

1
#if IS_ENABLED(CONFIG_SENSOR)
2
register_sensor();
3
#endif

Linux 中优先使用项目提供的 IS_ENABLED()、IS_BUILTIN()、IS_MODULE() 等宏，而不是把所有判断都写成裸 #ifdef。原因之一是模块状态：CONFIG_SENSOR=m 通常表现为 CONFIG_SENSOR_MODULE=1，并不等同于 #define CONFIG_SENSOR 1。IS_ENABLED(CONFIG_SENSOR) 能同时覆盖内建和模块两种启用状态。

对于数值和字符串，生成结果保留相应值：

1
#define CONFIG_LOG_LEVEL 3
2
#define CONFIG_LOCALVERSION "-lab"

Linux 6.18 已把 syncconfig 标为内部实现细节。正常用户运行 make 或配置目标即可，顶层 Makefile 会在 .config 或 Kconfig 输入变化时更新这些生成物。手工调用 make syncconfig 通常是在绕过正确入口。

U-Boot 为什么看起来还多一层？#

U-Boot 从 v2014.10-rc1 开始用 Kconfig 替代旧的板级配置体系，但 v2026.07 仍保留一些兼容生成步骤。除了与 Linux 相同的 .config、include/config/auto.conf 和 include/generated/autoconf.h，它还可能生成或使用：

1
include/config.h
2
include/autoconf.mk
3
spl/include/autoconf.mk
4
tpl/include/autoconf.mk

板级代码中也仍能看到 include/configs/<board>.h。因此在 U-Boot 中遇到一个 CONFIG_ 或 CFG_ 宏时，不能只在 Kconfig 文件里搜索一次就宣布它不存在。要区分：

• Kconfig 管理并生成的 CONFIG_*。
• 旧板级头文件或其他构建步骤提供的兼容配置。
• CFG_* 这类不一定由 Kconfig 管理的编译期常量。
• Device Tree 描述的硬件实例与运行时数据。

新配置应优先进入 Kconfig，而不是继续往板级头文件塞宏。旧路径存在是迁移历史，不是新代码需要复制的设计模式。

裁剪一个真实功能时，我现在怎么做？#

假设我要在 U-Boot 中去掉某个以太网驱动，或者在 Linux 中加入某个 I2C 控制器。我会沿着同一条链倒着走。

1
Symbol: FOO [=n]
2
Depends on: BAR [=n] && ARCH_BAZ [=y]

1
obj-$(CONFIG_FOO) += foo.o

1
make O=build my_board_defconfig
2
make O=build menuconfig
3
make O=build savedefconfig

1
make O=build ARCH=arm64 my_defconfig
2
make O=build ARCH=arm64 menuconfig
3
make O=build ARCH=arm64 savedefconfig

1
scripts/diffconfig old.config new.config

1
make listnewconfig
2
make olddefconfig

几个容易制造幽灵问题的操作#

1
config FOO
2
  bool "Foo support"

我最终保留的心智模型#

我现在把 Kconfig 看成一个有 4 类边的符号图：

• depends on 压低取值上限。
• select 强制抬高取值下限，但不替目标检查依赖。
• imply 提供可被用户拒绝的弱下限。
• default 只在用户没有作出决定时给出起点。

defconfig 是送进图中的稀疏输入，.config 是当前版本求解后的工作状态，auto.conf 和 autoconf.h 是分别交给 Make 与 C 的机器接口。随后 obj-$(CONFIG_FOO) 决定文件是否进场，IS_ENABLED(CONFIG_FOO) 决定文件内部哪段代码存活。

这套设计从 1881 份 Linux Kconfig 文件扩展到 U-Boot 的 1098 份，靠的不是某个神奇菜单，而是把配置声明、求值、构建选择和源码条件分开。未来我怀疑更多固件会把硬件描述继续推向 Device Tree，把编译期能力留给 Kconfig；但只要我们仍要为固定板卡在镜像尺寸、启动链和驱动集合之间做取舍，这张符号图就不会消失。

接下来最好的练习不是继续读语法表。选自己板子的一个驱动，从它的 config FOO 追到 obj-$(CONFIG_FOO)，再追到 autoconf.h 和最终镜像。追完一个真实符号，蓝色菜单就只是 UI 了。很好，我终于可以回去裁内核，而不是在 menuconfig 里用空格键进行嵌入式占卜。

参考资料#

• Linux 6.18 Kconfig Language
• Linux 6.18 Configuration targets and editors
• Linux 6.18 scripts/kconfig/Makefile
• Linux 6.18 scripts/Makefile.build
• Linux 6.18 Linux Kernel Makefiles
• Linux Kernel active releases
• U-Boot v2026.07: Kconfig in U-Boot
• U-Boot v2026.07: Building with GCC