Porting existing WDM driver to KMDF, I need to reproduce the following functionality. User-mode client creates event and passes event handle to the driver using DeviceIoControl. Driver calls ObReferenceObjectByHandle and keeps this handle in PKEVENT field. I know that I must use EvtIoInCallerContext for this, because event handler is valid only in caller thread context.
Questions: does EvtIoInCallerContext reduce the whole driver performance? Is there any other way to get the same functionality, when driver sets event, and user mode client waits for this event? For example, named events, or anything else, which allows not no use EvtIoInCallerContext?
Alex Farber wrote:
Porting existing WDM driver to KMDF, I need to reproduce the following functionality. User-mode client creates event and passes event handle to the driver using DeviceIoControl. Driver calls ObReferenceObjectByHandle and keeps this handle in PKEVENT field. I know that I must use EvtIoInCallerContext for this, because event handler is valid only in caller thread context.
Questions: does EvtIoInCallerContext reduce the whole driver performance? Is there any other way to get the same functionality, when driver sets event, and user mode client waits for this event? For example, named events, or anything else, which allows not no use EvtIoInCallerContext?
I don’t think EvtIoInCallerContext will kill performance, especially since you’re just using it once to pass the event handle.
However, I don’t like EvtIoInCallerContext in general; what I don’t like is how the semantics can change later if your driver has an upper filter attached.
Named events should work (I’ve never tried it), and sounds like it would be the fastest way to get it working for your situation. You’d just have to examine the details of what the event name should be (to make it global instead of per-session), and try to choose a name that wouldn’t be used by anything else.
My method of choice for driver-app communication is the “inverted call” - the user-mode app opens a handle to the device and starts an overlapped operation with a special IOCTL. When the driver completes the IOCTL, then the overlapped operation completes (which usually signals an event in the user-mode app).
As with any solution, there are details to consider: if the events come in quickly and the user-mode app doesn’t have an outstanding IOCTL at the time one comes in, then the driver has to decide to drop or queue them (remembering to check for open handles on the device), etc. How you handle these kinds of situations depends on what exactly your device+app is trying to do.
This paper gives an overview of various types of driver-app communication:
http://www.microsoft.com/whdc/driver/kernel/KM-UMGuide.mspx
Also see this blog post for more resources:
http://blogs.msdn.com/iliast/archive/2007/10/06/driver-driver-and-driver-application-communication.aspx
Best regards,
-Stephen Cleary
xxxxx@yahoo.com wrote:
Porting existing WDM driver to KMDF, I need to reproduce the following functionality. User-mode client creates event and passes event handle to the driver using DeviceIoControl. Driver calls ObReferenceObjectByHandle and keeps this handle in PKEVENT field. I know that I must use EvtIoInCallerContext for this, because event handler is valid only in caller thread context.
Questions: does EvtIoInCallerContext reduce the whole driver performance?
What leads you to think this might be true? I’d like to know what led
to this.
If you think about how KMDF must be architected, I think the answer
becomes pretty clear. Without the InCallerContext callback, KMDF gets
the request, finds the queue it belongs in, queues it, pends the
message, returns to the caller, and queues up a callback to process the
queue.
When the callback is present, the KMDF just bypasses that whole process
and calls EvtIoInCallerContext instead. It’s then up to the
InCallerContext handler to decide how to process the request. If the
callback decides the normal processing is appropriate, it calls
WdfDeviceEnqueueRequest. If not, it doesn’t.
It’s just an alternate path. There should be no measurable performance
difference.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
EvtIoInCallerContext does not have a perf impact, it is just another call in the io processing pipeline.
However, I don’t like EvtIoInCallerContext in general; what I don’t like is how the semantics can change later if your driver has an upper filter attached.
In reality, what is the likelyhood of a filter showing up? Also, filters have to play by the rules of the stack they are filering. Amongst these rules are the context in which the lower stack processes io, so if a filter is changing the context for this IOCTL, it is a bug in the filter
Named events should work (I’ve never tried it), and sounds like it would be the fastest way to get it working for your situation. You’d just have to examine the details of what the event name should be (to make it global instead of per-session), and try to choose a name that wouldn’t be used by anything else.
Named events are problematic b/c of multiple users logged in and security. If it is named, anyone with the right access rights can open it and modify the state. If you create an anonymous event like the OP is talking about, it can only be shared by the app that created the event and whomever the app chooses to share it with.
The problem with events is that if there is data associated with setting the event, you must then track state and send an IOCTL down to the driver to retrieve the information. The inverted call model is typically the answer to this problem (as steve suggested), since the event and data (the output buffer of the pended IOCTL) are tied into the same notification. As for receiving a hardware event w/no pended user mode notification requests, yes you must implement some sort of policy (throw it away, store it and complete requests immediately with the info when one finally arrives), but that is not such a big deal (and must still exist if you have a PKEVENT and there is data associated with setting it). You can brute force the issue though, just have the app send down an excessive number of IOCTLs to pend (let’s say 50 
)
D
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, June 19, 2008 7:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Raising event from KMDF driver
Alex Farber wrote:
Porting existing WDM driver to KMDF, I need to reproduce the following functionality. User-mode client creates event and passes event handle to the driver using DeviceIoControl. Driver calls ObReferenceObjectByHandle and keeps this handle in PKEVENT field. I know that I must use EvtIoInCallerContext for this, because event handler is valid only in caller thread context.
Questions: does EvtIoInCallerContext reduce the whole driver performance? Is there any other way to get the same functionality, when driver sets event, and user mode client waits for this event? For example, named events, or anything else, which allows not no use EvtIoInCallerContext?
I don’t think EvtIoInCallerContext will kill performance, especially since you’re just using it once to pass the event handle.
However, I don’t like EvtIoInCallerContext in general; what I don’t like is how the semantics can change later if your driver has an upper filter attached.
Named events should work (I’ve never tried it), and sounds like it would be the fastest way to get it working for your situation. You’d just have to examine the details of what the event name should be (to make it global instead of per-session), and try to choose a name that wouldn’t be used by anything else.
My method of choice for driver-app communication is the “inverted call” - the user-mode app opens a handle to the device and starts an overlapped operation with a special IOCTL. When the driver completes the IOCTL, then the overlapped operation completes (which usually signals an event in the user-mode app).
As with any solution, there are details to consider: if the events come in quickly and the user-mode app doesn’t have an outstanding IOCTL at the time one comes in, then the driver has to decide to drop or queue them (remembering to check for open handles on the device), etc. How you handle these kinds of situations depends on what exactly your device+app is trying to do.
This paper gives an overview of various types of driver-app communication:
http://www.microsoft.com/whdc/driver/kernel/KM-UMGuide.mspx
Also see this blog post for more resources:
http://blogs.msdn.com/iliast/archive/2007/10/06/driver-driver-and-driver-application-communication.aspx
Best regards,
-Stephen Cleary
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
I must keep driver interface unchanged on the first step, so EvtIoInCallerContext is my current choice. For future work, I will use information provided in this thread. Thank you.