I have experience with several other OS device driver models but not WDM.
I hope this is the appropiate place for this type of question.
I have a unique device that only my program(s) will be communicating with.
This device can produce data with and without request from the host.
I need to determine how to contact an application which has opened the
driver handle when information which was not asked for, arrives from the
hardware.
I can think of a few possibilities that would work but are rather clunky:
-
user thread issues read ioctl which is blocked in the driver until
timeout or data received.
-
driver queues data in buffer until read request received
-
user thread waits on named event, driver posts event, user thread calls
into driver with read.
If these are my choices, I’ll take 3.
Having a user level function callback from the driver was my first thought
but that would mean a kernel level thread in user space which obviously
would not work.
Is there some way to issue something like a postThreadMessage() to an apps
message queue?
What is the standard way to contact higher level code/application from a
kernel device driver?
Clay
Clay,
Consider the merge of 1 and 3, issue an IOCTL with OVERLAPPED I/O then
when
the user thread wishes to wait, wait on the event associated with the
overlapped I/O.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Clay Townsend”
To: “NT Developers Interest List”
Sent: Tuesday, June 03, 2003 1:59 PM
Subject: [ntdev] newbie request for info
> I have experience with several other OS device driver models but not WDM.
> I hope this is the appropiate place for this type of question.
>
> I have a unique device that only my program(s) will be communicating with.
> This device can produce data with and without request from the host.
>
> I need to determine how to contact an application which has opened the
> driver handle when information which was not asked for, arrives from the
> hardware.
>
> I can think of a few possibilities that would work but are rather clunky:
> 1) user thread issues read ioctl which is blocked in the driver until
> timeout or data received.
>
> 2) driver queues data in buffer until read request received
>
> 3) user thread waits on named event, driver posts event, user thread calls
> into driver with read.
>
> If these are my choices, I’ll take 3.
> Having a user level function callback from the driver was my first thought
> but that would mean a kernel level thread in user space which obviously
> would not work.
> Is there some way to issue something like a postThreadMessage() to an apps
> message queue?
>
> What is the standard way to contact higher level code/application from a
> kernel device driver?
>
> Clay
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
The standard way to do this is to post your read ioctlss and complete them
as data arrives, using IRP completion to signal any waiting thread. The
driver performs the operations asynchronously, the application can be
written either to use async or synchronous IO. Completing an asynchronous IO
request signals the thread waiting for that request to complete. See
GetOverlappedResult and GetQueuedCompletionStatus in the win32 platform sdk.
In general adding your own event based mechanism to this buys you nothing
other than increased complexity.
-----Original Message-----
From: Clay Townsend [mailto:xxxxx@mail.com]
Sent: Tuesday, June 03, 2003 2:00 PM
To: NT Developers Interest List
Subject: [ntdev] newbie request for info
I have experience with several other OS device driver models but not WDM.
I hope this is the appropiate place for this type of question.
I have a unique device that only my program(s) will be communicating with.
This device can produce data with and without request from the host.
I need to determine how to contact an application which has opened the
driver handle when information which was not asked for, arrives from the
hardware.
I can think of a few possibilities that would work but are rather clunky:
-
user thread issues read ioctl which is blocked in the driver until
timeout or data received.
-
driver queues data in buffer until read request received
-
user thread waits on named event, driver posts event, user thread calls
into driver with read.
If these are my choices, I’ll take 3.
Having a user level function callback from the driver was my first thought
but that would mean a kernel level thread in user space which obviously
would not work. Is there some way to issue something like a
postThreadMessage() to an apps message queue?
What is the standard way to contact higher level code/application from a
kernel device driver?
Clay
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
“Roddy, Mark” wrote:
In general adding your own event based mechanism to this buys you nothing
other than increased complexity.
I hate to disagree with a fellow WD-3 editor, but I think the complexity
of handling cancellation of a pending IOCTL outweighs the complexity of
using a shared event. Just my opinion, of course.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
Ok, I’ll bite. Why, given those nifty cancel-safe queues, is this anything
more than boilerplate code?
-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Tuesday, June 03, 2003 3:42 PM
To: NT Developers Interest List
Subject: [ntdev] Re: newbie request for info
“Roddy, Mark” wrote:
In general adding your own event based mechanism to this buys you
nothing other than increased complexity.
I hate to disagree with a fellow WD-3 editor, but I think the complexity of
handling cancellation of a pending IOCTL outweighs the complexity of using a
shared event. Just my opinion, of course.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
“Roddy, Mark” wrote:
Ok, I’ll bite. Why, given those nifty cancel-safe queues, is this anything
more than boilerplate code?
The cancel-safe queue doesn’t give you an easy way to manage the pointer
to the IRP. Plus you have to write all those callback routines.
I solved the problem in my book, and in my GENERIC.SYS, with a so-called
“pending IOCTL” mechanism. The idea is that you have a single pointer
cell to a given type of IRP. You “cache” the IRP in this pointer cell,
and the library then handles cancellation and IRP_MJ_CLEANUP pretty much
automatically. When you want to complete the IRP, you “uncache” it. If
you get back a NULL pointer, you know that it got cancelled or cleaned
up.
It’s boilerplate code if you use this mechanism, but people out there in
the world seem reluctant to do it for some reason.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
> I can think of a few possibilities that would work but are rather clunky:
-
user thread issues read ioctl which is blocked in the driver until
timeout or data received.
-
driver queues data in buffer until read request received
-
user thread waits on named event, driver posts event, user thread calls
into driver with read.
If these are my choices, I’ll take 3.
How about a combination of 1 and 3?
Open the file handle for overlapped operations, then post a read (or ioctl)
with a properly initialized Overlapped structure.
Or, if you write your driver to be able to queue multiple requests, the host
program could issue two or more overlapped reads so that the buffer for the
second can be acquiring data after the driver has completed the first one
and before the host can requeue it. This could eliminate the need for an
internal data buffer in the driver and the necessary data copy.
If you have Overlapped structures, you can wait for the events in them with
a WaitForMultipleObjects or WaitForSingleObject, or maybe better, use IO
Completion Ports.
In general, look into Overlapped structures, Completion Ports, and Alertable
Waits. While a tad clumsy to set up and handle compared to synchronous IO,
these will do all of the things that it appears you need, and rather
elegantly.
Loren
You have received several good responses, but I will add my $0.02 worth.
I am assuming that since the name of this list is “NT” that it is NOT
9x/Me.
- Get Walter Oney’s WDM book, 2nd edition. If you use overlapped IO,
you will need to handle cancelled IOs correctly.
- Avoid named events. Using an event created in user mode and give
the event handle to the driver, which can translate it to a kernel event
handle.
I like events, since I have used them and they work just fine. They are
best for low volume data.
Some others like overlapped IOs. You can have multiple IOs pending and
a thread ready for each if your driver can’t hold onto the data until a
user request gets down to the driver. Use these for high volume data
transfer.
----- Original Message -----
From: “Clay Townsend”
To: “NT Developers Interest List”
Sent: Tuesday, June 03, 2003 1:59 PM
Subject: [ntdev] newbie request for info
> I have experience with several other OS device driver models but not
WDM.
> I hope this is the appropiate place for this type of question.
>
> I have a unique device that only my program(s) will be communicating
with.
> This device can produce data with and without request from the host.
>
> I need to determine how to contact an application which has opened the
> driver handle when information which was not asked for, arrives from
the
> hardware.
>
> I can think of a few possibilities that would work but are rather
clunky:
> 1) user thread issues read ioctl which is blocked in the driver until
> timeout or data received.
>
> 2) driver queues data in buffer until read request received
>
> 3) user thread waits on named event, driver posts event, user thread
calls
> into driver with read.
>
> If these are my choices, I’ll take 3.
> Having a user level function callback from the driver was my first
thought
> but that would mean a kernel level thread in user space which
obviously
> would not work.
> Is there some way to issue something like a postThreadMessage() to an
apps
> message queue?
>
> What is the standard way to contact higher level code/application from
a
> kernel device driver?
>
> Clay
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> I can think of a few possibilities that would work but are rather
clunky:
-
user thread issues read ioctl which is blocked in the driver
until
timeout or data received.
-
driver queues data in buffer until read request received
Instead of 1) send the overlapped ioctl to the driver. Send even lots
of them, they will be completed on data arrival.
Also use 2) as a last resort if the app will stop the pipeline due to
some cause.
Max