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).
