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 属性文件所xx取代。新设计的内核机制应该尽量使用 sysfs 机制，而将 proc 保留给纯净的“进程文件系统”。

    初识 /sys

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

    这是在 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/devices/ 下的目录结构作进一步探讨：

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

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

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

    在 /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 统一设备模型。

Linux 统一设备模型

    在 Linux 2.5 内核的开发过程中，人们设计了一套新的设备模型，目的是为了对计算机上的所有设备进行统一地表示和操作，包括设备本身和设备之间的连接关系。这个模型是在分析了 PCI 和 USB 的总线驱动过程中得到的，这两个总线类型能代表当前系统中的大多数设备类型，它们都有完善的热挺拔机制和电源管理的支持，也都有级连机制的支持，以桥接的 PCI/USB 总线控制器的方式可以支持更多的 PCI/USB 设备。为了给所有设备添加统一的电源管理的支持，而不是让每个设备中去独立实现电源管理的支持，人们考虑的是如何尽可能地重用代码；而且在有层次模型的 PCI/USB 总线中，必须以合理形式展示出这个层次关系，这也是电源管理等所要求的必须有层次结构。

    如在一个典型的 PC 系统中，中央处理器(CPU)能直接控制的是 PCI 总线设备，而 USB 总线设备是以一个 PCI 设备(PCI-USB桥)的形式接入在 PCI 总线设备上，外部 USB 设备再接入在 USB 总线设备上；当计算机执行挂起(suspend)操作时， Linux 内核应该以 “外部USB设备->USB总线设备->PCI总线设备” 的顺序通知每一个设备将电源挂起；执行恢复(resume)时则以相反的顺序通知；反之如果不按此顺序则将有设备得不到正确的电源状态变迁的通知，将无法正常工作。

    sysfs 是在这个 Linux 统一设备模型的开发过程中的一项副产品(见 参考资料 中 Greg K. Hartman 写作的 LinuxJournal 文章)。为了将这些有层次结构的设备以用户程序可见的方式表达出来，人们很自然想到了利用文件系统的目录树结构（这是以 UNIX 方式思考问题的基础，一切都是文件！）在这个模型中，有几种基本类型，它们的对应关系见 表 2. Linux 统一设备模型的基本结构 ：

    表 2. Linux 统一设备模型的基本结构

    从内核在实现它们时所使用的数据结构来说， Linux 统一设备模型又是以两种基本数据结构进行树型和链表型结构组织的：

    kobject: 在 Linux 设备模型中最基本的对象，它的功能是提供引用计数和维持父子(parent)结构、平级(sibling)目录关系，上面的 device, device_driver 等各对象都是以 kobject 基础功能之上实现的；

struct kobject {
        const char              *name;
        struct list_head        entry;
        struct kobject          *parent;
        struct kset             *kset;
        struct kobj_type        *ktype;
        struct sysfs_dirent     *sd;
        struct kref             kref;
        unsigned int state_initialized:1;
 unsigned int state_in_sysfs:1;
        unsigned int state_add_uevent_sent:1;
        unsigned int state_remove_uevent_sent:1;
};

    其中 struct kref 内含一个 atomic_t 类型用于引用计数， parent 是单个指向父节点的指针， entry 用于父 kset 以链表头结构将 kobject 结构维护成双向链表；

    kset: 它用来对同类型对象提供一个包装集合，在内核数据结构上它也是由内嵌一个 kboject 实现，因而它同时也是一个 kobject (面向对象 OOP 概念中的继承关系) ，具有 kobject 的全部功能；

    其中的 struct list_head list 用于将集合中的 kobject 按 struct list_head entry 维护成双向链表；

    涉及到文件系统实现来说， sysfs 是一种基于 ramfs 实现的内存文件系统，与其它同样以 ramfs 实现的内存文件系统(configfs,debugfs,tmpfs,...)类似， sysfs 也是直接以 VFS 中的 struct inode 和 struct dentry 等 VFS 层次的结构体直接实现文件系统中的各种对象；同时在每个文件系统的私有数据 (如 dentry->d_fsdata 等位置) 上，使用了称为 struct sysfs_dirent 的结构用于表示 /sys 中的每一个目录项。

struct sysfs_dirent {
        atomic_t                s_count;
        atomic_t                s_active;
        struct sysfs_dirent     *s_parent;
        struct sysfs_dirent     *s_sibling;
        const char              *s_name;

        union {
                struct sysfs_elem_dir           s_dir;
                struct sysfs_elem_symlink       s_symlink;
                struct sysfs_elem_attr          s_attr;
                struct sysfs_elem_bin_attr      s_bin_attr;
        };

        unsigned int            s_flags;
        ino_t                   s_ino;
        umode_t                 s_mode;
        struct iattr            *s_iattr;
};

    在上面的 kobject 对象中可以看到有向 sysfs_dirent 的指针，因此在sysfs中是用同一种 struct sysfs_dirent 来统一设备模型中的 kset/kobject/attr/attr_group.

    具体在数据结构成员上， sysfs_dirent 上有一个 union 共用体包含四种不同的结构，分别是目录、符号链接文件、属性文件、二进制属性文件；其中目录类型可以对应 kobject，在相应的 s_dir 中也有对 kobject 的指针，因此在内核数据结构， kobject 与 sysfs_dirent 是互相引用的；

    有了这些概念，再来回头看 图 1. sysfs 目录层次图 所表达的 /sys 目录结构就是非常清晰明了:

    在 /sys 根目录之下的都是 kset，它们组织了 /sys 的顶层目录视图；
    在部分 kset 下有二级或更深层次的 kset；
    每个 kset 目录下再包含着一个或多个 kobject，这表示一个集合所包含的 kobject 结构体；
    在 kobject 下有属性(attrs)文件和属性组(attr_group)，属性组就是组织属性的一个目录，它们一起向用户层提供了表示和操作这个 kobject 的属性特征的接口；
    在 kobject 下还有一些符号链接文件，指向其它的 kobject，这些符号链接文件用于组织上面所说的 device, driver, bus_type, class, module 之间的关系；
    不同类型如设备类型的、设备驱动类型的 kobject 都有不同的属性，不同驱动程序支持的 sysfs 接口也有不同的属性文件；而相同类型的设备上有很多相同的属性文件；
    注意，此表内容是按照{zx1}开发中的 2.6.28 内核的更新组织的，在附录资源如 LDD3 等位置中有提到 sysfs 中曾有一种管理对象称为 subsys (子系统对象)，在{zx1}的内核中经过重构认为它是不需要的，它的功能xx可以由 kset 代替，也就是说 sysfs 中只需要一种管理结构是 kset，一种代表具体对象的结构是 kobject，在 kobject 下再用属性文件表示这个对象所具有的属性；

常见 sysfs 属性的功能

    使用 sysfs 的关键就是掌握这些 sysfs 属性的用法，下面以一些常见的 sysfs 属性来展示它的用法；

    使用设备(PCI)的 sysfs 属性文件

    以一份桌面系统上的视频卡为例，列举它对应的 kobject 上的属性文件的对应用途；

    一般来说，在 Linux 桌面上都有视频卡以支持 Xorg 软件包作为 XWindow 来运行，因此先找到 Xorg 的进程号，查看这个进程所使用的所有文件（注意查看这个进程属性需要 root 用户权限）；

# ps xfa |grep Xorg
 2001 tty1     Ss+    2:24      \_ /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-NPrkZK/database -nolisten tcp vt1
# lsof -nP -p 2001
Xorg    2001 root  mem    REG        8,3    617732     231033 /usr/lib/xorg/modules/drivers/sis_drv.so
[...]
Xorg    2001 root  mem    REG        0,0 134217728       5529 /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource0
Xorg    2001 root  mem    REG        0,0    131072       5531 /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource1
[...]
Xorg    2001 root    7u   REG        0,0       256       5504 /sys/devices/pci0000:00/0000:00:00.0/config
Xorg    2001 root    8u  unix 0xdbe66000       0t0       8756 socket
Xorg    2001 root    9u   REG        0,0       256       5528 /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/config

    注意到此 Xorg 是以内存映射 (mem) 的形式打开了 "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource0" 和 "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/resource1" ，同时以文件读写形式 (7u,9u) 打开了 "/sys/devices/pci0000:00/0000:00:00.0/config" 和 "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/config"

    事实上， PCI 设备对应的 kobject 目录下的 config 正是代表PCI设备的“配置空间”，对于普通 PCI (非PCI-E)设备而言，其配置空间大小一般是 256字节，这个空间可以使用十六进制工具 dump 出来，如下。(有关 PCI 设备本身的三种地址空间，请参考附录 LDD3)

# hexdump -C /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/config
00000000  39 10 30 63 03 00 30 02  00 00 00 03 00 00 00 80  |9.0c..0.........|
00000010  08 00 00 d8 00 00 00 e1  01 d0 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 19 10 30 1b  |..............0.|
00000030  00 00 00 00 40 00 00 00  00 00 00 00 00 00 00 00  |....@...........|
00000040  01 50 02 06 00 00 00 00  00 00 00 00 00 00 00 00  |.P..............|
00000050  02 00 30 00 0b 02 00 ff  00 00 00 00 00 00 00 00  |..0.............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100

    这个空间正好是 256字节大小，熟悉 PCI 的人们还可以知道，从 PCI 配置空间可以读到有关此 PCI 设备的很多有用信息，如厂商代码，设备代码，IRQ 号码等；前四个字节 0x39 0x10 0x30 0x63 就是按小端(little endian)存放的2个短整数，因此其 PCI 厂商号码和 PCI 设备号码分别是 0x1039 和 0x6330

# lspci -v -d 1039:6330
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter (prog-if 00 [VGA controller])
 Subsystem: Elitegroup Computer Systems Device 1b30
 Flags: 66MHz, medium devsel
 BIST result: 00
 Memory at d8000000 (32-bit, prefetchable) [size=128M]
 Memory at e1000000 (32-bit, non-prefetchable) [size=128K]
 I/O ports at d000 [size=128]
 Capabilities: [40] Power Management version 2
 Capabilities: [50] AGP version 3.0

    在 PCI 设备上除了有 config 是配置空间对用户的接口以外，还有 resource{0,1,2,...} 是资源空间，对应着 PCI 设备的可映射内存空间；此外 PCI 设备还提供了很多接口，全部列表如下：

# ls -lU /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/
总计 0
-rw-r--r-- 1 root root      4096 12-09 00:28 uevent
-r--r--r-- 1 root root      4096 12-09 00:27 resource
-r--r--r-- 1 root root      4096 12-09 00:27 vendor
-r--r--r-- 1 root root      4096 12-09 00:27 device
-r--r--r-- 1 root root      4096 12-09 00:28 subsystem_vendor
-r--r--r-- 1 root root      4096 12-09 00:28 subsystem_device
-r--r--r-- 1 root root      4096 12-09 00:27 class
-r--r--r-- 1 root root      4096 12-09 00:27 irq
-r--r--r-- 1 root root      4096 12-09 00:28 local_cpus
-r--r--r-- 1 root root      4096 12-09 00:28 local_cpulist
-r--r--r-- 1 root root      4096 12-09 00:28 modalias
-rw------- 1 root root      4096 12-09 00:28 enable
-rw-r--r-- 1 root root      4096 12-09 00:28 broken_parity_status
-rw-r--r-- 1 root root      4096 12-09 00:28 msi_bus
lrwxrwxrwx 1 root root         0 12-09 00:28 subsystem -> ../../../../bus/pci
drwxr-xr-x 2 root root         0 12-09 00:28 power
-rw-r--r-- 1 root root       256 12-08 23:03 config
-rw------- 1 root root 134217728 12-08 23:03 resource0
-rw------- 1 root root 134217728 12-09 00:28 resource0_wc
-rw------- 1 root root    131072 12-08 23:03 resource1
-rw------- 1 root root       128 12-09 00:28 resource2
-r-------- 1 root root         0 12-09 00:28 rom

    可以看到很多其它属性文件，这些属性文件的权限位也都是正确的，有 w 权限位的才是可以写入。其中大小为 4096字节的属性一般是纯文本描述的属性，可以直接 cat 读出和用 echo 字符串的方法写入；其它非 4096字节大小的一般是二进制属性，类似于上面的 config 属性文件；关于纯文本属性和二进制属性，在下文 编程实践：添加sysfs支持 一节会进一步说明。

    从 vendor, device, subsystem_vendor, subsystem_device, class, resource 这些只读属性上分别可以读到此 PCI 设备的厂商号、设备号、子系统厂商号、子系统设备号、PCI类别、资源表等，这些都是相应 PCI 设备的属性，其实就是直接从 config 二进制文件读出来，按照配置空间的格式读出这些号码；
    使用 enable 这个可写属性可以禁用或启用这个 PCI 设备，设备的过程很直观，写入1代表启用，写入0则代表禁用；
    subsystem 和 driver 符号链接文件分别指向对应的 sysfs 位置；(这里缺少 driver 符号链接说明这个设备当前未使用内核级的驱动程序)
    resource0, resource0_wc, resource1, resource2 等是从"PCI 配置空间"解析出来的资源定义段落分别生成的，它们是 PCI 总线驱动在 PCI 设备初始化阶段加上去的，都是二进制属性，但没有实现读写接口，只支持 mmap 内存映射接口，尝试进行读写会提示 IO 错误，其中 _wc 后缀表示 "合并式写入(write combined)" ，它们用于作应用程序的内存映射，就可以访问对应的 PCI 设备上相应的内存资源段落；
    有了 PCI 核心对 sysfs 的完善支持，每个设备甚至不用单独的驱动程序，如这里的 "0000:01:00.0" 不需要一个内核级的驱动程序，有了 PCI 核心对该设备的配置空间发现机制，可以自动发现它的各个不同段落的资源属性，在 Xorg 应用程序中可以直接以 "/usr/lib/xorg/modules/drivers/sis_drv.so" 这个用户空间的驱动程序对其进行映射，就可以直接操作此视频卡了；

    有了这一个 PCI 设备的示例可以知道，有了一个 PCI 设备的 /sys/devices/ 设备对象，去访问它的各项属性和设置属性都非常简单。

本文转自：