Well, I named some specifics, but okay, how about this:
show a DMA device with interrupts, cancellable in-progress IRPs and a DMA
start timeout timer. This hits a lot of the ugly synchronization cases I
can think of. Particularily, you would have an ISR, DPC, timer callback,
and cancel routine all competing to complete the same IRP. And, handling
the case of a piece of DMA hardware that clears the interrupt register on
check, (that is hardware you can only check once to see if it interrupted),
would be good. Not having a hardware check in the DpcForIsr makes checking
for the correct IRP there a virtual nightmare.
A driver with multiple queues, say separate queues for reads and writes,
would be really handy just to show people its possible and how.
Then, something like a serial driver using the new queue library would round
out everything I could imagine anyone would need. The serial driver handles
I/O in a much different manner than a typical DMA driver, multiple
interrupts per IRP, lots of ISR synchronization and such.
So, why didn’t you guys release the source to the library? I can’t think
there would really be any critical IP in there would there? As in, I
wouldn’t expect you are using any non-standard DDK calls. Just curious, it
really surprised me that source for this wasn’t included in the DDK.
–
Bill McKenzie
“Nar Ganapathy [MS]” wrote in message
news:xxxxx@ntdev…
>
> If you have specific guidelines or examples on what the sample should do,
> please send feedback to this newgroup or to Microsoft directly and we will
> try to improve the sample.
>
> –
> This posting is provided “AS IS” with no warranties, and confers no
rights.
> “Bill McKenzie” wrote in message
> news:xxxxx@ntdev…
> >
> > BTW, just checked out the new cancel-safe queue library documentation
and
> it
> > is usable on 98/Me, but I have no idea why they incorporated the code
into
> > the OS on XP instead of leaving it a library. As it is, it is
impossible
> to
> > use this library in one cross platform binary, which is most
unfortunate.
> > Further, that cancel sample in the DDK doesn’t show much. It really
> doesn’t
> > show any of the hard stuff related to queuing IRPs, like in-progress
> > cancellable IRPs, dealing with ISR/ DPC/StartIo synchronization
problems,
> > lots of hard cases. Kind of disappointing really.
> >
> > Further, I really wish they would have included the source for the
> library,
> > as I am curious how they solved some of the delicate synchronization
> > problems inherent with these queues. Not saying I don’t trust them, but
> it
> > would be good to be able to check what is going on here. Having gone
> > through writing a cancel-safe queue with a team of some of the best
> > developers in the business, I know how easy it is to get this code
wrong.
> >
> > –
> > Bill McKenzie
> >
> >
> >
> > “Bill McKenzie” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > It would be perfectly reasonable for you to do this, further, you
don’t
> > ever
> > > have to put this IRP in the queue to begin with if it doesn’t need to
be
> > > queued. It is quite common for a driver to queue a specific type of
IRP
> > > say, IRP_MJ_READ, and not queue others, like IRP_MJ_WRITE,
> > > IRP_MJ_DEVICE_CONTROL, etc. Queuing is a serialization methodology,
but
> > if
> > > your IRPs don’t need to be serialized, don’t use a queue for them.
> > >
> > > Further, I would NEVER use system queuing anymore. The system queue
> uses
> > > and abuses the system wide cancel spinlock. This spinlock is a single
> > > global resource used by every driver in the system. Over use of this
> lock
> > > stomps system performance. So, you would be better off using a driver
> > queue
> > > and minimizing the use of this resource. There is a new library
> available
> > > for 2000 and later, (and maybe earlier OSes, I just don’t know), that
is
> > > supposed to help you create a cancel-safe driver IRP queue. It comes
> with
> > > the latest DDKs. I have never used it, because while I was at
BlueWater
> > and
> > > BSquare I used the WinDK toolkit which provided its own cancel-safe
IRP
> > > queues. In fact looking at the new library in the DDK I see that the
> > WinDK
> > > functions and the new DDK library functions are AMAZINGLY similar.
> There
> > is
> > > a sample in the newer DDKs under \src\general\cancel that shows how to
> use
> > > the new DDK library.
> > >
> > > Anyway, I probably told you more than you needed to know here, but I
> hope
> > I
> > > answered your question.
> > >
> > > –
> > > Bill McKenzie
> > >
> > >
> > >
> > > “lists.osr.com” wrote in message
news:xxxxx@ntdev…
> > > >
> > > > Hi Everybody,
> > > >
> > > > In “Windows NT Device Driver Development” by Viscarola and
Mason,
> > > there
> > > > are a couple of statements that say slightly different things to me
> (as
> > I
> > > > read it).
> > > >
> > > > In Chapter 14 with regard to System Queueing it says “Drivers
that
> > use
> > > > System Queueing can have only one operation per device in progress
at
> a
> > > > time.” Right after that there is a note which says “Using system
> > Queueing
> > > > implies that only one IRP can be in progress per device at a time.”
> The
> > > > word “implies” says to me “but not neccesarily”. Thus my confusion.
> > > >
> > > > So my question is, if I use System Queueing why can’t I take the
> IRP
> > > > that is being processed by my StartIo routine, stash the pointer
> away,
> > > > remove it from the queue, and then call IoStartNextPacket, and
> complete
> > > the
> > > > original IRP sometime later when I see fit? What problem’s might I
> > > > eventually run into.
> > > >
> > > > My device is a PCI device and the IRP in question specifically
> does
> > > not
> > > > touch the hardware (but rather is simply waiting for a periodic
event
> > > > message to come back from the device). The OS is NT4.0 SP6a.
> > > >
> > > > Thanks,
> > > > Joe
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
