Linux 设备模型基本概念（一）

1、设备模型引入

Linux 2.6内核最初为了应付电源管理的需要，提出了一个设备模型来管理所有的设备。在物理上，外设之间是有一种层次关系的，比如把一个U盘插到笔记本上，实际上这个U盘是接在一个USB Hub上，USB Hub又是接在USB 2.0 Host Controller (EHCI)上，最终EHCI又是一个挂在PCI Bus上的设备。这里的一个层次关系是：PCI->EHCI->USB Hub->USB Disk。如果操作系统要进入休眠状态，首先要逐层通知所有的外设进入休眠模式，然后整个系统才可以休眠。因此，需要有一个树状的结构可以把所有的外设组织起来。这就是最初建立Linux设备模型的目的。

2、sysfs的引入

当然，Linux设备模型给我们带来的便利远不止如此。既然已经建立了一个组织所有设备和驱动的树状结构，用户就可以通过这棵树去遍历所有的设备，建立设备和驱动程序之间的联系，根据类型不同也可以对设备进行归类，这样就可以更清晰的去“看”这颗枝繁叶茂的大树。另外，Linux驱动模型把很多设备共有的一些操作抽象出来，大大减少了重复造轮子的可能。同时Linux设备模型提供了一些辅助的机制，比如引用计数，让开发者可以安全高效的开发驱动程序。达成了以上这些好处之后，我们还得到了一个非常方便的副产品，这就是sysfs----一个虚拟的文件系统。sysfs给用户提供了一个从用户空间去访问内核设备的方法，它在Linux里的路径是/sys。这个目录并不是存储在硬盘上的真实的文件系统，只有在系统启动之后才会建起来。

tree /sys 就可以看到/sys 的结构了~

/proc是内存中有关系统进程的实时信息；
/sys是有关系统内核以及驱动的实时信息；

这里有10个子目录，但并不是说这10个目录代表了10种完全不同的设备类型，实际上这些目录只是给我们提供了如何去看整个设备模型的不同的视角。其实从不同的目录出发都有可能找到同一个设备的。那真正的设备信息到底放在哪里呢？看看目录的名称就应该能猜到，对，就是devices子目录，Linux的所有设备都可以在这个目录里找到。

我们如果要写程序来访问sysfs，可以像读写普通文件一样来操作/sys目录下的文件，或者，也可以使用libsysfs。不过需要注意的是，Linux内核社区并不推荐用libsysfs，因为这个API的更新不够快，赶不上内核的变化。libsysfs已经逐渐背离最初创建它的目标，这个lib带来的问题似乎比它解决的还要多。当然，如果只是要访问设备，一般很少会直接操作sysfs，它太细节太底层了，大部分情况下可以使用更加方便的DeviceKit或者libudev。

3、sys 结构

/sys下的子目录	内容
/sys/devices	该目录下是全局设备结构体系，包含所有被发现的注册在各种总线上的各种物理设备。一般来说，所有的物理设备都按其在总线上的拓扑结构来显示，但有两个例外，即platform devices和system devices。platform devices一般是挂在芯片内部的高速或者低速总线上的各种控制器和外设，它们能被CPU直接寻址；system devices不是外设，而是芯片内部的核心结构，比如CPU，timer等，它们一般没有相关的驱动，但是会有一些体系结构相关的代码来配置它们。 (sys/devices是内核对系统中所有设备的分层次表达模型，也是/sys文件系统管理设备的最重要的目录结构)
sys/dev	该目录下维护一个按照字符设备和块设备的主次号码(major:minor)链接到真是设备(/sys/devices)的符号链接文件。
/sys/class	该目录下包含所有注册在kernel里面的设备类型，这是按照设备功能分类的设备模型，每个设备类型表达具有一种功能的设备。每个设备类型子目录下都是这种哦哦那个设备类型的各种具体设备的符号链接，这些链接指向/sys/devices/name下的具体设备。设备类型和设备并没有一一对应的关系，一个物理设备可能具备多种设备类型；一个设备类型只表达具有一种功能的设备，比如：系统所有输入设备都会出现在/sys/class/input之下，而不论它们是以何种总线连接到系统的。(/sys/class也是构成linux统一设备模型的一部分)
/sys/block	该目录下的所有子目录代表着系统中当前被发现的所有块设备。按照功能来说防止在/sys/class下会更合适，但由于历史遗留因素而一直存在于/sys/block，但从linux2.6.22内核开始这部分就已经标记为过去时，只有打开了CONFIG_SYSFS_DEPRECATED配置编译才会有这个目录存在，并且其中的内容在从linux2.6.26版本开始已经正式移到了/sys/class/block，旧的接口/sys/block为了向后兼容而保留存在，但其中的内容已经变为了指向它们在/sys/devices/中真实设备的符号链接文件。
/sys/bus	该目录下的每个子目录都是kernel支持并且已经注册了的总线类型。这是内核设备按照总线类型分层放置的目录结构，/sys/devices中的所有设备都是连接于某种总线之下的，bus子目录下的每种具体总线之下可以找到每个具体设备的符号链接，一般来说每个子目录(总线类型)下包含两个子目录，一个是devices，另一个是drivers；其中devices下是这个总线类型下的所有设备，这些设备都是符号链接，它们分别指向真正的设备(/sys/devices/name/下)；而drivers下是所有注册在这个总线上的驱动，每个driver子目录下是一些可以观察和修改的driver参数。 (它也是构成linux统一设备模型的一部分)
/sys/fs	按照设计，该目录使用来描述系统中所有的文件系统，包括文件系统本身和按照文件系统分类存放的已挂载点。
/sys/kernel	这个目录下存放的是内核中所有可调整的参数
/sys/firmware	该目录下包含对固件对象(firmware object)和属性进行操作和观察的接口，即这里是系统加载固件机制的对用户空间的接口.(关于固件有专用于固件加载的一套API)
/sys/hypervisor	该目录是与虚拟化Xen相关的装置。(Xen是一个开放源代码的虚拟机监视器)
/sys/module	该目录下有系统中所有的模块信息，不论这些模块是以内联(inlined)方式编译到内核映像文件中还是编译为外模块(.ko文件)，都可能出现在/sys/module中。即module目录下包含了所有的被载入kernel的模块。
/sys/power	该目录是系统中的电源选项，对正在使用的power子系统的描述。这个目录下有几个属性文件可以用于控制整个机器的电源状态，如可以向其中写入控制命令让机器关机/重启等等。

4、设备模型的基本概念

下图是嵌入式系统常见的硬件拓扑的一个示例：

硬件拓扑描述Linux设备模型中四个重要概念中三个：Bus，Class和Device（第四个为Device Driver，后面会说）。

Bus（总线）：Linux认为（可以参考include/linux/device.h中struct bus_type的注释），总线是CPU和一个或多个设备之间信息交互的通道。而为了方便设备模型的抽象，所有的设备都应连接到总线上（无论是CPU内部总线、虚拟的总线还是“platform Bus”）。

Class（分类）：在Linux设备模型中，Class的概念非常类似面向对象程序设计中的Class（类），它主要是集合具有相似功能或属性的设备，这样就可以抽象出一套可以在多个设备之间共用的数据结构和接口函数。因而从属于相同Class的设备的驱动程序，就不再需要重复定义这些公共资源，直接从Class中继承即可。

Device（设备）：抽象系统中所有的硬件设备，描述它的名字、属性、从属的Bus、从属的Class等信息。

Device Driver（驱动）：Linux设备模型用Driver抽象硬件设备的驱动程序，它包含设备初始化、电源管理相关的接口实现。而Linux内核中的驱动开发，基本都围绕该抽象进行（实现所规定的接口函数）。

注：什么是Platform Bus？
在计算机中有这样一类设备，它们通过各自的设备控制器，直接和CPU连接，CPU可以通过常规的寻址操作访问它们（或者说访问它们的控制器）。这种连接方式，并不属于传统意义上的总线连接。但设备模型应该具备普适性，因此Linux就虚构了一条Platform Bus，供这些设备挂靠。

4.1 设备模型的核心思想

Linux设备模型的核心思想是（通过xxx手段，实现xxx目的）：

1. 用Device（struct device）和Device Driver（struct device_driver）两个数据结构，分别从“有什么用”和“怎么用”两个角度描述硬件设备。这样就统一了编写设备驱动的格式，使驱动开发从论述题变为填空体，从而简化了设备驱动的开发。

2. 同样使用Device和Device Driver两个数据结构，实现硬件设备的即插即用（热拔插）。
在Linux内核中，只要任何Device和Device Driver具有相同的名字，内核就会执行Device Driver结构中的初始化函数（probe），该函数会初始化设备，使其为可用状态。而对大多数热拔插设备而言，它们的Device Driver一直存在内核中。当设备没有插入时，其Device结构不存在，因而其Driver也就不执行初始化操作。当设备插入时，内核会创建一个Device结构（名称和Driver相同），此时就会触发Driver的执行。这就是即插即用的概念。

3. 通过"Bus-->Device”类型的树状结构解决设备之间的依赖，而这种依赖在开关机、电源管理等过程中尤为重要。
试想，一个设备挂载在一条总线上，要启动这个设备，必须先启动它所挂载的总线。很显然，如果系统中设备非常多、依赖关系非常复杂的时候，无论是内核还是驱动的开发人员，都无力维护这种关系。
而设备模型中的这种树状结构，可以自动处理这种依赖关系。启动某一个设备前，内核会检查该设备是否依赖其它设备或者总线，如果依赖，则检查所依赖的对象是否已经启动，如果没有，则会先启动它们，直到启动该设备的条件具备为止。而驱动开发人员需要做的，就是在编写设备驱动时，告知内核该设备的依赖关系即可。

4. 使用Class结构，在设备模型中引入面向对象的概念，这样可以最大限度地抽象共性，减少驱动开发过程中的重复劳动，降低工作量。