Linux内核设备模型(1)

Linux内核设备模型

翻译者：郭少悲
2009/12/01

原文：linux/Documentation/driver-model/overview.txt

概述
~~~~

Linux内核驱动模型是针对内核之前所有不同的驱动模型的统一抽象模型。它的目的是,通
过结合一套数据和操作集到一个全局可访问的数据结构里，从而添加基于某种指定总线的设
备和桥接驱动。

传统的驱动模型实现了类似树的数据结构(或者一个链表数据结构）来控制设备,
而没有一个跨越不同总线类型，统一的抽象数据结构。

当前的驱动模型提供了一个通用的统一的数据模型，用于描述一个总线，以及挂载在总线
上的设备。这个统一的总线模型包含了一套每个总线都拥有的通用属性，一套通用的回调
函数，例如bus probing, bus shutdown, bus power management回调函数
等等。

通用的设备和桥接接口体现了现代计算机的目标：即无缝设备“即插即用”的能力，电源管
理能力，和热插拔能力。特别地，由Intel和Microsoft支配的模型假定几乎所有的设备在
x86兼容的总线上能够以上述方式工作。当然，不是每一个总线能够支持所有的这些操作
，但是几乎绝大部分的总线支持这些操作的绝大部分。


底层访问
~~~~~~~~

通用的数据域已经从单个具体的总线层移置到一个通用的数据结构里。这些域仍然必须
能够被总线层访问，有时也可以被特定的设备驱动访问。

其他的总线层被鼓励学习PCI总线层的做法，struct pci_dev定义如下：

struct pci_dev {
    ...

    struct device dev;
};

首先记住，它是静态分配的。这意味着在设备探测时只分配一次。也需要记住，这个域
(struct device dev)在struct pci_dev的尾部。这让人们理解在需要bus driver和
global driver之间进行转换时应当做什么，减少切换需要的开销。
(我的理解是，很简单，就是两个数据结构之间通过指针来查找定位)

PCI总线层完全能够自由地访问struct device的各个域。它了解struct pci_dev的结构，也应
当了解struct device的结构。具体的PCI设备驱动使用了新的驱动模型，就不能也不应当
接触struct device的各个域，除非有一个要做的强制理由。

这种抽象阻止了在过渡阶段不必要的阵痛（我的理解，指的是数据在不同结构层上的处理
）。如果一个域的名字改变或者移除，底层的驱动就会遭到破坏。从另一方面讲，如果仅
有总线层（非设备层）访问struct device，那么应当只有总线层发生改变。


用户接口
~~~~~~~~

借助系统对于所有设备有一个完整的层次视图的优势，向用户空间输出一个完整的设备层
次视图比较容易做到。这个功能已经通过实现一个特殊目的的虚拟文件系统sysfs而变为
现实了。用户可以在用户空间任意的地方mount sysfs文件系统。

你可以在/etc/fstab文件里添加下面一行内容，保证你的系统能够永久自动地mount
sysfs。(当然，你需要确认mount点/sys是存在的)

none         /sys    sysfs    defaults        0    0

你也可以通过手动命令就行mount，如下：

# mount -t sysfs sysfs /sys

一旦设备被插入到这个树里，对应地会为它产生一个目录。这个目录可能会在树的每个层
里出现：全局层，总线层，或者是设备层。

全局层通常创建两个文件－'name'和'power'。前者仅仅报告了设备的名字；后者报告了
设备的当前电源状态，它也被用来设置当前的电源状态。

总线层也许会为它所检测到的挂载在其上的设备创建文件。例如，PCI层通常会为每个
PCI设备创建'irq'和'resource'文件。

一个特定设备的驱动也许会在它的目录里导出设备特定的文件，显示设备相关的数据
或者调整设备参数的接口。

更多的sysfs目录布局请参考文档Documentation/filesystems/sysfs.txt。