2.5  NT Objects with Device, Configuration, or Layer Dependencies

This section introduces device, adapter, and controller objects by showing the correspondence between these objects and the representative hardware configurations and system drivers shown in Figures 2.5 through 2.18. Note that every driver in the following figures creates at least one device object, except for the video and SCSI miniport drivers. The NT-supplied port driver creates and manages all necessary NT objects on their behalf.

Chapter 3 describes device, adapter, and controller objects separately in some detail, along with all the other NT objects a driver might use or must use, such as interrupt objects for lowest-level NT drivers whose physical devices generate interrupts.

Device Objects and Device Extensions

Each NT driver (except for video and SCSI miniport drivers) must create at least one device object by calling an I/O support routine when the driver is loaded, as already mentioned in Section 2.3. Some NT drivers must create more than one device object: whatever a particular NT driver’s level in a chain of layered drivers, a separate device object represents each physical, logical, and/or virtual device for which the driver handles I/O requests. For the video and SCSI miniport drivers, the corresponding NT port driver creates the necessary device objects.

In other words, the driver object previously shown in Figure 2.4 represents a single NT driver that could have created more than one device object. When it is called, each standard driver routine that is given an IRP is also given a pointer to the target device object for the I/O request. Most NT drivers use the device extension of the target device object to maintain necessary device state information or driver-determined context data about the current I/O request they are processing.

Because most NT device and intermediate drivers execute in an arbitrary thread context (that of whatever thread happens to be current), a device extension is each driver’s primary place to maintain device state and all other driver-specific or device-specific data the driver needs. For example, any NT driver that implements a CustomTimerDpc or CustomDpc routine shown in Figure 2.4 usually provides storage for the required Kernel-defined timer, and/or DPC objects in a device extension.

Every NT driver that has an ISR must provide storage for a pointer to a set of Kernel-defined interrupt objects, and most NT device drivers store this pointer in a device extension. Each NT driver determines the size of the device extension when it creates a device object, and each driver defines the contents and structure of its own device extension(s).

Adapter Objects

Certain other NT objects that drivers use are also configuration-dependent, device-dependent, and/or design-dependent. For example, a lowest-level driver whose device is connected to a system DMA controller (as shown previously in Figures 2.11 and 2.15) must explicitly associate its device object with an adapter object that represents a DMA controller channel to carry out transfer operations. Such a driver provides storage, usually in a device extension, for a pointer to an adapter object and has an AdapterControl routine, as shown in Figure 2.4, that calls system-supplied adapter object support routines to accomplish DMA transfers.

Controller Objects

A lowest-level driver for a set of similar devices coordinated by a physical controller, such as the “AT” disk controller shown in Figure 2.13, can create a controller object and use it to synchronize I/O operations between the attached devices. Such a driver implements a ControllerControl routine, as shown in Figure 2.4, and calls the I/O Manager’s controller object support routines.