4. 配置系统入门
Buildroot 的配置系统是整个 BSP 定制流程的“总控台”。它决定了目标架构、工具链类型、内核版本、根文件系统格式、软件包集合以及大量编译与打包行为。理解配置系统，核心不是记住某个菜单在哪，而是理解 Kconfig 配置模型、defconfig 配置快照 与 .config 实际配置 三者之间的关系。只有把这三者串起来，才能在项目迭代、版本升级和团队协作中稳定地保存与加载配置。
一、核心原理：Kconfig、.config 与 defconfig 的关系
Buildroot 使用与 Linux 内核同源的 Kconfig 机制。源码树中的 Config.in 文件定义配置项、依赖关系、默认值和菜单结构；执行 make menuconfig 时，配置工具读取这些定义，并生成或更新根目录下的 .config。这个 .config 是当前构建真正使用的配置集合，每一行形如 BR2_xxx=y 或 BR2_xxx="value"。
而 defconfig 是保存在 configs/ 目录下的“配置快照”，通常只记录与默认值不同的关键选项，用于快速复现某个板级或产品级配置。执行 make <board>_defconfig 时，Buildroot 会先加载默认配置，再叠加该 defconfig 中的选项，最终生成 .config。因此，.config 是运行时状态，defconfig 是可版本管理的配置源。
二、方法流程：menuconfig 操作与配置项分类
进入配置界面的标准命令是：
cd buildroot
make menuconfig界面中常见按键：↑/↓ 移动，Enter 进入子菜单，空格 切换 [*] 编译进系统、[ ] 不编译、<M> 编译为模块（部分包支持），/ 搜索配置项，? 查看帮助与依赖，Esc Esc 返回或退出，退出时选择 Yes 保存到 .config。
Buildroot 的配置项大致可分为以下几类，理解分类有助于快速定位：
| 分类 | 典型配置项 | 作用 |
|---|---|---|
| 目标架构 | BR2_arm、BR2_aarch64、BR2_x86_64 |
决定 CPU 架构、ABI 与浮点策略 |
| 工具链 | BR2_TOOLCHAIN_BUILDROOT、BR2_TOOLCHAIN_EXTERNAL |
选择内部构建或外部预编译工具链 |
| 系统配置 | BR2_TARGET_GENERIC_HOSTNAME、BR2_TARGET_GENERIC_ISSUE |
主机名、登录提示、root 密码等 |
| 内核 | BR2_LINUX_KERNEL、BR2_LINUX_KERNEL_DEFCONFIG |
是否编译内核、内核版本与配置 |
| 根文件系统 | BR2_TARGET_ROOTFS_EXT2、BR2_TARGET_ROOTFS_SQUASHFS |
选择 rootfs 格式与压缩方式 |
| 软件包 | BR2_PACKAGE_BUSYBOX、BR2_PACKAGE_OPENSSH |
选择要集成到目标系统的应用与库 |
三、案例场景：从零配置一块 ARM 开发板
假设目标板为 ARM Cortex-A7，使用内部工具链，需要 ext4 根文件系统并集成 BusyBox 与 Dropbear。典型操作路径如下：
make menuconfig进入配置界面。- Target options → Target Architecture 选择
ARM (little endian)，Target Architecture Variant 选择cortex-A7。 - Toolchain → Toolchain type 选择
Buildroot toolchain，C library 选择glibc或musl。 - System configuration → 设置 hostname、system banner、root password。
- Filesystem images → 勾选
ext2/3/4 root filesystem，并选择 ext4 变体。 - Target packages → 勾选
BusyBox、Networking applications → dropbear。 - 保存退出后执行
make savedefconfig，生成精简配置。
make savedefconfig
cp defconfig configs/myboard_defconfig
make myboard_defconfig
make -j$(nproc)这样，configs/myboard_defconfig 就可以提交到 Git，团队成员通过 make myboard_defconfig 一键复现相同配置。
make savedefconfig 后查看生成的 defconfig，它比完整 .config 更简洁，更适合代码评审。
四、误区与复盘：配置保存与加载的常见问题
误区一：直接提交 .config。 .config 包含大量默认值和自动推导项，体积大且随版本变化剧烈，容易产生冲突。正确做法是提交 defconfig。
误区二：修改 defconfig 后不重新生成 .config。 手动编辑 configs/myboard_defconfig 后，必须执行 make myboard_defconfig 才会生效；直接 make 仍使用旧 .config。
误区三：忽略依赖关系。 Kconfig 中很多选项有 depends on 和 select。若某个包无法勾选，可用 / 搜索该选项，按 ? 查看它依赖哪些条件未满足。
误区四：配置项被覆盖。 某些包在编译时会自动 select 依赖项，导致 .config 与手动选择不一致。此时应检查 Config.in 中的 select 语句，而不是反复手动修改。
make clean 不会删除 .config；执行 make distclean 会删除 .config 及所有生成文件。若想保留配置，请先备份 defconfig 或 .config。
复盘来看，配置系统的稳定使用可以归纳为一条主线：用 menuconfig 交互修改，用 .config 驱动构建，用 savedefconfig 导出快照，用 defconfig 实现复现。掌握这条主线，后续的 BSP 定制、内核裁剪与根文件系统裁剪都会变得有据可依。