43、Windows驅動程式模型筆記(一)

1、通常，驅動程式在某些不可預測線程的上下文中應該使用非同步方式處理I/O請求。我們使用術語任意線程上下文(arbitrary thread context)來描述驅動程式並不知道(或並不關心)處理器當前執行在哪一個線程上的上下文。

2、 Windows 2000使用對稱式多處理器模型，即所有的處理器都是相同的，系統任務和使用者模式程式可以執行在任何一個處理器上，並且所有處理器都平等地訪問記憶體。多處理器的存在給裝置驅動程式帶來了一個困難的同步問題，因為執行在多個CPU上的代碼可能同時訪問共用資料或共用硬體資源。Windows 2000提供了一個同步對象，自旋鎖(spin lock)，驅動程式可以使用它來解決多處理器的同步問題。

3、當CPU運行在 PASSIVE_LEVEL級時，當前啟動並執行線程可以被任何優先順序大於它的線程搶先。然而，一旦CPU的IRQL大於PASSIVE_LEVEL級，線程搶先將不再發生，此時CPU執行在使CPU越過PASSIVE_LEVEL級的任意線程上下文中。但是，運行在任何IRQL級上的活動都可以被更高 IRQL級上的活動中斷。所以驅動程式必須假定在任何時刻都可能失去控制權，而此時系統可能需要執行更基本的任務。

4、為了實現可配置性，首先應該在代碼中避免直接引用硬體，即使是在平台相關的條件編譯塊中也是這樣。應該使用HAL工具或調用低級匯流排驅動程式，或者實現一個標準的或定製的控制介面，並通過控制台程式與使用者互動。另外，還應該支援Windows管理儀器(WMI)控制項，這種控制項允許使用者和管理員在分布式企業環境中配置硬體特徵。最後，應該使用註冊表作為配置資訊的資料庫，這可以使配置資訊在系統重新啟動後仍然存在。

5、為了實現這種可移植性，驅動程式應該全部用C寫，並且只使用ANSI C標準規定的語言元素。應避免使用編譯器廠商專有的語言特徵，並避免使用沒有被作業系統核心輸出的已耗用時間庫函數(參見第三章)。如果不能避免驅動程式中的平台依賴，至少應該用條件編譯指令隔離這些代碼。

6、可以把一個完整的驅動程式看作是一個容器，它包含許多常式，當作業系統遇到一個IRP時，它就調用這個容器中的常式來執行該IRP的各種操作。

可以把一個完整的驅動程式看作是一個容器，它包含許多常式，當作業系統遇到一個IRP時，它就調用這個容器中的常式來執行該IRP的各種操作。有些常式，例如DriverEntry和AddDevice，還有與幾種IRP對應的派遣函數將出現在每一個這樣的容器中。需要對IRP排隊的驅動程式一般都有一個 StartIo常式。執行DMA傳輸的驅動程式應有一個AdapterControl常式。大部分能產生硬體中斷的裝置，其驅動程式都有一個插斷服務常式 (ISR)和一個延遲程序呼叫(DPC)常式。驅動程式一般都有幾個支援不同類型IRP的派遣函數，其中三個派遣函數是必須的。所以，WDM驅動程式開發 者的一個任務就是為這個容器選擇所需要的常式。

圖示 P21 1-5 WDM驅動程式“容器”中的內容

7、有三種註冊表鍵負責配置。它們是硬體(hardware)鍵、類 (class)鍵、服務(service)鍵。必須明確一點，這些名字(指hardware、class、service)並不是某個專用子鍵的名稱：它 們是這三種鍵的一般稱謂，其具體的路徑名要取決於它們所屬的裝置。概括地講，硬體鍵包含單個裝置的資訊，類鍵涉及所有相同類型裝置的共同資訊，服務鍵包含 驅動程式資訊。有時人們用“執行個體(instance)鍵”和“軟體(software)鍵”來代表硬體鍵和服務鍵。

    裝置的硬體鍵出現在註冊表local machine分支的\System\CurrentControlSet\Enum子鍵上。

    應用程式經常需要訪問註冊表中關於硬體裝置的資訊。為了使這成為可能而同時又不暴露重要的Enum鍵，Microsoft提供了一組SetupDiXxx函數。

   裝置介面的符號串連名(通過枚舉該介面GUID的所有執行個體或者從WM_DEVICECHANGE訊息的參數中獲得這個名字)。ClassGUID是裝置類GUID(通用唯一識別碼)的ASCII形式；在效果上，它是一個指向該裝置類鍵的指標。Service指向服務鍵。

類鍵 所有裝置類的類鍵都出現在HKLM\System\CurrentControlSet\Control\Class鍵中。它們的鍵名是由Microsoft賦予的GUID值。

服務(或軟體)鍵 對裝置驅動程式重要的最後一個鍵是服務鍵。它指出驅動程式執行檔案的位置，以及控制驅動程式裝入的一些參數。服務鍵位於HKLM\System\CurrentControlSet\Services鍵中。

    當我說系統“裝入”一個驅動程式時，是指系統把驅動程式的映像映射到虛擬記憶體中，並重定位記憶體參考，最後調用驅動程式的主進入點。主進入點通常命名為 DriverEntry。我將在本章後面講述DriverEntry函數。如果驅動程式已經在記憶體中，則裝入過程僅僅是增加驅動程式映像的參考計數。

8、驅動程式的裝入順序並不是很重要。系統以PnP管理器裝入驅動程式的順序調用驅動程式的AddDevice函數，而這個順序與裝置對象在裝置堆疊中出現的順序完全一致。

圖示2-2 裝置遞迴枚舉過程

圖示2-2顯示了一個由多個裝置堆疊組成的樹形結構，但這並不表示IRP必須從上一層的PDO流向下一層的FiDO。實際上，一個堆棧的PDO驅動程式就是其下一層堆棧的FDO驅動程式，見圖示2-2中的陰影塊。當驅動程式以PDO角色接收到一個IRP時，它對該IRP執行一些操作但不發出這個或其它IRP到裝置(以FDO角色)。相反，當匯流排驅動程式以FDO角色接收到一個IRP時，它可能需要向裝置發送某些IRP(以PDO角色)。

圖示 圖2-8 裝置(位於二級匯流排)讀請求處理流程