1. 先把 defconfig、.config、Kconfig 这三者的关系理清刚接触 linux kernel 编译的人大概都遇到过这样的场景在源码根目录敲下make menuconfig改了几个选项保存退出然后make -j$(nproc)开始编译结果发现改的东西根本没生效或者从同事那拷来一个.config编译直接报一堆 unmet dependency又或者手里拿到一块新板子BSP 包里给了个xxx_defconfig却不知道它和根目录那个.config到底是什么关系。这类问题几乎每个做嵌入式 linux 的人都会踩一遍而且踩完之后如果没人给你把概念捋顺下次换个平台还会再踩。这篇文章就专门讲清楚 linux kernel 里 defconfig 和 .config 这两个东西它们分别是什么、谁生成谁、改动哪个才是正确的、在厂商 BSP比如高通 CAF 内核那种带 vendor 目录的包里又有什么变化。适合两类人看一类是刚开始做内核移植、驱动开发的工程师一类是需要在 CI 里脚本化控制内核配置的构建同学。看完之后你至少能做到两件事一是遇到“配置改了不生效”能自己定位二是能把一套配置干净地维护进 git 仓库。1.1 三个文件三个完全不同的角色很多人把 defconfig 和 .config 当成同一类东西这是所有混乱的根源。它们其实是配置体系里两个不同阶段的产物职责完全不同。Kconfig是“元数据”它是散落在源码树里几百上千个文件比如drivers/net/Kconfig、arch/arm64/Kconfig、init/Kconfig。它定义的是“有哪些配置项可选、这些选项的类型是什么、选项之间有什么依赖、默认值是多少”。注意Kconfig 本身不包含任何具体的选择结果它只是一张不断被 source 拼接起来的巨大表单定义。defconfig是一份“预设答案”但它是一份极简的答案。它放在arch/架构/configs/目录下只记录那些与架构默认值不同的选项。比如arch/arm64/configs/defconfig、arch/arm/configs/multi_v7_defconfig。它存在的意义是给某个平台或某个产品一套可复现的起点。.config是“最终生效的答案”位于源码树根目录或者你指定的输出目录O是make在构建时真正读取的文件。里面会列出成千上万行CONFIG_XXXy、CONFIG_YYYm或者# CONFIG_ZZZ is not set它是 Kconfig 表单一遍遍求解之后落地的结果也是编译器和 Makefile 真正去 grep 的东西。一句话概括这个链条Kconfig 提供题库defconfig 提供一部分标准答案两者经过一次求解得到完整的 .config。1.2 为什么内核一定要拆成两层如果只有 defconfig 一层理论上也能跑通——事实上很多小型项目就是直接把配置文件拷贝成.config用。内核之所以坚持两层背后有三个很现实的原因。第一是体积与可读性。一个开了图形、网络、存储、各种驱动的 arm64 配置完整.config动辄六七千行其中大量是# CONFIG_XXX is not set。如果把这份完整文件作为官方 defconfig 放进 git每次内核升级Kconfig 新增数百个选项都要制造巨大的 diffreview 时根本看不出到底是哪条真正的改动。精简后的 defconfig 通常只有几百行甚至一两百行改了什么一目了然。第二是默认值的演进。内核社区会不断调整各个 Kconfig 项的default。如果用完整.config那么上游把某个选项的默认值从 n 改成 y你的配置里那个# CONFIG_XXX is not set会僵在那里永远跟不上下游的合理默认。而精简 defconfig 只写“我要偏离默认的地方”剩下的交给上游演进这对长期维护一个平台至关重要。第三是可参数化。内核提供了make olddefconfig、make oldconfig、make savedefconfig一整套工具允许你在拿到一份旧配置后用新 Kconfig 的默认值自动补全。这是完整.config做不到的语义——你无法区分某一行是“当年显式选的”还是“当年默认值就是这样”。1.3 defconfig 放哪儿、叫什么名字是有讲究的内核并不要求 defconfig 一定叫defconfig它的命名规则由Makefile里的目标推导决定。当你在根目录敲make foo_defconfig时Kbuild 会去找arch/$(SRCARCH)/configs/foo_defconfig而make defconfig这个没有前缀的形式走的是另一条路——它读取arch/$(SRCARCH)/Makefile里定义的KBUILD_DEFCONFIG变量默认一般就是defconfig。# ARM64最常见的用法 make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- defconfig # 指定某个具体平台的配置 make ARCHarm defconfig # 实际用 arch/arm/configs/defconfig如果存在 make ARCHarm multi_v7_defconfig make ARCHarm64 myboard_defconfig # 内核里的查找逻辑简化 # arch/${SRCARCH}/configs/${target%_defconfig}这里有个容易忽略的细节SRCARCH和ARCH不一定相同。在 x86 上ARCHi386和ARCHx86_64最终都会把SRCARCH归到x86所以你在arch/x86/configs/下只会看到i386_defconfig、x86_64_defconfig这样的文件而不会看到两个架构目录。做移植时如果搞错了SRCARCH就会得到“找不到 defconfig 文件”的报错。另外要强调一点只改arch/xxx/configs/yyy_defconfig不改.config是不会影响当前编译的。因为构建系统根本不读 defconfig它只读.config。必须重新执行make yyy_defconfig或者手动同步新配置才会落到.config里。这个“改动源头和生效对象分离”的特性是后面所有坑的技术根源。2. 从 defconfig 到 autoconf.h配置到底是怎么被“编译”出来的理解了概念接下来要看机制。内核配置系统其实是两个 C 程序的组合scripts/kconfig/conf负责解析和求解scripts/kconfig/mconfmenuconfig 用的那个负责交互界面。整个流程可以简化成“Kconfig 树 输入配置 → 求解 → 输出配置”这个求解过程发生在每次执行make xxx_defconfig、make menuconfig、make oldconfig的时候。搞明白这一步你就能理解为什么改.config里的某些行会被“自动改回去”以及为什么有些选项在你手动改完之后又消失了。2.1make xxx_defconfig背后真正跑的命令打开内核顶层Makefile搜索%config附近的规则你会看到类似这样的东西不同版本略有差异%config: outputmakefile scripts_basic FORCE $(Q)$(MAKE) $(build)scripts/kconfig $ # scripts/kconfig/Makefile 里 %_defconfig: $(obj)/conf $(Q)$ $(silent) --defconfigarch/$(SRCARCH)/configs/$ $(Kconfig)也就是说make myboard_defconfig本质上执行的是scripts/kconfig/conf --defconfigarch/arm64/configs/myboard_defconfig Kconfigconf这个程序做了什么它从根Kconfig文件开始递归source所有子 Kconfig构建出一棵完整的选项树然后读取--defconfig指定的文件作为“初始值”对所有选项求解一遍依赖关系最终把结果写到.config。注意这里是“求解”而不是“复制”。如果你的 defconfig 里写了CONFIG_FOOy但FOO依赖的BAR在新版内核里已经不存在了那么这一行就会被静默丢弃同时命令行通常会打印一句warning: unexpected data或者干脆什么都不说。实测中更常见的现象是选项被保留但依赖没有满足。比如 defconfig 里写了CONFIG_USB_GADGETy而USB_GADGET依赖USB_SUPPORT如果USB_SUPPORT没有在 defconfig 里指定、其默认值又是 n那么结果就是.config里出现CONFIG_USB_GADGETy但相关的依赖链是断的。此时编译可能会出现奇怪的链接错误而不是配置阶段的报错。所以每次换内核版本第一件事就是重新跑一遍 defconfig 并检查 warning。2.2 Kconfig 的依赖求解为什么选项会“自己消失”在menuconfig里如果你找不到某个明明存在的选项八成是依赖没满足。Kconfig 的显示逻辑是一个选项只有在它的所有depends on条件都满足时才会出现在菜单里。这跟select的行为正好相反。举个我实际踩过的例子想做 USB 串口驱动调试把CONFIG_USB_SERIALy写进 defconfig结果menuconfig里根本找不到这一项。原因是USB_SERIAL在源码里写作config USB_SERIAL tristate USB Serial Converter support depends on USB TTY ...TTY如果没有在配置里打开通常是默认打开的但某些裁剪过的配置会关掉USB_SERIAL就会彻底从菜单里消失。这时候你的 defconfig 里那行CONFIG_USB_SERIALy会被conf解析但因为直接依赖不满足它不会写进最终.config只会留下一条 warning.config:1234:warning: unexpected data: CONFIG_USB_SERIALydepends on是硬依赖不满足就整项作废而select是反向依赖它的行为是“我打开时顺手把别人打开”。select最坑的地方在于它不检查被选中项自身的依赖。如果A select B而B depends on C你在menuconfig里打开AB会被强制设为 y但C可能还是 n于是编译炸掉。社区对乱用 select 一直是批评态度作为 BSP 的维护者遇到别人提交的 Kconfig 补丁乱加 select是必须拦下来的。还有一类特殊情况是imply它是弱版 select能拉起来就拉拉不起来不报错。这个关键字在近几年的内核里用得越来越多主要就是为了缓解 select 的滥用问题。2.3.config之外还有三个你没注意到的产物很多人以为.config生成完就结束了实际上构建系统还会派生出另外三样东西它们才是真正被编译器和 Makefile 使用的产物路径作用.config源码根目录或O指定目录人对可读的完整配置menuconfig读写它auto.confinclude/config/auto.conf给 Makefile 用只有CONFIG_Xy形式不带注释autoconf.hinclude/generated/autoconf.h给 C 代码用展开成#define CONFIG_X 1tristate.confinclude/config/tristate.conf记录哪些项是m用于模块化构建autoconf.h是你写驱动时最常打交道的因为#ifdef CONFIG_MY_DRIVER这个宏就是它提供的。但注意一个反直觉的点CONFIG_Xm在autoconf.h里对应的是#define CONFIG_X_MODULE 1而CONFIG_X本身不会被定义。这就是为什么驱动里标准写法是#ifdef CONFIG_MY_DRIVER ... #endif // 或者区分内建和模块 #if IS_ENABLED(CONFIG_MY_DRIVER) ... #endifIS_ENABLED()是内核提供的一个巧妙宏它能把y、m、未定义三种情况统一处理比裸#ifdef靠谱得多。我见过不少驱动代码只判断CONFIG_X结果模块化编译时那段代码被整体优化掉运行时行为跟内建完全不同排查了半天才发现是这个原因。另外auto.conf和autoconf.h不是每次都重新生成。Kbuild 会比较.config的时间戳只有发生变化才重新生成。这就引出一个经典坑手动sed改了.config但没触发重新生成。sed只改了文件内容但如果文件的时间戳因为某些原因没有更新比如脚本里先touch了再改Kbuild 可能认为配置没变。稳妥的做法是改完.config之后显式跑一次make olddefconfig让它走一遍完整的求解和派生流程。3. 改配置的四条路分别适合什么场景知道机制之后实际问题就变成“我想加一个选项该怎么改”。这里我按使用频率从前到后列四种方式并且说清楚每种的适用边界。很多人只知道menuconfig但在 CI 或者批量维护几十块板子的场景里交互式操作是不可接受的。3.1 menuconfig 不是万能的但它是发现问题的最好工具make menuconfig依赖ncurses容器里没装的话先装一下# Debian/Ubuntu 系 sudo apt-get install -y libncurses-dev flex bison bc # 交叉编译环境里记得带上 ARCH 和 CROSS_COMPILE make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- menuconfig用menuconfig有几个实操上的小技巧值得记一下按/是搜索输入USB_SERIAL之类的关键字或直接的配置项名。搜索结果里会显示“Depends on:”那一行这是判断依赖是否满足最直接的依据。搜索结果里如果前面带-号比如-*-说明它是被select强制拉起来的你自己取消不了得先去关掉 select 它的那一项。修改完不要急着退出养成Save之后再看一眼顶部的Load an Alternate Configuration File确认自己改的是哪个文件。曾经有人把配置保存到了/tmp然后第二天找不到笑不出来。大屏终端下推荐用make nconfig新版搜索和跳转体验比 menuconfig 好一截有 X11 环境可以试make xconfig但 Qt/GTK 依赖在服务器上通常装不全。但menuconfig最大的问题是不可自动化、不可复现。你在界面上点的每一下都没有记录换个人换台机器就得重来。所以它适合“探索与验证”不适合“固化配置”。3.2 脚本化修改scripts/config与手工 sed 的边界内核自带一个小工具scripts/config专门用来在脚本里修改.configcd linux-6.6 # 设置某个选项为 y ./scripts/config --enable CONFIG_MY_DRIVER # 设置为模块 ./scripts/config --module CONFIG_MY_DRIVER # 显式关闭 ./scripts/config --disable CONFIG_DEBUG_INFO # 设置字符串或数值 ./scripts/config --set-str CONFIG_LOCALVERSION -myboard ./scripts/config --set-val CONFIG_LOG_BUF_SHIFT 18 # 关键改完必须重新求解一遍依赖 make ARCHarm64 olddefconfig这里必须强调那个“关键”注释。scripts/config的行为非常老实它就是去.config里找那一行做文本替换完全不检查 Kconfig 依赖。如果你--enable了一个依赖不满足的选项.config里会出现它但make olddefconfig之后它又会消失——因为olddefconfig是真正的求解过程。olddefconfig和oldconfig的区别也值得说清楚make oldconfig对新出现的、没有在.config里的选项逐个交互式询问。适合人工升级内核版本。make olddefconfig对新选项直接采用 Kconfig 里的默认值不询问。适合脚本和 CI。我个人的习惯是任何自动化的配置修改末尾一律接make olddefconfig然后再用grep CONFIG_MY_DRIVER .config验证一遍。如果验证失败说明依赖链缺东西回头去补。这套组合拳比直接sed靠谱得多因为sed无法处理“不在文件里就追加”的情况也容易误伤同名前缀的选项CONFIG_USBy和CONFIG_USB_GADGETy用sed s/CONFIG_USBy/.../就会出错。3.3savedefconfig把改好的 .config 反推回精简配置这是我认为整个配置体系里最重要、但被使用得最少的一个功能。流程是这样的你在menuconfig里折腾了半天.config现在是完整的你想把它变成一份可以提交进 git 的 defconfigmake ARCHarm64 savedefconfig # 生成一份极简文件defconfig默认在源码根目录 # 也可以指定路径 make ARCHarm64 savedefconfig DEFCONFIGarch/arm64/configs/myboard_defconfig生成的defconfig只包含“与 Kconfig 默认值不同”的项通常能压缩到原来.config的十分之一。然后你把它移动或复制到arch/arm64/configs/myboard_defconfig提交。下次别人拿到源码只需要make myboard_defconfig就能复现出一份等效的.config。这里有个非常容易踩的坑savedefconfig的结果依赖 Kconfig 的当前默认值。比如某个选项在新版内核里默认值从 n 改成了 y你原来显式写的CONFIG_FOOy就会被省掉因为“跟默认一样”看起来行为没变但如果只是你本地误改了 Kconfig比如打补丁时顺手改了 defaultsavedefconfig 的输出就会莫名少一行甚至多一行。所以提交前一定要做一次验证# 用精简配置重新生成 .config跟原配置对比 cp .config /tmp/config.bak make ARCHarm64 myboard_defconfig diff -u /tmp/config.bak .config理想情况下 diff 应该只包含注释行或者完全没有输出。有实质性差异说明你的 defconfig 并没有完整表达你的意图得回头看看是不是漏了依赖项。3.4 配置片段fragment与 merge_config.sh多产品线的利器当你手里有三块板子90% 的配置相同、10% 不同的时候复制三份 defconfig 是灾难性的维护方式——上游一改默认值你要同步改三个文件。更优雅的方式是“基线 片段”# 基线配置 片段配置 ./scripts/kconfig/merge_config.sh -m \ arch/arm64/configs/base_defconfig \ arch/arm64/configs/frag-myboard-a.config \ arch/arm64/configs/frag-camera-ov5640.config # -m 表示只合并不立即生成 autoconf.h # 合并完成后重新求解 make ARCHarm64 olddefconfig # 把结果固化成新的 defconfig make ARCHarm64 savedefconfigmerge_config.sh的处理逻辑是按顺序读取所有输入文件后出现的片段覆盖前面的同名项。这个顺序非常重要——通常把通用基线放前面产品特有配置放后面。片段文件不需要是完整的 defconfig里面可以只写三五行CONFIG_MYBOARD_SENSORy CONFIG_MYBOARD_DEBUGy # CONFIG_MYBOARD_FEATURE_X is not set注意最后一行那种“显式关闭”的写法如果你只是不写它它可能被基线或其他片段的默认值打开显式写# ... is not set才是真正的关闭。切换表示法-开头那套是老的用法现在统一推荐这种注释形式。这套机制在 Android 通用内核GKI时代变成了标配下面一节详细讲。4. 嵌入式与 BSP 场景下配置管理怎么做才不乱上面讲的是通用机制真正落到找工作或者做项目你面对的往往不是 upstream 主线内核而是芯片厂商打包好的 BSP目录结构、命名习惯、甚至构建脚本都被改过。这一节说说这类环境下的实际情况。4.1 厂商内核的配置目录长什么样以高通 CAF 内核这类常见的 BSP 为例配置文件的组织方式和主线有明显区别主线风格arch/arm64/configs/board_defconfig一个平台一个文件。BSP 风格常见arch/arm64/configs/vendor/子目录里面按芯片代号或项目名放置比如vendor/chip_defconfig、vendor/chip-perf_defconfig。GKI 风格同时存在arch/arm64/configs/gki_defconfig通用部分和arch/arm64/configs/vendor/chip_GKI.config这样的 fragment由构建脚本用merge_config.sh或自研脚本合并。这种分层不是厂商没事找事而是被现实逼出来的。一颗 SoC 要出货给几十个手机型号每个型号的屏幕、摄像头、传感器、射频配置都不同如果每个型号一份完整 defconfig光是维护成本就受不了。分层的目标是通用部分跟着芯片平台走差异部分跟着项目走。所以你在 BSP 里做移植第一步不是急着menuconfig而是先把构建脚本找出来搞清楚它到底合并了哪几个文件、顺序是什么。常见的位置包括build.config.*、build_target.sh、kernel/configs/。有些厂商的脚本还会在合并后自动跑一段scripts/config做微调这些都要在日志里确认。4.2 一个内核支持多条产品线时的分层策略如果让你从零设计一套多产品的配置管理我建议按这个思路分四层层级文件示例职责谁负责改芯片基线base_defconfig该 SoC 必需的外设、时钟、电源、总线芯片/BSP 团队平台变体frag-perf.config/frag-lowmem.config性能版与低配版的差异BSP 团队产品差异frag-project.config屏幕、摄像头、传感器型号项目驱动工程师调试开关frag-debug.config只在调试固件里开的功能各人本地不入库关键是每一层只写“与本层相关的、与上一层不同的部分”。判断标准很简单如果某个开关放之四海而皆准它就不该出现在产品层。我见过项目层里塞了几百行通用 USB 配置结果上游一升级几个项目全炸了。另外建议在 CI 里加一道校验每次提交 defconfig 或 fragment 之后自动跑一次合并 olddefconfigsavedefconfig然后 diff 出结果。如果 diff 里有非预期的项直接卡住提交。这个检查能拦下大部分“不小心点了某个菜单导致配置漂移”的问题性价比极高。4.3 配置文件的版本管理和 review 关注点.config不要提交进 git。它包含大量由默认值推导出来的冗余信息而且含有本地路径之类的东西比如CONFIG_LOCALVERSION里可能带上开发机的用户名。提交它只会制造无意义的冲突。应该提交的是defconfig、fragment、以及生成它们的脚本。review 的时候重点看这几类改动新增的CONFIG_Xy有没有对应的驱动代码或硬件支持是不是从别的项目复制过来忘了删。有没有把m改成y。内建和模块对启动时间、内存占用、分区大小的要求完全不同这类改动经常是为了图省事但代价不小。有没有出现CONFIG_DEBUG_*、CONFIG_*_TEST、CONFIG_KASAN之类只在调试期开的开关。这些开着会显著拖慢启动、增大镜像出厂固件里必须关掉。# CONFIG_XXX is not set的显式关闭是否必要。如果只是为了“防止默认值变化”最好在提交信息里写清楚理由否则后人看不懂为什么要专门关一个默认就是关的东西。5. 排查实录配置改了不生效的八种可能前面讲的是“应该怎么做”这一节讲“做错了会怎样”。下面这些现象我都真实遇到过按出现频率排序。5.1 现象与原因速查表现象最可能的原因快速验证方法menuconfig里找不到目标选项依赖未满足选项被隐藏用/搜索看 Depends on 那行.config里有CONFIG_Xy但编译报未定义没跑olddefconfig或依赖断链grep X include/generated/autoconf.h改了arch/arm64/configs/xxx_defconfig没效果没重新执行make xxx_defconfig对比 defconfig 与.config的修改时间手动 sed 改.config后编译行为不变时间戳没更新派生文件未重生成删掉include/config/auto.conf重编配置里开了某个驱动但驱动没编进内核m被当成y用模块没打包进 rootfs看modules.builtin与modules.order换内核版本后编译大量报错defconfig 里的项已在新版被改名或删除重新跑 defconfig看 warning 输出make提示 “syncconfig” 反复出现.config时间戳比auto.conf新反复触发检查是否有脚本在循环改.config用O输出目录时配置莫名其妙在源码根目录跑了 menuconfig实际用的是另一份echo $(pwd)确认 KCONFIG_CONFIG 指向5.2 一套可靠的排查顺序遇到配置类问题我一般按这个顺序走从外到内避免瞎猜确认自己在哪个目录、用的是哪份.config。如果构建时带了O或者环境变量KCONFIG_CONFIG那配置文件的路径就不是默认的那个。# 打印当前生效的配置文件路径 echo $KCONFIG_CONFIG ls -la .config # 或者用 make 自带的打印 make ARCHarm64 -s printkconfig 2/dev/null || true确认.config里的项与预期一致。grep -n CONFIG_MY_DRIVER .config看看是三态中的哪种有没有被注释掉。确认派生文件已经更新。对比.config和include/config/auto.conf的时间戳。前者更新说明需要重新跑make olddefconfig。确认 C 代码里用的是正确的宏。IS_ENABLED(CONFIG_X)与#ifdef CONFIG_X在m场景下行为不同这是代码层面的问题不是配置层面的。确认最终产物里真的包含驱动。strings vmlinux | grep my_driver_init或者看System.map里有没有对应符号这一步能排除“配置对了但没链接进去”的情况。这套顺序的价值在于它是单调收敛的——每一步都能排除掉一大类可能不会来回打转。5.3 几条踩出来的经验任何对配置的批量修改结尾都必须跟一次make olddefconfig并且用grep验证结果。没有验证的修改等于没改。关于CONFIG_LOCALVERSION有个小技巧值得分享。它会拼到uname -r的末尾是区分不同产品固件最直接的标记。但注意它必须带引号写且开头一般是短横线./scripts/config --set-str CONFIG_LOCALVERSION -myboard-v1.2 # 结果uname -r 显示 6.6.0-myboard-v1.2另外还有CONFIG_LOCALVERSION_AUTO它会自动把 git 的 commit id 拼进去。这个开关在开发期很有用能一眼看出固件是从哪个提交编的但出厂固件务必关掉否则每次提交都会让版本号变化OTA 升级判断包版本时容易出问题。关于IKCONFIG如果你的固件里CONFIG_IKCONFIG_PROCy打开了运行时可以通过/proc/config.gz拿到当前内核的完整配置。这在现场排查问题时价值巨大——客户报告某个功能不可用你第一件事就是zcat /proc/config.gz | grep XXX确认出厂固件里到底开没开。我建议所有产品固件都把这个开关打开多出来的几十 KB 换来的可诊断性是值得的。但要注意如果内核没开IKCONFIG_PROC而是打开了CONFIG_IKCONFIG那配置信息会内嵌在vmlinux里需要用scripts/extract-ikconfig vmlinux手动提取。最后说一个很多人问过的问题为什么make savedefconfig生成的文件那么短是不是丢东西了不一定。它只是把跟默认值相同的部分省掉了。判断有没有丢东西的标准不是行数而是“重新按它生成一遍.config再跟你原来的.config做 diff 有没有实质差异”。这个验证做一遍心里就踏实了。我在第一次维护 BSP 的时候因为没做这步把一个依赖项漏在了本地.config里结果编译机上直接失败返工花了大半天。从那以后无论多急这一步我都不省。