Linux 内核/sys 文件系统介绍1

sysfs 是 Linux 内核中设计较新的一种虚拟的基于内存的文件系统，它的作用与 proc 有些类似，但除了与 proc 相同的具有查看和设定内核参数功能之外，还有为 Linux 统一设备模型作为管理之用。相比于 proc 文件系统，使用 sysfs 导出内核数据的方式更为统一，并且组织的方式更好，它的设计从 proc 中吸取了很多教训。本文就 sysfs 的挂载点 /sys 目录结构、其与 Linux 统一设备模型的关系、常见属性文件的用法等方面对 sysfs 作介绍，并且就内核编程方面，以具体的例子来展示如何添加 sysfs 支持。

 sysfs 的历史，其与 proc 的关系？
sysfs 本身并不是一项很新的技术，但笔者发现，虽然 sysfs 从2003年诞生至今已有5年，但人们对 sysfs 依然缺乏了解；一个很重要的原因可能是缺乏文档， Linux 内核方面最重要的理论书籍“Linux 设备驱动第3版”和“理解 Linux 内核第2版”都诞生于2003年前后，并且从那以后尚未有再版过，其它一些重要文章则多对 sysfs 与 proc 相提并论且举例常常只有 proc，这导致了 sysfs 的很多重要概念至今仍鲜为人知，因此有必要对 sysfs 作更多介绍，这是写作本文的初衷。

    sysfs 与 /sys

    sysfs 文件系统总是被挂载在 /sys 挂载点上。虽然在较早期的2.6内核系统上并没有规定 sysfs 的标准挂载位置，可以把 sysfs 挂载在任何位置，但较近的2.6内核修正了这一规则，要求 sysfs 总是挂载在 /sys 目录上；针对以前的 sysfs 挂载位置不固定或没有标准被挂载，有些程序从 /proc/mounts 中解析出 sysfs 是否被挂载以及具体的挂载点，这个步骤现在已经不需要了。请参考附录给出的 sysfs-rules.txt 文件链接。

    sysfs 与 proc

    sysfs 与 proc 相比有很多优点，最重要的莫过于设计上的清晰。一个 proc 虚拟文件可能有内部格式，如 /proc/scsi/scsi ，它是可读可写的，(其文件权限被错误地标记为了 0444 ！，这是内核的一个BUG)，并且读写格式不一样，代表不同的操作，应用程序中读到了这个文件的内容一般还需要进行字符串解析，而在写入时需要先用字符串格式化按指定的格式写入字符串进行操作；相比而言， sysfs 的设计原则是一个属性文件只做一件事情， sysfs 属性文件一般只有一个值，直接读取或写入。整个 /proc/scsi 目录在2.6内核中已被标记为过时(LEGACY)，它的功能已经被相应的 /sys 属性文件所完全取代。新设计的内核机制应该尽量使用 sysfs 机制，而将 proc 保留给纯净的“进程文件系统”。

    初识 /sys

    清单 1. 与 /sys 文件系统的一次交互(视内核版本号和外接设备的不同，在您的系统上执行这些命令的结果可能与此有所不同)

  ls -F /sys
block/  bus/  class/  dev/  devices/  firmware/  fs/  kernel/  module/  power/
$ ls -F /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/
broken_parity_status  enable         modalias  resource0     rom               uevent
class                 irq            msi_bus   resource0_wc  subsystem@        vendor
config                local_cpulist  power/    resource1     subsystem_device
device                local_cpus     resource  resource2     subsystem_vendor

    这是在 Fedora 10 的 2.6.27.5-117.fc10.i686 的内核上，可以看到在 /sys 目录下有 block, bus, class, dev, devices, firmware, fs, kernel, module, power 这些子目录，本文将分别介绍这些目录存在的含义。

    第二个 ls 命令展示了在一个 pci 设备目录下的文件， "ls" 命令的 "-F" 命令为所列出的每个文件使用后缀来显示文件的类型，后缀 "/" 表示列出的是目录，后缀 "@" 表示列出的是符号链接文件。可以看到第二个目录下包含有普通文件 (regular file) 和符号链接文件 (symbolic link file) ，本文也将以这个具体的设备为例说明其中每一个普通文件的用途。 /sys 文件系统下的目录结构

    /sys 下的目录结构是经过精心设计的：在 /sys/devices 下是所有设备的真实对象，包括如视频卡和以太网卡等真实的设备，也包括 ACPI 等不那么显而易见的真实设备、还有 tty, bonding 等纯粹虚拟的设备；在其它目录如 class, bus 等中则在分类的目录中含有大量对 devices 中真实对象引用的符号链接文件； 清单1 中在 /sys 根目录下顶层目录的意义如下：

    表 1. /sys 下的目录结构

/sys 下的子目录	所包含的内容
/sys/devices	这是内核对系统中所有设备的分层次表达模型，也是 /sys 文件系统管理设备的最重要的目录结构，下文会对它的内部结构作进一步分析；
/sys/dev	这个目录下维护一个按字符设备和块设备的主次号码(major:minor)链接到真实的设备(/sys/devices下)的符号链接文件，它是在内核 2.6.26 首次引入；
/sys/bus	这是内核设备按总线类型分层放置的目录结构， devices 中的所有设备都是连接于某种总线之下，在这里的每一种具体总线之下可以找到每一个具体设备的符号链接，它也是构成 Linux 统一设备模型的一部分；
/sys/class	这是按照设备功能分类的设备模型，如系统所有输入设备都会出现在 /sys/class/input 之下，而不论它们是以何种总线连接到系统。它也是构成 Linux 统一设备模型的一部分；
/sys/block	这里是系统中当前所有的块设备所在，按照功能来说放置在 /sys/class 之下会更合适，但只是由于历史遗留因素而一直存在于 /sys/block, 但从 2.6.22 开始就已标记为过时，只有在打开了 CONFIG_SYSFS_DEPRECATED 下编译才会有这个目录的存在，并且在 2.6.26 内核中已正式移到 /sys/class/block, 旧的接口 /sys/block 为了向后兼容保留存在，但其中的内容已经变为指向它们在 /sys/devices/ 中真实设备的符号链接文件；
/sys/firmware	这里是系统加载固件机制的对用户空间的接口，关于固件有专用于固件加载的一套API，在附录 LDD3 一书中有关于内核支持固件加载机制的更详细的介绍；
/sys/fs	这里按照设计是用于描述系统中所有文件系统，包括文件系统本身和按文件系统分类存放的已挂载点，但目前只有 fuse,gfs2 等少数文件系统支持 sysfs 接口，一些传统的虚拟文件系统(VFS)层次控制参数仍然在 sysctl (/proc/sys/fs) 接口中中；
/sys/kernel	这里是内核所有可调整参数的位置，目前只有 uevent_helper, kexec_loaded, mm, 和新式的 slab 分配器等几项较新的设计在使用它，其它内核可调整参数仍然位于 sysctl (/proc/sys/kernel) 接口中 ;
/sys/module	这里有系统中所有模块的信息，不论这些模块是以内联(inlined)方式编译到内核映像文件(vmlinuz)中还是编译为外部模块(ko文件)，都可能会出现在 /sys/module 中： 编译为外部模块(ko文件)在加载后会出现对应的 /sys/module//, 并且在这个目录下会出现一些属性文件和属性目录来表示此外部模块的一些信息，如版本号、加载状态、所提供的驱动程序等； 编译为内联方式的模块则只在当它有非0属性的模块参数时会出现对应的 /sys/module/, 这些模块的可用参数会出现在 /sys/modules//parameters/ 中， 如 /sys/module/printk/parameters/time 这个可读写参数控制着内联模块 printk 在打印内核消息时是否加上时间前缀； 所有内联模块的参数也可以由 ".=" 的形式写在内核启动参数上，如启动内核时加上参数 "printk.time=1" 与 向 "/sys/module/printk/parameters/time" 写入1的效果相同； 没有非0属性参数的内联模块不会出现于此。
/sys/power	这里是系统中电源选项，这个目录下有几个属性文件可以用于控制整个机器的电源状态，如可以向其中写入控制命令让机器关机、重启等。
/sys/slab (对应 2.6.23 内核，在 2.6.24 以后移至 /sys/kernel/slab)	从2.6.23 开始可以选择 SLAB 内存分配器的实现，并且新的 SLUB（Unqueued Slab Allocator）被设置为缺省值；如果编译了此选项，在 /sys 下就会出现 /sys/slab ，里面有每一个 kmem_cache 结构体的可调整参数。对应于旧的 SLAB 内存分配器下的 /proc/slabinfo 动态调整接口，新式的 /sys/kernel/slab/ 接口中的各项信息和可调整项显得更为清晰。

    接下来对 /sys/devices/ 下的目录结构作进一步探讨：

    清单 2. 查看 /sys/devices/ 的目录结构

 

$ ls -F /sys/devices/
isa/  LNXSYSTM:00/  pci0000:00/  platform/  pnp0/  pnp1/  
system/  virtual/

    可以看到，在 /sys/devices/ 目录下是按照设备的基本总线类型分类的目录，再进入进去查看其中的 PCI 类型的设备：

    清单 3. 查看 /sys/devices/pci0000:00/ 的目录结构

 

$ ls -F /sys/devices/
isa/  LNXSYSTM:00/  pci0000:00/  platform/  
pnp0/  pnp1/  system/  virtual/

    在 /sys/devices/pci0000:00/ 目录下是按照 PCI 总线接入的设备号分类存放的目录，再查看其中一个，

    清单 4. 查看 /sys/devices/pci0000:00/ 的目录结构

 

$ ls -F /sys/devices/pci0000:00/0000:00:01.0/
0000:01:00.0/ device  local_cpus  power/   subsystem_vendor
broken_parity_status  enable   modalias resource    uevent
class     irq            msi_bus     subsystem@        vendor
config  local_cpulist  pci_bus/    subsystem_device

    可以看到，其中有一个目录 0000:01:00.0/, 其它都是属性文件和属性组，而如果对 0000:01:00.0/ 子目录中进行再列表查看则会得到 清单1 的目录结构。

    继续以上过程可以了解整个目录树的结构，这里把它整理成 图 1. sysfs 目录层次图

    图 1. sysfs 目录层次图

 

    其中涉及到 ksets, kobjects, attrs 等很多术语，这就不得不提到 Linux 统一设备模型。