與在服務器和桌面系統(tǒng)的風風火火比較起來，Linux在嵌入式領域似乎總是不溫不火，是生不逢時，還是另有隱情？

最近幾年，Linux操作系統(tǒng)在桌面和服務器系統(tǒng)等領域的應用取得了很大的成功。它的存在已經(jīng)對這些領域中的傳統(tǒng)霸主，例如微軟的Windows和Sun公司的SunOS/Solaris操作系統(tǒng)等造成了極大的威脅。這主要得益于其較低的使用開銷和更高的應用性能：現(xiàn)在，Linux操作系統(tǒng)加高端奔騰處理器構成的計算機系統(tǒng)在性能上已經(jīng)遠遠超過了同等價位的運行著Solaris的基于SPARC處理器的計算機系統(tǒng);Linux能夠取得成功的另一個主要原因在于它是一個開放源碼的系統(tǒng)軟件，Linux用戶可以享受到世界各地Linux愛好者提供的支持。

就在Linux系統(tǒng)在桌面和服務器領域應用風頭正勁的時候，業(yè)界內外普遍地認為Linux也會成功打入到嵌入式系統(tǒng)中，成為主流操作系統(tǒng)之一。但是，事與愿違，現(xiàn)實中的情形遠沒有那么樂觀。那些為桌面和服務器系統(tǒng)提供Linux操作系統(tǒng)軟件的開發(fā)商們并不熱衷于將Linux引入到嵌入式系統(tǒng)領域。而其他的一些已經(jīng)在嵌入式Linux領域開拓市場的公司，比如Lineo和MontaVista，也一直沒有獲得穩(wěn)定的收益。為什么Linux沒有能夠在嵌入式領域中獲得它在桌面系統(tǒng)中同樣的輝煌呢？原因就是桌面系統(tǒng)和嵌入式系統(tǒng)對操作系統(tǒng)的需求有所差異。

桌面系統(tǒng)和嵌入式系統(tǒng)對操作系統(tǒng)的需求有很多差異，而且都很關鍵。我們在這里先討論幾個最重要的問題，這些問題已經(jīng)足夠體現(xiàn)出Linux系統(tǒng)在嵌入式系統(tǒng)領域所面臨的挑戰(zhàn)。這些挑戰(zhàn)都是在之前的桌面系統(tǒng)應用中未曾遇到的，主要包括：

●中斷延遲(interruptlatency）

●線程響應時間(threadresponsetime)

●調度策略（scheduling）

●設備驅動程序

●可靠性和安全性

以上這些都是技術層面上的挑戰(zhàn)。而在將Linux系統(tǒng)引入嵌入式領域時，還有很多的非技術性層面上的挑戰(zhàn)也是必須要考慮的。

技術挑戰(zhàn)

中斷延遲

實時系統(tǒng)（Real-TimeSystem）是指能夠在限定的時間（一般是很短的時間范圍）內對系統(tǒng)中發(fā)生的某類事件（比如從某個外圍設備傳來的中斷請求）進行處理的系統(tǒng)。如果系統(tǒng)對這些事件的響應出現(xiàn)了問題，比如未能在限定時間內對其做出相應處理，就會導致系統(tǒng)出現(xiàn)故障。絕大多數(shù)嵌入式系統(tǒng)都有很高的實時性需求，而桌面系統(tǒng)卻不一定。在嵌入式系統(tǒng)測試中，衡量系統(tǒng)實時性的最主要參數(shù)有兩個：一個是中斷延遲時間的長短，另一個是線程上下文切換時間的長短。

中斷延遲是指從產(chǎn)生中斷請求到相應中斷服務程序的第一條指令被執(zhí)行之間的這段時間。由于中斷具備有優(yōu)先級而且可以嵌套產(chǎn)生，因此可以測知優(yōu)先級最高的中斷在執(zhí)行時的延遲時間。測試表明，產(chǎn)生中斷延遲的原因除了處理器響應時間外，更重要的是操作系統(tǒng)往往會大大增加中斷被延遲的時間。在操作系統(tǒng)運行過程中，存在著一些關鍵的操作。這些操作在執(zhí)行時，操作系統(tǒng)會禁止在其間插入任何中斷。因此如果一個中斷請求在操作系統(tǒng)禁止中斷的這段時間里產(chǎn)生，那么對它的處理就會始終保持在掛起狀態(tài)，直到操作系統(tǒng)重新允許中斷插入。最終，中斷延遲在最壞情況下的數(shù)值是和操作系統(tǒng)關鍵操作中的指令序列在中斷請求產(chǎn)生后繼續(xù)執(zhí)行的時間緊密相關。

實時系統(tǒng)就是要確保系統(tǒng)中的關鍵事件能夠在限定的時間段內被處理。操作系統(tǒng)開發(fā)商會提供給用戶一個表示中斷延遲的數(shù)值以體現(xiàn)產(chǎn)品的實時性能。這個數(shù)值是在實驗室環(huán)境下測得的，它可能是平均值，典型值，或者是在最好情況下的系統(tǒng)中斷延遲。但在實際應用過程中，最壞情況下的延遲中斷才是用戶最需要考慮的。那么如何才能得到這個數(shù)值呢？瑞典的一個研究小組對操作系統(tǒng)中禁止中斷產(chǎn)生的代碼區(qū)域進行分析，試圖用這種方法對當前一款商業(yè)化的實時操作系統(tǒng)進行研究并得到系統(tǒng)中最壞情況下的中斷延遲的大小。

這項研究使用了先進的程序流分析方法來確定操作系統(tǒng)中所有的關鍵操作（即那些“禁止插入中斷”的代碼）區(qū)域的位置和結構。研究人員還利用了周期精確的模型來測定選定代碼區(qū)域的被執(zhí)行次數(shù)。但是研究結果并不讓人感到振奮。因為用于禁止和允許中斷的指令所需的源操作數(shù)在執(zhí)行時才能確定，所以研究人員不能用靜態(tài)分析的方法得到關鍵操作的執(zhí)行情況。還有一些其他的程序流問題，比如關鍵操作序列的嵌套出現(xiàn)等等，也阻礙了研究的進展。最終據(jù)研究人員估測，大概只有一半數(shù)目的“禁止插入中斷”的關鍵操作區(qū)域能夠被確定，而另一半大約有600個區(qū)域會對中斷響應時間產(chǎn)生未知的影響。

研究人員評估了他們能夠確定的那些關鍵操作區(qū)域的執(zhí)行時間。這些區(qū)域的執(zhí)行情況非常復雜，有很多已經(jīng)不是以簡單的順序結構執(zhí)行了，少數(shù)幾個區(qū)域甚至包含了三個嵌套的循環(huán)，而且還有一些關鍵操作區(qū)域的循環(huán)次數(shù)是不定的。在研究人員提供的報告中，可以看到一個具有嵌套循環(huán)的關鍵操作區(qū)域的執(zhí)行周期數(shù)的估測為26729。試想在一個主頻為100MHz的微處理器上，僅僅是這樣一個區(qū)域就要消耗大約250微秒的時間。相信沒有任何一個實時操作系統(tǒng)的開發(fā)商會愿意公開這個量級上的中斷延遲。