i/o request flow in wdf kernel ‑ mode drivers peter g. viscarola, open systems resources, inc....
Post on 21-Dec-2015
215 views
TRANSCRIPT
I/O Request Flow in WDF Kernel‑Mode Drivers
Peter G. Viscarola, Open Systems Resources, Inc. Microsoft DDK Most Valuable Professional
May 10, 2006
Introduce to This paper describes how I/O requests are processed within th
e Microsoft® Windows® operating system and the Windows Driver Foundation (WDF) kernel‑mode driver framework (KMDF)
I/O flow is a complex topic, so this paper is organized into two parts focusing on the general activities performed by each component
that handles the request focusing on the path of the request through different routines in
the driver according to the options and configurations the driver chooses
The Flow of an I/O Request Through the System Application I/O Requests
Common I/O Requests Issued by Applications Create Requests Close Requests Read and Write Requests Device Control Requests
Synchronous and Asynchronous Application Requests Are Asynchronous Requests Always Completed Asyn
chronously? Are Synchronous Requests Always Completed Synch
ronously?
I/O Request Path from Application to Driver
USBHUB
System Service Dispatcher
I/O Manager
Kernel Mode
User Mode
1
Applicationstatus = ReadFile(handle,...)
USBPORT
PCI
UsbDev.sys(KMDF driver)
KMDF Library(Wdfdynam.sys)
3
5 4
2
1
6
I/O Request Path
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.
I/O Request Path from Application to Driver (cont.) I/O Request Path from Application to the Frame
work Windows Issues a System Service Call for an Ap
plication I/O Request The System Service Dispatcher Calls the I/O Ma
nager The I/O Manager Builds an IRP and Sends It to t
he Framework Validating request parameters Building the IRP Sending the IRP to the framework.
I/O Request Path from Framework to Driver
Driver Callbacks
IRP_MJ_PNPIRP_MJ_POWER
IRP_MJ_SYSTEM_CONTROL (KMDF only)
I/O Requests(IRP_MJ_READIRP_MJ_WRITEIRP_MJ_DEVICE_CONTROL)
IRP_MJ_Xxx
Driver Callbacks
Driver Callbacks
Dispatcher
I/O Package
Plug and Play/Power
Package
WMI Package
I/O Target
Non-power-managed I/O
Queues
...
Power-managed I/O Queues
The KMDF Request Processing Pipeline
I/O Request Path from Framework to Driver (cont.) The Framework Routes the Request to the Appropriate
Package The I/O Package Checks the I/O Request Type The I/O Package Further Validates Request
Parameters Read and write requests Device control requests
The Framework Processes the Request Handles the request on behalf of the driver Forwards the requests to the driver for the next-lower
device in the device stack. Creates a WDFREQUEST object that represents the
arriving request and passes it to the KMDF driver.
KMDF Driver Processing of I/O Requests Processing a Request Internall Processing a Request by Sending It to An
other Driver Processing before sending the request. Initializing the next I/O stack location
in the request Sending requests synchronously or async
hronously
I/O Completion Path from Driver to Application
USBHUB
System Service Dispatcher
I/O Manager
Kernel Mode
User Mode
Applicationstatus = ReadFile(handle,...)
USBPORT
PCI
UsbDev.sys(KMDF driver)
KMDF Library(Wdfdynam.sys)
3
5 4
2
1
6
E
D
C
B
A
I/O Completion Path
I/O Request Path
I/O statusCompletion informationBuffered data
I/O Completion Path from Driver to Application (step A) Driver Completion of a Request
When an I/O request is fully satisfied
I/O status. Completion information. Requested data.
I/O Completion Path from Driver to Application (step B) I/O Completion Path from Framework to
I/O Manager When a KMDF driver completes a WDFREQUEST,
it calls a function such as WdfRequestComplete. Next, the framework destroys the WDFREQUEST
itself, returning any context storage associated with the WDFREQUEST
I/O Completion Path from Driver to Application (step C) I/O Manager Completion of a Request The I/O Manager completes I/O requests i
n two stages: Stage 1: Completion processing that might t
ake place in any process and thread context (sometimes called an "arbitrary" process and thread context).
Stage 2: Completion processing that must take place in the context of the thread that issued the I/O request.
Flow of an I/O Request Within a KMDF Driver
describes the path an I/O request takesduring processing within a KMDF driver.
Factors that influence the path of an I/O request within a KMDF driver. The type of device being supported. The driver’s WDFQUEUE configuration The driver’s synchronization scope conf
iguration The overall state of the WDFDEVICE and
WDFQUEUE.
Framework Receives a Request and Inserts It on a WDFQUEUE Read, write, device control, and internal device control reque
sts are presented to KMDF drivers through WDFQUEUEs. If the device has previously been defined as a filter device object The framework determines the correct WDFQUEUE into which to
place the arriving WDFREQUEST The framework then checks the dispatch type for the chosen WD
FQUEUE At this point, both a WDFQUEUE and an I/O event processi
ng callback (if the queue dispatch type is not WdfIoQueueDispatchManual) have been chosen
Framework Invokes the Driver's I/O Event Processing Callback Dispatch Type of the Queue
WdfIoQueueDispatchParallel a new request is inserted into a WDFQUEUE configur
ed for parallel dispatching WdfIoQueueDispatchSequential
WDFQUEUEs configured for sequential dispatching provide for only one WDFREQUEST from the queue to be in progress at a time.
WdfIoQueueDispatchManual. Inserting a request into a WDFQUEUE configured for
manual dispatching never results in the framework calling a type‑specific or default I/O event processing callback
Queue State The state of a queue is managed by KMDF drivers and the framew
ork using the following flags: WdfIoQueueAcceptRequests. When set, this flag indicates that the
queue is accepting requests. WdfIoQueueDispatchRequests. When set, this flag indicates that th
e queue is dispatching requests. WdfIoQueueNoRequests. When set, this flag indicates that the que
ue is currently empty. WdfioQueueDriverNoRequests. When set, this flag indicates that al
l requests that have been delivered from this queue to the driver are complete (that is, the driver has no outstanding requests from this queue in progress).
WdfIoQueuePnPHeld – When set, this flag indicates that the queue is not accepting requests due to a Plug and Play or power management event.
decision process used by the framework If the queue’s dispatch type is WdfIoQueueDis
patchManual If the queue’s dispatch type is either WdfIoQu
eueDispatchParallel or WdfIoQueueDispatchSequential
If the queue’s serialization scope is not WdfSynchronizationScopeNone, a lock is identified.
The framework examines the number of requests in progress from the queue
Driver's I/O Event Processing Callback Executes Validating the Arriving Request Processing the Arriving Request Satisfying the Request within the I/O Event Processin
g Callback Initiating a Request on the Device Sending a Request to Another Driver for Processing
Alternatively, a driver might need to create and send one or more requests to another driver Synchronousl Asynchronously, Specifying a Completion Routine Asynchronously, Without Specifying a Completion Routine.
Driver's Interrupt Event Callback Executes Running at device IRQL has several consequenc
es for the driver: Other system processes are blocked when the interru
pt event callback executes, due to its high IRQL. Therefore, the amount of processing performed in this routine should be kept to a minimum.
Very few KMDF or system functions can be called from the driver’s interrupt event callback, again due to its high IRQL. For example, a driver cannot call WdfRequestComplete from its interrupt event callback, because this function must be called at IRQL DISPATCH_LEVEL or below.
Driver's Interrupt Event Callback Executes The typical KMDF driver performs four ba
sic actions in its interrupt event callback: Ensures that its device is interrupting. Saves the reason for the interrupt and/or dat
a from the interrupt. Acknowledges the interrupt. f additional work is required, requests a call
back to its DpcForIsr
Summary This paper describes the major steps that an I/O request from
user mode takes as it is processed by Windows, with the goal of helping you understand the overall flow of an I/O request through the system.
This paper also describes the major steps that a KMDF driver takes to process a WDFREQUEST. These steps are defined by the device type, driver design, WDFQUEUE and dispatching configuration and the device’s synchronization scope.
心得 目前 Windows 系統支援最廣的驅動程式模型,是「視窗驅動模型」( Windows D
river Model , WDM )。 視窗驅動模型提供了包括非同步輸入輸出、分層式驅動程式、隨插即用、電源管理、
視窗管理規範( Windows Management Instrumentation , WMI )等豐富的功能。目前的 Windows 也針對不同類型的裝置(例如儲存裝置、網路裝置、音效裝置等),使用共通的驅動程式模型(稱為 device‑class specific driver models )。不同類型的裝置,先由微軟設計出共通驅動程式模型中的 port driver ,再由硬體廠商負責設計 miniport driver , port driver 和 miniport driver 則為周邊裝置提供完整的驅動力。這種驅動程式模型大大簡化了硬體廠商開發驅動程式的負擔,也縮短了廠商開發的時間。
Reference : http://www.windowstore.com.tw/www/trainning/trainning45.aspx