16.8.1 Registry Paths Supplied to NT Drivers

When its DriverEntry routine is called, each NT driver is given a pointer to a Unicode string specifying a path to a driver-specific key in the registry, along with a pointer to the driver object. Every driver object also contains a pointer to such a string specifying a path to another key in the registry. Figure 16.6 illustrates the registry paths given to NT drivers when they initialize.

Figure 16.6 Registry Paths for NT Drivers

As Figure 16.6 shows, the HardwareDatabase pointer in the driver object and the RegistryPath pointer input to the DriverEntry routine each identify particular keys in the registry. A DriverEntry routine is given read access to the Unicode strings at RegistryPath and HardwareDatabase, but it must call support routines to manipulate registry keys and the configuration information they contain.

Under each key in the registry is either a set of named values with assigned value data or additional subkeys (eventually) with a set of values. The combination of a named value and its corresponding data is called a value entry.

NT provides the following sets of support routines that NT drivers call, depending on how a particular driver gets hardware configuration information and/or uses the registry:

·The I/O Manager supplies the following routines that NT device drivers can call to get hardware configuration information from and to claim bus-relative and device-specific hardware resources in the registry:

·IoQueryDeviceDescription to retrieve hardware configuration information collected by the ARC or NtDetect component and written into the registry by the OS loader

·IoReportResourceUsage to either claim specified hardware resources for one or more devices in the registry or return whether a resource conflict exists

·IoAssignResources to claim a set of configurable (preferred and alternative) hardware resources for a device in the registry and to return information about which resources it claimed for the caller

·The HAL supplies the following routines that device drivers can call to get bus-type-specific hardware configuration information or to claim hardware resources in the registry:

·HalGetBusData to return bus-relative configuration information for the device, if any, at a particular location or slot on an I/O bus, which is equivalent to calling HalGetBusDataByOffset with a zero Offset

·HalGetBusDataByOffset to return bus-relative configuration information, starting at a given offset, for the device, if any, at a particular slot; for a specified nonzero Offset, on a dynamically configurable I/O bus with a published, standard interface

·HalAssignSlotResources to claim hardware resources for the driver of a device at a given slot on a dynamically configurable I/O bus

·The system supplies a number of kernel-mode runtime library routines (Rtl..RegistryXxx) that can be used to query the value entries of keys with names known to the driver, to supply default value entries for "missing" keys, and to modify the value entries of keys.

Drivers that get or set information under the registry keys \Registry\Machine\System\CurrentControlSet\Services\DriverName and/or \Registry\Machine\Hardware\DeviceMap can use the Rtl..RegistryXxx routines. Note that the caller either must "know" the DriverName value or create a subkey under a key with a known name to call these Rtl..RegistryXxx routines.

·The NT Configuration Manager supplies a set of Zw..Key routines that drivers can use to open a registry key with a name known to the driver, to enumerate the immediate subkeys of an open key and get their respective value entries, which always includes the the name of the subkey, to query the value entries for a particular key, or to modify the value entries of keys in the registry.

Some NT device drivers also call IoCreateSymbolicLink to create symbolic links between user- or administrator-supplied names for the driver's device(s) and the corresponding NT device object names. For more information about how to use the Zw..Key routines in conjunction with IoCreateSymbolicLink, see Section 16.9.