sysfs--初窥门径

好文：http://www.ibm.com/developerworks/cn/linux/l-cn-sysfs/
先来看下怎么用sysfs，再去分析原理。以2.6.30内核中led的使用为例，因为我常用的3.2.0感觉不如这个版本清楚
涉及到文件 class.c led-class.c leds-s3c24xx.c

先来看用户空间怎么控制Led灯
点灯：echo 1 > /sys/class/leds/led0/brightness
灭灯：echo 0 > /sys/class/leds/led0/brightness
下面我们就来看看sysfs是如何一步步产生了这些操作结点的

/sys目录我们先略过，这肯定是sysfs核心产生的。我们分析sys里边的内容如何产生，
过程中凡是涉及到sysfs核心的东西都先略过，后期再分析。
先来看一下sys目录：# ls /sys -F 加了-F选项会显示出文件类型
block/ class/ devices/ fs/ module/
bus/ dev/ firmware/ kernel/ power/
对于各个目录的作用，在《深入理解linux内核》设备驱动模型一节和上面网址中都有介绍。
现在按照上面的例子，先来看看class目录的产生。
1.在…/driver/base/class.c中。

classes_init(void)    class_kset = kset_create_and_add("class", NULL, NULL);

看一下kset_create_and_add的原型：
static struct kset *kset_create(const char *name, struct kset_uevent_ops *uevent_ops, struct kobject *parent_kobj)
第一个是名字，第二个略过不说，第三个是父类容器
从形参看，第三个参数是NULL，所以class是没有父类容器的，所以class目录会出现在/sys的底层目录
好了，/sys/class出现了，我们不再往下深入，只是理清大体流程。

2.那么如何在class目下下产生其它节点内？
熟悉Linux分层设计思想的肯定一下就能想到，既然是在class目录下产生节点，肯定是由class核心来统一管理了。
没错，就是这样，class提供了一个注册函数__class_create供外部使用，这个函数又被device.h重新封装为class_create
class_create这个函数相信只要写过字符设备的人都很熟悉，在调用device_create之前通常会先调用class_create产生类。
好了，接下来我们就看看内核自带的Led驱动是怎么做的。

leds_init(void)    leds_class = class_create(THIS_MODULE, "leds");  //这个调用，就在/sys/class下产生了leds目录    leds_class->suspend = led_suspend;    leds_class->resume = led_resume;    

这里要多提一点，如果我们平时写个led驱动会怎么做呢？通常大部分人会直接在同一个文件中调用
class_create和device_create，或者注册成为misc设备。这样并没有什么不妥，但是内核的做法更
符合软件分层设计思想。把led共性抽出来，注册为一个leds类，然后由led_class.c统一管理。
然后所有的平台相关的设备再通过led_class.c提供的接口把具体的设备注册到leds目录里边。
是不是一层层的非常清楚明了。这就是内核魅力所在。到这里，就产生了/sys/class/leds目录。

led-class.c就是整个led子系统的核心了，下面我们就从led_classdev_register来分析，
详细看下led类是如何利用sysfs实现相应功能的。

led_classdev_register(struct device *parent, struct led_classdev *led_cdev)  //...drivers/leds/led-class.c    led_cdev->dev = device_create(leds_class, parent, 0, led_cdev, "%s", led_cdev->name);    device_create_file(led_cdev->dev, &dev_attr_brightness);    device_create_file(led_cdev->dev, &dev_attr_max_brightness);    device_create_file(led_cdev->dev, &dev_attr_trigger);

形参有两个，一个是parent，一个是led_classdev结构体指针
parent通常指向platform平台设备的私有数据，这个可以先不用管，后边用处也不大
第二个参数就是Led核心提供的led设备抽象，可以参考下文来了解
http://blog.csdn.net/yuanlulu/article/details/6438841

然后就是我们熟悉的device_create函数了，都知道是在/dev目录下生成相应的设备结点。
而且会让led_cdev->dev和led核心维护的leds_class建立联系，为后边的device_create_file做准备。
接下来就是最重要的三个device_create_file调用，这个函数是sysfs核心提供的，通过调用它，
就可以生成设备的属性，也就是在用户空间操作的属性。
比如上面的device_create_file(led_cdev->dev, &dev_attr_brightness)调用
就会在/sys/class/leds/led0目录下产生brightness属性，而我们用
echo 1 > /sys/class/leds/led0/brightness命令即可实现点灯
cat /sys/class/leds/led0/brightness就可以查看灯的状态

sysfs具体做了什么暂时不分析，但是大体能够猜到，调用device_create_file函数就会导致
sysfs核心为这个属性建立相应的目录，并且绑定相应的读写方法。
那么对于led的操作方法是什么呢？在led-class.c中搜dev_attr_brightness你会发现是搜不到的，
这是因为它被定义成了一个宏函数DEVICE_ATTR，这也是sysfs核心提供的。代码中有这么一句：
static DEVICE_ATTR(brightness, 0644, led_brightness_show, led_brightness_store);
把这个宏展开就是：

static struct device_attribute dev_attr_brightness = { \    .attr = {.brightness = __stringify(brightness), .mode = 0644 }, \    .show   = led_brightness_show,                  \    .store  = led_brightness_store,                 \}   

dev_attr_brightness就出现了，而show和store方法也被绑定了。
当调用cat …led0/brightness命令时候，就会调用led_brightness_show函数
当调用echo 1 > …led0/brightness命令时候，就会调用led_brightness_store函数

我们看一下led_brightness_store的实现

led_brightness_store(const char *buf, size_t size)    long state = simple_strtoul(buf, &after, 10);  //把buf的字符串转换为long型    if (state == LED_OFF)        led_set_brightness(led_cdev, state);            led_cdev->brightness_set(led_cdev, value);

函数原型略去了两个形参，buf就是echo的内容了，sysfs已经帮我们从用户空间拷贝到了内核空间，
所以可以直接使用，首先把字符串转为数字，然后判断是灭灯还是亮灯，最后调用的是led_cdev->brightness_set
熟悉驱动框架的都知道，这个肯定就是调用到具体的平台相关led驱动中的函数了，即通过led-class.c
提供的led_classdev_register接口注册进来的驱动提供的具体函数了。以2240为例就是

s3c24xx_led_probe    cdev.brightness_set = s3c24xx_led_set;    led_classdev_register(&dev->dev, &led->cdev);

那么我们应该怎么给驱动添加sysfs属性的支持呢？下面就以蜂鸣器操作为例展示一下：
这是linux3.2.0中关于AM335X平台内核提供的蜂鸣器驱动源码–am335x_buzzer.c

/*    am335x_buzzer.c  gpio driver ,misc device     PINS:        GPIO1_28*/#include <linux/init.h>#include <linux/module.h>#include <linux/miscdevice.h>#include <linux/moduleparam.h>#include <linux/platform_device.h>#include <linux/fs.h>#include <linux/gpio.h>#define  DEV_NAME  "buzzer" #define GPIO_TO_PIN(bank, gpio) (32 * (bank) + (gpio))#define GPIO_BUZZER    GPIO_TO_PIN(1, 28)#define BEEP_ON         0#define BEEP_OFF        1static int gpio_open(struct inode *inode, struct file *file){           return 0;}static int gpio_release(struct inode *inode, struct file *file){    return 0;}static long gpio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg){    switch(cmd)    {        case BEEP_OFF:            gpio_set_value(GPIO_BUZZER, BEEP_OFF);            break;        case BEEP_ON:            gpio_set_value(GPIO_BUZZER, BEEP_ON);               break;        default:            return -ENOTTY;    }    return 0;}static struct file_operations dev_ope = {    .owner= THIS_MODULE,    .unlocked_ioctl = gpio_ioctl,    .open           = gpio_open,    .release        = gpio_release,};static struct miscdevice gpio_misc = {    .minor = MISC_DYNAMIC_MINOR,    .name = DEV_NAME,    .fops = &dev_ope,};static int __devinit gpio_probe(struct platform_device *pdev){    int ret;    int result;    ret = misc_register(&gpio_misc);    if (ret)    {        printk(KERN_ERR"misc gpio failed\n");        return ret;    }    result = gpio_request(GPIO_BUZZER, "gpio_buzzer");      if (result != 0)    {        printk("buzzer_request pin failed!\n");    }       gpio_direction_output(GPIO_BUZZER, BEEP_OFF);     printk(KERN_INFO"am335x buzzer driver\n");    return 0;}static int __devexit gpio_remove(struct platform_device *pdev){    misc_deregister(&gpio_misc);    gpio_free(GPIO_BUZZER);    printk(KERN_INFO "unregistered gpio_buzzer device\n ");    return 0;}static struct platform_driver gpio_device_driver = {    .probe = gpio_probe,    .remove = gpio_remove,    .driver = {        .name = DEV_NAME,        .owner = THIS_MODULE,    }};static int __init gpio_init(void){    return platform_driver_register(&gpio_device_driver);}static void __exit gpio_exit(void){    platform_driver_unregister(&gpio_device_driver);}module_init(gpio_init);module_exit(gpio_exit);MODULE_DESCRIPTION("GPIO_BUZZER Drivers"); MODULE_LICENSE("GPL");

它是以platform总线实现的，在probe函数中又调用了misc_register把它注册为misc类设备
所以此时加载驱动会在/sys/class/misc中看到buzzer节点，但是ls一下只有下面几个属性
$ls /sys/class/misc/buzzer
dev power subsystem uevent

这四个属性是所有设备共有的属性，由sysfs核心产生，此时我们想提供一个state属性，
可用通过cat …/buzzer/state查看蜂鸣器状态，通过echo 0 > …/buzzer/state和
echo 0 > …/buzzer/state实现蜂鸣器响和不响操作。
我们需要做的有下面几件事：
1.调用 DEVICE_ATTR 宏声明state属性名称、读写权限及操作函数
2.实现操作函数buzzer_state_show和buzzer_state_set
3.调用device_create_file接口增加属性

所以代码就改为（只列出增加部分和修改部分，另增加了一个example属性）：

static ssize_t buzzer_state_show(struct device *dev,         struct device_attribute *attr, char *buf){    return sprintf(buf, "%u\n", gpio_get_value(GPIO_BUZZER));}static ssize_t buzzer_state_set(struct device *dev,        struct device_attribute *attr, const char *buf, size_t size){    char *after;    unsigned long state = simple_strtoul(buf, &after, 1);    switch(state)    {        case BEEP_OFF:            gpio_set_value(GPIO_BUZZER, BEEP_OFF);            break;        case BEEP_ON:            gpio_set_value(GPIO_BUZZER, BEEP_ON);               break;        default:            return -ENOTTY;    }    return size;}static DEVICE_ATTR(state, 0644, buzzer_state_show, buzzer_state_set);static ssize_t buzzer_example_show(struct device *dev,         struct device_attribute *attr, char *buf){    return sprintf(buf, "\n%s\n", "hello I am sysfs example");}static ssize_t buzzer_example_set(struct device *dev,        struct device_attribute *attr, const char *buf, size_t size){    printk("%s\n", buf);    return size;}static DEVICE_ATTR(example, 0644, buzzer_example_show, buzzer_example_set);static int __devinit gpio_probe(struct platform_device *pdev){    int ret;    int result;    ret = misc_register(&gpio_misc);    if (ret)    {        printk(KERN_ERR"misc gpio failed\n");        return ret;    }    result = gpio_request(GPIO_BUZZER, "gpio_buzzer");      if (result != 0)    {        printk("buzzer_request pin failed!\n");    }       gpio_direction_output(GPIO_BUZZER, BEEP_OFF);     ret = device_create_file(gpio_misc.this_device, &dev_attr_state);    if(ret)        goto err_out;    ret = device_create_file(gpio_misc.this_device, &dev_attr_example);    if(ret)        goto err_example;       printk(KERN_INFO"am335x buzzer driver\n");    return 0;err_example:    device_remove_file(gpio_misc.this_device, &dev_attr_state);err_out:    gpio_free(GPIO_BUZZER);    misc_deregister(&gpio_misc);    return ret;}

做了修改后加载驱动，再查看buzzer的属性时候就可以看到增加了state属性
$ ls /sys/class/misc/buzzer
dev example power state subsystem uevent

然后进行测试：
$ cat example
hello I am sysfs example

$ echo 123456 > example
[ 566.408172] 123456 //驱动中把用户输入简单的通过printk打印出来了

$ cat state
1 //即蜂鸣器的管脚是高电平

echo 0 > state 就会导致蜂鸣器鸣叫

至此，就把sysfs应用简单分析了一下，并简单修改了buzzer的驱动验证了一下。
至于sysfs的核心实现，后边有时间再写吧。最后为整个子系统分下层

---

用户空间：
使用shell命令操作sys下节点属性可以直接控制硬件。
比如echo 1 > /sys/class/leds/led0/brightness

---

内核空间：

---

sysfs核心：产生/sys目录

---

class.c：产生/sys/class目录

---

led-class.c：产生/sys/class/leds目录及相关属性

---

leds-s3c24xx.c：提供属性操作具体方法

---