As shown in Figure 16.6, RegistryPath points to the driver-specific key \Registry\Machine\System\CurrentControlSet\Services\DriverName. The value entry of the key DriverName is a Unicode string that identifies the driver, such as “Serial.”
One or more subkeys under each DriverName key include the driver-specific Parameters with value entries needed to load the driver, and can also include one or more subkeys for device-specific Parameters needed to initialize each device a particular NT driver controls.
If an NT device driver needs hardware configuration information that the ARC or NtDetect component cannot “find,” that the driver cannot get from its device, or that the HAL cannot get from the bus, this information should be supplied under the ..\DriverName registry key, so that the driver can get this hardware configuration information from its Parameters key(s) when it is loaded. An NT driver loses its RegistryPath pointer when its DriverEntry routine returns. If a driver-supplied Reinitialize routine uses this path, an NT driver should save the RegistryPath pointer that is input to its DriverEntry routine.
Note that the DriverName value along the RegistryPath string is not necessarily the generic name for a type of physical device like “Serial.” NT drivers generally cannot use this string to create names for their device object(s).
Names for device objects are also Unicode strings but have the form \Device\GenericDeviceTypeDigit, such as \Device\Harddisk1\Partition2, as also discussed in Chapters 4 and 5. However, NT drivers for certain kinds of devices can call IoGetConfigurationInformation to determine the Digit value each driver should append to the name of each device object that it creates to represent a physical device.
Some higher-level NT drivers also might call IoGetConfigurationInformation to determine how many device objects for a particular kind of physical device have been created by lowest-level drivers.
IoGetConfigurationInformation returns a CONFIGURATION_INFORMATION-type pointer to the I/O Manager’s structure. NT device drivers set the following about certain types of physical devices in this structure as these drivers are being loaded:
ULONG DiskCount; // Harddisks already named ULONG FloppyCount; // Floppy drives already named ULONG CdRomCount; // CdRom drives already named ULONG TapeCount; // Tape drives already named ULONG ScsiPortCount; // ScsiPort (HBAs) already named ULONG SerialCount; // Serial ports already named ULONG ParallelCount; // Parallel ports already named BOOLEAN AtDiskPrimaryAddressClaimed; // 0x1f0 - 0x1ff BOOLEAN AtDiskSecondaryAddressClaimed; // 0x170 - 0x17f
Drivers of the preceding kinds of physical devices can use the current value in this global system structure to name their device objects with the correct Digit suffix. For example, if the current value of DiskCount is one, a disk device driver would name its driver-created device objects for two physical disks \Device\Harddisk1 and \Device\Harddisk2. Note that the configuration information counts are one-based while device object Digit suffixes are zero-based values. Such a driver must increment the DiskCount value in the configuration information structure for each device object that it creates to represent a physical disk.
The last two members of the configuration information structure indicate whether either of the bus-relative I/O address spaces used by “AT” disk (WD1003-compatible) controllers is being claimed by the driver. A subsequently loaded disk driver for a device with an “AT-compatible” mode might use this information.
A higher-level NT SCSI class driver can call IoGetConfigurationInformation to determine how many HBAs are present in a particular machine, as well as how many Harddisk, Floppy, CdRom, Tape, Serial, or Parallel devices have already been named. Since SCSI class and filter drivers are loaded after the NT SCSI port and HBA-specific miniport drivers, ScsiPortCount indicates the total number of HBAs in the machine. A SCSI class driver can use the value of ScsiPortCount as a loop-control variable to determine which HBAs drive buses with attached peripheral devices of the class driver’s type. For more information about initializing SCSI drivers, see also Appendix A.