[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.