Re: [PATCH V7 6/7] xl: add usb-assignable-list command

[Juergen Gross <jgross@suse.com>]

On 10/07/2015 10:40 AM, Ian Campbell wrote:
> On Tue, 2015-10-06 at 17:55 +0100, George Dunlap wrote:
>> On 25/09/15 03:11, Chunyan Liu wrote:
>>> Add xl usb-assignable-list command to list assignable USB devices.
>>> Assignable USB device means the USB device type is assignable and
>>> it's not assigned to any guest yet.
>>>
>>> Signed-off-by: Chunyan Liu <cyliu@suse.com>
>>>
>>> ---
>>>    Same as "libxl: add libxl_device_usb_assignable_list API" patch,
>>>    this patch could be sqaushed to previous one. Split because of
>>>    some dispute. Could be squashed if acceptable, otherwise could
>>>    be removed.
>>
>> I think it's worth pointing out to other reviewers that the
>> "usb-assignable-list" command introduced here:
>> 1. Has identical behavior to "xm usb-assignable-list", but
>> 2. Has different behavior than "xl pci-assignable-list".
>
> OOI how does xl pci-assignable-list compare to xm pci-assignable-list.
>
>> Namely:
>>
>> xl pci-assignable-list will list PCI devices which have been detached
>> from their normal driver and have been assigned to pciback (in
>> preparation for being attached to a domain).

Assigning a PCI device to pciback is a necessary step to be able to
attach it to a domain.

>> This command will list all USB devices in dom0 that are not assigned to
>> VMs.

Attaching a USB device to a domain works by detaching it from it's
normal driver and attaching it to the pvUSB backend. And this backend
is per domain (qemu), so it's not possible to prepare this step by
attaching the device to "the" pvUSB backend.

And just detaching the device from it's driver is no solution either,
as the driver can grab it again at any time, as all drivers are queried
for all unassigned devices when a new USB device shows up.

And you'd need another command to move a USB-device to the assignable
state.

>> Juergen and I had a long back-and-forth about it around v3.  I thought
>> having slightly different semantics might be confusing, and Juergen
>> thought the functionality was important to include.  We didn't really
>> come to a conclusion and none of the tools maintainers expressed an
>> opinion.
>
> TBH I couldn't follow precisely what that discussion was about, so thanks
> for your summary. IMHO you both make good points.
>
> However given that xend was now removed 2 releases ago I think the time for
> strictly mimicking xm behaviour purely for the sake of that
> compatibility/transition has passed.
>
> Obviously if the xm interface was fine we shouldn't deviate from it just to
> be contrary, but similarly if the xm interface was bad in some way or
> doesn't fit in with the direction xl has taken since the two coexisted then
> we shouldn't feel bound to follow xm.
>
> In this case and at this point in time I think I find the argument that xl
> subcommands should, where possible, behave similarly to each other more
> compelling than they should match their xm counterparts. (maybe if we'd
> been aware of it we would have implemented pci-assignable-list differently,
> but that ship has sailed).
>
> So IMHO xl usb-assignable-list should behave like pci-assignable-list by
> default.

As stated above: this will have weird consequences or you need some kind
of placeholder backend just for this functionality. Is this really worth
the effort?


Juergen