请问如何为WDM驱动和应用程序分配一段共享内存？

昨天我的提问感谢朋友们的回答。我后来仔细看了一下确实是可以的。根据最后一个朋友的建议，使用共享内存也可以实现。我怎么看帮助文档，怎么也找不着如何为WDM和应用程序分配一段共享内存。所以，只好再次向各位朋友请教了！
问题如下：
1）如何分配一段共享内存，WDM和应用程序都可以从里面读和写数据？
2）这段内存大小有何限制？
3）可否最大限度把所有的可用内存都分配为共享内存？
4）这段共享内存是虚拟内存还是真实物理内存在使用上是不是都没有区别？
5）我以前在应用程序分配了尽可能多的内存后，应用程序速度变慢。这里是否存在分配内存的一个合适百分比，即：实际分配内存\\最大可用内存 处于一个什么样的合适值不影响应用程序的速度？

请大侠指点！

1.在设备创建时，分配一块非分页内存；在设备Unload时删除；中间你就可以访问这块共享内存，这里还有关键一步，将这块非分页内存映射为应用程序可以访问的内存地址
可以参考以下的代码，论坛中有很多类似的例子
pMdl = (PMDL)ExAllocatePoolWithTag(NonPagedPool, SizeOfMdl(IoSysBuffer,ShareBufferLen),0x206B6444); //Tag=Ddk
if(pMdl)
{
pMdl = MmCreateMdl(pMdl,IoSysBuffer,ShareBufferLen);
MmBuildMdlForNonPagedPool(pMdl);
IoUserBuffer = MmMapLockedPages(pMdl, UserMode); // 映射
FuncRetnVar = (ULONG)IoUserBuffer;
// IoUserBuffer为应用程序可以访问的内存地址
// FuncRetnVar 为IoControl的返回变量
}
WDM和应用程序都可以从里面读和写数据
2.因为是非分页内存，尽量小（我是这样认为，还要为其他程序留出足够的空间）
3.你可以试一下，结果告诉我一下
4.有区别，非分页内存位于真实物理内存
5.应该是这样，速度变慢原因是在应用程序配了尽可能多的内存后，把你的部分内存映射到windows的交换文件中。

Sharing Memory Between Drivers and Applications
 2000 OSR Open Systems Resources, Inc. Updated: 2002
At one time or another, most driver writers will have the need to share memory between a driver and a user-mode program. And, as with most such things, there are a wide variety of ways to accomplish the goal of sharing a block of memory between a driver and a user-mode application. Some of these approaches are decidedly right and some are wrong. Two of the easiest techniques are:
? The application sends an IOCTL to the driver, providing a pointer to a buffer that the driver and the application thereafter share.
? The driver allocates a block of memory (from nonpaged pool for example), maps that block of memory back in the address space of a specific user-mode process, and returns the address to the application.
For the sake of brevity, we’ll restrict our discussion to these two, straightforward, techniques. Other perfectly acceptable techniques include sharing a named section that’s backed by either the paging file or a memory mapped file. Perhaps we’ll discuss those in a future article. Also, note that this article won’t specifically address sharing memory that’s resident on a device. While many of the concepts are the same, sharing device memory with a user-mode program brings with it its own set of special challenges.
Sharing Buffers Using IOCTLs
Sharing memory between a driver and a user-mode app using a buffer described with an IOCTL is the simplest form of “memory sharing”. After all, it’s identical to the way drivers support other, more typical, I/O requests. The base address and length of the buffer to be shared are specified by the application in the OutBuffer of a call to the Win32 function DeviceIoControl().
The only interesting decision for the driver writer who uses this method of buffer sharing is which buffer method (or, “transfer type” as it’s known) to specify for the IOCTL. Either METHOD_DIRECT (that is, using an MDL) or METHOD_NEITHER (using user virtual addresses) will work. If METHOD_DIRECT is used, the user buffer will be locked into memory. The driver will also need to call MmGetSystemAddressForMdlSafe() to map the described data buffer into kernel virtual address space. An advantage of this method is that the driver can access the shared memory buffer from an arbitrary process context, and at any IRQL.
There are a number of restrictions and caveats inherent in using METHOD_NEITHER to describe a shared memory buffer. Basically, these are the same ones that apply any time a driver uses this method. Chief among these is the rule that the driver must only access the buffer in the context of the requesting process. This is because access to the shared buffer is via the buffer’s user virtual address. This will almost certainly mean that the driver must be at the top of the device stack, called directly by the user application via the I/O Manager. There can be no intermediate or file system drivers layered above the driver. Again practically speaking, this probably also means that the driver is restricted to accessing the user buffer from within its dispatch routines, when called by the requesting process.
Another important restriction inherent in using METHOD_NEITHER is that access by the driver to the user buffer must always be done at IRQL PASSIVE_LEVEL. This is because the I/O manager hasn’t locked the user buffer in memory, and it could be paged out when accessed by the driver. If the driver can’t meet this requirement, it will need to build an MDL and then lock the buffer in memory.
Another, perhaps less immediately obvious, restriction to this method