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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-04-25 at 13:21 +0100, George Dunlap wrote:
> 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.

I was thinking of this in terms of the bus/"protocol" being emulated,
but not in terms of how the actual device was provided. The provision of
the type of device is the "kind" field I think?

Ian.


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