My Driver needs to allocate and provide buffers as large as 4kb to its clients. This memory would be shared between my driver and clients for r/w. Client will write data into this buffer and will send it back to driver for processing. Both driver and clients reside in kernel space.
Need suggestions on how to allocate and share memory with clients? Can we do this using IOCTL’s direct I/O or buffered I/O method?
Can we achieve this by via export drivers and exposing interfaces for allocation/processing requests?
Which one is better approach? Is there any other way to share memory between kernel mode drivers?
If these are two kernel mode drivers, then they live in the same address
space and there is nothing special on sharing the memory. If these are Plug
and Play drivers consider using a device interface between the two drivers.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, July 25, 2014 2:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Efficient way to share memory between two kernel mode
drivers
My Driver needs to allocate and provide buffers as large as 4kb to its
clients. This memory would be shared between my driver and clients for r/w.
Client will write data into this buffer and will send it back to driver for
processing. Both driver and clients reside in kernel space.
Need suggestions on how to allocate and share memory with clients? Can we do
this using IOCTL’s direct I/O or buffered I/O method?
Can we achieve this by via export drivers and exposing interfaces for
allocation/processing requests?
Which one is better approach? Is there any other way to share memory between
kernel mode drivers?
> If these are two kernel mode drivers, then they live in the same address space and there is nothing
special on sharing the memory.
Well, there are still certain nasty details that must be considered…
For example, consider what happens if A gets unloaded and, in its Unload() routine, frees the shared buffers that it had allocated, but B does not know about it so that it keeps on writing to the shared buffer. To make things even nastier, releasing pool allocations does not invalidate their corresponding virtual address. Therefore, you have all chances to get truly random results in this situation - nothing will happen until memory gets reused by MM (because B will write to the memory that is not used by anyone), but after it has been reused corruption may occur (because B will write to the memory that is already owned by some other driver).
Another example of a dodgy scenario is the situation when A gets unloaded without signaling an event that
B is waiting on. If it happens, the resulting deadlock is not going to get resolved until the reboot.
Therefore, you have to design certain protocols for A- to- B communication to ensure that the above mentioned scenarios do not occur. I guess that pended IRPs and IOCTLs may be quite useful means of implementing these protocols…
Can WDM/non-WDF drivers co-exist with wdf drivers in wp8? If yes, if WDM driver communicates with WDF driver via IOCTLS, will it require any special handling? non-wdf wont be able to communicate to WDF driver via IOCTLS.
Of course they can. Nothing special is required. Outside of a WDFDEVICE, it interoperates with the rest of the OS and other drivers with underlying WDM constructs. WDF doesn’t knows it is talking to another WDF driver.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, July 27, 2014 9:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Efficient way to share memory between two kernel mode drivers
Can WDM/non-WDF drivers co-exist with wdf drivers in wp8? If yes, if WDM driver communicates with WDF driver via IOCTLS, will it require any special handling? non-wdf wont be able to communicate to WDF driver via IOCTLS.
What about non-WDF, non-WDM driver? can such a driver co-exist with WDM and WDF drivers? If so, is my understanding correct that it wont be able to communicate to WDF driver via IOCTLS so I should be using export driver to expose interface rather than IOCTLS.
What about non-WDF, non-WDM driver? can such a driver co-exist with WDM and WDF drivers? If so, is my understanding correct that it wont be able to communicate to WDF driver via IOCTLS so I should be using export driver to expose interface rather than IOCTLS.
No, your understanding is way off. Remember that KMDF is all about the way requests are HANDLED. It doesn?t have anything to do with external interfaces. KMDF ends at the driver boundary. From the outside, a KMDF driver looks like a WDM driver, because it IS a WDM driver. The kernel itself doesn?t know anything about KMDF.
The primary way to pass requests from driver to driver is via IoCallDriver. At that point, no one cares whether it is WDM or KMDF. Only after the request is received does KMDF get involved. Then, when your driver passes things along, the request once again becomes a plain old IRP, and KMDF is no longer involved.
IRPs and ioctls are universal. Every driver handles them. KMDF doesn?t change that in the slightest. It only changes the way your driver plays with the IRPs it receives.