|
Linux 2.6内核的一个重要特色是提供了统一的内核设备模型。随着技术的不断进步，系统的拓扑结构越来越复杂，对智能电源管理、热插拔以及plug and play的支持要求也越来越高，2.4内核已经难以满足这些需求。为适应这种形势的需要，2.6内核开发了全新的设备模型。 2.6 设备模型提供了这个抽象. 现在它用在内核来支持广泛的任务, 包括: 电源管理和系统关机 这些需要一个对系统的结构的理解. 例如, 一个 USB 宿主适配器不可能被关闭, 在处理所有的连接到这个适配器的设备之前. 这个设备模型使能了一个按照正确顺序的系统硬件的遍历. 与用户空间的通讯 sysfs 虚拟文件系统的实现被紧密地捆绑进设备模型, 并且暴露它所代表的结构. 关于系统到用户空间的信息提供和改变操作参数的旋纽正越来越多地通过 sysfs 和 通过设备模型来完成. 可热插拔设备 计算机硬件正更多地动态变化; 外设可因用户的一时念头而进出. 在内核中使用的来处理和(特别的)与用户空间关于设备插入和拔出的通讯, 是由设备模型来管理. 设备类别 系统的许多部分对设备如何连接没有兴趣, 但是它们需要知道什么类型的设备可用. 设备模型包括一个机制来分配设备给类别, 它在一个更高的功能性的级别描述了这些设备, 并且允许它们从用户空间被发现. 对象生命期 许多上面描述的功能, 包括热插拔支持和 sysfs, 使在内核中创建和操作对象复杂了. 设备模型的实现要求创建一套机制来处理对象生命期, 它们之间的关系, 和它们在用户空间的表示.
１． Sysfs文件系统
Sysfs文件系统是一个类似于proc文件系统的特殊文件系统，用于将系统中的设备组织成层次结构，并向用户模式程序提供详细的内核数据结构信息。其顶层目录主要有：
Block目录：包含所有的块设备
Devices目录：包含系统所有的设备，并根据设备挂接的总线类型组织成层次结构
Bus目录：包含系统中所有的总线类型
Drivers目录：包括内核中所有已注册的设备驱动程序
Class目录：系统中的设备类型（如网卡设备，声卡设备等）
２． 内核对象机制关键数据结构
2.1 kobject内核对象
Kobject 是Linux 2.6引入的新的设备管理机制，在内核中由struct kobject表示。通过这个数据结构使所有设备在底层都具有统一的接口，kobject提供基本的对象管理，是构成Linux 2.6设备模型的核心结构，它与sysfs文件系统紧密关联，每个在内核中注册的kobject对象都对应于sysfs文件系统中的一个目录。
Kobject 是基础的结构, 它保持设备模型在一起. 初始地它被作为一个简单的引用计数, 但是它的责任已随时间增长, 并且因此有了它自己的战场. struct kobject 所处理的任务和它的支持代码现在包括: 对象的引用计数 常常, 当一个内核对象被创建, 没有方法知道它会存在多长时间. 一种跟踪这种对象生命周期的方法是通过引用计数. 当没有内核代码持有对给定对象的引用, 那个对象已经完成了它的有用寿命并且可以被删除. sysfs 表示 在 sysfs 中出现的每个对象在它的下面都有一个 kobject, 它和内核交互来创建它的可见表示. 数据结构粘和 设备模型是, 整体来看, 一个极端复杂的由多级组成的数据结构, 各级之间有许多连接. kobject 实现这个结构并且保持它在一起. 热插拔事件处理 kobject 子系统处理事件的产生, 事件通知用户空间关于系统中硬件的来去. 你可能从前面的列表总结出 kobject 是一个复杂的结构. 这可能是对的. 通过一次看一部分, 但是, 是有可能理解这个结构和它如何工作的. Kobject结构定义为： struct kobject {
char * k_name; 指向设备名称的指针
char name[KOBJ_NAME_LEN]; 设备名称
struct kref kref; 对象引用计数
struct list_head entry; 挂接到所在kset中去的单元
struct kobject * parent; 指向父对象的指针
struct kset * kset; 所属kset的指针
struct kobj_type * ktype; 指向其对象类型描述符的指针
struct dentry * dentry; sysfs文件系统中与该对象对应的文件节点路径指针
}; |
其中的kref域表示该对象引用的计数，内核通过kref实现对象引用计数管理，内核提供两个函数kobject_get()、kobject_put()分别用于增加和减少引用计数，当引用计数为0时，所有该对象使用的资源将被释放。
Ktype域是一个指向kobj_type结构的指针，表示该对象的类型。Kobj_type数据结构包含三个域： 一个release方法用于释放kobject占用的资源； 一个sysfs_ops指针指向sysfs操作表和一个sysfs文件系统缺省属性列表。 Sysfs操作表包括两个函数store()和 show()。当用户态读取属性时，show()函数被调用，该函数编码指定属性值存入buffer中返回给用户态；而store()函数用于存储用户态传入的属性值。
2.2 kset内核对象集合
Kobject通常通过kset组织成层次化的结构，kset是具有相同类型的kobject的集合，在内核中用kset数据结构表示，定义为：
struct kset {
struct subsystem * subsys; 所在的subsystem的指针
struct kobj_type * ktype; 指向该kset对象类型描述符的指针
struct list_head list; 用于连接该kset中所有kobject的链表头
struct kobject kobj; 嵌入的kobject
struct kset_hotplug_ops * hotplug_ops; 指向热插拔操作表的指针
}; |
包含在kset中的所有kobject被组织成一个双向循环链表，list域正是该链表的头。Ktype域指向一个kobj_type结构，被该 kset中的所有kobject共享，表示这些对象的类型。Kset数据结构还内嵌了一个kobject对象（由kobj域表示），所有属于这个kset 的kobject对象的parent域均指向这个内嵌的对象。此外，kset还依赖于kobj维护引用计数：kset的引用计数实际上就是内嵌的 kobject对象的引用计数。
2.3 subsystem内核对象子系统
Subsystem是一系列kset的集合，描述系统中某一类设备子系统，如block_subsys表示所有的块设备，对应于sysfs文件系统中的block目录。类似的，devices_subsys对应于sysfs中的devices目录，描述系统中所有的设备。Subsystem由struct subsystem数据结构描述，定义为：
struct subsystem {
struct kset kset; 内嵌的kset对象
struct rw_semaphore rwsem; 互斥访问信号量
}; |
每个kset必须属于某个subsystem，通过设置kset结构中的subsys域指向指定的subsystem可以将一个kset加入到该subsystem。所有挂接到同一subsystem的kset共享同一个rwsem信号量，用于同步访问kset中的链表。 ３． 内核对象机制主要相关函数
针对内核对象不同层次的数据结构，linux 2.6内核定义了一系列操作函数，定义于lib/kobject.c文件中。
3.1 kobject相关函数
void kobject_init(struct kobject * kobj)；
kobject初始化函数。设置kobject引用计数为１，entry域指向自身，其所属kset引用计数加１。
int kobject_set_name(struct kobject *kobj, const char *format, ...)；
设置指定kobject的名称。
void kobject_cleanup(struct kobject * kobj)和void kobject_release(struct kref *kref)；
kobject清除函数。当其引用计数为０时，释放对象占用的资源。
struct kobject *kobject_get(struct kobject *kobj)；
将kobj 对象的引用计数加1，同时返回该对象的指针。
void kobject_put(struct kobject * kobj)；
将kobj对象的引用计数减1，如果引用计数降为0，则调用kobject_release()释放该kobject对象。
int kobject_add(struct kobject * kobj)；
将kobj对象加入Linux设备层次。挂接该kobject对象到kset的list链中，增加父目录各级kobject的引用计数，在其parent指向的目录下创建文件节点，并启动该类型内核对象的hotplug函数。
int kobject_register(struct kobject * kobj)；
kobject注册函数。通过调用kobject_init()初始化kobj，再调用kobject_add()完成该内核对象的注册。
void kobject_del(struct kobject * kobj)；
从Linux设备层次(hierarchy)中删除kobj对象。
void kobject_unregister(struct kobject * kobj)；
kobject注销函数。与kobject_register()相反，它首先调用kobject_del从设备层次中删除该对象，再调用kobject_put()减少该对象的引用计数，如果引用计数降为0，则释放该kobject对象。
3.2 kset相关函数
与kobject 相似，kset_init()完成指定kset的初始化，kset_get()和kset_put()分别增加和减少kset对象的引用计数。 Kset_add()和kset_del()函数分别实现将指定keset对象加入设备层次和从其中删除；kset_register()函数完成 kset的注册而kset_unregister()函数则完成kset的注销。
3.3 subsystem相关函数
subsystem有一组完成类似的函数，分别是：
void subsystem_init(struct subsystem *subsys);
int subsystem_register(struct subsystem *subsys);
void subsystem_unregister(struct subsystem *subsys);
struct subsystem *subsys_get(struct subsystem *subsys)
void subsys_put(struct subsystem *subsys); |
４． 设备模型组件
在上述内核对象机制的基础上，Linux的设备模型建立在几个关键组件的基础上，下面我们详细阐述这些组件。
4.1 devices
系统中的任一设备在设备模型中都由一个device对象描述，其对应的数据结构struct device定义为：
struct device {
struct list_head g_list;
struct list_head node;
struct list_head bus_list;
struct list_head driver_list;
struct list_head children;
struct device *parent;
struct kobject kobj;
char bus_id[BUS_ID_SIZE];
struct bus_type *bus;
struct device_driver *driver;
void *driver_data;
/* Several fields omitted */
}; |
g_list 将该device对象挂接到全局设备链表中，所有的device对象都包含在devices_subsys中，并组织成层次结构。Node域将该对象挂接到其兄弟对象的链表中，而bus_list则用于将连接到相同总线上的设备组织成链表，driver_list则将同一驱动程序管理的所有设备组织为链表。此外，children域指向该device对象子对象链表头，parent域则指向父对象。Device对象还内嵌一个kobject对象，用于引用计数管理并通过它实现设备层次结构。Driver域指向管理该设备的驱动程序对象，而driver_data则是提供给驱动程序的数据。Bus域描述设备所连接的总线类型。
内核提供了相应的函数用于操作device对象。其中Device_register()函数将一个新的device对象插 入设备模型，并自动在/sys/devices下创建一个对应的目录。Device_unregister()完成相反的操作，注销设备对象。Get_device()和put_device()分别增加与减少设备对象的引用计数。通常device结构不单独使用，而是包含在更大的结构中作为一个子结构使用，比如描述PCI设备的struct pci_dev，其中的dev域就是一个device对象。
4.2 drivers
系统中的每个驱动程序由一个device_driver对象描述，对应的数据结构定义为：
struct device_driver {
char *name; 设备驱动程序的名称
struct bus_type *bus; 该驱动所管理的设备挂接的总线类型
struct kobject kobj; 内嵌kobject对象
struct list_head devices; 该驱动所管理的设备链表头
int (*probe)(struct device *dev); 指向设备探测函数，用于探测设备是否可以被该驱动程序管理
int (*remove)(struct device *dev); 用于删除设备的函数
/* some fields omitted*/
}； |
与device结构类似，device_driver对象依靠内嵌的kobject对象实现引用计数管理和层次结构组织。内核提供类似的函数用于操作 device_driver对象，如get_driver()增加引用计数，driver_register()用于向设备模型插入新的driver对象，同时在sysfs文件系统中创建对应的目录。Device_driver()结构还包括几个函数，用于处理热拔插、即插即用和电源管理事件。
4.3 buses
系统中总线由struct bus_type描述，定义为：
struct bus_type {
char * name; 总线类型的名称
struct subsystem subsys; 与该总线相关的subsystem
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, u32 state);
int (*resume)(struct device * dev);
}；
|
每个bus_type对象都内嵌一个subsystem对象，bus_subsys对象管理系统中所有总线类型的subsystem对象。每个bus_type对象都对应/sys/bus目录下的一个子目录，如PCI总线类型对应于/sys/bus/pci。在每个这样的目录下都存在两个子目 录：devices和drivers（分别对应于bus_type结构中的devices和drivers域）。其中devices子目录描述连接在该总线上的所有设备，而drivers目录则描述与该总线关联的所有驱动程序。与device_driver对象类似，bus_type结构还包含几个函数（match()、hotplug()等）处理相应的热插拔、即插即拔和电源管理事件。
4.4 classes
系统中的设备类由 struct class描述，表示某一类设备。所有的class对象都属于class_subsys子系统，对应于sysfs文件系统中的/sys/class目录。 每个class对象包括一个class_device链表，每个class_device对象表示一个逻辑设备，并通过struct class_device中的dev域（一个指向struct device的指针）关联一个物理设备。这样，一个逻辑设备总是对应于一个物理设备，但是一个物理设备却可能对应于多个逻辑设备。此外，class结构中 还包括用于处理热插拔、即插即拔和电源管理事件的函数，这与device对象和driver对象相似。
总线, 设备, 和驱动 至今, 我们已经看到大量低级框架和一个相对少的例子. 我们试图在本章剩下部分中补充, 随着我们进入 Linux 设备模型的更高级. 为此, 我们介绍一个新的虚拟总线, 我们称为 lddbus, [46 ]并且修改 scullp 驱动来 "接入" 到这个总线. 再一次, 许多驱动作者将不会需要这里涉及的材料. 这个水平的细节通常在总线级别处理, 并且很少作者需要添加一个新总线类型. 这个信息是有用的, 但是, 对任何人好奇在 PCI, USB 等层面的里面发生了什么或者谁需要在那个级别做改变. 14.4.1. 总线 一个总线是处理器和一个或多个设备之间的通道. 为设备模型的目的, 所有的设备都通过一个总线连接, 甚至当它是一个内部的虚拟的,"平台"总线. 总线可以插入另一个 - 一个 USB 控制器常常是一个 PCI 设备, 例如. 设备模型表示在总线和它们控制的设备之间的实际连接. 在 Linux 设备模型中, 一个总线由 bus_type 结构代表, 定义在 <linux/device.h>. 这个结构看来象: struct bus_type { char *name; struct subsystem subsys; struct kset drivers; struct kset devices; int (*match)(struct device *dev, struct device_driver *drv); struct device *(*add)(struct device * parent, char * bus_id); int (*hotplug) (struct device *dev, char **envp, int num_envp, char *buffer, int buffer_size); /* Some fields omitted */ }; name 成员是总线的名子, 有些同 pci. 你可从这个结构中见到每个总线是它自己的子系统; 这个子系统不位于 sysfs 的顶层, 但是. 相反, 它们在总线子系统下面. 一个总线包含 2 个 ksets, 代表已知的总线的驱动和所有插入总线的设备. 所以, 有一套方法我们马上将涉及. 14.4.1.1. 总线注册 如同我们提过的, 例子源码包含一个虚拟总线实现称为 lddbus. 这个总线建立它的 bus_type 结构, 如下: struct bus_type ldd_bus_type = { .name = "ldd", .match = ldd_match, .hotplug = ldd_hotplug, }; 注意很少 bus_type 成员要求初始化; 大部分由设备模型核心处理. 但是, 我们确实不得不指定总线的名子, 以及任何伴随它的方法. 不可避免地, 一个新总线必须注册到系统, 通过一个对 bus_register 的调用. lddbus 代码这样做以这样的方式: ret = bus_register(&ldd_bus_type); if (ret) return ret; 这个调用可能失败, 当然, 因此返回值必须一直检查. 如果它成功, 新总线子系统已被添加到系统; 在 sysfs 中 /sys/bus 的下面可以见到, 并且可能启动添加设备. 如果有必要从系统中去除一个总线(当关联模块被去除, 例如), 调用调用 bus_unregister: void bus_unregister(struct bus_type *bus); 14.4.1.2. 总线方法 有几个给 bus_type 结构定义的方法; 它们允许总线代码作为一个设备核心和单独驱动之间的中介. 在 2.6.10 内核中定义的方法是: int (*match)(struct device *device, struct device_driver *driver); 这个方法被调用, 大概多次, 无论何时一个新设备或者驱动被添加给这个总线. 它应当返回一个非零值如果给定的设备可被给定的驱动处理. (我们马上进入设备和 device_driver 结构的细节). 这个函数必须在总线级别处理, 因为那是合适的逻辑存在的地方; 核心内核不能知道如何匹配每个可能总线类型的设备和驱动. int (*hotplug) (struct device *device, char **envp, int num_envp, char *buffer, int buffer_size); 这个模块允许总线添加变量到环境中, 在产生一个热插拔事件在用户空间之前. 参数和 kset 热插拔方法相同( 在前面的 "热插拔事件产生" 一节中描述 ). lddbus 驱动有一个非常简单的匹配函数, 它仅仅比较驱动和设备的名子: static int ldd_match(struct device *dev, struct device_driver *driver) { return !strncmp(dev->bus_id, driver->name, strlen(driver->name)); } 当涉及到真实硬件, match 函数常常在有设备自身提供的硬件 ID 和驱动提供的 ID 之间, 做一些比较. lddbus 热插拔方法看来象这样: static int ldd_hotplug(struct device *dev, char **envp, int num_envp, char *buffer, int buffer_size) { envp[0] = buffer; if (snprintf(buffer, buffer_size, "LDDBUS_VERSION=%s", Version) >= buffer_size) return -ENOMEM; envp[1] = NULL; return 0; } 这里, 我们加入 lddbus 源码的当前版本号, 只是以防有人好奇.
| 
發表於 2015-9-29 16:33:50
狗仔卡
