IRP request processing and completion Mechanism

I have recently learned about the Windows Kernel and feel that I/O processing is not a general concept. Therefore, it took a long time to collect a lot of knowledge in this area.

Requests in the Windows Kernel are basically completed through I/O request packet. As mentioned above, the device object is the only entity that can accept the request. Next, let me explain in detail how IRP requests are completed step by step.

First, we need to know how IRP is generated. The IRP is sent by the I/O manager, and the I/O manager is a bridge between the user State and the kernel state. When the user State process sends an I/O request, the I/O manager captures these requests, converts them to IRP requests, and sends them to the driver. I/O manager is undoubtedly very important and has a core position. It schedules and manages all I/O requests, selects the corresponding driver object and device object based on different request content, and generates, sends, and releases various IRPs. The entire I/O processing process is completed under its command.

An IRP is a variable size structure allocated from non-Paging memory. It consists of two parts: the IRP header and the auxiliary request parameter array, as shown in 1. These two parts are created by the I/O manager.

 

 

Figure 1 Structure of IRP

The IRP header contains the pointer to the IRP input and output buffer, and the driver pointer with the IRP current.

Next, the header is an array of the io_stack_location structure. Its size is determined by the number of devices in the device stack (the concept of the device stack will be described below ). The io_stack_location structure stores the parameters and code of an I/O Request, the device pointer corresponding to the request, and the iocompletion pointer.

Where can I send IRP requests generated by the I/O manager? Here we will talk about the concept of device stack. The operating system uses a device object to represent a physical device. Each physical device has one or more Device objects associated with it, the device object provides all operations on the device. Some device objects do not represent physical devices. A software-only driver that processes I/O requests, but does not pass these requests to hardware, must also create a device object that represents its operations. A device is often represented by multiple device objects. Each device object corresponds to a driver in the driver stack to manage the device's I/O requests. All Device objects of a device are organized into a device stack ). In addition, each element in the io_stack_location array corresponds to each device in the device stack. Generally, only each device object in the hierarchy can access its own io_stack_location. At any time, a request operation is completed on a device. The I/O manager sends the IRP request to the driver of the device on the top of the device stack (the IRP is passed to the device object, find the driver through the driverobject Member of the device object ). The driver accesses the Element check parameters of the corresponding device object in the io_stack_location array of the IRP to determine what operations to perform (by checking the majorfunction field in the structure, determine what operations to perform and how to interpret the content of the parameters shared body field ). The driver can process the data according to the majorfunction field in the io_stack_location structure. Each driver can either process or pass it to the driver of the next device object in the device stack.

To transmit an IRP request to a driver on the underlying device, follow these steps:

1. Set parameters for the next io_stack_location structure. You can use either of the following methods:

· Call iogetnextirpstacklocation to obtain the pointer of the next structure, and then assign a value to the parameter;

· Call iocopycurrentirpstacklocationtonext (if iocompletion function is set for the driver in step 2) or call ioskipcurrentirpstacklocation (if iocompletion function is not set for the driver in step 2) to pass the current parameter to the next one.

2. If necessary, call the iosetcompletionroutine function to set iocompletion for subsequent processing.

3. Call the iocalldriver function to pass the IRP request to the next driver. This function automatically adjusts the IRP Stack pointer and executes the dispatch function of the next driver.

When the driver passes the IRP request to the next driver, it no longer has access to the request. Forced access will cause the system to crash. If the driver still wants to access the request after it is passed, you must set the iocompletion function. IRP requests can be completed or canceled in other drivers or other threads.

When a driver calls the iocompleterequest function, the I/O operation is complete. This function allows the stack pointer of IRP to move up a position, as shown in Figure 2:

 

Figure 2 move the stack pointer when the IRP completes

Figure 2 shows the I/O stack situation after the C driver calls the iocompleterequest function. The solid-line arrow on the left indicates that the treasure pointer now points to the parameters and callback functions of drive B; the dotted-line arrow is the previous case. The hollow arrow on the right specifies the sequence in which the iocompletion function is called.

If the iocompletion function is set before the driver sends an IRP request to the underlying device in the device stack, the iocompletion function is called by the I/O manager.

The iocompletion function returns two types of values:

(1) status_continue_completion: tells the I/O manager to continue executing the iocompletion function of the Upper-layer driver.

(2) status_more_processing_required: tells the I/O manager to stop running the upper-layer driver and stops the stack pointer at the current position. When the precursor calls the iocompleterequest function, it continues to execute the iocompletion function driven by the upper layer.

When all the drivers have completed their corresponding sub-requests, the I/O request is over. I/O Manager updates the status information from IRP> iostatus. Status, and updates the number of transmitted bytes from IRP> iostatus. Information.

The writing is too hasty. If there are any mistakes, I hope you will give me some advice!

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/vangoals/archive/2009/07/20/4363863.aspx