《Linux那些事兒之我是USB》我是隨身碟（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。