核心中usb子系統的結構
我們已經知道了usb子系統的**都位於drivers/usb目錄下面，也認識了乙個很重要的目錄——core子目錄。現在，我們再來看乙個很重要的模組——usbcore。你可以使用「lsmod」命令看一下，在顯示的結果裡能夠找到有乙個模組叫做usbcore。
找到了usbcore那一行嗎？core就是核心，基本上你要在你的電腦裡用usb裝置，那麼兩個模組是必須的：乙個是usbcore，這就是核心模組；另乙個是主機控制器的驅動程式，比如這裡usbcore那一行我們看到的ehci_hcd和uhci_hcd，你的usb裝置要工作，合適的usb主機控制器模組也是必不可少的。
usbcore負責實現一些核心的功能，為別的裝置驅動程式提供服務，提供乙個用於訪問和控制usb硬體的介面，而不用去考慮系統當前存在哪種主機控制器。至於core、主機控制器和usb驅動三者之間的關係，如下圖所示。
usb驅動和主機控制器就像core的兩個保鏢，協議裡也說了，主機控制器的驅動（hcd）必須位於usb軟體的最下一層。hcd提供主機控制器硬體的抽象，隱藏硬體的細節，在主機控制器之下是物理的usb及所有與之連線的usb裝置。而hcd只有乙個客戶，對乙個人負責，就是usbcore。usbcore將使用者的請求對映到相關的hcd，使用者不能直接訪問hcd。
core為咱們完成了大部分的工作，因此咱們寫usb驅動的時候，只能呼叫core的介面，core會將咱們的請求傳送給相應的hcd。
usb子系統與裝置模型
關於裝置模型，最主要的問題就是，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結構，其中有乙個struct device_driver driver成員，usb core為每乙個裝置驅動準備了乙個函式，讓它把自己的這個struct device_driver driver插入到usb_bus_type中的drivers鍊錶中去。而這個函式正是我們此前看到的usb_register。而與之對應的usb_deregister所從事的正是與之相反的工作，把這個結構體從drivers鍊錶中刪除。
而struct bus_type結構的match函式在usb子系統裡就是usb_device_match函式，它充當了乙個紅娘的角色，在usb匯流排的usb裝置和usb驅動之間牽線搭橋，類似於交大bbs上的鵲橋版，雖然它們上面的條件都琳琅滿目的，但明顯這裡match的條件不是那麼的苛刻，要更為實際些。
可以說，usb core的確是用心良苦，為每乙個usb裝置驅動做足了功課，正因為如此，作為乙個實際的usb裝置驅動，它在初始化階段所要做的事情就很少，很簡單了，直接呼叫usb_register即可。事實上，沒有人是理所當然應該為你做什麼的，但usb core這麼做了。所以每乙個寫usb裝置驅動的人應該銘記，usb裝置驅動絕不是乙個人在工作，在他身後，是usb core所提供的默默無聞又不可或缺的支援。
Linux裝置模型
linux裝置驅動模型 我們在寫最簡單的裝置驅動程式的時候，我們將所有的硬體資訊都儲存在了驅動 中，這樣有乙個非常明顯的不足 會導致驅動程式的通用性極差，一旦硬體平台或硬體連線有鎖改變，就一定要修改驅動 為了解決這個問題，linux在2.6版本之後，新增了 匯流排 裝置 驅動 的linux裝置模型，...
linux裝置模型
linux核心的整體架構 linux裝置模型 linux裝置模型 1 基本概念 linux裝置模型 2 kobject linux裝置模型 3 uevent linux裝置模型 4 sysfs linux裝置模型 5 device和device driver linux裝置模型 6 bus linu...
Linux裝置驅動模型
核心版本 2.6.29 裝置驅動模型框架是linux驅動程式設計的基礎。它通過kobject,kset,ktype等底層資料結構將bus type,device,device driver 等高層資料結構組織起來，形成乙個層次 分類清晰的驅動模型。優點如下 1.重用。將物件抽象為匯流排 驅動 裝置三...