[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |