這本《Linux內核修煉之道》已經開賣（網上的鏈接為： 卓越、當當、china-pub ），雖然是嚴肅文學，但為了保證流暢性，大部分文字我還都是斟詞灼句，反復的念幾遍才寫上去的，盡量考慮到寫上去的每段話能夠讓讀者產生什麼疑惑，然後也都會緊接著盡量的去進行解釋清楚，中間的很多概念也有反復糾結過怎麼解釋能夠更容易的理解，力求即使對於初學者也可以有很少阻礙的一氣讀完。同時我也把書中一部分自己的感悟抽出來整理了精華版，share出來。當然水平有限，錯漏之處有發現而修訂時遺漏的，也有尚沒有發現的。這本書如果對您有用，乃我之幸事，如果無用，就在此先誠惶誠恐的向大家拜個不是了。
下面仍然是之前5月份一次presentation的部分內容及講義，不過當時的題目叫“驅動開發的方法論”，或許對大家有用吧。至於這幾次講座的視頻貌似網上都能找到。
************************************************************************
前一篇我們談到了如何高效學習Linux內核，現在我們開始另外一個話題，就是如何高效學習 linux 驅動開發。至於為什麼會選擇這樣一個 topic ，主要是基於這樣兩個原因：
第一個原因是：目前幾乎所有的驅動開發方面的參考書，內容結構都是先介紹介紹什麼是 linux 驅動，它分為哪些種類，然後是各種類型設備的驅動程序的內容細節。大都是只注重各種驅動本身的細節，而沒有站在一個全局整體的角度講解一下驅動開發的方法。這樣導致的後果就是，大多數的驅動開發者雖然可以正確的編寫驅動程序，但往往都是只知其一不知其二，知其然而不知其所以然。
第二個原因是：目前很多驅動開發者，即使是已經有多年經驗的開發者，在開發驅動的時候也就是填充填充driver 的結構體，對於比較成熟的平台，就是網上找個類似的驅動修改一下，即使寫十個百個千個驅動，也就是對某些硬件比較熟，遇到全新的芯片全新的平台就束手無策。應該說這樣對驅動的理解是很有限的。這也是目前linux 驅動開發領域的現狀。
我們首先認識一下 linux 驅動的基本面，我們認識一個新事物的的第一件事就是了解它的一些基本信息，就像我們人與人之間互相認識首先也是通過個人的基本信息一樣。
linux 驅動在本質上就是一種軟件程序，上層軟件可以在不用了解硬件特性的情況下，通過驅動提供的接口，和計算機硬件進行通信。
系統調用是內核和應用程序之間的接口，而驅動程序是內核和硬件之間的接口，也就是內核和硬件之間的橋梁。它為應用程序屏蔽了硬件的細節，這樣在應用程序看來，硬件設備只是一個設備文件，應用程序可以象操作普通文件一樣對硬件設備進行操作。
linux 驅動程序是內核的一部分，管理著系統中的設備控制器和相應的設備。它主要完成這麼幾個功能：對設備初始化和釋放；傳送數據到硬件和從硬件讀取數據；檢測和處理設備出現的錯誤。
一般來說，一個驅動可以管理一種類型的設備。例如不同的 U 盤都屬於 mass storage 設備，我們不需要為每一個 U 盤編寫驅動，而只需要一個驅動就可以管理所有這些 mass storage 設備。
為方便我們加入各種驅動來支持不同的硬件，內核抽象出了很多層次結構，這些層次結構是 linux 設備驅動的上層。它們抽象出各種的驅動接口，驅動只需要填寫相應的回調函數，就能很容易把新的驅動添加到內核。
一般來說， linux 驅動可以分為三類，就是塊設備驅動，字符設備驅動和網絡設備驅動。塊設備的讀寫都有緩存來支持，並且塊設備必須能夠隨機存取。塊設備驅動主要用於磁盤驅動器。
而字符設備的 I/O 操作沒有通過緩存。字符設備操作以字節為基礎，但不是說一次只能執行一個字節操作。例如對於字符設備我們可以通過 mmap 一次進行大量數據交換。字符設備實現比較簡單和靈活。
網絡設備在 Linux 裡做專門的處理。 Linux 的網絡系統主要是基於 BSD 的 socket 機制。網絡設備驅動為網絡操作提供接口，管理網絡數據的接送和收發。為了屏蔽網絡環境中物理網絡設備的多樣性， Linux 對所有的物理設備進行抽象並定義了一個統一的概念，稱之為接口（ interface ）。所有對網絡硬件的訪問都是通過接口進行的，接口對上層協議提供一致化的操作集合來處理基本數據的發送和接收，對下層屏蔽硬件差異。它與字符設備及塊設備不同之處其一就是網絡接口不存在於 Linux 的設備文件系統 /dev/ 中。
和前一篇的介紹一樣，看完外表，我們再看內涵，就是 Linux 驅動的工作流程。大概有四個部分：使用 insmod加載，模塊的初始化，進行設備操作，使用 rmmod 卸載。
Linux 驅動有兩種存在形式，一種是直接編譯進內核，就是我們在配置內核的時候，在相應選項上選 Y ，另外一種就是編譯成模塊，按需加載和卸載。通常我們使用 insmod 命令完成模塊的加載，在加載時還可以指定模塊參數。另外一個常用的加載工具是 modprobe ，它與 insmod 的不同在於它會檢查模塊之間的依賴關系，將該模塊依賴的模塊也加載到內核。
每個驅動都有自己的初始化函數，完成一些新功能的注冊，這個初始化函數只是在初始化的時候被使用。在 linux系統裡，設備以文件的形式存在，應用程序可以通過 open 、 read 等函數操作設備，通過設備文件實現對設備的訪問。設備不再使用時，我們使用 rmmod 命令來卸載它，卸載的過程會調用到驅動的推出函數，每個驅動都必須有一個退出函數，沒有的話，內核就不會允許去卸載它。
在對 linux 驅動的外表和內涵都有了一個初步的認識之後，我們來看看作為一個驅動開發者，我們需要注意哪些問題。
首先，對模塊機制的了解是開發 linux 驅動的基礎，因為我們編寫驅動的過程也就是在編寫一個內核模塊的過程。早期版本的內核是整體式的，也就是說所有的部分都靜態地連接成一個很大的執行文件。但是現在的內核采用的是新的機制，即模塊機制：許多功能包含在模塊內，當你需要時可以使用 insmod 去擁抱它，將它動態地載入到內核裡，當你不需要時，則可以使用 rmmod 將它一腳踢開。這就使得 kernel 的內核很小，而且在運行的時候可以不用 reboot 就能夠載入和替代模塊。
其次，我們要注重對設備模型的理解。其實從 2.6 內核開始，隨著設備模型的出現，驅動的開發就不再是個困難的問題，毫不誇張得說，理解了設備模型，再去看那些五花八門的驅動程序，你會發現自己站在了另一個高度，從而有了一種俯視的感覺，就像鳳姐俯視知音和故事會，韓峰同志俯視女下屬。不過貌似大部分驅動開發者都沒意識到這個問題。
最後，是要養成使用協議的 spec 、設備的 datasheet 、內核參考代碼去解決問題的習慣，而不是一碰到問題就到處尋找所謂的牛人去問怎麼解決。
中間的那些內容和前面精華版的博文裡差不多，就不貼了，…………
前面介紹了我個人感覺開發驅動需要注意的三個方面，現在說個實際的例子。前些天一個網友在自己的 csdn 博客上寫了篇文章，名字就叫給 fudan_abc 的一封信，信裡說了自己的問題，我覺得應該很多人都存在這樣類似的問題，這裡咱們來看一下。
先說他個人的情況：有一定的 linux c 基礎，熟悉 linux 內核 / 驅動的開發環境搭建和編譯。現在想做個 i2c芯片的 驅動，該驅動要跑在 x86 平台上。
手邊的資料有：
1. 芯片手冊 看了幾次，基本了解 上邊的 資源和 他的 i2c 地址
2. 找到 linux + arm 平台上的 對應的 .c 文件和 .h 文件。但是對應的 arm 平台的 kernel source 沒有。
3. .c 文件裡的 代碼看過 一遍，從函數名 可以知道他的功能。
然後開始 操作 怎麼移植這個 i2c 芯片到 x86 平台上。之後遇到了一些列的問題，比如 i2c 的地址信息等等，具體我就不敘述了。
然後他就去請教了一些人
請教某人 A ： “ 其實 i2c 很簡單，你填充那個 driver 結構體就 ok 了。 ” 我反問 “ 我對裡邊的 流程和調用不熟悉啊 “
A 回： ” 你把他們想象成一個黑盒就可以了 ” 我： “ 無法想象，我怎麼想象？我想看看裡邊的代碼到底是怎樣的。 ”A:"....." 。 對 A 的請教結果，無法解決我的問題：我到底該怎麼辦？
再請教 B:
B:“ 其實 i2c 移植就是注冊那幾個函數 , 你想看內核代碼實現，內核這麼大你怎麼可能搞清楚，我做了那麼多移植，有時候連芯片手冊都搞不清，直接 prink 吧代碼給調出來的 ” 我： “ 。。。 ” 無法理解，無話可說。
其實這裡邊的 A 和 B 說的也沒錯，很多人寫驅動大概就這麼做的，但是這樣子就是寫成百上千個驅動也不能說就理解 linux 驅動了，面試時碰到的絕大部分人都屬於這種情況，能回答自己做了什麼，但一談到一些相關的基本的問題就往往回答不上來。
我覺得首要的問題是缺乏好奇心，做技術的好奇心應該是原動力，特別對於搞 linux 內核和驅動的，好奇心有多強，你的水平就可能會增長到多高。
其次，對於做驅動的來說，對於 2.6 內核，重要的是去理解設備模型，很多人都本末倒置了，很多專門寫驅動的書也不注重設備模型的理解，只去應付一種種類型的協議和設備的驅動，即使寫個一萬個也僅僅是對比較成熟的芯片熟了些。而且，不理解設備驅動，難道寫驅動的時候不覺得很多東西很朦胧麼？這也是我個人覺得很奇怪的一方面。
像我之前設備模型的文章裡說的那樣，理解了設備模型，對各種類型的驅動就有種俯視的感覺了。這個時候再你去看特定類型的協議和設備的實現，脈絡就很清晰，比如你看 i2c 的實現。這個時候重要的就是 i2c 的協議，具體芯片的 datasheet ，加上看看內核裡現有的 i2c 驅動作為參考，就是我所說的驅動開發的三件寶。
所以說如果希望做 2.6 的驅動話，關鍵還是要先去理解下設備模型，將這個比較抽象的概念在心裡形象化，然後再去看具體的驅動比較好。
頂
