The Linux Kernel Device Model
Patrick Mochel <mochel@digitalimplant.org>
Drafted 26 August 2002
Updated 31 January 2006
Overview~~~~~~~~
新的Linux内核驱动模型对之前内核中各种不同的驱动模型进行了统一化的工作. 目的是对bus相关的驱动做一个增强 --- 通过向全局的数据结构中加入数据和方法
之前的驱动模型将其所控制的设备组织为类似于树（有时只是一个列表）的结构。对于不同的bus类型来说，并不存在一个统一的模型。
现在的驱动模型提供了一个通用的、统一的数据模型，用以描述bus及挂载与其上的设备。统一的bus模型包括一套适用于所有总线类型的属性，以及一套回调函数，比如当探测bus上的设备时所用到的函数（probe），关闭总线的函数（shutdown），电源管理的函数，等等.
通用的设备和桥设备（bridge）接口反映了现代计算机的目标：也就是进行无缝的设备即插即用，电源管理以及热插拔。尤其是，由Intel和Microsoft所定义的ACPI（Advanced Configuration and Power Management Interface）保证了在这样一套框架下，所有设备在x86兼容系统上的几乎所有总线上都能工作。当然，并不是每种总线都支持所有的操作，但事实是，几乎所有的总线支持几乎所有的操作。
DownstreamAccess~~~~~~~~~~~~~~~~~
通用的数据域已经从各个总线层中被移到了一个公用的数据结构. 这些域仍旧需要保证能被总线层，有时被特定设备的驱动访问到.
其它的总线层可以参考PCI层的做法.
结构pci_dev 现在是这样的:
struct pci_dev {
...
struct devicedev; /* Generic device interface */
...
};
请留意结构pci_dev 中的device域是要静态申请的。这意味着在探测设备是只能做一次allocation.
还要留意device结构并非一定要在pci_dev结构之前定义。这么做的目的是促使大家在总线驱动和全局驱动之间做切换时要考虑下到底在做什么，并防止无意义的、错误的数据结构嵌套.
PCI总线层可以访问device结构中的域。它了解pci_dev结构，当然也了解device结构。已经变更到现有的驱动模型的那些PCI设备驱动不会也不应该访问device结构，除非是编译上的原因.
上述抽象可以防止向新的模型过渡过程中的不必要的麻烦. 如果不是现在这样设计，如果某个域被改名或移除，其下游的驱动都将崩溃. 另一方面，如果只有总线层（并非设备层）访问device结构, 那么只要修改总线层就够了.
UserInterface~~~~~~~~~~~~~~
由于系统中的所有设备都组织为一个完整的树状结构，向用户空间导出该树状结构也就相对简单了. 这个任务由虚拟文件系统sysfs实现.
几乎所有的主流Linux发行版都会自动mount这个文件系统; 可以在mount命令的输出中看到:
$ mount
...
none on /sys type sysfs (rw,noexec,nosuid,nodev)
...
$
自动mount的工作一般是由/etc/fstab文件中类似于下面的指令完成的:
none
在基于Debian的系统中:
none /sys sysfs nodev,noexec,nosuid 0 0
如果未能自动挂载，可以手动:
# mount -t sysfs sysfs /sys
每当有设备被加入到树中，在/sysfs就会为其创建相应的目录. 探测设备过程中任何层都有可能向该目录写入数据– 全局层，总线层或设备层.
全局层目前会创建两个文件- 'name' 和 'power'. 前者只是用来提供设备的名字. 而后者则提供当前的电源状态，还可以用于设置电源状态.
总线层在总线上探测设备时也有可能在目录中为探测到的设备创建文件. 例如, PCI层会为每一个PCI设备创建'irq' 和 'resource' 文件.
设备驱动也可能向该目录导出文件，用来提供设备数据或可调整的接口.
关于sysfs的布局，可以在本目录的其它文档或Documentation/filesystems/sysfs.txt中找到更多信息.
