Hi all,
Could someone to make more clear for me, what exactly functions should be implemented
in Windows driver to support asynchronous call?
thank you,
Andrew
What do you mean??? Do you mean calls solely to your driver (i.e. the ones that you complete with IoCompleteRequest()) or the ones made by your driver (inluding the ones that you pass down the stack)???
In former case you have to mark IRP pending, return STATUS_PENDING from your Dispatch() routine, and call IoCompleteRequest() at some later stage. In later case you have to set IO Completion routine in IRP before passing it to IoCallDriver. Any other scenario is just this or that combination of the above two…
Anton Bassov
Hello Anton,
Thank you for your fast respond.
I’m confused regarding W.Oney “WDM2” book, since it has in the beginning of
chapter 9 some explanation
about Synchronous and Asynchronous calls to DeviceIoControl (without
OVERLAPPED and with OVERLAPPED)
in user application, but in examples of this book (chap. 9) I have found
test appplications without using OVERLAPPED.
My question is: If the driver supports notification of user level
application (Sharing events or pending IOCTL for notification),
should an application use FILE_FLAG_OVERLAPPED flag in the call to
CreateFile? (In this book he does not use it).
thank you,
Andrey
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, June 05, 2007 3:10 PM
Subject: RE:[ntdev] how to make my driver 100% asynchronous?
> What do you mean??? Do you mean calls solely to your driver (i.e. the ones
> that you complete with IoCompleteRequest()) or the ones made by your
> driver (inluding the ones that you pass down the stack)???
>
> In former case you have to mark IRP pending, return STATUS_PENDING from
> your Dispatch() routine, and call IoCompleteRequest() at some later stage.
> In later case you have to set IO Completion routine in IRP before passing
> it to IoCallDriver. Any other scenario is just this or that combination of
> the above two…
>
> Anton Bassov
>
> —
> 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
>
The driver’s support is seperate from the applications usage. A driver
should pend calls where appropriate,
but whether an application wants to use them is up to the applicaiton. The
driver will still be asynchronous.
Note: the 100% is potentially a bad design, since if a call is fast enough,
doing the request synchronouslly is
actually better.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Andrey Kamchatnikov” wrote in message
news:xxxxx@ntdev…
>
> I’m confused regarding W.Oney “WDM2” book, since it has in the beginning
> of chapter 9 some explanation
> about Synchronous and Asynchronous calls to DeviceIoControl (without
> OVERLAPPED and with OVERLAPPED)
> in user application, but in examples of this book (chap. 9) I have found
> test appplications without using OVERLAPPED.
>
> My question is: If the driver supports notification of user level
> application (Sharing events or pending IOCTL for notification),
> should an application use FILE_FLAG_OVERLAPPED flag in the call to
> CreateFile? (In this book he does not use it).
>
Do you mean overlapped IO?
If yes - then the questions is not about functions, but about the coding
discipline.
Namely - do not use KeWaitXxx for a long time in your dispatch routines.
Instead, call IoMarkIrpPending, pend the IRP somewhere (IoCsqXxx is a good
idea, even for a single IRP, since it supports cancellation out-of-the-box) and
return STATUS_PENDING from the dispatch routine.
The code path which is executed when the event you’re waiting for occurs -
should dequeue the IRP and complete it, instead of calling KeSetEvent.
Also note that IRP cancellation support is mandatory in this case.
Otherwise, your app will be nearly unkillable if it has a pending IRP on your
driver.
The only case when you’re officially allowed to do KeWaitXxx in a dispatch
routine is when IoIsOperationSynchronous returns TRUE. Note that
IoIsOperationSynchronous requires valid
IoGetCurrentIrpStackLocation(Irp)->FileObject, and, if this is not so - like in
the disk stack - it will BSOD.
If you will obey these rules - then your driver will allow for overlapped
IO out-of-the-box.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Andrey Kamchatnikov” wrote in message
news:xxxxx@ntdev…
Hi all,
Could someone to make more clear for me, what exactly functions should be
implemented
in Windows driver to support asynchronous call?
thank you,
Andrew
> My question is: If the driver supports notification of user level
application (Sharing events or pending IOCTL for notification),
should an application use FILE_FLAG_OVERLAPPED flag in the call to
CreateFile? (In this book he does not use it).
Any. The only implication is that, if FILE_FLAG_OVERLAPPED is not provided,
DeviceIoControl will only return after the pending IOCTL will be completed in
the driver. Is it really what you need?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Yes, pending the “set some property” or “get some property” IOCTLs is
surely a bad idea.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Don Burn” wrote in message news:xxxxx@ntdev…
> The driver’s support is seperate from the applications usage. A driver
> should pend calls where appropriate,
> but whether an application wants to use them is up to the applicaiton. The
> driver will still be asynchronous.
> Note: the 100% is potentially a bad design, since if a call is fast enough,
> doing the request synchronouslly is
> actually better.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Andrey Kamchatnikov” wrote in message
> news:xxxxx@ntdev…
> >
> > I’m confused regarding W.Oney “WDM2” book, since it has in the beginning
> > of chapter 9 some explanation
> > about Synchronous and Asynchronous calls to DeviceIoControl (without
> > OVERLAPPED and with OVERLAPPED)
> > in user application, but in examples of this book (chap. 9) I have found
> > test appplications without using OVERLAPPED.
> >
> > My question is: If the driver supports notification of user level
> > application (Sharing events or pending IOCTL for notification),
> > should an application use FILE_FLAG_OVERLAPPED flag in the call to
> > CreateFile? (In this book he does not use it).
> >
>
>
>
Maxim wrote:
Yes, pending the “set some property” or “get some property”
IOCTLs is surely a bad idea.
Unfortunately, this is what KMDF will do with such requests coming to a WDFQUEUE.
Only if your “set some properly” or “get some property” I/O control is a performance critical path.
Otherwise it may be unnecessary but I wouldn’t call it a “bad idea”. And later you might decide that you need to serialize the get & set operations using a lock or a queue, at which point the application might really appreciate the fact that you aren’t hijacking its thread to wait on your lock.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, June 05, 2007 4:25 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:how to make my driver 100% asynchronous?
Yes, pending the “set some property” or “get some property” IOCTLs is
surely a bad idea.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Don Burn” wrote in message news:xxxxx@ntdev…
> The driver’s support is seperate from the applications usage. A driver
> should pend calls where appropriate,
> but whether an application wants to use them is up to the applicaiton. The
> driver will still be asynchronous.
> Note: the 100% is potentially a bad design, since if a call is fast enough,
> doing the request synchronouslly is
> actually better.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Andrey Kamchatnikov” wrote in message
> news:xxxxx@ntdev…
> >
> > I’m confused regarding W.Oney “WDM2” book, since it has in the beginning
> > of chapter 9 some explanation
> > about Synchronous and Asynchronous calls to DeviceIoControl (without
> > OVERLAPPED and with OVERLAPPED)
> > in user application, but in examples of this book (chap. 9) I have found
> > test appplications without using OVERLAPPED.
> >
> > My question is: If the driver supports notification of user level
> > application (Sharing events or pending IOCTL for notification),
> > should an application use FILE_FLAG_OVERLAPPED flag in the call to
> > CreateFile? (In this book he does not use it).
> >
>
>
>
—
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
> Unfortunately, this is what KMDF will do with such requests coming to a WDFQUEUE
why is this unfortunate? for a request which requires device power, this is a prerequisite. if you complete the request in the i/o callback in a non power managed queue, the request is completed synchronously even if the driver returns STATUS_PENDING. This is really only unfortunate for broken UM components (like mscomm32.ocx) which cannot handle async i/o completing synchronously or expecting an overlapped handle to complete an i/o synchronously based on state.
d
Doron Holan wrote:
This is really only unfortunate for broken UM components (like
mscomm32.ocx) which cannot handle async i/o completing
synchronously or expecting an overlapped handle to complete
an i/o synchronously based on state.
Well, there you go. It just makes porting existing WDM drivers to KMDF that much harder, especially ones that have a lot of existing usermode code already written against them.
mscomm32.ocx is a good public example, especially since the knowledge base article blames the driver and says “contact your vendor for an updated driver,” making the truth a tough sell to people who don’t know any better.
In my specific situation I’m also supporting a lot of internal-type tools that were obviously not tested very well and need these kinds of workarounds for the same reasons.
> Well, there you go. It just makes porting existing WDM drivers to KMDF that
much harder, especially ones that have a lot of existing usermode code already
written against them.
Just do not violate the overlapped IO rules in your user-mode code in a way
MSCOMM32.OCX violates them.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com