3. Busybox配置系统：menuconfig配置界面、配置选项详解、保存与加载配置

Busybox的配置系统，说白了就是决定「这个工具箱里要放哪些工具」的开关面板。你想想看，一个嵌入式系统可能只需要十几条命令，但Busybox默认编译了三百多个。全编进去，镜像体积大、编译时间长，还容易踩雷。

我刚开始做嵌入式的时候，就吃过这个亏。那时候图省事，直接 make defconfig 一把梭，结果编译出来的 busybox 有 1.2MB，放到只有 2MB Flash 的板子上，连根文件系统都塞不进去。后来老老实实学配置裁剪，才把体积压到 300KB 以内。嗯，这节课我们就来把配置系统彻底搞明白。

3.1 menuconfig 配置界面

Busybox 的配置界面基于 Kconfig 体系，和 Linux 内核的配置系统同源。你如果配过内核，上手会非常快。

进入配置界面的命令很简单：

make menuconfig

前提是你已经解压了 Busybox 源码，并且安装了 ncurses-devel（或 libncurses-dev）库。如果没有，终端会报错：

*** Unable to find the ncurses libraries.

这时候装一下依赖就行：

# Debian/Ubuntu
sudo apt-get install libncurses-dev

# CentOS/RHEL
sudo yum install ncurses-devel

进入界面后，你会看到一个蓝底白字的菜单树。操作方式和 Linux 内核的 menuconfig 完全一致：

3.2 配置选项详解

每个配置项有三种状态，用方括号或尖括号表示：

• [*] 或 [Y] —— 编译进 Busybox（内置）。这是最常用的方式，命令直接集成到 busybox 二进制中。
• [ ] 或 [N] —— 不编译。裁剪时就把不需要的项设为 N。
• <M> —— 编译为独立模块。Busybox 里很少用，主要是为了兼容内核配置习惯。

举个例子，我们来看 Linux Module Utilities 这个菜单：

Linux Module Utilities --->
  [*] insmod
  [*] rmmod
  [*] lsmod
  [ ] modprobe
  [ ] depmod

如果你只需要加载和卸载内核模块，那就只勾 insmod 和 rmmod，modprobe 和 depmod 可以关掉。这样能省下不少空间。

配置项的类型不止开关，还有以下几种：

我个人最常打交道的是 bool 和 string。比如 CONFIG_PREFIX 这个字符串选项，它决定了 make install 时 busybox 安装到哪个目录。默认是 ./_install，我一般改成 /path/to/rootfs，直接装到根文件系统目录里。

3.3 保存与加载配置

配置完成后，按 Esc + Esc 退出，menuconfig 会弹出对话框问你是否保存。选 Yes，配置会写入 .config 文件。

.config 是纯文本文件，格式很简单：

CONFIG_INSMOD=y
CONFIG_RMMOD=y
CONFIG_LSMOD=y
# CONFIG_MODPROBE is not set
CONFIG_PREFIX="./_install"

每一行就是一个配置项。=y 表示选中，is not set 表示未选。你可以直接编辑这个文件，但我建议只在 menuconfig 里改，手动改容易搞乱依赖关系。

我曾经有一次为了省事，直接 sed 替换 .config 里的值，结果编译时报了一堆未定义的宏。查了半天才发现是依赖项没同步打开。从那以后，我再也不敢手改 .config 了。

3.3.1 保存配置的快照

实际项目中，你可能会维护多套配置：比如开发板用一套、量产板用一套、调试版用一套。Busybox 提供了保存和加载配置快照的功能：

# 保存当前配置到文件
make savedefconfig
# 这会生成一个 defconfig 文件，只包含非默认值的选项

# 从文件加载配置
make defconfig
# 或者指定自定义配置文件
cp my_config .config
make oldconfig

savedefconfig 是我非常喜欢的一个命令。它生成的 defconfig 文件只记录你修改过的选项，体积很小，适合放到版本控制里。比如你只改了 20 个选项，defconfig 可能只有 30 行，而完整的 .config 有上千行。

3.3.2 配置的合并与覆盖

有时候你需要基于默认配置做少量修改。Busybox 支持配置合并：

# 先加载默认配置
make defconfig

# 再加载你的增量配置
make my_board_defconfig

如果两个配置有冲突，后加载的会覆盖前面的。这个机制在团队协作时很有用——基础配置由一个人维护，其他人只提交增量配置。

3.4 配置系统核心逻辑图

下面这张图展示了 Busybox 配置系统的完整工作流程，从 Kconfig 定义到最终生成二进制：

从图中可以看到，Kconfig 定义是配置系统的「宪法」，它规定了每个选项的类型、默认值和依赖关系。menuconfig 是交互界面，帮你按规则修改配置。.config 是最终产物，直接驱动编译过程。

3.5 常见配置场景与避坑

最后分享几个我在项目中遇到的配置场景：

• 场景一：裁剪到极致 —— 只保留 init、sh、mount、ls、cat、echo 等十几条命令。这时候建议从 allnoconfig 开始，再逐个添加：make allnoconfig; make menuconfig。
• 场景二：调试阶段 —— 打开所有调试选项，比如 CONFIG_DEBUG、CONFIG_FEATURE_xxx_DEBUG。这些选项通常在 Busybox Settings → Debugging 菜单下。
• 场景三：驱动集成 —— 确保 CONFIG_MODPROBE、CONFIG_INSMOD 等模块工具打开，否则驱动 ko 文件加载不了。