Keep the following points in mind when designing an NT driver:
For example, a replacement parallel port or serial driver should create a logical device object for each port. By contrast, a new virtual disk driver that presented every hard disk in the machine as one big disk device could create a single device object to represent its disk, plus some number of device objects representing disk partitions for the file systems layered over such an intermediate driver.
The driver-specific I/O stack location in IRPs can be considered an operation-specific local storage area for some kinds of data.
NT drivers of nonSCSI busmaster DMA devices usually must have an AdapterControl routine and must call the system-supplied support routines that manipulate adapter objects in order to carry out DMA transfers.
The NT SCSI port driver sets up all necessary adapter objects for HBA-specific SCSI miniport drivers.
This driver creates a device-dedicated thread because setting up its device controller for an I/O operation takes so much time (up to 375ms per command byte for up to 9 individually loaded bytes per I/O operation). This driver synchronizes all I/O operations for one or more floppy drives with its device-dedicated thread. The floppy driver queues IRPs to the floppy thread, which waits to complete all operations necessary to carry out each I/O request before starting the next IRP on the floppy controller. In effect, the floppy driver and thread synchronize operations between or among floppy drives by serializing IRPs in the driver’s interlocked queue and processing only one request to completion at a time.
This driver is required to be an NT SCSI class driver. It sends requests to its disks through the NT SCSI port driver to HBAs driving buses with connected disk devices. The NT SCSI port driver is responsible for synchronizing operations for all SCSI class drivers, while the HBAs driving the SCSI buses are responsible for synchronizing hardware operations among peripheral devices on their respective buses.
The NT SCSI port driver creates a set of supplemental device queues to hold IRPs sent down by the higher-level NT SCSI class drivers, in order to manage the synchronization of requests to the SCSI peripheral devices on each HBA’s bus(es). The NT SCSI disk class driver simply sends each IRP down to the NT port driver, using the class/port interface, without having to synchronize operations among its target disks.
Each NT SCSI class driver sets up an IoCompletion routine for IRPs when the driver needs to determine the completion status of any operation it sends down to the NT SCSI port driver. For example, when a class driver must split transfers to suit the limits of a given HBA, the class driver’s IoCompletion routine can track the amount of data actually transferred in each sub-request it makes and free any IRPs and SRBs the class driver allocated for subtransfer requests.
This driver is a monolithic (single-module) driver that uses a controller object to synchronize operations between attached disk devices. This driver programs the device controller and communicates directly only with the controller hardware in order to carry out I/O requests to the physical disks. However, its physical devices might have been managed by a disk class driver layered above a (controller) port driver, instead of by a monolithic driver.
If necessary, an NT driver can create a device-dedicated thread, which can wait on a dispatcher object that the driver’s other routines (except an ISR or SynchCritSection routine) can set to the Signaled state and reset to the Not-Signaled state. As a general guideline, if you expect that your new device driver will often need to stall for longer than 50 microseconds while it waits for device-state changes during I/O operations, consider implementing a driver with a device-dedicated thread. If such a device driver is also a highest-level driver, consider using system worker threads and implementing one or more worker-thread callback routines.