学习深入Linux Sysfs编程与源码分析

运维 系统运维
从源代码中理解 Linux Sysfs 属性的用途更多的 Linux Sysfs 属性的功能只能靠阅读源代码来理解。还是以上文提到的 scsi_host 的 scan 属性来理解,这个功能没有任何文档上有描述,因此只能去读源代码。

Linux经过长时间的发展,很多用户都很了解Linux Sysfs了,本人很喜欢Linux Sysfs,下面就这个问题来详细说说吧。Linux Sysfs 源码分析和编程实践。Linux的发行遵守GNU(GNU is Not UNIX)的通用公共许可证,遵循公共版权许可证(GPL,General Public License),秉承“自由的思想,开放的源码”原则。

从源代码中理解 Linux Sysfs 属性的用途更多的 Linux Sysfs 属性的功能只能靠阅读源代码来理解。还是以上文提到的 scsi_host 的 scan 属性来理解,这个功能没有任何文档上有描述,因此只能去读源代码。

在内核中, Linux Sysfs属性一般是由 __ATTR 系列的宏来声明的,如对设备的使用 DEVICE_ATTR ,对总线使用 BUS_ATTR ,对驱动使用 DRIVER_ATTR ,对类别(class)使用 CLASS_ATTR, 这四个高级的宏来自于 , 都是以更低层的来自 中的 __ATTR/__ATRR_RO 宏实现; 因此我们在内核源码树中相应位置 drivers/scsi/ 找到这几个宏的使用情况,可以得到在 drivers/scsi/scsi_sysfs.c 中:
static ssize_t
store_scan(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
struct Scsi_Host *shost = class_to_shost(dev);
int res;
res = scsi_scan(shost, buf);
if (res == 0)
res = count;
return res;
static DEVICE_ATTR(scan, S_IWUSR, NULL, store_scan);

DEVICE_ATTR 宏声明有四个参数,分别是名称、权限位、读函数、写函数。这里对应的,名称是 scan, 权限是只有属主可写(S_IWUSR)、没有读函数、只有写函数。因此读写功能与权限位是对应的,因为 DEVICE_ATTR 把权限位声明与真正的读写是否实现放在了一起,减少了出现不一致的可能。(上文提到 /proc/scsi/scsi 接口的权限位声明与其功能不对应,这与注册 proc 接口的函数设计中的不一致是有关系的,权限位声明与功能实现不在代码中同一个位置,因此易出错。虽然修复 /proc/scsi/scsi 的权限位错误很容易,但内核团队中多年来一直没有人发现或未有人去修正这个 BUG,应该是与 /proc/scsi/ 接口的过时有关,过时的功能会在未来某个内核版本中去除。)

上面的 scan 属性写入功能是在 store_scan 函数中实现的,这个接口的四个参数中, buf/count 代表用户写入过来的字符串,它把 buf 进一步传给了 scsi_scan 函数;如果进一步分析 scsi_scan 函数实现可以知道,它期望从 buf 中接受三个或四个整型值(也接受"-"作为通配符),分别代表 host, channel, id 三个值,(第四个整数在早期内核中曾代表 lun 号码,但在较新内核中第四个数字被忽略,仅作为向后兼容保留接受四个整数),然后对具体的 (host, channel, id) 进行重新扫描以发现这个 SCSI 控制器上的设备变动。

添加 Linux Sysfs 支持

如果你正在开发的设备驱动程序中需要与用户层的接口,一般可选的方法有:
注册虚拟的字符设备文件,以这个虚拟设备上的 read/write/ioctl 等接口与用户交互;但 read/write 一般只能做一件事情, ioctl 可以根据 cmd 参数做多个功能,但其缺点是很明显的: ioctl 接口无法直接在 Shell 脚本中使用,为了使用 ioctl 的功能,还必须编写配套的 C语言的虚拟设备操作程序, ioctl 的二进制数据接口也是造成大小端问题 (big endian与little endian)、32位/64位不可移植问题的根源;
注册 proc 接口,接受用户的 read/write/ioctl 操作;同样的,一个 proc 项通常使用其 read/write/ioctl 接口,它所存在的问题与上面的虚拟字符设备的的问题相似;

注册 Linux Sysfs 属性;

最重要的是,添加虚拟字符设备支持和注册 proc 接口支持这两者所需要增加的代码量都并不少,***的方法还是使用 Linux Sysfs属性支持,一切在用户层是可见的透明,且增加的代码量是最少的,可维护性也***;方法就是使用 头文件提供的这四个宏,分别应用于总线/类别/驱动/设备四种内核数据结构对象上:
#define BUS_ATTR(_name, _mode, _show, _store)   \
struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show, _store)
#define CLASS_ATTR(_name, _mode, _show, _store) \
struct class_attribute class_attr_##_name = __ATTR(_name, _mode, _show, _store)
#define DRIVER_ATTR(_name, _mode, _show, _store)\
struct driver_attribute driver_attr_##_name =\
__ATTR(_name, _mode, _show, _store)
#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
 
总线(BUS)和类别(CLASS)属性一般用于新设计的总线和新设计的类别,这两者一般是不用的;因为你的设备一般是以PCI等成熟的常规方式连接到主机,而不会去新发明一种类型;使用驱动属性和设备属性的区别就在于:看你的 Linux Sysfs属性设计是针对整个驱动有效的还是针对这份驱动所可能支持的每个设备分别有效。

从头文件中还可以找到 show/store 函数的原型,注意到它和虚拟字符设备或 proc 项的 read/write 的作用很类似,但有一点不同是 show/store 函数上的 buf/count 参数是在Linux Sysfs 层已作了用户区/内核区的内存复制,虚拟字符设备上常见的 __user 属性在这里并不需要,因而也不需要多一次 copy_from_user/copy_to_user, 在 show/store 函数参数上的 buf/count 参数已经是内核区的地址,可以直接操作。
上面四种都是 Linux Sysfs 统一设备模型所添加的高级接口,如果使用 Linux Sysfs所提供的底层接口的话,则还有下面两个,定义来自 :(上面的总线/类别/驱动/设备四个接口都是以这里的__ATTR实现的)
#define __ATTR(_name,_mode,_show,_store) { \
.attr = {.name = __stringify(_name), .mode = _mode },   \
.show   = _show,  \
.store  = _store, \
#define __ATTR_RO(_name) { \
.attr   = { .name = __stringify(_name), .mode = 0444 }, \
.show   = _name##_show,\

上面这些宏都是在注册总线/类别/驱动/设备时作为缺省属性而使用的,在实际应用中还有一种情况是根据条件动态添加属性,如 PCI 设备上的 resource{0,1,2,...} 属性文件,因为一个 PCI 设备上的可映射资源究竟有多少无法预知,也只能以条件判断的方式动态添加上。
int __must_check sysfs_create_file(struct kobject *kobj,
const struct attribute *attr);
int __must_check sysfs_create_bin_file(struct kobject *kobj,struct bin_attribute *attr); 
这两个函数可以对一个 kobject 动态添加上文本属性或二进制属性,这也是唯一可以添加二进制属性的方法。

二进制属性与普通文本属性的区别在于二进制属性 struct bin_attribute 中内嵌一个 struct attribute 结构体对象,因此具有普通属性的所有功能特征;二进制属性上多一个 size 用来描述此二进制文件的大小,而普通属性文件的大小总是 4096, 准确地说,应该是一个内存页的大小,因为从当前 Linux Sysfs 内核实现来说,它分配一个内存页面来作为 (buf/count) 的缓冲区;二进制属性比普通属性多内存映射(mmap)接口的支持;

编程示例,对 LDD3 一书中的 lddbus 驱动程序的 Linux Sysfs 改进

首先,这个程序本身是针对当时作者写书的年代的内核(2.6.11)而编写的,在当前的 Fedora10 系统 (2.6.27.5-117.fc10.i686) 上甚至无法编译编译通过;因此首先需要将它移植过来至少达到可运行状态;附件的压缩包中含有修改过的 lddbus, sculld 的源代码和修改过程的四个patch:

***个 0001-ldd3-examples-build-on-fedora-10-2.6.27.5-117.fc10.i.patch 是将 lddbus 和 sculld 移植到 Fedora10 内核上可运行,这其中主要是一此内核 API 的变化;

第二个 0002-port-dmem-proc-entry-to-use-sysfs-entry.patch 演示了怎样将原有的 proc 接口改进成为 Linux Sysfs 属性接口的,从这个 patch 中可以看到删除的代码多而新增加的代码少,这说明对于相同的功能,使用 Linux Sysfs 编程接口的代码量更少,而且 sysfs 代码看起来也比 proc 更为整洁:打印每个设备的调试信息可以做成每个设备上分别有自己的接口,而不是统一的一个 proc 接口;设备属性文件最终出现的位置如 "/sys/devices/ldd0/sculld0/dmem"; static ssize_t sculld_show_dmem(struct device *ddev,
struct device_attribute *attr, char *buf)
/* 其中打印每个设备调试信息的代码复制自原proc接口 */
static DEVICE_ATTR(dmem, S_IRUGO, sculld_show_dmem, NULL);
static int __init sculld_register_dev(struct sculld_dev *dev, int index)
/* 创建此device属性文件 */
ret |= device_create_file(&dev->ldev.dev, &dev_attr_dmem);

第三个 0003-add-.gitignore.patch 是增加了 .gitignore 文件,屏蔽一些编译生成的临时文件;

第四个 0004-port-qset-get-set-ioctl-to-use-sysfs-entry.patch 演示了怎样把基于 ioctl 的操作接口改进成为基于 Linux Sysfs 接口,由于原来的 ioctl 接口设置和获取 qset 信息是表示整个驱动模块级的变量,它用来控制整个驱动程序而非驱动所支持的单个的设备,因此这个 qset 属性使用 DRIVER_ATTR 来添加更为合适; ssize_t sculld_show_qset(struct device_driver *driver, char *buf)
return snprintf(buf, PAGE_SIZE, "%d\n", sculld_qset);
ssize_t sculld_store_qset(struct device_driver *driver, const char *buf,
size_t count)sculld_qset = simple_strtol(buf, NULL, 0);return count;
/* 声明一个权限为0644的可同时读写的driver属性 */
static DRIVER_ATTR(qset, S_IRUGO | S_IWUSR, sculld_show_qset, sculld_store_qset);
/* 创建此driver属性文件 */
result = driver_create_file(&sculld_driver.driver, &driver_attr_qset);
驱动属性最终出现如 "/sys/bus/ldd/drivers/sculld/qset" ,这里声明的是同时可读写的,权限位 0644 与其保持一致。 6446 0 -rw-r--r-- 1 root root 4096 12月 14 07:44 /sys/bus/ldd/drivers/sculld/qset

【编辑推荐】

  1. 为你分析Linux操作系统和Windows系统
  2. 阐述Linux操作系统安装与认识支援的硬体
  3. 详解Linux操作系统中使用Windows分区
  4. Linux技术受风河与NEC垂青
  5. 多样性的Linux桌面
责任编辑:佚名 来源: CSDN
相关推荐

2009-12-22 13:26:03

Linux sysfs

2009-12-11 09:47:23

Linux内核源码进程调度

2009-12-11 09:42:54

Linux内核源码进程调度

2016-10-26 20:49:24

ReactJavascript前端

2024-04-29 09:06:46

线程初始化源码

2010-01-12 17:55:03

C++程序

2011-06-28 14:11:33

JavaScript

2009-12-22 13:05:15

Linux sysfs

2023-12-13 10:01:15

数据结构c++编程

2017-02-28 18:26:09

Linuxinput子系统编程

2009-06-16 10:51:14

Java源码

2024-10-14 13:30:20

2010-03-08 14:53:48

Linux分区

2023-03-15 21:46:17

中间件Java网络编程

2018-10-31 15:54:47

Java线程池源码

2009-07-03 11:14:57

2016-10-21 13:03:18

androidhandlerlooper

2021-09-08 10:47:33

Flink执行流程

2009-12-22 12:14:11

Linux内核

2019-07-08 20:00:35

Linux内核模块
点赞
收藏

51CTO技术栈公众号