從RTOS移植到實(shí)時(shí)Linux(圖)

在過去的10年中，Linux成功地取代了一些最主要的傳統(tǒng)RTOS平臺(tái)，成為了各種各樣的嵌入式設(shè)備和應(yīng)用中首選的新的嵌入式操作系統(tǒng)。盡管一度曾被認(rèn)為是不重要的平臺(tái)，但今天嵌入式Linux已經(jīng)成為主流，并引領(lǐng)著如下重要應(yīng)用領(lǐng)域的市場(chǎng)和設(shè)計(jì)份額：消費(fèi)電子、移動(dòng)和無線設(shè)備、數(shù)據(jù)聯(lián)網(wǎng)以及電信設(shè)備。

設(shè)計(jì)團(tuán)隊(duì)越來越多地期望使用Linux作為標(biāo)準(zhǔn)的嵌入式操作系統(tǒng)?？紤]Linux的種種原因包括：廣泛的硬件支持、更高的可靠性、更優(yōu)異的性能、可擴(kuò)展性以及更快的響應(yīng)速度。不過，工程師在將基于傳統(tǒng)RTOS的設(shè)計(jì)移植到嵌入式Linux時(shí)會(huì)遇到幾大難題，因?yàn)長(zhǎng)inux的架構(gòu)和傳統(tǒng)RTOS有很大的不同。

移植的時(shí)機(jī)
隨著應(yīng)用開發(fā)步伐的不斷加快和產(chǎn)品生命周期的不斷縮短，對(duì)于設(shè)計(jì)團(tuán)隊(duì)而言，能夠?qū)鹘y(tǒng)軟件移植到這些新平臺(tái)上并重新使用是十分重要的。盡管嵌入式Linux有許多優(yōu)勢(shì)，但是設(shè)計(jì)團(tuán)隊(duì)在選擇從傳統(tǒng)的RTOS進(jìn)行移植之前，必須考慮如下幾項(xiàng)因素：

● 內(nèi)存占用量。嵌入式Linux沒有傳統(tǒng)RTOS那樣緊湊。因此，工程師必須確保設(shè)備有足夠的內(nèi)存和閃存來應(yīng)對(duì)Linux更大的內(nèi)存占用量。

● 實(shí)時(shí)性考慮。嵌入式Linux可以實(shí)現(xiàn)50μs以下的響應(yīng)時(shí)間。不過，這不一定能夠滿足項(xiàng)目需求，這一點(diǎn)有助于確定是否需要RTOS。

● 認(rèn)證需求。期望轉(zhuǎn)換到嵌入式Linux的設(shè)計(jì)團(tuán)隊(duì)?wèi)?yīng)確保項(xiàng)目將仍然滿足業(yè)界特有的認(rèn)證需求，例如安全認(rèn)證或美國(guó)國(guó)防部認(rèn)證。

移植路徑選擇
盡管移植過程中存在固有的難題，但從傳統(tǒng)RTOS到Linux的移植不需要轉(zhuǎn)彎抹角。工程師可以采用以下三種路徑將應(yīng)用從傳統(tǒng)的RTOS移植到Linux。

仿真RTOS的API
第一種移植路徑是仿真?zhèn)鹘y(tǒng)RTOS的API。為了使傳統(tǒng)RTOS應(yīng)用能夠駐留并運(yùn)行在Linux上，必須具備基于Linux的運(yùn)行時(shí)服務(wù)于RTOS系統(tǒng)調(diào)用和其他API。許多（但并非全部）RTOS入口點(diǎn)和獨(dú)立編譯器庫(kù)例行程序都在Linux和glibc運(yùn)行時(shí)庫(kù)中有原樣的類似程序。如果不存在類似程序，就必須有新的代碼介入來仿真缺失的功能。即使存在類似的API，可能也會(huì)出現(xiàn)參數(shù)類型和數(shù)量不同的情況。

圖1 在Linux上仿真RTOS

傳統(tǒng)RTOS可以實(shí)現(xiàn)數(shù)百種系統(tǒng)調(diào)用和庫(kù)API。例如，VxWorks文檔描述了超過一千種獨(dú)特的函數(shù)和子例程。實(shí)際應(yīng)用只使用數(shù)十個(gè)獨(dú)特的RTOS API，而它們其余的操作都使用來自標(biāo)準(zhǔn)C/C++庫(kù)的調(diào)用函數(shù)。

為了仿真這些接口以用于移植，開發(fā)人員只需要RTOS調(diào)用的核心子集。許多OEM選擇自己建立和維護(hù)仿真輕量級(jí)庫(kù)，而其他OEM則使用來自供應(yīng)商的更全面的商用庫(kù)。除了商用庫(kù)和自主開發(fā)之外，另一種選擇是一個(gè)叫做v2lin的開源項(xiàng)目，它可以仿真數(shù)十種常用的VxWorks API。此外，v2lin項(xiàng)目經(jīng)過架構(gòu)改造之后，可用于較新的兼容于POSIX的glibc版本。

使用虛擬化進(jìn)行運(yùn)行時(shí)劃分
對(duì)于期望采用Linux的工程師而言，虛擬化是另一種可行的移植路徑。虛擬化包括操作系統(tǒng)的駐留或者作為一個(gè)應(yīng)用程序運(yùn)行在另一個(gè)虛擬平臺(tái)之上，其中一部分系統(tǒng)軟件（運(yùn)行在“裸機(jī)”之上或作為駐留的應(yīng)用程序）可實(shí)現(xiàn)一個(gè)或多個(gè)“客戶”O(jiān)S實(shí)例的執(zhí)行。在企業(yè)級(jí)計(jì)算中，基于Linux的虛擬化技術(shù)是數(shù)據(jù)中心的主流功能，而且虛擬化也在嵌入式系統(tǒng)中找到了許多的應(yīng)用。

嵌入式虛擬化要求將CPU、內(nèi)存和其他資源進(jìn)行劃分，以駐留RTOS以及一個(gè)或多個(gè)客戶“應(yīng)用程序”操作系統(tǒng)（通常是Linux）來運(yùn)行更高層次的軟件。

圖2 采用虛擬化劃分開的運(yùn)行時(shí)

虛擬化可以通過允許RTOS應(yīng)用程序和RTOS自身幾乎原樣地運(yùn)行在新設(shè)計(jì)之中，而Linux則運(yùn)行在自己的分區(qū)之中，以支持移植。這種方案適用于遺留代碼依賴于RTOS的API和RTOS的性能特點(diǎn)的情況，例如實(shí)時(shí)性能或協(xié)議棧的具體實(shí)現(xiàn)。

工程師可以使用虛擬化作為從遺留代碼向基于Linux的新設(shè)計(jì)過渡的簡(jiǎn)短且可靠的橋梁。不過，這種策略可能需要成本。OEM需要支付傳統(tǒng)RTOS運(yùn)行時(shí)的使用費(fèi)，還需要與VM供應(yīng)商談判商用許可證。

圖3 RTOS的本地端口

逐步將應(yīng)用移植到Linux
仿真和虛擬化可以提供直接明了的移植路徑來進(jìn)行原型制作、開發(fā)、甚至是對(duì)運(yùn)行在Linux上的傳統(tǒng)RTOS應(yīng)用進(jìn)行部署。但是，它們的缺點(diǎn)是需要額外的代碼，并會(huì)涉及基礎(chǔ)設(shè)施和許可費(fèi)用。相反，在Linux實(shí)現(xiàn)“本地化”就能降低復(fù)雜度，簡(jiǎn)化許可程序，并增強(qiáng)可移植性和性能。

圖4 將RTOS任務(wù)映射為L(zhǎng)inux線程

當(dāng)設(shè)計(jì)團(tuán)隊(duì)首次動(dòng)手處理移植項(xiàng)目時(shí)，他們往往會(huì)選擇仿真和虛擬化技術(shù)。隨著他們不斷學(xué)習(xí)并更加熟悉Linux的開發(fā)工具和運(yùn)行時(shí)屬性，OEM可以逐步地重新建造傳統(tǒng)應(yīng)用，以實(shí)現(xiàn)本地Linux執(zhí)行。

一種方法是選擇單個(gè)傳統(tǒng)程序進(jìn)行本地移植，并將它們駐留在獨(dú)立的Linux進(jìn)程中。在軟件顯示出其對(duì)其他子系統(tǒng)有著極小或者正常依賴性的情況下，這種技術(shù)最為適用。另一種明智的做法是，即使在部署仿真或虛擬化的時(shí)候也只將新的功能以本地代碼的形式來實(shí)現(xiàn)。

重要的一點(diǎn)是，要注意到這種選擇并不一定是相互排斥的。例如，設(shè)計(jì)團(tuán)隊(duì)可以每次選擇一個(gè)關(guān)鍵的傳統(tǒng)程序，逐步地將傳統(tǒng)應(yīng)用改造為本地Linux執(zhí)行，然后將它們放入單獨(dú)的Linux進(jìn)程中，而新功能只以本地代碼方式來實(shí)現(xiàn)。