2. Yocto基础回顾

在正式进入内核定制与补丁管理之前，有必要把 Yocto 项目中最核心的几个概念重新梳理一遍。很多初学者在修改内核时感到无从下手，根本原因并不是不会写补丁，而是没有理清 BitBake、OpenEmbedded、Poky、元数据层、配方与类之间的分工与依赖关系。本节将围绕这条主线，把构建系统的骨架讲清楚，为后续的内核配方改写、bbappend 追加和补丁注入打下基础。

一、核心原理：四个名字，四种角色

Yocto 项目本身并不是一个可以直接运行的软件，而是一套构建框架与协作规范的集合。真正干活的是 BitBake，它负责解析元数据、计算任务依赖、调度执行。OpenEmbedded 则提供了这套构建逻辑的“内容库”，包括大量配方、类文件和构建规则。Poky 是 Yocto 官方提供的参考发行版，它把 BitBake 与 OpenEmbedded 元数据打包在一起，让开发者开箱即用。而元数据层（Layer）是组织这些配方与配置的目录结构，是定制工作的主要战场。

可以用一句话概括它们的关系：BitBake 是引擎，OpenEmbedded 是规则库，Poky 是参考整车，元数据层是可插拔的零件包，配方是单个零件的加工说明书，类是说明书中的通用模板。

二、方法流程：一次构建到底发生了什么

当你在终端执行 bitbake core-image-minimal 时，BitBake 会按以下顺序工作：首先读取 bblayers.conf 中列出的所有元数据层，然后解析每层中的 layer.conf、配方文件和类文件，构建出一张巨大的任务依赖图。接着它按照依赖顺序执行每个配方的任务，从下载源码、解压、打补丁，到配置、编译、安装、打包，最终生成根文件系统镜像。

对于内核定制而言，最关键的任务节点是 do_patch 和 do_configure。补丁在 do_patch 阶段被应用到内核源码树，而内核配置片段则在 do_configure 阶段合并进 .config。理解这一点，就能明白为什么补丁文件必须放在配方的 SRC_URI 中，以及为什么 SRC_URI 的顺序会影响补丁应用结果。

# 查看某个配方的任务列表
bitbake -c listtasks linux-yocto

# 只执行到打补丁阶段
bitbake -c patch linux-yocto

# 查看内核配方的元数据来源
bitbake -e linux-yocto | grep ^SRC_URI

三、案例场景：从零定位一个内核配方

假设我们需要为一块自定义板卡修改内核配置。第一步是确认当前使用的是哪个内核配方。执行 bitbake -e virtual/kernel | grep ^FILE，可以找到实际生效的配方文件路径，通常是 linux-yocto.bb 或某个 BSP 层中的内核配方。第二步是查看该配方继承了哪些类，inherit kernel 和 inherit kernel-yocto 是最常见的两个。第三步是确认 SRC_URI 中已经包含了哪些补丁和配置片段，避免重复或冲突。

接下来，我们不会直接修改原始配方，而是在自定义层中创建一个 .bbappend 文件，通过追加的方式注入自己的补丁和配置。这是 Yocto 推荐的做法，既保持了上游配方的完整性，又让定制内容清晰可追溯。

# 自定义层中的内核追加配方
# meta-mylayer/recipes-kernel/linux/linux-yocto_%.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://0001-my-driver-fix.patch \
            file://my-board.cfg"

四、误区与复盘：常见理解偏差

下表汇总了本节涉及的核心对象及其职责，建议在后续内核定制过程中反复对照。