Inter - driver communication, or: register2 device-classes to one driver

NTDEV
1

Hi,
I have a simple target: inform the kbfiltr (Keyboard-Filter driver from
the DDK examples), everytime the number of HDD read/write accesses on
the system changes beetwen 0 and >0. And the kbfiltr should set the
Indicator-LEDs accordingly. And store the should-be indicator state
internal. I am a beginner and have 2 solutions:

  1. Register 2 device-classes in one driver (kbfiltr). Integrate very
    small parts of the “diskperf” example into kbfiltr.
    So the driver filters the keyboard and storage devices together.
    (I don’t want to rely on the diskperf service in WindowsXP. Since it
    should run on W2K, don’t want to pull infos, diskperf does unnecessary
    things, etc…)
    I think this solution is somehow - ugly. Is it even sensible?

  2. Write a 2nd filter driver for the storage-system. Use parts of
    “diskperf”.
    But: How the hell do they communicate? The kbfiltr should be
    pushed/invoked from the storage-filter.

What I absolute, absolute not want to do is pulling.

Thanks
Jan Diederich

2

Hello,

this article explains inter-driver communication: www.osronline.com/article.cfm?id=24

3

I would use a service to communicate. The service opens control devices on
each filter and is informed by the disk filter of state transitions, which
it then reflects back to the kb filter.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-292103-
xxxxx@lists.osr.com] On Behalf Of Jan Diederich
Sent: Sunday, July 01, 2007 4:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Inter - driver communication, or: register2 device-
classes to one driver

Hi,
I have a simple target: inform the kbfiltr (Keyboard-Filter driver from
the DDK examples), everytime the number of HDD read/write accesses on
the system changes beetwen 0 and >0. And the kbfiltr should set the
Indicator-LEDs accordingly. And store the should-be indicator state
internal. I am a beginner and have 2 solutions:

  1. Register 2 device-classes in one driver (kbfiltr). Integrate very
    small parts of the “diskperf” example into kbfiltr.
    So the driver filters the keyboard and storage devices together.
    (I don’t want to rely on the diskperf service in WindowsXP. Since it
    should run on W2K, don’t want to pull infos, diskperf does unnecessary
    things, etc…)
    I think this solution is somehow - ugly. Is it even sensible?

  2. Write a 2nd filter driver for the storage-system. Use parts of
    “diskperf”.
    But: How the hell do they communicate? The kbfiltr should be
    pushed/invoked from the storage-filter.

What I absolute, absolute not want to do is pulling.

Thanks
Jan Diederich

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

4

xxxxx@hushmail.com schrieb:
> Hello,
>
> this article explains inter-driver communication:
www.osronline.com/article.cfm?id=24

Thanks.

I used the search function. But didn’t find it.

Thanks :slight_smile:

5

There are a few things here to clear up.

  1. you can put your filter into multiple device classes. A device
    classes is applied to a particular device instance, not the entire
    driver. Think of the ps2 driver, i8042prt, it is installed in both the
    keyboard and mouse stacks. So, you can install your driver in both the
    disk and input stack with the right INF magic. If the same driver is in
    both stacks, you can easily make a direct call within your driver to
    change the LED state on the keyboard (but that would be for only one
    particular keyboard, not all of them)

  2. using a service as the junction between the 2 stacks. It can be
    done, but if you are going to user mode, why not just call SendInput to
    set the LED state from user mode (which has the added side benefit of
    being applied to all keyboards, not just a particular keyboard) and
    forget the keyboard filter completely?

  3. why even do this? Setting the LED state to something the user does
    not expect is a very bad usability problem. On win2k, we tried to be
    cute and do something like you are doing. We mapped the Sx [1-4] to the
    LED state on the keyboard, treating each LED as 0x1, 0x2 or 0x4 and then
    ORing them to get to the right Sx state. It was a nightmare in terms of
    hangs and bugs and confused the hell out users when their LEDs flashed.
    In short, I would recommend you use some other indicator for the info
    you want to convey, the LED state on the keyboard is not the best way to
    do it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Sunday, July 01, 2007 8:59 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Inter - driver communication, or: register2
device-classes to one driver

I would use a service to communicate. The service opens control devices
on
each filter and is informed by the disk filter of state transitions,
which
it then reflects back to the kb filter.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-292103-
xxxxx@lists.osr.com] On Behalf Of Jan Diederich
Sent: Sunday, July 01, 2007 4:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Inter - driver communication, or: register2 device-
classes to one driver

Hi,
I have a simple target: inform the kbfiltr (Keyboard-Filter driver
from
the DDK examples), everytime the number of HDD read/write accesses on
the system changes beetwen 0 and >0. And the kbfiltr should set the
Indicator-LEDs accordingly. And store the should-be indicator state
internal. I am a beginner and have 2 solutions:

  1. Register 2 device-classes in one driver (kbfiltr). Integrate very
    small parts of the “diskperf” example into kbfiltr.
    So the driver filters the keyboard and storage devices together.
    (I don’t want to rely on the diskperf service in WindowsXP. Since it
    should run on W2K, don’t want to pull infos, diskperf does unnecessary
    things, etc…)
    I think this solution is somehow - ugly. Is it even sensible?

  2. Write a 2nd filter driver for the storage-system. Use parts of
    “diskperf”.
    But: How the hell do they communicate? The kbfiltr should be
    pushed/invoked from the storage-filter.

What I absolute, absolute not want to do is pulling.

Thanks
Jan Diederich

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

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