Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
I/O Request Flow
Since we have looked at the overall architecture of the UMDF, let’s take a look at the I/O Request flow associated with a UMDF driver. Figure 2 shows the path that an I/O request takes from an application to a UMDF driver.
)
Figure 2 I/O flow to UMDF driver.
Callers use the Win32 API to send I/O requests to devices that are managed by UMDF drivers, just as they do for any other device. The Win32 API calls the appropriate kernel mode I/O routine, and the Windows kernel I/O manager creates an I/O request packet (IRP) and sends this IRP to the driver at the top of kernel mode device stack for the target device.
For a device that is managed by a UMDF driver, the reflector is the driver at the top of the kernel mode device stack. The reflector creates three types of device objects:
- Up device object: This is at the top of the kernel mode stack for the device and thus is the reflector’s target for IRPs from the I/O manager. When an IRP arrives, the reflector uses interprocess communications to forward it to the User Mode Driver host process, in which the framework and driver run. UMDF interprets the request and calls methods in the driver’s event callback interfaces to handle it. The reflector creates an up device object for each device stack in which it participates.
- Down device object: This is the reflector’s target for I/O requests that originate in the User Mode Driver and is therefore the default I/O target for the bottom driver in the user mode device stack. A User Mode Driver might issue an I/O request to perform a device I/O control operation on its own device or to retrieve data from another device to complete one of its own requests. The reflector creates a down device object for each stack in which it participates.
- Control device object: This manages I/O request to and from the driver manager, which are not part of the normal I/O flow to the driver. Instead, the control device manager, which is independent of the normal flow of I/O, power management, and Plug and Play requests. The reflector creates only one control device object per system.
In addition to creating IRP to represent user I/O requests, the I/O manager sends IRPS to notify driver of Plug-and-Play requests, power management requests, change to device status, and queries about device and driver resources (among other purposes). Therefore, the UMDF I/O mode encompasses both I/O request dispatching and Plug and Play and power notification.
Final Thoughts
Basically then, these two block diagrams and the subsequent discussions should give you some feel for a UMDF driver and the associated I/O flow of application to device information. In future articles, we continue to drill down on more details of creating an UMDF driver and installation approaches.