chapter 4.5: UMDF结构

从I/O manager的角度看，I/O request的目标必须是一个WDM device object。

UMDF的主要需求：给User mode和Kernel mode之间架一座安全传递I/O请求的桥梁。

UMDF主要元素：

    1.kernel-mode driver reflector,管理了UMDF的host process的通信

    2.通信机制，跨越UM/KM的屏障

注意lower device stack，有时需要硬件提供商实现

UMDF 子结构组件

每个UMDF driver是作为device stack的一部分来管理设备的

UMDF device stack上部分在用户模式，下部分在内核模式。

    上部分：Wudfhost进程，用来载入driver和framework DLLs，Wudfhost还协助管理drivers之间、KM/UM组件间的通信。

    下部分：是在实际上处理内核子系统和设备间的交互（如USB drivers的lower part由windows提供，其他的可能需要设备生产商提供）

*对于一些设备，下部分主要目地仅仅是把设备加到PnP manager的device tree中。如软件驱动和网络连接驱动。

UMDF Host Process

管理了处于用户模式的设备栈的组件，协助了这些组件与reflector的交互

每个UMDF栈都有自己的host process

     A UMDF stack：包含了一至多个function或filter driver，它具有自己的device objects和IRP，处理方式和内核中的一致，但实现方式不一样。

    一个或多个framework的实例：每一个version一个实例，提供了library

Wudfhost是dirver manager进程的子进程。虽然它不是windows service，但仍运行在LocalService 账户中。

*WUDF指的是UMDF，有时WDF指的是KMDF，注意文档中的用法。

Device manager

一个windows service，管理系统所有的UMDF host process，创建它们，维护状态信息，以及关闭他们

直到当第一个UMDF driver载入时，driver manager会被禁用

Reflector

支持所有UMDF drivers的内核模式驱动，它创建了两个device object：

    1.The Up device object：设备的内核设备栈的顶层设备，接收来自I/O manager的请求，传递给UMDF host process，并向I/O manager返回结果。

    2.The Down device object：

        这是一个side object，并不安装在内核模式设备栈中。接收UMDF host process处理过的请求，传递给低层的driver stack，还创建device interface和impersonating a client

reflector还创建另一个side object：Control device object，处理UMDF host process和reflector之间的I/O请求不相关的通信（如host process的创建和关闭）

为什么使用side objects：

创建device stack时，要在device stack创建前和lower device stack通信

移除device时，关闭device stack最后一个句柄后向device发送信息

由于reflector的过滤，没有任何其他人能用到side object

同理，device能在starting和removing的阶段房屋object

lower device stack

UMDF所有驱动在实际上的处理设备通信的内核驱动。

如USB drivers的lower device stack由windows提供，其他的则需要设备生产商提供实现

Fatal Errors in UMDF Drivers

不会影响内核级内存，由reflector向所有内核中的驱动发送error status，并告知应用程序。

Windows会记录错误日志，5次重启UMDF driver，然后禁用设备，卸载在设备栈中的内核相关驱动。

典型的UMDF I/O 请求

应用程序不会意识到在使用的驱动是UMDF级的。

典型请求的过程：

    1.App 调用winAPI(如ReadFile or DeviceIoControl),windows 调用相关方法把请求传给I/O manager

    2.I/O manager生成IRP传给reflector的Up device object，再传给driver的host process，host process 生成user-mode IRP

    3.host process把user-mode IRP传到framework中设备栈的栈顶

    4.framework从user-mode IRP生成framework I/O request object，传给相应的driver callback object

    5.driver 处理I/O request，把它传给default I/O target（下一层设备驱动）（过程是先传给framework，由framework分派）

    6.若stack有其他UMDF drivers，重复345步知道遇到一个能完成请求的驱动

    7.host process把完成的请求传给reflector的Down device object，它创建一个second IRP

    8.Down device object把请求传给lower device stack，最终，其中的driver完成second IRP请求

    9.Down device object把完成请求信息传给驱动的host process，它按顺序从栈底调用其中的completion callbacks

    10.framework把completed I/O request 传给reflactor的Up device object，释放user-mode IRP；Up device object把请求返回给I/O manager，最终返回给应用程序