14.4. 总线, 设备, 与驱动.pdfVIP

14.4. 总线, 设备, 和驱动 14.4. 总线, 设备, 和驱动 ⾄今, 我们已经看到⼤量低级框架和⼀个相对少的例⼦. 我们试图在本章剩下部 中补 充, 随着我们进⼊ 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); /* ome fields omitted */ }; name 成员是总线的名⼦, 有些同 pci . 你可从这个结构中见到每个总线是它⾃⼰的⼦系 统; 这个⼦系统不位于 sysfs 的顶层, 但是. 相反, 它们在总线⼦系统下⾯. ⼀个总线包含 2 个 ksets, 代表已知的总线的驱动和所有插⼊总线的设备. 所以, 有⼀套⽅法我们马上 将涉及. . 总线注册 如同我们提过的, 例⼦源码包含⼀个虚拟总线实现称为 lddbus. 这个总线建⽴它的 bus_type 结构, 如下: struct bus_type ldd_bus_type = { .name = ldd, .match = ldd_match 注意很少 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); . 总线⽅法 有⼏个给 bus_type 结构定义的⽅法; 它们允许总线代码作为⼀个设备核⼼和单独驱动 之间的中介. 在 2.6.10 内核中定义的⽅法是: int (match)(struct device device , struct device_driver *driver); 这个⽅法被调⽤, ⼤概多次, ⽆论何时⼀个新设备或者驱动被添加给这个总线. 它应当 返回⼀个⾮零值如果给定的设备可被给定的驱动处理. (我们马上进⼊设备和 device_driver 结构的细节) . 这个函数必须在总线级别处理, 因为那是合适的逻辑存在的 地⽅; 核⼼内核不能知道如何匹配每个可能总线类型的设备和驱动. int (hotp lug) (struct device device , char *envp , int num_envp , char buffer , int b