嵌入式Linux构建系统怎么选？Buildroot与Yocto对比

网关类设备，根文件系统（rootfs）和镜像是怎么造出来的？

它们解决什么问题

嵌入式 Linux 的“根文件系统”不会自己长出来，通常要从零拼：交叉编译器、C 库、BusyBox、内核模块、各种用户态库（openssl、sqlite、python），最后还要放进你的应用。手工拼不仅慢，还容易漏库、版本错配。Buildroot 和 Yocto 都是“从源码/包定义自动构建整套系统镜像”的工具，差别在于组织方式和适用阶段。

Buildroot：简单直接的全量构建

Buildroot 用一个顶层 Makefile 把一切串起来，配置界面是熟悉的 menuconfig。它把整个系统当作一个整体编译，产出固件后一般不再单独升级某个包。

# 典型工作流
make menuconfig          # 选架构、工具链、要的软件包
make                     # 一次性构建 toolchain + rootfs + kernel
# 产出在 output/images/：rootfs.tar、uImage、u-boot.bin

优点：学习曲线缓；构建快（增量友好）；配置直观。缺点：升级底层库（如 openssl）时，Buildroot 虽支持单包重建（make openssl-rebuild），但无法自动识别并重编所有依赖它的上层应用，为确保 ABI 一致，工程上通常选择全量重编；多产品变体管理弱；包版本锁定不如 Yocto 严谨。

Yocto：分层、可复现的工业化构建

Yocto（核心是 BitBake + OpenEmbedded）用“层（layer）”组织一切：芯片厂商层（meta-）、板级层（meta-）、应用层（meta-myapp）叠在一起。每个包是一个 recipe（.bb 配方），声明源码地址、依赖、补丁、安装规则。

# 典型工作流
source oe-init-build-env build      # 进入构建环境
bitbake core-image-minimal          # 构建最小镜像
# 产物在 tmp/deploy/images/<machine>/

优点：构建高度可复现，recipe + 锁定源码哈希保证同样输入同样输出；分层让 BSP 和应用解耦，多产品线共享底座；支持增量构建单个包、生成 SDK、做 SBOM。缺点：概念多（layer、recipe、bbclass、overrides），构建资源消耗大，全量首次编译很慢。

Buildroot 最小镜像示例

以 ARM 网关为例，选 arm64 架构、用内部工具链、加 dropbear（SSH）和你的采集程序：

# 基于现有 defconfig，再 menuconfig 选包
make qemu_aarch64_virt_defconfig
make menuconfig
#  Target packages -> Networking -> dropbear [Y]
#  Filesystem images -> ext4 root filesystem [Y]
make -j$(nproc)

关键是包选择要克制。Buildroot 默认进来的东西不少，关掉用不到的（如多余的文件系统类型、示例程序），镜像体积和构建时间都会降下来。你的应用通过 package/<yourapp>/<yourapp>.mk 加入，和别的基础设施包同等对待。

Yocto 最小镜像与自定义层

Yocto 起步需要先有 BSP 层。多数芯片原厂（NXP、TI、Raspberry Pi 社区）已提供 meta 层，直接拉下来叠自己的应用层：

# 创建并添加自定义应用层
bitbake-layers create-layer ../meta-myapp
bitbake-layers add-layer ../meta-myapp

# 在 meta-myapp 里写 recipe：recipes-app/mycollector/mycollector_1.0.bb
# 内容声明 SRC_URI（git 或本地）、DEPENDS、do_install

recipe 的核心是把“应用怎么来、依赖谁、装到哪”写清楚，BitBake 据此解析依赖图并确定性地构建。