Greetings and thanks for any advice.
My device takes in radar video and produces target track data. It divides
the radar picture into 2048 sectors (spokes) of 2048 radial data bins,
where each bin represents a discrete data range from the transmitter. So
the radar antenna is sitting there turning at about 30 rpm, which is 360
degrees every 2 seconds. The card generates an interrupt for every
sector, and thus interrupts 1024 times per second. At each interrupt, the
card has a spoke available in its memory buffer. My ISR needs to get that
data before the next interupt.
My design has the application program passing a user-mode virtual address
of a 2048x2048 byte buffer thru an IOCTL. My dispatch handler
MmProbeAndLock()s that buffer, and gets an MDL for it. My DpcForIsr DMAs
(the card is a busmaster) the spoke from the card into the user’s buffer.
And signals a event, also passed in by the user, when some
user-configurable number of spokes are received.
I chose this design so that the user didn’t have to issue 1024
DeviceIoControl() calls per second, and because of my timing issues.
My questions are:
- Do I really need to probe and lock the user’s entire buffer in my
Dispatch routine?
- Is this design typical for such a streaming type device, or is there
some better way that I don’t know about?
Thanks.
john reilly.
xxxxx@nexet.net
Sperry Marine.
You have to probe and lock the user buffer if you are doing dma into it.
My opinion is that locking down 4MB for what appears to be a real-time
operation is not excessive, and in fact is probably the only way to get the
kind of performance you need.
If you used one of the METHOD_*_DIRECT (as in OUT,) macros to define your
IOCTL, the OS would do the probe and lock for you, with the IOCTL output
buffer described by an MDL. Your IOCTL input buffer could contain the event
handle, and you would be ready to go with a lot less work on your driver’s
part.
-----Original Message-----
From: John Reilly [mailto:xxxxx@nexet.net]
Sent: Monday, August 12, 2002 9:31 AM
To: NT Developers Interest List
Subject: [ntdev] Driver Design Help
Greetings and thanks for any advice.
My device takes in radar video and produces target track
data. It divides the radar picture into 2048 sectors
(spokes) of 2048 radial data bins, where each bin represents
a discrete data range from the transmitter. So the radar
antenna is sitting there turning at about 30 rpm, which is
360 degrees every 2 seconds. The card generates an interrupt
for every sector, and thus interrupts 1024 times per second.
At each interrupt, the card has a spoke available in its
memory buffer. My ISR needs to get that data before the next
interupt.
My design has the application program passing a user-mode
virtual address of a 2048x2048 byte buffer thru an IOCTL. My
dispatch handler MmProbeAndLock()s that buffer, and gets an
MDL for it. My DpcForIsr DMAs (the card is a busmaster) the
spoke from the card into the user’s buffer.
And signals a event, also passed in by the user, when some
user-configurable number of spokes are received.
I chose this design so that the user didn’t have to issue 1024
DeviceIoControl() calls per second, and because of my timing issues.
My questions are:
- Do I really need to probe and lock the user’s entire
buffer in my Dispatch routine? 2. Is this design typical for
such a streaming type device, or is there some better way
that I don’t know about?
Thanks.
john reilly.
xxxxx@nexet.net
Sperry Marine.
You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%
> 1. Do I really need to probe and lock the user’s entire buffer in
my
Dispatch routine?
Use DO_DIRECT_IO, in this case IO manager will do this for you.
- Is this design typical for such a streaming type device, or is
there
some better way that I don’t know about?
More or less yes.
Max
> of a 2048x2048 byte buffer thru an IOCTL. My dispatch handler
MmProbeAndLock()s that buffer, and gets an MDL for it. My DpcForIsr
DMAs
Oh, sorry. You use IOCTLs, then you will need METHOD_xxx_DIRECT IOCTL
code.
DO_DIRECT_IO is for read/write only.
Max
Mark and Maxim,
Thanks for your responses. I have a question about your response.
If I define my IOCTL using METHOD_OUT_DIRECT, then the OS will probe and
lock my buffer. But how do I then tell the OS to leave the buffer locked
even after I complete the IOCTL’s IRP? And, if I don’t complete the IRP,
how does the user application ever get a return from the DeviceIoControl()
call? (Unless the call fails with a ERROR_IO_PENDING?)
Thanks again.
john reilly.
xxxxx@nexet.net
Sperry Marine.
You have to probe and lock the user buffer if you are doing dma into it.
My opinion is that locking down 4MB for what appears to be a real-time
operation is not excessive, and in fact is probably the only way to get the
kind of performance you need.
If you used one of the METHOD_*_DIRECT (as in OUT,) macros to define your
IOCTL, the OS would do the probe and lock for you, with the IOCTL output
buffer described by an MDL. Your IOCTL input buffer could contain the event
handle, and you would be ready to go with a lot less work on your driver’s
part.
> -----Original Message-----
> From: John Reilly [mailto:xxxxx@nexet.net]
> Sent: Monday, August 12, 2002 9:31 AM
> To: NT Developers Interest List
> Subject: [ntdev] Driver Design Help
>
>
> Greetings and thanks for any advice.
>
> My device takes in radar video and produces target track
> data. It divides the radar picture into 2048 sectors
> (spokes) of 2048 radial data bins, where each bin represents
> a discrete data range from the transmitter. So the radar
> antenna is sitting there turning at about 30 rpm, which is
> 360 degrees every 2 seconds. The card generates an interrupt
> for every sector, and thus interrupts 1024 times per second.
> At each interrupt, the card has a spoke available in its
> memory buffer. My ISR needs to get that data before the next
> interupt.
>
> My design has the application program passing a user-mode
> virtual address of a 2048x2048 byte buffer thru an IOCTL. My
> dispatch handler MmProbeAndLock()s that buffer, and gets an
> MDL for it. My DpcForIsr DMAs (the card is a busmaster) the
> spoke from the card into the user’s buffer.
> And signals a event, also passed in by the user, when some
> user-configurable number of spokes are received.
>
> I chose this design so that the user didn’t have to issue 1024
> DeviceIoControl() calls per second, and because of my timing issues.
>
> My questions are:
> 1. Do I really need to probe and lock the user’s entire
> buffer in my Dispatch routine? 2. Is this design typical for
> such a streaming type device, or is there some better way
> that I don’t know about?
>
> Thanks.
> john reilly.
> xxxxx@nexet.net
> Sperry Marine.
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>
You answered your own question. The IOCTL returns STATUS_PENDING, the
user app gets the win32 ERROR_IO_PENDING return code. (You have to use
overlapped IO for this to work.) You wrap the whole thing up in an api
function that hides all of this.
Note that your driver has to deal with application termination by
supporting cancel processing on the IOCTL IRP, and should also support
cleanup operations of the FileObject used for the IOCTL by supporting
IRP_MJ_CLEANUP.
===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
-----Original Message-----
From: “John Reilly”
To: “NT Developers Interest List”
Date: Thu, 15 Aug 2002 07:00:25 -0400
Subject: [ntdev] RE: Driver Design Help
> Mark and Maxim,
>
> Thanks for your responses. I have a question about your response.
>
> If I define my IOCTL using METHOD_OUT_DIRECT, then the OS will probe
> and
> lock my buffer. But how do I then tell the OS to leave the buffer
> locked
> even after I complete the IOCTL’s IRP? And, if I don’t complete the
> IRP,
> how does the user application ever get a return from the
> DeviceIoControl()
> call? (Unless the call fails with a ERROR_IO_PENDING?)
>
> Thanks again.
>
> john reilly.
> xxxxx@nexet.net
> Sperry Marine.
>
>
> > You have to probe and lock the user buffer if you are doing dma into
> it.
> >
> > My opinion is that locking down 4MB for what appears to be a
> real-time
> > operation is not excessive, and in fact is probably the only way to
> get the
> > kind of performance you need.
> >
> > If you used one of the METHOD_*_DIRECT (as in OUT,) macros to define
> your
> > IOCTL, the OS would do the probe and lock for you, with the IOCTL
> output
> > buffer described by an MDL. Your IOCTL input buffer could contain the
> event
> > handle, and you would be ready to go with a lot less work on your
> driver’s
> > part.
> >
> > > -----Original Message-----
> > > From: John Reilly [mailto:xxxxx@nexet.net]
> > > Sent: Monday, August 12, 2002 9:31 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Driver Design Help
> > >
> > >
> > > Greetings and thanks for any advice.
> > >
> > > My device takes in radar video and produces target track
> > > data. It divides the radar picture into 2048 sectors
> > > (spokes) of 2048 radial data bins, where each bin represents
> > > a discrete data range from the transmitter. So the radar
> > > antenna is sitting there turning at about 30 rpm, which is
> > > 360 degrees every 2 seconds. The card generates an interrupt
> > > for every sector, and thus interrupts 1024 times per second.
> > > At each interrupt, the card has a spoke available in its
> > > memory buffer. My ISR needs to get that data before the next
> > > interupt.
> > >
> > > My design has the application program passing a user-mode
> > > virtual address of a 2048x2048 byte buffer thru an IOCTL. My
> > > dispatch handler MmProbeAndLock()s that buffer, and gets an
> > > MDL for it. My DpcForIsr DMAs (the card is a busmaster) the
> > > spoke from the card into the user’s buffer.
> > > And signals a event, also passed in by the user, when some
> > > user-configurable number of spokes are received.
> > >
> > > I chose this design so that the user didn’t have to issue 1024
> > > DeviceIoControl() calls per second, and because of my timing
> issues.
> > >
> > > My questions are:
> > > 1. Do I really need to probe and lock the user’s entire
> > > buffer in my Dispatch routine? 2. Is this design typical for
> > > such a streaming type device, or is there some better way
> > > that I don’t know about?
> > >
> > > Thanks.
> > > john reilly.
> > > xxxxx@nexet.net
> > > Sperry Marine.
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> > > xxxxx@stratus.com To unsubscribe send a blank email to
> > > %%email.unsub%%
> > >
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%
“Mark Roddy” wrote in message news:xxxxx@ntdev…
…
> and should also support
> cleanup operations of the FileObject used for the IOCTL by supporting
> IRP_MJ_CLEANUP.
>
Unless I’m missing something, supporting _CLEANUP is an entirely unnecessary
complication in this case. All you get is another chance for your driver to
handle a potential race-condition. Support for cancel is sufficient.
Perhaps Mr. Roddy will illucidate me as to his thinking,
Peter
OSR
Heatstroke
===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
-----Original Message-----
From: “Peter Viscarola”
To: “NT Developers Interest List”
Date: Thu, 15 Aug 2002 09:51:56 -0400
Subject: [ntdev] Re: Driver Design Help
>
> “Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> …
> > and should also support
> > cleanup operations of the FileObject used for the IOCTL by supporting
> > IRP_MJ_CLEANUP.
> >
>
> Unless I’m missing something, supporting _CLEANUP is an entirely
> unnecessary
> complication in this case. All you get is another chance for your
> driver to
> handle a potential race-condition. Support for cancel is sufficient.
>
> Perhaps Mr. Roddy will illucidate me as to his thinking,
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%
> even after I complete the IOCTL’s IRP? And, if I don’t complete the
IRP,
how does the user application ever get a return from the
DeviceIoControl()
call? (Unless the call fails with a ERROR_IO_PENDING?)
The app’s thread with either be blocked in IopSynchronousServiceTail
till the IRP will be completed, or will return ERROR_IO_PENDING.
Max