From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chun Yan Liu" Subject: Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API) Date: Mon, 22 Jun 2015 20:42:29 -0600 Message-ID: <55895435020000660004BF30@relay2.provo.novell.com> References: <1433906441-3280-1-git-send-email-cyliu@suse.com> <1433906441-3280-4-git-send-email-cyliu@suse.com> <557EE03F.5040108@suse.com> <557F18E8.8050305@suse.com> <557FFFA9.2070002@suse.com> <5580064D.10600@suse.com> <21888.3129.360614.171879@mariner.uk.xensource.com> <1434540258.13744.332.camel@citrix.com> <5582B4BE.1070202@eu.citrix.com> <55880DCC.6070902@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55880DCC.6070902@eu.citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , George Dunlap , Ian Jackson Cc: Juergen Gross , Jim Fehlig , Simon Cao , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>> On 6/22/2015 at 09:29 PM, in message <55880DCC.6070902@eu.citrix.com>, 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? Fine to me. > > -George > >