Windows核心管理層的組件之I/O管理模組

Windows的裝置驅動架構

    Windows核心管理層的組件之一是I/O管理模組，有時候也稱為I/O子系統。I/O管理模組所管理的對象與活動縱向貫穿管理層、核心層乃至HAL層，所以稱之為子系統其實也有道理。I/O管理的主體就是我們所說的裝置驅動。很自然地，如果我們沿著縱向考察某項裝置的驅動，則一般而言也會分成若干層次。作業系統的一個基本原理就是分層虛擬，即使一種裝置的驅動程式全部都在同一個來源程式檔案中，只要不是特別簡單的裝置驅動，其設計必然會自覺或不自覺地體現分層虛擬原理。所以，一項裝置的驅動軟體常常表現為若干驅動程式的“堆疊（Stack）”。這個堆疊的頂層在管理層中，底層則在HAL層中；愈往上，離具體裝置的硬體愈遠，就愈抽象，與其他裝置的共性就愈多；愈往下，離具體裝置的硬體愈近，就愈具體、愈體現出具體裝置的個性。不過上層模組與下層模組之間不一定是一對一的關係，而可以是一對多的關係。以檔案系統為例，這個堆疊的頂層（大致上）是檔案系統，下層是檔案系統所在的載體。但是這個載體可以是磁碟，也可以是光碟片，還可以是“隨身碟”。如果是磁碟，則可以是串連在IDE介面上的固定硬碟，也可以是SCSI磁碟。所以，裝置驅動邏輯意義上的系統結構其實是一種（倒置的）樹狀結構，所謂一個堆疊實際上相當於從根節點通往某個特定分葉節點的一條路徑。
    另一方面，裝置驅動也是核心中最需要加以動態擴充的部分。這是因為在編譯產生系統核心時常常無法確切地知道使用中究竟需要哪一些裝置。顯然，最好的辦法是將各種裝置驅動的堆疊做成可以動態安裝的程式模組，就像在使用者空間可以動態載入DLL一樣。Windows正是這麼做的，副檔名為.sys的模組就是此類可動態裝載的核心模組。注意“模組”這個詞在不同的語境下有不同的意義。當我們談論核心管理層中的I/O管理模組時，是指邏輯上相對自成一體的一個部分，也許稱之為“板塊”更貼切一些。而在談論.sys模組的時候，則是說一塊可動態裝載的可執行映像。這種可動態裝載的可執行映像可大可小，事實上    win32k.sys就是這樣一個模組。當然，其他模組就沒有這麼大了。在實踐中，一般都根據具體的需要把一種特定裝置的驅動程式堆疊實現成一個.sys模組；或者把一個堆疊中的一層或幾層實現成一個.sys模組，實際使用時則由一個或數個.sys模組提供該種裝置的驅動程式堆疊。
所以，裝置驅動有兩個問題，一個是分層的問題，一個是動態裝載的問題。
    但是程式的分層有概念和形式之分，概念上的分層只是程式員編程的方法問題，當然裡面也體現著程式員的技藝和水平；而形式上的分層，則是系統為裝置驅動程式的開發定下的模型（Model）和架構（Framework），一方面要求開發人員按特定的、體現著程式分層的模型開發裝置驅動程式，另一方面則又為符合這種模型的裝置驅動程式提供基礎設施的支援。打個比方，就好像一個機架，一方面它要求凡是要插入這個機架的模組在形狀、尺寸等方面都符合某種規定；而另一方面，只要你符合這樣的規定，則機架為你提供電源、通風、模組間通訊等基礎設施。
對於Windows的裝置驅動模組，這個架構定義了：
    裝置驅動模組以何種形式提供有關的操作（體現為一個含有若干函數指標的資料結構），以及這些操作的範圍（開啟、關閉、讀、寫等）。
    怎樣啟動由裝置驅動模組提供的特定操作（將“作業碼”等參數組裝在一個標準格式的資料結構“I/O請求包”即IRP中，以此資料結構作為形式上的調用參數，通過裝置驅動架構為此提供的手段IoCallDriver()調用裝置驅動模組提供的相應函數指標）。
    如果需要，一個裝置驅動模組如何啟動其（同一堆疊中的）下層模組的操作（仍通過IoCallDriver()，並把“I/O請求包”傳到下一層）。
    可以從裝置驅動程式中調用核心的哪一些函數，訪問核心的哪一些變數（Windows的DDK對此做出了規定）。
    之所以對於裝置驅動模組的介面可以定義一種固定的模型，是因為裝置驅動模組所提供的服務有個固定的範圍，屬於一個固定的集合，不外乎開啟、關閉、讀、寫等操作。相比之下，使用者空間的DLL就不像裝置驅動模組那麼規範，因為一般而言DLL所提供的服務五花八門，並不限於某個固定的集合，因而無法統一到一組固定的函數集合中。

 

本文節選自《Windows 核心情景分析--採用開原始碼ReactOS》一書