say user app sends a big task into driver,
driver is going to do a lot of computation and costs plenty of time,
once driver finishes, how’s it going to notify the app that the result is ready ?
By completing the request, don’t you think…
BTW, your design seems to be fundamentally flawed anyway
Anton Bassov
Why do you want to do that in a driver? Like Anton said, the driver
completes the IRP.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, August 04, 2010 10:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] A dummy question: how’s driver to notify application that
the work is done
say user app sends a big task into driver, driver is going to do a lot of
computation and costs plenty of time, once driver finishes, how’s it going
to notify the app that the result is ready ?
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
Ok, my question is at step 3, BTW i’m doing this for some measurement.
step 1:
so basically from DeviceIoControl, lpOverlapped must point to a valid OVERLAPPED structure that contains a handle to an event object.
step2 :
When IRP completes, the event is sent out.
NTSTATUS
CatchIrpRoutine(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PKEVENT Event
)
{
if (Irp- >PendingReturned) {
// Release waiting thread
KeSetEvent( Event, IO_NO_INCREMENT, FALSE );
}
return STATUS_MORE_PROCESSING_REQUIRED;
}
step 3:
user level application can get this event ?
i never recall any sample like this.
First as Gary asked why do you have a large request in the driver? If
it is actually transferring data this could be justified but depending
on the device some smaller requests may be better. Second, you do not
explicitly set the event, you complete the request and the OS will set
the event for you. Your code snippet below is wrong in every way
imaginable, you should not need to test if pending was returned, you
should not set the event, and you should not return
STATUS_MORE_PROCESSING_REQUIRED that is a specific error code for
wanting to do more work on the IRP after catching it in a completion
routine.
Seriously look around and take a class you are at the point where you do
not know what you do not know.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Thursday, August 05, 2010 8:21 AM
Posted To: ntdev
Conversation: A dummy question: how’s driver to notify application
that the
work is done
Subject: RE: A dummy question: how’s driver to notify application that
the
work is doneOk, my question is at step 3, BTW i’m doing this for some measurement.
step 1:
so basically from DeviceIoControl, lpOverlapped must point to a valid
OVERLAPPED structure that contains a handle to an event object.step2 :
When IRP completes, the event is sent out.NTSTATUS
CatchIrpRoutine(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PKEVENT Event
)
{
if (Irp- >PendingReturned) {// Release waiting thread
KeSetEvent( Event, IO_NO_INCREMENT, FALSE );
}return STATUS_MORE_PROCESSING_REQUIRED; }
step 3:
user level application can get this event ?
i never recall any sample like this.__________ Information from ESET Smart Security, version of virus
signature
database 5342 (20100805) __________The message was checked by ESET Smart Security.
well, this is what i found, hope it’s the correct way
Going a step beyond that, though, the recommended way for drivers to
communicate asynchronous events to user-space processes is via the
asynchronous I/O mechanisms built into the driver API. That is, the
application calls the driver with a read, write or IoControl request.
The driver marks it pending (IoMarkIrpPending), puts it in an internal
queue and returns. When the event occurs, the driver marks the
request complete (IoCompleteRequest).
The application can issue the request in an asynchronous way through
the OVERLAPPED structure in ReadFile, WriteFile or DeviceIoControl.
Then, can receive the notifications via WaitForMultipleObjects (using
event objects that are not shared with the kernel) or one at a time
through GetQueuedCompletionStatus.
Your summation is generally correct, the application can also use I/O
Completion Ports for higher performance and handle over 1 million events
a second that way.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Thursday, August 05, 2010 10:58 AM
Posted To: ntdev
Conversation: A dummy question: how’s driver to notify application
that the
work is done
Subject: RE: A dummy question: how’s driver to notify application that
the
work is donewell, this is what i found, hope it’s the correct way
Going a step beyond that, though, the recommended way for drivers to
communicate asynchronous events to user-space processes is via the
asynchronous I/O mechanisms built into the driver API. That is, the
application calls the driver with a read, write or IoControl request.
The driver marks it pending (IoMarkIrpPending), puts it in an internal
queue
and returns. When the event occurs, the driver marks the request
complete
(IoCompleteRequest).The application can issue the request in an asynchronous way through
the
OVERLAPPED structure in ReadFile, WriteFile or DeviceIoControl.
Then, can receive the notifications via WaitForMultipleObjects (using
event
objects that are not shared with the kernel) or one at a time
through
GetQueuedCompletionStatus.__________ Information from ESET Smart Security, version of virus
signature
database 5343 (20100805) __________The message was checked by ESET Smart Security.
One small point. The event that you create in user-mode and assign to your
OVERLAPPED structure IS actually shared with the driver. When the driver
calls IoCompleteRequest the event is signaled.
You are right that WaitForMultipleObjects can be waiting on this event
handle as well as other event handles. IOW, the OVERLAPPED event is the same
as any other event handle.
Be sure that your driver also handles IRP_MJ_CLEANUP and IRP_MJ_CLOSE. This
is how the driver learns that the application has closed it’s handle (or
that the application has died…).
Good luck,
Thomas F. Divine
From:
Sent: Thursday, August 05, 2010 10:57 AM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] A dummy question: how’s driver to notify application
that the work is done
> well, this is what i found, hope it’s the correct way
>
> Going a step beyond that, though, the recommended way for drivers to
> communicate asynchronous events to user-space processes is via the
> asynchronous I/O mechanisms built into the driver API. That is, the
> application calls the driver with a read, write or IoControl request.
> The driver marks it pending (IoMarkIrpPending), puts it in an internal
> queue and returns. When the event occurs, the driver marks the
> request complete (IoCompleteRequest).
>
> The application can issue the request in an asynchronous way through
> the OVERLAPPED structure in ReadFile, WriteFile or DeviceIoControl.
> Then, can receive the notifications via WaitForMultipleObjects (using
> event objects that are not shared with the kernel) or one at a time
> through GetQueuedCompletionStatus.
>
> —
> 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
Thanks for all the suggestions.
Also i found C:\WinDDK\7600.16385.1\src\general\event
has the IRP_BASED example, lots to play with …
xxxxx@hotmail.com wrote:
say user app sends a big task into driver,
driver is going to do a lot of computation and costs plenty of time,
once driver finishes, how’s it going to notify the app that the result is ready ?
Typically, drivers do not do “a lot computation” that “costs plenty of
time”. Computationally-intensive tasks belong in user-mode.
NEVER do anything in kernel mode that can be done in user mode instead.
There is no performance advantage. Kernel code is more dangerous, and
difficult to debug, and the costs of an error are much, much higher.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> NEVER do anything in kernel mode that can be done in user mode instead.
…well, although Redmond guys may (and,apparently, will) agree with it in theory, they seem to have a very different opinion on this topic in their real-life implementations, don’t you think - after all, they somehow managed to design a kernel that allows file IO, pageable driver code, and,in general, supports plenty of other things ( ranging from window management to HTTP processing) that, objectively, belong in the UM.
Therefore, the OP just follows the tradition…
Anton Bassov
> once driver finishes, how’s it going to notify the app that the result is ready ?
IoCompleteRequest
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> CatchIrpRoutine(
You do not need any completion routines to signal the event in OVERLAPPED, IO manager will do this automatically when you call IoCompleteRequest.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Tim Roberts” wrote in message news:xxxxx@ntdev…
…
> NEVER do anything in kernel mode that can be done in user mode instead.
> There is no performance advantage. Kernel code is more dangerous, and
> difficult to debug, and the costs of an error are much, much higher.
This principle taken to extremity can also imply that pending i/o should be
avoided
as being too complex.
Because, to pend IRPs properly, you need to support cancellation,
and all the sync that it takes. A shared event looks simpler.
The driver just signals the event, then the usermode polls the driver for
data.
Less efficient, but simpler than inverted call.
Regards,
- pa
wrote in message news:xxxxx@ntdev…
>
>
>
>
>> NEVER do anything in kernel mode that can be done in user mode instead.
>
>
> …well, although Redmond guys may (and,apparently, will) agree with it
> in theory, they seem to have a very different opinion on this topic in
> their real-life implementations, don’t you think - after all, they somehow
> managed to design a kernel that allows file IO, pageable driver code,
> and,in general, supports plenty of other things ( ranging from window
> management to HTTP processing) that, objectively, belong in the UM.
> Therefore, the OP just follows the tradition…
>
>
>
>
>
> Anton Bassov
Windows indeed is very flexible; there is a zintillion of creative ways for
a driver to
indicate events for usermode, besides of the classic pending i/o (a.k.a.
“inverted call”).
A driver can notify the app by sending email 
– pa
> Because, to pend IRPs properly, you need to support cancellation
Not necessary. Cancellation on MJ_CLEANUP is enough for simple cases.
Also, there are IoCsq and KMDF queues.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com