From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V4 3/7] libxl: add pvusb API Date: Thu, 18 Jun 2015 15:03:05 +0200 Message-ID: <5582C189.5010602@suse.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5582B4BE.1070202@eu.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: George Dunlap , Ian Campbell , Ian Jackson Cc: Jim Fehlig , Simon Cao , Wei Liu , Chunyan Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 06/18/2015 02:08 PM, George Dunlap wrote: > 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). +1 Juergen