1.1 节我们讲了 DRM 演进（Why DRM），1.2 节我们介绍了本专栏覆盖范围（What），这一节我们讲下本书的主线逻辑（How organized）。
1. 为什么选择 BO 作为主线
DRM 子系统模块众多，初学者容易迷失在 KMS、GEM、TTM、dma-buf、dma-fence、scheduler 等概念的"字母汤"中。本专栏选择 Buffer Object（BO）的生命周期作为贯穿全部章节的主线，原因有三：
- BO 是 DRM 子系统中几乎所有模块的操作对象。无论是 GEM 的对象抽象、TTM 的物理资源管理、dma-buf 的跨设备共享、dma-fence 的同步保护，还是 scheduler 的命令调度——它们最终都在围绕"这块 GPU 内存"展开工作。
- BO 的生命周期天然形成一条递进链路。从创建到销毁，BO 经历的每个阶段都对应着一个核心问题，而每个问题恰好由一个独立模块来回答。章节顺序即是 BO"一生"的时间线。
- BO 主线连接了传统模式与现代演进。从显式 BO 管理（GEM/TTM）到统一虚拟地址空间（SVM），主线的终点自然引出 DRM 内存管理的范式转变，使读者既扎根经典又面向未来。
BO 是 DRM 子系统的"原子操作对象"——理解了 BO 的一生，就理解了整个子系统的协作方式。
2. BO 生命周期与章节对应关系
每章在主线中的角色如下：
| 章节 | 生命周期阶段 | 核心问题 |
|---|---|---|
| 第三章 GEM | 创建与引用 | BO 怎么被创建、命名、引用计数管理？ |
| 第四章 TTM | 物理资源管理 | BO 的物理内存从哪来、放在哪、如何搬迁？ |
| 第五章 共享 | 跨边界传递 | BO 怎么被安全地交给另一个进程或设备使用？ |
| 第六章 同步 | 并发访问控制 | 多方同时操作 BO 时，如何保证不出现数据竞争？ |
| 第七章 Scheduler | 命令执行调度 | 操作 BO 的 GPU 命令，按什么策略投递到硬件？ |
| 第八章 GPUVM | GPU 地址映射 | BO 映射到 GPU 虚拟地址空间的哪个位置？ |
| 第九章 SVM | 范式演进 | 能否消除显式 BO 管理，CPU/GPU 共享同一地址空间？ |
3. 主线逻辑：三个递进层次
将上述链路进一步抽象，本专栏实际解答了关于 GPU 内存管理的三个递进问题：
数据管理 — Ch3 GEM + Ch4 TTM + Ch5 共享
BO 的创建、安置、共享——解决"数据在哪、归谁"
执行协调 — Ch6 同步 + Ch7 Scheduler
依赖跟踪、命令调度——解决"何时可用、何时执行"
地址空间演进 — Ch8 GPUVM + Ch9 SVM
从显式映射到统一寻址——解决"如何让 GPU 看到数据"
三层演进的历史对应
这三层的演进也对应了 DRM 子系统二十年的发展方向：
GEM/TTM 入主线
dma-buf 标准化
GPU scheduler 公共化
dma-fence 规则固化
drm_gpuvm 合入
drm_gpusvm 提出
VM_BIND 标准化
4. 附录的定位
细心的读者会注意到，调试技术（DRM Print / DebugFS / Trace / KUnit）和 Linux 基础技术（进程管理、anon_inode 等）没有出现在上面的主线链路中。这是有意为之：
- 附录 A：DRM 内核调试技术 — 调试是贯穿所有章节的正交工具维度，不属于 BO 生命周期的某个阶段。将其独立为附录，读者在学习任意章节时都可以按需查阅。正文各章末尾会交叉引用附录的对应小节（例如：Ch4 TTM → 附录 A.7.2 显存监控、Ch6 同步 → 附录 A.7.4 fence 调试）。
- 附录 B：Linux 系统基础技术汇总 — 支撑 DRM 运行的底层基石（等待队列、进程控制等），按需参阅。
完整的专栏结构
5. 如何使用本主线
顺序阅读
按章节顺序即是 BO 从生到死的完整旅程，适合系统学习。
按需跳转
明确自己关注 BO 生命周期的哪个阶段，直接进入对应章节。
回溯理解
遇到某个模块时回顾本节的链路图，确认它在整体中的位置。
调试伴读
学习每章时同步翻阅附录 A 中对应的调试手段，边学原理边掌握排查工具。
如果把 BO 比作一个快递包裹，那么 GEM 是下单建单，TTM 是仓储分拣，共享是转运交接，同步是签收确认，Scheduler 是调度派送，GPUVM 是地址路由，SVM 是"无感配送"——不用填地址，系统自动知道送到哪。而附录 A 的调试技术，就是这套物流系统的"监控大屏"——随时可以打开查看包裹到了哪一站。