Pending read buffers & lower filter driver

NTDEV
1

Please advise. I’ve a USB lower filter driver that would have to submit some
URBs (commands) and consume the response (command result) from the device instead of passing up to the upper stack. At the same time, some entity in the upper stack may have pending reads for the same device. In this scenario, how URB submission should be done?

2

Are these pended reads from the upper stack on the same endpoint? Are the responses on the same endpoint?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hiqulabs.com
Sent: Sunday, February 12, 2012 3:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Pending read buffers & lower filter driver

Please advise. I’ve a USB lower filter driver that would have to submit some URBs (commands) and consume the response (command result) from the device instead of passing up to the upper stack. At the same time, some entity in the upper stack may have pending reads for the same device. In this scenario, how URB submission should be done?

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

3

Yes. The filter driver generated commands will be sent on the control endpoint and responses will come via interrupt endpoint. It is possible that the FDO may have pending reads for the interrupt endpoint.

4

Well, if the upper layer’s read on the interrupt endpoint completes because of some control endpoint io you performed, you should probably send that io back down the stack. Now the fun part here is that this will now put that io at the end of the interrupt read queue, but the upper driver expects that read to be at the FRONT of the read queue, which when completed out of expected order can potentially cause problems and bugs.

The most surefire way to avoid this is do two things

  1. you always send a read on the interrupt endpoint (perhaps more than one so you have a set ping ponging)
  2. when an upper layer read on that interrupt endpoint comes in, you always queue it
  3. when one of your own reads completes, if there is a queued read from the upper layer, you complete it

While the most foolproof, it complicated and higher potential for things to go wrong in your driver

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hiqulabs.com
Sent: Sunday, February 12, 2012 4:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pending read buffers & lower filter driver

Yes. The filter driver generated commands will be sent on the control endpoint and responses will come via interrupt endpoint. It is possible that the FDO may have pending reads for the interrupt endpoint.

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

Thanks for the detailed response. Is there anyway to determine if an upper driver has a pending reads on intr EP?

6

Sure. It will go through your filter on the way down the stack

d

debt from my phone

From: xxxxx@hiqulabs.com
Sent: 2/12/2012 6:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Pending read buffers & lower filter driver

Thanks for the detailed response. Is there anyway to determine if an upper driver has a pending reads on intr EP?

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