Raw device limitations

Hi all,

my driver is implementing USB over Ethernet, but the problem I’ve run
into now is not specific to USB. It’s about device installation and
parent-child relationships.

USB devices are expected to have at least one parent device (a root hub)
and one additional grandparent (a host controller, from where
enumeration by tools such as UsbView usually starts).

So far I have dodged this complication and had one single device object
advertise both GUID_DEVINTERFACE_USB_HUB and
GUID_DEVINTERFACE_USB_HOST_CONTROLLER, handle IOCTLs for both device
types, and this has worked very well for a wide range of USB devices and
third-party software. But now, because of one persistent case of
software not finding its USB device on the virtual bus, I am willing to
give in and create two separate devices for virtual host controller and
root hub.

The obvious solution (a) would be to have the root-enumerated
grandparent (host controller) create one PDO (the root hub) and load a
driver for it by usual INF-based installation. Drawback is that, at
least on XP, the user will have to confirm one additional driver
installation. So instead (b) I made the grandparent device create a raw
PDO. This had the expected result of the “root hub” appearing without an
additional driver installation. But then I realized that, being just a
PDO, the raw device cannot have children of its own. Drat.

This seems to be a show-stopper for approach (b). Am I missing
something? Can I silently put a FDO on top of a raw PDO? Or is there
another way to make approach (a) less inconvenient, i.e. avoid the
additional driver installation warning?

You can enumerate pdos from a raw pdo,I have a kmdf unit test that does exactly this type of thing. Enumerating a pdo is just answering qdr/busrelations. A raw pdo has no fdo and is immediately started so this is done directly in the pdo code

d

I think you have to go with your first plan and the extra install. PDOs
can’t have child devices.

Mark Roddy

On Fri, Mar 1, 2013 at 6:15 AM, Wilhelm N?ker wrote:

> Hi all,
>
> my driver is implementing USB over Ethernet, but the problem I’ve run into
> now is not specific to USB. It’s about device installation and parent-child
> relationships.
>
> USB devices are expected to have at least one parent device (a root hub)
> and one additional grandparent (a host controller, from where enumeration
> by tools such as UsbView usually starts).
>
> So far I have dodged this complication and had one single device object
> advertise both GUID_DEVINTERFACE_USB_HUB and GUID_DEVINTERFACE_USB_HOST_**CONTROLLER,
> handle IOCTLs for both device types, and this has worked very well for a
> wide range of USB devices and third-party software. But now, because of one
> persistent case of software not finding its USB device on the virtual bus,
> I am willing to give in and create two separate devices for virtual host
> controller and root hub.
>
> The obvious solution (a) would be to have the root-enumerated grandparent
> (host controller) create one PDO (the root hub) and load a driver for it by
> usual INF-based installation. Drawback is that, at least on XP, the user
> will have to confirm one additional driver installation. So instead (b) I
> made the grandparent device create a raw PDO. This had the expected result
> of the “root hub” appearing without an additional driver installation. But
> then I realized that, being just a PDO, the raw device cannot have children
> of its own. Drat.
>
> This seems to be a show-stopper for approach (b). Am I missing something?
> Can I silently put a FDO on top of a raw PDO? Or is there another way to
> make approach (a) less inconvenient, i.e. avoid the additional driver
> installation warning?
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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=ListServerhttp:
></http:>

Yes they can

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, March 1, 2013 7:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Raw device limitations

I think you have to go with your first plan and the extra install. PDOs can’t have child devices.

Mark Roddy

On Fri, Mar 1, 2013 at 6:15 AM, Wilhelm N?ker > wrote:
Hi all,

my driver is implementing USB over Ethernet, but the problem I’ve run into now is not specific to USB. It’s about device installation and parent-child relationships.

USB devices are expected to have at least one parent device (a root hub) and one additional grandparent (a host controller, from where enumeration by tools such as UsbView usually starts).

So far I have dodged this complication and had one single device object advertise both GUID_DEVINTERFACE_USB_HUB and GUID_DEVINTERFACE_USB_HOST_CONTROLLER, handle IOCTLs for both device types, and this has worked very well for a wide range of USB devices and third-party software. But now, because of one persistent case of software not finding its USB device on the virtual bus, I am willing to give in and create two separate devices for virtual host controller and root hub.

The obvious solution (a) would be to have the root-enumerated grandparent (host controller) create one PDO (the root hub) and load a driver for it by usual INF-based installation. Drawback is that, at least on XP, the user will have to confirm one additional driver installation. So instead (b) I made the grandparent device create a raw PDO. This had the expected result of the “root hub” appearing without an additional driver installation. But then I realized that, being just a PDO, the raw device cannot have children of its own. Drat.

This seems to be a show-stopper for approach (b). Am I missing something? Can I silently put a FDO on top of a raw PDO? Or is there another way to make approach (a) less inconvenient, i.e. avoid the additional driver installation warning?


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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

— NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers 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

really? huh. ok that is actually good news as I am about to do something
very similar to the op.

Mark Roddy

On Fri, Mar 1, 2013 at 12:34 PM, Doron Holan wrote:

> Yes they can **
>
>

>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, March 1, 2013 7:42 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Raw device limitations

>
> ****
>
> I think you have to go with your first plan and the extra install. PDOs
> can’t have child devices.
>
>
>

>
> Mark Roddy
>
>

>
> On Fri, Mar 1, 2013 at 6:15 AM, Wilhelm N?ker wrote:

>
> Hi all,
>
> my driver is implementing USB over Ethernet, but the problem I’ve run into
> now is not specific to USB. It’s about device installation and parent-child
> relationships.
>
> USB devices are expected to have at least one parent device (a root hub)
> and one additional grandparent (a host controller, from where enumeration
> by tools such as UsbView usually starts).
>
> So far I have dodged this complication and had one single device object
> advertise both GUID_DEVINTERFACE_USB_HUB and
> GUID_DEVINTERFACE_USB_HOST_CONTROLLER, handle IOCTLs for both device types,
> and this has worked very well for a wide range of USB devices and
> third-party software. But now, because of one persistent case of software
> not finding its USB device on the virtual bus, I am willing to give in and
> create two separate devices for virtual host controller and root hub.
>
> The obvious solution (a) would be to have the root-enumerated grandparent
> (host controller) create one PDO (the root hub) and load a driver for it by
> usual INF-based installation. Drawback is that, at least on XP, the user
> will have to confirm one additional driver installation. So instead (b) I
> made the grandparent device create a raw PDO. This had the expected result
> of the “root hub” appearing without an additional driver installation. But
> then I realized that, being just a PDO, the raw device cannot have children
> of its own. Drat.
>
> This seems to be a show-stopper for approach (b). Am I missing something?
> Can I silently put a FDO on top of a raw PDO? Or is there another way to
> make approach (a) less inconvenient, i.e. avoid the additional driver
> installation warning?
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
>

>
> — NTDEV is sponsored by OSR OSR is HIRING!! See
> http://www.osr.com/careers 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

>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

In the end bus enumeration is the results of qdr/busrelations that is built up by the entire stack. The kernel has no idea who in the stack inserted child or reported it missing. it can easily be done by the PDO. the only blocker is if the stack above the PDO doesn’t play by the rules properly (always keeping the existing list in the PIRP intact and adding on to it vs incorrectly nuking it)

d

I confirmed. I have done the exact with WDM in the old days.

The kernel doesn’t care FDO. The important thing to the OS is
the struct _device_node_t * which comes with the PDO. Not sure how to do it
with kmdf though??

Calvin

On Fri, Mar 1, 2013 at 9:34 AM, Doron Holan wrote:

> Yes they can **
>
>

>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, March 1, 2013 7:42 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Raw device limitations

>
> ****
>
> I think you have to go with your first plan and the extra install. PDOs
> can’t have child devices.
>
>
>

>
> Mark Roddy
>
>

>
> On Fri, Mar 1, 2013 at 6:15 AM, Wilhelm N?ker wrote:

>
> Hi all,
>
> my driver is implementing USB over Ethernet, but the problem I’ve run into
> now is not specific to USB. It’s about device installation and parent-child
> relationships.
>
> USB devices are expected to have at least one parent device (a root hub)
> and one additional grandparent (a host controller, from where enumeration
> by tools such as UsbView usually starts).
>
> So far I have dodged this complication and had one single device object
> advertise both GUID_DEVINTERFACE_USB_HUB and
> GUID_DEVINTERFACE_USB_HOST_CONTROLLER, handle IOCTLs for both device types,
> and this has worked very well for a wide range of USB devices and
> third-party software. But now, because of one persistent case of software
> not finding its USB device on the virtual bus, I am willing to give in and
> create two separate devices for virtual host controller and root hub.
>
> The obvious solution (a) would be to have the root-enumerated grandparent
> (host controller) create one PDO (the root hub) and load a driver for it by
> usual INF-based installation. Drawback is that, at least on XP, the user
> will have to confirm one additional driver installation. So instead (b) I
> made the grandparent device create a raw PDO. This had the expected result
> of the “root hub” appearing without an additional driver installation. But
> then I realized that, being just a PDO, the raw device cannot have children
> of its own. Drat.
>
> This seems to be a show-stopper for approach (b). Am I missing something?
> Can I silently put a FDO on top of a raw PDO? Or is there another way to
> make approach (a) less inconvenient, i.e. avoid the additional driver
> installation warning?
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
>

>
> — NTDEV is sponsored by OSR OSR is HIRING!! See
> http://www.osr.com/careers 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

>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

WDFCHILDLIST is used for enumeration for any role in the stack, FDOs also get static enumeration.

d

I see. So I obviously cannot call WdfFdoGetDefaultChildList() etc. for a
(raw) PDO, but WdfChildListCreate() will happily add a child list to any
device, no matter if it’s a PDO or FDO. That’s good to know.

Thanks for all the answers.