實時操作系統(tǒng)到Linux系統(tǒng)的移植

從一個操作系統(tǒng)到另一個操作系統(tǒng)應(yīng)用程序的移植即使在最好的情況下也經(jīng)常是一個艱巨的任務(wù)。把一個實時的嵌入式應(yīng)用程序移植到一個新的操作系統(tǒng)上可以說是一項最困難的任務(wù)。

　　為了幫助開發(fā)人員計劃在不久的將來轉(zhuǎn)移到嵌入式Linux上，或者考慮將現(xiàn)有的應(yīng)用程序運行在嵌入式Linux上這種投資的必要性，Jim 解釋了這一轉(zhuǎn)換的過程，評估了涉及到的困難和挑戰(zhàn)，并且闡述了認識這種轉(zhuǎn)換的益處。

　　越來越多的公司正在轉(zhuǎn)向嵌入式Linux，把它作為他們下一代產(chǎn)品的操作系統(tǒng)。然而他們以前都是使用實時操作系統(tǒng)作為他們的嵌入式系統(tǒng)。事實上，VDC的報告顯示了嵌入式Linux可以占到32位和64位領(lǐng)域設(shè)計的三分之一，是其他所有嵌入式系統(tǒng)的兩倍。

　　很明顯，關(guān)于從老式RTOS產(chǎn)品的應(yīng)用程序移植到Linux的可行性的問題必須得到回答，由此這種移植才能夠被有效的用于工程管理。

　　一個典型的基于RTOS的應(yīng)用程序依賴于很多因素,其中最重要的是編程/內(nèi)存模型、API、性能、特別是實時響應(yīng)的能力。另外一個重要的考慮是軟件開發(fā)環(huán)境，但那是軟件環(huán)境文章值得討論的話題。

　　編程模型

　　幾乎所有使用的RTOS有一個簡單的編程模型，它由多線程的執(zhí)行(通常稱為任務(wù))構(gòu)成，包含在單一的地址空間中。舉例來說，一個c語言的程序有一個單一的主函數(shù),它創(chuàng)建所有其他的線程。每一個線程依次被定義為總程序中的一個c函數(shù)。典型的，不管是RTOS還是非保護內(nèi)存中的應(yīng)用程序，他們的物理地址和邏輯地址都是一樣的。可能會有一些超級用戶模式下的操作使用限制了在用戶模式下的應(yīng)用程序發(fā)出一些指令。基本上，所有的內(nèi)存對于應(yīng)用程序來說是虛擬的。

　　在過去，大多數(shù)嵌入式處理器沒有內(nèi)存管理單元，因此RTOS單地址空間模式是必須的。然而今天大多數(shù)的中高端處理器配備了MMU，因此如果需要的話，MMU能夠管理內(nèi)存。

　　該體系結(jié)構(gòu)的描述提出了一個移植RTOS代碼到Linux上的簡單架構(gòu)。

　　RTOS的全部應(yīng)用代碼移植到一個Linux單進程

　　RTOS的任務(wù)轉(zhuǎn)換成Linux線程

　　RTOS的物理地址空間映射到Linux的虛擬地址空間

　　諸如VME機架的多板或多處理器架構(gòu)，移植到一個多進程的Linux應(yīng)用。

　　構(gòu)架上的考慮：進程和線程的創(chuàng)建

　　是否使用遵循API的VXWORKS和PSOS等RTOS仿真軟件包，開發(fā)人員最終必須決定是否將線程或是進程作為執(zhí)行RTOS的任務(wù)。在這點上，Linux內(nèi)核對待不管是線程還是進程都是同等的，都是以調(diào)度為目的。然而不同的API創(chuàng)建和管理每個實體的類型、性能、資源的成本和益處都是關(guān)聯(lián)的。

　　通常來說，進程比線程大一點，因為他們傳送著更多的上下文信息。一個Linux線程的上下文如同RTOS的一個任務(wù)，主要由cpu寄存器、堆棧、當(dāng)前的程序指針以及一些內(nèi)核數(shù)據(jù)結(jié)構(gòu)的入口組成。一個進程加上一個完整的虛擬地址空間。這樣，至少內(nèi)核必須創(chuàng)建和跟蹤進程的頁轉(zhuǎn)換、所有代碼的類型、上下文、數(shù)據(jù)等。對于重量級進程上下文的主要影響有兩點:創(chuàng)建的時間和相互的上下文切換時間。

　　只要可能，RTOS的代碼都會爭取要輕量級的執(zhí)行。同樣的，當(dāng)很多RTOS提供了動態(tài)的任務(wù)創(chuàng)建API,其他以靜態(tài)任務(wù)定義頁表為特色，所有RTOS的商家不鼓勵使用頻繁的任務(wù)創(chuàng)建以節(jié)省時間和空間。Linux進程的創(chuàng)建不是故意那么麻煩;Linux進程是重量級的，因為他們提供了更多的保護性和依賴性。

　　這個熟悉地老式的架構(gòu)，因為簡單，所以非常容易遭受破壞。正在運行的任務(wù)能夠覆蓋應(yīng)用程序的代碼和數(shù)據(jù)，另外還會寫入到外圍設(shè)備的寄存器、破壞內(nèi)核的數(shù)據(jù)結(jié)構(gòu)、覆蓋內(nèi)核代碼。任務(wù)的堆棧能夠很容易的溢出，并且一個接一個被覆蓋掉或者通過控制內(nèi)存來破壞堆的頂部、其他數(shù)據(jù)或者附近的代碼。

　　更高的層次來說，這種非正式有組織的，高度非遮掩的架構(gòu)提出了對于代碼質(zhì)量的兩個主要挑戰(zhàn)：自身的失敗機會以及和主要事件再次失敗的結(jié)合。

　　當(dāng)個別任務(wù)或者其他軟件組件失敗了，它失敗的原因幾乎不可能被定位。甚至當(dāng)檢測到失敗并且嘗試恢復(fù)時候會以整個系統(tǒng)的失敗而結(jié)束。監(jiān)視代碼不能夠經(jīng)常安全地重啟任務(wù)，RTOS不能夠恢復(fù)由失敗任務(wù)動態(tài)定位的資源。結(jié)果就是復(fù)位通常是通過強制使用看門狗定時器來完成的，看門狗定時器重新啟動整個系統(tǒng)或者軟件引起的系統(tǒng)錯誤。

　　通常當(dāng)一個程序跑飛了，它沒有任何征兆。一個錯誤的任務(wù)能夠破壞在RTOS系統(tǒng)中任何地方的數(shù)據(jù)和代碼。幸運的是，雖然這些破壞的影響瞬間產(chǎn)生，但是好像破壞的影響會在幾秒、幾小時、幾個月以后才會出現(xiàn)。

　　當(dāng)異常的征兆出現(xiàn)了，去聯(lián)想預(yù)想不到的應(yīng)用程序行為是及其困難的，這些行為由于原始的原因或者是很微小的，或者是破壞性的。