檔案系統驅動編程基礎篇之2——標準模型

二、標準模型

WDM採用了結構化的編程方式，執行效率很高，但編寫效率較低，這也是DriverStudio得以發展的重要原因。正如掌握了COM原理，使用ATL才能掌握精髓的道理一樣，讀者需要忍受記憶大量基礎知識的“痛苦”，暫時放棄編寫驅動程式的捷徑。

下面的某些圖示稍顯陳舊，不過已經足以說明問題了。

儘管驅動程式分為多個種類（圖1-4），但它們包含的基本內容（圖1-5）是一致的。每個驅動程式都從初始化程式DriverEntry進入，通過某個派遣常式DispatchXXX派發特定命令（我們不妨稱之為IRP），這些IRP有可能在派遣常式裡就得到瞭解決，也有可能交給驅動程式的其他部分解決。如果驅動程式A本身不能處理這個IRP命令，它就需要將IRP傳遞到更下層的驅動B，由它們來處理，此時驅動程式A可能因為等待IRP完成而處於睡眠狀態，或繼續處理新的IRP，直到下層驅動B通知（或通過某種機制喚醒並通知）A該IRP已經處理完畢了，此時A就將處理的結果（我們稱之為NTSTATUS）返回原來派發這個IRP的發起人。這就是驅動程式處理IRP的一個簡化過程。

我們提到了驅動程式是分層的這個概念，那麼如何理解分層的概念呢？請看圖示：

引用資料1的原話：WDM模型使用了如圖2-1的階層。圖中左邊是一個裝置對象堆棧。裝置對象是系統為協助軟體管理硬體而建立的資料結構。一個物理硬體可以有多個這樣的資料結構。處於堆棧最底層的裝置對象稱為物理裝置對象(physical device object)，或簡稱為PDO。在裝置對象堆棧的中間某處有一個對象稱為功能裝置對象(functional device object)，或簡稱FDO。在FDO的上面和下面還會有一些過濾器裝置對象(filter device object)。位於FDO上面的過濾器裝置對象稱為上層過濾器，位於FDO下面(但仍在PDO之上)的過濾器裝置對象稱為下層過濾器。

由某個傢伙（可能是使用者模式下的應用程式，也可能是系統核心組件）發起的IRP從上層過濾器驅動程式一直順流而下，傳遞到匯流排驅動程式處理後，再逐級返回上層，最終發起人得到處理的結果。

一般情況下，IRP也許不需要傳遞到匯流排驅動程式就被處理掉了，但如果大家都不認識這個IRP，他們就只好逐級下傳了，如果此時有個搞破壞的驅動程式混了進來，攔截了這個IRP，輕則丟失使用者資訊、重啟、死機，重則造成系統區的資料混亂，你除了重新安裝作業系統再無任何事情可做。由此可見，我們不要求驅動程式“有理想”，但必須“有紀律”，每個驅動程式都必須嚴格按照規範書寫代碼，這要求編程人員具備較高的素質。

下面我們來瞭解驅動編程裡最基本的標準模型，這個模型不能解決所有的編程需求，根據需要，它將存在各種變化。我們來看看這個驅動編程裡的“基本定式”：

IO管理器，大家應該理解為該IRP的發起人，可能是張三，也可能是李四，而不是某個固定的組件。這個模型表明了單個驅動程式裡各組件的合作與分工，注意它是個迴圈不斷的過程，它的發起人與最終接受人是相同的，所謂“從哪裡來，就回哪裡去”。如果我們的編程不涉及真正的硬體，StartIo常式、插斷服務常式ISR、DPC常式均可能不存在。各組件的具體功能請參看資料1的第五章。