日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

主流嵌入式Linux動態(tài)擴展技術比較分析( 二 )

云知道


與內(nèi)核空間功能擴展相比，在用戶空間擴展安全性更強，對Linux操作系統(tǒng)和應用程序更加透明 。用戶層擴展技術的缺點在于，將服務提升到用戶層使程序運行過程中核心態(tài)和用戶態(tài)之間的切換和自陷次數(shù)增加，導致系統(tǒng)負載增加，系統(tǒng)性能下降 。另外，微內(nèi)核與傳統(tǒng)的嵌入式Linux內(nèi)核在結構上是完全不同的 。在嵌入式Linux中，如果采用該技術來增加系統(tǒng)的動態(tài)擴展性能，需要對內(nèi)核結構重新設計[2] 。
（2） 可擴展內(nèi)核技術
可擴展內(nèi)核技術允許用戶應用程序向內(nèi)核植入（inject）代碼以擴展其功能 。由于被植入的代碼是在核心態(tài)運行，從而避免了微內(nèi)核技術中的系統(tǒng)性能下降的問題 。被植入的代碼是在核心態(tài)運行，需要有一個實時檢查機制來驗證代碼的安全性，保證被植入代碼不會導致系統(tǒng)的崩潰 。程步奇等人[1]使用軟件故障孤立技術來實現(xiàn)擴展模塊的故障孤立，保證系統(tǒng)不受到擴展模塊的破壞 。Bershad等人[3]也使用軟件故障孤立技術來限制被植入代碼可訪問的內(nèi)存地址范圍 。代碼安全性檢查無疑增加了系統(tǒng)的負擔，問題產(chǎn)生的根本原因是那些被植入的擴展性代碼對核心來說是不可信任的 。為了減輕系統(tǒng)的負擔，就需要假設被植入的代碼是安全的、可信任的 。
（3） 解釋器技術/JOS技術
與文獻[2]中提到的JOS（Java Operating System）技術相同，該技術允許開發(fā)者用Java語言編寫系統(tǒng)模塊，例如TCP/IP協(xié)議?；蛭募到y(tǒng) 。將這些模塊編譯成類（class）文件，并在系統(tǒng)運行時由JVM（Java Virtual Machine）動態(tài)地加載 。Liao等人[4]在1996年提出，將JVM插入到微內(nèi)核中，從而可以讓用戶編寫Java程序，以擴展內(nèi)核功能 。
解釋器技術是以解釋的方式來執(zhí)行程序代碼的，比較適合于交互式系統(tǒng)；與編譯器相比，解釋器/JVM在移植時相對簡單；解釋器通過采用中間代碼表示的方法，當代碼長度小于500 KB的時候，可執(zhí)行的中間代碼通常比編譯產(chǎn)生的二進制代碼小，這一點很適合于存儲空間非常有限的嵌入式系統(tǒng)；最后，Java代碼容易維護和編寫，可移植性好，可實現(xiàn)代碼重用 。采用解釋器技術的缺點是，中間可執(zhí)行代碼的執(zhí)行速度慢 。在嵌入式Linux系統(tǒng)中，內(nèi)核很大一部分由應用所共享，甚至應用程序本身就是內(nèi)核的一個線程，執(zhí)行頻率高，采用解釋器技術會大大降低系統(tǒng)的效率 。有些Java平臺采用即時(Justintime)編譯技術來改進代碼的執(zhí)行速度[2] 。該技術是利用空間來換取時間，因此很難在硬件資源非常有限的嵌入式系統(tǒng)上實現(xiàn) 。此外，由于Java語言的類庫很大，在一定程度上也阻礙了其在資源有限的嵌入式系統(tǒng)中的發(fā)展 。
（4） 內(nèi)核加載技術/LKM技術
許多桌面操作系統(tǒng)，例如Linux，提供LKM（Loadable Kernel Module）來動態(tài)擴展它們的內(nèi)核 。當模塊(Module)安裝到內(nèi)核后就作為核心的一部分，不進行實時安全檢測，全速運行 。在嵌入式Linux系統(tǒng)中，LKM的主要問題是：存儲模塊需要占用額外空間以及被加載模塊的安全性 。模塊的安全問題可以通過軟件保護技術來解決[1] 。
Oikawa等人在1996年提出一種與LKM類似的動態(tài)核心模塊（DKMs）技術[5] 。與LKM一樣，DKMs以文件的形式存儲并能在系統(tǒng)運行過程中動態(tài)地加載和卸載 。DKMs由一個用戶層的DKM服務器來管理，并非由內(nèi)核來管理 。當核心需要某模塊時，由DKM服務器負責把相應的DKM加載；當核心的內(nèi)存資源緊缺時，由DKM服務器負責卸載一個沒有被使用的DKM 。缺點是所有的DKM是存儲在本地系統(tǒng)上的，占用了大量寶貴的存儲空間 。
與Oikawa的方法不同，Chang DaWei 等人于2003年提出了OperatingSystemPortal framework（OSP）的方法[2] 。該方法是將核心模塊存儲在一個資源充足的遠程服務器上，并由服務器端工具OS Portal來管理所存儲的模塊，同時也負責處理客戶端（嵌入式系統(tǒng)內(nèi)核）發(fā)出的請求，按照請求動態(tài)的選擇并連接模塊，然后通過網(wǎng)絡傳到客戶端 。由于模塊的管理和連接都在服務器端，所以對客戶端來說可以節(jié)省大量的資源空間 。OS Portal的結構如圖1所示 。

推薦閱讀