Prev: Install VHidMini.sys as 1st HID Driver Problems
Next: DPInst and virtual drivers (e.g. MSVAD)
From: Aniketa K S on 5 Jul 2007 03:03

Hi,

I need to share memory between user mode application and the NDIS60
Miniport driver:

1. Allocate memory in user space. In driver, I use NdisAllocateMdl
(which will also build MDL and lock the pages depending on the buffer
is from Non Paged pool or not). Then I call
MmGetSystemAddressForMdlSafe to get the driver accessible address. So
will this non NDIS routine (MmGetSystemAddressForMdlSafe) be approved
by WHQL if used in NDIS driver? The DDK points to use this routine
instead of NdisBufferVirtualAddressSafe which is not supported in
NDIS60.

2. Allocate memory in kernel space. I see that the
MmGetSystemAddressForMdlSafe is a macro internally calling
MmMapLockedPagesSpecifyCache function with KernelMode as AccessMode.
Will WHQL approve (assuming MmGetSystemAddressForMdlSafe is approved)
if I use the later routine to map memory to user space?

Please let me know.

Thanks,
Aniketa

From: Anton Bassov on 5 Jul 2007 03:38
> I need to share memory between user mode application and the NDIS60
> Miniport driver:

In most cases sharing memory between driver an app is unreasonable - it is
much better to rely upon "inverted call" technique... The problem is that you
have to synchronize access to the buffer,which, in practical terms, washes
away all potential performance benefits you are expecting to gain, but
sharing memory gives you quite a few unnecessary worries and complication .
It may be not a bad option if you have to transfer huge amounts of data
frequently, but NDIS miniport is
not the right kind of device for it. I somehow presume that your transfers
are small
and infrequent - after all, the main bulk of incoming/outgoing data traffic
goes via
the protocol drivers, so that, apparently, you just need something
"non-traditional" once in a while....

> 1. Allocate memory in user space.

"Great" idea....

What if the target app where a buffer in question resides abnormally
terminates????
What is going to happen the next time a driver tries to access this memory???
As you can see already, sharing memory gives you unnecessary compliations
that can be avoided by using "inverted call" instead.....

> 2. Allocate memory in kernel space.

Even "better"....

What if some buggy app corrupts kernel memory??? Therefore, the above
approach is extremely unsafe and should be avoided....

Anton Bassov

"Aniketa K S" wrote:

>
> Hi,
>
> I need to share memory between user mode application and the NDIS60
> Miniport driver:
>
> 1. Allocate memory in user space. In driver, I use NdisAllocateMdl
> (which will also build MDL and lock the pages depending on the buffer
> is from Non Paged pool or not). Then I call
> MmGetSystemAddressForMdlSafe to get the driver accessible address. So
> will this non NDIS routine (MmGetSystemAddressForMdlSafe) be approved
> by WHQL if used in NDIS driver? The DDK points to use this routine
> instead of NdisBufferVirtualAddressSafe which is not supported in
> NDIS60.
>
> 2. Allocate memory in kernel space. I see that the
> MmGetSystemAddressForMdlSafe is a macro internally calling
> MmMapLockedPagesSpecifyCache function with KernelMode as AccessMode.
> Will WHQL approve (assuming MmGetSystemAddressForMdlSafe is approved)
> if I use the later routine to map memory to user space?
>
> Please let me know.
>
> Thanks,
> Aniketa
>
>
From: Aniketa K S on 5 Jul 2007 05:14
On Jul 5, 12:38 pm, Anton Bassov
<AntonBas...(a)discussions.microsoft.com> wrote:
> > I need to share memory between user mode application and the NDIS60
> > Miniport driver:
>
> In most cases sharing memory between driver an app is unreasonable - it is
> much better to rely upon "inverted call" technique... The problem is that you
> have to synchronize access to the buffer,which, in practical terms, washes
> away all potential performance benefits you are expecting to gain, but
> sharing memory gives you quite a few unnecessary worries and complication .
> It may be not a bad option if you have to transfer huge amounts of data
> frequently, but NDIS miniport is
> not the right kind of device for it. I somehow presume that your transfers
> are small
> and infrequent - after all, the main bulk of incoming/outgoing data traffic
> goes via
> the protocol drivers, so that, apparently, you just need something
> "non-traditional" once in a while....
>
> > 1. Allocate memory in user space.
>
> "Great" idea....
>
> What if the target app where a buffer in question resides abnormally
> terminates????
> What is going to happen the next time a driver tries to access this memory???
> As you can see already, sharing memory gives you unnecessary compliations
> that can be avoided by using "inverted call" instead.....
>
> > 2. Allocate memory in kernel space.
>
> Even "better"....
>
> What if some buggy app corrupts kernel memory??? Therefore, the above
> approach is extremely unsafe and should be avoided....
>
> Anton Bassov
>
> "Aniketa K S" wrote:
>
> > Hi,
>
> > I need to share memory between user mode application and the NDIS60
> > Miniport driver:
>
> > 1. Allocate memory in user space. In driver, I use NdisAllocateMdl
> > (which will also build MDL and lock the pages depending on the buffer
> > is from Non Paged pool or not). Then I call
> > MmGetSystemAddressForMdlSafe to get the driver accessible address. So
> > will this non NDIS routine (MmGetSystemAddressForMdlSafe) be approved
> > by WHQL if used in NDIS driver? The DDK points to use this routine
> > instead of NdisBufferVirtualAddressSafe which is not supported in
> > NDIS60.
>
> > 2. Allocate memory in kernel space. I see that the
> > MmGetSystemAddressForMdlSafe is a macro internally calling
> > MmMapLockedPagesSpecifyCache function with KernelMode as AccessMode.
> > Will WHQL approve (assuming MmGetSystemAddressForMdlSafe is approved)
> > if I use the later routine to map memory to user space?
>
> > Please let me know.
>
> > Thanks,
> > Aniketa

Hi Anton,

What is the "inverted call" technique you have mentioned? Can you
elaborate it? But as for the issues that comes with sharing, I am
aware of them and the necessary precautions to be taken.

Coming to the actual question, will WHQL approve the Mmxxx functions I
have mentioned?

Thanks,
Aniketa

From: Anton Bassov on 5 Jul 2007 05:54
> What is the "inverted call" technique you have mentioned? Can you
> elaborate it?

Basically, just asynch IO - an app send a request to a driver; a driver
pends it and completes the request when it wants to inform an app about some
event and/or pass it some data. Check OSR archives for more detailed info.

> Coming to the actual question, will WHQL approve the Mmxxx functions I
> have mentioned?

IIRC, in one of discussions I participated in it was mentioned that,
starting from NDIS 6, miniports can call non-NDIS functions and still be
approved by WHQL.
However, I may be wrong here.....

Anton Bassov
"Aniketa K S" wrote:

> On Jul 5, 12:38 pm, Anton Bassov
> <AntonBas...(a)discussions.microsoft.com> wrote:
> > > I need to share memory between user mode application and the NDIS60
> > > Miniport driver:
> >
> > In most cases sharing memory between driver an app is unreasonable - it is
> > much better to rely upon "inverted call" technique... The problem is that you
> > have to synchronize access to the buffer,which, in practical terms, washes
> > away all potential performance benefits you are expecting to gain, but
> > sharing memory gives you quite a few unnecessary worries and complication .
> > It may be not a bad option if you have to transfer huge amounts of data
> > frequently, but NDIS miniport is
> > not the right kind of device for it. I somehow presume that your transfers
> > are small
> > and infrequent - after all, the main bulk of incoming/outgoing data traffic
> > goes via
> > the protocol drivers, so that, apparently, you just need something
> > "non-traditional" once in a while....
> >
> > > 1. Allocate memory in user space.
> >
> > "Great" idea....
> >
> > What if the target app where a buffer in question resides abnormally
> > terminates????
> > What is going to happen the next time a driver tries to access this memory???
> > As you can see already, sharing memory gives you unnecessary compliations
> > that can be avoided by using "inverted call" instead.....
> >
> > > 2. Allocate memory in kernel space.
> >
> > Even "better"....
> >
> > What if some buggy app corrupts kernel memory??? Therefore, the above
> > approach is extremely unsafe and should be avoided....
> >
> > Anton Bassov
> >
> > "Aniketa K S" wrote:
> >
> > > Hi,
> >
> > > I need to share memory between user mode application and the NDIS60
> > > Miniport driver:
> >
> > > 1. Allocate memory in user space. In driver, I use NdisAllocateMdl
> > > (which will also build MDL and lock the pages depending on the buffer
> > > is from Non Paged pool or not). Then I call
> > > MmGetSystemAddressForMdlSafe to get the driver accessible address. So
> > > will this non NDIS routine (MmGetSystemAddressForMdlSafe) be approved
> > > by WHQL if used in NDIS driver? The DDK points to use this routine
> > > instead of NdisBufferVirtualAddressSafe which is not supported in
> > > NDIS60.
> >
> > > 2. Allocate memory in kernel space. I see that the
> > > MmGetSystemAddressForMdlSafe is a macro internally calling
> > > MmMapLockedPagesSpecifyCache function with KernelMode as AccessMode.
> > > Will WHQL approve (assuming MmGetSystemAddressForMdlSafe is approved)
> > > if I use the later routine to map memory to user space?
> >
> > > Please let me know.
> >
> > > Thanks,
> > > Aniketa
>
> Hi Anton,
>
> What is the "inverted call" technique you have mentioned? Can you
> elaborate it? But as for the issues that comes with sharing, I am
> aware of them and the necessary precautions to be taken.
>
> Coming to the actual question, will WHQL approve the Mmxxx functions I
> have mentioned?
>
> Thanks,
> Aniketa
>
>
 | 
Pages: 1
Prev: Install VHidMini.sys as 1st HID Driver Problems
Next: DPInst and virtual drivers (e.g. MSVAD)