從RTOS到Linux的應用移植

引言

　　在過去幾年中，Linux成功地取代了一些最主要的傳統RTOS（實時操作系統）平臺，成為了各種各樣的嵌入式設備和應用中首選的嵌入式操作系統。盡管一度曾被認為是不重要的平臺，但今天嵌入式Linux已經成為主流，廣泛應用于消費電子、手持和無線設備、數據聯網以及電信設備等領域。Google公司在2007年11月發布的Android手機操作系統正是基于Linux內核的操作系統，使得Linux在數字移動電話業取得跨越式發展。

　　筆者在從臺式頻譜儀到手持式頻譜儀的項目研發中實現了RTOS到Linux的應用移植。本文介紹了整體的設計思路和一些關鍵問題的實現細節。

1　RTOS到Linux的移植分析

　　幾乎所有的RTOS都有一個簡單的編程模型，它由多線程的執行（通常稱為任務）構成，包含在單一的地址空間中。在RTOS中，單一主程序下多任務同時運行，具有很高的實時響應能力。

　　過去大多數嵌入式處理器沒有內存管理單元，因此RTOS是單地址空間模式，即它們的物理地址和邏輯地址都是一樣的。然而目前大多數的中高端處理器配備了MMU（內存管理單元）。在MMU的支持下，Linux采用虛擬內存管理，將地址空間分為物理地址和虛擬地址，因此系統操作硬件時要進行地址映射。

　　根據兩類系統的體系結構，RTOS移植到Linux的基本框架如圖1所示。

圖1　RTOS移植到Linux的基本框架
　　由圖1可看出，移植的基本步驟為：
① RTOS的全部應用代碼移植到一個Linux單進程；
② RTOS的任務轉換成Linux線程；
③ RTOS的物理地址空間映射到Linux的虛擬地址空間。
　　在具體的應用移植過程中，還應考慮在Linux系統下解決上層應用實時響應底層硬件中斷，應用層與內核層的異步通信、數據交換，以及多進程、多線程的設計等問題。

2　RTOS到Linux的移植實現

2.1　地址映射

　　多數RTOS是針對較早的無MMU的CPU而設計，所以忽略了內存管理部分，即使當MMU問世后也是這樣——不區分物理地址和虛擬地址。大多數 RTOS還全部運行在特權模式，雖然表面上看來是增強了性能，但全部的RTOS應用和系統代碼都能夠訪問整個地址空間、內存映射過的設備以及其他I/O操作。這樣，即使存在差別，也很難把RTOS應用程序代碼同驅動程序代碼區分開來。

　　對于當前包含MMU的處理器而言，Linux系統提供了復雜的存儲管理系統，使得進程所能訪問的虛擬內存達到4 GB。

　　在Linux系統中，進程的4 GB虛擬內存空間[1]被分為兩個部分——用戶空間與內核空間。用戶地址空間一般分布為0~3 GB，剩下的3~4 GB為內核空間。上層應用程序通常情況下只能訪問用戶空間的虛擬地址，不能訪問內核空間的虛擬地址。應用程序只有通過系統調用（代表應用程序進程在內核態執行）等方式才可以訪問到內核空間。

　　而外設I/O資源是不在Linux內核虛擬地址空間中的（如SRAM或硬件接口寄存器等），若需要訪問某外設I/O資源，必須先將其物理地址映射到內核虛擬地址空間中，然后才能在內核空間中訪問它。

　　Linux內核訪問外設I/O資源的方式有兩種：靜態映射（map_desc）和動態映射（ioremap）。對于靜態映射，內核在系統啟動時通過map_desc結構體靜態創建I/O資源到內核地址空間的線性映射表(即page table)，這種映射表是一一映射的關系。開發人員可以自定義該I/O內存資源映射后的虛擬地址。創建好了靜態映射表，在內核或驅動中訪問該I/O資源時則無需再進行ioremap映射，可以直接通過映射后的I/O虛擬地址去訪問它。

　　這里主要討論更常用的動態映射方式。動態映射方式是直接通過內核提供的ioremap函數動態創建一段外設I/O內存資源到內核虛擬地址的映射表，從而可以在內核空間中訪問這段I/O資源。代碼如下：

#define bcon*(volatile unsigned long*)ioremap(0x56000010,4)//動態映射
上述代碼的含義是將0x56000010開始的4字節的物理地址映射到內核的虛擬地址中，返回的起始虛擬地址值賦給bcon宏定義。對宏定義的操作即對物理地址的操作。
ioremap宏定義在asm/io.h內：
#define ioremap(addr, size)__ioremap(addr, size, 0)
__ioremap函數原型為(arm/mm/ioremap.c)：
void __iomem * __ioremap(unsigned long phys_addr, size_t size, unsigned long flags);

其中，phys_addr為要映射的起始的I/O地址；size為要映射的空間的大小；flags為要映射的I/O空間和權限有關的標志。

該函數返回映射后的內核虛擬地址(3G~4G)，接著便可以通過讀寫該返回的內核虛擬地址去訪問這段I/O內存資源。所以，在移植的開始就應該在頭文件中完成設備物理地址的映射，方便后續的開發。

2.2　多進程多線程設計

　　大多數的RTOS內核都提供多任務的管理機制。任務是一個具有獨立功能的無限循環的程序段的一次運行活動，是實時內核調度的單位。多任務在內核的管理、調度下并行執行，而且任務都是無限循環的，持續實現其功能。多任務實時操作系統示意圖如圖2所示。

圖2　多任務實時操作系統示意圖

　　在比較兩類嵌入式系統的架構之后，移植的過程中很自然地將RTOS的多任務轉換成Linux的多進程、多線程。

　　進程是Linux系統資源管理的最小單位，是程序的一次執行過程，是Linux資源分配的基本單位。線程是在進程內部，它是比進程更小的能獨立運行的基本單位，是Linux系統分配CPU時間的基本單位。線程比進程更節約資源，節約時間。在具體的移植過程中，采用主進程等待上層連接，主進程下多線程并行執行。同時采用互斥信號量解決線程訪問資源的同步問題。

　　Linux主進程程序流程如圖3所示。

圖3　Linux主進程程序流程

2.3　應用層與內核層通信

　　由于RTOS的單地址空間模式使得其內核層與應用層沒有區別，所以在數據交換、實時響應等方面有一定的優勢。而Linux系統提供了嚴格的內存管理機制，能保證系統更加穩定地運行。但同時增加了應用層與內核層，以及應用層與底層硬件通信的難度。本節內容主要解決應用層與內核層的信號通知、數據交換這兩個關鍵問題。

2.3.1　　異步信號通知機制

　　RTOS是對外來事件在限定時間內能作出反應的系統。在RTOS中，時間是一種重要的系統資源，對外部事件的響應和任務的執行都必須在限定的時間內完成。在多機系統中，還必須在限定的時間內完成消息的發送和接收。在RTOS中，輸出結果的正確性不僅取決于計算所形成的邏輯結束，還要取決于結果產生的時間。

　　Linux在發行最初并未定義為一款實時操作系統。隨著Linux內核的不斷發展，如今穩定的Linux2.6內核已經具備了很好的實時響應能力。本文的研究項目中，需要上層應用對底層硬件進行實時響應。RTOS并沒有嚴格區分上層應用和內核，其多任務并行執行，能很好達地到實時響應的目的。而移植到Linux系統中，上層應用和底層硬件并不能直接通信，要經過內核驅動層。雖然可以采用查詢方式實現，但是實時性不高，同時浪費CPU資源。本文采用異步信號通知機制，實現了上層應用對底層硬件的實時響應。

　　異步通知[2]的意思是：一旦設備就緒，則主動通知應用程序，這樣應用程序根本不需要查詢設備狀態，這一點非常類似于硬件上“中斷”的概念，比較準確的稱謂是“信號驅動的異步I/O”。信號是在軟件層次上對中斷機制的一種模擬，在原理上進程收到信號與處理器收到中斷請求是一樣的。信號是異步的，一個進程不必通過任何操作來等待信號的到達，原理如圖4所示。

圖4　異步信號通知示意圖

　　在具體的程序設計過程中，上層應用為了能處理一個設備釋放的信號，要完成3項工作：

① 通過F_SETOWN控制命令設置設備文件的擁有者為本進程，這樣從設備驅動發送的信號才能被本進程接收到。

② 通過F_SETFL控制命令設置設備文件支持FASYNC，即異步通知模式。

③ 通過signal()函數連接信號和信號處理函數。

　　在上層應用設置捕獲信號后，還應在設備驅動端設置信號源，在合適的時機讓設備驅動釋放信號，其相關代碼也包括3部分：

① 支持F_SETOWN命令，能在這個控制命令處理中設置filp﹥f_owner為對應進程ID。

② 支持F_SETFL命令的處理，每當FASYNC標志改變時，驅動程序中的fasync()函數將得以執行。

③ 在設備資源可獲得時，調用kill_fasync()函數釋放相應的信號給上層應用。

　　上述3項工作和上層應用的3項工作是一一對應的。按其步驟設計程序，即可實現上層應用通過內核層對底層硬件的及時響應。

2.3.2　proc方式數據共享

　　除了前面提到的信號、套接字、信號量外，Linux還有管道、報文隊列、共享內存等進程間通信機制。在移植過程中，由于Linux系統分為應用層和內核層，所以不僅要進行進程間的通信，還要實現應用層與內核層的數據交換。以上的機制多是基于進程間通信，并不能很好地滿足要求。在這里采用proc文件系統的方法在Linux內核層和應用層之間進行數據交換。

　　在Linux系統中，proc文件系統是一個虛擬文件系統，用于內核向用戶導出信息。利用proc文件系統通信是比較方便的一種應用層與內核層的數據交換方式，可以將對虛擬文件的讀寫作為與內核中實體進行通信的一種手段。內核的很多數據都是通過這種方式出口給上層應用的，內核的很多參數也是通過這種方式來讓上層方便設置的。實際上，很多應用嚴重地依賴于proc文件系統，因此它幾乎是必不可少的組件。

　　對于proc文件系統的使用，有如下的接口函數：
struct proc_dir_entry *create_proc_entry(const char *name,mode_t mode,struct proc_dir_entry *parent);
typedef int (read_proc_t) (char *page, char **start, off_t off, int count, int *eof, void *data);
typedef int (write_proc_t) (struct file *file, const char __user *buffer,unsigned long count, void *data);
void remove_proc_entry(const char *name, struct proc_dir_entry *parent);

　　以上函數作用分別是創建proc文件系統節點、讀寫proc節點，以及刪除proc節點。具體移植的proc程序流程如圖5所示。

圖5　proc程序流程

2.4　調試運行

　　根據移植的基本框架，在解決了以上幾個關鍵問題后，基本完成了整個移植的過程。最后要做的就是程序的調試。對于程序語法的調試，在編譯的過程中解決。根據Linux平臺下的編譯器gcc的提示信息，修改出現的語法類錯誤。在保證了應用程序文件的成功編譯后，采用gdb調試軟件進行功能的調試，同時結合打印函數printf跟蹤調試。在程序適當的位置加入printf打印信息，例如根據創建proc節點的返回值來打印成功或者失敗的信息，可以很直觀地了解程序的運行情況，是很有效的調試方法。通過兩種手段的結合，最后完成應用程序的調試。結果表明，能夠在Linux系統下正常運行。

結語

　　現在越來越多的開發團隊正在放棄第一代實時操作系統，選擇更穩定的開放式的嵌入式Linux平臺。參考本文概括的應用程序的移植步驟以及相關的關鍵技術，開發人員可以通過更少的時間，將以前的RTOS的代碼成功地移植到一個現代化的Linux平臺上來。

linux操作系統文章專題:linux操作系統詳解（linux不再難懂）