发布时间：2013-8-18 20:21
分类名称：Driver
From: <Programming the Microsoft Windows Driver Model 2nd>
Plug and Play device
A Plug and Play device has an electronic signature that the system can detect. For Plug and Play devices, a system bus driver detects the existence of the hardware and reads the signature to determine what kind of hardware it is. Thereafter, an automatic process based on the registry and INF files allows the system to load the right driver.
When a bus driver detects the insertion or removal of hardware, it calls IoInvalidateDeviceRelations to notify the PnP Manager that the bus's population of child devices has changed. To obtain an updated list of the PDOs for the child devices, the PnP Manager sends an IRP to the bus driver. The major ?function code for this IRP is IRP_MJ_PNP, and the minor function code is IRP_MN_QUERY_DEVICE_RELATIONS, with a code indicating that the PnP Manager is looking for the so-called "bus" relations.
In response to the bus relations query, the bus driver returns its list of PDOs. The PnP Manager can easily determine which of the PDOs represent devices that it hasn't yet initialized. Let's focus on the PDO for your hardware for the time being and see what happens next.
The PnP Manager will send another IRP to the bus driver, this time with the minor function code IRP_MN_QUERY_ID. In fact, the PnP Manager sends several such IRPs, each with an operand that instructs the bus driver to return a particular type of identifier. One of the identifiers, the device identifier, uniquely specifies the type of device. A device identifier is just a string, and it might look like one of these examples:
PCI\VEN_102C&DEV_00E0&SUBSYS_00000000
USB\VID_0547&PID_2125&REV_0002
PCMCIA\MEGAHERTZ-CC10BT/2-BF05
The PnP Manager uses the device identifier to locate a hardware key in the system registry. For the moment, let's assume that this is the first time your particular device has been plugged into the computer. In that case, there won't yet be a hardware key for your type of device. This is where the setup subsystem steps in to figure out what software is needed to support your device.
Installation instructions for all types of hardware exist in files with the extension .INF. Each INF contains one or more model statements that relate particular device identifier strings to install sections within that INF file. Confronted with brand-new hardware, then, the setup subsystem tries to find an INF file containing a model statement that matches the device identifier. It will be your responsibility to provide this file, which is why I labeled the box You that corresponds to this step.
When the setup subsystem finds the right model statement, it carries out the instructions you provide in an install section. These instructions probably include copying some files onto the end user's hard drive, defining a new driver service in the registry, and so on. By the end of the process, the setup program will have created the hardware key in the registry and installed all of the software you provided.
Now step back a few paragraphs and suppose that this was not the first time this particular computer had seen an instance of your hardware. For example, maybe we're talking about a USB device that the user introduced to the system long ago and that the user is now reattaching to the system. In that case, the PnP Manager would have found the hardware key and would not have needed to invoke the setup program. So the PnP Manager would skip around all the setup processing to point 5 in Figure.
At this point, the PnP Manager knows there is a device and that your driver is responsible for it. If your driver isn't already loaded in virtual memory, the PnP Manager calls the Memory Manager to map it in. The system doesn't read the disk file containing your driver directly into memory. Instead, it creates a file mapping that causes the driver code and data to be fetched by paging I/O. The fact that the system uses a file mapping really doesn't affect you much except that it has the side effect of making you be careful later on about when you allow your driver to be unmapped. The Memory Manager then calls your DriverEntry routine.
Next the PnP Manager calls your AddDevice routine to inform your driver that a new instance of your device has been discovered. Then the PnP Manager sends an IRP to the bus driver with the minor function code IRP_MN_QUERY_RESOURCE_REQUIREMENTS. This IRP is basically asking the bus driver to describe the requirements your device has for an interrupt request line, for I/O port addresses, for I/O memory addresses, and for system DMA channels. The bus driver constructs a list of these resource requirements and reports them back.
Finally the PnP Manager is ready to configure the hardware. It works with a set of resource arbitrators to assign resources to your device. If that can be done—and it usually can be—the PnP Manager sends an IRP_MJ_PNP to your driver with the minor function code IRP_MN_START_DEVICE. Your driver handles this IRP by configuring and connecting various kernel resources, following which your hardware is ready to use.
legacy device
A legacy device does not have any electronic signature, so the system can't detect it automatically. The end user must therefore initiate the "detection" process by invoking the Add New Hardware Wizard, which ends with the system knowing that a certain new piece of hardware exists. Thereafter, the system uses the same automatic registry-and-INF-file process that's used for Plug and Play devices to load the right driver.
The setup program follows the instructions in the install section by creating registry entries for use by the root enumerator. The registry entries might include a logical configuration that lists the I/O resource requirements for the device (point 3).
Finally the setup program instructs the end user to restart the system (point 4). The designers of the setup system expected that the end user would now need to follow the manufacturer's directions to configure the card by setting jumpers or switches and would then need to insert the card into an expansion slot of a powered-down computer.
Following the restart (or following the end user's decision to bypass the restart), the root enumerator will scan the registry and find the newly added device. Thereafter, the process of loading your driver is nearly identical to that for a Plug and Play device.
Recursive Enumeration
In the preceding sections, I described how the system loads the correct driver for a single device. That description begs the question of how the system manages to load drivers for all the hardware in the computer. The answer is that it uses a recursive process.
In the first instance, the PnP Manager invokes the root enumerator to find all hardware that can't electronically announce its presence—including the primary hardware bus (such as PCI). The root bus driver gets information about the computer from the registry, which was initialized by the Windows XP Setup program. Setup got the information by running an elaborate hardware detection program and by asking the end user suitable questions. Consequently, the root bus driver knows enough to create a PDO for the primary bus.
The function driver for the primary bus can then enumerate its own hardware electronically. When a bus driver enumerates hardware, it acts in the guise of an ordinary function driver. Having detected a piece of hardware, however, the driver switches roles: it becomes a bus driver and creates a new PDO for the detected hardware. The PnP Manager then loads drivers for this device PDO, as previously discussed. It might happen that the function driver for the device enumerates still more hardware, in which case the whole process repeats recursively. The end result will be a tree like that shown in the following Figure, wherein a bus-device stack branches into other device stacks for the hardware attached to that bus. The dark-shaded boxes in the figure illustrate how one driver can wear an "FDO hat" to act as the function driver for its hardware and a "PDO hat" to act as the bus driver for the attached devices.
