posts - 46, comments - 44, trackbacks - 0, articles - 2
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理
             在不同的场合,很多驱动编写人员需要在驱动和用户程序间共享内存。两种最容易的技术是:

l 应用程序发送IOCTL给驱动程序,提供一个指向内存的指针,之后驱动程序和应用程序就可以共享内存。(应用程序分配共享内存)

l 由驱动程序分配内存页,并映射这些内存页到指定用户模式进程的地址空间,并且将地址返回给应用程序。(驱动程序分配共享内存)

使用IOCTL共享Buffer:

使用一个IOCT描述的Buffer,在驱动和用户程序间共享内存是内存共享最简单的实现形式。毕竟,IOCTL也是驱动支持其他I/O请求最经典的方法。应用程序调用Win32函数DeviceIoControl(),要被共享的Buffer的基地址和长度被放入OutBuffer参数中。对于使用这种Buffer共享方式的驱动编写者需要确定的事情就是对于特定的IOCTL采取哪种Buffer method。既可以使用METHOD_XXX_DIRECT,也可以使用METHOD_NEITHER。

(PS: 在METHOD_XXX_DIRECT模式下,IO管理器为应用层指定的输出缓冲区(OutputBuffer)创建一个MDL锁住该应用层的缓冲区内 存,然后,我们可以在内核层中使用MmGetSystemAddressForMdlSafe获得应用层输出缓冲区所对应的内核层地址。MDL地址被放在 了Irp->MdlAddress中)。

如果采用METHOD_XXX_DIRECT方式,那用户Buffer将被检查是否正确存取,检查过后用户Buffer将被锁进内存。驱动需要调用MmGetSystemAddressForMdlSafe将 前述Buffer映射到内核地址空间。这种方式的一个优点就是驱动可以在任意进程上下文、任意IRQL优先级别上存取共享内存Buffer。如果只需要将 数据传给驱动则使用METHOD_IN_DIRECT方式。如果从驱动返回数据给应用程序或者做双向数据交换则使用METHOD_OUT_BUFFER。

(PS: 这些检查都将由IO管理器来负责,并且,此时IO管理器将为用户层的缓冲区创建MDL。因为此时还未到设备驱动层,当前上下文还属于当前发起 DeviceIo调用的进程,用户模式缓冲区的内存有效。但是,经过IO管理器发送IRP到下层驱动时,就不能保证当前上下文,幸而有IO管理器为我们创 建MDL。这样,我们就可以在内核层获得对应的内核地址,并且自由写入数据。)

使用METHOD_NEITHER方式描述一个共享内存Buffer存在许多固有的限制和需要小心的地方。(基本上,在任何时候一个驱动使用这种方式都是一样的)。其中最主要的规则是驱动只能在发起请求进程的上下文中存取Buffer。这是因为要通过Buffer的用户虚拟地址存取共享内存Buffer。这也就意味着驱动必须要在设备栈的顶端,被用户应用程序经由IO Manager直接调用。期间不能存在中间层驱动或者文件系统驱动在我们的驱动之上。在实际情况下,WDM驱动将严格限制在其Dispatch例程中存储用户Buffer。而KMDF驱动则需要在EvtIoInCallerContext事件回调函数中使用。

另 外一个重要的固有限制就是使用METHOD_NEITHER方式的驱动要存取用户Buffer必须在PASSIVE_LEVEL的IRQL级别。这是因为 IO Manager没有把Buffer锁在内存中,因此驱动程序想要存取共享Buffer时,内存可能被换出去了。如果驱动不能满足这个要求,就需要驱动创建 一个mdl,然后将其共享Buffer锁进到内存中。

(PS: METHOD_NEITHER不建议使用,还是使用直接IO好。)

另 外,考虑到传输类型的选择,对于这种方式可能的非直接明显的限制是对于共享的内存必须被用户模式应用程序分配。如果考虑到配额限制,能够被分配的内存数量 是有限的。另外,用户应用程序不能分配物理连续的内存和Non-cache内存。当然,如果驱动和用户模式应用所有要做的就是使用合理大小的数据 Buffer将数据传入和传出,这个技术可能是最简单和实用的。

和 它的简易一样,使用IOCTL在驱动和用户模式应用之间共享内存的也是最常被误解的方案。一个使用这种方案的新Windows驱动开发者常犯的错误就是当 驱动已经查询到了Buffer的地址后就通知结束IOCTL。这是一个非常坏的事情。为什么?如果应用程序突然退出了,比如有一个意味,会发生什么情况。 另外一个问题就是当使用METHOD_XXX_DIRECT,如果带有MDL的IRP被完成,Buffer将不再被映射到系统内核地址空间,一次试图对以 前有效的内核虚拟地址空间的存取(MmGetSystemAddressForMdlSafe获取)将使系统崩溃。这通常要避免。

一 个针对这个问题的方案是应用程序使用FILE_FLAG_OVERLAPPED打开设备并且考虑IOCTL使用一个OVERLAPPED结构。一个驱动可 以针对IRP设置cancel例程(使用IoSetCancelRoutine),将IRP标记为挂起(使用IoMakeIrpPending),并且返 回给调用者STATUS_PENGDING前将IRP放进内部队列。当然,KMDF驱动对这类问题可以放心,只需要将请求设置为进行中并且可取消,就像 WDFQUEUE。

(PS: 要小心使用MDL,防止应用层程序意外退出而造成MDL所描述的虚拟内存无效。)

使用这种方法有两个优点:

1、当应用程序从IOCTL调用中得到ERROR_IO_PENDING的返回结果时,知道Buffer被映射了。并且知道什么时候IOCTL最终完成并将Buffer取消映射。

2、通过取消例程(WDM)或者一个EvtIoCancelOnQueue事件处理回调例程,驱动程序成功在应用程序退出或者取消IO命令时得到通知,所以它可以执行必要的操作来完成IOCTL。因而有MDL位置用于内存取消映射操作。

转载自:http://hi.baidu.com/clingingice/blog/item/203146941729670f7bf480f6.html

英文原文:http://www.osronline.com/article.cfm?article=39