linux设备模型之ktype

ktype和release方法

关于kobject引用计数重要的一点是当这个引用计数归0时，kobject会发生什么。创建kobject的代码通常不知道引用计数什么时候归0。即使object的生命周期是可以预测的，但是linux其他模块引入sysfs使情况变得复杂，其他模块可以获取任何注册到系统中的kobject。

 

最后的结果是通过kobject保护的包含它的结构在引用计数归0之前不能被释放。创建kobject的代码不直接控制引用计数。所以在引用计数归0时要异步通知创建kobject的代码，也就是回调它所提供的release方法。

 

一旦通过kobject_add()函数注册kobject，就不能使用kfree()直接释放它。唯一安全的方法是调用kobject_put()函数。在kobject_init()后，总是调用kobject_put()释放它是一个好的习惯，防止错误发生蔓延。

 

这样的通知通过kobject的release()方法来完成。通常如下：

  void my_object_release(struct kobject *kobj)

{

   struct my_object *mine = container_of(kobj, struct my_object, kobj);

     /* Perform any additional cleanup on this object, then... */

     kfree(mine);

  }

 

再着重强调一下：每个kobject必须有一个release方法，这个kobject在release()方法调用之前必须一直存在。如果你忘记提供release方法，内核会警告你。不要试图赋空值去除这个警告，如果这么做会被kojbect维护者无情的嘲笑。

 

注意，在提供的release函数中kobject的名字是可用的，但是在回调时不能改变这个名字。否则会造成kobject核心的内存泄漏，这样会让别人不高兴。

 

有趣的是，kobject本身不包含release方法，而是包含在与之关联的ktype中。看一下ktype结构kobj_type:

struct kobj_type

{

     void (*release)(struct kobject *);

       const struct sysfs_ops  *sysfs_ops;

       struct attribute    **default_attrs;

  };

这个结构用来描述一个特定类型的kobject（更确切的说是包含它的对象）。每个kobject需要一个对应的kobj_type结构；在调用kobject_init() 或 kobject_init_and_add()的时候必须给这个结构的指针赋值。

 

kobj_type的release域是指向服务于这种类型的kobject的release方法的指针，其他两个域(sysfs_ops and default_attrs)控制了包含这个类型的对象在sysfs中怎样去呈现，超出这个文档的范围。

 

default_attrs 成员指针是一个会自动创建的用这个ktype注册的任何kobject的默认属性列表。

 

参考文档：

/Documentation/kobject.txt

http://blog.chinaunix.net/uid-20522771-id-3447116.html

为了更方便查看相关文章，可以关注我的个人微信公众号：