KMDF Queueing

NTDEV
1

I have a question about queueing in KMDF. It seems to me like proper
queue handling is core to the successful creation of a KMDF driver, so I
want to make sure I’m getting it.

Let’s say I have a device that can deliver two or three different types
of data; it can handle multiple requests at once, but only one of each
type. One way to handle that is to have a bunch of ioctls with
complicated locking. But let’s also say that it would be more natural
if the applications could use ReadFile and WriteFile for all of the data
types. One reasonable solution is to have the driver expose two or
three names in its namespace.

So, given that, I think I could have a parallel/immediate queue as my
default queue, with a default handler that examines the request to
figure out which data type it is, and then immediately forwards the
request into one of two or three sequential queues. Each of the
sequential queues could have its own EvtIoRead and EvtIoWrite handler,
which could concentrate on their own unique data type without worrying
very much about the other formats. It’s almost like having minidrivers
inside my driver.

Is that a reasonable application of the KMDF queueing model?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

2

You don’t need any namespace at all. You don’t need your own router.

You can have one sequential queue for Reads, one sequential queue for
Writes, and the default can be sequential, as well. The KMDF will route
WDFREQUESTs through the appropriate queue for you.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 10:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Queueing

I have a question about queueing in KMDF. It seems to me like proper
queue handling is core to the successful creation of a KMDF driver, so I
want to make sure I’m getting it.

Let’s say I have a device that can deliver two or three different types
of data; it can handle multiple requests at once, but only one of each
type. One way to handle that is to have a bunch of ioctls with
complicated locking. But let’s also say that it would be more natural
if the applications could use ReadFile and WriteFile for all of the data
types. One reasonable solution is to have the driver expose two or
three names in its namespace.

So, given that, I think I could have a parallel/immediate queue as my
default queue, with a default handler that examines the request to
figure out which data type it is, and then immediately forwards the
request into one of two or three sequential queues. Each of the
sequential queues could have its own EvtIoRead and EvtIoWrite handler,
which could concentrate on their own unique data type without worrying
very much about the other formats. It’s almost like having minidrivers
inside my driver.

Is that a reasonable application of the KMDF queueing model?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

3

Yes, that sounds quite reasonable. If you don’t need to route a read
based on the device or its namespace, you can configure different top
level queues via WdfDeviceConfigureRequestDispatching where each queue
has different properties.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 08, 2006 9:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Queueing

I have a question about queueing in KMDF. It seems to me like proper
queue handling is core to the successful creation of a KMDF driver, so I
want to make sure I’m getting it.

Let’s say I have a device that can deliver two or three different types
of data; it can handle multiple requests at once, but only one of each
type. One way to handle that is to have a bunch of ioctls with
complicated locking. But let’s also say that it would be more natural
if the applications could use ReadFile and WriteFile for all of the data
types. One reasonable solution is to have the driver expose two or
three names in its namespace.

So, given that, I think I could have a parallel/immediate queue as my
default queue, with a default handler that examines the request to
figure out which data type it is, and then immediately forwards the
request into one of two or three sequential queues. Each of the
sequential queues could have its own EvtIoRead and EvtIoWrite handler,
which could concentrate on their own unique data type without worrying
very much about the other formats. It’s almost like having minidrivers
inside my driver.

Is that a reasonable application of the KMDF queueing model?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

This might have seemed a bit brusque. I suppose I should have qualified
the “You don’t need …” statements with “Unless you already need it,
anyway”.

But the KMDF certainly doesn’t require that kind of handling, once you
setup the queues in the initialization code, it will do most of the
plumbing for you.

Most of my difficulties with using the KMDF have come from
misunderstanding how much work the KMDF would do for us, hence misusing
the framework.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, June 08, 2006 11:09 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Queueing

You don’t need any namespace at all. You don’t need your own router.

You can have one sequential queue for Reads, one sequential queue for
Writes, and the default can be sequential, as well. The KMDF will route
WDFREQUESTs through the appropriate queue for you.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 10:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Queueing

I have a question about queueing in KMDF. It seems to me like proper
queue handling is core to the successful creation of a KMDF driver, so I
want to make sure I’m getting it.

Let’s say I have a device that can deliver two or three different types
of data; it can handle multiple requests at once, but only one of each
type. One way to handle that is to have a bunch of ioctls with
complicated locking. But let’s also say that it would be more natural
if the applications could use ReadFile and WriteFile for all of the data
types. One reasonable solution is to have the driver expose two or
three names in its namespace.

So, given that, I think I could have a parallel/immediate queue as my
default queue, with a default handler that examines the request to
figure out which data type it is, and then immediately forwards the
request into one of two or three sequential queues. Each of the
sequential queues could have its own EvtIoRead and EvtIoWrite handler,
which could concentrate on their own unique data type without worrying
very much about the other formats. It’s almost like having minidrivers
inside my driver.

Is that a reasonable application of the KMDF queueing model?

5

xxxxx@seagate.com wrote:

This might have seemed a bit brusque. I suppose I should have qualified
the “You don’t need …” statements with “Unless you already need it,
anyway”.

But the KMDF certainly doesn’t require that kind of handling, once you
setup the queues in the initialization code, it will do most of the
plumbing for you.

I probably didn’t describe my scenario clearly enough. Picture, for
example, a single PCI device that is able to streams both ultrasound
echo readings of a room and continuous temperature/humidity data through
two separate DMA paths. One could create a bus driver with two separate
PDOs, but that’s a heck of a lot of work. One could use ioctls with two
different codes, but that isn’t a natural application model. By using
namespaces, I can allow two applications (or two threads of a single
app) to open the driver, and each one can use ReadFile. By exploiting
multiple queues, I can shunt them to two different EvtIoRead handlers.

I’m guessing that the WDFQUEUE mechanism has pretty low overhead, so if
I can simplify the design of the driver by adding a couple more, that
seems like a good tradeoff.

Most of my difficulties with using the KMDF have come from
misunderstanding how much work the KMDF would do for us, hence misusing
the framework.

Yes. I’m just getting started, and I find that many of my WDM habits
are getting in the way. It just feels wrong, for example, to return
from an IRP handler without doing anything to the IRP or returning a
status, but that seems to be the proper way to return STATUS_PENDING.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

>It just feels wrong, for example, to return

from an IRP handler without doing anything to the IRP or returning a
status, but that seems to be the proper way to return STATUS_PENDING.

Yes, all requests are pended automatically.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 08, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF Queueing

xxxxx@seagate.com wrote:

This might have seemed a bit brusque. I suppose I should have
qualified
the “You don’t need …” statements with “Unless you already need it,
anyway”.

But the KMDF certainly doesn’t require that kind of handling, once you
setup the queues in the initialization code, it will do most of the
plumbing for you.

I probably didn’t describe my scenario clearly enough. Picture, for
example, a single PCI device that is able to streams both ultrasound
echo readings of a room and continuous temperature/humidity data through
two separate DMA paths. One could create a bus driver with two separate
PDOs, but that’s a heck of a lot of work. One could use ioctls with two
different codes, but that isn’t a natural application model. By using
namespaces, I can allow two applications (or two threads of a single
app) to open the driver, and each one can use ReadFile. By exploiting
multiple queues, I can shunt them to two different EvtIoRead handlers.

I’m guessing that the WDFQUEUE mechanism has pretty low overhead, so if
I can simplify the design of the driver by adding a couple more, that
seems like a good tradeoff.

Most of my difficulties with using the KMDF have come from
misunderstanding how much work the KMDF would do for us, hence misusing
the framework.

Yes. I’m just getting started, and I find that many of my WDM habits
are getting in the way. It just feels wrong, for example, to return
from an IRP handler without doing anything to the IRP or returning a
status, but that seems to be the proper way to return STATUS_PENDING.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

7

Bravo! Personally, I think namespaces are highly underused. This is a very good example of where they’re appropriate.

Peter
OSR

8

> different codes, but that isn’t a natural application model. By using

namespaces, I can allow two applications (or two threads of a single
app) to open the driver, and each one can use ReadFile. By exploiting
multiple queues, I can shunt them to two different EvtIoRead handlers.

IIRC the audio stack in Windows uses the namespaces for audio hardware which
has several wave/MIDI subdevices. More so, PortCls.sys which does all of this
is conceptually similar to KMDF a bit.

Doron and Peter, am I correct that it was PortCls which influenced the KMDF
design?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

9

Portcls, IMO, was an influence in how *not* to design KMDF ;). We
didn’t use it as a basis for any design decision we made.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Sunday, June 11, 2006 4:25 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF Queueing

different codes, but that isn’t a natural application model. By using
namespaces, I can allow two applications (or two threads of a single
app) to open the driver, and each one can use ReadFile. By exploiting
multiple queues, I can shunt them to two different EvtIoRead handlers.

IIRC the audio stack in Windows uses the namespaces for audio hardware
which
has several wave/MIDI subdevices. More so, PortCls.sys which does all of
this
is conceptually similar to KMDF a bit.

Doron and Peter, am I correct that it was PortCls which influenced the
KMDF
design?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

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