Re: [Xen-devel] Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)

[Juergen Gross <jgross@xxxxxxxx>]

On 06/22/2015 03:29 PM, George Dunlap wrote:
> On 06/18/2015 01:08 PM, George Dunlap wrote:
> > This usb interface stuff is really becoming a morass.  The core
> > functionality is fairly independent of the interface.  I'm inclined to
> > say that we should start with a simple specification (only bus.addr),
> > and try to get both pvusb and hvmusb in.  Then we can talk about where
> > to add additional specifications (including cross-boot stable
> > specifcations).
> So Ian J, Ian C, Wei and I chatted face-to-face about what to do going
> forward; below are some key points we discussed and the conclusion we
> came to.  Decisions are only official when they've been discussed on the
> list, so please consider this a proposal and give your feedback. :-)
>
> (Also, Ian/Ian/Wei, let me know if I've misremembered or forgotten
> something.)
>
> Points of discussion:
>
> * We would ideally like to be able to have the released interface work
> both for both PV and HVM; for one so that we don't have to have separate
> #defines for that functionality; but also to make sure that the
> interface is suitable for both functionalities.
>
> * It's difficult at the moment to actually do collaborative development
> on the libxl USB feature, because the code is not yet in the tree.
>
> * Regarding user-facing interfaces (like xl, as opposed to libxl): the
> interface cannot be half-baked; it should not provide functionality
> which works most of the time but sometimes will fail.
>
> Having only "bus-ports" or "vendorid:deviceid" is not sufficient,
> because it will lure the user into thinking that they can put those
> numbers into a config file and get repeatable results every time.  But
> since bus numbers change, and vendorid:deviceid is not unique, either of
> these would be a false promise.
>
> Udevs ID_PATH naming scheme seems like a sensible thing to adopt, at
> least for Linux.  We could consider making an OS-specific string for
> identifying the same device across reboots.
>
> On the other hand, bus.address is very obviously unstable; nobody in
> their right mind would use it for anything they wanted to persist across
> reboots.  So including bus.address as a temporary measure to be able to
> test the underlying library until we get a more reliable naming scheme
> in place would be OK, as long as the UI interface could be extended
> going forward.
>
> * We should avoid adding complexity to the libxl interface until it's
> needed; accepting one way of specifying USB devices, and letting the
> toolstack do translation into that way of specifying it (perhaps
> providing helper libraries to do so), should be enough for now.  The way
> of specifying USB devices does not need to be stable across reboots, as
> long as it won't change between the time the toolstack does the
> translation and the time the device is plugged in.
>
> bus.address is the best specification from that point of view: it's
> unique (unlike device:vendorid), and if a device is unplugged and
> another one plugged in between the time the translation happens and the
> time libxl gets around to doing something, the old bus.address won't
> exist anymore and the command will fail.
>
> * There may be a point in the future when we want to be able provide
> device auto-plug functionality at the libxl layer.  (i.e., "When device
> X shows up, please plug it into VM Y.")  For this we will need a
> reliable way of specifying devices; bus.address will not do.
>
> But that functionality doesn't exist yet; so for now we should stick
> with bus.address, but design the interface such that it can be extended
> with more options for specifying a device when such functionality is neede.
>
> With all that in mind, here is a proposal:
>
> 1. For the moment, only use bus.address at the libxl layer to specify a
> device.
>
> 2. Let's check in the libxl part of Chunyan's PVUSB series as soon as
> the 4.7 development window opens (assuming the coding style issues have
> all been addressed).  We can also check in the xl functionality with
> minimal bus.address support for testing.
>
> 3. I will the port the HVM USB series and submit them as soon as possible.
>
> 4. We work on a set of helper functions that a toolstack can use to
> translate other ways of specifying a device, much like the disk
> specification helper functions that we provide.  One of these should be
> something which is reliably stable over reboots, such as the udev
> ID_PATH specification.
>
> Thoughts?
I'm absolutely fine with this proposal.


Juergen


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