讨论中仍然缺失的一个重要事情是当一个 kobject 的引用计数到 0 时会发生什么. 创建 kobject 的代码通常不知道什么时候要发生这个情况; 如果它知道, 在第一位使用一个引 用计数就没有意义了. 即便当引入 sysfs 时可预测的对象生命周期变得更加复杂; 用户 空间程序可保持一个对 kobject 的引用( 通过保持一个它的关联的 sysfs 文件打开 )一 段任意的时间.
最后的结果是一个被 kobject 保护的结构无法在任何一个单个的, 可预测的驱动生命周 期中的点被释放, 但是可以在必须准备在 kobject 的引用计数到 0 的任何时刻运行的代 码中. 引用计数不在创建 kobject 的代码的直接控制之下. 因此这个代码必须被异步通 知, 无论何时对它的 kobject 的最后引用消失.
这个通知由 kobject 的一个释放函数来完成. 常常地, 这个方法有一个形式如下:
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 必须有一个释放函数, 并且这个 kobject 必须持续 ( 以一致的状态 ) 直到这个方法被调用. 如果这些限制不满足, 代码就有缺陷. 当这个 对象还在使用时被释放会有风险, 或者在最后引用被返回后无法释放对象.
有趣的是, 释放方法没有存储在 kobject 自身里面; 相反, 它被关联到包含 kobject 的 结构类型中. 这个类型被跟踪, 用一个 struct kobj_type 结构类型, 常常简单地称为一 个 "ktype". 这个结构看来如下:
struct kobj_type {
void (*release)(struct kobject *); struct sysfs_ops *sysfs_ops; struct attribute **default_attrs;
};
在 struct kobj_type 中的 release 成员是, 当然, 一个指向这个 kobject 类型的 release 方法的指针. 我们将回到其他 2 个成员( sysfs_ops 和 default_attrs )在本 章后面.
每一个 kobject 需要有一个关联的 kobj_type 结构. 易混淆地, 指向这个结构的指针能 在 2 个不同的地方找到. kobject 结构自身包含一个成员(称为 ktype)包含这个指针. 但是, 如果这个 kobject 是一个 kset 的成员, kobj_type 指针由 kset 提供. ( 我们 将在下一节查看 ksets. ) 其间, 这个宏定义:
struct kobj_type *get_ktype(struct kobject *kobj); finds the kobj_type pointer for a given kobject.