Handling IRPs: Definition 1: IRP as a Container for an I/O Request

Definition 1: IRP as a Container for an I/O Request

The operating system presents most I/O requests to drivers using IRPs. IRPs are appropriate for this purpose because:

·         IRPs can be processed asynchronously.

·         IRPs can be cancelled.

·         IRPs are designed for I/O that involves more than one driver.

 

The IRP data structure packages the information that a driver requires to respond to an I/O request. The request might be from user mode or from kernel mode; regardless of the request’s origin, a driver requires the same information.

Every IRP has two parts, shown in Figure 1:

·         A header that describes the primary I/O request

·         An array of parameters that describe subordinate requests (sometimes called sub-requests)

 

 

Figure 1. Structure of an IRP

The size of the header is fixed and is the same for every IRP. The size of the array of parameters depends on the number of drivers that will handle the request.

Contents of the IRP Header

An IRP is usually handled by a stack of drivers. The header of each IRP contains data that is used by each driver that handles the IRP. While a given driver is handling an IRP, that driver is considered to be the current owner of the IRP.

The header of each IRP contains pointers to the following:

·         Buffers to read the input and write the output of the IRP

·         A memory area for the driver that currently owns the IRP

·         A routine, supplied by the driver that currently owns the IRP, which the operating system calls if the IRP is canceled

·         The parameters for the current sub-request

 

In addition to the pointers, the IRP header contains other data that describes the nature and state of the request.

IRP Parameters

Following the IRP header is an array of sub-requests. An IRP can have more than one sub-request because IRPs are usually handled by a stack of drivers. Each IRP is allocated with a fixed number of such sub-requests, usually one for each driver in the device stack. This number typically matches theStackSize field of the top device object in the stack, though a driver in the middle of a stack could allocate fewer. If a driver must forward a request to a different device stack, it must allocate a new IRP.

Each sub-request is represented as an I/O stack location (a structure of type IO_STACK_LOCATION), and the IRP typically contains one such I/O stack location for each driver in the device stack to which the IRP is sent. A field in the IRP header identifies the I/O stack location that is currently in use. The value of this field is called theIRP stack pointer or the current stack location.

The IO_STACK_LOCATION structure includes the following:

·         The major and minor function codes for the IRP

·         Arguments specific to these codes

·         A pointer to the device object for the corresponding driver

·         A pointer to an IoCompletion routine if the driver has set one

·         A pointer to the file object associated with the request

·         Various flags and context areas

 

The IO_STACK_LOCATION does not contain the pointers to the input and output locations; these pointers are in the IRP itself. All the sub-requests operate on the same buffers.