Re: Kernel mode to user mode
- From: "David Craig" <drivers@xxxxxxxxxx>
- Date: Wed, 13 Feb 2008 09:50:14 -0800
I can agree generally with not using events. However, I have one instance
where they make sense in the context of using IoCtls for data passing also.
An app passes an IoCtl to a driver initiating a series of tests that will
occur. Events are passed into the driver with the IoCtl and the results of
the tests will be passed back when the IoCtl completes. The driver requires
that the app perform certain actions when the driver wants them to occur.
As the driver sees the actions it signals an event to indicate it has seen
the activity and for the app to proceed to the next phase. The app signals
the driver when it has done an activity that the driver needs to know about.
This required multiple events and works well. It was for testing and not
release, but there can be uses for events. Not frequently, but sometimes.
I do think they should be thought of last and not first as many seem to do.
In the days of 9x, using events meant you could have a common communications
channel for an app that runs on both platforms. That is no longer required.
Getting all of the event waits to timeout properly when the activity was not
seen made that event usage somewhat complex, but since the app and driver
had many different run modes all based upon IoCtls and the design required a
single IoCtl per test, this was the best solution. Some activities must be
issued in an app and not a driver since you might be testing the source of
the activity.
"Don Burn" <burn@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:uV2RhMlbIHA.5160@xxxxxxxxxxxxxxxxxxxxxxx
Walter,
I hate to disagree, but after having bullet proofed a couple of event
base solutions to handle the various termination situations and event
overrun problems, I would never use an event as a signal to an applicaiton
unless I never cared if the application got the event, and even then
recognize since all handles are not cleaned up the applicaiton may be a
zombie for a long time.
Worse yet I have not found there to be any speed advantage to an event
unless there is no data passed at which point one wonders what the effort
is for. Finally, the OP said he is new to driver development, inverted
calls is easy, supporting all the mess of detecting terminated processes,
can be a lot of complexity.
If this is a simple PNP driver, the OP should use KMDF and let it
handle the PnP/Power stuff. If it is a legacy driver, the PnP
considerations do not apply. Finally, if this is a learning effort, the
OP should learn how to communicate with the standard model which is IRP's,
and not go down the deadend approach of events, especially since they will
likely be slower.
--
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
"Walter Oney" <waltoney@xxxxxxxxxxxx> wrote in message
news:47B30668.5F8CE454@xxxxxxxxxxxxxxx
Don Burn wrote:
Don't waste your time with an event. Use an inverted call
http://www.osronline.com/article.cfm?id=94. Basically, you have you
application pass one or more IOCTL's to the driver which pends them till
it
wants to notify the app, then it competes them. Using an event has a
ton of
problems.
I would respectfully disagree. You have to provide a way to cancel an
IOCTL when various things happen (including PNP events), and
synchronization is a nightmare. Managing an event object is child's play
in comparison, provided that you do the right things with the KEVENT
instead of just using the user-mode handle willy-nilly.
The OP's problem may be that he's doing a non-alertable kernel-mode wait
for the user-mode application to respond. It would be far better to have
the application send an IOCTL (which doesn't get pended). Next best
would be to do an alertable user-mode wait.
--
Walter Oney, Consulting and Training
http://www.oneysoft.com
.
- References:
- Re: Kernel mode to user mode
- From: Don Burn
- Re: Kernel mode to user mode
- From: Walter Oney
- Re: Kernel mode to user mode
- From: Don Burn
- Re: Kernel mode to user mode
- Prev by Date: is there a user-mode equivalent to EngDitherColor?
- Next by Date: Sharing a semaphore between user mode and kernel mode
- Previous by thread: Re: Kernel mode to user mode
- Next by thread: Re: Kernel mode to user mode
- Index(es):
Relevant Pages
|
