linux 设备模型（一）
随着linux系统越来越成熟，与设备驱动相关的一些新的特性需要加入，而之前独立的设备及其驱动程序能有效地沟通起来，linux2.6内核最初为了应付电源管理的需要，提出了一个设备模型来管理所有的设备。在物理上，外设之间是有一种层次的关系，例如把一个U盘插在电脑的usb接口，实际上这个U盘是挂在usb hub上，usb hub又是连接在usb2.0 Host control上，usb2.0 Host最终挂在PCI Bus总线上。这个设备的物理层次关系如下：PCI –>usb2.0 Host control –>usb hub –>usb disk 。假设，电脑一段时间没有任何操作，系统将进入休眠状态，那么系统首先需要逐层通知外设进入休眠模式，然后整个系统才可以休眠。所以，需要一个树状的结构把所有的外设组织起来，这就是最初建立linux设备模型的目的（应付电源管理的需要）。在分析linux设备模型时，应抓住一个关键的本质，linux设备模型给系统带来了什么好处，为什么要提出这个概念？
因此，linux设备模型 首要的目的就是为设备和驱动建立一个树状的模型。这样的结果带来了更多的便利，用户可以通过这棵树遍历所有的设备，建立设备与驱动的联系，根据设备的不同可以从更高层次对设备进行归类，这样就可以更清晰的去“看”这可大树。另外，linux设备模型把很多设备共有的一些操作抽象出来，这样带来的好处减少重复着轮子的可能。在设计linux设备模型后，同时得到了一个非常方便的副产品---sysfc虚拟文件系统。sys给用户提供了一个从用户空间去访问内核设备的方法，这个文件系统只存在RAM中，系统启动后才会生成。
sysfs 文件系统的目录架构
sysfs被加载在/sys的目录下，它的子目录包括：
block： 在系统中发现的每个块设备在该目录下对应一个子目录。每个子目录中有包含一些属性文件，它们描述了这个块设备的各方面的属性
bus： 在内核中注册的每条总线在该目录下对应一个子目录，如pci， usb i2c paltform等。其中在每个总线目录里面又包含两个子目录
devices 和drivers：devices目录包含了整个系统中发现属于该总线类型的设备
driver 目录包含了注册到该总线的所有驱动
class： 将设备按照功能进行分类
devices： 包含系统所有的设备
kernel： 内核中的配置参数
module： 系统中所有模块的信息
firmware： 系统中的固件、
fs： 描述系统中的文件系统
power： 系统中电源选项
这里有9个目录，这里并不说9个目录代表了9中不同的设备类型，实际上这9个目录是给我们提供了如何去看设备模型的不同视角。从不同的目录出发都有可能找到同一个设备。linux的所有设备都可以在这个目录中找到，从其它目录（从另外一个视角）找到它是指向这里的一个链接。这里是一个大杂烩，虽然五脏俱全但我们却无从下手。这里还是以U盘为例，插上U盘之后，在devices目录里如何找到这支U盘呢？真得很难办到！！！但是如果透过block目录，我们很容易就可以找到这个U盘设备，符号链接device正是指向devices目录下的位置。现在，总结一下/sys目录下各个子目录的作用。block目录是从块设备的角度来组织设备；bus目录是从系统总线这个角度来组织设备，比如PCI总线或者USB总线；class目录把看问题的视角提高到了类别的高度，比如PCI设备或者USB设备等；dev目录的视角是设备节点；devices目录在前面提到了，这里是所有设备的大本营；firmware目录包含了一些比较低阶的子系统，比如ACPI、EFI等；fs目录里看到的是系统支持的所有文件系统；kernel目录下包含的是一些内核的配置选项；modules目录下包含的是所有内核模块的信息，内核模块实际上和设备之间是有对应关系的，通过这个目录顺藤摸瓜找到devices或者反过来都是可以做到的；power目录存放的是系统电源管理的数据，用户可以通过它来查询目前的电源状态，甚至可以直接“命令”系统进入休眠等省电模式。sysfs正是用户和内核设备模型之间的一座桥梁，通过这个桥梁我们可以从内核中读取信息，也可以向内核里写入信息。
如果要写程序来访问sysfs，可以像读写普通文件一样来操作/sys目录下的文件，或者，也可以使用libsysfs。不过需要注意的是，Linux内核社区并不推荐用libsysfs，因为这个API的更新不够快，赶不上内核的变化。libsysfs已经逐渐背离最初创建它的目标，这个lib带来的问题似乎比它解决的还要多。当然，如果只是要访问设备，一般很少会直接操作sysfs，它太细节太底层了，大部分情况下可以使用更加方便的DeviceKit或者libudev。
