#在「Linux核心的整體架構」一文中，蝸蝸提到了Linux核心支援世界上幾乎所有的不同功能硬體設備，這也是Linux的優點。然而，這也導致了Linux核心中一半的代碼是設備驅動程序，而隨著硬體設備的快速升級換代，設備驅動程式的程式碼量也在迅速增長。我認為，這種現象破壞了「簡潔即美」的理念，使得Linux內核顯得非常臃腫、雜亂且難以維護。然而，蝸蝸也明白，這並非Linux的過錯，因為Linux是一個宏內核，必須面對設備多樣性並實現對應的驅動程式。
為了降低裝置多樣性帶來的Linux驅動程式開發複雜度以及實現裝置熱插拔和電源管理等功能，Linux核心引入了裝置模型（也稱為驅動程式模型）的概念。設備模型將硬體設備分類並歸納，然後抽像出一套標準的資料結構和介面。這樣，驅動程式的開發就變得簡單明了，只需要填入和實作核心規定的資料結構即可。
本文將從設備模型的基本概念開始，透過核心對應程式碼的分析，逐步解說Linux設備模型的實作與使用方法。
#下圖是嵌入式系統常見的硬體拓樸的範例：
硬體拓樸描述Linux設備模型中四個重要概念中三個：Bus，Class和Device（第四個為Device Driver，後面會說）。
Bus（匯流排）：Linux認為（可以參考include/linux/device.h中struct bus_type的註解），匯流排是CPU和一個或多個裝置之間資訊互動的通道。而為了方便設備模型的抽象，所有的設備都應連接到匯流排（無論是CPU內部匯流排、虛擬的匯流排或「platform Bus」）。
Class（分類）：在Linux設備模型中，Class的概念非常類似物件導向程式設計中的Class（類別），它主要是集合具有相似功能或屬性的設備，這樣就可以抽像出一套可以在多個裝置之間共用的資料結構和介面函數。因而從屬於相同Class的設備的驅動程序，就不再需要重複定義這些公共資源，直接從Class繼承即可。
Device（設備）：抽象系統中所有的硬體設備，描述它的名字、屬性、從屬的Bus、從屬的Class等資訊。
Device Driver（驅動程式）：Linux裝置模型用Driver抽象硬體裝置的驅動程序，它包含裝置初始化、電源管理相關的介面實作。而Linux核心中的驅動開發，基本上都圍繞著該抽象進行（實作所規定的介面函數）。
附註：什麼是Platform Bus？
在電腦中有這樣一類設備，它們透過各自的設備控制器，直接和CPU連接，CPU可以透過常規的尋址操作存取它們（或者說存取它們的控制器）。這種連接方式，並不屬於傳統意義上的匯流排連接。但設備模型應該具備普適性，因此Linux就虛構了一條Platform Bus，讓這些設備掛靠。
Linux設備模型的核心思想是（透過xxx手段，實現xxx目的）：
\1. 用Device（struct device）和Device Driver（struct device_driver）兩個資料結構，分別從「有什麼用」和「怎麼用」兩個角度來描述硬體設備。這樣就統一了編寫設備驅動的格式，使驅動開發從論述題變為填空體，從而簡化了設備驅動的開發。
\2. 同樣使用Device和Device Driver兩個資料結構，實現硬體設備的即插即用（熱拔插）。
在Linux核心中，只要任何Device和Device Driver具有相同的名字，核心就會執行Device Driver結構中的初始化函數（probe），該函數會初始化設備，使其為可用狀態。
而對大多數熱拔插設備而言，它們的Device Driver一直存在核心中。當裝置沒有插入時，其Device結構不存在，因而其Driver也就不執行初始化操作。當裝置插入時，核心會建立一個Device結構（名稱和Driver相同），此時就會觸發Driver的執行。這就是即插即用的概念。
\3. 透過」Bus–>Device」類型的樹狀結構（請參閱2.1章節的圖例）解決設備之間的依賴，而這種依賴在開關機、電源管理等過程中尤其重要。
試想，一個設備掛載在一條總線上，要啟動這個設備，必須先啟動它所掛載的匯流排。很顯然，如果系統中設備非常多、依賴關係非常複雜的時候，無論是核心還是驅動的開發人員，都無法維護這種關係。
而設備模型中的這種樹狀結構，可以自動處理這種依賴關係。啟動某一個設備前，核心會檢查該設備是否依賴其它設備或總線，如果依賴，則檢查所依賴的物件是否已啟動，如果沒有，則會先啟動它們，直到啟動該設備的條件具備為止。而驅動開發人員需要做的，就是在編寫設備驅動時，告知內核該設備的依賴關係即可。
\4. 使用Class結構，在設備模型中引入物件導向的概念，這樣可以最大限度地抽象共性，減少驅動開發過程中的重複勞動，降低工作量。
以上是詳解Linux設備模型(1)_基本概念的詳細內容。更多資訊請關注PHP中文網其他相關文章！
