WDF Queuing and Mapping question.

NTDEV
1

Hi All,
I need to resolve a confusion that is bugging me a little. I have a WDF sequential queue and a WDF manual queue. My driver gets a command from the sequential queue, fires it and then puts in the manual queue. At this time will my driver get a new command from sequential queue? My understanding is that the driver will not get a new command from the sequential queue till it actually completes or cancels the previous command. Inserting the command back in to a WDF manual queue will not give me a new command. Is this correct?

Another question that I have is If I have a embedded pointer in a IOCTL and I use WdfRequestProbeAndLockUserBufferForRead To map the buffer for access, will the KMDF unmap the buffer when I complete/cancel the IOCTL?

Any comments are appriciated.
Thanks,
– Ajitabh.

2

On Fri, Apr 10, 2009 at 06:39:59PM -0700, Ajitabh Saxena wrote:

I need to resolve a confusion that is bugging me a little. I
have a WDF sequential queue and a WDF manual queue. My driver gets a
command from the sequential queue, fires it and then puts in the manual
queue. At this time will my driver get a new command from sequential
queue? My understanding is that the driver will not get a new command
from the sequential queue till it actually completes or cancels the
previous command. Inserting the command back in to a WDF manual queue
will not give me a new command. Is this correct?

No. As soon as you put the request into another queue, it no longer
belongs to the sequential queue. As far as the sequential queue is
concerned, the request is "completed", so it will fire another request.

Another question that I have is If I have a embedded pointer in a IOCTL
and I use WdfRequestProbeAndLockUserBufferForRead To map the buffer for
access, will the KMDF unmap the buffer when I complete/cancel the IOCTL?

Yes. The buffer "belongs" to the request, so when the request is cleaned
up, the buffer will be cleaned up, and that includes unmapping the
kernel view.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

3

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Sunday, April 12, 2009 11:54 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF Queuing and Mapping question.

On Fri, Apr 10, 2009 at 06:39:59PM -0700, Ajitabh Saxena wrote:

I need to resolve a confusion that is bugging me a little. I
have a WDF sequential queue and a WDF manual queue. My driver gets a
command from the sequential queue, fires it and then puts in the
manual
queue. At this time will my driver get a new command from sequential
queue? My understanding is that the driver will not get a new command
from the sequential queue till it actually completes or cancels the
previous command. Inserting the command back in to a WDF manual queue
will not give me a new command. Is this correct?

No. As soon as you put the request into another queue, it no longer
belongs to the sequential queue. As far as the sequential queue is
concerned, the request is “completed”, so it will fire another request.
Not necessarily. Depends on the SyncronizationScope of the Queue and
it’s parent DO.

Another question that I have is If I have a embedded pointer in a
IOCTL
and I use WdfRequestProbeAndLockUserBufferForRead To map the buffer
for
access, will the KMDF unmap the buffer when I complete/cancel the
IOCTL?

Yes. The buffer “belongs” to the request, so when the request is cleaned
up, the buffer will be cleaned up, and that includes unmapping the
kernel view.

Nice simplification over having to explicitly unmap/unlock it as is
necessary if you use MmProbeAndLockPages().

Phil

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

4

Thanks for the response. Can you please elaborate on
“Not necessarily. Depends on the SyncronizationScope of the Queue and it’s parent DO.”

– Ajitabh.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Monday, April 13, 2009 7:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF Queuing and Mapping question.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Sunday, April 12, 2009 11:54 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF Queuing and Mapping question.

On Fri, Apr 10, 2009 at 06:39:59PM -0700, Ajitabh Saxena wrote:

I need to resolve a confusion that is bugging me a little. I
have a WDF sequential queue and a WDF manual queue. My driver gets a
command from the sequential queue, fires it and then puts in the manual
queue. At this time will my driver get a new command from sequential
queue? My understanding is that the driver will not get a new command
from the sequential queue till it actually completes or cancels the
previous command. Inserting the command back in to a WDF manual queue
will not give me a new command. Is this correct?

No. As soon as you put the request into another queue, it no longer
belongs to the sequential queue. As far as the sequential queue is
concerned, the request is “completed”, so it will fire another request.

Not necessarily. Depends on the SyncronizationScope of the Queue and it’s parent DO.

Another question that I have is If I have a embedded pointer in a IOCTL
and I use WdfRequestProbeAndLockUserBufferForRead To map the buffer for
access, will the KMDF unmap the buffer when I complete/cancel the IOCTL?

Yes. The buffer “belongs” to the request, so when the request is cleaned
up, the buffer will be cleaned up, and that includes unmapping the
kernel view.

Nice simplification over having to explicitly unmap/unlock it as is necessary if you use MmProbeAndLockPages().

Phil

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Ajitabh Saxena wrote:

Thanks for the response. Can you please elaborate on
“Not necessarily. Depends on the SyncronizationScope of the Queue and
it’s parent DO.”

If you set your queue’s SynchronizationScope to “Device”, KMDF uses a
lock to make sure that only one of your callback functions can run at a
time, device-wide.

However, Phil, I don’t think that changes what I said. If I get a
request from a serial queue, then requeue it to a manual queue and
return, no callbacks will be active. Thus, the sequential queue is free
to pop another request.

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

6

I think the distinction Phil was pointing out is about how soon you’ll get called. Without device level locking you could be called for another request on the sequential queue before WdfReqeustForwardToIoQueue returns (if a request came in on another thread for example). With device level locking that call won’t happen until you return from the current event callback.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, April 13, 2009 12:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDF Queuing and Mapping question.

Ajitabh Saxena wrote:

Thanks for the response. Can you please elaborate on
“Not necessarily. Depends on the SyncronizationScope of the Queue and
it’s parent DO.”

If you set your queue’s SynchronizationScope to “Device”, KMDF uses a
lock to make sure that only one of your callback functions can run at a
time, device-wide.

However, Phil, I don’t think that changes what I said. If I get a
request from a serial queue, then requeue it to a manual queue and
return, no callbacks will be active. Thus, the sequential queue is free
to pop another request.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer