3、Busybox源码获取：从Yocto源码仓库获取Busybox、理解SRC_URI机制、源码补丁管理
好，咱们进入正题。这一章聊的是Busybox源码怎么拿到手，以及Yocto里那套SRC_URI机制到底怎么玩。说白了，就是搞清楚「菜从哪来、怎么运、要不要改刀」这三个问题。
我刚开始接触Yocto时，总觉得源码获取不就是git clone一下嘛？后来被坑过几次才明白——Yocto的源码管理远不止拉代码那么简单。它要处理版本锁定、校验和、补丁管理、镜像缓存……一套组合拳下来，你才能稳定复现构建。
核心要点：Yocto通过SRC_URI变量统一描述源码来源，支持git仓库、tarball、本地路径等多种协议。Busybox的源码获取，本质上就是配置好SRC_URI，让BitBake帮你搞定下载、校验、解压、打补丁的全流程。
3.1 从Yocto源码仓库获取Busybox
Yocto官方已经为Busybox写好了recipe，你不需要从零开始。路径通常在 meta/recipes-core/busybox/ 下。我习惯先看看这个目录里有什么：
$ ls meta/recipes-core/busybox/
busybox_1.36.1.bb
busybox.inc
busybox-1.36.1/
busybox-1.36.1/defconfig
busybox-1.36.1/find-getopt.patch
busybox-1.36.1/udhcpc-fix.patch
...主recipe文件 busybox_1.36.1.bb 里定义了版本、源码地址、补丁列表。打开看看：
SUMMARY = "Busybox: multi-call binary combining many common Unix utilities"
HOMEPAGE = "https://busybox.net/"
SECTION = "base"
LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://LICENSE;md5=... "
SRC_URI = "https://busybox.net/downloads/busybox-${PV}.tar.bz2 \
file://defconfig \
file://find-getopt.patch \
file://udhcpc-fix.patch \
..."
SRC_URI[sha256sum] = "...
"
嗯，这里有个细节：${PV} 会自动展开成 1.36.1。Yocto的变量展开机制，说白了就是模板引擎，你定义好规则，它帮你拼出完整URL。
我的习惯：拿到一个新BSP时，我第一件事就是看 meta-xxx/recipes-core/busybox/ 下有没有自定义的bbappend文件。如果有，说明这个BSP厂商对Busybox做了定制，你得先搞清楚他们改了啥。
3.2 理解SRC_URI机制
SRC_URI是Yocto里最核心的变量之一。它告诉BitBake：「源码在哪、怎么拿、拿完后怎么处理」。我把它拆成三个维度来理解：
| 维度 | 说明 | 常见写法 |
|---|---|---|
| 来源协议 | 指定下载方式 | https://、git://、file://、ftp:// |
| 校验机制 | 确保源码完整性 | SRC_URI[sha256sum]、SRC_URI[md5sum] |
| 本地文件 | 补丁、配置文件等 | file://defconfig、file://*.patch |
举个例子，Busybox的SRC_URI里既有远程tarball，也有本地补丁和配置文件。BitBake处理时，会先下载远程文件，校验sha256，然后解压，最后把 file:// 开头的文件复制到源码目录的合适位置。
这里有个坑，我曾经踩过：
我曾经遇到过——SRC_URI里写了两个相同来源的补丁，结果第二个覆盖了第一个，导致某些修改没生效。排查了半天才发现是补丁顺序问题。记住：SRC_URI里的条目顺序就是BitBake的处理顺序，补丁按顺序叠加。
另外，file:// 路径的查找规则也值得注意。BitBake会按以下顺序搜索：
- recipe文件所在目录（如
meta/recipes-core/busybox/busybox-1.36.1/） - 通过
FILESPATH变量指定的额外路径 - BBFILE_COLLECTIONS 中所有层的对应目录
所以，如果你在自定义层里放了一个同名的defconfig，它会覆盖meta层的默认配置。这就是Yocto的层优先级机制在起作用。
3.3 源码补丁管理
补丁管理，说白了就是「不改上游源码，只改我们自己的副本」。Yocto用quilt工具来管理补丁，但你不必手动操作quilt——BitBake在 do_patch 任务里自动帮你打上所有补丁。
Busybox的补丁通常放在recipe同目录下的版本号子目录里：
busybox-1.36.1/
├── defconfig
├── find-getopt.patch
├── udhcpc-fix.patch
└── busybox-cve-2023-xxxxx.patch每个补丁文件头部都有标准的描述信息：
From: Zhang San <zhangsan@example.com>
Date: Mon, 15 Jan 2024 10:30:00 +0800
Subject: [PATCH] fix udhcpc option parsing
Upstream-Status: Submitted [https://lists.busybox.net/...]
Signed-off-by: Zhang San <zhangsan@example.com>
---
networking/udhcpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
我个人非常看重 Upstream-Status 字段。它告诉后来人：这个补丁是临时方案还是已经被上游接受了？我见过太多项目，补丁打了一堆，没人知道哪些可以删掉。养成标注状态的习惯，能省很多事。
避坑指南：补丁文件不要用绝对路径。比如 --- a/networking/udhcpc.c 里的 a/ 前缀是quilt自动生成的，你手动写补丁时也要保持这个格式。否则BitBake可能找不到要修改的文件。
补丁管理的另一个重点是「补丁粒度」。我建议一个补丁只解决一个问题。比如：
- 好的做法：
fix-udhcpc-option-parsing.patch只改udhcpc的选项解析 - 坏的做法：
all-my-changes.patch把配置、bugfix、新功能全塞一起
为什么？因为当上游发布新版本时，你只需要重新评估每个小补丁是否适用。大补丁一坨，你根本不知道哪些部分已经合入上游了。
3.4 知识体系总览
下面这张图帮你理清Busybox源码获取的完整链路：
从图上你能看到，SRC_URI是入口，它把远程源码、本地配置、补丁文件统一交给BitBake。BitBake按 do_fetch → do_unpack → do_patch → do_configure 的顺序处理，最终产出配置好的源码树。
嗯，这里要注意：do_configure 其实已经进入构建阶段了，但Busybox的特殊之处在于——它的配置（defconfig）也是在 do_configure 里应用的。所以补丁管理要确保在打补丁阶段完成所有源码修改，配置阶段只负责选择启用哪些功能。
最后分享一个小技巧。我习惯在 local.conf 里加一行：
INHERIT += "patch-status"这样构建时如果遇到 Upstream-Status 缺失的补丁，BitBake会给出警告。对于团队协作的项目，这能强制大家规范补丁管理。