kobject设备模型分析.pdf

《kobject设备模型分析.pdf》由会员分享，可在线阅读，更多相关《kobject设备模型分析.pdf（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、sysfs 是 kobject 的表达，所以这里翻译了 Documention 下的 kobjct.txt，并加上了一些自己的注释，这样基本就对 kobject和 sysfs 有了一个比较深刻的理解，我们可以简单的将 sysfs 看成最 bottom 的操作，然后 kobject 的想关操作是架构在 sysfs之上，再然后 kobject 和 attribute 所嵌入的结构体再构成上一层结构来操作 kobject，最后就实现了 kernel 内部各个 portion通过 sysfs 与 userspace 进行交互。要想了解 linux 驱动模型，以及驱动模型之上的 kobject 抽象，有

2、一个难点就是我们没有一个明确的入手点。要想了解 kobject我们必须了解很多不同的类型，而这些类型之间又会交叉引用，所以为了让理解更容易我们从多方面入手，首先看一些可能模糊不清的概念，然后随着深入我们会加入细节，在最后我们会定义一些我们工作上需要使用的术语。kobject 是一个结构体，它包含 name，reference count 以及指向一个 parent 的指针(这个指针等于就是将 kobject 加入了一个体系结构中)，一个特定的类型，以及在 sysfs 文件系统中的一个相关表达。kobject 一般不会单独使用，大部分的时候它会被嵌入其他的结构体，而这些结构体才是我们代码中真正需

3、要的。一个结构体最多只能嵌入一个 kobject，不然 reference count 就会乱掉，出错。(PS：实际上我们可以理解这个 kobject 实际上是我们与 sysfs 进行交互的一个接口，我们在设备驱动以及总线相关的结构体中嵌入这个 kobject，那么我们的设备驱动就可以通过 sysfs 与 userspace 进行交互了。虽然 sysfs 是 kobject 的表达，但我们可以近似的将 kobject 看成是架在 sysfs 上面的，在 kobject 上面封装的一系列操作实际上到底层都是调用的 sysfs 的公共接口)struct kobject const char *na

4、me;struct list_head entry;struct kobejct*parent;struct kset *kset;struct kobj_type*ktype;struct sysfs_dirent*sd;struct kref kref;unsigned int state_initialized:1;unsigned int state_in_sysfs:1;unsigned int state_add_uevent_sent:1;unsigend int state_remove_uevent_sent:1;ktype 定义了嵌入了 kobject 的结构体的类型，每一

5、个嵌入了 kobject 的结构体都必须有一个想对应的 ktype，ktype 定义了这个 kobject 创建和销毁时候需要做的事情。struct kobj_type void(*release)(struct kobject*kobj);struct sysfs_ops*sysfs_ops;struct attribute*default_attrs;(PS:看过代码以后感觉这个定义了 kobject 创建和销毁时候应该做的事情实际上并没有，kobj_type 结构体有 3 个成员，release 函数指针由自己定义来实现，定义了引用计数为 0 的时候对 kobject 的处理；sysfs

6、_ops 里面有两个成员变量分别是show 和 store 函数指针，分别是对 attribute 文件进行读写时候的处理，也需要我们来实现；attribute_attrs 是一个 attribute数组，是这个 kobject 被创建的时候会自动创建的 attributes)kset 说穿了就是一个 kobjects 的集合，这些 kobjects 可以有相同的 ktype 也可以不同 ktype。kset 应该来说是一个容器类型，用来存放 kobjects。struct kset struct list_head list;spinlock_t list_lock;struct kobje

7、ct kobj;struct kset_uevent_ops*uevent_ops;(PS:kset 我们看 kernel 的注释，它定义了 attribute callback 以及一个 kobject 可能发生的 event，从结构提本身来说我们可以看到它本身有一个链表来记载它所包含的 kobject，而且它本身包含一个 kobject，对于事件的处理应该是这个uevent_ops 了，从官方的解释来看(kset 的一组 uevent 的相关操作)它就是涉及对 uevent 的处理，这里还不知道它具体是如何处理的)我们知道单独使用的 kobject 在 kernel 里面是极少的，kobj

8、ect 主要通过嵌套的方式用来控制对一个大的，某个领域的结构体的访问。如果有面向对象的思想的话，我们可以将 kobject 理解为一个最顶端的抽象类，其他结构体都继承它的基础特性，并加入自己的特性。c 语言没有继承的技术，但是可以通过结构体嵌套的方式实现类似的逻辑。举个例子，比如一个 UIO 设备拥有一块内存区域，这个内存区域的结构体的定义如下：struct uio_mem struct kobject kobj;unsigned long addr;unsigned long size;int memtype;void _iomem*internal_addr;(PS:在实际编程中我们经常需

9、要完成从 kobject，及其所嵌入的结构体之间的转换，比如说知道 kobject 实体，我们要找到它所嵌入的结构体实体，从上面的例子就是我们知道 kobj 的时候，我们要找到它所在的 uio_mem 实体。这里就涉及一个很有用的宏container_of(pointer,type,member),这个宏定义在linux/kernel.h里面，第一个参数就是指向kobject的指针，type是指嵌入 kobject 的结构体类型，member 就是在结构体类型里面 kobject 的成员名，以上面的 uio_mem 为例就是：sturct uio_mem*u_mem=container_of(

10、kp,struct uio_mem,kobj)我们使用下面的函数来初始化一个 kobject，其中 ktype 是必须的：void kobject_init(struct kobject*kobj,struct kobj_type*ktype);(PS:我们可以简单看看这个 init 干了什么事情，首先将 kobj-kref 置为 1，也就是初始化的 kobject 的引用计数为 1；然后kobj-entry 这个双向链表都指向自身；然后就是对标志位的一系列初始化，主要是初始化为真，在 sysfs 为假，相关的 event也全为 0)初始化以后我们就可以通过 kobject_add 将我们的

11、kobject 加入 sysfs 文件系统了：int kobject_add(struct kobject*kobj,struct kobject*parent,const char*fmt,);(PS:这个函数第一个参数是要加入 sysfs 的 kobject；第二个参数是 kobject 的 parent，可以为空，如果为空的话首先判断kset 是否为空，如果不为空则 parent 设置为 kset，如果都为空则默认这个 kobject 会被建立在 sysfs 的顶层目录下；fmt 是定义了 kobject 的 name。同样我们可以看看这个 add 的具体过程，首先根据 fmt 设置 k

12、object 的 name 成员，然后 kset存在的话会将这个 kobject 加入 kset，加入 kset 的过程就是将 kobject 的 entry 放入 kobj-kset-list 这个双向循环链表中，由此我们可以看到 kobject 的 entry 的功能就是放入 kset 的 list 链表中。这里还会设置 kobject 的 parent，然后就会调用 sysfs_create_dir 来创建目录，创建目录的过程会 allocate 一个 sysfs_dirent 的结构体，从 kernel 对这个结构体的描述来看，sysfs 上面每一个结点都是使用这个结构体来描述的，由此

13、我们可以理解 kobject 里面的 sd 成员这里的 sd 个人猜测应该是 sysfs directory 吧变量作用了，他是在注册到 sysfs 的时候由 sysfs 来创建的，创建完目录以后如果 ktype 里面有attribute 数组的话，还会创建默认的 attribute 文件。)kobject 的目录名不能粗暴的直接去改 kobject 的 name 成员，应该使用相应的 API 去改：int kobject_rename(struct kobject*kobj,const char*new_name);(PS:我们看过这个函数的实现后就清楚，它会先调用 sysfs_rename

14、_dir 来修改目录名以后再才会修改 kobject 的 name 成员，最后它还会将发生改变的目录加上目录改变的事件以环境变量的方式通过 kobjec_uevent_env()发送出去。)这个函数没有锁操作，也不会检查 name 的有效性，所以调用这个函数的时候我们要进行相应的合法性检测，并加入自己的互斥操作。另外我们也可以通过下面的函数来取得 kobject 的 name 成员：const char*kobject_name(const struct kobject*kobj);另外这里还一个对 kobject 的 init 和 add 合二为一的操作：int kobject_init_a

15、nd_add(sturct kobject*kobj,struct kobj_type*ktype,struct kobjcet*parent,const char*fmt,)当我们将一个 kobject注册到 kobject core以后，我们可能需要告诉其他模块或者 userspace我们已经注册了一个 kobject，这里有一个函数可以帮我们实现这一点：int kobject_uevent(struct kobject*kobj,enum kobject_action action);当我们第一次 add 一个 kobject 的时候可以用 KOBJ_ADD 事件，但是这个事件的通知必须

16、是在这个 kobject 所有的 attibure或者它的子目录都创建以后才行，因为一旦调用这个函数用户空间就知道了，就可能会去操作这个 kobject 下面的 attribute文件。当这个 kobject 被删除的时候，KOBJ_REMOVE 事件会自动产生。(PS:把这个函数基本过了一遍，大致是这样的，首先找到 kobj 属于哪个 kset 的，如果当前 kobj 没有 kset 就会寻找他父 kobje的 kset，直到找到 kset 为止，没有找到就会报错；找到 kset 以后会看它的 uevent_ops 里面的 filter 指针是否为空，不为空的就话就会调用这个函数，如果这个函

17、数返回 0 的话说明 uevent 被过滤掉了，会直接返回；然后会调用 uevent_ops 里面的name 函数来取得 subsystem 的 name，如果 name 指针为空就会直接使用 kset 的 name 作为 subsystem 的 name，如果 name 的值为空的话会直接返回；然后会申请一个 kobj_uevent_env 来存放环境变量，在这里先获得 kobj 所在的目录，这个目录是从 sysfs 根目录一直到 kobj 的绝对目录，然后就会将前面我们获得的 kobj 的根目录，subsystem 的 name，以及我们的 action 都会放入 kobj_uevent_

18、env 这个结构体中；完成上面的步骤以后还会判断 uevent_ops 的 uevent 指针是否为空，不为空的话会调用这个函数，这个函数的功能应该是在前面的 kobj_uevent_env 加入一些 kset 本身的 uevent；如果是 KOBJ_ADD 或者 KOBJ_REMOVE 还会修改 kobj 内部的标志位；最后就是在 env 结构体中加入一个 uevent 系列号，然后根据 CONFIG_NET 是否使用将 env 的内容使用 netlink message 的方式广播给 userspace，最后还有一个uevent_helper，没太整明白这个意思，应该来说是通过 call_

19、usermodehelper 这个函数来开启 uevent_helper 这个进程来处理要上传的事件，uevent_helper 默认是 sbin/hotplug。关于这个 hotplug 的东西，会在以后的文档中专门讲一下的。经过这个过程我们大致可以了解kset里面的uevent_ops的几个函数指针的功能，分别是过滤事件，获取subsystem的nam加入这个 kset 特定的 uevent。)e，kobject 一个很核心的功能就是计算它所嵌入的结构体的引用计数，只要引用计数不为 0 这个结构体就不会被释放，下面的 API分别是增加和减少引用计数的，分别将引用计数加 1 和减 1：str

20、uct kobject*kobject_get(struct kobjcet*kobj);void kobject_put(sturct kobject*kobj);我们应该养成很好的习惯，要获取一个 kobject 的时候使用 get，不使用的时候 put。因为 kobject 是动态的可能涉及到共享，所以不要用静态的方式声明一个 kobject，而是使用动态分配的方式申请 kobject。如果仅仅是想在 sysfs 里面创建一个目录，而不用管什么 kset，show/store 以及其他细节，可以通过下面的方式：struct kobject*kobject_create_and_add(c

21、har*name,struct kobject*parent)然后我们可以直接调用 sysfs 的 API 的方式在这个目录下创建属性文件：sysfs_create_file/sysfs_create_group 我们可以看一个例子：samples/kobject/kobject-example.c(PS:这个 example 没有什么好说的，唯一要注意的是_ATTR()这个宏，写代码的时候应该会经常用到，主要用来对自己定义的 attribute 结构体进行赋值，我们知道 kobject 一般不会单独使用，attribute 也一样，一般会将 attribute 结构体嵌入到其他结构体里面，比

22、如说什么 device_attribute,kobj_attribute 等等，一般都是嵌入 attribute 结构体以后加上两个对其操作的函数，一般是 show 和 store，而这个宏就是对这些结构体成员赋值用的。)到现在为止我们还漏掉了一个重要的事情没讲，那就是一个 kobject 的引用为 0 的时候会发生什么事情。创建 kobject 的代码并不知道 kobject 的引用什么时候会变成 0，当这个 kobject 注册到 sysfs 并且有其他的客人呢了模块来引用它的时候，这个情况会变得更复杂。当一个结构体内部的 kobject 引用不为 0 的时候，我们不能够认为的 free

23、掉，而应该使用 kobject_put来操作它。当一个 kobject 的引用为 0 的时候会自动调用 ktype 里面的 release 函数，所以我们必须实现我们的 ktype 里面的 release 函数。一般来说这些 release 函数都有如下面一样类似的格式：void my_object_releas(struct kobject*kobj)struct my_object*mine=container_of(kobj,sturct my_object,kobj);kfree(mine);每个 ktype 必须实现这个函数，如果不实现你就等着 kernel kobject 的代码维

24、护者来 A 你吧 记住不要在 release 这个回调函数里面修改 kobject 的 name 成员变量，否则会造成内存泄露。kset 是一个 kobjects 的集合，没有限制说他们必须是同样的 ktype，但是如果不是相同的 ktype 在操作的时候必须万分小心。kset 一般来说完成 3 个功能：1、它是一个 kobject 包，在 kernel 里面可以用来跟踪“所有的块设备”或者“所有的 pci 设备驱动”；2、kset本身也是sysfs里面的一个子目录，每个keset内嵌一个kobject，可以看成是这个kset-list里面所有的kobjects的 parent，kernel

25、sysfs 体系中的最顶层目录就是这么构成的；kset 支持 kobject 的热拔插，而且会影响到报告到 userspace的 uevent。在面向对象的概念里，我们可以将 kset 看成一个最顶层的容器类。kset 使用 kernel 的标准链表来链接它下面所有的 kobjects，kobjtets 通过 kset 成员指向他们的 kset，在大多数的情况下 kobjects 的 kset 就是他们的 parent。(PS:这里虽然说了那么多关于 kset 的东西，但是我们分析它这个结构体就可以看出，它的主要作用除了本身是一个包含目录的目录之外，其他的就是影响到 uevent 的发送，前面

26、看 kobject_uevent 的时候我们已经分析过了)因为 kset 包含一个内嵌的 kobject，所以 kset 也必须动态分配，而不能用静态的方式创建。我们可以通过下面的方式来创建一个 kset:struct kset*kset_create_and_add(const char*name,struct kset_uevent_ops*u,struct kobject*parent);(PS:同样我们分析这个函数，实际上是由 create 和 register 两部分组成的，create 一个 kset 比较简单，就是 allocate 一个结构体，值得注意的是对内嵌的 kobjec

27、t 的赋值，name 和 parent 是根据参数来的，另外内嵌 kobject 的 ktype 是固定的kset_ktype，这个 kset_type 定义了 release 指针和 sysfs_ops，另外内嵌 kobject 的 kset 为 NULL，也就是说 kset 类型没有默认的 attribute 文件，也不再属于哪个 kset，且对其的 sysfs_ops 以及 release 都是固定的。然后 register 的过程也是比较简单的先初始化内部的 list，然后将内嵌的 kobject 加入 sysfs，最后会自动产生一个 KOBJ_ADD 事件。综上我们可以知道 kset

28、 注册的过程基本上是 kobject 一样的，也就是说其本质上还是还是一个 kobject，只是是一个特殊的 kobject 而已)当我们不再使用 kset 的时候可以使用 void kset_unregister(struct kset*kset);来销毁它。(PS:时间上这个 unregister 就是将其内嵌的 kobject 调用一下 kobject_put()。从这点上来看我们更可以说所谓 kset 就是一个特殊的 kobject 而已，不过是多了个链表来包含一组 kobjects)前面提到了这个 kset_uevent_ops 结构体，kset 通过这个结构体来控制 kobject

29、 相关的 uevent 操作，下面我们就详细解释下这个结构体的几个参数：struct kset_ueven_ops int(*filter)(struct kset*kset,struct kobject*kobj);const char*(*name)(struct kset*kset,struct kobject*kobj);int(*uevent)(struct kset*kset,struct kobject*kobj,struct kobj_uevent_env*env);filter 函数允许 kset 阻止一些 kobject export 到 userspace 的 ueven

30、t，如果这个函数返回 0 那么 uevent 就不会报到用户空间。name 函数可以覆盖默认的要报到用户空间的 kset 的内嵌 kobject 的 name，一般来说报到用户空间的 name 是 kset 的内嵌kobject 的 name，我们可以在这里修改这个默认值。uevent 函数在 uevent 被报告到用户空间的时候会被调用，可以允许加入更多的环境变量到 env 结构体中。一个 kobject 一般在其 kset 子目录下，但并不是确定的，因为确定一个 object 在哪个目录首先是判断 parent，然后再判断kset。一个 kobject 被成功注册到 kobject cor

31、e 以后，如果我们的代码不再需要他们的时候我们要删除它。一般来说我们可以使用kobjet_put()来实现这一点。kobject core会自动在引用为0的时候调用release函数来删除相对应的结构体，并同时exoport出 KOBJ_REMOVE 这个消息。如果你需要分两步来删除一个 kobject(删除 kobject 的时候不能进入休眠)，你可以首先使用kobject_del()来将一个 kobject 从 sysfs 注销，这样 kobject 对用户空间就不可见了，但这个时候 koject 的引用计数是没有变的。然后最后再调用 kobjct_put 来最终删除 kobject。在环

32、形引用的情况下，可以使用 kobject_del()函数来减去对 parent kobject 的引用。在某些情况下 parent object 引用它的 child object 是有效的，在这种情况下必须使用 kobject_del()来破除这种环形引用，从而调用 release 函数删除父子kobject。(PS:我们可以具体看看 kobject_del 的实现，它首先调用 sysfs_remove_dir 来删除 kobject 的目录，然后将kobj-state_in_sysfs 置为 0，然后将 kobject 从其 kset 的 list 中删除，最后会调用 kobject_put(kobj-parent)；由此我们就看到 kobject 的功能就是将 kobject 从 sysfs 和 kset-list 中删除，并降低 kobj-parent 的引用计数，所以它可以用来消除环形引用)