设备模型与驱动框架
这页讲的是：Linux 怎么把五花八门的硬件设备纳入统一管理，以及驱动如何不是“直接乱写寄存器”，而是放进总线、设备、驱动框架这套体系里协同工作。学这页的关键，是把“具体驱动代码”和“整个系统如何组织硬件”区分开。
这块是什么
设备模型与驱动框架负责回答：系统里有哪些设备、它们挂在哪条总线上、该由哪个驱动接管、生命周期怎么管理、怎样把硬件能力暴露成统一系统服务。它是 Linux 连接硬件世界的组织层。驱动当然重要，但驱动不是散落在系统里的“单兵作战代码”，而是被放在统一框架中管理和协调。
可以把它想成“硬件管理系统”：先把设备登记入册，再按规则找到合适驱动，最后把能力接入整个内核。
它负责什么
组织设备与总线
- 识别设备属于哪类总线
- 描述设备层级和关系
- 统一设备注册方式
- 让系统知道“有哪些硬件、它们归谁管”
匹配驱动
- 让驱动和设备按规则绑定
- 处理 probe/remove 生命周期
- 支持热插拔与动态管理
- 把驱动加载从“手工拼接”变成系统化流程
把硬件能力接入系统
- 提供设备文件或内核接口
- 接入具体子系统
- 配合电源管理和资源管理
- 把硬件变成文件、网络、输入等上层能力的一部分
设备是怎么被系统接住的
| 阶段 | 你现在怎么理解 | 为什么重要 |
|---|
| 设备被发现 | 系统先知道硬件存在，知道它属于哪种总线或平台。 | 没有“发现”，驱动就无从谈起。 |
| 设备对象被建立 | 内核用统一对象方式记录设备的身份和关系。 | 这让硬件不再只是“某段寄存器地址”，而是系统中的正式成员。 |
| 驱动匹配并 probe | 系统把合适驱动和设备配对，驱动开始初始化设备。 | 这一步决定硬件能力能否真正进入可用状态。 |
| 接入上层子系统 | 设备能力被交给网络、存储、输入等具体子系统使用。 | 说明驱动的终点不是“寄存器配好了”，而是系统服务真正可用了。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| 设备模型 | 内核统一表示和管理设备的一套对象体系。 |
| 总线 | 连接设备和驱动的组织方式，比如 PCI、USB、I2C、platform 等。 |
| probe / remove | 驱动接管设备与释放设备时的关键生命周期入口。 |
| sysfs | 把内核中的设备对象关系以文件视图展示出来的方式之一。 |
| DMA | 设备和内存高效交换数据的常见机制，很多驱动都会碰到。 |
为什么重要
- 没有统一设备模型，Linux 不可能优雅地支持这么多不同硬件。
- 驱动不是孤立存在的，它必须被放进系统的设备、总线和电源管理框架中。
- 很多子系统看起来是“网络”或“存储”问题，往下追最终都会落到设备和驱动。
- 理解这层之后，你再看驱动代码，会更容易知道它到底是在系统的哪一个位置上工作。
常见误解
- 误解一：驱动就是直接操作寄存器。实际上驱动通常还要遵守总线、设备模型、生命周期和资源管理规则。
- 误解二：总线只是硬件名词。实际上它还意味着一套设备发现、匹配和管理方式。
- 误解三：设备模型只是展示用。实际上它决定了内核如何统一组织硬件对象和驱动关系。
它不负责什么
- 它不决定应用层业务语义，只负责把硬件能力接入系统。
- 它不单独提供调度、内存、并发这些公共机制，但驱动会大量依赖它们。
- 它不等于某个具体设备驱动文件，而是驱动们共同依赖的组织框架。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| Core API | kobject、引用计数、工作队列等基础设施大量用于驱动框架。 |
| 内存管理 | 驱动经常需要缓冲区分配、映射、DMA 和页管理配合。 |
| 中断 / 并发 | 设备事件常通过中断触发，驱动必须处理并发与同步。 |
| 网络 / 文件系统 | 上层子系统最终都要靠具体驱动去碰真实硬件。 |
读完这页后，你应该能回答
- 为什么驱动不是孤立代码，而是被放在统一框架里管理？
- 设备、总线、驱动三者之间到底是什么关系？
- 为什么很多上层系统能力最后都要落到设备模型和驱动上？
后面适合继续问：总线和驱动到底谁负责匹配？platform 设备和 PCI/USB 有什么差别？设备模型为什么和 sysfs 关系这么深？