Sharing memory between user and kernel applications
Arsalan Ahmad
Could any one please tell me what are different possible ways to share
memory between a user level application and a kernel level driver?
I am interested in transferring data from kernel driver to user level
application and vice versa. In my current implementation, the user-level
application uses ReadFile(), WriteFile() to read and write data from/to
kernel driver. However I am looking on different ways to improve this
transfer of data. So is it possible to share a memory block between user
application and kernel driver to transfer data between them in fastest
possible way?
Any hint or idea will be appreciated.
Thanks,
Arsalan
anton bassov
> application and kernel driver to transfer data between them in fastest
> possible way?
Of course it is possible - just pass an adress to the buffer that
resides in the app's user address space, to the driver with IOCTL, and
make driver build MDL of this buffer and lock pages in it. At this
point your driver will be able to access memory, referred by this
buffer, as a kernel address, and to do so in context of any thread.
However, such approach creates a potential security hole, so that
sharing memory between an app and a driver is not very good idea in
itself, unless you have a deadly serious reason to do something like
that
What are you trying to do? Maybe, there is something better than
sharing memory (for example, IOCTLs and inverse calls)??? Certainly, IO
Manager's involvement on every data transfer may involve some
overhead, but how significant it is???? Let's face it - if the whole
thing involves app somehow, it cannot be time-critical anyway.
Anton Bassov
Don Burn
interface needs extremely high (multiple 100MB/sec) bandwidth. The problem
is you are not going to improve the transfer, you are going to mess it up.
For instance you can use shared memory, but how do you synchronize the
accesses between the user space and the kernel, if you use system calls
your overhead is worse than calling read and write. This is a commonly
asked question, and I have rarely seen the large effort pay off (only time
it has was for large video transfers), but I have seen it slow down the
computer or worse yet crash things often.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
"Arsalan Ahmad" <ars...@hotmail.com> wrote in message
news:%23Kw43jq...@TK2MSFTNGP06.phx.gbl...
Arkady Frenkel
http://www.microsoft.com/whdc/driver/kernel/KM-UMGuide.mspx
Arkady
"anton bassov" <soviet...@hotmail.com> wrote in message
news:1166011699.4...@16g2000cwy.googlegroups.com...
soviet...@hotmail.com
In fact, I am not sure what the OP is up to, but I would say that there
is at least 95% chance that he can handle everything with IOCTLs and
inverse calls - situations when the above things are not sufficient are
quite rare, although still possible.....
Anton Bassov
Don Burn
I believe 95% is a way to low estimate, my guess is that there is a
99.9995% chance that doing anything other than standard calls is just going
to cause problems not improve things.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
<soviet...@hotmail.com> wrote in message
news:1166018199.0...@j44g2000cwa.googlegroups.com...
anton bassov
Certainly, when it comes to the actual performance, everything depends
on *HOW* the OP does things, but, in terms of implementation,
"non-standard" approach will DEFINITELY introduce some complexities
that are, in vast majority of cases, simply not needed.....
To make things worse, unless you really know what you are doing, these
code complexities may easily transform themselves into performance
problems , and, once the OP seems to be a newbie, this is more than
likely to happen here......
Don Burn
For the most part I think we are in violent agreement. I will add
that I have found a number of subtle crashes that occur thanks to shared
memory approaches, most of them in drivers that the company believes are
solid and that cannot be the problem. Worse yet, in almost every case,
reverting to a standard model without shared memory speeds up the data
path.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
"anton bassov" <soviet...@hotmail.com> wrote in message
news:1166025039.3...@f1g2000cwa.googlegroups.com...
soviet...@hotmail.com
> For the most part I think we are in violent agreement.
In fact, I would say that were are in complete agreement....
To be honest, I can imagine only one case when sharing a buffer may be
usefull, so that my statement about 95% of cases is based solely upon
the assumption that, once my imagination may be just too poor,
probably it makes sense to leave 5% margin....
The only case that gets into my head is a situation when your
application has to make a scatter-gather DMA transfer of a *HUGE*
amount of data, so that it would prefer to do everything in one go, or
at least to minimize the number of DMA operations.
In such case it can allocate a buffer, lock it in RAM, and pass it to a
driver, so that driver can build MDL, describing the buffer, and use
this MDL for building scatter-gather list (once pages had been already
locked it RAM, driver does not need to lock and unlock MDL)
Kevin
Write a SCSI miniport to implement a "virtual" scsi-device, and expose a
kernel-mode interface that your REAL driver gets notified-of and uses to
access a buffer that your APP sends down after opening your "virtual" scsi
device. The data buffer is all locked and ready by the scsi-port driver,
and you don't need to deal with ioctl codes, just handle IRP_MJ_READ.
But, you do have to write a SCSI miniport, which is not trivial, but plenty
of boilerplate code is available, and mostly everything hardware related is
skipped (must use an ISA bus, though, for historical reasons).
Your REAL driver gets notified of the SCSI miniport interface, and calls via
the interface to supply the address of a function that the SCSI miniport
will call when the APP buffer is ready.
Your APP calls ReadFile() on your scsi-device, and your SCSI miniport,
during IRP_MJ_READ, calls the REAL driver with the buffer address.
The REAL driver can use then use the APP-provided buffer as it wishes.
When the REAL driver is ready to return the data to the APP, it calls the
SCSI miniport via the interface to notify it that the data is ready.
The SCSI miniport completes IRP_MJ_READ.
When the APP returns from ReadFile(), the buffer is ready with data from the
REAL kernel driver.
The nice thing about this is that it separates out the kernel-mode
implementation details from the APP: no sharing of ioctl codes. Instead,
the kernel mode components are synced via the interface definition. You can
rebuild the kernel mode components without rebuilding the app.
Also, serializing multiple reads is handled for you by the scsi-port driver,
so you don't have to re-invent the wheel handling multiple apps making
simultaneous ioctl calls.
Not so sure about this, but overlapped i/o is probably handled easier than
coding in support for overlapped ioctls.
Marketing requirements may disallow adding a Device to the system!! The
flip-side is you can define a new device class for your virtual scsi-device,
with a new icon, and device-specific property pages!!
"Arsalan Ahmad" <ars...@hotmail.com> wrote in message
news:%23Kw43jq...@TK2MSFTNGP06.phx.gbl...
soviet...@hotmail.com
Now compare your "solution" to so - called "inverted call" (which is
nothing more than just asynchronous IO from the app's perspective) -
you simply pend an IOCTL, and complete it when driver wants to inform
an application about some event and/or pass data to it....
Which approach is more reasonable ?????
For the purpose of this discussion, I am intentionally going to avoid
the detailed analysis of all nonsense that you have said in your post.
However, I just cannot hold myself back from commenting the
"masterpiece" below :
[begin quote]
> Not so sure about this, but overlapped i/o is probably handled easier than
> coding in support for overlapped ioctls.
[end quote]
In other words, IOCTL requests, in your opinion, cannot qualify for
being IO operations.....
It looks like you will never change.....
Anton Bassov
Don Burn
complicated device to get right. Second, you are having to expose some
sort of SCSI device that is likely to have a device stack layered over it.
Third you do realize that a virtual SCSI miniport will never pass WHQL
which for many firms getting the driver signed is a requirement.
Sorry, this is truly stupid. If you want a READ interface instead of an
IOCTL this can be done by having a second device object and registering it
for DIRECT_IO. Of course if you need to pass something down to the driver
as well as send data to the application, read as an approach stinks, since
you have to play games to coordinate WRITE's to the driver with data, with
reads from the driver.
Hopefully the OP will totally ignore this stupid suggestion.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
"Kevin" <kev...@hutmail.org> wrote in message
news:O3QNB09I...@TK2MSFTNGP04.phx.gbl...
Kevin
I must have missed "unless they are COMPLICATED, NON-CERTIFIABLE or
STUPID!!"
So, I guess this idea might not go over so well:
Embed your driver in a virtual audio device. When you want to receive data
in your app, open up a channel for recording. To send data, play it back as
sound.
Side benefit: you can "hear" your data!!
Downside: may cause bleeding of the ears.
Or this one:
Write a mirror display device driver. In your app, create a window. In the
driver, transfer data by blitting it to the window. In the app, read the
data in WM_ERASEBKGND.
Side benefit: you can "see" your data!!
Downside: your data might render as Anton Bassov sans clothing.
David Jones
> Oh, I read the part that said "any hint or idea".
>
> I must have missed "unless they are COMPLICATED, NON-CERTIFIABLE or
> STUPID!!"
Does it really have to be explicitly stated that "any hint or idea"
refers to "any /good/ hint or idea"?
David