Hello World Module

不能免俗的一個hello world等級的module，基本上就是學習編譯技巧跟觀察，一點作用都沒有
檔案為hello.c位於某個版本的kernel source下的drivers/hello目錄內，比如說/home/account/friendarm/kernel/linux-2.6.32.2/hello，底下有兩個檔案hello.c跟Makefile

Makefile只有兩行，一行指定compiler，另外一行就是module的相依行囉

編譯指令為
make -C /home/account/friendarm/kernel/linux-2.6.32.2 M='drivers/hello' modules
-C後面的參數為kernel source tree位置，後面則是要編譯的module的位置

我跟著是放到micro2440上面執行(如果在桌上型，Makefile內的CC可以省略，直接用系統內建就可以了)，因為micro2440上面預設把所有訊息打開了，所以可以在console底下看到訊息輸出，不然一般應該在/var/log/messages檔案內

linux input subsystem

linux input的subsystem已經發展許久，為了簡化driver，系統發展出了input core的部分，不過也是因為這樣，使用者在使用方便之餘，已經搞不清楚到底事件的觸發是如何從source to destination了，還好linux是開放原始碼，所以trace source code還是可以瞧出端倪的

很多書本不知道是為了哪種理由，其實這部分大多很含糊的略過，只簡單提到使用input_register_device()去註冊由input_allocate_device()配置出來的device，然後跟著使用input_event()跟input_sync()完成工作，最多再給出個虛擬的滑鼠的範例，結束

看完之後我還是搞不懂，事件如何導向消化的地方，我可否自行寫一個輸入系統，再自行寫一個handler來處理呢?直覺上是可行的，但是如果不了解如何運作，恐怕也是很難做到

透過drivers/input/input.c的source code解析可以得到答案，不過網路上已經有人剖析得很清楚，我就直接借用連結過來吧
http://blog.163.com/wxiongn@126/blog/static/1178820382010724104617786/
http://blog.163.com/wxiongn@126/blog/static/117882038201072410502312/

個人認為的linux驅動程式學習步驟

linux驅動程式開發的門檻比一般程式設計的門檻高，原因在於對於硬體及韌體的了解需要比一般的更多，相較之下，如web service的開發則傾向設計的門檻比較高，比方說MVC的應用，以及類似DB的設計等等，幾乎是不同的走向

linux驅動程式開發最好對硬體有些了解（本人對硬體就很不了解，花了不少時間填補），再者對於一些作業系統的基本元件，如process、semaphore...等等要有概念，接著了解system programming(指那些system call)，跟著可以開始作驅動程式開發

• 如果是嵌入式系統，可以overview各種cpu、chip、memory、hardware interfaces開始；跟著必須補齊如boot loader、kernel、root system等等概念，oreilly的"建構嵌入式linux系統"是本這方面的好書，相對的PC上的linux就比較沒有這方面的疑問，很多都已經非常的標準化了，變化行不如嵌入式系統大
• 基本的裝置分類方式character、block、queue，學習linux從高階的角度看待各種設備。
• 驅動程式IO的元素，如blocking/non-blocking、synchronous/asynchronous、critical section的維護、device/device_memory IO、記憶體的操作(kmalloc、__get_free_page...)、interrupt。因為驅動程式主要就是為了輸入、輸出訊號，這些元素都是必備的
• 接著了解bus/device/driver的架構、分層(layer)、分離、子系統(input、usb...)的應用。這部份有些書本略過了，真的很難消化，網路上資源不少，但是又很少願意以圖形說明，如果只有自己爬code會很累
• 在貼近各種bus界面，以及硬體的控制，如PCI、USB、I2C...
• 其他還有debug的技巧

整體linux的學習過程應該要花上好些時間，再者如果每個部份又不是很熟悉又很容易因為一同栽入，見樹不見林，我想提供一個簡單的方向讓有心的人可以稍微有點概念。
我認為最難的兩個部份，一個是linux driver的架構、各種子系統的設計，其實因為發展了許久，所以開始結構化，但是結構化就是簡化程式碼，但是提昇程式碼之間的相關性，再不了解相關性（如子系統的原理），看code就倍感吃力；其次是各種硬體跟界面的經驗，跟界面也都有他的設計的經驗跟原則，當使用者或者一般程式設計師都有OS幫忙處理，所以現在要寫這一層，就比較吃力一點。最後，當然最好的是身邊有個熟悉的人，可以讓你一直問:P但是這真的是看緣份了

最後應該就是硬體的資訊，這方面不屬於韌體工程是的範疇，但是又有點難分割，在業界有vendor廠商提供主要的幫忙，但是了解愈多愈能幫助自己完成工作

最後我想說，相較於四、五年前現在資料真的多許多，主要是拜android風行之賜，相關資料一下子有了爆炸行的成長

linux驅動程式-chapter 7

這個章節看似比較鬆散一點，不過如果從了解中斷的角度應該會比較容易入手一點
先想想中斷，中斷分類可以分成幾種

• 從來源，分為內部中斷(cpu引起，如除0)跟外部中斷(硬體週邊引起)
• 從是否可遮罩，分成可遮罩與不可遮罩
• 從中斷處理函數，分成向量中斷跟非向量中斷

不論如何，基本的處理精神都是希望趕緊將中斷處理完畢跟著把控制權交還給本來的程式，很可惜有的中斷要長時間處理，比方鏡頭要拷貝整個影像，這需要長時間
所以很多OS設計就將中斷分成兩個部份，一個部份是處理引發的事情，讀入一些需要的資料（如暫存器），記憶體拷貝的部份在另外找時間處理，以如此折衷的方式進行。前面稱為中斷的top half，後續的處理過程稱為bottom half。

跟著我們知道有個獨特的中斷為計時中斷，很多軟體的timer也是基於此設計，書中先介紹不使用OS支援的方式實作timer，跟著引入有OS支援的方式

一開始介紹了如何使用jiffies來計算時間，每個jiffiers是一次震盪的時間（不管是cpu或者是主機板上的石英振盪器)，一開始書本給的範例是使用busy waiting的方式來計時，也就是讓程式一直消耗cpu，且反覆觀察jiffies的變化，透過time_after、time_before等函數來比較jiffies變數之間的大小，進而達成timer的作法
很明顯busy waiting的方式當然是不好的，與其等待不如把cpu讓給有需要的人。另外就是OS為了服務更多的timer(想像很多process需要定時執行某些事情，這些process需要很多timers)，於是OS維護了一個timers的list，每隔一段時間就檢驗這些list，並且將那些時間到了的process放入排程(schedule)之中
而這樣的作法就是將那些process視為half bottom，而kernel中檢驗list中的timer變成了half top，中斷發生的時候就快速篩選timer並且進入排程
一個簡化的版本是呼叫schedule_timeout()該函數中是使用timer_list來維護

接著談到中斷的bottom half的實作方式有tasklet與work queue的方式

Linux之AIO

雖然這已經是很久之前就存在的技術，但是感覺在一般的程式設計書籍並不常見(應該說比例上)，但是最近AIO卻是延伸到web server上變得火紅，從node.js可見一斑
主要是因為閱讀蒐集linux driver的資料的時候看到的，因為感覺LDD這本書有點看不懂，可能礙於實際開發經驗，以及程式設計背景知識，即使知道了如何寫出driver，但是感覺並無法實際充分利用。所以我也另外買了一本大陸作者的書籍"Linux 裝置驅動程式之開發詳解(第2版)"，前面講解還算通暢，可是到了AIO左右已經開始有點不知所云，轉而向網路搜尋，找到了M. Tim Jones的著作，他並非亞洲人
http://www.ibm.com/developerworks/cn/linux/l-async/
發現原來該書的作者應該是瞟竊他人的著作!!??雖然後來唸到後面有看到一個URL指向該文章，也不知道這個網路文章(已經翻譯成中文)是否為書本作者翻譯的，但是完全不加以註明，讓人覺得書本文章是他自己寫的，書中一段文字幾乎跟網頁文字相同!!再加上範例也很像。
我發現難以理解主要是因為書本作者根本把一些重要的網頁圖片拿掉，如下面的圖片，明白點出blocking/nonblocking跟asynchronous/synchronous之間衍生的關係

建議對書中看得不大懂的讀者，轉向直接閱讀該網頁的內容，其中還有四個圖案講解kernel跟這四種IO之間的關係，簡明易懂，個人看了感覺大有收穫