Several methods of Device Driver notification application

In the popular Windows operating systems, device drivers are the underlying software interfaces used to manipulate hardware. In order to share the experience in the design of the device driver program, five methods are provided for notifying the application of the device driver program...

To ensure the security and stability of the operating system and the portability of applications, the Windows operating system does not allow applications to directly access the hardware resources of the system, but must rely on the corresponding device driver. The device driver can directly operate on the hardware. If two-way communication is implemented between the application and the device driver, the application can control the underlying hardware device. The communication between them includes two aspects: one is the data that the application sends to the device driver, and the other is the message that the device driver sends to the application. The former is easier to implement. After obtaining the handle of the device driver through the createfile () function, you can use Win32 functions, such as deviceiocontrol (), readfile (), or writefile () communication between applications and device drivers. The implementation of the latter is far more complex than the former, and there are few articles about this situation. This does not mean that it is not important. On the contrary, it plays an important role in some application scenarios. After the device driver completes data collection, it needs to immediately notify the application so that the application can take data away and process it in a timely manner. In such cases.

In view of the importance of the device driver notifying the application, I have summarized some experiences and summarized five methods: asynchronous process call (APC) and event Method (VxD) message mode, asynchronous I/O mode, and Event Mode (WDM ). The following describes the principles of these methods and provides some source code for implementation.

1. asynchronous process call (APC)

Win32 applications use the createfile () function to dynamically load the device driver, define a callback function backfunc (), and use the callback function address & backfunc () as the parameter through deviceiocontrol () to the device driver. After the device driver obtains the callback function address, it stores it in a global variable (such as Callback) and calls the get_cur_thread_handle () function to obtain the handle of Its Application Thread, and save the handle in a global variable (such as appthread. When the conditions are met, the device driver calls the _ vwin32_queueuserapc () function to send messages to the Win32 application. This function has three parameters: the first parameter is the address of the callback function (registered), and the second parameter is the message passed to the callback function; the third parameter is the caller's thread handle (registered ). After the Win32 application receives the message, it automatically calls the callback function (actually called by the device driver ). The input parameters of the callback function are filled in by the device driver. The callback function mainly processes messages here.

2 Event Mode (VxD)

First, the Win32 application creates an event handle called ring3. Because the virtual device driver uses the event's ring0 handle, you need to create a ring0 handle. Use the loadlibrary () function to load the undisclosed dynamic link library kernel32.dll and obtain the handle of the dynamic link library. Then, call getprocaddress () to find the position of the function openvxdhandle () in the dynamic link library. Then, use the openvxdhandle () function to convert the ring3 event handle to the ring0 event handle. Win32 applications use the createfile () function to load the device driver. If the load is successful, call the deviceiocontrol () function to pass the ring0 event handle to the VxD. At the same time, create an auxiliary thread to wait for the signal to become a signal state, and you can do other things. When the condition is ripe, VxD sets the ring0 event to a signal state (call the _ vwin32_setwin32event () function), which immediately triggers the corresponding ring3 event to a signal state. Once the ring3 event handle is in a signal state, the worker thread of the Win32 application processes the message accordingly.

3. Message Mode

Win32 applications call the createfile () function to dynamically load virtual device drivers. After loading, call the deviceiocontrol () function to send the form handle to VxD. VxD uses this handle to send messages to the form. When conditions are met, VxD calls the shell_postmessage () function to send messages to Win32 applications. To make the function use successfully, you must use # define to customize a message, and define it in the application as well. You must also use on_message () in the message loop () to define the message processing function corresponding to the message, so that the message processing function can be called when the message is generated. The first parameter of the shell_postmessage () function is the Win32 form handle, the second parameter is the message ID, and the third and fourth parameters are the parameters sent to the message processing function, the fifth and sixth parameters are the callback function and the parameters passed to it. After the Win32 application receives the message, it processes the message.

4 asynchronous I/O mode

The Win32 application first calls the createfile () function to load the device driver. When you call this function, set the last 2nd parameters to file_attribute_normal | file_flag_overlapped, indicating that you can perform overlapping I/O operations on files in the future. After the device driver file is created successfully, an event in the initial state is created with no signal and needs to be manually reset, and the event is passed to the data structure (such as overlapped) of the overlapped type ). Then, use overlapped as a parameter and pass it to the deviceiocontrol () function. The device driver sets this I/O Request package (IRP) to pending and sets a cancellation routine. If the current IRP queue is empty, the IRP is sent to the startio () routine; otherwise, it is placed in the IRP queue. After the device driver completes these tasks, it ends the processing of the deviceiocontrol (). Therefore, the Win32 application may return the result from the call of deviceiocontrol () without waiting for the completion of the IRP. Determine the return value to obtain the processing status of the IRP. If the current IRP is suspended, the main program first does some other work, and then calls the waitforsingleobject () or waitformultipleobject () function to wait for the event in overlapped to become a signal state. The device driver processes the queued IRPs when appropriate. After the processing is complete, the iocompleterequest () function is called. This function sets the event in overlapped to a signal state. The Win32 application immediately responds to the event, exits the waiting state, resets the event to the non-signal state, and then calls the getoverlappedresult () function to obtain the processing result of the IRP.

5 Event Mode (WDM)

The Win32 application first creates an event, then transmits the event handle to the device driver, and then creates an auxiliary thread, waiting for the event to have a signal status, and then does other tasks on its own. After obtaining the event handle, the device driver converts it to an event pointer that can be used and stores it for later use. When the conditions are met, the device driver sets the event to a signal State, so that the application's auxiliary thread will immediately know the message and process it accordingly. When the device driver no longer uses this event, the pointer of this event should be removed.

6 conclusion

In the popular Windows operating systems, device drivers are the underlying software interfaces used to manipulate hardware. It provides hardware-independent user interfaces and directly performs operations such as I/O, hardware interruption, DMA, and memory access. It shields applications from hardware details, making the software independent of hardware and portable across multiple platforms. This article introduces five methods for device driver notification applications. The first three methods are mainly used in VxD, and the last two methods are mainly used in WDM. All five methods have been tested. Test results show that they can all achieve the purpose of Device Driver notification applications.

References:
[1] Research and Development of Virtual Device Driver VxD. Computer Engineering, 2003
[2] (US) Chris cant. Guide to development of drivers for Windows WDM devices. Translated by Sun Yi, Mary Bo, Guo xuefei. Beijing: Machinery Industry Press 2000
[3] research on DSP-based ICT image reconstruction system. Beijing: School of mechanical engineering and automation, Beijing University of Aeronautics and Astronautics, 2002