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

[George Dunlap <george.dunlap@eu.citrix.com>]

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