驱动篇：sysfs 文件系统与 Linux 设备模型

驱动篇：sysfs 文件系统与 Linux 设备模型

Linux 2.6 以后的内核引入了 sysfs 文件系统, sysfs 被看成是与 proc 、 devfs 和 devpty 同类别的文件系统,该文件系统是一个虚拟的文件系统,它可以产生一个包括所有系统硬件的层级视图,与提供进程和状态信息的 proc 文件系统十分类似。

sysfs 把连接在系统上的设备和总线组织成为一个分级的文件,它们可以由用户空间存取,向用户空间导出内核数据结构以及它们的属性。sysfs 的一个目的就是展示设备驱动模型中各组件的层次关系,其顶级目录包括 block 、 bus 、 dev 、 devices 、 class 、 fs 、 kernel 、 power 和 firmware等。

block 目录包含所有的块设备; devices 目录包含系统所有的设备,并根据设备挂接的总线类型组织成层次结构; bus 目录包含系统中所有的总线类型; class 目录包含系统中的设备类型(如网卡设备、声卡设备、输入设备等)。在 /sys 目录下运行 tree 会得到一个相当长的树形目录

在 /sys/bus 的 pci 等子目录下,又会再分出 drivers 和 devices 目录,而 devices 目录中的文件是对 /sys/devices 目录中文件的符号链接。同样地, /sys/class 目录下也包含许多对 /sys/devices 下文件的链接。


随着技术的不断进步,系统的拓扑结构越来越复杂,对智能电源管理、热插拔以及即插即用的支持要求也越来越高, Linux 2.4 内核已经难以满足这些需求。为适应这种形势的需要, Linux 2.6 以后的内核开发了上述全新的设备、总线、类和驱动环环相扣的设备模型Linux 设备模型与设备、驱动、总线和类的现实状况是直接对应的,也正符合 Linux 2.6 以后内核的设备模型。

大多数情况下, Linux 2.6 以后的内核中的设备驱动核心层代码作为 “ 幕后大佬 ” 可处理好这些关系,内核中的总线和其他内核子系统会完成与设备模型的交互,这使得驱动工程师在编写底层驱动的时候几乎不需要关心设备模型,只需要按照每个框架的要求, “ 填鸭式 ” 地填充xxx_driver 里面的各种回调函数, xxx 是总线的名字。

在 Linux 内核中,分别使用 bus_type 、 device_driver 和 device 来描述总线、驱动和设备

device_driver 和 device 分别表示驱动和设备,而这两者都必须依附于一种总线,因此都包含 struct bus_type 指针。
在 Linux 内核中,设备和驱动是分开注册的,注册 1 个设备的时候,并不需要驱动已经存在,而 1 个驱动被注册的时候,也不需要对应的设备已经被注册。设备和驱动各自涌向内核,而每个设备和驱动涌入内核的时候,都会去寻找自己的另一半,而正是 bus_type 的 match ()成员函数将两者捆绑在一起。简单地说,设备和驱动就是红尘中漂浮的男女,而 bus_type 的 match ()则是牵引红线的月老,它可以识别什么设备与什么驱动是可配对的。一旦配对成功, xxx_driver 的 probe ()就被执行( xxx 是总线名,如 platform 、 pci 、 i2c 、 spi 、 usb 等)。

总线、驱动和设备最终都会落实为 sysfs 中的 1 个目录,因为进一步追踪代码会发现,它们实际上都可以认为是 kobject 的派生类, kobject 可看作是所有总线、设备和驱动的抽象基类, 1 个 kobject 对应 sysfs 中的 1 个目录。总线、设备和驱动中的各个 attribute 则直接落实为 sysfs 中的 1 个文件, attribute 会伴随着 show ()和 store ()这两个函数,分别用于读写该attribute 对应的 sysfs 文件。