實時操作系統(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)用程序行為是及其困難的,這些行為由于原始的原因或者是很微小的,或者是破壞性的。[!--empirenews.page--]Linux編程模型的內(nèi)部編譯的可靠性
Linux作為一個unix兼容的操作系統(tǒng)代表著一個更加強大的應(yīng)用和系統(tǒng)編程模型。應(yīng)用程序執(zhí)行在他們受保護的地址空間,因為它們之間的地址相互是不可見的,并且它們通過硬件的MMU來預(yù)防覆蓋掉他們自己的代碼,MMU出現(xiàn)在多數(shù)現(xiàn)代化的32位64位的處理器中。
當(dāng)他們共享Linux內(nèi)核的虛擬地址空間時,他們不能夠覆蓋內(nèi)核代碼或數(shù)據(jù)。既然進程不能夠相互看到,他們就不能夠相互破壞數(shù)據(jù)或代碼
API和實時庫
在開源標(biāo)準以前,RTOS的制作者定義了他們自己的系統(tǒng)調(diào)用或API,這對于每個RTOS的制作者來說都是獨一無二的。接口函數(shù)是為流行的編程語言而提供的,諸如c、c++,這使得API函數(shù)對于使用高級語言的程序員是合適的。
在過去的十年中,盡管只有POSIX規(guī)范的一部分和嵌入式應(yīng)用程序相關(guān),大多數(shù)的RTOS制作者還是給標(biāo)準的POSIX提供了兼容庫。很多客戶使用他們自己的API集使本地RTOS接口分層以獲得獨立性和便捷性,而不是想被鎖定成為一個私有的特殊版權(quán)的接口。
開發(fā)人員使用標(biāo)準的API建立應(yīng)用程序來獲得兩個另外的目的:允許代碼被移植成像Linux那樣的標(biāo)準操作系統(tǒng)以及允許以后同樣的代碼在這樣的一個環(huán)境下比使用私有的API更加容易移植。
很多包括標(biāo)準調(diào)用的商業(yè)RTOS以POSIX或者BSD來設(shè)定,但是那些API經(jīng)常只存在于windows下。特別是一個內(nèi)核私有的API是最常被使用的,就是這些API鎖定了項目到一個特殊的平臺或者解決方案。
如果開發(fā)人員正在移植標(biāo)準的代碼或者考慮哪個API運用到新的代碼中,那么理解在Linux和其他操作系統(tǒng)中使用的最普遍的標(biāo)準是非常重要的。
POSIX
POSIX流行在基于UNIX的開源系統(tǒng)中、政府和軍事舞臺。然而POSIX對于傳統(tǒng)的嵌入式實時系統(tǒng)幾乎沒有影響。POSIX標(biāo)準家族起源于美國國家標(biāo)準與技術(shù)研究所,現(xiàn)在有被歸入IEEE、IEEE1003和其他標(biāo)準的預(yù)兆。在過去的十年中,POSIX經(jīng)歷了多次的修訂,最近的一次是在2000年。
兼容性和一致性是兩個關(guān)于POSIX的重要觀點。兼容性意味著一個特定的操作系統(tǒng)平臺貫徹標(biāo)準的一些子集,這種貫徹是備有文件證明的。甚至那些執(zhí)行微小子集的平臺能夠兼容于POSIX標(biāo)準。POSIX的一致性,相反的,代表了更加嚴格的標(biāo)準,意味著一個操作系統(tǒng)服從于過去的已證明測試。
SVR4,BSD和其他UNIX的API
事實上SVR4和UNIX的BSD版本是流行的系統(tǒng)標(biāo)準,這些標(biāo)準對于Linux的影響是巨大的。Linux貫徹了那些UNIX API的大的子集(舉個例子,對于共享內(nèi)存、隊列、信號量、BSD套接口和TCP/IP堆的Linux的ipc系統(tǒng)調(diào)用)。
熟悉SVR4、BSD,或者像AIX,HP-UX等其他通用的UNIX的開發(fā)人員對于Linux他們也能夠很快的掌握。
c語言庫
在嵌入式設(shè)計、RTOS或其他方面,很多API僅僅是標(biāo)準c庫,這些庫或者是直接執(zhí)行函數(shù)或者是作為系統(tǒng)調(diào)用的包裝。Linux有熟悉的libc/glibc,盡管尺寸很大,但易于理解。
glibc的運行時間是對嵌入式應(yīng)用程序內(nèi)存尺寸的挑戰(zhàn)。很多Linux的供應(yīng)商為對于尺寸敏感的應(yīng)用程序提供了經(jīng)過裁減了的庫。
RTOS接口層
RTOS的核心是對于進程間通訊調(diào)用的使用,這種調(diào)用提供了在任務(wù)中同步和通訊的機制。
表1提供了在典型的RTOS進程間通訊調(diào)用和同等的Linux調(diào)用之間的映射總結(jié)。
盡管在RTOS的調(diào)用和同等的Linux調(diào)用之間的映射是直接的,但是移植的工作量會被增加,如果使用仿真庫,這種仿真庫為其他RTOS移植過來的Linux應(yīng)用程序提供了同樣的調(diào)用接口。
對于Xenomai開源項目,這樣的一個仿真技術(shù)是適用的。而這里,不同的仿真層提供給POSIX、VxWorks、VRTX和Itron這些被廣泛使用的RTOS。注意,像很多開源項目,Xenomai和它的外殼是正在進行的工作,他們可能還沒有完成或者還要進行修改。不過,它代表了一個在移植過程中潛在的高價值的出發(fā)點。
舉個例子,POSIX模塊主要是用來提供PSE51兼容的API.為了幫助移植其他PSE51兼容
API的應(yīng)用程序,它包含了一些對于POSIX規(guī)范的擴展。
POSIX外殼已經(jīng)包含了以下這些基本的特色:
線程
互斥量
信號量
條件變量
實時信號的支持
放棄和放棄處理
特殊線程數(shù)據(jù)
消息隊列
定時器支持
共享內(nèi)存
POSIX外殼創(chuàng)建實時線程,他們或是運行在Linux內(nèi)核模塊或者在用戶空間的周期應(yīng)用程序中。
實時內(nèi)核的API允許內(nèi)核和用戶空間的編程。開發(fā)人員通常更喜歡在用戶空間編程,因為他們之間的延遲小,特別是在硬件上,MMU的切換開銷很小。目前為止在用戶空間編程比直接從內(nèi)核空間運行應(yīng)用程序更為容易。在用戶空間編程帶來了內(nèi)存保護和在這個環(huán)境中調(diào)試實時應(yīng)用程序的GNU調(diào)試器的支持。