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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 05/21/2015 11:52 AM, Juergen Gross wrote:
>>  From your description, "xm usb-assignable-list" would list *all* USB
>> devices on the system which were available to be assigned to a guest.
>>
>> "xl pci-assignable-list" does *not* list all PCI devices on a system
>> which are available to be assigned.  It lists the ones which can be
>> assigned without the "seize=1" parameter -- the ones you've already done
>> something with.  It won't tell you about the other devices on the system
>> which have not yet been assigned to pciback.
> 
> So "xl pci-assignable-list" is suppressing some of the PCI devices which
> in theory could be assigned. I don't think this "weird" behaviour should
> be mimicked by "xl usb-assignable-list".

That's not really an accurate characterization.  I introduced the
concept of "assignable" because under xm, you had to manually much about
in sysfs yourself to assign the device to pciback before attaching it to
a guest.  So "pci-assignable-add" takes a device and assigns it to
pciback; "pci-attach" attaches an assignable device to the guest.
"pci-assignable-list" lists the devices which have been made
"assignable" under this new definition.

> 
>> Yes, from a pedantic perspective, both will tell you on which devices
>> you can run "X-attach" without any extra arguments.  But from a
>> practical perspective, "xm usb-assignable-list" tells you something
>> practical about the state of devices on the whole system; and "xl
>> pci-assignable-list" tells you a technical quirk about devices are in a
>> half-way state between not being assigned and actually being assigned.
> 
> I can't believe you are suggesting to use "a technical quirk" as a good
> example for future development. Just because a user interface isn't
> perfect shouldn't result in other interfaces to behave in the same
> imperfect way.

You seem to have missed in my tone that I think "xm usb-assignable-list"
behavior is more useful.  I said that "xm usb-assignable-list" gave you
practical information, and I said that "xl pci-assignable-list" gives
you about a technical quirk.  I also said that "pci-assignable" a state
half-way in between being assigned and not assigned, which I personally
think portrays it as rather clunky.

I never claimed that we should make the new usb-*-list command mimic
pci-assignable-list.  What I'm responding to is your claim that they do
similar things, and so implying that it should be OK for them to have
similar names.  They do not do the similar things, and therefore they
must not have similar names.

So, as I said in the previous e-mail:
* I think that it would definitely be useful to have the "xm
usb-assignable-list" functionality.
* But we cannot give it the same name as the current "xl
pci-assignable-list" functionality, since they behave differently
* I think "assignable" is the best name for what "xm
usb-assignable-list" does; however,
* We have existing users to consider; I think choosing a different name
(like "xl usb-available-list") will have the lowest negative impact on
existing users.

>> (I'm about 45% of the opinion that we should make pci behave like the
>> proposed USB patches -- i.e., make seize=1 the default, and just
>> deprecate the whole "pci-assignable" state altogether.  My only
>> hesitation is that it removes one level of safety check against doing
>> something like unplugging the host's main disk controller or something.)
> 
> You could add a configuration item in xl.conf for setting the default
> behaviour, defaulting to "default_seize=1". :-)

I think we have that already, actually.  (If not at least we discussed
it.)  But unfortunately that doesn't help us in the current situation,
as the "pci-assignable" state still exists, and we still need commands
to deal with it.

 -George

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