设备模型之kobject,kset及其关系

Linux2.6以后的设备驱动，都是在设备模型的基础上构建的，因此，要编写linux下的设备驱动程序，不论是usb设备，pci设备等，都需要了解设备模型。

设备模型的基础结构体主要是kobject，kset这两个结构体：

struct kobject {

   char      * k_name;

   char      name[KOBJ_NAME_LEN];

   struct kref    kref;

   struct list_head  entry;

   struct kobject    * parent;

   struct kset    * kset;

   struct kobj_type  * ktype;

   struct dentry     * dentry;

};

 

struct kset {

   struct subsystem  * subsys;

   struct kobj_type  * ktype;

   struct list_head  list;

   struct kobject    kobj;

   struct kset_hotplug_ops  * hotplug_ops;

};

 

还有一个subsys结构体，但subsys结构体跟kset差不多，就多了一个互斥访问信号量，因此，就不需要列出了，另外还有一个结构体

struct kobj_type {

   void (*release)(struct kobject *);

   struct sysfs_ops  * sysfs_ops;

   struct attribute  ** default_attrs;

 };

用来表示kobject，kset的类型。 

一个kobject结构如下图的kobject 类型部分，而一个kset结构如下图的kset 类型部分，一个kobject加入一个kset，主要是kobject结构体中的相关字段记录了对应的kset信息，①记录了kobject所对应 kset，其所指向的是kset所包含的kobject的地址，②记录了kobject所对应的kset的kset指针，③记录了kobject的类 型，④记录了kset所有的kobject的链子，这个链子是一个双向链表，每当有一个kobject加入到当前的kset,就会调用 list_add_tail()函数，把要加入kset的kobject连入链表的结尾，最终形成一个链表。

当有另外一个kobject要加入当前的kset，其中的①②③步跟第一个加入当前kset的kobject是一样的，即把要加入 的kobject的成员设置，使之指向当前的kset对应数据，而④需要把kobject添加到kset的list的尾部，下图表示了kobject b加入到kset A的图示：

当有一个kset，需要加入到当前的kset,其方法也跟一个kobject要加入到当前kset一样，即把要加入的kset中所 包含的kobject的成员设置，使这些成员指向对应的kset的对应数据。而当前kset要加入另一个kset，其方式也是跟一个kset加入到当前 kset一样，都是设备kset中的kobject，使kobject的成员指向要加入的kset的对应数据即可，下图显示了一个kset B加入到kset A中的图示。

一个简单的kset,kobject关系图如下：

设备驱动基础1：设备模型之总线，驱动，设备

Kobject，kset 是设备模型的基本结构体，设备模型使用这两个结构体来完成设备的层次关系，但在实际的设备驱动编写中，我们基本上用不到kobject,kset这些结构 体，是因为这些结构体又被嵌入到更大的结构体中，原因在于kobject，kset结构体只能表征设备的层次关系，但是一个设备的驱动，并不是简单的一个 层次关系而已，因此，必需要把kobject，kset结构体嵌入到更大的结构体中，使用kobject,kset来表征层次关系，用其他的成员表示设备 驱动的具体功能。

在设备模型中，我们将看到，设备驱动主要是由总线，驱动程序，设备三个部分构成，通过这三个标准部件，把各种纷繁杂乱的设备归结过来，达到简化设备驱动编写的目的，也即我们编写的设备驱动，其实也只是这三部分中的一个很小的部分的。

 

我们编写的设备驱动程序，一定是先属于一个总线的驱动，比如属于 USB总线，或者属于PCI总线，或者属于I2C总线，等等，因为我们编写的设备驱动，在注册，安装到系统时，系统会先检查驱动是属于哪个总线的（设备驱 动编写时已经定义好），会把驱动加入到对应的总线的kset中，即把当前设备驱动的kobject加入到对应总线的kset中，形成层次关联。而当系统检 测到有设备存在（硬件），也会先判断设备是属于哪个总线的（硬件连接），然后遍历当前总线下的所有设备驱动程序，通过所属总线的探测函数，查找是否有设备 驱动程序匹配可以驱动当前的设备（一般是通过获得设备的PID，VID，跟驱动程序的PID，VID比较，看是否匹配而定），如果有驱动程序可以驱动设 备，则把当前设备也加入到所属总线的kset中，如果没有可驱动设备的驱动程序，则只能在总线的设备链表中存在，而如果设备都无法通过总线的匹配，则也没 有办法存在于总线的设备链表中。由于一条总线要管理总线上的所有驱动，同时要管理总线上的有所设备，则需要再把所有设备和所有驱动都分开，分别设立一个设 备kset和一个设备驱动kset，用于管理所有的设备和设备驱动，如此，则总线kset实际上包含了两个kset（设备kset，设备驱动kset）， 设备kset又包含了所有的当前总线的设备的kobject，设备驱动kset包含了所有的当前总线的设备驱动的kobject；而所有的总线，又形成了 bus的kset，归结起来就形成下图的层次关系：

每个设备，都被挂接到不同的总线上，当设备挂接到对应的总线上 后，其所对应的总线类型就确定了，而设备在挂接到总线上时，总线先要扫描设备，看看设备是否适合总线的要求，如果适合了，那接着就要扫描整个总线上的设备 驱动链表，查找是否有驱动程序可以管理设备，如果找到，则把设备结构体中的相应指针成员指向对应的驱动程序，如果暂时没有找到对应的设备驱动程序，则设备 结构体中的指向驱动程序的指针暂时为空，表示还没有设备驱动，还在总线的设备队列中等待；而如果设备不能通过总线的检查，即不会出现在总线的设备列表上， 自然不会去扫描设备驱动链表，查找匹配的驱动了。

而每个设备驱动程序，都是被安装到对应的总线上的，不论是手动安 装，还是自动安装，所谓安装，就是把驱动程序挂载到对应总线的驱动链表中，而挂载到对应的总线驱动链表，首先要满足总线的匹配要求，只有适合了要求，才能 挂载到总线的驱动链表，也只有到达这个步骤，系统才会扫描整个总线的设备链表，来查找是否有设备需要此驱动来管理，如果找到这个设备，则驱动程序中的设备 管理链表，会记录这个设备的地址，从而达到管理设备的目的。

经过上述的设备插入，或者驱动安装，系统就会出现只有设备，而没 有设备驱动程序的情况，也会出现，只有设备驱动程序，没有对应的设备的情况，此时，设备或者设备驱动程序，就会暂时在各自的队列里等待，一旦有驱动程序安 装，或新的设备插入，就都会自动的去扫描对应的链表，来检测是否有配对的可能。

综合上述三者的关系，如图：

 

Linux设备模型 之 总线类型 - bus_typebus_type

相关数据结构：

struct bus_type {
 char   * name;

 struct subsystem subsys;
 struct kset  drivers;
 struct kset  devices;

 struct bus_attribute * bus_attrs;
 struct device_attribute * dev_attrs;
 struct driver_attribute * drv_attrs;

 int  (*match)(struct device * dev, struct device_driver * drv);
 int  (*hotplug) (struct device *dev, char **envp,
        int num_envp, char *buffer, int buffer_size);
 int  (*suspend)(struct device * dev, pm_message_t state);
 int  (*resume)(struct device * dev);
};

内核所支持的每一种总线类型都由一个bus_type对象表示。
bus_type中内嵌了一个subsystem - subsys。
系统中的bus_subsys子系统将所有的bus_type中的subsys集合在一起。
bus_subsys对应sysfs中的/sys/bus目录.

另外，bus_type中有两个内嵌的kset对象：devices 和 drivers。分别表示该bus上的设备和驱动。

函数bus_for_each_dev() 和 bus_for_each_drv()分别用于遍历bus上devices和drivers链表中的所有元素。