locked
Device/Driver stack in WDF RRS feed

  • Question

  • I am aware that in WDM, we can attach a device on top of another in the device sack using IOAttachDevice() API. In this API we can specify the name of the device belonging to another driver  to which we can attach. Thus we have a device/driver stack. I unbderstand that this way, one device can be placed over another device beloning to another driver but in the same stack. We can thus pass the IRP from one driver to the lower level one. But how is this done in WDF? The microsoft  docunetation  says that WDFDeviceCreate() attaches to a device/driver on top of a lower level diver. But how can I specify on which WDDevice ithe new device should attach like in WDFDeviceCreate()? I find that there is no equivaltn API in WDF.

    Is the passing of IRP in WDF  same as passing of IRP down the stack the same as in WDM?

    Thursday, January 16, 2014 6:03 PM

Answers

  • attaching to an already started stack, while possible, is not a supported scenario and can cause a lot of issues. this scenario is not supported in KMDF. you do NOT need to attach to a stack to send io to it, you just need to open a handle to it and then send io to the top of the stack. this is mostly the same steps you use to attach to an already running stack since you need to get the top of the stack anyways.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 17, 2014 12:55 AM
  • The fdo and filter roles are defined by the inf. You don't specify that in the device unit structure. The filter needs to call WdfFdoSetFilter so that the correct filter behavior is enabled.

    1 very possible. Allocate a wdfrequest, set a completion routine, format it and send it down the stack with the in stack iotarget (WdfDeviceGetIoTarget)

    2 complete the presented request in the driver allocated completion routine


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 17, 2014 3:38 AM

All replies

  • First why do you want to attach to a random device object?  Even in WDM one should attach to either a PDO for your FDO, or a given FDO is your driver is a filter.   In either case in WDM the AddDevice routine provides the lower object to attach to as a paramter.  In WDF, the EvtDriverDeviceAdd the data is in the DEVICE_INIT structure and the framework takes care of the explicit call to attach.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, January 16, 2014 6:11 PM
  • attaching to an already started stack, while possible, is not a supported scenario and can cause a lot of issues. this scenario is not supported in KMDF. you do NOT need to attach to a stack to send io to it, you just need to open a handle to it and then send io to the top of the stack. this is mostly the same steps you use to attach to an already running stack since you need to get the top of the stack anyways.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 17, 2014 12:55 AM
  • Thank you Doron. In normal scenarion , in a WDF driver project, we create a single Device Device Object. But may I know how I can specify a FilterDO or an FDO in the DEVICEINIT structure so that the device i create in WDFDeviceCreate() attaches to the above mentioned FilterDO or FDO? My intention is to create a driver stack with a Filter DO and FDO js just as an experiment/feasibility. Also,

    1. Once I am an a WDF callback for the above top level object, say EvtWrite(), I need to create a new IRP and pass it to lower driver, say a Filter driver.

    2.  The original IRP is completed at the top level itself and not passed to the lower level.

    Is this kind of a situation supported in WDF?


    • Edited by its_me_here Friday, January 17, 2014 2:01 AM
    Friday, January 17, 2014 1:59 AM
  • The fdo and filter roles are defined by the inf. You don't specify that in the device unit structure. The filter needs to call WdfFdoSetFilter so that the correct filter behavior is enabled.

    1 very possible. Allocate a wdfrequest, set a completion routine, format it and send it down the stack with the in stack iotarget (WdfDeviceGetIoTarget)

    2 complete the presented request in the driver allocated completion routine


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 17, 2014 3:38 AM
  • Thanks Doron. Regarding INF files, does it mean that if we need a FDO and Filter DO , we create two separate drivers and mention one as Filter in its INF and the second one as  Function Driver in the other driver's INf?

    Also I understand that by IO target we normally mean the Device Object that is the next lower device object of the current one. How can I set the Filter Driver as the IO target of the Function Driver or vice versa and build a stack? In the Steps 1 of my requirement in your above anwer, we are sending the newly created WDFRequest to the IOTarget which is the next lower object. But before sending the WdfRequest, we need to place it below the current device object, right?  How can this be done?

    Friday, January 17, 2014 12:09 PM