Hi there!
I´m very confused about communications between my application and my driver, that was build under Microsoft UMDF 1.0. Should I comm using CreateFile, WriteFile and ReadFile, likewise former frameworks?
Thank you so much!
Lucas M. Bracher
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
That, and DeviceIoControl (if you defined and used IOCTLs).
Ok. And how I can “wake up” my application to send data from driver to application? Same way I make callbacks in dlls?
Thanks!
Bob Kjelgaard escreveu: That, and DeviceIoControl (if you defined and used IOCTLs).
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
---------------------------------
Yahoo! Search
Música para ver e ouvir: You’re Beautiful, do James Blunt
Lucas Bracher wrote:
Ok. And how I can “wake up” my application to send data
from driver to application? Same way I make callbacks in dlls?
Just pend some IOCTLs inside your driver, and when you need to communicate something back to userspace, complete them.
Your driver and the application reside in separate address spaces, so callbacks of this sort aren’t generally something to attempt. Not that people don’t at least try to cheat that principle on occasion…
One way of accomplishing this is to have a “wait for input” IOCTL that the app sends to the driver. The driver pends it until input is ready, then completes it, perhaps with some details as to how much is available (on an IOCTL you can define the input and output blocks, so this is usually plenty of flexibility for this sort of a need). The serial driver sample in the DDK/WDK uses this approach. Your app thread can basically just synchronously send this, and do the I/O after it returns. IN practice, you usually add some timeout and cancellation logic on both ends of that, but I believe the sample shows a fine way to handle that.
Another is to signal this with a notification event. There is a DDK sample (or used to be, anyway) that illustrates this. I’ve used this approach along with a shared buffer mapped between the address spaces on occasion, so it can be made to work.
But the IOCTL approach is easier to follow and maintain [and will raise a lot fewer eyebrows], so I’d recommend it as the better way to do this.
I don’t believe UMDF directly supports user-mode only callbacks from the UMDF driver to your app, but if they do, someone who knows more about it than I do should say so.
UMDF does not support a callback back into the calling process. The
pattern in UMDF is the same, you send the driver an IOCTL, the driver
pends it and is completed when the “event” occurs.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Friday, November 17, 2006 10:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Beginner - How to communicate to a UMDF driver from
my application?
Your driver and the application reside in separate address spaces, so
callbacks of this sort aren’t generally something to attempt. Not that
people don’t at least try to cheat that principle on occasion…
One way of accomplishing this is to have a “wait for input” IOCTL that
the app sends to the driver. The driver pends it until input is ready,
then completes it, perhaps with some details as to how much is available
(on an IOCTL you can define the input and output blocks, so this is
usually plenty of flexibility for this sort of a need). The serial
driver sample in the DDK/WDK uses this approach. Your app thread can
basically just synchronously send this, and do the I/O after it returns.
IN practice, you usually add some timeout and cancellation logic on both
ends of that, but I believe the sample shows a fine way to handle that.
Another is to signal this with a notification event. There is a DDK
sample (or used to be, anyway) that illustrates this. I’ve used this
approach along with a shared buffer mapped between the address spaces on
occasion, so it can be made to work.
But the IOCTL approach is easier to follow and maintain [and will raise
a lot fewer eyebrows], so I’d recommend it as the better way to do this.
I don’t believe UMDF directly supports user-mode only callbacks from the
UMDF driver to your app, but if they do, someone who knows more about it
than I do should say so.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Sorry, I tried to understand this approach, but I couldn´t (maybe due to my little experience). Where I can find a example about pending IOCTL?
Thank you so much! 
Lucas.
xxxxx@gmail.com escreveu: Lucas Bracher wrote:
Ok. And how I can “wake up” my application to send data
from driver to application? Same way I make callbacks in dlls?
Just pend some IOCTLs inside your driver, and when you need to communicate something back to userspace, complete them.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora!
The following is a good reference for the concept
http://www.osronline.com/article.cfm?id=94 the examples here are for a
stock Windows driver (no framework), you will need to apply this to UMDF by
having a queue that you take a reqest off of when you need to communicate
with the application.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
“Lucas Bracher” wrote in message
news:xxxxx@ntdev…
> Sorry, I tried to understand this approach, but I couldn´t (maybe due to
> my little experience). Where I can find a example about pending IOCTL?
>
> Thank you so much!
>
> Lucas.
>
> xxxxx@gmail.com escreveu: Lucas Bracher wrote:
>
>> Ok. And how I can “wake up” my application to send data
>> from driver to application? Same way I make callbacks in dlls?
>
> Just pend some IOCTLs inside your driver, and when you need to
> communicate something back to userspace, complete them.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> ---------------------------------
> Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu
> celular. Registre seu aparelho agora!
The UMDF OSR-FX2 driver (src\umdf\usb\fx2_driver\final) does this for the I/O control which waits for the state of the DIP switches to change.
-p
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lucas Bracher
Sent: Saturday, November 18, 2006 6:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Beginner - How to communicate to a UMDF driver from my application?
Sorry, I tried to understand this approach, but I couldn?t (maybe due to my little experience). Where I can find a example about pending IOCTL?
Thank you so much!
Lucas.
xxxxx@gmail.com escreveu:
Lucas Bracher wrote:
Ok. And how I can “wake up” my application to send data
from driver to application? Same way I make callbacks in dlls?
Just pend some IOCTLs inside your driver, and when you need to communicate something back to userspace, complete them.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http:</http:> — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer