WDM driver and services

What are the things that one needs to consider when interacting with a user
mode component( say with a service EXE) from a WDM streaming driver.

Basically, the service si started before the logon and it makes an IOCTL to
the driver with the necessary data. It also wants to create an Event that the
driver would call whenever it needs data and waits on the event so that when
the event is triggered, it does an IOCTL(KssyncrhroniseDeviceControl through
a cutom property set) and then goes back into Wait mode for the event to
signal.
How would this be done ? Just implementing a pending IRP wont do as there
are no IRP's, but SRB's and the WMD streaming driver would only interact with
the Stream Class driver.

Does, the WDM driver need to implement EVENT_SETS(I guess not) ? Because, in
this case, the service can Create an Event and send that event handle to the
WDM driver and wait on it to get into signalled state ?

so if thats the right approach, what does the WDM streaming driver need to
do to handle this scenario and signal the event, whenever it needs some data.

Thanks.

Max
Tue Oct 12 18:55:50 CDT 2004

> How would this be done ? Just implementing a pending IRP wont do as there
> are no IRP's, but SRB's and the WMD streaming driver would only interact
> with
> the Stream Class driver.

There are IRPs. They are wrapped by SRBs and that's what your minidriver
deals with, however underneath is still good old IRP (it's even present as
one of the fields in SRB, OriginalIrp or something like that).

Similar to IRPs SRBs are not completed until your minidriver completes them
using StreamClassDeviceNotification or StreamClassStreamNotification. When
SRB is being completed the original IRP is completed as well.
So what you do is your submit IOCTL from the user mode and wait for the
driver to complete it. In the minidriver you pend SRB by NOT calling
StreamClassDevice/StreamNotification until later. That's what causes
original IRP to be put on hold.
When ready, complete the SRB and that will eventually unblock user mode
thread when IOCTL completes.

-- Max.

Amit
Tue Oct 12 20:57:03 CDT 2004



"Max Paklin" wrote:

> > How would this be done ? Just implementing a pending IRP wont do as there
> > are no IRP's, but SRB's and the WMD streaming driver would only interact
> > with
> > the Stream Class driver.

Oh, I do realize that every SRB will be associated with an underlying IRP. I
was just saying the usual method wont work, but as you pointed out it seems
Stream Class has a corresponding way to do it.

Btw, is that the same between a stream class and avstream drivers ? I want
to take that into account now so that I dont have t worry about it later.
>
> There are IRPs. They are wrapped by SRBs and that's what your minidriver
> deals with, however underneath is still good old IRP (it's even present as
> one of the fields in SRB, OriginalIrp or something like that).

Oh ok, but we still shouldnt deal with irp's right in the minidriver?

> Similar to IRPs SRBs are not completed until your minidriver completes them
> using StreamClassDeviceNotification or StreamClassStreamNotification. When
> SRB is being completed the original IRP is completed as well.
> So what you do is your submit IOCTL from the user mode and wait for the
> driver to complete it. In the minidriver you pend SRB by NOT calling
> StreamClassDeviceSreamNotification until later. That's what causes
> original IRP to be put on hold.
> When ready, complete the SRB and that will eventually unblock user mode
> thread when IOCTL completes.

So what you are saying is basically do Async I/O using DeviceIocontrol and
send an Overlapped pointer that will contain the event ? and wait for the
Object..
and only when the driver finishes the SRB, the stream class(and I/O manager)
would handle the rest of notifying back to the app to get out of the Wait ?
The reason I am asking this is because this is a service and not just a
regular app. So, I would have opened the pipe for listening. But maybe thats
not required and just a DeviceIocontrol would suffice within a while loop tat
keeps running.

Thanks.

> -- Max.
>
>
>

Max
Wed Oct 13 11:59:20 CDT 2004

>> > How would this be done ? Just implementing a pending IRP wont do as
>> > there
>> > are no IRP's, but SRB's and the WMD streaming driver would only
>> > interact
>> > with
>> > the Stream Class driver.
>
> Oh, I do realize that every SRB will be associated with an underlying IRP.
> I
> was just saying the usual method wont work, but as you pointed out it
> seems
> Stream Class has a corresponding way to do it.
>
> Btw, is that the same between a stream class and avstream drivers ? I want
> to take that into account now so that I dont have t worry about it later.

Yes and no.
AVStream operates with IRPs (mostly) so what you usually do with AVStream is
you return STATUS_PENDING from your dispatch entry point and AVStream -
supposedly - pends the IRP.

I've never done it myself, but according to the DDK it is supposed to work.

There are a number of exception to this rule and one of those is that you
can't return STATUS_PENDING from pin state transition callback. I don't know
why and the DDK doesn't elaborate on that. Moreover state transition
callback doesn't receive an IRP so there appears to be no way the state
transition can be delayed unless you want to block in the dispatch entry
point, which can be bad as you have to assume that you might be running in
abitrary context.



>> There are IRPs. They are wrapped by SRBs and that's what your minidriver
>> deals with, however underneath is still good old IRP (it's even present
>> as
>> one of the fields in SRB, OriginalIrp or something like that).
>
> Oh ok, but we still shouldnt deal with irp's right in the minidriver?

Normally you shouldn't. However there are case when you have to. One of
those is minidriver receiving an IRP that class driver doesn't handle. In
that cast the class driver hands it the minidriver wrapped into "unknown"
SRB. For example, WMI IRPs would work that way unless you hook driver object
dispatch table.


> So what you are saying is basically do Async I/O using DeviceIocontrol and
> send an Overlapped pointer that will contain the event ? and wait for the
> Object..
> and only when the driver finishes the SRB, the stream class(and I/O
> manager)
> would handle the rest of notifying back to the app to get out of the Wait
> ?

You can do synchronous I/O if you don't mind blocking.
It's your call.


> The reason I am asking this is because this is a service and not just a
> regular app. So, I would have opened the pipe for listening. But maybe
> thats
> not required and just a DeviceIocontrol would suffice within a while loop
> tat
> keeps running.

I don't see a difference between a service and an application in this
context, but maybe I miss something.
I'd create a dedicate thread a do a blocking call to a driver from that
thread.

-- Max.

Amit
Wed Oct 13 17:35:27 CDT 2004



"Max Paklin" wrote:

> >> > How would this be done ? Just implementing a pending IRP wont do as
> >> > there
> >> > are no IRP's, but SRB's and the WMD streaming driver would only
> >> > interact
> >> > with
> >> > the Stream Class driver.
> >
> > Oh, I do realize that every SRB will be associated with an underlying IRP.
> > I
> > was just saying the usual method wont work, but as you pointed out it
> > seems
> > Stream Class has a corresponding way to do it.
> >
> > Btw, is that the same between a stream class and avstream drivers ? I want
> > to take that into account now so that I dont have t worry about it later.
>
> Yes and no.
> AVStream operates with IRPs (mostly) so what you usually do with AVStream is
> you return STATUS_PENDING from your dispatch entry point and AVStream -
> supposedly - pends the IRP.

Interesting, which probably explains why the Get/SetHandler works only on
avstream and not stream class minidrivers as get/sethandlers expect an IRP,
while there stream class deals with SRB's.

> I've never done it myself, but according to the DDK it is supposed to work.
>
> There are a number of exception to this rule and one of those is that you
> can't return STATUS_PENDING from pin state transition callback. I don't know
> why and the DDK doesn't elaborate on that. Moreover state transition
> callback doesn't receive an IRP so there appears to be no way the state
> transition can be delayed unless you want to block in the dispatch entry
> point, which can be bad as you have to assume that you might be running in
> abitrary context.
>
>
>
> >> There are IRPs. They are wrapped by SRBs and that's what your minidriver
> >> deals with, however underneath is still good old IRP (it's even present
> >> as
> >> one of the fields in SRB, OriginalIrp or something like that).
> >
> > Oh ok, but we still shouldnt deal with irp's right in the minidriver?
>
> Normally you shouldn't. However there are case when you have to. One of
> those is minidriver receiving an IRP that class driver doesn't handle. In
> that cast the class driver hands it the minidriver wrapped into "unknown"
> SRB. For example, WMI IRPs would work that way unless you hook driver object
> dispatch table.
>
>
> > So what you are saying is basically do Async I/O using DeviceIocontrol and
> > send an Overlapped pointer that will contain the event ? and wait for the
> > Object..
> > and only when the driver finishes the SRB, the stream class(and I/O
> > manager)
> > would handle the rest of notifying back to the app to get out of the Wait
> > ?
>
> You can do synchronous I/O if you don't mind blocking.
> It's your call.


Well, all my service is going to do ir provide Video data to the driver
every now and then. So, until the driver doesnt say that it needs more data,
maybe the service doesnt have to do anything more..

so this is what I am thinking....

while(1) ///of course I am checking for the stop video data event too...
{

DeviceI/o( or a Set Property or a KsysyncDeviceControl)
if(err_pending)
data = WaitForMultipleObjects
if(data == MoreData Event)
resetevent
else
break;
}

this is some algorithm of what I am thinking of doing.....
so which goes back to my earlier question...that assuming I return Pending
from my minidriver for the custom property, and assuming at some time later,
I complete the SRB..would the stream class( and I/O manager) return correctly
to the service app to make things work as I have stated above ?

Thanks.
>
> > The reason I am asking this is because this is a service and not just a
> > regular app. So, I would have opened the pipe for listening. But maybe
> > thats
> > not required and just a DeviceIocontrol would suffice within a while loop
> > tat
> > keeps running.
>
> I don't see a difference between a service and an application in this
> context, but maybe I miss something.
> I'd create a dedicate thread a do a blocking call to a driver from that
> thread.
>
> -- Max.
>
>
>

Max
Thu Oct 14 00:21:12 CDT 2004

> so this is what I am thinking....
>
> while(1) ///of course I am checking for the stop video data event too...
> {
>
> DeviceI/o( or a Set Property or a KsysyncDeviceControl)
> if(err_pending)
> data = WaitForMultipleObjects
> if(data == MoreData Event)
> resetevent
> else
> break;
> }
>
> this is some algorithm of what I am thinking of doing.....
> so which goes back to my earlier question...that assuming I return Pending
> from my minidriver for the custom property, and assuming at some time
> later,
> I complete the SRB..would the stream class( and I/O manager) return
> correctly
> to the service app to make things work as I have stated above ?

KsSynchronousDeviceControl does something similar to what you outlined
above. The key word is _synchronous_. There is no need for your code in that
case. Same for IPropertySet methods as they simply call
KsSynchronousDeviceControl.
KsSynchronousDeviceControl will never return with STATUS_PENDING.
However if you need to wait for multiple events you will have to issue
DeviceIoControl with event passed in OVERLAPPED and then wait for that event
as well as your own "quit" event.

Usually I prefer a different approach. When I want to exit, I stop the
graph. That results in driver receiving state transition call where driver
completes outstanding IRP/SRB and that causes KsSynchronousDeviceControl to
return. It is better as it doesn't require a special "quit" event and it
simplifies logic a little as all you have to do is to call
KsSynchronousDeviceControl.

-- Max.