Linux设备模型 (2)-chumojing-ChinaUnix博客

chumojing的ChinaUnix博客

首页　| 　博文目录　| 　关于我

chumojing

博客访问： 2172295
博文数量： 374
博客积分： 7276
博客等级：少将
技术积分： 5669
用户组：普通用户
注册时间： 2011-10-06 16:35

文章分类

全部博文（374）

手机（3）
硬件相关（2）
版本控制（3）
android（1）
MCU（4）
杂文随笔（1）
内存管理（2）
示波器（1）
bootloader（6）

UBOOT（4）
linux相关（38）

awk（2）

vim（7）

gdb（1）

shell（9）
设计模式（3）
过程记录（2）
内核知识（14）

内核函数（2）

内核移植（7）
ubuntu（19）
Makefile（3）
学习资源（1）
busybox（8）
应用编程（85）

定时器（4）

进程线程（14）

eclipse（3）

Qt（13）

网络（17）

C\C++（8）
设备驱动（151）

时钟体系（1）

延时操作（1）

CACHE DMA（1）

内存屏障（0）

设备驱动-GPIO（4）

电源管理（15）

设备驱动-PCI（1）

设备驱动-LCD（0）

设备驱动-tty（8）

网络驱动（3）

设备模型（10）

设备驱动-USB（21）

内核同步机制（7）
未分配的博文（27）

文章存档

2013年（23）

2012年（153）

2011年（198）

我的朋友

相关博文

Linux设备模型 (2)

分类： LINUX

2011-10-20 09:08:26

上一篇文章《Linux设备模型 (1)》主要介绍了Linux设备模型在用户空间的接口sysfs，用户通过这个接口可以一览内核设备的全貌。本文将从Linux内核的角度来看一看这个设备模型是如何构建的。

在Linux内核里，kobject是组成Linux设备模型的基础，一个kobject对应sysfs里的一个目录。从面向对象的角度来说，kobject可以看作是所有设备对象的基类，因为C语言并没有面向对象的语法，所以一般是把kobject内嵌到其他结构体里来实现类似的作用，这里的其他结构体可以看作是kobject的派生类。Kobject为Linux设备模型提供了很多有用的功能，比如引用计数，接口抽象，父子关系等等。引用计数本质上就是利用kref实现的，至于kref的细节可以参考我之前的文章《Linux内核里的“智能指针”》。

另外，Linux设备模型还有一个重要的数据结构kset。Kset本身也是一个kobject，所以它在sysfs里同样表现为一个目录，但它和 kobject的不同之处在于kset可以看作是一个容器，如果你把它类比为C++里的容器类如list也无不可。Kset之所以能作为容器来使用，其内部正是内嵌了一个双向链表结构struct list_head。对于list_head的细节可以参考《玩转C链表》一文。

下面这幅图可以用来表示kobject和kset在内核里关系。

在接下来的篇幅里我们会逐步看到这个关系图在内核里是如何建立的。本文的示例代码可以从这里下载，下文中的两个实作都在这个示例代码里。

Kobject

Kobject在Linux内核里的定义如下：

01struct kobject {
02    const char      *name;
03    struct list_head    entry;
04    struct kobject      *parent;
05    struct kset     *kset;
06    struct kobj_type    *ktype;
07    struct sysfs_dirent *sd;
08    struct kref     kref;
09    unsigned int state_initialized:1;
10    unsigned int state_in_sysfs:1;
11    unsigned int state_add_uevent_sent:1;
12    unsigned int state_remove_uevent_sent:1;
13    unsigned int uevent_suppress:1;
14};

在《Linux设备模型 (1)》里面我们介绍到内核里的设备之间是以树状形式组织的，在这种组织架构里比较靠上层的节点可以看作是下层节点的父节点，反映到sysfs里就是上级目录和下级目录之间的关系，在内核里，正是kobject帮助我们实现这种父子关系。在kobject的定义里，name表示的是kobject在sysfs中的名字；指针parent用来指向kobject的父对象；Kref大家应该比较熟悉了，kobject通过它来实现引用计数；Kset指针用来指向这个 kobject所属的kset，下文会再详细描述kset的用法；对于ktype，如果只是望文生义的话，应该是用来描述kobject的类型信息。 Ktype的定义如下：

1struct kobj_type {
2    void (*release)(struct kobject *kobj);
3    const struct sysfs_ops *sysfs_ops;
4    struct attribute **default_attrs;
5};

函数指针release是给kref使用的，当引用计数为0这个指针指向的函数会被调用来释放内存。sysfs_ops和attribute是做什么用的呢？前文里提到，一个kobject对应sysfs里的一个目录，而目录下的文件就是由sysfs_ops和attribute来实现的，其中，attribute定义了kobject的属性，在sysfs里对应一个文件，sysfs_ops用来定义读写这个文件的方法。Ktype里的 attribute是默认的属性，另外也可以使用更加灵活的手段，本文的重点还是放在default attribute。

下面看一个实作。在这个实作里，我们定义一个内嵌kobject的结构。

1struct my_kobj {
2    int val;
3    struct kobject kobj;
4};

最终我们的目的是在内核里构建这样的架构。

对应sysfs里的目录关系是：

mykobj1/
|-- mykobj2
| |-- name
| `-- val
|-- name
`-- val

这是module_init代码。

01static int __init mykobj_init(void)
02{
03    printk(KERN_INFO "mykobj_init\n");
04 
05    obj1 = kzalloc(sizeof(struct my_kobj), GFP_KERNEL);
06    if (!obj1) {
07        return -ENOMEM;
08    }
09    obj1->val = 1;
10 
11    obj2 = kzalloc(sizeof(struct my_kobj), GFP_KERNEL);
12    if (!obj2) {
13        kfree(obj1);
14        return -ENOMEM;
15    }
16    obj2->val = 2;
17 
18    my_type.release = obj_release;
19    my_type.default_attrs = my_attrs;
20    my_type.sysfs_ops = &my_sysfsops;
21 
22    kobject_init_and_add(&obj1->kobj, &my_type, NULL, "mykobj1");
23    kobject_init_and_add(&obj2->kobj, &my_type, &obj1->kobj, "mykobj2");
24 
25    return 0;
26}

这段代码可以分作三个部分。第一部分是分配obj1和obj2并赋值；第二部分是初始化kobj_type变量my_type；第三部分是调用 kobject_init_and_add函数来初始化kobject并把它加入到设备模型的体系架构（也就是上文中提到的内核中的那棵树）中。 kobject_init_and_add是简化的写法，这个函数也可以分两步完成：kobject_init和kobject_add。

int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
             struct kobject *parent, const char *fmt, ...);
 
void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
int kobject_add(struct kobject *kobj, struct kobject *parent,
        const char *fmt, ...);

kobject_init用来初始化kobject结构，kobject_add用来把kobj加入到设备模型之中。在实作中，我们先对obj1进行初始化和添加的动作，调用参数里，parent被赋为NULL，表示obj1没有父对象，反映到sysfs里，my_kobj1的目录会出现在/sys 下，obj2的父对象设定为obj1，那么my_kobj2的目录会出现在/sys/my_kobj1下面。

前面提到，kobject也提供了引用计数的功能，虽然本质上是利用kref，但也提供了另外的接口供用户使用。

1	struct kobject kobject_get(struct kobject kobj);

2	void kobject_put(struct kobject *kobj);

kobject_init_and_add和kobject_init这两个函数被调用后，kobj的引用计数会初始化为1，所以在module_exit时要记得用kobject_put来释放引用计数。

我们再回到实作中，看看如何使用ktype。代码里，my_attrs是这样定义的：

01struct attribute name_attr = {
02    .name = "name",
03    .mode = 0444,
04};
05 
06struct attribute val_attr = {
07    .name = "val",
08    .mode = 0666,
09};
10 
11struct attribute *my_attrs[] = {
12    &name_attr, 
13    &val_attr,
14    NULL,
15};

结构体struct attribute里的name变量用来指定文件名，mode变量用来指定文件的访问权限。这里需要着重指出的是，数组my_attrs的最后一项一定要赋为NULL，否则会造成内核oops。

sysfs_ops的代码如下：

01ssize_t my_show(struct kobject *kobj, struct attribute *attr, char *buffer)
02{
03    struct my_kobj *obj = container_of(kobj, struct my_kobj, kobj);
04    ssize_t count = 0;
05 
06    if (strcmp(attr->name, "name") == 0) {
07        count = sprintf(buffer, "%s\n", kobject_name(kobj));
08    } else if (strcmp(attr->name, "val") == 0) {
09        count = sprintf(buffer, "%d\n", obj->val);
10    }
11 
12    return count;
13}
14 
15ssize_t my_store(struct kobject *kobj, struct attribute *attr, const char *buffer, size_t size)
16{
17    struct my_kobj *obj = container_of(kobj, struct my_kobj, kobj);
18 
19    if (strcmp(attr->name, "val") == 0) {
20        sscanf(buffer, "%d", &obj->val);
21    }
22 
23    return size;
24}
25 
26struct sysfs_ops my_sysfsops = {
27    .show = my_show,
28    .store = my_store,
29};

读文件会调用my_show，写文件会调用my_store。

最后是module_exit：

01static void __exit mykobj_exit(void)
02{
03    printk(KERN_INFO "mykobj_exit\n");
04 
05    kobject_del(&obj2->kobj);
06    kobject_put(&obj2->kobj);
07     
08    kobject_del(&obj1->kobj);
09    kobject_put(&obj1->kobj);
10 
11    return;
12}

kobject_del的作用是把kobject从设备模型的那棵树里摘掉，同时sysfs里相应的目录也会删除。这里需要指出的是，释放的顺序应该是先子对象，后父对象。因为kobject_init_and_add和kobject_add这两个函数会调用kobject_get来增加父对象的引用计数，所以 kobject_del需要调用kobject_put来减少父对象的引用计数。在本例中，如果先通过kobject_put来释放obj1，那 kobject_del(&obj2->kobj)就会出现内存错误。

在这个实作中，我们建立了两个对象obj1和obj2，obj1是obj2的父对象，如果推广开来，obj1可以有更多的子对象。在Linux内核中，这种架构方式其实并无太大的实际价值，有限的用处之一是在sysfs里创建子目录（Linux内核里有这种用法，这种情况下，直接调用内核提供的kobject_create来实现，不需要自定义数据结构并内嵌kobject），而且，创建子目录也是有其他的办法的。我们知道，Linux设备模型最初的目的是为了方便电源管理，这就需要从上到下的遍历，在这种架构里，通过obj1并无法访问其所有的子对象。这个实作最大的意义在于可以让我们比较清晰的理解kobject如何使用。通常情况下，kobject只需要在叶节点里使用，上层的节点要使用kset。

Kset

Kset的定义如下：

1struct kset {
2    struct list_head list;
3    spinlock_t list_lock;
4    struct kobject kobj;
5    const struct kset_uevent_ops *uevent_ops;
6};

Kset结构里的kobj表明它也是一个kobject，list变量用来组织它所有的子对象。

我们直接看一个实作。在这个实作里，我们将构建如下的架构。

对应sysfs里的目录关系是：

my_kset/
|-- mykobj1
| |-- name
| `-- val
`-- mykobj2
|-- name
`-- val

这个实作和前一个差别很小，下面只简略的引用一些代码。

01static int __init mykset_init(void)
02{
03    printk(KERN_INFO "mykset_init\n");
04 
05    my_kset = kset_create_and_add("my_kset", NULL, NULL);
06    if (!my_kset) {
07        return -ENOMEM;
08    }
09 
10    // Allocate obj1 and obj2
11    // ...
12 
13    obj1->kobj.kset = my_kset;
14    obj2->kobj.kset = my_kset;
15 
16    // Init my_type
17    // ...
18 
19    kobject_init_and_add(&obj1->kobj, &my_type, NULL, "mykobj1");
20    kobject_init_and_add(&obj2->kobj, &my_type, NULL, "mykobj2");
21 
22    return 0;
23}
24 
25static void __exit mykset_exit(void)
26{
27    printk(KERN_INFO "mykset_exit\n");
28 
29    // Release obj1 and obj2
30    // ...
31 
32    kset_unregister(my_kset);
33 
34    return;
35}

在module_init里，我们首先调用kset_create_and_add创建my_kset，接下来把my_kset赋给obj1和obj2，最后调用kobject_init_and_add来添加obj1和obj2。这里需要注意的是，kobject_init_and_add参数里的 parent都是NULL，在这种情况下，obj1和obj2的父对象由kobject结构里的kset指针决定，在这个实作里就是my_kset。在 module_exit里，我们还需要额外调用kset_unregister来释放之前创建的my_kset。

注：看过的读者应该对Linux Device Model一章中的subsystem还有印象，我在这里注明一下，从2.6.23开始Linux内核就抛弃了subsystem，subsystem其实只是kset的一个马甲，所以抛弃它对Linux设备模型并没什么影响。

作者：wwang
出处：http://www.cnblogs.com/wwang
本文采用进行许可，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。

阅读(919) | 评论(0) | 转发(4) |

上一篇：Linux设备模型 (1)

下一篇：Linux设备模型 (3)

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6