[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 2/2] xl: Add commands for usb hot-plug



On 04/25/2013 01:14 PM, George Dunlap wrote:
On 04/25/2013 01:08 PM, Ian Campbell wrote:
On Thu, 2013-04-25 at 12:57 +0100, George Dunlap wrote:
On 04/25/2013 12:38 PM, Ian Campbell wrote:
On Thu, 2013-04-25 at 11:16 +0100, George Dunlap wrote:
+    for (i = 0; i < num; i++) {
+        printf("%8s  ", (dev[i].protocol==LIBXL_USB_PROTOCOL_PV)?"pv":"dm");

You can use libxl_usb_protocol_to_string here.

Could do, but I didn't necessarily want the long version ("devicemodel").

TBH the more I think about it the more I think DM/DEVICEMODEL in this
interface is leaking an implementation detail, after all the user
doesn't really care who/what is emulating a USB controller.

Protocol = {PV,OHCI,XHCI}?

As we covered before:

1. I have no way of selecting OHCI vs XHCI at this point

OK, so maybe HCI (as the generic term for a USB host controller) or EMU
or something is more appropriate. I'm not too fussed about the
distinction between {O,U,X}HCI right now.

2. Even if I did, why should the caller have to keep track of what kind
of USB hardware is exposed to the guest?

Perhaps because they have to make sure they have the appropriate drivers
in the guest?

In particular if qemu decides to use xhci will that work seemlessly with
Windows XP? I think XHCI is supposed to be backwards compatible with
OHCI but I'm not really sure how that works in practice.

They should be able to just  say "Add" and have stuff sorted out.

Sure.

3. The point of saying DEVICEMODEL is that it's not PV.  An HVM guest
may be able to do either, and should be allowed to choose.

But not PV does not imply device model, except by
inspecting/understanding implementation details. What you are really
asking for is an emulated USB host controller and you don't care where
it comes from.

4. In any case, PROTOCOL_AUTO should be the expected default thing which
should be called 99% of the time, unless there's a reason to choose
otherwise.

5. #4 doesn't undermine #2 as an argument, because the caller should be
able to specify "use qemu" without having to remember which hardware is
currently exposed to the guest.

My point is that the user doesn't want to specify "use qemu" they want
to specify "use an emulated USB host controller".

Right -- so your only problem is that you don't want users to have to
know "emulated" <=> "device model".  That's fine.

Hmm...

So, I think I'm remembering why I chose "device model" in the first place. The problem is that the *device itself* is not emulated -- it's a real device which is exposed via the device model. We're emulating the instructions and the usb hardware used to access the device, but not the device itself. The device model is a conduit, which is why "protocol" seemed like the closest fit in terms of a word.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.