 [oR]
I/O Processing Sequence It is important to understand the complete life cycle of an I/O request. This section describes the flow of a request from user-mode code to I/O Manager to device driver. An I/O request goes through several stages during its life. -
Preprocessing by the I/O Manager -
Preprocessing by the device driver -
Device start and interrupt service -
Postprocessing by the driver -
Postprocessing by the I/O Manager The following sections describe the stages in more detail. Preprocessing by the I/O Manager This phase performs device-independent preparation and verification of an I/O request. -
The Win32 subsystem converts the request into a native system service call. The system service dispatcher traps into kernel mode and into the I/O Manager. -
The I/O Manager allocates a data structure known as an I/O Request Packet (IRP). The next chapter describes an IRP in more detail, but an IRP can be thought of as a work order presented to a driver and its device. The IRP is filled with necessary information, including a code which identifies the type of I/O request. -
The I/O Manager performs some validation of the arguments passed with the request. This includes verifying the file handle, checking access rights to the file object, ensuring that the device supports the requested function, and validating the user buffer addresses. -
If the device requests a buffered I/O (BIO) operation, the I/O Manager allocates a nonpaged pool buffer, and for a write request, copies data from user space into the system buffer. If the device requests direct I/O (DIO), the user's buffer is locked down and a list of page descriptors is built for use by the driver. -
The I/O Manager invokes the appropriate driver dispatch routine. Preprocessing by the Device Driver Each driver builds a dispatch table of entry points for each supported I/O function request. The I/O Manager uses the function code of the I/O request to index into this table and invoke the appropriate driver Dispatch routine. The routine performs the following tasks: -
It performs additional parameter validation. The device driver can detect device-specific limitations unknown to the I/O Manager. For example, a user might request a data transfer size in violation of the capabilities of a specific device (or driver). -
If the request can be handled without device activity (e.g., reading zero bytes), the Dispatch routine simply completes the request and sends the IRP back to the I/O Manager, marked as complete. -
If (as is usual) device operation is required, the Dispatch routine marks the request (IRP) as pending. The I/O Manager is instructed to queue a call to the driver's Start I/O routine as soon as the device is free. (It is possible the device is handling a previous request.) Device Start and Interrupt Service Data transfers and other device operations are managed by the driver's Start I/O and Interrupt Service routines. START I/O When a Dispatch routine requests that the I/O Manager start a device, the I/O Manager first checks to see whether a device is already busy. The I/O Manager detects this condition by checking whether or not there is an IRP outstanding for the device (i.e., still marked as pending). If so, it queues the request to start the device. Otherwise, the driver's Start I/O routine is called directly. The Start I/O routine performs the following tasks: -
It checks the IRP function (read, write, etc.) and performs any setup work specific to that type of operation. -
If the device is part of a multifunction controller, a ControllerControl routine requests exclusive ownership of the controller hardware. -
If the operation requires DMA, an AdapterControl routine requests exclusive ownership of the appropriate DMA channel hardware. -
It uses a SynchCriticalSection routine to safely access device registers and start the device. -
It returns control to the I/O Manager and awaits a device interrupt. ISR When an interrupt occurs, the kernel's interrupt dispatcher calls the driver's ISR. The ISR would typically perform the following steps: -
Check to see if the interrupt was expected. -
Dismiss the hardware device interrupt. -
If programmed I/O was in progress and the total data transfer was still incomplete, the ISR would start another byte or word of data and await another interrupt. -
If DMA was in progress and more data remained to be transferred, a DPC would be scheduled to set up the DMA hardware for the next chunk of data. -
If an error occurred or the data transfer was complete, a DPC would be queued to perform postprocessing at a lower IRQL. Postprocessing by the Driver The kernel's DPC dispatcher eventually calls the driver's DPC routine to perform the driver's postprocessing chores. These would typically include -
If a DMA operation just occurred and more data remains to be transferred, it sets up the DMA hardware, starts the device, and waits for another interrupt. It then returns to the I/O Manager with the IRP left as pending. -
If there was an error or timeout, the DPC routine might record the event and then either retry or abort the I/O request. -
It releases any DMA and controller resources being held by the driver. -
The DPC routine puts the size of the transfer and final status information into the IRP. -
Finally, it tells the I/O Manager that the current request has completed by marking the pending IRP as complete. This instructs the I/O Manager to restart the device (by calling Start I/O) with the next IRP, if one is waiting. Postprocessing by the I/O Manager Once the driver's DPC marks an IRP as complete, the I/O Manager performs cleanup operations. These include -
If this was a buffered I/O write operation, the I/O Manager releases the nonpaged pool buffer used during the now completed transfer. -
If this was a direct I/O operation, it unlocks the user's buffer pages. -
It queues a request to the original requesting thread for a kernel-mode asynchronous procedure call (APC). This APC will execute I/O Manager code in the context of the requesting thread. -
When the kernel-mode APC runs, it copies status and transfer-size information back into user space. -
If this was a buffer I/O read operation, the APC copies the contents of the nonpaged pool buffer into the caller's original user-space buffer. It then frees the system buffer. -
If the original request was for a Win32 overlapped operation, the APC routine sets the associated event and/or file object into the signaled state. -
If the original request included a completion routine (e.g., ReadFileEx), the APC schedules a user-mode APC to execute the completion routine. Figure 3.2 shows a summary of the I/O processing sequence just described. Figure 3.2. Life cycle of an I/O request.  |
