最近幾年，Linux操作系統在桌面和服務器系統等領域的應用取得了很大的成功。它的存在已經對這些領域中的傳統霸主，例如微軟的Windows和Sun公司的SunOS/Solaris操作系統等造成了極大的威脅。這主要得益於其較低的使用開銷和更高的應用性能:現在，Linux操作系統加高端奔騰處理器構成的計算機系統在性能上已經遠遠超過了同等價位的運行著Solaris的基於SPARC處理器的計算機系統;Linux能夠取得成功的另一個主要原因在於它是一個開放源碼的系統軟件，Linux用戶可以享受到世界各地Linux愛好者提供的支持。
就在Linux系統在桌面和服務器領域應用風頭正勁的時候，業界內外普遍地認為Linux也會成功打入到嵌入式系統中，成為主流操作系統之一。但是，事與願違，現實中的情形遠沒有那麼樂觀。那些為桌面和服務器系統提供Linux操作系統軟件的開發商們並不熱衷於將Linux引入到嵌入式系統領域。而其他的一些已經在嵌入式Linux領域開拓市場的公司，比如Lineo和MontaVista，也一直沒有獲得穩定的收益。為什麼Linux沒有能夠在嵌入式領域中獲得它在桌面系統中同樣的輝煌呢？原因就是桌面系統和嵌入式系統對操作系統的需求有所差異。
桌面系統和嵌入式系統對操作系統的需求有很多差異，而且都很關鍵。我們在這裡先討論幾個最重要的問題，這些問題已經足夠體現出Linux系統在嵌入式系統領域所面臨的挑戰。這些挑戰都是在之前的桌面系統應用中未曾遇到的，主要包括：
● 中斷延遲(interrupt latency）
● 線程響應時間(thread response time)
● 調度策略（scheduling）
● 設備驅動程序
● 可靠性和安全性
以上這些都是技術層面上的挑戰。而在將Linux系統引入嵌入式領域時，還有很多的非技術性層面上的挑戰也是必須要考慮的。 技術挑戰
中斷延遲
實時系統（Real-Time System）是指能夠在限定的時間（一般是很短的時間范圍）內對系統中發生的某類事件（比如從某個外圍設備傳來的中斷請求）進行處理的系統。如果系統對這些事件的響應出現了問題，比如未能在限定時間內對其做出相應處理，就會導致系統出現故障。絕大多數嵌入式系統都有很高的實時性需求，而桌面系統卻不一定。在嵌入式系統測試中，衡量系統實時性的最主要參數有兩個：一個是中斷延遲時間的長短，另一個是線程上下文切換時間的長短。
中斷延遲是指從產生中斷請求到相應中斷服務程序的第一條指令被執行之間的這段時間。由於中斷具備有優先級而且可以嵌套產生，因此可以測知優先級最高的中斷在執行時的延遲時間。測試表明，產生中斷延遲的原因除了處理器響應時間外，更重要的是操作系統往往會大大增加中斷被延遲的時間。在操作系統運行過程中，存在著一些關鍵的操作。這些操作在執行時，操作系統會禁止在其間插入任何中斷。因此如果一個中斷請求在操作系統禁止中斷的這段時間裡產生，那麼對它的處理就會始終保持在掛起狀態，直到操作系統重新允許中斷插入。最終，中斷延遲在最壞情況下的數值是和操作系統關鍵操作中的指令序列在中斷請求產生後繼續執行的時間緊密相關。
實時系統就是要確保系統中的關鍵事件能夠在限定的時間段內被處理。操作系統開發商會提供給用戶一個表示中斷延遲的數值以體現產品的實時性能。這個數值是在實驗室環境下測得的，它可能是平均值，典型值，或者是在最好情況下的系統中斷延遲。但在實際應用過程中，最壞情況下的延遲中斷才是用戶最需要考慮的。那麼如何才能得到這個數值呢？瑞典的一個研究小組對操作系統中禁止中斷產生的代碼區域進行分析，試圖用這種方法對當前一款商業化的實時操作系統進行研究並得到系統中最壞情況下的中斷延遲的大小。
這項研究使用了先進的程序流分析方法來確定操作系統中所有的關鍵操作（即那些“禁止插入中斷”的代碼）區域的位置和結構。研究人員還利用了周期精確的模型來測定選定代碼區域的被執行次數。但是研究結果並不讓人感到振奮。因為用於禁止和允許中斷的指令所需的源操作數在執行時才能確定，所以研究人員不能用靜態分析的方法得到關鍵操作的執行情況。還有一些其他的程序流問題，比如關鍵操作序列的嵌套出現等等，也阻礙了研究的進展。最終據研究人員估測，大概只有一半數目的“禁止插入中斷”的關鍵操作區域能夠被確定，而另一半大約有600個區域會對中斷響應時間產生未知的影響。
研究人員評估了他們能夠確定的那些關鍵操作區域的執行時間。這些區域的執行情況非常復雜，有很多已經不是以簡單的順序結構執行了，少數幾個區域甚至包含了三個嵌套的循環，而且還有一些關鍵操作區域的循環次數是不定的。在研究人員提供的報告中，可以看到一個具有嵌套循環的關鍵操作區域的執行周期數的估測為26729。試想在一個主頻為100MHz的微處理器上，僅僅是這樣一個區域就要消耗大約250微秒的時間。相信沒有任何一個實時操作系統的開發商會願意公開這個量級上的中斷延遲。 線程響應時間
線程響應時間是指從產生中斷請求到由該中斷服務程序喚起的線程中的第一條指令被執行之間的這段時間。和中斷延遲一樣，線程響應時間也是衡量系統實時性能的一個重要因素。嵌入式應用的設計者往往用線程實現程序所需的一些功能，比如設備操作代碼，因為這樣做便於進行調試而且會減少那些在執行過程中禁止插入中斷的代碼數量，有助於減少最壞情況下的中斷延遲時間。
在線程的執行過程中，有一個重要的問題在於響應高優先級中斷的線程的執行會受到其他低優先級中斷的影響。在高優先級的線程執行過程中是允許插入中斷的，因此可以有任意多的低優先級中斷請求產生。這些低優先級中斷請求的相關中斷服務程序都要被依次執行，大大增加了線程響應時間。這是一個典型的“優先級翻轉”的例子，即低優先級任務的執行延誤了高優先級任務的工作。在桌面系統中，出現這樣的翻轉是無礙大局的。
實時操作系統應該能夠提供一種方法來防止這種優先級翻轉問題的出現。有一個簡單卻很有效的方法是由設計者在關鍵的中斷處理線程中對中斷的優先級加以區分。當某個線程被調度時，系統內核就限制住那些優先級比該線程低的中斷產生。直到在沒有更高優先級的線程要執行時，才重新允許插入低優先級的中斷。
調度策略
Linux並沒有提供和中斷相關聯的線程優先級。實時操作系統卻需要進行基於線程優先級的調度，用來確保在某事件發生時，系統中的關鍵線程能夠立即執行。
標准的Linux調度器使用的是“公平”的啟發式調度策略。這主要是因為Linux繼承了Unix的特性，是分時共享的交互式操作系統。因此，程序設計者就不可能指定一個具有絕對最高優先級的線程。當中斷服務程序啟動某個線程去處理相應事件時，Linux調度器很有可能會先選擇一些其他的線程優先執行。也正因為如此，我們完全不可能確定在最壞情況下的線程響應時間。
與早些時候的v2.4內核相比，Linux的v2.6內核做了一些調度性能上的改進，但是對實時性的改造仍舊不在其中。按照Red Hat公司的說法：“線程庫的實現幾乎沒有對實時性的支持。系統可以選用一些調度參數，但是這些參數往往是起不到任何作用的。出現這種情況的主要原因是內核中的大部分實現都不遵守實時性的規則……而且內核中的很多其他方面也沒有能夠給予提高實時性所需的必要支持。”
除去中斷延遲時間較長以外，Linux運行時會發生在某一段時間內禁止搶占的現象，即使在v2.6內核中加入了“搶占補丁”後仍舊存在這個問題。有測試數據表明Linux的v2.6內核在最壞情況下的響應時間是1.2毫秒。這個數值雖然比2.4版本的20毫秒有了很大的提高，但是一個實時嵌入式操作系統在最壞情況下的響應時間最差也應該是在亞微秒這個量級上（需要依賴於具體的硬件配置），因此Linux相對於這個標准還有很大的差距。而且Linux系統中實測到的時間並不能反映出理論上的最壞情況，這一點在實時系統中是絕不允許的。
設備驅動程序
如果設備驅動代碼運行在各自受保護的地址空間中，就會大大減少給系統帶來的風險。現在，具有虛擬設備驅動結構的操作系統摒棄了傳統的將設備驅動程序運行在內核物理存儲空間的方法。在這種結構中，有些虛擬設備驅動由中斷服務程序喚起，在內核空間以外對設備進行管理。還有些驅動采用的是非中斷驅動的方式，直接在被映射到驅動進程內的設備相關的存儲地址空間內進行操作。這種實現需要通過一套靈活、強大並且有效的API使得虛擬設備驅動能夠安全地使用它所需的物理設備資源。
但是Linux系統缺乏這種虛擬設備驅動結構。雖然現在的Linux能夠為應用提供受保護的虛擬存儲空間，但是它還是將復雜的設備驅動程序加入到了自己的物理內核地址空間中執行，這就平添了很多風險。傳統的增加新Linux設備驅動的方法是將這個驅動代碼編譯為目標文件，然後將其鏈接進內核中或者由內核模塊裝載器將它動態地裝載。這些驅動程序很難被調試而且可以不受限制地訪問任意物理存儲空間。
Linux的單核設計在系統的穩定性、可靠性以及安全性等諸多方面存在著問題。一個更好的結構，比如在一些嵌入式操作系統中已經采用了微核結構，就將設備驅動程序、網絡協議棧、文件系統和其他復雜的軟件放到應用地址空間中，這樣就不會危害到內核以及其他應用了。
上述Linux操作系統在嵌入式系統領域面臨的種種技術挑戰已經引起了業界的重視。目前已經有多種措施來提高Linux系統的實時性能。主要策略有:
● 增加實時子內核。如RTLinux，由兩個子內核構成，一個用於Linux環境，一個用於實時環境。另外遵循GPL的RTAI（實時應用程序接口）也類似於這種方式，采取硬件虛擬化技術對Linux內核做了硬實時（Hard Real-Time）的擴充。這兩種方法可以有效改善系統中斷延遲時間的問題。
● 為Linux打實時補丁。可以借助Linux操作系統的源代碼補丁來提高系統的實時性能。當前主要的實時補丁有低響應時間補丁、搶先任務補丁以及實時調度程序補丁等等。雖然打過補丁的Linux系統能夠改善系統實時性能，但是仍舊不能夠用於任務繁重的實時嵌入式系統應用中。
技術的改進為Linux在嵌入式系統中的應用掃除了一些障礙，但是如果Linux操作系統想在嵌入式領域奪取一席之地，要做的事情還遠不止這些。
非技術因素
貌似免費
Linux的廣泛應用很大程度上來源於大眾對“Linux是免費的”這個概念的誤解。在現實情況中，使用嵌入式Linux產品的相關費用是非常昂貴的。例如，MontaVista、Hard Hat Linux的開發商，每年要向每個使用其產品的嵌入式系統開發人員收取1.5萬美元的費用。按照五年計算，一個由五人組成的嵌入式系統開發團隊就需要支付37.5萬美元。與此相比，很多由開發商獨立設計提供的嵌入式系統解決方案的花銷都要低很多。
還有一些使用Linux的嵌入式系統開發者選擇直接從網上下載Linux資源，然後按照“業內權威”的意見和建議來解決在Linux使用中碰到的各種問題。他們以為這樣做就避免了使用商業化產品帶來的巨額花銷，但實際上他們低估了用於支持Linux使用帶來的內部消耗。有些公司宣稱他們只需要一個全職的Linux高手做員工就能解決一切問題。而根據一個保守的估計，這些公司每年要為這個全職的員工支付15萬美元的薪水，那麼五年下來的開銷就是75萬美元，這遠遠大於它們去采用那些專門的嵌入式系統解決方案所需的費用。而且還有一個問題不能忽視，那就是雖然一個“權威”可以解決很多的Linux問題，但是他們顯然還是不如那些產品研發者對自己的東西了解得透徹。
相對於其他專門的嵌入式系統解決方案，支持Linux的開銷太高，所以有很多曾經試圖采用嵌入式Linux系統後來又發現這個實際情況的用戶給Linux找了個新的形容詞：貌似免費。
長期的支持
大部分的嵌入式產品都有一定的市場周期，一般是幾年。有些航空電子設備前期開發要耗費十幾年的時間，而它真正的使用時間也不過就是比研發時間長幾年。甚至某些手持設備從開始在工廠裡研發到最後在市場上消失，整個生命周期也就是幾年的光景。
嵌入式系統的開發人員往往希望他們的產品所依托的開發商具有穩定的、經得起考驗的運作模式。因為他們必須要依賴這些開發商在較長時間內來支持他們的產品，更關鍵的是還要能夠繼續支持他們進行後續產品的開發。
很多嵌入式Linux開發商已經意識到他們並不能夠滿足嵌入式系統開發者所要求的長期支持和服務。惟一的解決方法就是適當地增加售後支持工程師的隊伍。而目前大部分嵌入式Linux開發商采用的運營方式是以相對低廉的價格出售他們的產品，並以此作為主要盈利方式。
有一些已經意識到了這一困境的開發商為了賣出產品，就開始對Linux進行一些自己獨有的嵌入式系統擴充，或者是增加一些迎合市場需求的軟件。這麼做使他們陷入了另一個境地:通過增加那些獨有的嵌入式系統擴充，Linux開發商將成為另一個自行設計的專用嵌入式系統解決方案的提供商，而不再是一個純粹的嵌入式Linux開發商。Linux社團不會接受更不會去提倡Linux開發商們的這種行為，因為他們這麼做已經違背了Linux倡導的自由精神。
Linux在嵌入式系統領域的應用面臨著重重挑戰，有技術層面上的，更有非技術層面上的。這些挑戰造成了當前Linux在嵌入式系統領域舉步維艱的局面。到底Linux是不是適合於嵌入式系統的應用是我們當前務必要認真思考的一個問題，畢竟Linux操作系統從誕生之日起就是為桌面和服務器系統打造的，也許將它應用於嵌入式領域只是我們的一相情願。 GPL
Linux是受GPL約束的。GPL規范了各家公司如何才能夠將GPL許可的軟件整合到它們自己的產品中再銷售給用戶。將GPL軟件整合進產品中會導致一些技術問題。但還有一些問題是經常被忽視的，那就是由GPL許可證本身帶來的問題。其中與各方利益關系最密切的就是如果在自己開發的產品中采用了一些GPL軟件，那麼是不是就意味著這個產品也要受到GPL的約束。
操作系統在整個嵌入式系統中的地位是舉足輕重的。在GPL的條款中強調：“你必須使你發布或出版的作品（它包含程序的全部或一部分，或包含由程序的全部或部分衍生的作品）允許第三方作為整體按許可證條款免費使用。”正是這一條款，使得開發商們不可能願意冒風險去將GPL軟件整合進自己的產品中。
有很多公司花費了大量的資金去研究使用GPL軟件可能帶來的問題，還有一些用戶團隊也正致力於研究這些因為軟件許可證而導致的問題。但是他們發現由於對GPL的解讀各有不同，這裡存在著大量的“灰色地帶”。即使是那些在Linux團體中很有聲望的人士對於GPL應用的觀點也往往不一致。一個最值得注意的問題就是Linux中的“可加載模塊”。這個概念在前文中已經提到過了，Linux用戶是可以動態地將模塊直接加載到內核當中的。Linux社團中的一些很著名的人物堅稱“可加載模塊”必須遵守GPL許可證。然而，Linus Torvalds——Linux之父卻持有相反的觀點。他認為“可加載模塊”不應該受到GPL的約束。還有其他一些人覺得“可加載模塊”是否要遵循GPL許可證是要根據該模塊與內核間是不是存在某些類似的風格（比如是否共享了一些數據結構等等）來判斷的。正是因為存在著規則解讀不明的情況，所以很多公司和用戶都對GPL感到不滿：因為灰色地帶就意味著風險。
GPL對那些試圖將開源軟件整合進自己產品的公司還提出了另一個挑戰，那就是關於這些公司是否會存在專利侵權和著作權被侵犯的問題。GPL並不對用戶提供保證以避免遵守許可證的代碼被侵權，同樣GPL也不能夠保證被許可的代碼沒有侵犯已有的專利。實際上，GPL已經明確地說明了它沒有辦法做這樣的保證聲明，這使得用戶在使用GPL軟件後只能自己去面對那些可能的專利和版權糾紛。如果這些糾紛在產品已經量產並推向市場後發生，那麼開發商必須面對的就是復雜的召回工作或者是付給專利持有者巨額的費用。
開放的標准
Linux在有些人的印象中是開放標准的。其實並非如此，Linux只是一款開放源碼軟件。開放源碼的軟件是指可以自由使用，而且是可以自由修改的軟件。而開放的標准是指一個規范，這個規范是能夠被自由地閱讀和實現的。開放標准可以增強技術實現的移植性，還避免了技術被某家開發商壟斷的情形出現。因為Linux是沒有標准來規范其發行的，所以各家開發商在發布各自的產品時對Linux所做的改動存在著較大差異，這直接導致了很多應用不能夠跨系統移植。
POSIX（可移植的操作系統接口）就是開放標准的一個例子。它描述的是操作系統中的應用接口標准。已經有很多不同的操作系統開發商在他們各自的產品中提供了符合POSIX標准的接口。這就使得應用的開發者擺脫了只能局限於一家操作系統的困境，其編寫的代碼可以不加修改很方便地移植到其他的遵守POSIX標准的操作系統上。
在Unix操作系統中就早已定義了通用的接口集合。這個集合就是今天POSIX標准的基礎。有人可能會想既然Linux是脫胎於Unix的，那麼Linux也應該是符合POSIX標准才對。但事實上，雖然Linux目前具有一套類似POSIX的接口，但在很多關鍵的地方它們是並不一致的，比如之前談到過的調度問題、信號以及線程的實現等等。即使是最新版本的Linux線程庫（NPTL，Native POSIX Thread Library for Linux）也不是完全和POSIX兼容的。開發者們會發現他們編寫的可移植的POSIX應用並不能夠在Linux系統上正常工作，反之亦然。
這些不一致帶來的後果可能是災難性的。例如，二者對setuid系統調用的實現差異就會導致很大的問題。POSIX標准中要求只要有一個線程調用了setuid，那麼和該線程同屬一個進程的所有線程都會受到這次調用的影響。但是在Linux系統中，只有調用了setuid的那個線程才會做出相應的反應，而其他線程仍舊維持原狀。一些POSIX進程在創建時可能具有超級用戶的權限（比如系統管理員編寫的程序），因此它們具有完全的系統訪問權，比如可以刪除計算機上的任何用戶文件等等。出於安全原因的考慮，在這些程序完成一些只有超級用戶才能完成的工作後，往往會調用setuid來降低它們自己的權限。如果這樣一個符合POSIX標准的程序運行在Linux系統上，我們會發現那些在調用setuid之前創建的線程在調用後都還保持著超級用戶的權限。那麼對於一個有害的程序，也許它不能夠在符合POSIX標准的系統上興風作浪，但它卻能夠在Linux系統中干盡壞事。
也許有人會考慮開源操作系統的開發者們也可以進行開放的操作系統標准的研究。但實際上，Linus Torvalds本人就是不贊同POSIX的，他說：“POSIX是一個發育不健全的標准，是成不了氣候的。我們不准備按照POSIX標准來設計操作系統。”那麼Linux會成為一個與POSIX標准相兼容的操作系統麼？Linus又說：“現在的情況是，沒有理由去改變現狀。”
