Re: User-land Callback From Driver

On Jan 1, 7:43 pm, L. Spiro <LSp...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I looked at the code and I could not find anything that has to do with
calling a user-mode function. I know it is there, but I could not find it.

Since this is just an OnProcessOpen/OnProcessClose callback it is acceptible
to use a method that is not the fastest.
Could I at least create the following system?

- My user-mode thread tells the driver where to put some data when a process
is opened/closed.
- My thread loops waiting for data to be put there.
- The driver puts data there when a process is opened or closed and then
waits for the data to be removed by the user-mode thread before leaving the
driver callback.
- The user-mode thread sees data (a flag set to 1), does whatever, and sets
the flag to 0 which tells the driver to continue.

Will this at least work, even if not super-responsive?
A little delay is okay but I want to handle my event entirely within the
scope of the driver callback's start and end, so the driver needs to wait for
the user-mode to finish.

I know there is a risk that no new processes may ever be opened/closed if my
user-mode thread ever fails to pick up the event, but I have fail-safe
mechanisms planned to prevent that (the driver may consider only waiting up
to 1 second before considering the event lost and moving on).
And of course I will drop to passive-level to let my user-mode threads run.

That aside, are there any other precautions I would need to take to get it
working?

L. Spiro

1. Your user mode process sends an IOCTL down to your driver. The
driver interprets it as: "Please monitor changes and return your data
in the buffers of this IOCTL."
2. Your driver pends this IOCTL. Your umode app has sent it in
overlapped mode, therefore it waits on the event.
3. At some arbitrary point in time, driver receives the change
notification, and stores the information in the IOCTL buffers that it
had pended. It then completes the IRP. This eventually causes the
umode app to wake up.
4. Umode app then processes the buffer of the Ioctl and fires the next
Ioctl to the kmode component.

This is the simplest solution. There are more elegant ways that would
block less, but you'd have to pay me for it!! ;)
.

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: 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)
  • Re: Kernel mode to user mode
    ... application pass one or more IOCTL's to the driver which pends them till it ... wants to notify the app, ... instead of just using the user-mode handle willy-nilly. ... the application send an IOCTL. ...
    (microsoft.public.development.device.drivers)
Loading