[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
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 <jgross@xxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |