Re: Kernel mode to user mode

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


.

Relevant Pages

  • Re: User-land Callback From Driver
    ... My user-mode thread tells the driver where to put some data when a process ... Don Burn ... Windows 2k/XP/2k3 Filesystem and Driver Consulting ...
    (microsoft.public.development.device.drivers)
  • Re: get from KernelMode to UserMode very quickly?
    ... Windows driver forums "Windows is not a real time OS". ... calling a user-mode routine from same, ... User-mode APC. ...
    (microsoft.public.development.device.drivers)
  • Re: User-land Callback From Driver
    ... My user-mode thread tells the driver where to put some data when a process ... Your user mode process sends an IOCTL down to your driver. ...
    (microsoft.public.development.device.drivers)
  • Re: Ndis packet user mode round-trip
    ... Lets start by saying that some folks have noticed a network performance ... you can be sure that a user-mode round-trip design ... will be more noticable then a stripped-down PassTru driver. ... PCAUSA has a NDIS IM driver called an "IP Packet Redirector" that can be ...
    (microsoft.public.development.device.drivers)
  • Re: Fastest Possible Hardware Interrupt Response?
    ... if you are counting microseconds you need a KM driver to do this for you. ... applications developer access to hardware interrupts. ... appear to use a kernel-mode driver that accepts a pointer to user-mode code ...
    (microsoft.public.win32.programmer.kernel)