實(shí)時(shí)操作系統到Linux系統的移植

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

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

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

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

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

　　編程模型

　　幾乎所有使用的RTOS有一個(gè)簡(jiǎn)單的編程模型，它由多線(xiàn)程的執行(通常稱(chēng)為任務(wù))構成，包含在單一的地址空間中。舉例來(lái)說(shuō)，一個(gè)c語(yǔ)言的程序有一個(gè)單一的主函數,它創(chuàng )建所有其他的線(xiàn)程。每一個(gè)線(xiàn)程依次被定義為總程序中的一個(gè)c函數。典型的，不管是RTOS還是非保護內存中的應用程序，他們的物理地址和邏輯地址都是一樣的?？赡軙?huì )有一些超級用戶(hù)模式下的操作使用限制了在用戶(hù)模式下的應用程序發(fā)出一些指令?；旧?，所有的內存對于應用程序來(lái)說(shuō)是虛擬的。

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

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

　　RTOS的全部應用代碼移植到一個(gè)Linux單進(jìn)程

　　RTOS的任務(wù)轉換成Linux線(xiàn)程

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

　　諸如VME機架的多板或多處理器架構，移植到一個(gè)多進(jìn)程的Linux應用。

　　構架上的考慮：進(jìn)程和線(xiàn)程的創(chuàng )建

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

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

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

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

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

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

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

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