在先前的專欄中，我們為大家介紹了「I/O」以及「interrupt handling」，接下來我們要將這二個部份合在一起，並討論幾個相當重要的觀念以及機制。首先，我們回到最早在介紹 Linux 驅動程式架構的部份，我們介紹到了 system call 以及 file operations 的觀念；接續 I/O 的部份，我們又提到 read/write system call。到這裡，我們就要融合貫通先前所介紹的重要觀念。請大家先將先前的專欄讀熟，再接續本系列專欄。

在 Linux 驅動程式的整個框架中，最重要，而且必須一開始就先了解的主題有二個：

1. Blocking I/O 的觀念。
2. Wait queue 以及 event-driven（event-polling）的觀念。

雖然這裡分成二個小主題，不過其實這是同樣的一個主題。這裡有很多值得提出討論的觀念，首先針對 Blocking I/O 的觀念進行深度探討。

什麼是 blocking I/O？

當 user process 透過 read/write system call 讀取硬體資料時，會有哪些情況出現？請注意，這裡講的是「user process」，並不是驅動程式的 system call 實作（driver function、fops->read 或 fops->write）。以 user process 呼叫 read() 來讀取硬體資料的案例來說，當然免不了就是以下的情況：

1. 驅動程式能順利由硬體拿到資料，並丟到 user-space 給「該」process。
2. 驅動程式目前無法由硬體拿到資料。怎麼辦？

現在沒辦法馬上由硬體拿到資料，怎麼辦呢？當然要等待了。驅動程式必須設法等到可以由硬體拿到資料為止，再將資料丟給該 process。試想，現在有一個 process 想要讀取硬體資料，第一次的 read() 很順利地馬上就拿到資料了，可是第二次的 read() 因為硬體的關係，驅動程式暫時無法由硬體取得資料，於是 process 的第二次 read() 並不會立刻結束。

Process 這個時候「停在」第二次的 read() 呼叫，但其實此時，系統的執行位置是來到驅動程式的 read driver function（fops->read），而 fops->read 在待候硬體資料。「Blocking」就是「停住」的意思，所以第二次的 read() 動作就變成是 blocking I/O。請注意：

1. 這裡一定是討論 user process 是否會停在 read() 或 write()。Blocking I/O 一定要由 user process 的角度討論才會是正確的觀念。
2. 第二次的 read 是 blocking I/O（blocking operaton），這是「驅動程式的 fops->read 實作」所導致的結果。所以，user process 的 read/write 會不會停住，完全是看 fops->read 與 fops->write 的實作。
3. 我們在這裡只討論驅動程式的 read/write 實作，也就是 user process 存取 device file。

這就是所謂的 blocking I/O。由驅動程式的角度來看，可以總結如下：

1. 當驅動程式想讓 user process 在呼叫 read() 函數時，都保證能取得資料，此時驅動程式便要實作「當目前尚無資料可回傳給 user process 時，便讓 user process 停留等待」的機制（可能是驅動程式尚無法由裝置取得資料）。

2. w當驅動程式想讓 user process 在呼叫 write() 函數時，都保證能寫入資料，此時驅動程式便要實作「當目前無法寫入資料至裝置時，便讓 user process 停留等待」的機制（可能是裝置尚未 ready）。

讓 user process 停止的方式，涉及排程的觀念，這部份在下一篇日記會接著說明。

2008 年 8 月 8 日是北京奧運的開幕日，這一天，也是 Openmoko 推出第三代最新一代手機平臺「Om 2008.8」的日子。Om 2008.8 也稱為 ASU，ASU 是一個專案代號，全名是 April/August Software Update。

ASU 可同時支援 EFL、Qtopia 以及 GTK+ 應用程式，同時也包含一個安裝程式（Installer），可讓使用者自由安裝手機應用軟體，這是過去在校園巡迴課程向同學所介紹的 Openmoko 新的概念，如今終於正式現身了。

ASU 比較另人期待的地方是加入了 EFL 以及 Qtopia，過去 Om 2007.2 是基於 GTK+ 的手機平臺，現在的 Om 2008.8 則是「跳脫」GTK+ 的重要里程碑。ASU 裡有二個值得一提的軟體成果，首先是 Illume。[Illume] 是一個能支援 GTK+ 的 window manager，這是 [Enlightenment] 裡的一個模組，Illume 讓 enlightenment 的 UI 能在手機上有更好的表現。另外一個重要的軟體成果則是 ASU 能在 X11 環境上執行 Qtopia 的應用程式與服務，並使用上述提及的 Illume 做為 window manager。Illume 能同時支援多種不同的圖形介面程式庫。

圖：Openmoko 新的 Software Architecture，能同時支援 ELF（enlightenment）、Qtopia（on X11）以及 GTK+ 應用程式。（圖片來源：wiki.openmoko.org）

Neo FreeRunner/ASU 是 Openmoko 至今最重要的產品，雖然軟體與硬體仍然不足以讓 Neo FreeRunner/ASU 成為日常生活用的手機，但 Openmoko 社群對 ASU 仍大多是抱持正面的看法。其他軟體方面的問題，像是最近在社群裡被抱怨的開機時間（boot time）問題，或是已知的其他問題，像是 GSM modem、電池、WiFI driver 等，都是目前努力的工作項目，未來也會有所改善。

從 Om 2007.1 到 Om 2007.2，再由 Om 2007.2 到 ASU/Om 2008.8，接下來 Openmoko 即將推出的好菜為 FSO（FreeSmartphone.Org）。FSO 會是再次令人驚奇的新里程碑。

上週進行「GNU Toolchains & Embedded Linux Programming」課程時，最後出了一道考題給同學。題目如下。

請說明上述程式執行後，為什麼會出現以下結果。請將原理描述清楚。

$ gcc -o helo helo.c
$ ./helo
0x80495c0
now x = 10
now x = 100

這是一道綜合性的考題，考了很多東西。完全沒有 toolchains 觀念前，同學是一頭霧水，也沒有什麼方向。但是在二天的課程後，從同學繳回的測試卷來看，大家的觀念都已經很健全了。在這裡將題目也提供給大家思考。這是一道不算難的考題，主要考的是「觀念」，並透過「工具的操作」來驗證這些觀念。

觀念的建立絕對是教育訓練最重要的一個環節，也是講師的主要任務，而透過工具的交互操作，來強化課堂觀念，是一個不錯的方法，可以幫助同學記憶。

今天進行「GNU Toolchains & Embedded Linux Programming」課程，在講解 fork 時，有同學問到「能不能 fork 多個 child process」，當然是可以的。後續又有同學問到，「能不能 fork 孫子」，當然也是可以的，只不過，在 child process 裡再 fork child process 並不是很主要的做法，只在一些特殊情況，例如要避免 zombie process 產生時，才會用上。

所以，我們只講解如何 fork 多個 child process 的做法。我們舉了一段 code 當做範例，這段 code 寫得很單純，可以說明 fork 的一些觀念。在這裡，大家必須了解的是「fork 之後」的行為是什麼：

1. parent process 的執行流程
2. child process 的執行流程

接著將以下的程式（n_fork.c）實際上機執行，並觀察執行結果。

執行後出現以下結果：

$ gcc -o n_fork n_fork.c
$ ./n_fork &
This is the child process. PID: 8450
This is the child process. PID: 8451
This is the child process. PID: 8452
Parent process, PID: 8449
Child process ID: 8450 8451 8452

我們用 pstree 指令來觀察執行之後的系統狀態：

後續我們會結合一個 Web server 的練習，來展示 fork 多個 child process 的應用。