Hi again,
Before I try to re-invent the wheel I thought I would ask here.
In my filter driver I require to pass back to my (monitoring) application
read and write data which passes through my filter. Since I do not want the
driver waiting for the appliction to process this data it seems reasonable
to add packets of data to a FIFO queue in the driver from which the
application can later retrieve them.
I have been experimenting by adding two queues into my device extension, one
for read data and one for write data and adding private “Get Read Data” and
“Get Write Data” ioctls which the application calls to retrive the data. The
driver informs the application of the presence of data by means of two
shared events.
Does this sound like a reasonable approach or is there already a standard
accepted method in existence for doing this?
Thanks - you are keeping me sane!
Alasdair
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
Since you’ve been using IOCTL, you could just pend the IRP in the driver and
have the app wait on overlapped I/O. The driver completes the pending IOCTL
whenever the data this ready to pickup.
Personally, I preferred firing a WMI event with data associated if the size
of the data is not big and it’s not performance critical.
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Alasdair Tompson (external) [mailto:xxxxx@t-mobile.co.uk]
Sent: October 7, 2004 11:30 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Queuing Model
Hi again,
Before I try to re-invent the wheel I thought I would ask here.
In my filter driver I require to pass back to my (monitoring) application
read and write data which passes through my filter. Since I do not want the
driver waiting for the appliction to process this data it seems reasonable
to add packets of data to a FIFO queue in the driver from which the
application can later retrieve them.
I have been experimenting by adding two queues into my device extension, one
for read data and one for write data and adding private “Get Read Data” and
“Get Write Data” ioctls which the application calls to retrive the data. The
driver informs the application of the presence of data by means of two
shared events.
Does this sound like a reasonable approach or is there already a standard
accepted method in existence for doing this?
Thanks - you are keeping me sane!
Alasdair
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
I’ve never written a filter driver, but here’s my thoughts:
- Create some sort of queue in your driver (two queues seem like a good
plan, but you could just have a flag or some such to indicate read/write
data).
- Create an IOCTL that can get the data.
- Make the IOCTL wait and event to signal the data has arrived. If you
don’t want to wait “forever” (i.e. you want the app to be able to get
“there was no data”), you can use a timeout in the wait operation.
- When data comes in, set the event for data available, and stuff the data
into the queue.
That way you don’t have to expose the “data available event” to the outside
world, and it’s easier to change this to some other mechanism.
Your method would of course work, but it makes it more difficult to change
the mechanism between the app and the driver, and I find that
“encapsulation” is a good thing in this case…
–
Mats
xxxxx@lists.osr.com wrote on 10/07/2004 04:29:30 PM:
Hi again,
Before I try to re-invent the wheel I thought I would ask here.
In my filter driver I require to pass back to my (monitoring)
application read and write data which passes through my filter.
Since I do not want the driver waiting for the appliction to process
this data it seems reasonable to add packets of data to a FIFO queue
in the driver from which the application can later retrieve them.
I have been experimenting by adding two queues into my device
extension, one for read data and one for write data and adding
private “Get Read Data” and “Get Write Data” ioctls which the
application calls to retrive the data. The driver informs the
application of the presence of data by means of two shared events.
Does this sound like a reasonable approach or is there already a
standard accepted method in existence for doing this?
Thanks - you are keeping me sane!
Alasdair
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have
received this email in error please notify the sender immediately
and delete this email from your system without copying or
disseminating it or placing any reliance upon its contents. We
cannot accept liability for any breaches of confidence arising
through use of email. Any opinions expressed in this email
(including attachments) are those of the author and do not
necessarily reflect our opinions. We will not accept responsibility
for any commitments made by our employees outside the scope of our
business. We do not warrant the accuracy or completeness of such
information.
ForwardSourceID:NT00004E0E
The queue is a pretty standard approach. However don’t bother with the
events. Instead the application should just issue an asynchronous read
from each queue (or a single read that covers both queues, or however
you want to do it). If there’s no data available the driver will just
pend the request. The next time you have data to put into the queue,
first see if you can satisfy a pending “get” request from the
application … if there isn’t one pending then you queue the data.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alasdair Tompson
(external)
Sent: Thursday, October 07, 2004 8:30 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Queuing Model
Hi again,
Before I try to re-invent the wheel I thought I would ask here.
In my filter driver I require to pass back to my (monitoring)
application read and write data which passes through my filter. Since I
do not want the driver waiting for the appliction to process this data
it seems reasonable to add packets of data to a FIFO queue in the driver
from which the application can later retrieve them.
I have been experimenting by adding two queues into my device
extension, one for read data and one for write data and adding private
“Get Read Data” and “Get Write Data” ioctls which the application calls
to retrive the data. The driver informs the application of the presence
of data by means of two shared events.
Does this sound like a reasonable approach or is there already a
standard accepted method in existence for doing this?
Thanks - you are keeping me sane!
Alasdair
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have
received this email in error please notify the sender immediately and
delete this email from your system without copying or disseminating it
or placing any reliance upon its contents. We cannot accept liability
for any breaches of confidence arising through use of email. Any
opinions expressed in this email (including attachments) are those of
the author and do not necessarily reflect our opinions. We will not
accept responsibility for any commitments made by our employees outside
the scope of our business. We do not warrant the accuracy or
completeness of such information.