Linux那些事儿之我是U盘(8)总线,设备,和驱动(上)

struct bus_type中为devices和drivers准备了两个链表,而代表device的结构体struct device中又有两个成员,struct bus_type *bus和struct device_driver *driver,同样,代表driver的结构体struct device_driver同样有两个成员,struct bus_type *bus和struct list_head devices,struct device和struct device_driver的定义和struct bus_type一样,在include/linux/device.h中.凭一种男人的直觉,可以知晓,struct device中的bus记录的是这个设备连在哪条总线上,driver记录的是这个设备用的是哪个驱动,反过来,struct device_driver中的bus代表的也是这个驱动属于哪条总线,devices记录的是这个驱动支持的那些设备,没错,是devices(复数),而不是device(单数),因为一个驱动程序可以支持一个或多个设备,反过来一个设备则只会绑定给一个驱动程序.

于是我们想知道,关于bus,关于device,关于driver,他们是如何建立联系的呢?换言之,这三个数据结构中的指针是如何被赋值的?绝对不可能发生的事情是,一旦为一条总线申请了一个struct bus_type的数据结构之后,它就知道它的devices链表和drivers链表会包含哪些东西,这些咚咚一定不会是先天就有的,只能是后天填进来的.而具体到usb系统,完成这个工作的就是usb core.usb core的代码会进行整个usb系统的初始化,比如申请struct bus_type usb_bus_type,然后会扫描usb总线,看线上连接了哪些usb设备,或者说root hub上连了哪些usb设备,比如说连了一个usb键盘,那么就为它准备一个struct device,根据它的实际情况,为这个struct device赋值,并插入devices链表中来.又比如root hub上连了一个普通的hub,那么除了要为这个hub本身准备一个struct device以外,还得继续扫描看这个hub上是否又连了别的设备,有的话继续重复之前的事情,这样一直进行下去,直到完成整个扫描,最终就把usb_bus_type中的devices链表给建立了起来.

那么drivers链表呢?这个就不用bus方面主动了,而该由每一个driver本身去bus上面登记,或者说挂牌.具体到usb系统,每一个usb设备的驱动程序都会有一个struct usb_driver结构体,其代码如下,来自include/linux/usb.h

485 /* -------------------------------------------------------------------------- */
486
487 /**
488 * struct usb_driver - identifies USB driver to usbcore
489 * @owner: Pointer to the module owner of this driver; initialize
490 * it using THIS_MODULE.
491 * @name: The driver name should be unique among USB drivers,
492 * and should normally be the same as the module name.
493 * @probe: Called to see if the driver is willing to manage a particular
494 * interface on a device. If it is, probe returns zero and uses
495 * dev_set_drvdata() to associate driver-specific data with the
496 * interface. It may also use usb_set_interface() to specify the
497 * appropriate altsetting. If unwilling to manage the interface,
498 * return a negative errno value.
499 * @disconnect: Called when the interface is no longer accessible, usually
500 * because its device has been (or is being) disconnected or the
501 * driver module is being unloaded.
502 * @ioctl: Used for drivers that want to talk to userspace through
503 * the "usbfs" filesystem. This lets devices provide ways to
504 * expose information to user space regardless of where they
505 * do (or don't) show up otherwise in the filesystem.
506 * @suspend: Called when the device is going to be suspended by the system.
507 * @resume: Called when the device is being resumed by the system.
508 * @id_table: USB drivers use ID table to support hotplugging.
509 * Export this with MODULE_DEVICE_TABLE(usb,...). This must be set
510 * or your driver's probe function will never get called.
511 * @driver: the driver model core driver structure.
512 *
513 * USB drivers must provide a name, probe() and disconnect() methods,
514 * and an id_table. Other driver fields are optional.
515 *
516 * The id_table is used in hotplugging. It holds a set of descriptors,
517 * and specialized data may be associated with each entry. That table
518 * is used by both user and kernel mode hotplugging support.
519 *
520 * The probe() and disconnect() methods are called in a context where
521 * they can sleep, but they should avoid abusing the privilege. Most
522 * work to connect to a device should be done when the device is opened,
523 * and undone at the last close. The disconnect code needs to address
524 * concurrency issues with respect to open() and close() methods, as
525 * well as forcing all pending I/O requests to complete (by unlinking
526 * them as necessary, and blocking until the unlinks complete).
527 */
528 struct usb_driver {
529 struct module *owner;
530
531 const char *name;
532
533 int (*probe) (struct usb_interface *intf,
534 const struct usb_device_id *id);
535
536 void (*disconnect) (struct usb_interface *intf);
537
538 int (*ioctl) (struct usb_interface *intf, unsigned int code, void *buf);
539
540 int (*suspend) (struct usb_interface *intf, u32 state);
541 int (*resume) (struct usb_interface *intf);
542
543 const struct usb_device_id *id_table;
544
545 struct device_driver driver;
546 };
547 #define to_usb_driver(d) container_of(d, struct usb_driver, driver)
看似很长一段,实际上也就是注释为主.而此刻我们只需注意到其中的struct device_driver driver这个成员,usb core为每一个设备驱动准备了一个函数,让它把自己的这个struct device_driver driver插入到usb_bus_type中的drivers链表中去.而这个函数正是我们此前看到的usb_register.而与之对应的usb_deregister所从事的正是与之相反的工作,把这个结构体从drivers链表中删除.可以说,usb core的确是用心良苦,为每一个usb设备驱动做足了功课,正因为如此,作为一个实际的usb设备驱动,它在初始化阶段所要做的事情就很少,很简单了,直接调用usb_register即可.事实上,没有人是理所当然应该为你做什么的,但usb core这么做了.所以每一个写usb设备驱动的人应该铭记,usb device driver绝不是一个人在工作,在他身后,是usb core所提供的默默无闻又不可或缺的支持.