From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH V4 3/7] libxl: add pvusb API Date: Thu, 18 Jun 2015 13:08:30 +0100 Message-ID: <5582B4BE.1070202@eu.citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434540258.13744.332.camel@citrix.com> 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 , Ian Jackson Cc: Juergen Gross , Wei Liu , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org On 06/17/2015 12:24 PM, Ian Campbell wrote: > On Tue, 2015-06-16 at 12:44 +0100, Ian Jackson wrote: >> George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"): >>> On Tue, Jun 16, 2015 at 12:19 PM, Juergen Gross wrote: >>>> I'm pretty sure this is just a matter of timing during boot: the busses >>>> are all (or at least some of them) queried at the same time and the >>>> first answering gets number 1, the next 2, and so on. And timing seems >>>> to be different enough to result in unstable bus numbers. >>> >>> Right -- I meant "stable in topology within one boot", but at least >>> two of you have now understood me to mean "across reboots" by default, >>> so that's obviously a detail that needs to be specified. :-) >> >> I think "stable in topology within one boot" is nearly vacuous (or are >> we expecting buses or devices to spontaneously renumber themselves for >> no reason) and also nearly useless. >> >> We definitely need _some_ way for a user to identify a specific device >> uniquely in a way that is reliable from one boot to the next. vid:pid >> is one way to do this, but not always sufficient. > > We should perhaps separate out the "end user" from the "libxl > user" (i.e. the toolstack application) in our deliberations here. > > We have the option of settling on a single way of describing a device to > libxl in the libxl API but allowing the toolstack to choose to present > the user with multiple different ways to specify things by providing a > suitable set of helper functions (in either libxlu or libxl proper) from > a variety of schemes to the one true way of describing a device. > > That sounds better to me than having the libxl API consist of the union > of all potentially useful ways to refer to a device. This was my original design. :-) > I'm not sure whether that also gives us the freedom to use something > which is only stable for a given boot at the libxl API layer though. I'm not sure why it doesn't -- as long as things don't change between the time the toostack converts a "stable name" into a specification and the time libxl uses it, it should be fine. One advantage of having a richer interface that Juergen pointed out previously was the ability to specify attaching devices automatically when they show yp; i.e., "If a device with this vendorid:deviceid:serialnumber shows up, please attach it to this VM". But we don't have that functionality now; and there's no reason we couldn't add extra ways of specifying devices in the future. 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). -George