chapter 8.3: I/O request Flow

I/O request路径：
图8.1
1.应用程序调用Windows API建立请求
2.WinAPI调用kernel-mode subsystems，kernel-mode subsystems调用I/O manager
3.I/O manager构建IRP，发送至KM的设备栈的top driver。
4.向下传递直到设备栈中的driver完成IRP
5.I/O manager调用I/O completion callback
6.I/O manager获得IRP的I/O状态，标记成Windows error code，返回结果
7.I/O manager把控制权交给windows API
8.windows API返回结果给应用程序


UMDF I/O request路径
=============


KMDF I/O request路径
图8.3
1.top driver接收请求，传递给下一层（当前为function driver）
2.framework截取IRP，检查major function 凑得，觉定是否由deriver处理IRP
    若PDO或FDO无法无法处理request，framework发出STATUS_INVALID_DEVICE_REQUEST，继续步骤6.
    若filter driver无法处理请求，framework把请求转发至下层，并继续步骤4
    若能处理，framework创建WDF request object，调用driver的回调函数，或者把请求加入queue中。
3.KMDF处理请求。若完成请求，调用WdfRequestCompleteXxx，进入步骤7
    若driver无法完成请求，driver把它发送至默认I/O target（下一次驱动），
driver可以注册completion callback。
4.下一层driver处理请求
5.请求完成后，I/O manager调用在IRP中注册的completion callback
6.framework调用I/O request object的completion callback
7.framework保证IRP包括status，完成信息和任何相关数据，然后删除request object，把控制权交给I/O manager。


I/O completion 处理
UMDF
====
KMDF
当KMDF完成了WDF request：
    1.在WDF request object中填充I/O状态和完成信息
    2.调用WDF request object的cleanup回调函数
    3.之后再完成IRP请求
    4.当reference count到0时，释放WDF request object，调用destroy callback
    5.摧毁WDF request object，释放相关空间
由framework管理cleanup和destruction


Windows I/O 请求完成处理
IRP完成时，线程的3个相关数据：
I/O status
    UMDF：HRESULT
    KMDF：NTSTATUS
    由I/O manager转译状态到app能识别的Windows erroro code
Completion信息
    返回的byte数量
    即ReadFile的IpNumberOfBytesRead参数
    或WriteFile的IpNumberOfBytesWritten参数
    或DeviceIoControl的IpBytesReturned参数
Requested data
    data buffer


Framework中的I/O request flow
framework中，内部IRProuter检查IRP的major function code来决定下列哪个组建应该处理IRP：
    1.I/O request handler：
        给驱动分派I/O request，管理I/O的取消和完成，和PnP/power handler一起工作来保证设备状态和设备I/O一致。
    2.PnP&Power handler：
        使用内部状态机和回调管理处理
    3.WMI handler(KMDF):
        支持WMI请求，提供WMI默认处理方式，当KMDF不提供WMI数据是，不用注册为WMI data provider。
下图为request pipeline，灰色区域仅支持KMDF
图8.4
------/IRP Preprocessing\-----------
*** KMDF驱动可以注册preprocessing callback来处理KMDF不处理的IRP类型
若KMDF驱动为IRP major function code注册了回调函数，IRP router会为该IRP调用回调，当preprocessing完成后，IRP直接被返回至router。
UMDF不支持framework不处理的IRP。
------/IRP routing to Internal Request Handler\--------
如上图，router为不同的major function code的IRP分派handler。
图中未显示：其他major function code的IRP被发送至默认handler(下一层驱动或完成IRP并返回STATUS_INVALID_DEVICE_REQUEST)


I/O Request Handler中的处理
I/O Request Handler收到新的请求时，首先检查WDF是否支持并检查driver是否处理该I/O请求类型。
WDF为PnP驱动支持如下I/O请求：

I/O request type	IRP major function code
Create	IRP_MJ_CREATE
Cleanup	IRP_MJ_CLEANUP
Close	IRP_MJ_CLOSE
Read	IRP_MJ_READ
Write	IRP_MJ_WRITE
Device I/O control	IRP_MJ_DEVICE_CONTROL
Internal device I/O control	IRP_MJ_INTERNAL_DEVICE_CONTROL (KMDF only)

-------/参数验证\-------
若WDF支持并且驱动处理该类型，I/O handler会检查参数的正确性
1.Read&Write request：I/O handler检查IRP是否包含0长度的data buffer，默认对这些请求标记成功，并指示传送了0byte，但driver可以拍之queue来接受0长度的buffers
2.Device I/O control requests：检查需要direct I/O的input和output buffers，若任何buffer失效，则I/O hander标记错误码并说明0bytes被传送。framework无法确定buffer被丢失或buffer大小是否正确，因为这是设备相关的，driver必须基于需求验证这些参数。
------/I/O handler的请求处理\------
在参数验证后，I/O handler通过IRP类型，driver类型，driver queue配置来决定做什么。
1.代driver处理request：若能如此，handler就这么做（创建、清除和关闭）
2.默认把请求发送给默认I/O target：若handler无法代处理IRP，就发送给target
3.给驱动分派请求：若非1，2，则生成I/O request object，发送至WDF driver（queue或callback）