Figure 2.23 illustrates the device objects that represent the disks and the controller object that represents the disk controller shown previously in Figure 2.13. The “AT” disk driver shown in Figure 2.14 creates these device objects and the controller object by calling I/O support routines.
Figure 2.23 AT Disk Device Objects and Controller Object
This driver creates a device object for each disk, plus some number of logical device objects representing disk partitions. Figure 2.23 happens to show the first disk with one partition and the second with two, but the number of partitions would vary from disk to disk, depending on how different users partition the disk(s) in their respective machines.
Note that this driver’s logical device objects representing disk partitions must be deleted and a new set created if the user repartitions a disk dynamically.
The system “AT” disk driver uses the controller object shown in Figure 2.23 to synchronize I/O operations between the attached disks, so it implements a ControllerControl routine, as shown previously in Figure 2.4.
A controller object is by no means the only mechanism an NT device driver can use to synchronize I/O operations among its physical, logical, or virtual devices. NT supplies drivers with many ways to synchronize I/O operations and to synchronize access to any data or hardware shared by a given driver’s routines. For example, the Kernel-defined event and semaphore objects shown in the next figure, and the spin lock associated with a driver’s interrupt object(s) are three such mechanisms.
While the “AT” disk driver is like the keyboard and auxiliary device port driver (see Section 2.5.2) in handling interrupts for two devices, the disk controller is actually the interrupting device. Consequently, this driver calls the I/O Manager’s interrupt support routine once to register its ISR.
Note that the port driver of a class/port pair is responsible for handling synchronization between (or among) dissimilar devices attached to a device controller, while the class driver(s) can ignore synchronization issues. For example, the keyboard and auxiliary device port driver (see Section 2.5.2) processes IRPs sent independently and at random by both the keyboard and mouse class drivers above it, so the keyboard and auxiliary device port driver must manage the synchronization of operations between the keyboard and mouse devices.