See below…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, December 19, 2008 1:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handing kernel interrupts in application
I was advised here to use the inverted call pattern to handle kerenl
interrupts in my application.
Well, what else would one expect from a “good adviser” on this list (IIRC,
in this particular case it was Doron who suggested “inverted call”)???
After all, this is very typical for this list - once inverted call is
supposed to be “better” than using events, everyone here would say “use
inverted call” without even thinking about the problem in question, despite
the fact that using events may be much more appropriate in a given
situation.
IMHO, in situations like that inverted call is simply unreasonable for the
reasons we have discussed here, i.e. you cannot calculate the queue size in
advance. Look at your original solution presented on another thread
[begin quote]
-
The WDF driver handles the interrupt in the ISR and sends a requesr to
IsrDPC.
-
IsrDPC calls KeSetEvent (&Event, IO_NO_INCREMENT, FALSE);
-
The application sends an IOCTL code to check if an interrupt occured.
-
The IOCTL handler calls:
4.1 KeWaitForSingleObject(&Event,Executive,KernelMode,FALSE,NULL);
****
*
4.1.5: The driver handles an interrupt and does a KeSetEvent
*
****
4.2 KeClearEvent (&Event)
4.3 WdfRequestComplete(Request, 0);
Is this the optimal mechanism ?
[end quote]
IMHO, in actuality steps 1 to 3 , indeed, describe an optimal solution that
looks pretty much like fctl() - select() -read() sequence on UNIX. Such
solution eliminates the problem that we are speaking about here. The only
thing that needs modification is step 4. What you need here is a custom
queue protected by a spinlock, and UM event ( I would rather use
synchronization, rather than notification, event , so that it gets
automatically reset when UM WaitForSingleObject() returns control).
UM application submits event handle with IOCTL ABC and then gets into the
following infinite loop:
while(1)
{
WaitForSingleObject(…);
DeviceIoControl (IOCTL XYZ,…);
… process retrieved data
}
DPC inserts an element describing a given occurrence of interrupt into a
queue and signals the event. As a result, the waiting thread gets unblocked
and sends an IOCTL XYZ to a driver ( METHOD_BUFFERED is, of course , the
most appropriate IO method here) . IOCTL handler copies all data from the
queue to a system buffer, and frees queue elements. Access to the queue is
synchronized with a spinlock, so that DPC and IOCTL handler don’t get into
the race conditions with one another. Pure and simple - no problem either
with a queue size or synchronization…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.