1.2.6  Packet-driven I/O with Reusable IRPs

The I/O Manager’s chief job is to accept I/O requests (usually from user-mode applications), to create IRPs to represent them, to route the IRPs to the appropriate NT drivers, to track them until they are completed, and to return status to the original requestor of each I/O operation. The I/O Manager uses IRPs to communicate with NT drivers and to allow NT drivers to communicate with each other.

Note that some IRPs might be routed to more than one NT driver. For example, a request to open a file on a disk might go first to a file system driver, through an intermediate mirror driver, and ultimately to a physical disk driver, as implied in Sections 1.1 and 1.2.2.

Therefore, each IRP has a fixed part and one or more driver-specific I/O stack locations:

·In the fixed part (or header), the I/O Manager maintains information about the original request, such as the caller’s parameters, the address of the device object on which a file is open, etc. The fixed part also contains an I/O status block, in which drivers set information about the status of the requested operation.

·In the highest-level driver’s I/O stack location, the I/O Manager sets driver-specific parameters, such as the particular operation requested (represented as function codes) and context used by the corresponding driver to determine what it is supposed to be doing. In turn, each higher-level NT driver sets up the I/O stack location of the next-lower-level driver, if any.

As a given IRP is processed through each NT driver’s set of standard routines, each routine can access that driver’s I/O stack location in the IRP, thereby reusing the IRP at each stage of the driver’s operations. In addition, higher-level NT drivers can create (or reuse) IRPs to send requests down to lower-level drivers.

For an overview of the processing of IRPs through layered drivers, see Chapter 2. For device-type-specific information about IRPs, see the Kernel-mode Driver Reference.