實時操作系統到Linux系統的應用移植
發布時間：2010-9-25 11:21
發布者：eetech
|
從一個操作系統到另一個操作系統應用程序的移植即使在最好的情況下也經常是一個艱巨的任務。把一個實時的嵌入式應用程序移植到一個新的操作系統上可以說是一項最困難的任務。 為了幫助開發人員計劃在不久的將來轉移到嵌入式Linux上，或者考慮將現有的應用程序運行在嵌入式Linux上這種投資的必要性，Jim 解釋了這一轉換的過程，評估了涉及到的困難和挑戰，并且闡述了認識這種轉換的益處。 越來越多的公司正在轉向嵌入式Linux，把它作為他們下一代產品的操作系統。然而他們以前都是使用實時操作系統作為他們的嵌入式系統。事實上，VDC的報告顯示了嵌入式Linux可以占到32位和64位領域設計的三分之一，是其他所有嵌入式系統的兩倍。 很明顯，關于從老式RTOS產品的應用程序移植到Linux的可行性的問題必須得到回答，由此這種移植才能夠被有效的用于工程管理。 一個典型的基于RTOS的應用程序依賴于很多因素,其中最重要的是編程/內存模型、API、性能、特別是實時響應的能力。另外一個重要的考慮是軟件開發環境，但那是軟件環境文章值得討論的話題。 編程模型 幾乎所有使用的RTOS有一個簡單的編程模型，它由多線程的執行（通常稱為任務）構成，包含在單一的地址空間中。舉例來說，一個c語言的程序有一個單一的主函數,它創建所有其他的線程。每一個線程依次被定義為總程序中的一個c函數。典型的，不管是RTOS還是非保護內存中的應用程序，他們的物理地址和邏輯地址都是一樣的�？赡軙幸恍┏売脩裟Ｊ较碌牟僮魇褂孟拗屏嗽谟脩裟Ｊ较碌膽贸绦虬l出一些指令�；旧�，所有的內存對于應用程序來說是虛擬的。 在過去，大多數嵌入式處理器沒有內存管理單元，因此RTOS單地址空間模式是必須的。然而今天大多數的中高端處理器配備了MMU，因此如果需要的話，MMU能夠管理內存。 該體系結構的描述提出了一個移植RTOS代碼到Linux上的簡單架構。 RTOS的全部應用代碼移植到一個Linux單進程 RTOS的任務轉換成Linux線程 RTOS的物理地址空間映射到Linux的虛擬地址空間 諸如VME機架的多板或多處理器架構，移植到一個多進程的Linux應用。 構架上的考慮：進程和線程的創建 是否使用遵循API的VXWORKS和PSOS等RTOS仿真軟件包，開發人員最終必須決定是否將線程或是進程作為執行RTOS的任務。在這點上，Linux內核對待不管是線程還是進程都是同等的，都是以調度為目的。然而不同的API創建和管理每個實體的類型、性能、資源的成本和益處都是關聯的。 通常來說，進程比線程大一點，因為他們傳送著更多的上下文信息。一個Linux線程的上下文如同RTOS的一個任務，主要由cpu寄存器、堆棧、當前的程序指針以及一些內核數據結構的入口組成。一個進程加上一個完整的虛擬地址空間。這樣，至少內核必須創建和跟蹤進程的頁轉換、所有代碼的類型、上下文、數據等。對于重量級進程上下文的主要影響有兩點:創建的時間和相互的上下文切換時間。 只要可能，RTOS的代碼都會爭取要輕量級的執行。同樣的，當很多RTOS提供了動態的任務創建API,其他以靜態任務定義頁表為特色，所有RTOS的商家不鼓勵使用頻繁的任務創建以節省時間和空間。Linux進程的創建不是故意那么麻煩；Linux進程是重量級的，因為他們提供了更多的保護性和依賴性。 這個熟悉地老式的架構，因為簡單，所以非常容易遭受破壞。正在運行的任務能夠覆蓋應用程序的代碼和數據，另外還會寫入到外圍設備的寄存器、破壞內核的數據結構、覆蓋內核代碼。任務的堆棧能夠很容易的溢出，并且一個接一個被覆蓋掉或者通過控制內存來破壞堆的頂部、其他數據或者附近的代碼。 更高的層次來說，這種非正式有組織的，高度非遮掩的架構提出了對于代碼質量的兩個主要挑戰：自身的失敗機會以及和主要事件再次失敗的結合。 當個別任務或者其他軟件組件失敗了，它失敗的原因幾乎不可能被定位。甚至當檢測到失敗并且嘗試恢復時候會以整個系統的失敗而結束。監視代碼不能夠經常安全地重啟任務，RTOS不能夠恢復由失敗任務動態定位的資源。結果就是復位通常是通過強制使用看門狗定時器來完成的，看門狗定時器重新啟動整個系統或者軟件引起的系統錯誤。 通常當一個程序跑飛了，它沒有任何征兆。一個錯誤的任務能夠破壞在RTOS系統中任何地方的數據和代碼。幸運的是，雖然這些破壞的影響瞬間產生，但是好像破壞的影響會在幾秒、幾小時、幾個月以后才會出現。 當異常的征兆出現了，去聯想預想不到的應用程序行為是及其困難的，這些行為由于原始的原因或者是很微小的，或者是破壞性的。 Linux編程模型的內部編譯的可靠性 Linux作為一個 unix兼容的操作系統代表著一個更加強大的應用和系統編程模型。應用程序執行在他們受保護的地址空間，因為它們之間的地址相互是不可見的，并且它們通過硬件的MMU來預防覆蓋掉他們自己的代碼，MMU出現在多數現代化的32位64位的處理器中。 當他們共享Linux內核的虛擬地址空間時，他們不能夠覆蓋內核代碼或數據。既然進程不能夠相互看到，他們就不能夠相互破壞數據或代碼 API和實時庫 在開源標準以前，RTOS的制作者定義了他們自己的系統調用或API，這對于每個RTOS的制作者來說都是獨一無二的。接口函數是為流行的編程語言而提供的，諸如c、c++，這使得API函數對于使用高級語言的程序員是合適的。 在過去的十年中，盡管只有POSIX規范的一部分和嵌入式應用程序相關，大多數的RTOS制作者還是給標準的POSIX提供了兼容庫。很多客戶使用他們自己的API集使本地RTOS接口分層以獲得獨立性和便捷性，而不是想被鎖定成為一個私有的特殊版權的接口。 開發人員使用標準的API建立應用程序來獲得兩個另外的目的：允許代碼被移植成像Linux那樣的標準操作系統以及允許以后同樣的代碼在這樣的一個環境下比使用私有的API更加容易移植。 很多包括標準調用的商業RTOS以POSIX或者BSD來設定，但是那些API經常只存在于windows下。特別是一個內核私有的API是最常被使用的，就是這些API鎖定了項目到一個特殊的平臺或者解決方案。 如果開發人員正在移植標準的代碼或者考慮哪個API運用到新的代碼中，那么理解在Linux和其他操作系統中使用的最普遍的標準是非常重要的。 POSIX POSIX流行在基于UNIX的開源系統中、政府和軍事舞臺。然而POSIX對于傳統的嵌入式實時系統幾乎沒有影響。POSIX標準家族起源于美國國家標準與技術研究所，現在有被歸入IEEE、IEEE1003和其他標準的預兆。在過去的十年中，POSIX經歷了多次的修訂，最近的一次是在2000年。 兼容性和一致性是兩個關于POSIX的重要觀點。兼容性意味著一個特定的操作系統平臺貫徹標準的一些子集，這種貫徹是備有文件證明的。甚至那些執行微小子集的平臺能夠兼容于POSIX標準。POSIX的一致性，相反的，代表了更加嚴格的標準，意味著一個操作系統服從于過去的已證明測試。 SVR4,BSD和其他UNIX的API 事實上SVR4和UNIX的BSD版本是流行的系統標準，這些標準對于Linux的影響是巨大的。Linux貫徹了那些UNIX API的大的子集（舉個例子，對于共享內存、隊列、信號量、BSD套接口和TCP/IP堆的Linux的ipc系統調用）。 熟悉SVR4、BSD，或者像AIX,HP-UX等其他通用的UNIX的開發人員對于Linux他們也能夠很快的掌握。 c語言庫 在嵌入式設計、RTOS或其他方面，很多API僅僅是標準c庫，這些庫或者是直接執行函數或者是作為系統調用的包裝。Linux有熟悉的libc/glibc，盡管尺寸很大，但易于理解。 glibc的運行時間是對嵌入式應用程序內存尺寸的挑戰。很多Linux的供應商為對于尺寸敏感的應用程序提供了經過裁減了的庫。 RTOS接口層 RTOS的核心是對于進程間通訊調用的使用，這種調用提供了在任務中同步和通訊的機制。 表1提供了在典型的RTOS進程間通訊調用和同等的Linux調用之間的映射總結。 盡管在RTOS的調用和同等的Linux調用之間的映射是直接的，但是移植的工作量會被增加，如果使用仿真庫，這種仿真庫為其他RTOS移植過來的Linux應用程序提供了同樣的調用接口。 對于Xenomai開源項目，這樣的一個仿真技術是適用的。而這里，不同的仿真層提供給POSIX、VxWorks、VRTX和Itron這些被廣泛使用的RTOS。注意，像很多開源項目，Xenomai和它的外殼是正在進行的工作，他們可能還沒有完成或者還要進行修改。不過，它代表了一個在移植過程中潛在的高價值的出發點。 舉個例子，POSIX模塊主要是用來提供PSE51兼容的API.為了幫助移植其他PSE51兼容 API的應用程序，它包含了一些對于POSIX規范的擴展。 POSIX外殼已經包含了以下這些基本的特色：
POSIX外殼創建實時線程，他們或是運行在Linux內核模塊或者在用戶空間的周期應用程序中。 實時內核的API允許內核和用戶空間的編程。開發人員通常更喜歡在用戶空間編程，因為他們之間的延遲小，特別是在硬件上，MMU的切換開銷很小。目前為止在用戶空間編程比直接從內核空間運行應用程序更為容易。在用戶空間編程帶來了內存保護和在這個環境中調試實時應用程序的GNU調試器的支持。 實時性能 也許對于嵌入式應用程序來說最重要的是滿足實時的要求。對于設計RTOS使得它們及時響應來滿足實時的要求，并且測量RTOS的系統調用，已經做了相當大的努力加以實現，因此開發人員能夠確定系統的性能滿足于實時的要求。RTOS的調用在一定意義上是循環的，應用程序和由RTOS提供的中斷是同步的。因此進行一個同步調用花費RTOS的時間是中斷處理時間的一部分。 在2002年以前，Linux的實時性比較差，而它的吞吐量特別是在網絡方面比較好。然而那是吞吐量而不是實時性。原因是基本的Linux內核和unix應用框架。這些系統被設計成在應用程序開銷的時候，內核執行它所需要的。其原因就是如果開發人員知道內核不會被一個異常中斷搶占，內核的代碼就更容易編寫。 雖然這種方法被廣泛使用于unix和早期的Linux中，但是近來有一個下降的趨勢。它使得運行在多處理器體系的系統變得效率很低。同一時刻，非搶占式Linux使得Linux達到實時的標準變得困難，因為即使一個中斷發生并且中斷事件被調度運行，內核還會完成當前的任務。為了解決在多處理器系統的運行效率問題，Linux內核的開發人員開始侵入Linux內核的內部區域讓它非搶占區域變得更小，以至于更多的內核區域在多處理器系統上能夠并行的執行并且完成的更好。 那些對于改善Linux實時性有興趣的人使用搶占的Linux內核來加速本地的實時響應。延遲減小到幾百微秒到1毫秒之間。更多的性能提高包括縮短非搶占區域來減小那些區域帶來的任何延遲。 自2002年以來，Linux已經支持實時應用程序。從那時起，Linux開發人員開始加強它的實時性能，標準Linux的實時性能在不斷的提高�，F在Linux的實時性能相當于大多數特有的實時內核。最近出現了對于Linux實時能力的重要推進，消耗CPU時間的同步機制的自旋鎖被繼承優先級互斥這種更可靠的同步機制替代了�；コ鈾C制保證了cpu時間總是盡可能的分配給優先級最高的應用程序，從而更縮短了從中斷到實時應用程序的過程。 最后一個主要的實時Linux的改進是將中斷處理作為一個應用程序的標準來執行。以前Linux的設計賦予中斷處理比任何其他應用程序更高的優先級。通過把中斷處理作為一個普通的應用程序處理，一旦優先級更高的應用程序可以搶占比它優先級低的中斷處理程序。 現在這些改變已經完成，性能和穩定性的改進使得Linux上的應用和以前基于傳統的實時操作系統擁有一樣的快速和穩定。 邁步向前 現在開發者正在放棄第一代實時操作系統，選擇更穩定的一個開放式的嵌入式平臺比如像Linux。移植這些傳統的系統代表著挑戰同時又提供了非常豐厚的投資回報。真正的風險不是放棄熟悉的環境，工具和API，而是當嵌入式系統開發不斷前進時候，它卻停滯不前。 遵循這篇文章概括的步驟和RTOS的移植技術， 開發人員可以通過最少的時間和精力成功地移植以前的RTOS的代碼到一個現代化的Linux平臺上來。 Jim Ready是montavista的創始人和CTO, 擁有25以上的技術和豐富的經驗， Jim被認為是在嵌入式系統和實時軟件工程里的權威。做為Ready System的合伙創始人，他倡導VRTX實時內核的開發，VRTX是第一個用于商業用途的RTOS產品。在Ready System和Microtec Research合并期間，Jim在Microtec/Mentor Graphics任職Ready System的董事長兼CTO，Microtec Research后來被Mentor Graphics收購了。他在1999創建了montavista 軟件公司，提供Linux系統到嵌入式系統市場并且給開源的Linux社區提供了嵌入式系統的專業技術。Jim分別在伊利諾斯大學，加利福尼亞大學獲得了學士和碩士學位。 |
網友評論