基于靈活內核的構件化驅動程序

摘 要: 本文探討了整體內核和微內核兩種操作系統體系結構的優缺點，并基于嵌入式操作系統—和欣的靈活內核技術提出構件化驅動程序設計，主旨是使用 ezCOM 構件技術封裝驅動程序，實現多種模式下調用驅動程序，從而部分有效地解決微內核與整體內核系統之間的矛盾。

    關鍵詞 ： 構件化驅動 , 構件技術 , 操作系統體系結構

    1 操作系統體系結構的爭論

    一般而言操作系統提供兩種功能 [2] ：⒈有系統地在互相競爭的進程之間分配計算機資源；⒉作為計算機的擴展，提供功能強大的編程環境和應用環境。由于計算機硬件的快速發展和用戶要求的提高，操作系統的復雜性與日俱增，系統的體系結構對系統性能的影響也越來越明顯。

    關于操作系統體系結構的討論一直沒有停息過，大多數的操作系統采用兩種體系結構之一：一個是整體內核 (Monolithic kernel or Macro-kernel) 操作系統，另一個是微內核 (Micro-kernel) 操作系統。

    1.1 整體內核操作系統

    整體內核操作系統有如下特征：操作系統功能定義模塊，系統服務和驅動程序都在內核空間，分別定義成不同的功能模塊；任何模塊可以遵循特定的接口規范來調用其它模塊；所有模塊必須連接在一起，形成一個可執行文件，使用時整個文件都應完整裝載到計算機的內存中；所有模塊都運行于超級用戶的模式下，可直接取用計算機的硬件資源；應用程序若要取用這種資源，如掃描儀，它需要執行系統調用，請求一個系統模塊幫它獲取相應的資源。這里的系統調用實際上是這樣做的：首先將計算機切換到超級用戶模式，然后進入操作系統的某個模塊。傳統的操作系統都是整體內核的，例如 Microsoft DOS ， Linux ， Unix ， Windows95 等。

    1.2 微內核操作系統 [5]

    微內核是從功能上說，它由操作系統最基礎的抽象模塊構成的，整體內核系統中包含的許多系統服務以及驅動程序都被放在了核外，核內一般只包括進程管理、 I/O 處理、內存管理、進程間通訊等。 MACH 是非常典型的微內核系統， MACH 的核內包括的抽象功能模塊有任務，線程，內存對象，消息和端口，它們提供了管理和處理虛擬內存，調度和進程間通信的機制。模塊化的特點使 MACH 擁有可裁剪性，可擴展性，可移植性等良好特性，而這些特性是整體內核操作系統很難具備的。除了 MACH 之外，微內核操作系統還有 QNX 、 MINIX 、 CHORUS 、 AMORBA 等。

    2 微內核系統和整體內核系統的比較

    簡而言之，微內核將操作系統的許多服務移到了用戶空間，而傳統的操作系統通常是將其放在核內的，這對系統的性能產生了顯著的影響。微內核系統和整體內核系統比較具有以下優點：

    魯棒性 (Robustness) 微內核系統將許多系統服務放到用戶空間，由于這些服務程序是運行在完全獨立的內存空間中 ( 當然這里不包括內核級的服務程序 ) ，程序本身存在的 BUG 和不可預知的錯誤就不會那么容易導致內核的崩潰。

    安全性 (Security) 微內核系統的許多模塊獨立地運行于核外，因此可以以模塊為單位把安全問題分解，使得系統服務程序嚴格按照安全要求運行，而不是“隨心所欲”。

    可配置性 (Configurability) 一般微內核系統中的服務程序可以在整個系統不重新啟動的情況下被更換，這一點對于整體內核的操作系統是難以實現的。

    易于編程 內核中的代碼通常需要使用特殊的內存分配和輸入輸出等例行程序，用戶態的代碼要比核態的代碼容易編寫，它無須去考慮內核特定的一些限制。

    降低內存的固定使用量 分配給內核的內存 ( 代碼和數據 ) 一般地說必須駐留在內存中，不允許被交換出內存。被移到用戶空間的核態代碼越多，內核常駐內存的程序量就越少，移到核外的系統服務程序只有在被用到時才會裝入內存。

    實時性能 系統運行于核態時，為了防止打斷一些臨界處理，會暫時禁止中斷。內核中的代碼越少，禁止中斷的機會就越少。

    可擴展性 (extensibility) 在微內核系統中添加系統模塊就像編寫用戶程序一樣簡單，只要它遵從系統提供的設計接口，而整體內核系統添加模塊首先需要你對操作系統內部工作機制有一定的了解，在編寫好模塊程序之后，還需要重新編譯內核，以便把添加的模塊連接到內核中去。

    前面提到的都是微內核系統的進步之處，當然微內核系統也并非完美無缺，微內核系統和整體內核系統相比也有不足之處：

    微內核規模并不小 大多數微內核系統的內核規模并不小，盡管“微內核”的名字讓人產生這種錯覺。 QNX 操作系統是一個例外，如果內核做得很大相應系統的 RAM 使用量就會有所增長；

    效率的缺失 將許多系統的服務置于核外，就需要給這些服務程序之間提供相應形式化的消息傳遞機制 (Message Passing Interface or Remote Procedure Call) 。在整體內核操作系統中，不同的系統服務模塊總是通過系統內存來互相傳遞信息，而微內核結構中就只有用正式的機制，這樣會導致性能的降低，在 Linus 和 Tanenbaum 的有名的那場關于微內核與整體內核的爭論 [3] 了這個問題；

    出現的新問題 系統的部件之間會出現一些新類型的死鎖或其他的條件錯誤，而這些在整體內核的系統中是不會出現的。

    3 研究現狀

    由于操作系統體系結構爭論的廣泛性，大多數從事操作系統研究和實現的學者們都意識到無論整體內核還是微內核結構都不是盡善盡美的。這場爭論帶來的另一積極后果是，雙方的支持者都試圖有所改變，以彌補自身系統存在的缺陷。

    一直以來，微內核結構的支持者對整體內核系統的可移植性都存在質疑，整體內核的操作系統也盡量使其內核模塊化，減少模塊之間的依賴性，這樣就提高了系統的可維護性和系統的可移植性。

    整體內核的支持者對微內核結構最有力的反擊往往是效率問題，的確由于微內核系統將很多系統服務放在核外，系統的效率難免會受影響。因此最近幾年微內核的支持者忙于研究如何提高系統的效率，一種途徑是尋找更優的進程間通訊機制，以便從根本上提高效率，另一種結果是一些微內核系統把有的系統服務又重新置于內核之中，這從某種程度上確實提高了效率，但是其代價是一定程度上違背了微內核的初衷。

    近幾年由于嵌入式系統的飛快發展，微內核操作系統的研究又成為熱點，這主要是因為嵌入式系統資源有限，而整體內核系統的內核一般都要占據很大的內存空間，這是嵌入式系統無法容忍的。嵌入式系統看好微內核的另一重要原因是魯棒性和可動態配置，因為許多嵌入式系統應用是用于控制系統，控制失靈往往會造成難以估計的災難。微內核的缺點在嵌入式系統的應用中仍然非常突出，嵌入式系統通常都要求較高的效率。

    從上面的論述中可以看出，微內核和整體內核的爭論問題，最后歸結為穩定性和效率的選擇問題。迄今為止，仍沒有很完美的解決方案，一般是根據問題的重點決定采用某種方案。

    4 和欣操作系統

    和欣操作系統 [1] 是北京科泰公司自行研制開發的一個基于構件化軟件模型的系統，適應嵌入式實時需求，基于靈活內核技術，直接支持瀏覽器，對網絡應用可提供強大支持。它具有許多先進的特性，在這里我們主要關注和構件化驅動程模型緊密相關的特性。

    首先，和欣是基于構件化軟件模型的操作系統。構件化軟件設計思想貫穿了整個系統的設計與實現中，系統實現本身就是構件模式。除微內核中最底層的控制部分外，所有系統功能都是以構件接口的形式提供。另外，操作系統對構件化軟件模型提供了必要的運行環境，來源不同的構件可以在該環境上實現互操作。系統提供了構件自動尋址 / 自動加載機制，用戶不必知道調用的構件程序是本地的還是來自于網上，也就是說，構件運行環境可以對用戶透明。構件化系統的實現，使得操作系統本身具有高度的靈活性和擴展性。和欣采用的構件技術是 ezCOM 技術，該技術是北京科泰公司開發的一項技術，它基于微軟的 COM 技術，后面會詳細介紹 ezCOM 技術。

    其次，和欣系統實現了靈活內核技術（ Agile Kernel ）。 用戶可以根據需要，將一些來源值得信賴或對運行效率要求高的驅動程序配置于內核態，而另一些置于用戶態，在一個嵌入式系統中同時滿足安全性與實時性的特殊要求。構件、中間件技術提供了一致性的構件加載規范，不同的就是讓調用的構件運行在內核空間還是用戶空間。在這樣的體系結構中，我們不必區分是大內核還是微內核，事實上，所謂的 “ 內核 ” 可大可小，完全依據系統自身的需求動態決定。

 

圖 1 和欣的靈活內核技術

    5 ezCOM 技術

    80 年代以來，面向對象型軟件編程技術有了很大的發展，為大規模的軟件協同開發以及軟件標準化、軟件共享、軟件運行安全機制等提供了理論基礎。實際上，面向對象技術的發展一直是為了解決軟件工程提出的問題。

    在過去二十年里，軟件工程出現了許多需要解決的問題是： 1. 面向對象軟件的封裝技術。這就是將復雜的問題，通過封裝變成許多相對簡單、獨立的問題； 2. 軟件模塊之間的互操作性； 3. 軟件版本升級的獨立性。任何一個構件的升級或變化都不會影響到系統中與其進行互操作的其他構件； 4. 構件實現的語言無關性； 5. 運行環境的透明性。需要一個簡單、統一的編程模型，使得構件可以在進程內、跨進程甚至于跨網絡運行。同時提供系統運行的安全、保護機制。

    在各個時期為了解決這些問題，軟件技術經歷了幾個發展階段。以 C++ 為代表的面向對象的編程技術從源程序級實現了對象封裝，但它的模塊之間是靜態綁定； COM 程序模型 [4] 采用了構件化技術，它主要強調構件之間的相互操作的協議標準，模塊之間是動態綁定的； COM+ 程序模型實現了中間件技術，也就是在服務與客戶之間動態添加中間層，在中間層可以完成與服務邏輯上正交的一些事務處理，如安全事務處理、網絡負載均衡等。

    從 C++ 到 COM 、 COM+ ，軟件工程技術的發展使人們更加深入地認識了科學的編程方法學，同時也為解決本節開頭提出的軟件工程問題提出了更加完美的解決方案。

    和欣操作系統采用了構件技術框架， ezCOM 技術 [1] 就是該框架的核心內容。它基于成熟的 COM 技術，并對該技術作了一些重要的發展， ezCOM 技術具有以下特點：

    靈活的實現機制 提供了優化、方便的 ezCOM 工具庫和 ezCOM 庫支持環境，靈活的 ezCOM 服務器和 ezCOM 客戶的實現機制。

    簡化的構件封裝技術 ezCOM 客戶和所使用的 ezCOM 構件對象之間增加了由 ezCOM 工具庫自動實現的封裝層，屏蔽了調用 COM 構件對象過程的繁瑣細節，大大簡化了 COM 客戶的實現。

 

圖 2 ezCOM 運行機制

    增加了標準接口的實現類來完成標準接口的實現 該標準接口類的實現可以由 ezCOM 工具庫自動完成，開發者在實現 ezCOM 構件類時，只要它繼承了標準接口實現類就不用再關心標準接口的實現，但這絲毫不會改變接口二進制接口標準。

    統一的類廠實現

    擴展的接口描述語言 為 ezCOM 服務器中新功能的實現提供了方便，如腳本語言調用構件對象函數等。

    和欣操作系統的基本系統服務均使用 ezCOM 技術包裝，而且在核心態與用戶態統一系統服務的接口，這一點顯然不同于以往的許多操作系統。以往的多數操作系統提供兩份功能相似的系統服務接口，其中一份給內核模塊使用，另一份給用戶態模塊使用。和欣系統的這一特性使得編寫既能運行于核內又能運行于核外的功能模塊成為可能。

    圖 2 展示了和欣操作系統中 ezCOM 技術的運行機制。當用戶程序調用一個構件時，系統便根據構件的元數據創建一個代理構件，用戶程序通過代理構件實現對構件對象的訪問。圖中虛線框中的部分是系統自動生成的構件運行環境。系統通過對代理構件的管理實現 ezCOM 的種種特性。

    6 構件化驅動程序設計

    自從關于微內核和整體內核的爭論開始以來，雙方的支持者都在不同的程度上對各自的體系結構進行了改造，但矛盾依然存在。下面提出的基于和欣操作系統的構件化驅動程序模型將嘗試解決這一矛盾，確切地說解決途徑是在微內核系統和整體內核系統之間尋求一種折衷方案。

    構件化驅動程序設計方案是使用 ezCOM 構件技術封裝驅動程序，每個驅動程序都是一個模塊化非常強的構件。這些構件由 DLL 的形式承載，一個 DLL 中可以封裝一個或多個驅動程序構件。使用 ezCOM 構件技術封裝驅動程序使得驅動程序可繼承 ezCOM 的大部分優點，而且也給驅動程序帶來了新的特性。構件化驅動程序可以建立符合設備功能和用戶理解的接口，這一點不同于類 UINX 系統， UINX 系統的驅動程序都是以文件的接口形式體現。

    由 ezCOM 技術封裝的驅動程序根據功能區分將提供兩組接口，一組為系統功能接口；另一組為用戶使用接口。系統功能接口是用于從系統角度管理設備驅動程序，完成設備驅動的配置、初始化和啟動終止等功能。用戶使用接口是用戶程序（驅動程序的客戶端程序）使用，通過這些接口用戶程序可以訪問改程序驅動的硬件設備，實現和硬件設備的信息交換。

    構建設備驅動程序的代碼只會使用內核提供的基本系統服務或由這些基本系統服務構建的服務模塊，基于這一原則構建的設備驅動程序可以靈活地選擇運行環境。具體地說，設備驅動程序可以動態配置到以下幾種環境中運行： 1. 在系統內核中運行驅動程序； 2. 在用戶進程內運行驅動程序； 3. 在內核外地進程外服務模塊運行驅動程序。和欣操作系統的統一系統服務接口和 ezCOM 技術提供的靈活的跨邊界構件運行機制保證了構件化設備驅動程序的以上三種運行方式。在圖 1 中也可以看到這一點。

    通過動態配置驅動程序的運行環境，和欣操作系統能夠在多種系統性能之間進行選擇。如果某一個驅動程序經過長期測試具有很強的穩定性或是系統追求高效率時，可以讓驅動程序在核內運行，這時驅動程序調用系統服務就無需再通過 IPC （ inter-process communication ）陷入到內核中，而只需完成一個普通的函數調用過程，這樣 IPC 和線程切換耗去的時間都會節省下來，自然效率會大大提高。但是在效率得到提升的同時，系統的穩定性卻降低了，由于驅動程序運行在系統內核中，驅動程序的崩潰會對內核造成很嚴重的影響，甚至會導致內核的崩潰。為了得到較高的穩定性，可以讓驅動程序運行于內核外，也就是讓驅動程序以后兩種方式來運行。

    驅動程序的后兩種運行方式的區別在于是否運行于客戶端程序進程內，如果驅動程序只被某個應用使用，則完全可以讓其運行在用戶進程內，這樣用戶程序和驅動程序的交互無需通過 IPC ，但是驅動程序的崩潰會影響應用程序。如果驅動程序運行于內核外的進程外服務模塊中，雖然效率會受損失，但由于客戶端程序和驅動程序運行在不同的地址空間，當然作為客戶端的用戶程序會更穩定。

    應當說明的是，驅動程序在上面三種方式下運行，并不需要改變驅動程序的源代碼。而客戶端程序如果不是特別聲明要求驅動程序的運行方式，在驅動程序運行方式發生改變時，客戶端程序也不需要修改，這時驅動程序的運行方式是由作為第三方的配置來決定的。

    和欣操作系統的靈活內核技術和 ezCOM 技術使得構造具有上述的構件化驅動程序成為可能，其實這種模式同樣適用于不涉及硬件的服務構件。和欣系統的內核和符合這種模式的服務構件組建起來的系統可以根據具體需要在多種性能之間進行選擇，從而部分有效地解決整體內核和微內核之間的矛盾。

    【參考文獻】

    •  北京科泰公司資料 . 和欣操作系統簡介 . 2002.8.

    •  A. Tanenbaum. Modern Operating Systems. Prentice-Hall 1993, 2nd edition 2001.

    •  Chris Dibora, Sam Ockman, and Mark Stone. Open Sources-voices from the Open Source Revolution. O'REILLY, 1999.

    •  Dale Rogerson, 楊秀章譯 . COM 技術內幕微軟組件對象模型 . 北京 : 北京清華大學出版社 , 1998.

    •  Giemn. M, Grob L. Microkernel based operating systems moving UNIX onto modern system architectures. In proc. Uniforum '92 conf. , USENIX Assoc, 1992.

                Device driver design based on agile kernel                             Du Yongwen, He Huacan

    (Department of Computer Science and Engineering, Northwestern Polytechnical University)
                            (710072 Xi'an of China)

                                Chen Rong

        (KoreTide Century. Inc. ， Beijing. 100029 ， Beijing of China)

    Abstract: In this paper, for solving debates between micro-kernel and macro-kernel we propose component-based device driver on agile kernel of HEXIN operating system. The device driver which is built in this model can be executed under many domains. When device driver run in different domains, the system would gain different qualities.

    keywords: component-based driver , component technique, operating system architecture

原文轉自：http://www.anti-gravitydesign.com