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/目录下设备的操作。