2.3 多內核嵌入式操作系統和虛擬機
多內核嵌入式操作系統指有多個內核的嵌入式操作系統。這些內核同時在硬件平臺上面運行，共同管理著系統中的軟件和硬件資源。多內核的嵌入式操作系統按照其組織結構可以分為兩類：一類叫做一體化結構的多內核嵌入式操作系統，另一類叫做基于虛擬機的多內核嵌入式操作系統。
2.3.1 為什么要引入多內核嵌入式操作系統和虛擬機
實際應用有時會對嵌入式操作系統提出一些多元化的需求（如有非常強的實時性能；能在資源極為有限的硬件平臺上運行；可以運行基于Linux系統開發的應用軟件），使得現有的任何一種嵌入式操作系統都不能直接滿足這些需求。解決這個問題的方法通常有兩種：一種是新開發一種功能更強的嵌入式操作系統；另一種是將兩個甚至多個嵌入式操作系統組合在一起，通過相互彌補不足的方式滿足應用需求。第一種方法看似直截了當，但受很多因素的制約，實際上往往行不通。例如，使用者對現有的操作系統已經非常習慣，難以舍棄；現有操作系統的研發者出于商業利益的考慮，暫時不愿意開發新的系統；開發新操作系統所需的某種關鍵技術未得到解決等。所以在很多情況下還是選擇第二種解決方法。這就是為什么要引入多內核嵌入式操作系統的原因。
當多個嵌入式操作系統在同一個硬件平臺上運行時，必然出現如何協調各操作系統之間關系的問題。這有兩種解決方法，一種是由各操作系統自己解決相互協調的問題，另一種是由一個位于硬件之上，操作系統之下的獨立功能模塊來解決相互協調的問題。這個位于硬件之上，操作系統之下的獨立功能模塊就是所謂的虛擬機。
對嵌入式操作系統的多元化需求，適合采用多內核嵌入式操作系統予以解決，下面來看兩個比較典型的實例。
第一個實例來自于智能手機。智能手機相當于普通手機與PDA的融合。在它的CPU上面既要運行通信處理軟件，也要運行普通PDA軟件（如個人信息管理軟件）。因此對智能手機上的操作系統提出了兩個不同的需求。從通信處理的角度出發，要求操作系統有很強的實時處理能力。從便于PDA應用軟件開發和移植的角度出發，要求操作系統應當與Linux甚至更多的常用嵌入式操作系統兼容。這兩個需求是相互矛盾的，很難在基于一個嵌入式操作系統的前提下解決，但采用一個雙內核的嵌入式操作系統就能夠比較好地解決這一問題。在這個雙內核嵌入式操作系統中，一個內核有很強的實時性能，可用于支持通信方面的實時任務。另一個則是Linux的內核，可以支持非實時的應用任務，大量符合POSIX標準的應用程序幾乎不加修改地就可以在這個內核上運行。
第二個實例來自于無線傳感網。在無線傳感網中有微傳感器和網關兩類網絡結點。微傳感器的資源極為有限，因此運行于微傳感器上的嵌入式操作系統所占內存應當非常小，對微處理器的要求應當非常低。當然，需要這種嵌入式操作系統提供的功能也不是很復雜，都是一些支持任務運行所必需的功能。相對微傳感器而言，網關結點的資源豐富得多。它的主要功能是將由微傳感器所組成的網絡接入其他網絡，如GSM的無線蜂窩網。網關結點通常還可以提供其他一些功能，如網絡管理功能，甚至充當一般的微傳感器。因此網關上的操作系統要比微傳感器上的操作系統有更強的功能。對于微傳感器和網關之間的這種差別，一種解決辦法是在微傳感器和網關上分別采用不同的嵌入式操作系統，但這顯然不是一個好的解決方案，對無線傳感網應用軟件的開發和移植都有不良的影響。還有一種方案是在微傳感器上采用一種功能精簡的嵌入式操作系統，而在網關上采用一個雙內核的嵌入式操作系統，其中一個內核與運行在微傳感器上的操作系統內核相同，另一個操作系統內核則功能較強，可以支持復雜應用。
2.3.2 一體化結構多內核嵌入式操作系統原理與組成
一體化結構的多內核嵌入式操作系統由同在一個硬件平臺上運行的內核自己解決相互協調的問題。理論上，在一個硬件平臺上雖然可以同時運行多個嵌入式操作系統內核，但實際中使用的一般都是雙內核系統。這種雙內核嵌入式操作系統的典型用途是彌補嵌入式Linux操作系統在實時性方面的缺失。RTLinux和RTAI是這種雙內核操作系統的典型代表。它們都是把Linux內核與一個實時內核合并在了一起。
如圖2.38所示，這種雙內核操作系統的原理是將Linux內核（也可以是其他某種實時性較低的操作系統內核）作為實時內核的一個低優先級任務。系統中的任務被分為了實時任務和非實時任務兩類，實時內核調度和處理實時任務，Linux內核調度和處理非實時任務。由于Linux內核是實時內核的一個優先級最低的任務，所以只有當系統中沒有實時任務時，Linux內核才可能被運行，并開始處理系統中的非實時任務，因此實時任務總是能夠優先得到運行。通過這種簡單的方法，雙內核操作系統在保證實時性的前提下實現了兩個操作系統內核的融合。
圖2.38 一體化結構的雙內核嵌入式操作系統的組成
當有中斷請求到來時，由虛擬中斷管理模塊負責接收，并按先實時內核后Linux內核的次序，將中斷請求傳遞給兩個操作系統內核，使兩個操作系統內核都有機會按照自己方式對中斷進行處理。（RTLinux中沒有虛擬中斷管理模塊，它將該模塊承擔的功能合并到了實時內核中。所以在RTLinux中，當有中斷請求到來時，是由實時內核負責接收，并對其進行處理，然后再傳遞給Linux內核。）
一體化結構的多內核嵌入式操作系統有以下5個特點。
① 在保留原有操作系統內核構架的前提下，實現多個內核的有機融合，使它們可以相互配合工作，發揮各自的優勢，向應用軟件開發者提供一個功能更強的操作系統。
② 操作系統內核間的協調、通信等問題由各個內核自己解決。
③ 系統采用主次的結構，多個操作系統內核的地位不平等。系統一般以一個操作系統內核為主，由它負責一些管理性的工作，如操作系統內核間的通信。
④ 系統的層次關系及其各操作系統內核間的接口不清晰，因此在采用一體化結構將多個嵌入式操作系統組合在一起形成一個多內核嵌入式操作系統時，需要根據具體情況對原有的操作系統內核做比較多的修改和調整，這給系統的維護帶來了一定麻煩。有時這種修改和調整所產生的變化甚至會影響到應用軟件的開發。
⑤ 實時任務在核心態運行，給操作系統的穩定性帶來了一定隱患。多內核操作系統將非實時內核（如嵌入式Linux的內核）作為實時操作系統內核的一個低優先級任務。這種做法雖然簡化了系統設計，但是由于非實時內核必須在核心態運行，所以迫使所有的實時任務也要在核心態運行。實時任務作為一種應用程序，出錯可能性遠高于操作系統代碼，因此降低了系統的穩定性。
2.3.3 虛擬機的原理與組成
虛擬機是在一體化結構多內核嵌入式操作系統的基礎上發展起來的一種技術。一體化結構的多內核嵌入式操作系統存在著內核間的接口不清晰、系統的穩定性存在隱患等問題。虛擬機的引入在很大程度上解決了這些問題。
如圖2.39所示，虛擬機是一個直接位于硬件之上的底層軟件。在虛擬機之上可以運行多個嵌入式操作系統內核（雖然在實際中使用較多的也是雙內核的系統）。這些內核和虛擬機一起共同組成了一個基于虛擬機的多內核嵌入式操作系統。虛擬機提供支持在同一個硬件平臺上運行多個操作系統內核所需的一系列功能模塊。主要包括虛擬中斷管理模塊、虛擬管道模塊、內存管理模塊3個功能模塊。除此之外，原來硬件抽象層所具有的功能也應被包括在虛擬機之中。
圖2.39 基于虛擬機的多內核嵌入式操作系統的組成
1. 虛擬中斷管理模塊
虛擬中斷管理模塊對來自計算機硬件的中斷請求進行處理。它提供了保障多個操作系統內核同時在一個硬件平臺之上運行所需要的最基本功能，使多個操作系統內核可以獨立運行、互不影響。如圖2.40所示，虛擬中斷管理模塊自底向上可以劃分硬件監控層、中斷分發層、內核服務層3個層次。硬件監控層監聽來自硬件的中斷請求。中斷分發層按照優先級將來自硬件的中斷請求發送給運行在虛擬機之上的操作系統內核，并回調操作系統注冊的中斷服務程序。內核服務層負責中斷服務程序的注冊、注銷和開中斷、關中斷等項工作。
圖2.40 虛擬中斷管理模塊的結構
如圖2.41所示，運行在虛擬機上的操作系統內核有不同的優先級，這個優先級決定了來自硬件的中斷請求傳給各個操作系統內核的次序。優先級最高的操作系統內核總是最先接收到來自硬件的中斷請求，該請求然后依次被傳遞給運行在虛擬機上的其他操作系統內核。一個操作系統內核可以選擇是否接收和處理某種中斷請求。有一些中斷請求，如時鐘中斷，所有的操作系統內核必須接收和處理，但某些中斷請求可能僅與某個操作系統有關系，所以其他的操作系統內核就不必對其進行接收和處理，這樣可以減少許多不必要的工作。一個操作系統內核如果接收和處理某種中斷請求，虛擬中斷管理模塊就會調用這個操作系統的中斷服務程序，并在處理結束之后，將該中斷請求向下傳遞，直至到達優先級最低的操作系統內核。
圖2.41 中斷請求按優先級在各操作系統內核間傳遞
2. 虛擬管道管理模塊
虛擬管道管理模塊用于解決多個操作系統內核間的通信問題。它所支持的功能主要是供運行在虛擬機上的嵌入式操作系統內核使用，但在某些時候也可以被應用任務所使用，以便和其他操作系統中的任務相互通信。一體化結構的多內核嵌入式操作系統中一般有某個操作系統內核起主導作用，不同內核之間的通信由它來負責，因此不需要用一個專門的功能模塊來解決多個內核間的通信問題。
虛擬管道管理模塊的API接口目前尚未標準化，可以采用很多方式。Socket接口和專用設備是兩種可行的方式，它們都比較好地解決了與現有編程習慣的兼容問題。Socket接口方式是標準Socket接口的擴充。標準Socket接口規定：在調用Socket函數準備建立通信連接的時候，須給出3個參數，其中一個參數用于指明通信協議。為了支持虛擬管道，可在Socket支持的原有通信協議之外再擴充一種與虛擬管道相對應的協議，使用這種協議建立通信連接就可以通過虛擬管道與其他操作系統相通信。專用設備方式的原理是用一種設備代表虛擬管道。對這種設備可以像其他設備一樣進行打開、關閉、讀、寫等各種操作。這樣，使用虛擬管道進行通信的雙方只要一方向該設備寫入數據，另一方從該設備讀出數據就可以達到相互通信的目的。
3. 內存管理模塊
內存管理模塊用于處理在一個硬件平臺之上同時運行多個操作系統內核時在內存管理方面所產生的問題。當多個操作系統內核運行于一個硬件平臺上時，必須妥善地解決內存管理問題，否則就不可避免地發生混亂。但解決這個問題并不總是依靠虛擬機中的內存管理模塊。按照是否需要由內存管理模塊參與解決內存管理，可以把解決內存管理問題的方法分為兩類：一類是由內存管理模塊解決或幫助解決內存管理問題，另一類則完全是由各操作系統內核自己解決內存管理問題，不需要依靠內存管理模塊。
在采用第一類方法解決內存使用問題時，并不是由內存管理模塊完全接管內存的管理工作。它所起的作用只是讓各操作系統內核中的內存管理功能能夠互不干擾地正常工作。例如，若一個多內核操作系統采取的內存管理方案是把物理內存按照一定的比例分配給各個操作系統，由各操作系統分別管理分配給自己的物理內存。那么在進行操作系統內核切換時就需要由內存管理模塊對MMU中的頁表進行刷新或進行局部的修改。
在采用第二類方法解決內存的管理問題時，內存管理模塊的功能完全退化，虛擬機中的內存管理模塊實際上已不存在。這類方法的共同特點是解決內存管理問題的措施都與各操作系統所采用的具體內存管理技術密切相關。Hopen雙內核操作系統采用的就是這類方法。下面來看該操作系統的內存管理方案。
Hopen雙內核操作系統是Hopen操作系統系列產品中的一個成員。它的兩個內核分別是Hopen-RT操作系統內核和嵌入式Linux操作系統內核。Hopen-RT是一個實時性很強的嵌入式操作系統，它可以彌補嵌入式Linux在實時性方面的不足。
如圖2.42所示，在32位的計算機中有4GB的虛擬地址空間。嵌入式Linux將這4GB的地址空間分成了兩部分。低地址的3GB（從虛擬地址0X0至0XBFFFFFFF）作為各任務的用戶空間。高地址的1GB（從虛擬地址0XC0000000～0XFFFFFFFF）作為操作系統內核所用的空間，即系統空間。當一個任務通過系統調用進入內核之后，也在系統空間中運行。
圖2.42 嵌入式Linux操作系統虛擬地址空間的劃分
如圖2.43所示，為了解決雙內核共同運行時的內存管理問題，Hopen雙內核操作系統將Linux任務的用戶空間壓縮到了0～2GB（從虛擬地址0X0～0X7FFFFFFF）。減少1GB的用戶空間對任何Linux任務都不會產生不良影響。節省出來的1GB地址空間沒有給Linux內核使用，而是給了Hopen-RT的實時任務。Hopen-RT為每個實時任務提供32MB的用戶空間，并且最多可支持20個實時任務同時運行。這樣一共需要640MB的地址空間。剩余的384MB的地址空間留給了共享庫。在Linux操作系統中1GB的地址空間雖然不歸Linux內核使用，但被映射到系統空間中。在Hopen-RT操作系統中則是把任務的用戶空間映射到這1GB地址空間中某個32MB的區間內。由于系統空間中的內容常駐內存，不會被換進換出，所以大大提高了Hopen-RT實時任務的實時性。
圖2.43 Hopen雙內核操作系統虛擬地址空間的劃分
4. 硬件抽象層模塊
硬件抽象層模塊之中封裝了一般意義上的硬件抽象層應當提供的功能。這些功能的作用是隱藏硬件平臺的一些細節，增強操作系統的硬件無關性。