Section 1.4. Windows Device DriverRelated Data Structures | Inside Windows Storage: Server Storage Technologies for Windows 2000, Windows Server 2003 and Beyond

1.4 Windows Device Driver “Related Data Structures

Before we consider the details of Windows NT device drivers, it will be advantageous to understand some important data structures that these drivers use. Every Windows driver, including storage drivers, must deal with three major types of objects: driver objects, device objects, and I/O request packets. These objects are described in Sections 1.4.1 through 1.4.3.

1.4.1 Driver Objects

A driver object is created by the Windows NT Executive when a driver is loaded. The driver object is allocated from nonpageable memory. A driver object contains important information, such as the driver dispatch table that identifies addresses for various driver routines. Each driver has only one driver object, even when the driver is controlling multiple devices. Even when a driver runs on multiple CPUs on a multiprocessor Windows NT system, there is only one driver object in memory. Although the driver object is created by the Windows NT Executive, it is the responsibility of the driver writer to fill out some details, such as the routine addresses in the driver dispatch table. This requirement applies only to drivers that export a driver object; therefore minidrivers that rely on the class or port driver's object are not required to enter these object details.

1.4.2 Device Objects

A device object represents a physical I/O device (e.g., host bus adapter, disk, or tape device) or a logical device (e.g., a virus-checking filter driver). Each device can have only one device object. A device object contains a pointer to the driver object that handles processing of this device. A device object also describes physical characteristics of the device ”for example, the largest amount of I/O that can be done in a single operation, or the unit on which the buffer supplied to a device must be aligned.

The three kinds of device objects share the same basic device object structure, but they differ in device object extensions and in how they are used. The three kinds of device objects are

The physical device object ( PDO ), which represents a device on a bus. PDOs are typically created by a bus driver (bus drivers are explained in Section 1.7.1). A PDO is required to communicate with the device. Examples of data kept in the PDO are device power state and device identity ”for example, SCSI bus identifier, SCSI target identifier, and SCSI logical unit number (LUN). These SCSI terms are explained in Chapter 2. For now, suffice it to say that to uniquely identify a SCSI device, you need to specify three values: bus, target, and LUN identifiers.
The functional device object ( FDO ), which is typically created by a class or port driver (class and port drivers are discussed in Sections 1.7.2 and 1.7.3). Use of a device requires an FDO. Examples of data kept within an FDO include details of disk organization ”for example, a disk partition table and, if the disk is a DVD, the region information about a DVD.
The filter device object ( DO ), which represents a device to a filter driver.

Figure 1.3 shows some significant parts of a driver object.

Figure 1.3. Windows NT Driver Object

graphics/01fig03.gif

One important part of the driver object is the driver dispatch table. The driver dispatch table defines various standard functions that a driver implements. Depending on the exact nature of the driver, some of these functions must be implemented by the driver, and some may optionally be implemented by the driver. Figure 1.3 shows only the Read, Write, and DeviceIoControl functions, but there are many more, and curious readers may obtain more details from the Windows Driver Development Kit.

Devices for which a driver implements functionality are described by device objects (PDO, FDO, or DO), and all the devices for which a driver provides functionality are kept in a linked list. The head of the linked list is kept in the driver object, as shown at the bottom left of Figure 1.3. Note that because device objects (PDOs, FDOs, DOs) contain a pointer to the driver device object, one can walk the data structure, locate the driver object, and from the dispatch table inside that driver object, invoke the appropriate driver function.

1.4.3 I/O Request Packets

Windows NT is a layered operating system that uses a packet-based interface to communicate with kernel mode drivers. These packets, which are used to communicate with drivers, are referred to as I/O request packets , or IRPs . The communication with a driver could come from another driver or from the I/O subsystem.

IRPs are allocated from nonpageable memory. Nonpageable memory is a precious system resource. IRPs are allocated and maintained on a thread-specific queue. Windows NT maintains some IRPs ready and allocated on a lookaside list ^[3] so that they may be quickly assigned to a driver or the I/O Manager when requested .

^[3] The term lookaside list is a generic phrase used to refer to a situation in which something of importance (e.g., an IRP) is maintained in a separate list and may be readily moved from that list to another list (e.g., the list of IRPs attached to a particular thread).

As Figure 1.4 shows, IRPs have a fixed- size header and a variable number of I/O stack locations. The I/O stack locations represent data structures for individual drivers that will process the IRP. That is, each driver that processes an IRP gets its own private data area in the IRP stack. When an IRP is allocated and sent to a driver, sufficient stack locations are needed for each driver that will handle the IRP. A driver attempting to access a nonexistent IRP stack location will cause a system error. Thus an IRP that works for one driver stack chain may or may not be reused for another driver stack chain.

Figure 1.4. IRP Structure

graphics/01fig04.gif

As shown in Figure 1.4, the IRP header consists of various kinds of information, such as

Whether the request is synchronous or asynchronous
Whether the request is a paging I/O operation or an operation that should be done with no intermediate caching
A buffer pointer for I/O operations
An I/O status block representing the current status of the IRP, which changes as the IRP is handled by various drivers
Information needed to handle IRP cancellation, in case an I/O operation specified by an IRP is canceled (for example, because of a timeout or because the user decides it is taking too long)
An indication of whether the I/O request originated in user mode or kernel mode

Figure 1.4 also shows that each IRP stack location consists of information that is specific to a particular driver. Here are some examples of information within the stack location:

Major function code (such as read, write, and device control operation)
Minor function code that specifies more precisely what needs to be done and that is applicable for only some major function codes
Function-specific parameters such as parameters for device control
Pointer to file object

The IRP structure contains an element that indicates which is the current IRP stack location. A driver is responsible for manipulating this element before passing the IRP to the next driver in the chain. Each active IRP is put on a thread-specific queue that contains the IRPs associated with I/O initiated by that IRP.

A driver may create secondary IRPs in response to an IRP that it receives. The advantage is that the secondary IRPs may be simultaneously handled, in a somewhat parallel fashion, thus speeding up the I/O process. Of course, there are limitations here; for example, write operations to a tape device cannot be broken into multiple write operations that are handled in parallel.

Top