在 2.5 开发循环中一个声明的目标是为内核创建一个统一的设备模型. 之前的内核没有单一的数据结 构, 使它们可以来获取关于系统如何整合的信息. 尽管缺乏信息, 有时事情也进行的不错. 新系统, 带 有它们的更加复杂的技术并且需要支持诸如电源管理等特性, 但是, 清楚地要求需要一个通用的描述系 统结构的抽象.
2.6 设备模型提供了这个抽象. 现在它用在内核来支持广泛的任务, 包括: 电源管理和系统关机
这些需要一个对系统的结构的理解. 例如, 一个 USB 宿主适配器不可能被关闭, 在处理所有的 连接到这个适配器的设备之前. 这个设备模型使能了一个按照正确顺序的系统硬件的遍历.
与用户空间的通讯
sysfs 虚拟文件系统的实现被紧密地捆绑进设备模型, 并且暴露它所代表的结构. 关于系统到 用户空间的信息提供和改变操作参数的旋纽正越来越多地通过 sysfs 和 通过设备模型来完成.
可热插拔设备
计算机硬件正更多地动态变化; 外设可因用户的一时念头而进出. 在内核中使用的来处理和(特 别的)与用户空间关于设备插入和拔出的通讯, 是由设备模型来管理.
设备类别
系统的许多部分对设备如何连接没有兴趣, 但是它们需要知道什么类型的设备可用. 设备模型 包括一个机制来分配设备给类别, 它在一个更高的功能性的级别描述了这些设备, 并且允许它 们从用户空间被发现.
对象生命期
许多上面描述的功能, 包括热插拔支持和 sysfs, 使在内核中创建和操作对象复杂了. 设备模 型的实现要求创建一套机制来处理对象生命期, 它们之间的关系, 和它们在用户空间的表示.
Linux 设备模型是一个复杂的数据结构. 例如, 考虑图设备模型的一小部分, 它展示了(用简单的形式) 和 USB 鼠标关联的设备模型结构的微小片段. 图中心的下方, 我们看到核心"设备"树, 展示了鼠标如 何连接到系统. "bus"树跟踪什么连接到每个总线, 而在"classes" 下的子树涉及设备提供的功能, 不 管它们是如何连接的. 设备模型树即便在一个简单的系统中也包含几百个节点, 如同在图中展示的那些; 它是一个难于整个呈现的数据结构.
对大部分, Linux 设备模型代码负责所有这些方面, 而不强加自己于驱动作者之上. 它大部分位于后面; 和设备模型的直接交互通常由总线一级的逻辑和各种其他的内核子系统处理. 结果, 许多驱动作者会完 全忽略设备模型, 并且信任它来照顾它自己.
有时, 但是, 理解设备模型是一个好事情. 有时设备模型从其他的层后面遛出来; 例如, 通用的 DMA 代码( 我们在第 15 章遇到) 使用 struct device. 你可能想使用一些由设备模型提供的能力, 例如引 用计数和由 kobjects 提供的相关特色. 通过 sysfs 和 用户空间的通讯也是一个设备模型功能; 本章 解释了这个通讯如何工作.
但是, 我们开始于一个自底而上的设备模型的表述. 设备模型的复杂性使得难于从一个高层视角来理解. 我们的希望是, 通过展示低层设备组件如何工作, 我们可为你准备这个挑战, 掌握这些组件如何用来建 立更大的结构.
对大部分读者, 本章可作为高级材料,不需要在第一次读完. 鼓励那些对 Linux 设备模型如何工作感兴 趣的人努力向前, 但是, 在我们进入底层细节时.