接手一份别人的内核源码第一件事往往不是看代码而是看配置。我遇到过太多次这样的场面甲方扔过来一个 tar 包里面躺着一份.config硬件工程师手里又有一份xxx_defconfig两边各自编译出来的镜像能差出好几兆启动日志里的驱动加载顺序都不一样。更离谱的是有人直接问哪个文件才是真正的配置因为他在源码根目录改了半天.configmake之后发现改动全没了。这些问题的根子都在于没搞清楚.config和defconfig这两个东西在构建链条里各自扮演什么角色。这篇就把 Kconfig、.config、defconfig三者的关系、常用 make 目标的实际行为、内核裁剪的落地方法和版本升级时容易翻车的细节一次性讲透适合刚接触内核编译的嵌入式开发者也适合已经在维护 BSP 但想把配置管理做规范的人。1. 从一个同一个源码包、两份镜像的现场说起1.1 构建系统找不到.config时到底在抱怨什么最典型的报错长这样*** Configuration file .config not found!紧接着一句*** Please run some configurator (e.g. make oldconfig or make menuconfig or make xconfig).。这不是链接错误也不是编译错误而是构建系统在进入真正的编译阶段之前发现自己缺了一份输入契约。内核的 Makefile 在展开obj-$(CONFIG_XXX)这类语句时依赖include/config/auto.conf提供符号取值而auto.conf是从.config生成的。没有.config整条依赖链在前几步就断了。这里有个新手经常踩的坑.config的位置跟构建目录绑定而不是跟源码目录绑定。只要你用了make Oout这种外部构建方式那份.config就躺在out/目录里源码根目录是找不到的。我在一个项目里见过同事反复ls -a源码根目录说文件明明在啊最后发现他是在另一台机器上跑的外部构建。所以排查这类配置改了不生效的问题第一步永远是确认当前命令实际使用的 objtree 在哪而不是盯着源码目录看。提示不确定当前构建用的是哪份.config可以加V1让 Makefile 把实际执行的 kconfig 命令打出来命令行里--defconfig或KCONFIG_CONFIG的参数会暴露真实路径。1.2 一份是这一次的完整快照一份是这一类板子的推荐起点把.config理解成一次点餐的完整订单每道菜要不要、辣度多少、加不加香菜全部逐条写清楚任何人照着这份订单去做出来的东西跟你想的一样。它本质上是一次构建的全部输入包含了几千行取值绝大多数是各符号的默认值被显式展开的结果。defconfig则是另一回事。它放在arch/$ARCH/configs/下面是一份经过精简的初始化模板只把那些与默认值不同的项钉下来。用点餐类比它更像贴在店门口的推荐点法只写辣度三颗星、不要香菜其余按店里标准来。同一家店换个时间营业标准菜可能变了但这个模板照样能用因为它没把所有细节都写死。理解了这个差别很多现象就顺了为什么defconfig只有几百行而make defconfig跑完之后生成的.config有几千行为什么升级内核版本之后.config的 diff 有上万行而defconfig的 diff 通常只有几十行。1.3 只保留其中一份会出什么问题有人图省事只留.config进版本库。短期没问题长期是灾难跨版本升级时 diff 里混着大量某个符号的默认值从 y 变成 n这类噪声评审的人根本看不清你真正改了什么而且不同开发者机器上的默认值可能因为 ARCH、工具链配置不同而分叉同一份.config在不同环境下编译结果并不完全一致。反过来只留defconfig也不行。生产环境要复现某次发布的镜像必须能拿到当时那份完整的配置快照。defconfig展开时依赖当时的 Kconfig 默认值而默认值会随版本变动所以用同一个 defconfig 在两个版本上编译出完全一样的二进制是不成立的。我的做法是仓库里只提交defconfig及其 fragment同时每次正式发布时把展开后的.config归档到发布包旁边两者缺一不可。2. Kconfig 才是源头另两份都只是它的产物2.1 Kconfig 里几个真正影响结果的写法很多人把 Kconfig 当成纯文档其实它是带执行语义的。几类写法必须熟bool/tristate/int/string/hex决定符号类型tristate多了m编译成模块这一档。default决定没被显式指定时取什么值可以有条件表达式也可以依赖其他符号。depends on是可见性与取值的前提依赖不满足时符号可能直接不进候选菜单。select是强制点亮它会绕过对方的depends on这是很多我明明把依赖关掉了这个项还是被打开现象的根源。menuconfig与menu主要影响菜单层级choice是一组互斥选项source用来把子目录的 Kconfig 拉进来。select这个点值得多说一句。它对人友好对排错不友好。当 Aselect B而 B 又有自己的依赖时配置系统会强行把 B 设为 y但 B 的依赖可能没满足于是要么编译报错要么运行期行为诡异。排查这类问题最快的方式是去drivers/或fs/下 grep 一下select 符号名看看到底是谁在替你做决定。2.2.config的书写规则这一行不存在和写着 not set不是一回事.config里符号有三种表达CONFIG_FOOy或CONFIG_FOOm内置或模块。# CONFIG_FOO is not set显式取 n。完全没有CONFIG_FOO这一行不表态让默认值说话或者是依赖不满足导致该符号压根没进入候选集。第三种情况是手工改配置时最大的陷阱。我见过太多人在.config末尾追加一行CONFIG_XXXy就以为搞定了跑一遍make olddefconfig之后那行被悄悄抹掉因为他没注意到CONFIG_XXX依赖的某个总线或子系统是 n。手动加配置项一定要改完立刻make olddefconfig再diff一次看你的改动是留下了还是被回滚了这个动作五秒钟能省掉半天排错。提示判断一个符号为什么打不开最直接的办法是make menuconfig里按/搜索符号名界面会把这个符号的依赖链和被谁 select完整列出来。2.3 从.config到代码autoconf.h与auto.conf.config本身不参与编译。构建系统会把它转成两个中间产物include/generated/autoconf.h给 C 代码用的宏定义#define CONFIG_FOO 1这种形式。include/config/auto.conf给 Kbuild 用的变量obj-$(CONFIG_FOO) foo.o里的$(CONFIG_FOO)就是从这儿来的。这两个文件的位置同样在 objtree 里。排代码里的#ifdef CONFIG_FOO明明配置打开了却不生效这类问题时直接去看autoconf.h里有没有那个宏比猜快得多。另外不少内核还带include/config/下的空目录结构那是给 Makefile 做依赖追踪用的不用手动碰。2.4 常用 make 目标对照表配置相关的目标多且容易混我把实际用得到的整理成一张表方便对照目标作用实际使用场景make menuconfig文本菜单界面日常最常用服务器环境也稳make nconfig新版文本界面支持更顺手的搜索远程终端上体验更好make xconfig图形界面依赖 Qt本地有桌面环境时比较直观make defconfig按架构默认配置展开x86 上一般走arch/x86/configs下约定的那份make xxx_defconfig找arch/$ARCH/configs/xxx_defconfig板级配置的标准入口make oldconfig只交互询问新增/变化的符号版本升级后第一次配置make olddefconfig新符号一律取默认值不交互手工改完.config后的收尾make savedefconfig生成精简版defconfig配置定稿后收敛make allnoconfig/allyesconfig/allmodconfig全关/全开/全模块覆盖率测试、编译问题复现make tinyconfig生成体积极小的配置只作为裁剪起点不能直接当产品配置make localmodconfig依据当前系统已加载模块生成配置开发机自用不适合出货make listnewconfig/helpnewconfig列出新增配置项大版本升级时快速过一遍make mrproper清理包括.config在内的所有生成物要小心配置会被删掉3. 生成和修改.config的几条路子以及各自的适用边界3.1 图形界面的三条路menuconfig、nconfig、xconfigmenuconfig依赖 ncurses在干净的容器里经常报找不到 curses.h装包即可Debian 系是libncurses-devRHEL 系是ncurses-devel。xconfig依赖 Qt 开发库装起来比 ncurses 重得多除非你确实需要鼠标操作和树状视图否则不值得为一个配置界面在服务器上装一堆图形库。我个人在远程环境下更愿意用nconfig它的搜索和高亮比老版 menuconfig 舒服尤其是符号名记不全、要靠关键词捞的时候。不管用哪个界面核心技巧是搜索键。想确认一个功能到底叫什么符号、藏在哪个菜单、依赖什么直接搜比一层层翻菜单快十倍。搜出来的结果里Depends on:和Selected by:两行信息量最大前者告诉你为什么它不可选后者告诉你谁在偷偷把它打开。3.2 不开图形界面的做法oldconfig、olddefconfig 和 scripts/config批量、可脚本化的场景图形界面反而是累赘。内核自带scripts/config工具可以在不改写整个文件的前提下按符号名增删改# 关闭模块签名校验打开运行时配置读取能力 scripts/config --file .config --disable MODULE_SIG scripts/config --file .config --enable IKCONFIG scripts/config --file .config --enable IKCONFIG_PROC # 修改数值型符号 scripts/config --file .config --set-val FOO_BUFFER_SIZE 4096 # 必须收尾否则依赖关系没被重新求解 make ARCHarm64 olddefconfig注意scripts/config传入的是不带CONFIG_前缀的符号名它自己会拼上去。这条路子最大的价值在于可复现把一系列配置修改写成脚本进仓库比让每个同事手动点菜单可靠得多也方便 CI 里自动产出多种变体配置。make oldconfig的用法就一个在版本跨得比较大时把新增符号一个一个问过去。虽然烦但安全相关的默认值经常就在这些新符号里无脑olddefconfig会错过。3.3 手工编辑.config的真实风险直接改文本并非不行我在处理只差一两项的时候也会这么干但必须清楚三个后果。第一依赖不满足的改动会被静默抹掉前面已经讲过。第二类型写错会报警告但不会阻止构建比如把int型符号写成字符串配置系统会给一条 warning然后取默认值你可能根本没注意。第三改完不跑olddefconfig直接编译构建系统会自己同步同步过程中如果有新符号需要回答它会打印一句提示让你回去跑make oldconfig此时你的编译其实用的是一份还没定稿的配置。经验做法是手改只改取值不改结构改完立刻make olddefconfig然后git diff .config看一眼净变化。三步走下来基本不会出现我改了但没生效的诡异情况。3.4localmodconfig的用途和它的边界make localmodconfig会读当前系统的已加载模块把不需要的驱动关掉生成一份贴着这台机器的配置。思路很聪明我用它给开发机做过一次大幅瘦身编译时间从四十多分钟降到十几分钟。但它的边界也很清楚它只认当前这一刻在场的硬件。如果目标板上有 USB 网卡、第二块存储控制器、串口扩展这类平时不挂载的设备它们的驱动会被一刀切掉换台机器或者换个使用场景就起不来。所以它适合我自己这台开发机自用绝不适合产品出货配置。用完之后照样要savedefconfig收敛、人工审查一遍被关掉的项。4.defconfig的正确制作方式savedefconfig而不是复制粘贴4.1 为什么直接把.config改名叫defconfig是个坏习惯这是最常见的错误做法看起来能跑通——make defconfig确实会读你把.config改名来的文件——但代价很大。文件会膨胀到几千行里面绝大部分是默认值被显式写出来以及一堆# CONFIG_XXX is not set。跨版本升级时别人的默认值改了你这几千行里就有几百行变成噪声真正的改动被淹没。更麻烦的是某些符号的默认值会跟随机器环境变化比如跟 CPU 特性或工具链能力挂钩你把当前机器的展开结果硬编码进去等于把一份环境相关的东西伪装成板级配置。评审的时候没人愿意读这种 diff。4.2savedefconfig到底省掉了什么它的逻辑很朴素只保留与当前默认值不同的项。默认值由当前的 Kconfig 定义和ARCH共同决定所以同一个配置在不同架构上收敛出来的defconfig是不一样的。make ARCHarm64 menuconfig # 正常配置、裁剪 make ARCHarm64 savedefconfig # 在构建目录生成精简后的 defconfig cp defconfig arch/arm64/configs/myboard_defconfig产物默认写在构建目录用了O就在输出目录里文件名就叫defconfig需要你手动拷贝到arch/$ARCH/configs/下并按规范改名。收敛完的典型体量是几百行评审时一眼能看完。提示savedefconfig的省是有前提的它省掉的是和当前默认值相同的项。所以内核大版本升级后旧的.config展开再收敛结果会跟以前不一样这是正常的不是工具出了问题。4.3 命名、路径与make xxx_defconfig的查找规则make myboard_defconfig会去arch/$ARCH/configs/myboard_defconfig找文件文件名必须以_defconfig结尾这是 pattern rule 的匹配要求命名成myboard.config是找不到的。而make defconfig走的是另一条路径通常由arch/$ARCH/Makefile里的KBUILD_DEFCONFIG变量指定x86 上一般对应x86_64_defconfig一类可以尝试用命令行覆盖但更稳妥的做法还是显式写make myboard_defconfig。这里必须重点提醒ARCH的问题。make在不指定ARCH时默认按宿主机架构展开在一台 x86 服务器上给 ARM 板子做配置却忘了加ARCHarm64你会得到一份看起来很正常、实际上全是 x86 选项的配置然后编译时各种诡异的头文件找不到。我养成的习惯是所有配置命令前面一律带ARCH和CROSS_COMPILE宁可冗余也不省。4.4 多产品线场景下的 fragment 合并一个产品线往往有多个硬件变体摄像头、实时补丁、调试开关各不相同如果每个变体都维护一份完整的defconfig重复内容占八成改一处基础项要同步改五份。这时候用配置片段fragment更合理内核源码里就带了一个合并脚本。# 基础配置 若干增量片段后出现的覆盖先出现的 ARCHarm64 scripts/kconfig/merge_config.sh -m \ arch/arm64/configs/base_defconfig \ frag/camera.config frag/rt.config make ARCHarm64 olddefconfig-m表示只做合并、不自动跑一遍默认值求解所以合并完必须自己make olddefconfig把依赖重新解一遍最后再savedefconfig收敛出这个变体最终要提交的文件。目录上我一般这样组织arch/$ARCH/configs/下只放收敛后的成品frag/下放片段每个片段文件里用注释写清为哪个硬件/哪个功能准备半年后回头看也不会懵。提示片段文件里不要写is not set形式的关闭项除非你确实需要在合并时强制覆盖别人打开的值。只写需要打开的项合并结果更可预测。5. 内核裁剪从配置项出发把镜像和启动时间压下去5.1 先量化再动手裁剪最大的忌讳是一上来就关选项。我一般先做三件事size vmlinux看各段text/data/bss占比在 objtree 里按体积排序看哪些目录贡献最大用scripts/bloat-o-meter对比裁剪前后的符号级变化。启动时间方面给内核命令行加initcall_debug从 dmesg 里能看到每个初始化函数的耗时比拍脑袋关驱动靠谱得多。顺序上CONFIG_DEBUG_INFO通常是第一个该关的。它不改变功能只是给二进制塞调试信息关掉之后 vmlinux 体积经常能小掉一半以上。开发调试阶段留着出货配置里一定要去掉。同理DEBUG_KERNEL下面挂着的一堆运行时检查项各种内存/锁检测工具、函数追踪也会带来可观的开销出货时按需保留最少的一两个。5.2select和依赖导致的删不掉以及正确的处理顺序裁剪时经常遇到这样的情况你在菜单里把某个子系统关掉了保存后重新打开它又变回 y。这几乎一定是两个原因之一——被别的符号select了或者它本身不是可选项而是某项功能的必然依赖。处理顺序建议从上往下先关上层应用功能某个具体驱动、某个文件系统、某个协议族再回头看下层公共组件。反过来的话你关掉公共组件上层会把它 select 回来来回拉锯。判断依据可以用make savedefconfig之后的 diff如果某一行反复出现在你的改动里又被回滚说明它有强依赖或强 select去 grep Kconfig 找源头。5.3 一份可参考的裁剪清单与千万别关名单不同产品差异很大但下面这张表在多数嵌入式场景下都适用类别典型选项处理建议调试信息DEBUG_INFO及其子项出货配置一律关闭运行时检测内存/锁检测、函数追踪类选项除专门排障版本外关闭示例与测试SAMPLES等关闭无关文件系统产品用不到的文件系统逐个关闭保留根文件系统所需无线与音视频无线子系统、声卡、显示相关无对应硬件时关闭体积优化内核压缩方式、模块压缩按启动性能需求权衡模块支持MODULES有使用modprobe的需求时保留容器与系统服务cgroups、命名空间、SYSFS跑 systemd 或容器运行时必须保留基础能力BINFMT_ELF、PRINTK、TMPFS、PROC_FS绝对不能关最后一行要单独强调。我见过有人为了缩体积把PRINTK关掉结果目标板启动失败时一条日志都没有只能靠点灯定位排障成本翻了几倍。也有人关掉BINFMT_ELF内核起来了但用户态第一个程序就跑不起来。还有一些是不跑容器就以为不用的比如事件通知、信号量相关的几个基础设施很多运行时和上层框架都在用关掉之后表现为某个服务莫名起不来。提示make tinyconfig生成的配置体积非常小但那是构建系统能接受的下限不是能启动的下限只适合当裁剪起点或者做配置系统本身的测试。5.4 分阶段裁剪与回归验证的方法我自己的节奏是一次只关一个类别编译通过后立刻启动一次拿到 dmesg 与基线版本对比确认没有新增报错、没有驱动加载失败、关键外设功能正常再进入下一类。这样出问题时能立刻锁定到刚关掉的那一类而不是面对几十个改动去二分。基线管理也很重要始终保留一份已知可用的最小配置每轮裁剪从它出发验证通过后把它更新成新的基线。目标板上如果打开了运行时配置读取能力可以直接在板子上核对当前运行的配置避免出现我以为用的是这份配置实际烧的是另一份这种低级但高发的事故。还有一个容易被忽略的点编译通过不等于功能完好。有些驱动是编译期内置但只在特定运行时场景才被调用裁剪时看代码依赖看不出来。所以回归测试至少要覆盖产品的核心业务流程而不只是能起来。6. 版本升级、协作和日常维护中容易翻车的细节6.1 新符号出现时的那句提示别当成错误大版本升级后第一次构建经常会看到类似配置文件已变化请运行配置工具的提示随后构建系统自己跑一遍同步。这不是报错而是它在处理 Kconfig 里新增或语义变化的符号。同步完之后如果还有未决的新符号它会明确告诉你回去跑一次交互式配置。我的建议是跨大版本升级时老老实实跑一次make oldconfig逐项看完新增项再savedefconfig收敛。为什么呢新增项里的默认值不一定对产品合适尤其是安全和资源相关的开关有的默认开启会带来额外开销有的默认关闭会导致某个新硬件用不了。这一遍花二十分钟能避免上线后一个诡异的性能回退。6.2 配置漂移外部构建、多份.config与缓存不一致外部构建make O能让源码目录保持干净非常适合一个源码树同时产出多个产品配置。但它也带来两个坑一是前面说的.config位置问题二是两份配置来回切换时的缓存残留。切换配置后如果不做一次彻底的清理上一份配置编译出的目标文件可能被复用产出的镜像里混着两种配置的代码。配置系统确实有依赖追踪机制理论上.config变了会自动触发相关目标重建但它追踪的是配置层面的变化跨产品线的大改动我仍然建议切配置后跑一次清理再全量编译一次确认无误后再用增量。另外绝对不要在两个终端里一边menuconfig一边make两边同时读写同一份配置和中间产物结果不可预测。至于清理命令的记忆点make clean保留.configmake mrproper连.config一起删。我见过同事习惯性敲make mrproper当大扫除然后把辛苦调了两天的配置清掉了——如果确实需要彻底清理又想保住配置先把.config拷出来再清。6.3 仓库里该提交什么、不该提交什么结论很明确提交arch/$ARCH/configs/下的xxx_defconfig以及自己维护的 fragment不提交.config。内核源码自带的忽略规则已经处理了.config及其备份文件你不需要额外配置。提交前务必用savedefconfig收敛一次让 diff 只反映真实意图这是对下一个读代码的人最基本的尊重。另一个细节是提交粒度一次提交只改一类东西。把关闭调试信息和打开某个外设驱动塞进同一个提交回退的时候会很难受。配置文件的 diff 不像代码那样有清晰的结构只能靠提交信息来补所以在提交信息里写清楚为什么关掉某项比写更新配置有用一百倍。我自己一直保持的一个小习惯分享出来每次改完配置准备提交前先跑一次savedefconfig再跑一次git diff然后问自己一个问题——这些变化里有哪几行是半年后的我还能一眼看懂原因的看不懂的那几行我就补上注释或者单独拆一个提交。配置文件的维护成本从来不在改的那一刻而在一年后有人需要基于它做二次开发的那一刻。