嵌入式系統(tǒng)由于其工作環(huán)境、位置分布、與應(yīng)用系統(tǒng)的結(jié)合方式等方面的原因，在系統(tǒng)的升級、修改方面存在著相當(dāng)?shù)睦щy，且費(fèi)用高。目前大多數(shù)嵌入式系統(tǒng)內(nèi)核只能在一定程度上進(jìn)行靜態(tài)擴(kuò)展，這意味著修改某些內(nèi)核屬性值后要重新編譯內(nèi)核，對普通用戶而言難以實(shí)現(xiàn)。通信的發(fā)展使得嵌入式操作系統(tǒng)的動態(tài)擴(kuò)展成為可能，可以在遠(yuǎn)程控制的基礎(chǔ)上增加嵌入式系統(tǒng)的靈活性，延長嵌入式系統(tǒng)的壽命;同時(shí)，由于嵌入式Linux的應(yīng)用日益廣泛，研究嵌入式Linux的動態(tài)擴(kuò)展具有重要意義。

動態(tài)擴(kuò)展是指系統(tǒng)在運(yùn)行狀態(tài)下實(shí)現(xiàn)系統(tǒng)的升級和維護(hù)。動態(tài)擴(kuò)展技術(shù)目前被廣泛應(yīng)用在軟件系統(tǒng)開發(fā)的各個(gè)領(lǐng)域。組件、可擴(kuò)展的數(shù)據(jù)庫系統(tǒng)、主動網(wǎng)等多種技術(shù)都是動態(tài)擴(kuò)展技術(shù)在各個(gè)領(lǐng)域的具體體現(xiàn)。在嵌入式操作系統(tǒng)領(lǐng)域，動態(tài)擴(kuò)展技術(shù)研究的主要目標(biāo)是實(shí)現(xiàn)內(nèi)核抽象的擴(kuò)展。實(shí)現(xiàn)操作系統(tǒng)內(nèi)核抽象的動態(tài)擴(kuò)展能夠提高系統(tǒng)的靈活性、適應(yīng)性，使系統(tǒng)能夠根據(jù)應(yīng)用的需求，提供特定的服務(wù)。然而，由于嵌入式系統(tǒng)硬件資源有限，這對研究嵌入式Linux系統(tǒng)核心的動態(tài)擴(kuò)展性是一個(gè)極大的挑戰(zhàn)。

本文主要討論嵌入式Linux系統(tǒng)中內(nèi)核抽象的動態(tài)擴(kuò)展技術(shù)。

1、幾種主要的內(nèi)核動態(tài)擴(kuò)展技術(shù)的分析

當(dāng)前應(yīng)用于操作系統(tǒng)中的動態(tài)擴(kuò)展技術(shù)主要有四種:微內(nèi)核技術(shù)、可擴(kuò)展內(nèi)核技術(shù)、解釋器技術(shù)/JOS技術(shù)和內(nèi)核下載技術(shù)/LKM技術(shù)[1,2]。 這三種技術(shù)已經(jīng)在桌面操作系統(tǒng)的不同環(huán)境中得到了充分的應(yīng)用。嵌入式操作系統(tǒng)及其使用環(huán)境具有桌面操作系統(tǒng)所不同的特征，它在性能、地址空間、所需存儲空間和底層訪問頻率等方面的特征，使得我們在擴(kuò)展技術(shù)的選擇上需要加以權(quán)衡。

(1) 微內(nèi)核技術(shù)

在微內(nèi)核操作系統(tǒng)中，內(nèi)核中包括了一些基本內(nèi)核功能(如創(chuàng)建和刪除任務(wù)、任務(wù)調(diào)度、內(nèi)存管理和中斷處理等)，部分操作系統(tǒng)抽象和關(guān)鍵服務(wù)(如文件系統(tǒng)、網(wǎng)絡(luò)協(xié)議棧等)，都是在用戶空間運(yùn)行的。這大大減小了內(nèi)核的體積，同時(shí)也極大地方便了整個(gè)系統(tǒng)的升級、維護(hù)和移植。系統(tǒng)通過核心到用戶層向上調(diào)用服務(wù)的方法來為應(yīng)用程序提供服務(wù)。由于服務(wù)存在于用戶層，用戶可通過修改服務(wù)來獲得不同的行為，因而也稱為用戶層擴(kuò)展技術(shù)。由于所有的應(yīng)用程序都要利用操作系統(tǒng)提供的API或系統(tǒng)調(diào)用，完成內(nèi)存管理、進(jìn)程管理、I/O、設(shè)備管理等，因此通過在用戶空間監(jiān)視并截獲某個(gè)進(jìn)程的系統(tǒng)調(diào)用，然后將擴(kuò)展功能代碼插入系統(tǒng)調(diào)用中，就可以擴(kuò)展Linux操作系統(tǒng)功能。

與內(nèi)核空間功能擴(kuò)展相比，在用戶空間擴(kuò)展安全性更強(qiáng)，對Linux操作系統(tǒng)和應(yīng)用程序更加透明。用戶層擴(kuò)展技術(shù)的缺點(diǎn)在于，將服務(wù)提升到用戶層使程序運(yùn)行過程中核心態(tài)和用戶態(tài)之間的切換和自陷次數(shù)增加，導(dǎo)致系統(tǒng)負(fù)載增加，系統(tǒng)性能下降。另外，微內(nèi)核與傳統(tǒng)的嵌入式Linux內(nèi)核在結(jié)構(gòu)上是完全不同的。在嵌入式Linux中，如果采用該技術(shù)來增加系統(tǒng)的動態(tài)擴(kuò)展性能，需要對內(nèi)核結(jié)構(gòu)重新設(shè)計(jì)。

(2) 可擴(kuò)展內(nèi)核技術(shù)

可擴(kuò)展內(nèi)核技術(shù)允許用戶應(yīng)用程序向內(nèi)核植入(inject)代碼以擴(kuò)展其功能。由于被植入的代碼是在核心態(tài)運(yùn)行，從而避免了微內(nèi)核技術(shù)中的系統(tǒng)性能下降的問題。被植入的代碼是在核心態(tài)運(yùn)行，需要有一個(gè)實(shí)時(shí)檢查機(jī)制來驗(yàn)證代碼的安全性，保證被植入代碼不會導(dǎo)致系統(tǒng)的崩潰。程步奇等人使用軟件故障孤立技術(shù)來實(shí)現(xiàn)擴(kuò)展模塊的故障孤立，保證系統(tǒng)不受到擴(kuò)展模塊的破壞。 Bershad等人也使用軟件故障孤立技術(shù)來限制被植入代碼可訪問的內(nèi)存地址范圍。代碼安全性檢查無疑增加了系統(tǒng)的負(fù)擔(dān)，問題產(chǎn)生的根本原因是那些被植入的擴(kuò)展性代碼對核心來說是不可信任的。為了減輕系統(tǒng)的負(fù)擔(dān)，就需要假設(shè)被植入的代碼是安全的、可信任的。

(3) 解釋器技術(shù)/JOS技術(shù)

與文獻(xiàn)中提到的JOS(Java Operating System)技術(shù)相同，該技術(shù)允許開發(fā)者用Java語言編寫系統(tǒng)模塊，例如TCP/IP協(xié)議?；蛭募到y(tǒng)。將這些模塊編譯成類(class)文件，并在系統(tǒng)運(yùn)行時(shí)由JVM(Java Virtual Machine)動態(tài)地加載。Liao等人在1996年提出，將JVM插入到微內(nèi)核中，從而可以讓用戶編寫Java程序，以擴(kuò)展內(nèi)核功能。

解釋器技術(shù)是以解釋的方式來執(zhí)行程序代碼的，比較適合于交互式系統(tǒng);與編譯器相比，解釋器/JVM在移植時(shí)相對簡單;解釋器通過采用中間代碼表示的方法，當(dāng)代碼長度小于500 KB的時(shí)候，可執(zhí)行的中間代碼通常比編譯產(chǎn)生的二進(jìn)制代碼小，這一點(diǎn)很適合于存儲空間非常有限的嵌入式系統(tǒng);最后，Java代碼容易維護(hù)和編寫，可移植性好，可實(shí)現(xiàn)代碼重用。采用解釋器技術(shù)的缺點(diǎn)是，中間可執(zhí)行代碼的執(zhí)行速度慢。在嵌入式Linux系統(tǒng)中，內(nèi)核很大一部分由應(yīng)用所共享，甚至應(yīng)用程序本身就是內(nèi)核的一個(gè)線程，執(zhí)行頻率高，采用解釋器技術(shù)會大大降低系統(tǒng)的效率。有些Java平臺采用即時(shí)(Just in time)編譯技術(shù)來改進(jìn)代碼的執(zhí)行速度。該技術(shù)是利用空間來換取時(shí)間，因此很難在硬件資源非常有限的嵌入式系統(tǒng)上實(shí)現(xiàn)。此外，由于Java語言的類庫很大，在一定程度上也阻礙了其在資源有限的嵌入式系統(tǒng)中的發(fā)展。

(4) 內(nèi)核加載技術(shù)/LKM技術(shù)

許多桌面操作系統(tǒng)，例如Linux，提供LKM(Loadable Kernel Module)來動態(tài)擴(kuò)展它們的內(nèi)核。當(dāng)模塊(Module)安裝到內(nèi)核后就作為核心的一部分，不進(jìn)行實(shí)時(shí)安全檢測，全速運(yùn)行。在嵌入式Linux系統(tǒng)中，LKM的主要問題是：存儲模塊需要占用額外空間以及被加載模塊的安全性。模塊的安全問題可以通過軟件保護(hù)技術(shù)來解決。

Oikawa等人在1996年提出一種與LKM類似的動態(tài)核心模塊(DKMs)技術(shù)。與LKM一樣，DKMs以文件的形式存儲并能在系統(tǒng)運(yùn)行過程中動態(tài)地加載和卸載。DKMs由一個(gè)用戶層的DKM服務(wù)器來管理，并非由內(nèi)核來管理。當(dāng)核心需要某模塊時(shí)，由DKM服務(wù)器負(fù)責(zé)把相應(yīng)的DKM加載;當(dāng)核心的內(nèi)存資源緊缺時(shí)，由DKM服務(wù)器負(fù)責(zé)卸載一個(gè)沒有被使用的DKM。缺點(diǎn)是所有的DKM是存儲在本地系統(tǒng)上的，占用了大量寶貴的存儲空間。

與Oikawa的方法不同，Chang DaWei 等人于2003年提出了OperatingSystemPortal framework(OSP)的方法。該方法是將核心模塊存儲在一個(gè)資源充足的遠(yuǎn)程服務(wù)器上，并由服務(wù)器端工具OS Portal來管理所存儲的模塊，同時(shí)也負(fù)責(zé)處理客戶端(嵌入式系統(tǒng)內(nèi)核)發(fā)出的請求，按照請求動態(tài)的選擇并連接模塊，然后通過網(wǎng)絡(luò)傳到客戶端。由于模塊的管理和連接都在服務(wù)器端，所以對客戶端來說可以節(jié)省大量的資源空間。OS Portal的結(jié)構(gòu)如圖1所示。

圖1 OS Portal的結(jié)構(gòu)圖