My driver is a USB functional device driver for a USB to Serial (Multiport Serial Device) converter. It (my driver) is also a bus-enumerator for the physical child serial ports (PDO) AND a functional device driver for the child serial ports FDO’s.
The problem is that since the child PDOs are reported by the USB FDO, when the USB cable is disconnected, the child stack is unconditionally removed and the handle to any open child serial port is no longer valid. This is problematic on a system where the USB device is frequently disconnected and reconnected for whatever reason. It means that the application’s serial data session is lost and probably has to close and re-open.
The solution would be to have a different device (say a root-enumerated device) enumerate the child serial ports so that they are no longer children of the USB device and are unaffected by USB disconnects and reconnects other than they are unable to transfer data while the USB device is disconnected.
Question: Would it be possible to use this root-enumerated device (FDO) as a “proxy” to report the child serial ports created by the USB device driver. In other words it would do an IoInvalidateDeviceRelations on its FDO and report the child serial ports (PDO’s) in response to IRP_MN_QUERY_DEVICE_RELATIONS?
I know there are lots of other details too numerous to mention such as synchronizing the removal of the serial device PDO’s with the USB device’s removal but I’m just exploring if this is possible or maybe someone else has an answer?
Thanks in advance!
Every time this comes I push for making the app pnp aware AND not solving it with more driver craziness. It solves the problem at the right level and localizes the complexity to a component that can’t crash the OS. If you must solve this at the driver later you can do this with a root enumerated bus driver. The toaster bus driver sample, either the static or dynamic version , gets you the enumeration functionality and you just have to wire in the triggers to the usb device to report a pdo present or missing or whatever other statedul changes to need to share. And don’t use wdm, Kmdf makes this far simpler.
Thanks for the reply, Doron. I couldn’t agree more that the PnP Awareness at the app level would simplify things so much. It seems like there’s been talk about this for 20 years but nothing happens.
I’m pretty much stuck with a WDM driver for the USB device so do you still think a KMDF driver would be better for the Proxy Bus Enumerator?
Yes, absolutely use KMDF for the new bus proxy driver. this would also move all the complex child device enumeration code out of your WDM driver and into the new driver, further reducing the cost of maintaining the old WDM driver.
So the complex child device enumeration in now handled by the KMDF bus proxy driver, but the problem I’m grappling with now is that a lot of code dealing with the child PDO is in the WDM driver and is not easily ported to the bus proxy driver. Does the bus proxy driver have to create the PDO in order to report bus relations or can it use a PDO passed from the WDM driver? From what I’ve read, you must call the WdfPdoInitXxx functions before creating the child WdfDevice so the framework can reply to IRP_MN_QUERY_TEXT and IRP_MN_QUERY_DEVICE_ID. Or could you filter the IRP_MJ_PNP calls to work around it?
Does the bus proxy driver have to create the PDO in order to report bus relations or can it use a PDO passed from the WDM driver?
The WDF driver needs to create the PDO to report it. You can’t hand it a PDO you created from outside the framework. You can’t filter RP_MJ_PNP calls to work around it.
When porting to WDF the “lots of WDM complex code” problem turns into simple, understandable WDF calls. Better to spend your energy in porting to WDF and doing it right vs. trying to hack around the problem. Can you give examples of where you think your WDM code doesn’t translate to WDF?
Hi Doran, I agree with you and after reviewing the WDM code it looks like there shouldn’t be a problem. Thanks again for your advice. So kind of you.
Woops sorry Doron for the mispelling