| Linux 2.6内核的一个重要特色是提供了统一的内核设备模型。随着技术的不断进步，系统的拓扑结构越来越复杂，对智能电源管理、热插拔以及plug and play的支持要求也越来越高，2.4内核已经难以满足这些需求。为适应这种形势的需要，2.6内核开发了全新的设备模型。 2.6 设备模型提供了这个抽象. 现在它用在内核来支持广泛的任务, 包括: 电源管理和系统关机 这些需要一个对系统的结构的理解. 例如, 一个 USB 宿主适配器不可能被关闭, 在处理所有的连接到这个适配器的设备之前. 这个设备模型使能了一个按照正确顺序的系统硬件的遍历. 与用户空间的通讯 sysfs 虚拟文件系统的实现被紧密地捆绑进设备模型, 并且暴露它所代表的结构. 关于系统到用户空间的信息提供和改变操作参数的旋纽正越来越多地通过 sysfs 和 通过设备模型来完成. 可热插拔设备 计算机硬件正更多地动态变化; 外设可因用户的一时念头而进出. 在内核中使用的来处理和(特别的)与用户空间关于设备插入和拔出的通讯, 是由设备模型来管理. 设备类别 系统的许多部分对设备如何连接没有兴趣, 但是它们需要知道什么类型的设备可用. 设备模型包括一个机制来分配设备给类别, 它在一个更高的功能性的级别描述了这些设备, 并且允许它们从用户空间被发现. 对象生命期 许多上面描述的功能, 包括热插拔支持和 sysfs, 使在内核中创建和操作对象复杂了. 设备模型的实现要求创建一套机制来处理对象生命期, 它们之间的关系, 和它们在用户空间的表示.
Kobject 是基础的结构, 它保持设备模型在一起. 初始地它被作为一个简单的引用计数, 但是它的责任已随时间增长, 并且因此有了它自己的战场. struct kobject 所处理的任务和它的支持代码现在包括: 对象的引用计数 常常, 当一个内核对象被创建, 没有方法知道它会存在多长时间. 一种跟踪这种对象生命周期的方法是通过引用计数. 当没有内核代码持有对给定对象的引用, 那个对象已经完成了它的有用寿命并且可以被删除. sysfs 表示 在 sysfs 中出现的每个对象在它的下面都有一个 kobject, 它和内核交互来创建它的可见表示. 数据结构粘和 设备模型是, 整体来看, 一个极端复杂的由多级组成的数据结构, 各级之间有许多连接. kobject 实现这个结构并且保持它在一起. 热插拔事件处理 kobject 子系统处理事件的产生, 事件通知用户空间关于系统中硬件的来去. 你可能从前面的列表总结出 kobject 是一个复杂的结构. 这可能是对的. 通过一次看一部分, 但是, 是有可能理解这个结构和它如何工作的. Kobject结构定义为：
其中的kref域表示该对象引用的计数，内核通过kref实现对象引用计数管理，内核提供两个函数kobject_get()、kobject_put()分别用于增加和减少引用计数，当引用计数为0时，所有该对象使用的资源将被释放。 一个release方法用于释放kobject占用的资源； 一个sysfs_ops指针指向sysfs操作表和一个sysfs文件系统缺省属性列表。 Sysfs操作表包括两个函数store()和 show()。当用户态读取属性时，show()函数被调用，该函数编码指定属性值存入buffer中返回给用户态；而store()函数用于存储用户态传入的属性值。
包含在kset中的所有kobject被组织成一个双向循环链表，list域正是该链表的头。Ktype域指向一个kobj_type结构，被该 kset中的所有kobject共享，表示这些对象的类型。Kset数据结构还内嵌了一个kobject对象（由kobj域表示），所有属于这个kset 的kobject对象的parent域均指向这个内嵌的对象。此外，kset还依赖于kobj维护引用计数：kset的引用计数实际上就是内嵌的 kobject对象的引用计数。
每个kset必须属于某个subsystem，通过设置kset结构中的subsys域指向指定的subsystem可以将一个kset加入到该subsystem。所有挂接到同一subsystem的kset共享同一个rwsem信号量，用于同步访问kset中的链表。
３． 内核对象机制主要相关函数
g_list 将该device对象挂接到全局设备链表中，所有的device对象都包含在devices_subsys中，并组织成层次结构。Node域将该对象挂接到其兄弟对象的链表中，而bus_list则用于将连接到相同总线上的设备组织成链表，driver_list则将同一驱动程序管理的所有设备组织为链表。此外，children域指向该device对象子对象链表头，parent域则指向父对象。Device对象还内嵌一个kobject对象，用于引用计数管理并通过它实现设备层次结构。Driver域指向管理该设备的驱动程序对象，而driver_data则是提供给驱动程序的数据。Bus域描述设备所连接的总线类型。
与device结构类似，device_driver对象依靠内嵌的kobject对象实现引用计数管理和层次结构组织。内核提供类似的函数用于操作 device_driver对象，如get_driver()增加引用计数，driver_register()用于向设备模型插入新的driver对象，同时在sysfs文件系统中创建对应的目录。Device_driver()结构还包括几个函数，用于处理热拔插、即插即用和电源管理事件。
每个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()等）处理相应的热插拔、即插即拔和电源管理事件。
总线, 设备, 和驱动 至今, 我们已经看到大量低级框架和一个相对少的例子. 我们试图在本章剩下部分中补充, 随着我们进入 Linux 设备模型的更高级. 为此, 我们介绍一个新的虚拟总线, 我们称为 lddbus, [46 ]并且修改 scullp 驱动来 "接入" 到这个总线. 再一次, 许多驱动作者将不会需要这里涉及的材料. 这个水平的细节通常在总线级别处理, 并且很少作者需要添加一个新总线类型. 这个信息是有用的, 但是, 对任何人好奇在 PCI, USB 等层面的里面发生了什么或者谁需要在那个级别做改变. 在 Linux 设备模型中, 一个总线由 bus_type 结构代表, 定义在 <linux/device.h>. 这个结构看来象: 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); 如同我们提过的, 例子源码包含一个虚拟总线实现称为 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); 这个调用可能失败, 当然, 因此返回值必须一直检查. 如果它成功, 新总线子系统已被添加到系统; 在 sysfs 中 /sys/bus 的下面可以见到, 并且可能启动添加设备. 如果有必要从系统中去除一个总线(当关联模块被去除, 例如), 调用调用 bus_unregister: void bus_unregister(struct bus_type *bus); 有几个给 bus_type 结构定义的方法; 它们允许总线代码作为一个设备核心和单独驱动之间的中介. 在 2.6.10 内核中定义的方法是: int (*match)(struct device *device, struct device_driver *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 之间, 做一些比较. static int ldd_hotplug(struct device *dev, char **envp, int num_envp, char *buffer, int buffer_size) if (snprintf(buffer, buffer_size, "LDDBUS_VERSION=%s", 这里, 我们加入 lddbus 源码的当前版本号, 只是以防有人好奇. 如果你在编写总线级别的代码, 你可能不得不对所有已经注册到你的总线的设备或驱动进行一些操作. 它可能会诱惑人直接进入 bus_type 结构中的各种结构, 但是最好使用已经提供的帮助函数. 这个函数就像 buf_for_each_dev, 除了, 当然, 它替之作用于驱动. 几乎 Linux 驱动模型中的每一层都提供一个添加属性的接口, 并且总线层不例外. bus_attribute 类型定义在 <linux/device.h> 如下: ssize_t (*show)(struct bus_type *bus, char *buf); ssize_t (*store)(struct bus_type *bus, const char *buf, 已经提供了一个方便的宏为在编译时间创建和初始化 bus_attribute 结构: BUS_ATTR(name, mode, show, store); 这个宏声明一个结构, 产生它的名子通过前缀字符串 bus_attr_ 到给定的名子. 任何属于一个总线的属性应当明确使用 bus_create_file 来创建: int bus_create_file(struct bus_type *bus, struct bus_attribute *attr); void bus_remove_file(struct bus_type *bus, struct bus_attribute *attr); lddbus 驱动创建一个简单属性文件, 再次, 包含源码版本号. show 方法和 bus_attribute 结构设置如下: static ssize_t show_bus_version(struct bus_type *bus, char *buf) return snprintf(buf, PAGE_SIZE, "%s\n", Version); static BUS_ATTR(version, S_IRUGO, show_bus_version, NULL); if (bus_create_file(&ldd_bus_type, &bus_attr_version)) printk(KERN_NOTICE "Unable to create version attribute\n"); 这个调用创建一个属性文件(/sys/busldd/version) 包含 lddbus 代码的版本号. 在最低层, Linux 系统中的每个设备由一个 struct device 代表: 有许多其他的 struct device 成员只对设备核心代码感兴趣. 但是, 这些成员值得了解: 设备的 "parent" 设备 -- 它所附着到的设备. 在大部分情况, 一个父设备是某种总线或者主控制器. 如果 parent 是 NULL, 设备是一个顶层设备, 这常常不是你所要的. 代表这个设备并且连接它到层次中的 kobject. 注意, 作为一个通用的规则, device->kobj->parent 等同于 device->parent->kobj. 唯一确定这个总线上的设备的字符串. PCI 设备, 例如, 使用标准的 PCI ID 格式, 包含域, 总线, 设备, 和功能号. 管理这个设备的驱动; 我们查看 struct device_driver 在下一节. void (*release)(struct device *dev); 当对这个设备的最后引用被去除时调用的方法; 它从被嵌入的 kobject 的 release 方法被调用. 注册到核心的所有的设备结构必须有一个 release 方法, 否则内核打印出慌乱的抱怨. 最少, parent, bus_id, bus, 和 release 成员必须在设备结构被注册前设置. int device_register(struct device *dev); void device_unregister(struct device *dev); 我们已经见到 lddbus 代码如何注册它的总线类型. 但是, 一个实际的总线是一个设备并且必须单独注册. 为简单起见, lddbus 模块只支持一个单个虚拟总线, 因此这个驱动在编译时建立它的设备: static void ldd_bus_release(struct device *dev) printk(KERN_DEBUG "lddbus release\n"); ret = device_register(&ldd_bus); printk(KERN_NOTICE "Unable to register ldd0\n"); 一旦调用完成, 新总线可在 sysfs 中 /sys/devices 下面见到. 任何加到这个总线的设备接着在 /sys/devices/ldd0 下显示. ssize_t (*show)(struct device *dev, char *buf); ssize_t (*store)(struct device *dev, const char *buf, DEVICE_ATTR(name, mode, show, store); 结果结构通过前缀 dev_attr_ 到给定名子上来命名. 属性文件的实际管理使用通常的函数对来处理: int device_create_file(struct device *device, struct device_attribute *entry); void device_remove_file(struct device *dev, struct device_attribute *attr); struct bus_type 的 dev_attrs 成员指向一个缺省的属性列表, 这些属性给添加到总线的每个设备创建. lddbus 驱动创建它自己的设备类型( struct ldd_device ) 并且期望单独的设备驱动来注册它们的设备使用这个类型. 它是一个简单结构: #define to_ldd_device(dev) container_of(dev, struct ldd_device, dev); int register_ldd_device(struct ldd_device *ldddev) ldddev->dev.bus = &ldd_bus_type; ldddev->dev.parent = &ldd_bus; ldddev->dev.release = ldd_dev_release; strncpy(ldddev->dev.bus_id, ldddev->name, BUS_ID_SIZE); return device_register(&ldddev->dev); EXPORT_SYMBOL(register_ldd_device); 这里, 我们简单地填充一些嵌入的设备结构成员( 单个驱动不应当需要知道这个 ), 并且注册这个设备到驱动核心. 如果我们想添加总线特定的属性到设备, 我们可在这里做. static ssize_t sculld_show_dev(struct device *ddev, char *buf) struct sculld_dev *dev = ddev->driver_data; return print_dev_t(buf, dev->cdev.dev); static DEVICE_ATTR(dev, S_IRUGO, sculld_show_dev, NULL); 接着, 在初始化时间, 设备被注册, 并且 dev 属性被创建通过下面的函数: static void sculld_register_dev(struct sculld_dev *dev, int index) sprintf(dev->devname, "sculld%d", index); dev->ldev.name = dev->devname; dev->ldev.driver = &sculld_driver; dev->ldev.dev.driver_data = dev; register_ldd_device(&dev->ldev); device_create_file(&dev->ldev.dev, &dev_attr_dev); 注意, 我们使用 driver_data 成员来存储指向我们自己的内部的设备结构的指针. int (*probe)(struct device *dev); int (*remove)(struct device *dev); void (*shutdown) (struct device *dev); 使用 device_driver 结构的函数的形式, 现在应当看来是类似的(因此我们快速涵盖它们). 注册函数是: int driver_register(struct device_driver *drv); void driver_unregister(struct device_driver *drv); ssize_t (*show)(struct device_driver *drv, char *buf); ssize_t (*store)(struct device_driver *drv, const char *buf, DRIVER_ATTR(name, mode, show, store); int driver_create_file(struct device_driver *drv, struct driver_attribute *attr); void driver_remove_file(struct device_driver *drv, struct driver_attribute *attr); bus_type 结构含有一个成员( drv_attrs ) 指向一套缺省属性, 对所有关联到这个总线的驱动都创建. struct driver_attribute version_attr; #define to_ldd_driver(drv) container_of(drv, struct ldd_driver, driver); 这里, 我们要求每个驱动提供特定当前软件版本, 并且 lddbus 输出这个版本字串为它知道的每个驱动. 总线特定的驱动注册函数是: int register_ldd_driver(struct ldd_driver *driver) driver->driver.bus = &ldd_bus_type; ret = driver_register(&driver->driver); driver->version_attr.attr.name = "version"; driver->version_attr.attr.owner = driver->module; driver->version_attr.attr.mode = S_IRUGO; driver->version_attr.show = show_version; driver->version_attr.store = NULL; return driver_create_file(&driver->driver, &driver->version_attr); static ssize_t show_version(struct device_driver *driver, char *buf) struct ldd_driver *ldriver = to_ldd_driver(driver); sprintf(buf, "%s\n", ldriver->version); 为完整起见, sculld 创建它的 ldd_driver 结构如下: 一个简单的对 register_ldd_driver 的调用添加它到系统中. 一旦完成初始化, 驱动信息可在 sysfs 中见到: |-- sculld0 -> ../../../../devices/ldd0/sculld0 |-- sculld1 -> ../../../../devices/ldd0/sculld1 |-- sculld2 -> ../../../../devices/ldd0/sculld2 |-- sculld3 -> ../../../../devices/ldd0/sculld3
|
本文转自feisky博客园博客，原文链接：http://www.cnblogs.com/feisky/archive/2010/05/30/1747320.html，如需转载请自行联系原作者
