Author: Zhao Yonghua Time: 2004-04-01 Source: yesky Editor: Ark
Writing hardware device drivers has always been a very challenging complex work, even if you have written developers with quite difficult Win32 programs, you must go to all kinds of discomfort when writing device drivers, need "brainwashing". Writing device driver is very similar to an arduous task: no window, no message needs to be handled, it is difficult to debug settings for the source code, almost all support libraries cannot be called; worse, because the device driver belongs to the operation The system's trust part is easy to harm the system, but it is often lacking a protective means to prevent processes and Windows systems. WDM (Windows Driver Model) is Microsoft provides an effective way to write new hardware drivers under Windows Platform for developers, which is called Windows driver model. WDM provides device classes, resulting in source code that can run in various Windows platforms: WIN XP / 2000 / ME / 98. It should be pointed out that occupational developers tend to use more depth DDK, which in addition to developing WDM type drivers, you can also develop non-WDM type Windows drivers. WDM is a convenient programming technology that allows developers to run across platforms, supporting the WDM bus driver supported by Microsoft, and the concept of "bus" in WDM is an additional Device protocols on other devices (including physical devices, logic, virtual devices), such as Windows XP built-in WDM technical support bus types include: PCI (Peripheral Component Interconnect), dynamic plug-and-play serial I / O Bus (such as USB and IEEE 1394), SCSI (Small Computer System Interface), NDIS (Network Driver Interface Specification, and remote NDIS (RNDIS). RNDis in the new WDM is new content: such as simplifying the development of network device hardware, weakening the dependence of the network device on the driver, making the end user easier to install the settings of the network device. WDM's new version of the device mainly includes: USB device class, such as HID (Human Interface Device); digital camera / scanner; video capture device for IEEE 1394; audio; control modem WinModem. The Port / MiniPort drive paradigm provided in the WDM class code supports third-party manufacturers to write "mini" driver for their special devices. Windows DDK is actually based on WDM, which provides: Driver Verifier and Windows Hardware Compatibility Tests test tools; integrated environments such as third-party drivers identified by WHQL (Windows Hardware Quality Labs). The WDM driver's three types of WDM supported drivers have a hierarchical structure, in other words, for a device, it can have three types of Drivers: bus driver, or functions driver, or filter driver (it can Assuming or correcting the behavior of the device). These driver chains serving a device service are so-called driver stacks.
A driver stack session handles the user's request, these drivers superimposed together, the low-level bus driver can be used to process all the basic contacts of the hardware, while the intermediate class driver provides the entire class driver Common facilities. Microsoft provides a bus driver for Windows and provides services for third-party equipment developers, such as enumeration devices, management of plug and play and I / O, and provides independent of device management. Device developers are more provided to provide functional drives, including: the operation interface of the device, the read and write handle of the device, and the management policy for the device power supply. Filter driver is mounted on or lower or lower ends of the drive stack, it can intercept the device, or the request, or the bus, determine these requests, and modify its content or respond to it, such as a USB keyboard The high-level filter driver enhances encryption check, and low-level filtering for mice helps to improve mouse performance. Function type driver is a structure: conventional execution belonging to a certain type of device can be implemented through its class drive, ie, when the driver is developed, the developer's work only needs to write very little driver code minidriver to deal with hardware. Most of the work can be done by calling class drivers. Microsoft provides class drivers to achieve common system tasks, such as plug and play and power management. The main contents of WDM Class Drivers include: (1) Flow class driver, support multimedia content in kernel mode; (2) HID-type drive with support input devices; (3) USB and IEEE 1394 bus classes; (4) support strings Row and parallel storage protocols.
Windows Support WDM-driven all system kernel components include: (1) Kernel components, refer to basic synchronization, performance computing, and timely, delaying IRQ control; (2) Object Manager components, object descriptions; (3) Executive Execute Components, Memory Assign, interlock and list operations; (4) I / O management components, including I / O IRP (Request Packet) control, device object, work item, registry access, system status prompt, DMA, and interrupt; (5) Memory management, virtual to physical memory image, physical memory hoster, lock, driver image memory lock, mobile I / O space; (6) processing service, system thread generation and deletion; (7) Run-time library, large capacity Save, Unicode and data type conversion; (8) power management, power status change, power IRP control, device free detection; (9) Plug and play subsystem, hardware detection, resource allocation, PNP (PLUG AND PLAY) IRP control And hardware events; (10) WMI (Windows Management Instrument), is used to support device testing and support structures indicating data; (11) The kernel stream is a support structure of connection stream data devices; (12) hardware extraction layer, Extract the platform, access, and call the I / O port and memory image devices. Power management can be a system level or device level, the former can request the entire system to close. There are six states in the system power supply: unfunction, completely shut down, three leisure status, and a sleep state. Equipment level power management has four states: fully turned on, completely closed, plus two sleep conditions. A device can be turned off here, even if the other parts of the system are running full speed.
The driver composition principle and the development of the module composition of the devices. It mainly includes: initialize yourself, create, and delete the device, process Win32 to open and close file handle requests, process the I / O request of the Win32 system, serialize the device Access, access hardware, call other drivers, cancel I / O requests, timeout I / O requests, process a PNP device is added or deleted, and process power management requests, call Windows Management Diagnostics WMI to report to system administrators. Wherein, "Initialization" module is essential, all drivers need to process users' I / O requests by distributing procedures. The WDM style device driver requires a "Plug and Play (PNP)" module and an INF file that is installed. In the above-mentioned different modules, some interactions can be called directly, while a large amount of information requires delivery of each device in the data structure such as "device objects"). The distribution example refers to the "Create", "Read", "Written", "Close", which can perform the initialization processing of IRP, check the legality of the parameters. A very difficult so-called "synchronous problem" that is often encountered in the driver writing, refers to two or more IRP distribution routines to "simultaneously" run, not only in the multiprocessor system, but also Sometimes it is also sharp in a single processor system: For example, a distribution routine on a single processor system is completed while waiting for a low-level driver call, another IRP distribution routine is called. There are two main mechanisms to deal with this conflict: one is a critical section routine, and this guarantee code will not be interrupted by the interrupt handler; another mechanism is serial processing IRP via the STARTIO routine, each device object has An internal IRP queue, the driver's distribution routine plugs the IRP into this device queue, the kernel I / O manager removes the IRP from the queue and passes the STARTIO routine of the driver, STARTIO routine serial Processing IRP to ensure conflicts with other IRP handles, but StartIO routines still need to avoid conflicts with hardware interruptions through critical segment routines. The interrupt is used to stop the execution of a task to a task, and is forced to run an interrupt to process code. Interrupts include software interrupts and hardware interrupts. Interrupt has priority, low priority interrupts are interrupted by high priority interrupts to ensure that important tasks are prioritized. The interrupt generated by hardware is always higher than the interrupt priority generated by the software. The hardware interrupt type includes: the execution of the device interrupt request grade handler, configuration file timer, clock, synchronizer, processor interrupt level, power failure class; software interrupt includes asynchronous process call execution, thread scheduling, delay process call execution . As for the regular thread execution, there is no interrupt. The main initialization entry point of the driver is a routine called DriveREntry. Most WDM device objects are created by the PNP Manager call AddDeDevice entry point. This routine is called when the new device is inserted and the driver corresponding to the INF file indication is called. After that, a series of PNP IRPs are sent to the driver, indicating the device When you start and query your functionality. In order to let the application cognitive drive device exist, the developer must create a symbolic link to the Win32 visible to each device object. At this time, there are two implementation paths: one is, using an explicit "hard-coded" symbolic link name In this regard, the source code of the application also has the hardcoding of the device name; there is a device interface, each device interface is identified by a GUID (globally unique identifier), registered with a specific one A symbolic link is created when the device interface. User programs can search for all devices with specific GUIDs. The driver's code is run by the system kernel by sending I / O IRP request. IRP is the basic structure of the device driver.
Other routines in the drivers called by the kernel are called callback routines, each with a standard function prototype, which is suitable for the corresponding environment. Commonly used callback routines include: unload (uninstall driver), addDevice, startio (serial processing IRP), ISR (interrupt service routine), DPCFORSR (delay process call routine), The critical section routine, withdraw the CANCEL routine of the IRP, a low-level driver completes the Completion routine called when IRP processing, when the DMA channel is available, the AdapterControl, Timer (Second Timer Tune Routor), which is called when the DMA channel is available 1 second time-time routine CustomTimtimerdpc, used to handle the CustomDPC of the work queue, Reinitialize (for initial consumption of drivers). Hardware drivers should have fault tolerance, such as connecting cable disconnects or cache overloads, and feedback the error message to the application. You can check the hardware status bit (such as the printer's shortup indication) and can handle the fast I / O event. Similar to other Windows programming, how to assign or access memory when writing a hardware driver is a very important technique. We know that virtual memory used in Windows means that the system can use more memory than physical memory. The implementation of virtual memory is: divide the possible address space of each application into a fixed size block, which is called page (the page size of the X86 processor is 4KB, the page of the Alpha processor is 8KB). Pages can reside in physical memory or switched to hard drives. The memory allocated by the device driver usually has two: can be a swap type paging memory, or a non-page memory permanently residing. If you try to access the paging memory in thread scheduling or higher interrupt level, it will cause a fault failure to cause the kernel crash. Even in a regular thread, if you access non-stocked paging memory, the kernel will cause the thread to block until the memory manager is installed back to memory. The key to the problem is that when designing drivers, one side is taboo to abuse non-paged memory, but on the other hand, non-page memory is often used. Because you want to access memory in thread scheduling or higher, you must call non-paged memory. When the memory is complete, all types of memory should be released via EXFREEPOOL. If the memory is not released, memory will be reduced, because even after the driver is uninstalled, the kernel does not collect these assigned memory. There is no developer who has written over the hardware driver. When you listen to the hardware driver programming, they will associate from intuition to deal with hardware resources, including I / O ports, interrupts, memory addresses, and DMA (direct memory access). In fact, this is a misunderstanding because there are many drivers to call any low-level hardware resources directly. For example, the USB client driver does not require any hardware resources. All the hardware-related trivial work has a USB bus driver. The USB client driver only issues a request for the bus driver. WDM version issues Although Windows XP / 2000/98 / ME support WDM, due to historical reasons, different versions of WDM content are different. Of course, the new WDM is the older version of the WDM supercoming. Cross-system WDM Driver usually uses the IOISWDMVersionavailable routine to determine that the current running system supports the version number of WDM. According to common sense, the easiest way to ensure cross-platform compatibility should be: Write a driver only those functions supported by the lowest version WDM.
