linux 2.6核心最初為了應付電源管理的需要，提出了乙個裝置模型來管理所有的裝置。在物理上，外設之間是有一種層次關係的，比如把乙個u盤插到筆記本上，實際上這個u盤是接在乙個usb hub上，usb hub又是接在usb 2.0 host controller (ehci)上，最終ehci又是乙個掛在pci bus上的裝置。這裡的乙個層次關係是：pci->ehci->usb hub->usb disk。如果作業系統要進入休眠狀態，首先要逐層通知所有的外設進入休眠模式，然後整個系統才可以休眠。因此，需要有乙個樹狀的結構可以把所有的外設組織起來。這就是最初建立linux裝置模型的目的。
當然，linux裝置模型給我們帶來的便利遠不止如此。既然已經建立了乙個組織所有裝置和驅動的樹狀結構，使用者就可以通過這棵樹去遍歷所有的裝置，建立裝置和驅動程式之間的聯絡，根據型別不同也可以對裝置進行歸類，這樣就可以更清晰的去「看」這顆枝繁葉茂的大樹。另外，linux驅動模型把很多裝置共有的一些操作抽象出來，大大減少了重複造輪子的可能。同時linux裝置模型提供了一些輔助的機制，比如引用計數，讓開發者可以安全高效的開發驅動程式。達成了以上這些好處之後，我們還得到了乙個非常方便的副產品，這就是sysfs----乙個虛擬的檔案系統。sysfs給使用者提供了乙個從使用者空間去訪問核心裝置的方法，它在linux裡的路徑是/sys。這個目錄並不是儲存在硬碟上的真實的檔案系統，只有在系統啟動之後才會建起來。
tree /sys 就可以看到/sys 的結構了~
/proc是記憶體中有關系統程序的實時資訊；
/sys是有關系統核心以及驅動的實時資訊；
這裡有10個子目錄，但並不是說這10個目錄代表了10種完全不同的裝置型別，實際上這些目錄只是給我們提供了如何去看整個裝置模型的不同的視角。其實從不同的目錄出發都有可能找到同乙個裝置的。那真正的裝置資訊到底放在**呢？看看目錄的名稱就應該能猜到，對，就是devices子目錄，linux的所有裝置都可以在這個目錄裡找到。
我們如果要寫程式來訪問sysfs，可以像讀寫普通檔案一樣來操作/sys目錄下的檔案，或者，也可以使用libsysfs。不過需要注意的是，linux核心社群並不推薦用libsysfs，因為這個api的更新不夠快，趕不上核心的變化。libsysfs已經逐漸背離最初建立它的目標，這個lib帶來的問題似乎比它解決的還要多。當然，如果只是要訪問裝置，一般很少會直接操作sysfs，它太細節太底層了，大部分情況下可以使用更加方便的devicekit或者libudev。
/sys下的子目錄
內容
/sys/devices
該目錄下是全域性裝置結構體系，包含所有被發現的註冊在各種匯流排上的各種物理裝置。一般來說，所有的物理裝置都按其在匯流排上的拓撲結構來顯示，但有兩個例外，即platform devices和system devices。platform devices一般是掛在晶元內部的高速或者低速匯流排上的各種控制器和外設，它們能被cpu直接定址；system devices不是外設，而是晶元內部的核心結構，比如cpu，timer等，它們一般沒有相關的驅動，但是會有一些體系結構相關的**來配置它們。
(sys/devices是核心對系統中所有裝置的分層次表達模型，也是/sys檔案系統管理裝置的最重要的目錄結構)
sys/dev
該目錄下維護乙個按照字元裝置和塊裝置的主次號碼(major:minor)鏈結到真是裝置(/sys/devices)的符號鏈結檔案。
/sys/class
該目錄下包含所有註冊在kernel裡面的裝置型別，這是按照裝置功能分類的裝置模型，每個裝置型別表達具有一種功能的裝置。每個裝置型別子目錄下都是這種哦哦那個裝置型別的各種具體裝置的符號鏈結，這些鏈結指向/sys/devices/name下的具體裝置。裝置型別和裝置並沒有一一對應的關係，乙個物理裝置可能具備多種裝置型別；乙個裝置型別只表達具有一種功能的裝置，比如：系統所有輸入裝置都會出現在/sys/class/input之下，而不論它們是以何種匯流排連線到系統的。(/sys/class也是構成linux統一裝置模型的一部分)
/sys/block
該目錄下的所有子目錄代表著系統中當前被發現的所有塊裝置。按照功能來說防止在/sys/class下會更合適，但由於歷史遺留因素而一直存在於/sys/block，但從linux2.6.22核心開始這部分就已經標記為過去時，只有開啟了config_sysfs_deprecated配置編譯才會有這個目錄存在，並且其中的內容在從linux2.6.26版本開始已經正式移到了/sys/class/block，舊的介面/sys/block為了向後相容而保留存在，但其中的內容已經變為了指向它們在/sys/devices/中真實裝置的符號鏈結檔案。
/sys/bus
該目錄下的每個子目錄都是kernel支援並且已經註冊了的匯流排型別。這是核心裝置按照匯流排型別分層放置的目錄結構，/sys/devices中的所有裝置都是連線於某種匯流排之下的，bus子目錄下的每種具體匯流排之下可以找到每個具體裝置的符號鏈結，
一般來說每個子目錄(匯流排型別)下包含兩個子目錄，乙個是devices，另乙個是drivers；其中devices下是這個匯流排型別下的所有裝置，這些裝置都是符號鏈結，它們分別指向真正的裝置(/sys/devices/name/下)；而drivers下是所有註冊在這個匯流排上的驅動，每個driver子目錄下 是一些可以觀察和修改的driver引數。
(它也是構成linux統一裝置模型的一部分)
/sys/fs
按照設計，該目錄使用來描述系統中所有的檔案系統，包括檔案系統本身和按照檔案系統分類存放的已掛載點。
/sys/kernel
這個目錄下存放的是核心中所有可調整的引數
/sys/firmware
該目錄下包含對韌體物件(firmware object)和屬性進行操作和觀察的介面，即這裡是系統載入韌體機制的對使用者空間的介面.(關於韌體有專用於韌體載入的一套api)
/sys/hypervisor
該目錄是與虛擬化xen相關的裝置。(xen是乙個開放源**的虛擬機器監視器)
/sys/module
該目錄下有系統中所有的模組資訊，不論這些模組是以內聯(inlined)方式編譯到核心映像檔案中還是編譯為外模組(.ko檔案)，都可能出現在/sys/module中。即module目錄下包含了所有的被載入kernel的模組。
/sys/power
該目錄是系統中的電源選項，對正在使用的power子系統的描述。這個目錄下有幾個屬性檔案可以用於控制整個機器的電源狀態，如可以向其中寫入控制命令讓機器關機/重啟等等。
下圖是嵌入式系統常見的硬體拓撲的乙個示例：
硬體拓撲描述linux裝置模型中四個重要概念中三個：bus，class和device（第四個為device driver，後面會說）。
bus（匯流排）：linux認為，匯流排是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裝置模型的核心思想是（通過***手段，實現***目的）：
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結構，在裝置模型中引入物件導向的概念，這樣可以最大限度地抽象共性，減少驅動開發過程中的重複勞動，降低工作量。
裝置模型一 基本概念
前言 裝置驅動模型研究好一陣子了,但是很快就忘了,不得不重新再研究,打算記錄下來,裝置驅動模型系列打算參考wowo科技系列的文章 以及自己的理解講訴一下,開篇的話引入wowo關於驅動模型的第一篇 寫的太好,沒辦法 linux支援世界上幾乎所有的 不同功能的硬體裝置 這是linux的優點 導致linu...
Linux裝置模型 1 基本概念
1.前言 在 linux核心的整體架構 中，蝸蝸有提到，由於linux支援世界上幾乎所有的 不同功能的硬體裝置 這是linux的優點 導致linux核心中有一半的 是裝置驅動，而且隨著硬體的快速公升級換代，裝置驅動的 量也在快速增長。個人意見，這種現象打破了 簡潔就是美 的理念，是醜陋的。它導致li...
Linux裝置模型 1 基本概念
1.前言 在 linux核心的整體架構 中，蝸蝸有提到，由於linux支援世界上幾乎所有的 不同功能的硬體裝置 這是linux的優點 導致linux核心中有一半的 是裝置驅動，而且隨著硬體的快速公升級換代，裝置驅動的 量也在快速增長。個人意見，這種現象打破了 簡潔就是美 的理念，是醜陋的。它導致li...