Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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

[snip]

> As a slight aside to this, can't libxl use libusb for a lot of this
> stuff and therefore avoid being Linux specific?
>
> http://libusb.info/ claims to support "Linux, OS X, Windows, Windows CE,
> Android, OpenBSD/NetBSD, Haiku.". Interestingly FreeBSD is missing there
> but I don't think that need to be a blocker.
>
> I don't see a problem with adding libusb to our set of dependencies, and
> it's certainly got to be better than (re)implementing a bunch of sysfs
> stuff (which I presume is what libusb does under the hood anyway).

OK, so we have three interfaces:

* User <-> toolstack
* toolstack <-> libxl
* libxl <-> underlying functionality (Linux pvusbback and qemu, at the
moment)

And we're also now considering whether to do a "minimal interface" in
libxl (i.e., only accept one kind of specification and make the
toolstack do the conversion from a more useful spec) or do a "rich
interface" (i.e., accept many different kinds of specification, allowing
the toolstack to just pass things through).

qemu already uses libusb, and so can already do almost everything that
libxl could use libusb to accomplish.  The only things it doesn't do
that we've talked about doing are the bus-ports specification, and the
"vendorid:deviceid:serialno" specification; both of which would be
trivial (and probably useful) to add.

So for all the things libusb can be used to convert between, we don't
actually need to do any conversion when speaking to qemu (unless we want
to be backwards compatible with older versions).

The udev "id_path" specification isn't something that libusb can handle;
we'd have to mess around with sysfs and/or udev-created device nodes /
symbolic links into sysfs anyway.

So for the qemu side of things, libusb is mostly useless.

We can't get around using sysfs to talk to pvusbback -- that's how it
works.  At the moment, the pvusbback interface requires sysfs strings,
which happen to be described in the bus-ports:interface format.  So the
main reason we're messing around with sysfs at the moment is to convert
other specifications into the sysfs strings suitable for using with pvusb.

To convert into a sysfs string ourselves:
* readdir on /sys/bus/usb/devices
* for each entry, look inside to see if it matches the specification
(i.e., bus==busnum, addr==devnum, &c)
* take the directory name of the entry that matches
* look inside that directory for all the interfaces for that device (so
we can assign each one to pvusbback).
* Write the strings you read from sysfs into the appropriate "bind"
nodes in pvusbback

To convert bus.addr into a sysfs string with libusb:
* libusb_get_device_list [1]
* for each entry, call libusb_get_device_descriptor and see if it
matches the specification (i.e., bus==bus, addr==addr, &c)
* Call libusb_get_ports to get an array of the port numbers
* Construct a sysfs string from the bus number and the array of port
numbers (i.e., %d-%d[.%d.%d])
* Get information about all the interfaces, and construct sysfs strings
from those as well
* Write the constructed strings into the pciback sysfs nodes

A couple of points:
1. The second is certainly not simpler than the first
2. The only code that needs to do it is completely linux-specific at the
moment anyway (since it's talking to the linux driver)
3. The first uses strings that it pulled directly from sysfs; the second
relies on constructing strings
4. If we do a "minimal interface" in libxl, then the toolstack will also
have to link against libusb to convert from a more useful specification
to the libxl specification

So it seems to me that libusb doesn't actually have that much to offer
us.  For the only situation where it actually is cross-platform (i.e.,
qemu), it's not needed; for the one situation where it could be used
(converting to sysfs-style strings for pvusbback), it's not simpler,
probably less robust, and its cross-platform capability is moot (since
it's a Linux-only driver anyway).

 -George

[1] See http://libusb.sourceforge.net/api-1.0/group__dev.html and
http://libusb.sourceforge.net/api-1.0/group__desc.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel