Introduction to the WDM Driver Model Framework

I just read "windows driver development technology details" a few days ago. When I saw this article on the internet, I thought it was a good summary, So I sorted it out and added it to my favorites!

========================================================== ========================

Past and present of WDM drivers

In October 06, 2012, the windows driver development workshop had a total of 2710 characters.

The WDM driver was quite new around 2000. I believe many people are just like me and are very interested in it, but cannot find a learning starting point. The reason is that WDM is a very "Die-board" program. It runs at ring 0 on the bottom of the Windows system and provides various interfaces for application calls. Because of this, it is not like a common Windows application, it can be quickly put to the ground-more often, you are reading its Windows technical information and a variety of Windows interface information, you need to be very familiar with the working principle of the underlying Windows system. Otherwise, if you are not careful, you will be "blue screen". However, when writing a Windows Driver, it is common to crash.

Therefore, many people are afraid of WDM drivers. As a matter of fact, when I first started learning WDM, I had read books for three days at home, but after reading the books, it seemed that I could not do much without reading them. I still don't know how to get started with the WDM driver, I don't even know how to write a "hello World. It was later that we realized that the WDM driver did not have the so-called "Hello World" program at all. It was a hard nut to crack, mainly because there was too little information about the WDM driver on the network at that time, the reason is that WDM is used for large-scale applications after Win2000. Next we will talk about the past and present of the WDM driver.

Past and present WDM drivers

The WDM (Windows Driver Model) model is developed from the kernel-mode device drivers of winnt3.51 and winnt4. The main change in WDM is the addition of plug-and-play, power management, Windows Management Interface (Wmi), and device interface support. The main objective of the WDM model is to achieve cross-platform use, more secure, more flexible, and simpler programming of Windows Device Drivers. WDM adopts the object-based technology and establishes a layered driver structure.

WDM is first implemented in Windows 98 and further improved in windows. It will exist in subsequent Windows operating systems, such as Windows ME and Windows XP. With the introduction of the WDM model, Microsoft hopes to reduce the difficulty and cycle of device driver development and gradually standardize the development of device drivers. It should be said that WDM will become the mainstream of device drivers in the future.

The value of Windows cross-platform compatibility

The development history of Windows Device Drivers Microsoft has released many "Windows" operating systems, from windows3.0 to Windows2000 and Windows XP. Some underlying technologies have been shared under various "Windows" platforms, while other technologies have greatly changed with different versions. One of the goals of Microsoft's Win32 API release is to encourage developers to develop compatible applications between Windows platforms.

Because the device driver interacts with the features at the lowest layer of the operating system, to achieve cross-platform compatibility, you must first be compatible with the underlying structure of different platforms. The basic structure of windows3.0 has continued to the Windows9x family. Although the operating system has changed a lot in driver development and management, the basic structure of the underlying layer has not changed. That is to say, a device driver developed for windows can be used on Windows 95 and Windows 98 without modification in most cases. In Windows 3.x, Windows 95, and Windows 98, Virtual Device Driver (VxD) is used.

The Virtual Device Driver was originally designed to support devices on the Windows platform. It is linked to the operating system as a dynamic connection library (DLL, working in protection mode (RING 0 ). Vxds solves the tasks that cannot be completed by conventional applications, such as direct hardware read/write. It can also be said that VxD is a way to expand the operating system kernel. Vxds was originally written in Intel assembly language. Later, with the use of VtoolsD, C and C ++ became popular.

Design goals of Windows NT

The Design of Windows NT reflects a more modern and modular internal system. Its goal is to improve flexibility and robustness, and its compatibility with Windows 3.x and Windows 9x is not its design goal. Therefore, windows NT's internal system does not provide compatibility with previous Windows platforms. NT adopts a unique kernel-mode driver system, which is generally written in C language.

When the driver in NT needs to directly control the machine, it sends a request to the hardware abstraction layer (HAL. The hardware abstraction layer is built between the driver and the actual hardware, hiding the hardware differences for the driver so that cross-processor (such as Pentium and alpha) can be compiled), source code compatible device drivers. Because Windows NT can work in a single processor and multi-processor environment, the driver must be very careful to protect critical data structures. Windows NT provides a hierarchical architecture. Each NT device driver has a low-layer interface and an upper-layer interface. Low-layer drivers directly control hardware. The middle-layer driver is used between the lower-layer and upper-layer drivers. Windows NT also defines a type of Driver System and supports certain device classes. For example, there are scsi drivers in the system that support SCSI tape devices and SCSI disks. The driver system of Windows NT has been inherited and extended in Windows 98 and Windows 2000, forming the current WDM System.

Recognizing the value of cross-platform compatibility, Microsoft began to try to unify the device system and provide a simple platform for future driver development. Microsoft's approach is not to re-develop a new system, but to make necessary improvements on the basis of a more reasonable Windows NT System to form a new device driver system, known as the Windows Driver Model or WDM, Microsoft also used the Win32 driver model name in earlier technical documents. Windows 98 was the first to support WDM, while Microsoft later introduced the operating systems that also support WDM, including Windows 2000 Series, Windows ME, Windows XP, but not Windows CE.

Introduction to WDM driver Models

The WDM model mainly uses a layered method to imitate the object-oriented technology. According to Microsoft's consistent ideas, it first implements a logical "layered" approach ", then, the standard implementation and lower-layer details are "encapsulated" to form a "base class". The customer program extends the "base class" function through "inheritance, complete the required implementation. In Microsoft's technical literature, Windows NT and Windows 2000 are called "Object-based" systems, just like operating systems, the WDM Driver Model is also an object-based system.

We know that in the system, both objects and classes and inheritance mechanisms are used, and objects can only communicate with each other by passing messages, this method is called "object-oriented method ". If you only use objects, this method can be called an object-based method. Although the "Object-based" method cannot obtain all the advantages of "Object-Oriented", it can still make the system design, analysis and understanding clearer.

The WDM model contains a lot of content. Next we will mainly discuss two main aspects of the WDM model: the driver type and the hierarchical driver structure, so as to discuss the WDM model. In fact, as long as you have a good understanding of these two aspects, you can quickly master WDM.

2.1 driver type

In the WDM model, each hardware device has at least two drivers: one function driver and one bus driver ). A device may also have a filter driver to change the behavior of a standard device driver. These drivers that serve the same device form a linked list called the device stack.

Bus driver

Bus drivers are actually I/O bus services, such as IEEE 1394. In the definition of WDM, a bus is a device used to connect other physical, logical, and virtual devices. The bus includes traditional bus SCSI and PCI, and also includes the parallel port, serial port, and i8042 port. Microsoft has provided bus drivers for Windows operating systems. The bus driver is already included in the operating system, so you do not have to install it. A bus driver is responsible for the following:

• Enumerate the devices on the bus;
• Reports dynamic events on the bus to the operating system;
• Responds to I/O requests for plug-and-play and power management;
• Provides multi-channel access To the bus (for some bus );
• Manage the devices on the bus;

The function driver is the main driver of a physical device. It implements the specific functions of the device, which is generally compiled by the device manufacturer. Function drivers provide interfaces for device operations, read and write operations for devices, manage device power policies, and filter drivers, when a user needs to change or add new features to a device, a type of device, or a bus, he can write a filter driver. In the device stack, the filter driver is installed on or below one or more device drivers.

Filter Driver

Filter the requests of specific devices, devices, and buses by the driver to modify the behaviors of devices or add new functions. However, the filter driver only processes the I/O requests it cares about. Other requests can be handled by other drivers, which can change the behavior of devices flexibly, at least the user will see it like this. For example, the upper-layer filter driver of a USB keyboard can force an additional security check.

A low-layer filter driver with a mouse can get a mouse track with acceleration effect by performing non-linear conversion on the Data moved by the mouse. A functional driver consists of a class driver and a Minidriver.

Class driver

Drivers implement common operations on a certain type of devices, which are provided by Microsoft. Drivers developers can write very small micro-drivers to process special operations on specific devices, for a large number of other common operations, class drivers of this class can be called, which is also one of the advantages of WDM drivers.

The class drivers provided by Microsoft process common system tasks, such as plug-and-play functions and power management. The class driver ensures the consistency of the operating system when processing similar tasks, thus improving the system stability. The device manufacturer provides micro-drivers to implement the special functions of its own device, while calling appropriate class drivers to complete other general work.

A large number of standard operation codes are implemented through various types of drivers and integrated into the operating system. This method can effectively reduce the size of the micro-driver of a specific device, this reduces the possibility of program errors. If a certain type of equipment has industrial standards, Microsoft will provide a WDM driver for this type of equipment. This class driver implements all the necessary tasks for this type of device, but does not implement anything specific to a specific device.

For example, the implementation of the hid (manual input device) driver provided by Microsoft is based on the USB hid specification V.11, but does not implement any special features of a specific device, for example, USB keyboard, mouse, game control, etc. For details about the WDM bus and drivers supported by Microsoft, see the driver development kit (DDK ).

Customer driver

Any driver that uses a bus driver or a class driver is often called a customer driver. The Advanced Configuration and Power Interface (ACPI) bus driver deals with the acpi bios of the PC, enumerating devices in the system and controlling their power usage. Peripheral components Interconnect (PCI) bus drivers to enumerate and configure devices on the PCI bus. The pnp isa bus driver performs similar work on Industrial Standard Architecture (ISA) devices that can use plug-and-play configurations. Stream drivers support high-bandwidth transmission of data streams for faster data processing. This class driver is often used in combination with the audio port class driver to support real-time video and audio.

These drivers are also responsible for multi-task timing, Direct Memory Access (DMA), memory optimization, plug-and-play, and I/O buffer management. The IEEE 1394 bus driver enumerates and controls the IEEE 1394 high-speed bus. USB bus drivers enumerate and control low-speed USB bus.

USB client drivers use various IOCTL to access their devices through USB drivers. SCSI and CDROM/DVD drivers are used to access hard disks, floppy disks, optical drives, and DVDs. Human input device (HID) Drivers manage data and command syntax translation between multiple bus (such as USB.

Most of the time, this type of driver controls the data sent from the user interaction interface, such as the keyboard, mouse, and game lever. Static Image architecture (STI) is not a driver at all, but a means of acquiring scanners and static cameras using micro drivers.

STI currently supports SCSI devices, serial devices, parallel devices, and USB devices. STI is based on COM (Component Object Model ). 2.2 layered driver structure we already know that WDM uses a layered driver structure, and WDM is object-based. To facilitate Hardware Management, WDM introduces some data structures for each single hardware. in the left-hand part of Figure 3, a device_object Data Structure stack is described.

The lowest layer in the data structure stack is the physical device object, which describes the relationship between our devices and the physical bus, or PDO for short. On the PDO, a function device object is provided to describe the logical functions of a device, referred to as fdo. In other locations of the data structure stack, there are many filter device objects (Fido) above or below fdo. Every object in the data structure stack belongs to a specific driver,

 

 

As indicated by the dotted line in the middle, PDO is a bus driver, fdo is a functional driver, and Fido is a filter driver. The plug-and-play Manager (PnP Manager) in the operating system creates the Data Object stack according to the instructions of the device driver. As we already know, one of the functions of the bus driver is to enumerate the devices on the bus. When the bus driver detects a device, the PnP Manager will immediately create a PDO. After the PDO is created, the PNP manager finds other filter drivers and function drivers by searching the registry.

 

 

 

 

Installation Process of Windows Driver

The installation program of the device is responsible for creating the table items in these registries. The driver installation is performed according to the commands in the INF file. The table items in the Registry indicate the locations of various drivers in the Data Object stack, so the PnP Manager starts to load the filter driver at the lowest layer and calls the adddevice function of the driver. This function creates an Fido in the Data Object stack, and also associates the previously created PDO with this Fido.

The PnP Manager implements this process repeatedly and loads the lower-layer filter driver, function driver, and upper-layer filter driver at other locations until the stack is complete. Applications can access devices by submitting Io request packets (IRPs. In the operating system, the access to the device is like this: the I/O manager in the operating system accepts I/O requests (usually sent by user-State applications ), create a corresponding IRP to describe it, send the IRP to the appropriate driver, and track the execution process. After the operation is complete, the returned status will be notified to the request initiator. The I/O manager, plug-and-play manager, and Power Manager in the operating system use IRP to communicate with kernel-mode drivers and WDM drivers, the communication between drivers also relies on IRP.

In the WDM driver, the IRP first enters from the top layer, the arrow at the right hand side of 3, and then transmits it down in sequence. At each layer, the driver determines the processing of IRP. Sometimes, a driver does not do anything except to pass down the IRP. Sometimes, a driver takes over the IRP completely and does not pass it down. Of course, a driver can also process the IRP and then pass it down. This depends on the features of the driver and the meaning of the IRP.

Here, we can know the reason why Microsoft uses a layered driver structure in the WDM model. When processing device I/O requests, by adding appropriate driver layers, you can flexibly change the behavior of devices to implement functions of different devices.