Design and development of WDM driver design
(Author: Su Jinguo, 2000 at 13:26 on November 9)
By installing DDK and the corresponding development software, we construct a development environment of the WDM driver. Then, we must go deep into the design and development work.
■ The WDM driver's operation process WDM itself has raised the status of the root in an abstraction of the PNP manager. The PNP Manager is responsible for the loading of all bus drivers. The bus driver is responsible for traversing all the devices located on the bus and creates a corresponding device object for each device. When the PNP manager discovers a device object, you find the Driver corresponding to the object. And call the DRIVER's Add Device routine. If DRIVER is not in memory, then load it first, then call the Add Device routine. Of course, the bus itself does not issue any signal to tell the PNP manager's own existence, so the bus driver is set when the NT is installed. ISA equipment is not specified, because KMD needs to check the existence and state of hardware, so it is the only reason for the existence of old-fashioned KMD. This is also one of the reasons for Microsoft's trust in the new specification to cancel the ISA bus. WDM supports PNP protocols and PM protocols, and implements only routines that need to be added to PNP and PM events in the Major Function. ■ Driver design Design a device driver, support the same IRP_MJ_XXX and IOCTL request code as NT drivers of other same types of devices. If you design an intermediate NT driver, you should first confirm that the device managed by the lower driver, because a high-level driver must have a low-level driver most IRP_MJ_XXX routine entry. When the high-level driver is connected to the I / O request, set the stack unit of the next low-level driver in the IRP in determining the current stack unit parameters, and then call the IocallDriver to pass the request to the lower driver. . Once the driver should process which IRP_MJ_XXX should be processed, you can start determining how many DISPATCH routines should have on the driver. Of course, it is also possible to consider combining the routines that have some RP_MJ_xxx processing into the same routine. For example, in ChangerDisk and VDISK, the routines for IRP_MJ_CREATE and IRP_MJ_CLOSE are the same function. A driver must create a Device object for the physical and logic devices that can be managed for each of the targets that may be I / O requests. Some low-level drivers may also create some unseasive number of Device objects. For example, a hard drive must create a Device object for each physical hard disk while also creating a Device object for each logical partition on each physical disk. A high-level driver must create a Device object for a virtual device it represent, such a higher-level driver to connect their Device objects to the Device object of this driver. In addition, a high-level driver typically creates a series of virtual or logical Device objects for Device objects created by its low-level driver. Although the driver can be designed in phases, a driver in the development phase does not have to create all the Device objects that it will handle, but determine all Device objects that are ultimately created from the beginning. Help any synchronization problem to be solved by the designer. In addition, it is determined that the DEVICE object to be created also helps to define the contents and data structures of Device Extension of the Device object. ■ The development of driver development drivers is a process from rough to fine. NT DDK's src / directory has a huge template code, almost all types of device drivers, high-level drivers, and filter drivers. Before starting to develop the driver, you should look at whether or not the similar type of routine that has to be developed will be on this model library. For example, if you want to develop an optical disk tower driver, although DDK does not have any description to the CD tower, the CD tower is a SCSI-II-II standard SCSI device, which can find a lot of drivers related to SCSI devices in the src / store / class directory. For example, SCSI TAPE, SCSI DISK, SCSI CDROM, etc., you can refer to a similar driver, thereby disproportionate development difficulty.
The following writers will further introduce the basic steps of the development driver: l. Writing the driver framework (1) First write a DriveRETRY routine and call IOCREATEDEVICE in this routine to create a Device object. (2) Write a basic framework for processing the DISPATCH routine requesting IRP_MJ_CREATE. If the driver creates more than one DEVICE object, you must write a routine for IRP_MJ_CLOSE requests, which can usually share one routine with DispatchCReate. (3) Compile the connection driver. 2. Test driver (1) First install the driver in the system, please refer to the "Compilation and Installation" of the following version of the "Compilation and Installation". (2) Establish a symbol connection for the NT logic device name and the target device object name. It is already known that the DEVICE object name is invisible to Win32 user mode. It cannot be accessed directly through the API. Win32 API can only be accessed. NT logical device name. You can establish a symbol connection between the two names by modifying the registry. Running regedt32.exe creates a symbolic connection under / hkey_local_machine / system / currentcontrolset / control / session manager / dos devices, which can also be created in the driver to call function IOCREATESYMBOLICLINK. (3) Complete all the above settings and check the error, we must restart the Windows system. (4) Write a simple test program to call the CREATEFILE function in the Win32 API and open this device with the NT logic device name just named. If it is successful, a simplest driver is successfully written. Support for more device I / O requests, such as drivers may need to respond to IRP_MJ_READ requests (available after completion of the ReadFile function). If the driver needs to be able to uninstall, IRP_MJ_CLOSE must be responded. Write the processing routine for the IRP_MJ_XXX you need, and initialize these routine portals in DriveREntry. A low-level driver requires a StartIO, ISR, and DPCFORSR routines that may also need a SYNCHCRITSECTION routine. If the device uses DMA, you may need an AdapterControl routine. For high-level drivers, one or more IOCOMPLETION routines may require one or more IOCOMPLETITION routines, at least check the I / O status block and then call IOCOMPLETEREQUEST. If necessary, make some modifications to the Device Extension data structure and content. One must be clear, that is, the code run level, i.e. IRQL, the most common level is Passive_LEVEL, APC_LEVEL, DISPATCH_LEVEL, and DIRQL. When watching the function in NT DDK Help, pay attention to the running level of the function, such as some functions can only be run under passive_level, some functions can be run at DISPATCH_LEVEL below, the higher the level, the code The more stringent requirements, such as when dispatch_level, you cannot use paging memory. Usually, you should run as much as possible to run under the low run level such as Passive_LEVEL, which runs over a long period of time will result in system efficiency, affect the real-time performance of system response.
