KMDF Notification

Hi. I want my driver to notify a user mode thread when an event happens.

For WDM, the preferred method (Oney) seemed to be creating a shared event
and pass this to the driver with a DeviceIOControl. In the driver you would
use ObReferenceObjectByHandle to get to the event.

Is this still the preferred way under WDF?
Is it better to create a DeviceIOControl that waits for the event (either
directly or through an overlapped call)?
Or is WMI and WdfWmiInstanceFireEvent the way to go?

I have tried the DeviceIOControl call that waits for the event but that
stops other DeviceIOControl calls getting to the driver. This is with
SynchronisationScope set to None.

Any advice appreciated.
Thanks.
Laurence.

Don
Tue Apr 11 10:19:25 CDT 2006

If you are returning any sort of data to the user mode app, then the IOCTL
is always the preferred method, unless this is something that is going to be
a published interface then consider WMI. For the DeviceIoControl, are you
opening the device OVERLAPPED? If not this will block other IOCTL's till
the first is done.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply




"Laurence" <lhoward@baldor.com> wrote in message
news:eLQODnXXGHA.1476@TK2MSFTNGP03.phx.gbl...
> Hi. I want my driver to notify a user mode thread when an event happens.
>
> For WDM, the preferred method (Oney) seemed to be creating a shared event
> and pass this to the driver with a DeviceIOControl. In the driver you
> would use ObReferenceObjectByHandle to get to the event.
>
> Is this still the preferred way under WDF?
> Is it better to create a DeviceIOControl that waits for the event (either
> directly or through an overlapped call)?
> Or is WMI and WdfWmiInstanceFireEvent the way to go?
>
> I have tried the DeviceIOControl call that waits for the event but that
> stops other DeviceIOControl calls getting to the driver. This is with
> SynchronisationScope set to None.
>
> Any advice appreciated.
> Thanks.
> Laurence.
>
>
>
>

Doron
Tue Apr 11 23:37:18 CDT 2006

a shared event is not the way to go. just create a manual WDFQUEUE to put
the IOCTLs into and pop a request from the WDFQUEUE when an event occurs and
complete it. the app just opens the device as OVERLAPPED and will
asynchronously get the result.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Don Burn" <burn@stopspam.acm.org> wrote in message
news:OgQ$UtXXGHA.3800@TK2MSFTNGP03.phx.gbl...
> If you are returning any sort of data to the user mode app, then the IOCTL
> is always the preferred method, unless this is something that is going to
> be a published interface then consider WMI. For the DeviceIoControl, are
> you opening the device OVERLAPPED? If not this will block other IOCTL's
> till the first is done.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
>
> "Laurence" <lhoward@baldor.com> wrote in message
> news:eLQODnXXGHA.1476@TK2MSFTNGP03.phx.gbl...
>> Hi. I want my driver to notify a user mode thread when an event happens.
>>
>> For WDM, the preferred method (Oney) seemed to be creating a shared event
>> and pass this to the driver with a DeviceIOControl. In the driver you
>> would use ObReferenceObjectByHandle to get to the event.
>>
>> Is this still the preferred way under WDF?
>> Is it better to create a DeviceIOControl that waits for the event (either
>> directly or through an overlapped call)?
>> Or is WMI and WdfWmiInstanceFireEvent the way to go?
>>
>> I have tried the DeviceIOControl call that waits for the event but that
>> stops other DeviceIOControl calls getting to the driver. This is with
>> SynchronisationScope set to None.
>>
>> Any advice appreciated.
>> Thanks.
>> Laurence.
>>
>>
>>
>>
>
>

Maxim
Wed Apr 12 18:30:26 CDT 2006

> For WDM, the preferred method (Oney) seemed to be creating a shared event
> and pass this to the driver with a DeviceIOControl. In the driver you would
> use ObReferenceObjectByHandle to get to the event.

No, completing a pending IOCTL is much better.

> Is this still the preferred way under WDF?

IIRC KMDF has its own facility for this (or was it FltMgr? :-)

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Don
Wed Apr 12 18:46:13 CDT 2006


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message news:u%
> IIRC KMDF has its own facility for this (or was it FltMgr? :-)

It was FltMgr



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

Bruno
Fri Apr 14 12:03:19 CDT 2006

>a shared event is not the way to go. just create a manual WDFQUEUE to put
>the IOCTLs into and pop a request from the WDFQUEUE when an event occurs
>and complete it. the app just opens the device as OVERLAPPED and will
>asynchronously get the result.
>
> d

I never thought I'd see the day, but I can finally post a reply to the
device drivers newsgroup with the message 'Check out my article'
http://codeproject.com/system/kmdf_osr_usb_fx2.asp

I explain this technique in the chapter on handling IO controls and USB
interrupts.
Go me :-)

--

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"