Windows的設備驅動框架

??? Windows內核管理層的部件之一是I/O管理模塊，有時候也稱為I/O子系統。I/O管理模塊所管理的對象與活動縱向貫穿管理層、核心層乃至HAL層，所以稱之為子系統其實也有道理。I/O管理的主體就是我們所說的設備驅動。很自然地，如果我們沿著縱向考察某項設備的驅動，則一般而言也會分成若干層次。操作系統的一個基本原理就是分層虛擬，即使一種設備的驅動程序全部都在同一個源程序文件中，只要不是特別簡單的設備驅動，其設計必然會自覺或不自覺地體現分層虛擬的原理。所以，一項設備的驅動軟件常常表現為若干驅動程序的“堆疊（Stack）”。這個堆疊的頂層在管理層中，底層則在HAL層中；愈往上，離具體設備的硬件愈遠，就愈抽象，與其他設備的共性就愈多；愈往下，離具體設備的硬件愈近，就愈具體、愈體現出具體設備的個性。不過上層模塊與下層模塊之間不一定是一對一的關系，而可以是一對多的關系。以文件系統為例，這個堆疊的頂層（大致上）是文件系統，下層是文件系統所在的載體。但是這個載體可以是磁盤，也可以是光盤，還可以是“U盤”。如果是磁盤，則可以是連接在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所提供的服務五花八門，并不限于某個固定的集合，因而無法統一到一組固定的函數集合中。

轉載于:https://www.cnblogs.com/broadview/archive/2009/05/13/1455628.html

總結

以上是生活随笔為你收集整理的Windows的设备驱动框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。