43. Windows Driver Model notes (1)

1. Generally, the driverProgramI/O requests should be processed asynchronously in the context of some unpredictable threads. We use the term arbitrary thread context to describe the context on which the driver does not know (or care about) the context of the current execution of the processor.

2. Windows 2000 uses the symmetric multi-processor model, that is, all the processors are the same, and system tasks and user-mode programs can be executed on any processor, all processors access the memory equally. The existence of multi-processor brings a difficult synchronization problem to the device driver, becauseCodeShared data or hardware resources may be accessed at the same time. Windows 2000 provides a synchronization object, spin lock, which can be used by the driver to solve the synchronization problem of multi-processor.

3. When the CPU runs at passive_level, the currently running thread can be preemptible by any thread with a higher priority. However, once the cpu irql level is greater than passive_level, the thread will no longer be preemptible. At this time, the CPU is executed in any thread context that causes the CPU to cross the passive_level level. However, any activities running at the IRQL level can be interrupted by activities at the higher IRQL level. Therefore, the driver must assume that the control may be lost at any time, and the system may need to execute more basic tasks at this time.

4. To achieve configurability, you should first avoid directly referencing hardware in the code, even in the Conditional compilation block related to the platform. You should use Hal tools or call low-level bus drivers, or implement a standard or custom control interface and interact with users through the control panel program. In addition, Windows WMI controls should be supported, which allow users and administrators to configure hardware features in a distributed enterprise environment. Finally, the registry should be used as the database for configuration information, which can make the configuration information still exist after the system restarts.

5. To achieve this portability, drivers should all be written in C and only use the language elements specified by the ansi c standard. Avoid using compiler vendor proprietary language features, and avoid using Runtime library functions that are not output by the operating system kernel (See Chapter 3 ). If the platform dependency in the driver cannot be avoided, at least use the Conditional compilation command to isolate the code.

6. You can regard a complete driver as a container, which contains many routines. When the operating system encounters an IRP, it calls the routines in the container to execute various operations on the IRP.

A complete driver can be seen as a container, which contains many routines. When an IRP is encountered by the operating system, it calls the routines in the container to execute various operations on the IRP. Some routines, such as DriverEntry and adddevice, and dispatch functions corresponding to several IRPs will appear in each of these containers. You needThe queued drivers generally have a startio routine. The driver that executes DMA transmission should have an adaptercontrol routine. For most devices that can generate hardware interruptions, their drivers have an interruption service routine (ISR) and a delay process call (DPC) routine. Drivers generally have several dispatch functions that support different types of IRPs. Three of them are required. Therefore, a task of the WDM driver developer is to select the required routine for this container.

Figure 21 1-5Content in the WDM driver "Container"

7. There are three registry keys for configuration. They are hardware keys, class keys, and service keys. It must be clear that these names (hardware, class, and service) are not specific subkeys: they are the general names of these three keys, the specific path name depends on the device to which they belong. Generally, a hardware key contains the information of a single device. A Class key involves the common information of all devices of the same type. A service key contains the driver information. Sometimes "instance keys" and "software keys" are used to represent hardware keys and service keys.

The hardware key of the device appears on the \ SYSTEM \ CurrentControlSet \ Enum sub-Key of the Local Machine branch of the Registry.

Applications often need to access information about hardware devices in the registry. To make this possible without exposing an important Enum key, Microsoft provides a set of setupdixxx functions.

The symbolic connection name of the device interface (by enumerating all instances of the guid or obtaining the name from the parameter of the wm_devicechange message ). Classguid is the ASCII format of The GUID (globally unique identifier) of the device class. In effect, it is a pointer to the device class key. The service points to the service key.

Class keyThe class keys of all device classes are displayed in the HKLM \ System \ CurrentControlSet \ Control \ class keys. Their key names are guid values assigned by Microsoft.

Service (or software) KeyThe last key that is important to the device driver is the service key. It specifies the location of the driver execution file and some parameters that control the driver loading. The service key is located in the HKLM \ System \ CurrentControlSet \ Services Key.

When I say that the system "loads" A driver, it means that the system maps the driver image to the virtual memory, relocates the memory reference, and finally calls the main entry point of the driver. The main entry point is usually named DriverEntry. I will introduce the DriverEntry function later in this chapter. If the driver is already in memory, the loading process only increases the reference count of the driver image.

8. The loading sequence of the driver is not very important. The system calls the adddevice function of the driver in the order that the PnP Manager loads the driver, which is exactly the same as the order in which the device object appears in the device stack.

Figure 2-2 Device recursive enumeration process

Figure 2-2 shows a tree structure composed of multiple device stacks, but this does not mean that the IRP must flow from the PDO layer to the Fido layer. In fact, the PDO driver of a stack is the fdo driver of the next stack. See the shadow block in Figure 2-2. When the driver receives an IRP as a PDO role, it performs some operations on the IRP but does not send this or other IRPs to the device (with the fdo role ). On the contrary, when the bus driver receives an IRP as the fdo role, it may need to send some IRP (with the PDO role) to the device ).

Figure 2-8Process of reading requests from devices (on the second-level bus)