1. Linux Device Driver Report I/O Request Flow in WDF Kernel- Mode Drivers

2. Outline Flow of an I/O Request Throught the System –Application I/O Requests –I/O Request Path from Application to Driver –KMDF Driver Processing of I/O Requests Flow of an I/O Request Within a KMDF Driver –Framework Receives a Request and Inserts It on a WDFQUEUE –Framework Invokes the Driver’s I/O Event Processing Callback –Driver’s I/O Event Processing Callback Executes

3. Application I/O Requests Application I/O Requests 的種類 –Create Requests CreateFile –Close Requests Close –Read and Write Requests ReadFile WriteFile –Device Control Requests DeviceControl

4. Application I/O Requests 同步、非同步 –Synchronous –Control 會等到 request 完成後，才會回到 application 。 –Asynchronous –Control 會立刻回到 application 。 –Application 必須自己檢查 Request 是否完成。

5. I/O Request Path from Application to Driver

6. 1.When an application issues an I/O request, Windows issues a system service call to the system service dispatcher. 2.The system service dispatcher calls the corresponding I/O processing function of the Windows I/O Manager. 3.The I/O Manager builds an I/O request packet (IRP) that describes the I/O request issued by the application and sends it to the framework (the KMDF library, Wdfdynam.sys). The framework sorts incoming requests by major function code and, in the case of a read, write, or device control request, sends it to the framework's I/O package for processing. The I/O package validates the request parameters and processes the request according to its type and the driver's configuration of its WDFQUEUE(s). 4.If the KMDF driver is a filter driver and has configured its WDFQUEUE(s) to forward requests of this type to the next-lower driver on the underlying driver stack, the framework forwards the request to the next-lower driver. Otherwise, it forwards the request to the KMDF driver. 5.If the KMDF driver receives the request, it processes the request and, if necessary, forwards it to the next-lower driver on the underlying stack. 6.That driver processes the request and, in turn, forwards the request to the next- lower driver and so on down the driver stack, as needed to satisfy the request.

7. I/O Request Path from Application to Driver I/O Request Path from Application to the Framework Windows Issues a System Service Call for an Application I/O Request The System Service Dispatcher Calls the I/O Manager The I/O Manager Builds an IRP and Sends It to the Framework –Validating request parameters –Building the IRP –Sending the IRP to the framework.

8. I/O Request Path from Application to Driver I/O Request Path from Framework to Driver

9. KMDF Driver Processing of I/O Requests Processing a Request Internally Processing a Request by Sending It to Another Driver Requests Marked Pending During Processing

10. KMDF Driver Processing of I/O Requests I/O Completion Path from Driver to Application.

11. KMDF Driver Processing of I/O Requests Driver Completion of a Request –I/O status. –Completion information. –Requested data. I/O Completion Path from Framework to I/O Manager I/O Manager Completion of a Request –Stage 1: Completion Processing in Arbitrary Context –Stage 2: Completion Processing in the Requestor’s Context

12. Framework Receives a Request and Inserts It on a WDFQUEUE WDFQUEUE Insertion Logic –If the device has previously been defined as a filter device object (by calling WdfFdoInitSetFilter) –The framework determines the correct WDFQUEUE into which to place the arriving WDFREQUEST –The framework then checks the dispatch type for the chosen WDFQUEUE Driver Queue Implementation

13. Framework Receives a Request and Inserts It on a WDFQUEUE Consider the following queue structure provided by the WDFDIO driver: WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbac ks, WdfIoQueueDispatchSequential); ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl; status = WdfIoQueueCreate(device, &ioCallbacks, WDF_NO_OBJECT_ATTRIBUTES, NULL); // optional pointer for queue handle

14. Framework Invokes the Driver's I/O Event Processing Callback Dispatch Type of the Queue Dispatch Types –WdfIoQueueDispatchParallel –WdfIoQueueDispatchSequential Impact of Dispatch Type on Driver Design Synchronization Scope for WDFDEVICEs and WDFQUEUEs Specifying Synchronization Scope

15. Framework Invokes the Driver's I/O Event Processing Callback How Synchronization Scope Works Queue State Is the Callback Called?

16. Driver's I/O Event Processing Callback Executes Validating the Arriving Request Processing the Arriving Request Satisfying the Request within the I/O Event Processing Callback Initiating a Request on the Device Sending a Request to Another Driver for Processing

17. Driver's I/O Completion Routine Executes I/O Completion Routine Example –VOID –EvtRequestReadCompletionRoutine( – IN WDFREQUEST Request, – IN WDFIOTARGET Target, – PWDF_REQUEST_COMPLETION_PARAMS CompletionParams, – IN WDFCONTEXT Context – ) –{ – NTSTATUS status; – size_t bytesRead = 0; – PWDF_USB_REQUEST_COMPLETION_PARAMS usbCompletionParams; – UNREFERENCED_PARAMETER(Target); – UNREFERENCED_PARAMETER(Context); – status = CompletionParams->IoStatus.Status; – – usbCompletionParams = – CompletionParams->Parameters.Usb.Completion; – – bytesRead = usbCompletionParams->Parameters.PipeRead.Length; – – WdfRequestCompleteWithInformation(Request, status, bytesRead); – return; –}