WDF I/O request flow

WDF I/O request flow

I/O manager 產生一個 IRP 後，dispatcher 會根據 IRP major I/O function code，傳送 IRP 到 I/O package/PnP-Power package/WMI package。WDF driver 可以註冊一個 callback 來處理這三種的 request。

假使 IRP 發到 I/O package，假如 driver 沒有建立 queue 和 callback 的話，則 WDF framework 會執行它預設的行為。如果是 driver type 是 filter driver，則它會將 IRP 傳給下一層 driver；如果是其它 driver type 的話，則會 fail。

如果 driver 有建立 queue 和 callback，則 framework 會建立一個 WDF request 並將它放進 queue 中，接著再呼叫 driver 所註冊的 callback。

假使裝置並不在可工作的狀態（如低電源狀態），I/O package 需要 PnP/Power package 執行 driver 註冊的關於電源的 callback 來讓電源回復可工作狀態，這樣 device 才能正常處理。

WDF driver 透過註冊 event callback 來處理它感興趣的事件。所有未被 driver 註冊處理的事件，framework 通通會處理掉。以一個 IRP 送給 filter driver 再到 function driver 為例，假使  filter driver 不想處理這個 IRP，WDM 中它仍需要幫忙將這個 IRP 送給下一層的 driver。然而在 WDF 中，filter driver 可以不註冊這種類型的 IRP，framework 會依據它預設的行為將此 IRP 送給它下一層的 function driver。

I/O flow to kernel-mode WDF driver

從圖中可以看出來，application 下一個 I/O request 後，Win32 API 會呼叫位於 I/O manager 中的 I/O routine。I/O manager 接著產生一個代表此 request 的 IRP，並且呼叫 KMDF 中的 entry point。這個 entry point 是 KMDF 向 I/O manager 註冊的。當 KMDF 收到這個 IRP 後，接著就進入剛剛所講的流程中。

I/O flow to user-mode WDF driver

然而在 user-mode driver 中有點不太一樣，由於 user-mode driver 不能存取 kernel-mode 的資源，因此 I/O manager 將 IRP 送給一個 kernel-mode component -- reflector。reflector 是一個 WDM filter driver，它在 kernel-mode driver stack 中抽象地表示一個 user-mode driver。reflector 將 I/O request 傳給 user-mode driver host process，並且監控 host process 能夠在時間內完成 critical 操作以避免 driver 與 application hang 住。

driver host process 不是一個 Windows service，它是由 driver manager 負責產生與結束。每一個 driver 都會有自己的 driver host process 與 device stack。它裡頭的 run-time 環境負責 dispatch I/O request、載入 driver 與建立/刪除 device stack。

UMDF 本身是一個 DLL，它提供 driver 的 I/O, PnP, 以及 power management。

上圖分的更細。reflector 會產生三個 device object：up/down/control。up 就是負責接收來自 I/O manager 的 IRP 並透過 IPC 與 host process 溝通。而 down device object 則是接收來自 driver 的 I/O request，它是 driver 預設的 I/O target。control device object 則也是透過 IPC 與 driver manager 溝通。driver manager 也是透過 IPC 與 host process 溝通。