virtualization layer for apps

Hello All,

We are working on this driver feature wherein it requires *virtualization* layer for the usb to serial function driver developed using kmdf
Wherein we created control device obj and redirect app handle to this Device obj to manage app originated WDF Requests to cdo and in-turn forwarding the same requests to the pnp DO

This scenario works fine if single device is present
In case of no device, from CDO only we are completing these Requests.

However when we plan to extend the same to multiple devices we have few challenges

  1. Is it possible to create multiple CDOs? (may not be, as we are facing few issues in managing single CDO only)
  2. Or we need replace CDO with normal DO?

With the 2nd option we face a challenge - one cannot create additional DO for a pnp DO since we do not get WDFDEVICE_INIT for this additional DO

And hence this is the one of the reason we went initially using Control device object as we can use WdfControlDeviceInitAllocate

However using wdm this can be achieved but the driver we are working is a KMDF

Any inputs to handle above scenario will be helpful

Use filenames to tell the target PDOs from each other.

xxxxx@gmail.com wrote:

We are working on this driver feature wherein it requires *virtualization* layer for the usb to serial function driver developed using kmdf

What’s the point of this?

Wherein we created control device obj and redirect app handle to this Device obj to manage app originated WDF Requests to cdo and in-turn forwarding the same requests to the pnp DO

This scenario works fine if single device is present
In case of no device, from CDO only we are completing these Requests.

I’m a little confused.

I get that you want a “permanent” device available, and from there
you’ll forward requests to your real device. But I don’t understand the
“no device” thing. If your driver is the driver for a USB device, then
you won’t be loaded until there is a device, and when your device goes
away, your driver is unloaded. How does the “no device” scenario come
about?

It’s true that, if you have created a CDO and you are not managing it’s
lifetime, the open CDO will prevent your driver from being unloaded.
However, when the device is replugged, you’ll get a brand new device
instance. How will the CDO know that?

However when we plan to extend the same to multiple devices we have few challenges

  1. Is it possible to create multiple CDOs? (may not be, as we are facing few issues in managing single CDO only)

Sure you can. You just have to keep track of them. However, I don’t
think that’s the right answer here.

It is tricky to do lifetime management in your situation, because your
FDOs are all PnP devices, and your CDO is not. The rules are
different. The manifestation is usually that your driver cannot be
unloaded.

  1. Or we need replace CDO with normal DO?

With the 2nd option we face a challenge - one cannot create additional DO for a pnp DO since we do not get WDFDEVICE_INIT for this additional DO

You would have to be a bus driver, and create child PDOs. With KMDF,
that’s not really very hard. However, when your USB device is
unplugged, PnP will want to unload your driver.


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