Linux裝置模型：設計思想 與 Kobject
基本概念
作者：wowo 釋出於：2014-2-27 17:01
分類：統一裝置模型
原文：http://www.wowotech.net/device_model/13.html
前言
在“Linux核心的整體架構”中，蝸蝸有提到，由於Linux支援世界上幾乎所有的、不同功能的硬體裝置（這是Linux的優點），導致Linux核心中有一半的程式碼是裝置驅動，而且隨著硬體的快速升級換代，裝置驅動的程式碼量也在快速增長。個人意見，這種現象打破了“簡潔就是美”的理念，是醜陋的。它導致Linux核心看上去非常臃腫、雜亂、不易維護。但蝸蝸也知道，這不是Linux的錯，Linux是一個巨集核心，它必須面對裝置的多樣性，並實現對應的驅動。
為了降低裝置多樣性帶來的Linux驅動開發的複雜度，以及裝置熱拔插處理、電源管理等，Linux核心提出了裝置模型（也稱作Driver Model）的概念。
裝置模型將硬體裝置歸納、分類，然後抽象出一套標準的資料結構和介面。
驅動的開發，就簡化為對核心所規定的資料結構的填充和實現。
本文將會從裝置模型的基本概念開始，通過分析核心相應的程式碼，一步一步解析Linux裝置模型的實現及使用方法。
Linux裝置模型的基本概念
Bus, Class, Device和Device Driver的概念
下圖是嵌入式系統常見的硬體拓撲的一個示例：
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”型別的樹狀結構（見圖例）解決裝置之間的依賴，而這種依賴在開關機、電源管理等過程中尤為重要。
試想，一個裝置掛載在一條總線上，要啟動這個裝置，必須先啟動它所掛載的匯流排。很顯然，如果系統中裝置非常多、依賴關係非常複雜的時候，無論是核心還是驅動的開發人員，都無力維護這種關係。
而裝置模型中的這種樹狀結構，可以自動處理這種依賴關係。啟動某一個裝置前，核心會檢查該裝置是否依賴其它裝置或者匯流排，如果依賴，則檢查所依賴的物件是否已經啟動，如果沒有，則會先啟動它們，直到啟動該裝置的條件具備為止。而驅動開發人員需要做的，就是在編寫裝置驅動時，告知核心該裝置的依賴關係即可。
4、使用Class結構，在裝置模型中引入面向物件的概念，這樣可以最大限度地抽象共性，減少驅動開發過程中的重複勞動，降低工作量。