kobject设备模型分析.pdfVIP

  sysfs 是kobject 的表达，所以这里翻译了Documention 下的kobjct.txt，并加上了一些自己的注释，这样基本就对kobject 和sysfs 有了一个比较深刻的理解，我们可以简单的将sysfs 看成最bottom 的操作，然后kobject 的想关操作是架构在sysfs 之上，再然后kobject 和attribute 所嵌入的结构体再构成上一层结构来操作kobject，最后就实现了kernel 内部各个portion 通过sysfs 与userspace 进行交互。 要想了解linux 驱动模型，以及驱动模型之上的kobject 抽象，有一个难点就是我们没有一个明确的入手点。要想了解kobject 我们必须了解很多不同的类型，而这些类型之间又会交叉引用，所以为了让理解更容易我们从多方面入手，首先看一些可能模 糊不清的概念，然后随着深入我们会加入细节，在最后我们会定义一些我们工作上需要使用的术语。 kobject 是一个结构体，它包含name，reference count 以及指向一个parent 的指针(这个指针等于就是将kobject 加入了 一个体系结构中)，一个特定的类型，以及在sysfs 文件系统中的一个相关表达。kobject 一般不会单独使用，大部分的时候它 会被嵌入其他的结构体，而这些结构体才是我们代码中真正需要的。一个结构体最多只能嵌入一个kobject，不然reference count 就会乱掉，出错。 (PS：实际上我们可以理解这个kobject 实际上是我们与sysfs 进行交互的一个接口，我们在设备驱动以及总线相关的结构体 中嵌入这个kobject，那么我们的设备驱动就可以通过sysfs 与userspace 进行交互了。虽然sysfs 是kobject 的表达，但我 们可以近似的将kobject 看成是架在sysfs 上面的，在kobject 上面封装的一系列操作实际上到底层都是调用的sysfs 的公共 接口) struct kobject { const char *name; 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 的结构体的类型，每一个嵌入了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_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;