内核对象kobject和sysfs（3）——kobj分析
在分析kobj之前，先总结下kobj的功能：
- 实现结构的动态管理；
- 实现内核对象到sysfs的映射；
- 实现自定义属性的管理。
关注一下kobj的结构：
struct kobject {
const char *name;// 该内核对象的名称
struct list_head entry;// 链入kset的连接件
struct kobject *parent;// 指向父对象，可以为空
struct kset *kset; // 指向的内核对象集合，可以为空
struct kobj_type *ktype; // 该内核对象使用的操作集合
struct kernfs_node *sd; /* sysfs directory entry */
struct kref kref; // 该内核对象的引用计数
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
struct delayed_work release;
#endif
unsigned int state_initialized:1;
unsigned int state_in_sysfs:1;
unsigned int state_add_uevent_sent:1;
unsigned int state_remove_uevent_sent:1;
unsigned int uevent_suppress:1;
};
kobject内的注释已经注释在页面上，在初次接触的时候，先关注其中name，parent，ktype， kref这三个域即可。下面详细分析：
- name是该内核对象的名称，在其向sysfs注册的时候，显示的目录的名字；
- parent指示了该内核对象在sysfs中的位置，如果有父类，则目录会创建在对应的父类下，如果没有，则创建在/sysfs下；
- ktype包含了该内核对象的操作方法，包括前面提及的kref的自定义释放函数和自定义属性操作；
下面给出ktype的及其内部相关结构：
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
struct attribute **default_attrs;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
const void *(*namespace)(struct kobject *kobj);
};
struct sysfs_ops {
ssize_t (*show)(struct kobject *, struct attribute *, char *);
ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};
struct attribute {
const char *name;
umode_t mode;
};
我们先大致看一下这三个结构。不做深入分析，先看一下如何操作kobj。
kobj的操作和kref的流程大致相似，包括初始化、注册、注销。
先来看看初始化：
325 void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
326 {
327 char *err_str;
328
329 if (!kobj) {
330 err_str = "invalid kobject pointer!";
331 goto error;
332 }
333 if (!ktype) {
334 err_str = "must have a ktype to be initialized properly!\n";
335 goto error;
336 }
337 if (kobj->state_initialized) {
338 /* do not error out as sometimes we can recover */
339 printk(KERN_ERR "kobject (%p): tried to init an initialized "
340 "object, something is seriously wrong.\n", kobj);
341 dump_stack();
342 }
343
344 kobject_init_internal(kobj);
345 kobj->ktype = ktype;
346 return;
347
348 error:
349 printk(KERN_ERR "kobject (%p): %s\n", kobj, err_str);
350 dump_stack();
351 }
352 EXPORT_SYMBOL(kobject_init);
187 static void kobject_init_internal(struct kobject *kobj)
188 {
189 if (!kobj)
190 return;
191 kref_init(&kobj->kref);
192 INIT_LIST_HEAD(&kobj->entry);
193 kobj->state_in_sysfs = 0;
194 kobj->state_add_uevent_sent = 0;
195 kobj->state_remove_uevent_sent = 0;
196 kobj->state_initialized = 1;
197 }
可以看到，kobject_init对应kref的kref_init。函数有两个参数，一个是待初始化的内核对象，一个是该对象的操作集合。关键的步骤在344~345行。在kobject_init_internal里我们可以看到，他对内嵌的kref进行了初始化，这和上一篇描述的用法基本相同。其他的代码都是一些状态的初始化，暂且略过。不过值得提及的是INIT_LIST_HEAD宏。该宏在内核中广泛用到，用于初始化一个通用链表的头结点，将前后都指向自己。内核通过通用链表的连接件，将数据结构链入链表中加以管理，这里不再赘述。回到345行，其实发现kobject_init操作对kobj_type 的内容并不做检查。
684 void kobject_put(struct kobject *kobj)
685 {
686 if (kobj) {
687 if (!kobj->state_initialized)
688 WARN(1, KERN_WARNING "kobject: '%s' (%p): is not "
689 "initialized, yet kobject_put() is being "
690 "called.\n", kobject_name(kobj), kobj);
691 kref_put(&kobj->kref, kobject_release);
692 }
693 }
694 EXPORT_SYMBOL(kobject_put);
kobject_put是内核对象的释放函数，对应于kref的kref_put。可以看到，kobject_put仅仅是对kref_put的一个封装而已，向kref机制注册了kobject_release函数。
663 static void kobject_release(struct kref *kref)
664 {
665 struct kobject *kobj = container_of(kref, struct kobject, kref);
666 #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
667 unsigned long delay = HZ + HZ * (get_random_int() & 0x3);
668 pr_info("kobject: '%s' (%p): %s, parent %p (delayed %ld)\n",
669 kobject_name(kobj), kobj, __func__, kobj->parent, delay);
670 INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
671
672 schedule_delayed_work(&kobj->release, delay);
673 #else
674 kobject_cleanup(kobj);
675 #endif
676 }
由于向kref注册的函数参数只能是kref，所以必须通过container_of宏来获取到封装该kref的kobject，这也是上一篇中说明kref必须是内嵌的原因之一。只有内嵌结构，才可以使用container_of宏进行操作。container_of宏在此不再赘述。
获取到kobj的地址后，在674行释放资源。
初学者看到这里，不妨停下来，也许你会发现，kobject实际上，从这两个函数看来。就是上一篇我们自己写的内核模块的一个更专业版本。kobj_type 在这两个函数里，也就是赋值的作用，并没有起到真正的功能。因此，也许我们可以把上一篇的代码改进一下，写一个不提供任何功能的内核模块，仅仅是为了验证一下kobj拥有kref的功能，不过需要注意的是，一定要实现其中的release函数，这一点在后面详细说明。
验证之后，分析kobject_add：
394 int kobject_add(struct kobject *kobj, struct kobject *parent,
395 const char *fmt, ...)
396 {
397 va_list args;
398 int retval;
399
400 if (!kobj)
401 return -EINVAL;
402
403 if (!kobj->state_initialized) {
404 printk(KERN_ERR "kobject '%s' (%p): tried to add an "
405 "uninitialized object, something is seriously wrong.\n",
406 kobject_name(kobj), kobj);
407 dump_stack();
408 return -EINVAL;
409 }
410 va_start(args, fmt);
411 retval = kobject_add_varg(kobj, parent, fmt, args);
412 va_end(args);
413
414 return retval;
415 }
416 EXPORT_SYMBOL(kobject_add);
354 static __printf(3, 0) int kobject_add_varg(struct kobject *kobj,
355 struct kobject *parent,
356 const char *fmt, va_list vargs)
357 {
358 int retval;
359
360 retval = kobject_set_name_vargs(kobj, fmt, vargs);
361 if (retval) {
362 printk(KERN_ERR "kobject: can not set name properly!\n");
363 return retval;
364 }
365 kobj->parent = parent;
366 return kobject_add_internal(kobj);
367 }
200 static int kobject_add_internal(struct kobject *kobj)
201 {
202 int error = 0;
203 struct kobject *parent;
204
205 if (!kobj)
206 return -ENOENT;
207
208 if (!kobj->name || !kobj->name[0]) {
209 WARN(1, "kobject: (%p): attempted to be registered with empty "
210 "name!\n", kobj);
211 return -EINVAL;
212 }
213
214 parent = kobject_get(kobj->parent);
215
216 /* join kset if set, use it as parent if we do not already have one */
217 if (kobj->kset) {
218 if (!parent)
219 parent = kobject_get(&kobj->kset->kobj);
220 kobj_kset_join(kobj);
221 kobj->parent = parent;
222 }
223
224 pr_debug("kobject: '%s' (%p): %s: parent: '%s', set: '%s'\n",
225 kobject_name(kobj), kobj, __func__,
226 parent ? kobject_name(parent) : "<NULL>",
227 kobj->kset ? kobject_name(&kobj->kset->kobj) : "<NULL>");
228
229 error = create_dir(kobj);
230 if (error) {
231 kobj_kset_leave(kobj);
232 kobject_put(parent);
233 kobj->parent = NULL;
234
235 /* be noisy on error issues */
236 if (error == -EEXIST)
237 WARN(1, "%s failed for %s with "
238 "-EEXIST, don't try to register things with "
239 "the same name in the same directory.\n",
240 __func__, kobject_name(kobj));
241 else
242 WARN(1, "%s failed for %s (error: %d parent: %s)\n",
243 __func__, kobject_name(kobj), error,
244 parent ? kobject_name(parent) : "'none'");
245 } else
246 kobj->state_in_sysfs = 1;
247
248 return error;
249 }
可以看到，kobject_add有三个参数。该函数功能是将该内核对象添加到sysfs内。因此第一个参数指明了要注册的内核对象，第二个参数配置了该对象的父类，可以为NULL。第三个参数为该内核对象的名称。我之前会疑惑为什么内核对象的名称不在初始化的时候指定，现在想想，在注册的时候才指定，其实也可以理解。毕竟只有注册进了sysfs，名称才有意义。
函数的主题功能集中在kobject_add_internal内。下面逐一分析：
- 214行对父类加以引用。parent作为本内核模块的父类，那么对于本内核模块来说是一个依赖。对其加引用保证了在自身被释放之前，父类不会被释放。为了形成对应，在注销函数内，一定会释放这个引用；
- 229行在sysfs下创建目录和之下的属性文件，具体创建的位置，由parent决定；
- kset暂时略过，在别的篇章详细分析。
由此可得，kobject_add唯一作用就是在sysfs里创建层次化的目录，而这种层次都是parent带来的。逻辑上的父子概念，在sysfs内形成了目录的包含概念。
到了这里，其实不妨对之前的测试模块添加注册和注销函数，感受下父子关系与目录子目录关系的转换。
在这之后，我们终于可以深入开始分析kobj_type。在分析之后，争取写一个真正的ktype。
release函数实际上就是自定义的kobject的释放函数。我们曾在674行调用kobject_cleanup释放obj，但没有具体分析，现代码列如下：
615 static void kobject_cleanup(struct kobject *kobj)
616 {
617 struct kobj_type *t = get_ktype(kobj);
618 const char *name = kobj->name;
619
620 pr_debug("kobject: '%s' (%p): %s, parent %p\n",
621 kobject_name(kobj), kobj, __func__, kobj->parent);
622
623 if (t && !t->release)
624 pr_debug("kobject: '%s' (%p): does not have a release() "
625 "function, it is broken and must be fixed.\n",
626 kobject_name(kobj), kobj);
627
628 /* send "remove" if the caller did not do it but sent "add" */
629 if (kobj->state_add_uevent_sent && !kobj->state_remove_uevent_sent) {
630 pr_debug("kobject: '%s' (%p): auto cleanup 'remove' event\n",
631 kobject_name(kobj), kobj);
632 kobject_uevent(kobj, KOBJ_REMOVE);
633 }
634
635 /* remove from sysfs if the caller did not do it */
636 if (kobj->state_in_sysfs) {
637 pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
638 kobject_name(kobj), kobj);
639 kobject_del(kobj);
640 }
641
642 if (t && t->release) {
643 pr_debug("kobject: '%s' (%p): calling ktype release\n",
644 kobject_name(kobj), kobj);
645 t->release(kobj);
646 }
647
648 /* free name if we allocated it */
649 if (name) {
650 pr_debug("kobject: '%s': free name\n", name);
651 kfree_const(name);
652 }
653 }
关键在645行，我们可以看见，最终的释放，调用的是我们注册进去的release函数。
attribute是一个属性，每一个属性在sysfs中对应一个文件，在该内核对象的目录下生成。在kobj_type内，attribute是一个二级指针，可以提供多个属性，一起注册。详细使用方法可以参考内核代码，有很多种范例。一定要谨记二级指针和数组指针的区别。这个我在编写测试用例的时候，没有参考内核代码是如何赋值的，结果犯了低级错误，导致了内核的崩溃。
209 struct sysfs_ops {
210 ssize_t (*show)(struct kobject *, struct attribute *, char *);
211 ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
212 };
操作方法实际上只有两个，一个show，一个store。上面介绍的属性只是一个单纯的属性，sysfs负责将属性和sysfs_ops联系起来，这涉及到文件系统的相关知识，这里不再赘述。只简单说一下过程：
attribute在sysfs下表现出是一个文件，打开该文件，将导致该文件的操作表和具体的sysfs_ops关联起来，对任意一个属性的读，将最终调用show，而写将调用store。写的内容或为读出内容而准备的缓冲区都被sysfs传递了下来，在函数里就是第三个参数。
但是这个属性文件是如何生成的呢？我们注意到229行的create_dir函数，将其展开：
66 static int create_dir(struct kobject *kobj)
67 {
68 const struct kobj_ns_type_operations *ops;
69 int error;
70
71 error = sysfs_create_dir_ns(kobj, kobject_namespace(kobj));
72 if (error)
73 return error;
74
75 error = populate_dir(kobj);
76 if (error) {
77 sysfs_remove_dir(kobj);
78 return error;
79 }
80
81 /*
82 * @kobj->sd may be deleted by an ancestor going away. Hold an
83 * extra reference so that it stays until @kobj is gone.
84 */
85 sysfs_get(kobj->sd);
86
87 /*
88 * If @kobj has ns_ops, its children need to be filtered based on
89 * their namespace tags. Enable namespace support on @kobj->sd.
90 */
91 ops = kobj_child_ns_ops(kobj);
92 if (ops) {
93 BUG_ON(ops->type <= KOBJ_NS_TYPE_NONE);
94 BUG_ON(ops->type >= KOBJ_NS_TYPES);
95 BUG_ON(!kobj_ns_type_registered(ops->type));
96
97 sysfs_enable_ns(kobj->sd);
98 }
99
100 return 0;
101 }
102
71行负责创建该obj对象对应的目录，这个函数最终会调用sysfs相关的文件系统接口创建目录，这里不再赘述。
75行负责创建属性对应的文件，我们将其展开：
49 static int populate_dir(struct kobject *kobj)
50 {
51 struct kobj_type *t = get_ktype(kobj);
52 struct attribute *attr;
53 int error = 0;
54 int i;
55
56 if (t && t->default_attrs) {
57 for (i = 0; (attr = t->default_attrs[i]) != NULL; i++) {
58 error = sysfs_create_file(kobj, attr);
59 if (error)
60 break;
61 }
62 }
63 return error;
64 }
56~62行，针对default_attr域进行检测以及遍历，对每一个attr创建文件，直到为NULL。因此，我们在对属性进行赋值的时候，最后一个属性一定需要赋值为NULL。虽然有时候系统会自动赋值为NULL，但是手动赋值为NULL更加安全。58行其实也是sysfs的创建文件的接口。具体实现略去不提。
分析到这里，其实又可以为自己的测试模块，添加一个真正的属性了。来验证一下，对属性的读写，是否真实的调用了show和store函数。
在测试之后，进入kobj的最后一个环节。我们之前提到过，kobj可以创建多个自定义的属性，对每个属性的操作方法也不同。然而，上面所说的，却是一对show和store函数统治所有属性。那么如何保证每个属性的都有自己的个性化操作呢？一个最简单的办法就是在函数内部调用swith函数判断是哪个属性下发的操作，然后进入自己的分支。但是这样的操作方式代码可读性，结构性不好。内核从来不使用这样的方法。下面我们介绍内核的使用方法。
下面是内核中一个模块实现的show方法：
113 static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
114 char *buf)
115 {
116 struct device_attribute *dev_attr = to_dev_attr(attr);
117 struct device *dev = kobj_to_dev(kobj);
118 ssize_t ret = -EIO;
119
120 if (dev_attr->show)
121 ret = dev_attr->show(dev, dev_attr, buf);
122 if (ret >= (ssize_t)PAGE_SIZE) {
123 print_symbol("dev_attr_show: %s returned bad count\n",
124 (unsigned long)dev_attr->show);
125 }
126 return ret;
127 }
116行，实际是一个container_of宏，我们看出来，实际上，内核会将struct attribute进行再封装，通过该宏取出个性化的属性，在121行调用自己的show方法。采用这种方法，便于添加属性也便于管理。下面贴出个性化的属性定义：
548 struct device_attribute {
549 struct attribute attr;
550 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
551 char *buf);
552 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
553 const char *buf, size_t count);
554 };
到这里，kobj相关的部分就分析完了，下面我们将进入kset的分析。当然，别忘了，按照内核里的个性化属性方法，编写自己的测试用例。