linux监控sysfs,linux设备模型之sysfs使用

前面几篇文章已经相对详细的描述了linux设备模型，linux设备模型本质上是把设备安装虚拟的总线、设备、驱动、类这些“概念性”的东西模型化了一下，使对设备和驱动的管理有了面向对象的感觉；对这一切的底层结构实现也做了描述，把握住kobject、kset等结构类型即可对linux设备模型的底层实现有更清晰的把握，能真正理解这些bus、device、driver、class到底是互相什么关系。

linux设备模型的底层实现的结果是在/sys目录下的一级级的各种目录，这在客观上就衍生出了sysfs文件系统，所以经常会说sysfs文件系统是针对设备模型的，实际上sysfs文件系统是linux设备模型的衍生产物。

由前面的文章能发现，sysfs下不一定所有设备都必须得对应驱动，很多设备和驱动都是仅仅为了调试用的，可以对某些文件进行读或者写操作来改变想要查看或修改的内容，换句话说，用户从shell下想要直接查看或修改内核(设备驱动)的一些参数，sysfs就是用户和内核之间的桥梁，这非常类似proc，只是proc更多用于查看或修改内核进程参数。

现在切入本文主要内容，如何使用sysfs，还是从例子入手：

int __devinit gpon_sysfs_init(void)

{

int err;

struct device *pd;

//在platform总线下建立一个设备，叫“gpon”

pd = bus_find_device_by_name(&platform_bus_type, NULL, "gpon");

if (!pd) {

//第一参数是名字；第二参数是序号；第三参数是资源；第四参数是资源个数

platform_device_register_simple("gpon", -1, NULL, 0);

pd = bus_find_device_by_name(&platform_bus_type, NULL, "gpon");

}

//在gpon设备的目录下，建立一个属性组

err = sysfs_create_group(&pd->kobj, &gpon_pm_group);

if (err) {

printk(KERN_INFO "sysfs group failed %d\n", err);

goto out;

}

……………………………….

}

上面首先在platform总线下创建一个设备叫gpon，然后在gpon设备的kobject即gpon目录下创建一个属性组gpon_pm_group，属性组的重要成员是name和attrs，分别是名字和属性，名字意味着将以此命名的目录出现在gpon目录下，属性代表实际的可读或可写的属性内容；这里全局变量gpon_pm_group如下：

static struct attribute_group gpon_pm_group ={

//名字为pm，以这个名字命名的目录将出现在gpon目录下

.name = "pm",

//这是实际的属性内容，全局变量gpon_pm_attrs

.attrs = gpon_pm_attrs,

};

重点内容是属性内容，观察全局变量gpon_pm_attrs；

static DEVICE_ATTR(fecCnt,        S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(rxPloamCnt,    S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(txPloamCnt,    S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(bwMapCnt,      S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(stdCnt,        S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(gemCnt,        S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(txPktCnt,      S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(rawCnt_1,      S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(rawCnt_2,      S_IRUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(cntRdClrFlState,S_IWUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(bwMapCntByState,S_IWUSR, gpon_pm_show, gpon_pm_store);

static DEVICE_ATTR(helpGPm,       S_IRUSR, gpon_pm_show, gpon_pm_store);

static struct attribute *gpon_pm_attrs[] = {

&dev_attr_fecCnt.attr,

&dev_attr_rxPloamCnt.attr,

&dev_attr_txPloamCnt.attr,

&dev_attr_bwMapCnt.attr,

&dev_attr_stdCnt.attr,

&dev_attr_gemCnt.attr,

&dev_attr_txPktCnt.attr,

&dev_attr_rawCnt_1.attr,

&dev_attr_rawCnt_2.attr,

&dev_attr_cntRdClrFlState.attr,

&dev_attr_bwMapCntByState.attr,

&dev_attr_helpGPm.attr,

NULL

};

终于到这里了，现在说一下DEVICE_ATTR，事实上不仅有DEVICE_ATTR，还有DRIVER_ATTR、 BUS_ATTR、CLASS_ATTR，这四个宏函数都定义在内核源码的/include/linux/device.h文件中，可以看到它们的定义差不多，以DEVICE_ATTR为例：

struct driver_attribute {

struct attribute attr;

ssize_t (*show)(struct device_driver *driver, char *buf);

ssize_t (*store)(struct device_driver *driver, const char *buf,

size_t count);

};

#define DRIVER_ATTR(_name, _mode, _show, _store) \

struct driver_attribute driver_attr_##_name =  \

__ATTR(_name, _mode, _show, _store)

可见，四个参数分别是_name、_mode、_show、_store，分别对应含义名称、文件读写权限、读方法、写方法；所以上面的一系列DEVICE_ATTR宏函数，就是定义了一系列文件的名称、读写权限、读方法、写方法；而底下的“struct attribute *gpon_pm_attrs[]”就是sysfs下的实际接口文件实现了，具体方式举例如：

static DEVICE_ATTR(fecCnt, S_IRUSR,  gpon_pm_show,  gpon_pm_store);

static struct attribute *gpon_pm_attrs[] = {

&dev_attr_fecCnt.attr,

………………………..

如果是设备的属性，那么在该属性的名字前面加入“dev_attr_”，在后面加入后缀“.attr”，如果是总线、类、驱动的属性，则应该是bus_attr/class_attr/drv_attr；

该文件的读方法就是第三参数即gpon_pm_show，写方法就是第四参数gpon_pm_store，如果希望该属性代表的内容是只读，那么就如第二参数S_IRUSR把文件权限设为只读，如果是希望该属性是只写，那就应该设置第二参数为S_IWUSR，若希望可读可写，则应该设置为S_IRUSR | S_IWUSR；

举例如下：

首先读取SN，值为12345678；这是个只读的属性；

/ # cat sys/bus/platform/devices/gpon/info/infoGpon

ONT Full Information:

---------------------

SN[VENDOR ID]:                 12:34:56:78 [4Vx]

然后设置SN，值为87654321；这是另一个只写的属性；

/ # echo 87654321 > /sys/bus/platform/devices/gpon/misc/serialNumCfg

最后再查看SN，值变为87654321，修改成功！

/ # cat sys/bus/platform/devices/gpon/info/infoGpon

ONT Full Information: --------------------- SN[VENDOR ID]:                 87:65:43:21 [噀C!] 也许会奇怪，为什么上面这么多的属性文件，都使用同样的读方法和写方法呢，这个完全得靠读方法还是或写方法还是自己去区分了，如我这里的方式就是大量的if else if…..来判断属性的name进而调用不同的处理函数。 最后总结一个我暂时的小经验的感觉，就sysfs本身来讲，也许更大的作用就是在shell上调试，类似proc的作用；而真正在代码里控制驱动的，依然是对/dev/目录下设备的操作。