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

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

On 05/20/2015 03:55 PM, Juergen Gross wrote:
> On 05/20/2015 04:41 PM, George Dunlap wrote:
>> On Wed, May 20, 2015 at 3:33 PM, Juergen Gross <jgross@xxxxxxxx> wrote:
>>> On 05/20/2015 04:20 PM, George Dunlap wrote:
>>>> On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
>>>>> On 04/19/2015 05:50 AM, Chunyan Liu wrote:
>>>>>> Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
>>>>>> usb-attach and usb-detach.
>>>>>> To attach a usb device to guest through pvusb, one could follow
>>>>>> following example:
>>>>>>     #xl usb-ctrl-attach test_vm version=1 num_ports=8
>>>>>>     #xl usb-list test_vm
>>>>>>     will show the usb controllers and port usage under the domain.
>>>>>>     #xl usb-attach test_vm 1.6
>>>>>>     will find the first usable controller:port, and attach usb
>>>>>>     device whose bus address is 1.6 (busnum is 1, devnum is 6)
>>>>>>     to it. One could also specify which <controller> and which
>>>>>> <port>.
>>>>>>     #xl usb-detach test_vm 1.6
>>>>>>     #xl usb-ctrl-detach test_vm dev_id
>>>>>>     will destroy the controller with specified dev_id. Dev_id
>>>>>>     can be traced in usb-list info.
>>>>>> Signed-off-by: Chunyan Liu <cyliu@xxxxxxxx>
>>>>>> Signed-off-by: Simon Cao <caobosimon@xxxxxxxxx>
>>>>>> ---
>>>>>> Changes to v2:
>>>>>>      * use bus.addr as user interface instead of busid in
>>>>>> usb-attach|detach
>>>>>>      * remove usb-assignable-list interface
>>>>> Why? While lsusb in combination with xl usb-list for each domain will
>>>>> give the same information, having to iterate through all domains
>>>>> can be
>>>>> quite annoying.
>>>>> An alternative would be to accept omitting the domain for xl usb-list
>>>>> and list all domains with assigned usb devices in this case.
>>>> I don't understand what information it is that you want.  Do you want
>>>> a list of devices *not already assigned* to domains?
>>> Yes.
>> ...and why do you need that, instead of just remembering what you'd
>> assigned to whom?
>> We don't really have the equivalent for pci either.  That is, if a
>> device shows up in "lspci" but not in "pci-assignable-list", that may
>> be either because 1) I hasn't yet been assigned to pciback (and this
>> is available to be assigned to a domain), or 2) because it's already
>> been assigned to a domain.  Someone new coming to the system would
>> need to check all VMs to see which devices hadn't yet been assigned.
> So this is a problem of pci-assignable-list, which isn't present for
> USB devices. Any USB device not already assigned to a VM would be listed
> as before with "xm usb-assignable-list".
> Additionally all systems support hotplug of USB devices - the list of
> available USB-devices can change rather often. If you unplug e.g. a
> memory stick which has been assigned to a VM and stick it in again it
> might show up under a different address and has to be reassigned.
> Remembering having it already assigned won't help in this case as much
> as a simple command to list the devices ready for assignment.

OK. :-)  Yes, I can see that having USB devices disappear and appear as
a different bus:host would make such a command particularly useful.

But then we have the problem that "assignable" means something different
in each case.  In pci-assignable-list, it means "Devices which have been
assigned to pciback but not yet been attached to a domain".  In your
suggested command, it means "Devices which have not yet been assigned
either to pvusbback or to a domain."

When I introduced pci-assignable-* I didn't realize that "assignable"
was already in one of the xm commands with a different meaning.  I
introduced it because until that point, neither xm nor xl had a way of
attaching a device to pciback.

So we basically have three options:
1. Keep both names the same
2. Rename usb-assignable-list to something else (usb-available-list?)
3. Rename pci-assignable-* to something else

#1 would be the most backwards-compatible.  But I think it's really bad
going forward, since you have two commands that look like they should do
similar things that don't.

#2 and #3 would both solve the potential confusion issue.

#2 would be the easiest on current xl users.  It's a bit annoying
interface-wise going forward, since "assignable" is probably the best
word for what Juergen wants; and it's not 100% backwards-compatible with
the previous xm usb commands.

#3 would give us probably the most consistent naming thing going
forward, but would be a pretty major breakage for current xl users.

I'm inclined to suggest #2 as the best balance between not disrupting
current users and not confusing future users.

Wei / Ian, any opinions?


Xen-devel mailing list



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