kboot初探與模擬驗證

kboot本質上是個小型Linux作業系統，但功能卻是個boot loader，何解？kboot本身提供簡單的系統工具，支援檔案與網路操作，可自外界取得kernel image或其他檔案，進而kboot利用了kexec的機制，讓Linux kernel可快速重新啟動，於是具備boot loader的功能。

kexec是一組新的系統呼叫，包含在2.6 kernel中 (視支援架構而定)，搭配其user-space的工具kexec-tools，則可在既有的Linux kernel (支援kexec系統呼叫) 中載入其他的kernel (不需要有kexec支援)，並給予必要之參數或檔案，如kernel command line與initrd等，這方面的資訊可參考以下文章：

• 使用 kexec 快速重啟 Linux (DeveloperWorks)
• kexec (LWN)

目前，kexec的硬體支援不限定x86，包含ARM與PPC都已有patch現身。那麼，如此的機制到底有什麼價值呢？以往的boot程序是很單純，清一色就是boot loader載入kernel，然後跳到user-mode或者是特定的工作，但現在的系統設計往往不是單一硬體、單一架構就可勝任的，諸如RAID或高負載的備援系統設計，都需要相當繁複的規劃，很顯然就非普通的boot loader可以應付，也很難修改Etherboot去圓滿符合需求，這時候，我們聯想到Linux，搭配到上述的kexec，不就是最美妙的boot loader嗎？在載入新的kernel之前，我們可作任何Linux能做的事情，像是載入firmware並進行設定、掛載NFS、掛載NTFS (透過Linux-NTFS)、... 等等，只要能提供新kernel給kexec-tools工具作載入，最後再透過kexec系統呼叫，就可完成這個「功能強大的boot loader」的終極任務。

kboot就是這樣的概念驗證實做品，使用的情境相當多元。舉例來說，kboot想進行遠端開機 (Diskless)，但只有Wireless LAN或3G network可用，這時候就掛載對應的kernel module (包附在kboot中)，然後透過user-space的應用程式進行設定，等待連線建立並確保檔案擷取成功，接著就在裝置上執行自遠端取得核心。另一種情境也很有趣，以往Linux distribution都得作通用性與最佳化的妥協，前者往往得將系統劃分諸多核心模組與大量的設定程式，後者往往得針對硬體作多次嘗試，那麼，透過kboot可先啟動generic kernel，然後進行硬體偵測，參考所需的硬體與最佳化組態，重新編譯核心，最後將該核心載入，而這個過程可透過一些設計得當的效能評估工具，一次又一次的重複自動微調，有別於以往的boot loader。關於kboot的應用，可參考以下簡報：

• kboot - A Boot Loader Based on Kexec (kboot作者提供的slides)
• 於Linux Conference AU的演講錄影
  
• HTTP-FUSE PS3 Linux : an internet boot framework with kboot (PS3 Linux hackers)

後者給予我們極大的想像空間，當我們在新的硬體進行核心與週邊移植時，的確可先把能運作的最低限度核心置入kboot，然後再從不同的開發分支取得新核心並啟動，而這些過程都是透明的，而且不需要燒錄到傳統儲存裝置中，只要資源允許，可在RAM中做到繁瑣的事情。

昨天做了一個小hack，將原本的kboot (Version 11) 進行調整，更動紀錄如下：

Enhancements:
. Provided qemu specific configurations for verifying kboot
. Enable Visibility for gcc-3.4 (symbol hidden)
. Perform size optimizations against user-space packages.
Upgraded:
. kernel - 2.6.21
. binutils - 2.17.50.0.16
. uClibc - 0.9.29

我們甚至不需要單獨的x86機器，就能測試kexec與kboot，只要有能夠運作Qemu的環境即可。首先，取得OrzLab修改的版本：kboot-11-orzlab.tar.bz2，解開後直接打 "make" 就會建構整個系統，包含下載必要的套件、工具，以及編譯與安裝等。搭載於kboot的Linux kernel是精簡的版本，只提供TCP/IP stack、procfs、initrd/initramfs、ne2k NIC driver、VESA VGA framebuffer console等，但足以讓我們作許多應用。

Qemu提供DHCP與TFTP server的模擬，完全省下我們佈署的難度，所以在模擬環境中，所需的操作甚至大幅少於實體。筆者提供了簡單的script名為 "qemu-launcher.sh"，直接執行即可，kboot啟動後的畫面如下：
依據Qemu的操作文件，預設透過模擬的DHCP server取得的IP是10.0.2.15，而server自己則是10.0.2.2，上面的畫面展示kboot已經載入一個小型的Linux kernel並出現提示訊息，等待命令操作，我們可打一些指令如下：
看到kernel version 2.6.21與ping連線的狀況，除此之外，還有ssh/sshd可用，所以大可連線到某台server，重新編譯核心程式碼，然後放到某個網路伺服器上。接著我們就要來驗證kexec/kboot的功能。Qemu內建的TFTP server相當好用，直接對應於host上的目錄架構，而就Debian/Ubuntu來說，host的核心會在根目錄建立symbolic link，而vmlinuz與initrd.img就指向目前運作的核心與initrd。

於是，我們在模擬的環境只要下簡單的一行指令即可載入並重新啟動： (鍵入粗體字部份)

kboot: tftp://10.0.2.2/vmlinuz

然後我們會看到 "Start Kernel" 的字樣跳過，然後我們就在Qemu的模擬環境看到啟動目前host上的核心：
因為在之前提供的qemu啟動script中省略root file system的指派，所以會停在kernel panic的畫面，不過這也達到我們的目的，驗證kexec/kboot，有了這個便利的模擬測試環境，未來也可作不同的變化。

lwkhttpd : Lightweight kHTTPd for Linux Kernel

昨天在SourceForge.net註冊了新專案Ajax/Embedded，做了必要的設定後，開始將之前Proof-of-Concept的程式碼check-in到SVN中。今天開放的項目是子計畫：lwkhttpd，也就是 "Lightweight kHTTPd for Linux Kernel" 之意，以下是該子計畫簡介：

lwkhttpd : Lightweight kHTTPd for Linux Kernel 2.6 series

Copyright (c) 2007 Open RazzmatazZ Laboratory (OrzLab).
Maintained by Jim Huang
Development page: http://sourceforge.net/projects/ajaxembed

[-] Overview

Ajax/Embedded is an experimental design dedicated to perform Ajax applications on embedded systems, such as Wirelss routers. To fit the web traffic on these devices, lwkhttpd is developed as the full kernel-mode HTTP daemon for Linux kernel 2.6 series. Besides handling static requests, lwkhttpd redirects dynamic requests to the user-mode webserver (used for Ajax engine) for extensibility.

儘管Web 2.0並未帶來相當革命性的技術移轉，但我們可以看到Web engine卻有調整與最佳化的空間。在lighttpd開發者的blog有一篇名為 "Faster Web 2.0" 的文章，提出三個方向對Web 2.0應用程式提供更好的效能：

• Large Response content
• Pre-generating content
• Read Ahead

簡單來說，FastCGI的執行模型雖然對OpenWebMail一類的Perl-based Web application有相當程度的效能提昇，但對於Ajax導向的模式來說，還是沒有切中問題核心。Ajax/Embedded底層提供如此一個kernel-mode HTTP daemon，以處理大量的static data，同時也提供 redirect to user-space的機制，讓動態網頁資料 (主要是XMLHttpRequest) 得以「轉包」到我們的Ajax engine，在這之上有豐富的C/C++ Web UI widget set可用。整體效益就如之前blog「Ajax/Embedded」所提，得以建構兼具效能、功能，以及安全性的native Web framework。

對了，Ajax/Embedded計畫項目會參加今年的Coding Jam 2007活動，已提交簡要的Proposal到TaiwanCodeJam的wiki page中。希望能快點拿到我們的參考硬體，ARM-based的硬體已開始運作，現在要試試Wifi相關的部份，開發的過程中讓我發現很有趣的現象：現在的computing model逐漸「M化」，不僅是mobile化，也是朝向兩個極端的演化，就Ajax/Embedded專案的適用範疇來看，事實上就是「client比server快上許多」的模式，同時server-side產生相對少量的資料，讓client-side盡情去描繪多采多姿的內容，也對使用者互動方面有了更多的需求。

Mutex與火車排班

在我心中，一直有個小心願，能以自己微弱的力量為這個社會多作些事情，包含免費的技術訓練，然而時間、精力是投入了，但不見得有效果，為此，我常常在反省。拜讀對岸高手Pengcheng Zou的blog - 「Linux地鐵」一文，我終於知道為什麼，畢竟技術或理論本身被提出，就是要克服現實問題，所以若能讓訓練本身更貼近現實，這樣才會發揮其價值。以下摘錄「Linux地鐵」一文的部份內容：

今天早上上班，快到地鐵就發現外面站了不少人，有做打車狀，有做打電話狀，隱約聽到有人說地鐵壞了。下到地鐵站台，果然看到兩列車停在那裡，站台上站滿了人。

後來在北京市地鐵運營有限公司網站上看到了事故原因：

11日早晨7點55分左右，地鐵2號線宣武門變電站瞬間過載跳閘，造成長椿街信號系統無法正常使用，列車運行方式被迫由自動閉塞改為電話閉塞，通過能力下降，運營間隔加大，造成長椿街臨近的復興門等重點站短時間乘客滯留。8點19分故障排除，地鐵運營方式隨後按自動閉塞方式運營，運營秩序逐步恢復正常。其間，2號線內外環西直門至宣武門早高峰列車間隔加大，列車最小間隔由原來3分半被迫延長到8至10分鐘，由於故障發生時正處於早高峰階段，客流本就較大，所以部分車站出現乘客短時滯留現象，地鐵1號線受此故影響有6列車在復興門站通過。13號線、八通線未受故障影響，運營正常。

何謂「閉塞」？寶貝爹地是鐵路的，正好請教。講 了半天，不甚了了。只好再從網上查，得知由車站向區間發車時必須確定區間內無車，還要防止兩個車站在同一線路上向同區間發車。這種按照一定的方法組織列車 在區間內的運行，稱為行車閉塞，用來聯絡的設備稱為閉塞設備。常用的閉塞設備有自動閉塞、半自動閉塞及電氣路籤閉塞等。地鐵採用自動閉塞設備。

這 下懂了，地鐵就是作業系統，所謂區間就是臨界區，閉塞裝置是各種同步機制，自動閉塞相當於spinlock，電話閉塞相當於semaphore。今天早上 效率比較高的spinlock失靈了，只好用效率較低而且不能用於中斷上下文的semaphore。所以導致系統性能下降，進程吞吐量明顯降低，客戶滿意 度下降。不少用戶轉而使用其他作業系統。

很多唸電腦科學的學生，往往在畢業後還不能理解那些同步理論的重要性，如今，火車排班就是最好的案例。Linux kernel中有兩種mutex (互斥)機制：

• semaphore
• spinlock

兩者主要區別是，semaphore在無法進入critical section (臨界區) 時，會引發context-switching，而若有硬體配合 (SMP) 的話，spinlock就沒有context-switching，這是許多教科書會提到的，但聽起來很奇怪吧？我們要思考的是本質，semaphore是process-level的操作，當有process要求進入critical section，好比在上面鐵路案例中，以電話要求區間的發車權，那麼，若critical section沒有被設置旗標，就可佔用並重設旗標，也就是我們可順利發車，但若不幸遇到該區間已經有車班呢？這時候該process就被迫「睡眠」，而本身也會被送入wait queue，這種枯等的經驗，想必很多通勤的朋友都能感受。我們也可以發現，這過程牽涉到process狀態的改變，因為勢必會有資源被釋放的時候 (但不保證)，屆時，被迫「睡眠」的項目也會因而被喚醒。

spinlock的本質是busy-waiting，聽起來很沒效率，但為何說在SMP很重要呢？最主要的原因是，沒有context-switch的負擔，沒有牽涉到process的狀態變化，在多處理器的環境下，spinlock相當有效率，而在單處理器上，卻只是disable/enable isr一類的操作。換過來想火車的案例，似乎就簡單多了，用電話通知本身涉及人與人的通訊內容、線路使用量，以及現實因素，可視為單處理器狀態，但如果是自動化，個別單元的協調時間是相當短的，所以可想成SMP架構，自然這兩者的mutex機制也有使用上的落差了。

當然，真的要探討Linux semaphore/spinlock的機制，其實複雜許多，特別在2.6 kernel還添入big kernel lock等新的機制，不過這些都出自典型作業系統理論 (命名可能有出入)，只要稍微變化一下，或許也能對應到現實。

Ajax/Embedded

之前花了一些時間作個 lightweight kHTTPd for Linux Kernel 2.6，也可用作於 HTTP accelerator / redirect server，在kernel mode處理static web data與redirection。這幾天正在實做一個user mode應用程式集，規範一個 Framework，能用 C/C++ 開發 AJAX Web Application，如此可確保footprint 與 performance都有不錯的表現。可應用於Router / Wireless AP / Embedded controller，參考硬體平台為ARM與MIPS，此專案暫定命名為Ajax/Embedded，中期的計畫就是能整合進FON (La Fonera)，以及銜接kHTTPd。

今天做了一個Preview / Proof-of-Concept的版本，展示一個GMail-like郵件撰寫與拼字檢查的Web application，連同Web server、Application Framework，以及Ajax engine，大約佔了2Mb的空間，雖然比其他Ajax解決方案來得省，不過很明顯有頗大的進步空間。

對於Ajax/Embedded來說，不僅效能與空間可獲得最佳化，事實上還可避免常見的XSS (Cross-Site-Scripting) 安全性議題，更可沒有負擔地與底層整合，比方說Wireless router查詢硬體狀態的設計就能直接呼叫ioctl。為了避免程式開發者耗費過多時間在調整UI，Web UI Framework本身必須提供夠高階的event-driven model，目前已經有類似Gtk+/Qt的Signals-Slots機制。