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

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 6/22/2015 at 09:29 PM, in message <55880DCC.6070902@xxxxxxxxxxxxx>, 
>>> George
Dunlap <george.dunlap@xxxxxxxxxxxxx> 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? 

Fine to me.

>  
>  -George 
>  
>  


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