《Linux那些事儿之我是USB》我是U盘（9）总线、设备和驱动（下）

bus上的两张链表记录了每一个设备和驱动，那么设备和驱动这两者之间又是如何联系起来的呢？此刻，必须抛出这样一个问题，先有设备还是先有驱动？

在以前，先有的是设备，每一个要用的设备在计算机启动之前就已经插好了，插放在它应该在的位置上，然后计算机启动，然后操作系统开始初始化，总线开始扫描设备。每找到一个设备，就为其申请一个struct device结构，并且挂入总线中的devices链表中来，然后每一个驱动程序开始初始化，开始注册其struct device_driver结构，然后它去总线的devices链表中去寻找（遍历），去寻找每一个还没有绑定驱动的设备，即struct device中的struct device_driver指针仍为空的设备，然后它会去观察这种设备的特征，看是否是他所支持的设备，如果是，那么调用一个叫做device_bind_driver的函数，然后他们就结为了秦晋之好。换句话说，把struct device中的struct device_driver driver指向这个驱动，而struct device_driver driver把struct device加入它的struct list_head devices链表中来。就这样，bus、device和driver，这三者之间或者说它们中的两两之间，就给联系上了。知道其中之一，就能找到另外两个。一荣俱荣，一损俱损。

但现在情况变了，出现了一种新的名词“热插拔”。设备可以在计算机启动以后在插入或者拔出计算机了。因此，很难再说是先有设备还是先有驱动了。因为都有可能。设备可以在任何时刻出现，而驱动也可以在任何时刻被加载。所以，出现的情况就是，每当一个struct device诞生，它就会去bus的drivers链表中寻找自己的另一半；反之，每当一个一个structdevice_driver诞生，它就去bus的devices链表中寻找它的那些设备。如果找到了合适的，那么和之前那种情况一样，调用device_bind_driver绑定好。如果找不到，没有关系，等待吧。

事实上，完善这个三角关系，正是每一个设备驱动初始化阶段所完成的重要使命之一。让我们还是回到代码中来，usb_register函数调用是调用了，但是传递给他的参数是什么呢？

我们注意到，调用usb_register函数的代码如下：

1073     /* registerthe driver, return usb_register return code if error */

1074         retval = usb_register(&usb_storage_driver);

是的，传递了一个叫做usb_storage_driver的家伙，这是什么？同一个文件中：

1055 static struct usb_driver usb_storage_driver ={

1056   .name =        "usb-storage",

1057  .probe =        storage_probe,

1058    .disconnect=   storage_disconnect,

1059 #ifdef CONFIG_PM

1060   .suspend =     storage_suspend,

1061   .resume =      storage_resume,

1062 #endif

1063    .pre_reset=    storage_pre_reset,

1064   .post_reset =   storage_post_reset,

1065    .id_table=    storage_usb_ids,

1066 };

可以看到这中定义了一个struct usb_driver的结构体变量，usb_storage_driver，关于usb_driver我们上节已经说过了，当时主要说的是其中的成员driver，而眼下要讲的则是另外几个成员。首先，owner是用来给模块计数的，每个模块都这么用，赋值总是THIS_MODULE。而name就是这个模块的名字，USB Core会处理它，所以如果这个模块正常被加载了的话，使用lsmod命令能看到一个叫做usb-storage的模块名。CONFIG_PM是与电源管理相关的。下面重点要讲一讲，.probe和.disconnect以及这个id_table。