From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
Chunyan Liu <cyliu@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jim Fehlig <jfehlig@suse.com>, Simon Cao <caobosimon@gmail.com>
Subject: Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)
Date: Mon, 22 Jun 2015 14:29:48 +0100 [thread overview]
Message-ID: <55880DCC.6070902@eu.citrix.com> (raw)
In-Reply-To: <5582B4BE.1070202@eu.citrix.com>
On 06/18/2015 01:08 PM, George Dunlap wrote:
> 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).
So Ian J, Ian C, Wei and I chatted face-to-face about what to do going
forward; below are some key points we discussed and the conclusion we
came to. Decisions are only official when they've been discussed on the
list, so please consider this a proposal and give your feedback. :-)
(Also, Ian/Ian/Wei, let me know if I've misremembered or forgotten
something.)
Points of discussion:
* We would ideally like to be able to have the released interface work
both for both PV and HVM; for one so that we don't have to have separate
#defines for that functionality; but also to make sure that the
interface is suitable for both functionalities.
* It's difficult at the moment to actually do collaborative development
on the libxl USB feature, because the code is not yet in the tree.
* Regarding user-facing interfaces (like xl, as opposed to libxl): the
interface cannot be half-baked; it should not provide functionality
which works most of the time but sometimes will fail.
Having only "bus-ports" or "vendorid:deviceid" is not sufficient,
because it will lure the user into thinking that they can put those
numbers into a config file and get repeatable results every time. But
since bus numbers change, and vendorid:deviceid is not unique, either of
these would be a false promise.
Udevs ID_PATH naming scheme seems like a sensible thing to adopt, at
least for Linux. We could consider making an OS-specific string for
identifying the same device across reboots.
On the other hand, bus.address is very obviously unstable; nobody in
their right mind would use it for anything they wanted to persist across
reboots. So including bus.address as a temporary measure to be able to
test the underlying library until we get a more reliable naming scheme
in place would be OK, as long as the UI interface could be extended
going forward.
* We should avoid adding complexity to the libxl interface until it's
needed; accepting one way of specifying USB devices, and letting the
toolstack do translation into that way of specifying it (perhaps
providing helper libraries to do so), should be enough for now. The way
of specifying USB devices does not need to be stable across reboots, as
long as it won't change between the time the toolstack does the
translation and the time the device is plugged in.
bus.address is the best specification from that point of view: it's
unique (unlike device:vendorid), and if a device is unplugged and
another one plugged in between the time the translation happens and the
time libxl gets around to doing something, the old bus.address won't
exist anymore and the command will fail.
* There may be a point in the future when we want to be able provide
device auto-plug functionality at the libxl layer. (i.e., "When device
X shows up, please plug it into VM Y.") For this we will need a
reliable way of specifying devices; bus.address will not do.
But that functionality doesn't exist yet; so for now we should stick
with bus.address, but design the interface such that it can be extended
with more options for specifying a device when such functionality is neede.
With all that in mind, here is a proposal:
1. For the moment, only use bus.address at the libxl layer to specify a
device.
2. Let's check in the libxl part of Chunyan's PVUSB series as soon as
the 4.7 development window opens (assuming the coding style issues have
all been addressed). We can also check in the xl functionality with
minimal bus.address support for testing.
3. I will the port the HVM USB series and submit them as soon as possible.
4. We work on a set of helper functions that a toolstack can use to
translate other ways of specifying a device, much like the disk
specification helper functions that we provide. One of these should be
something which is reliably stable over reboots, such as the udev
ID_PATH specification.
Thoughts?
-George
next prev parent reply other threads:[~2015-06-22 13:29 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 3:20 [PATCH V4 0/7] xen pvusb toolstack work Chunyan Liu
2015-06-10 3:20 ` [PATCH V4 1/7] libxl: export some functions for pvusb use Chunyan Liu
2015-06-11 16:08 ` Ian Jackson
2015-06-11 16:28 ` Wei Liu
2015-06-12 15:14 ` Ian Jackson
2015-06-10 3:20 ` [PATCH V4 2/7] libxl_read_file_contents: add new entry to read sysfs file Chunyan Liu
2015-06-11 16:16 ` Ian Jackson
2015-06-12 7:00 ` Chun Yan Liu
2015-06-12 15:11 ` Ian Jackson
2015-06-10 3:20 ` [PATCH V4 3/7] libxl: add pvusb API Chunyan Liu
2015-06-11 15:00 ` Juergen Gross
2015-06-11 16:07 ` Ian Jackson
2015-06-11 16:42 ` Ian Jackson
2015-06-12 7:39 ` Chun Yan Liu
2015-06-12 8:06 ` Chun Yan Liu
2015-06-12 11:22 ` Ian Jackson
2015-06-15 14:17 ` George Dunlap
2015-06-15 14:25 ` Jürgen Groß
2015-06-15 14:34 ` George Dunlap
2015-06-15 18:26 ` Juergen Gross
2015-06-16 10:30 ` George Dunlap
2015-06-16 10:51 ` Juergen Gross
2015-06-16 11:11 ` George Dunlap
2015-06-16 11:19 ` Juergen Gross
2015-06-16 11:23 ` George Dunlap
2015-06-16 11:44 ` Ian Jackson
2015-06-17 11:24 ` Ian Campbell
2015-06-18 11:50 ` George Dunlap
2015-06-18 12:08 ` George Dunlap
2015-06-18 13:03 ` Juergen Gross
2015-06-22 13:29 ` George Dunlap [this message]
2015-06-22 14:14 ` Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API) Juergen Gross
2015-06-22 14:22 ` Ian Jackson
2015-06-23 2:42 ` Chun Yan Liu
2015-06-23 2:43 ` Chun Yan Liu
2015-06-23 2:44 ` Chun Yan Liu
2015-06-16 10:41 ` [PATCH V4 3/7] libxl: add pvusb API Ian Jackson
2015-06-16 10:56 ` Jürgen Groß
2015-06-16 11:03 ` George Dunlap
2015-06-16 11:10 ` Ian Jackson
2015-06-16 11:25 ` Juergen Gross
2015-06-16 11:45 ` George Dunlap
2015-06-16 12:02 ` Ian Jackson
2015-06-16 13:19 ` George Dunlap
2015-06-16 13:32 ` Juergen Gross
2015-06-16 13:37 ` [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages] Ian Jackson
2015-06-16 14:41 ` George Dunlap
2015-06-16 15:58 ` Sander Eikelenboom
2015-06-16 15:59 ` Ian Jackson
2015-06-16 16:34 ` George Dunlap
2015-06-17 3:59 ` Juergen Gross
2015-06-17 10:27 ` George Dunlap
2015-06-18 6:24 ` Chun Yan Liu
2015-06-16 11:45 ` [PATCH V4 3/7] libxl: add pvusb API Ian Jackson
2015-06-16 13:06 ` Juergen Gross
2015-06-16 13:09 ` George Dunlap
2015-06-16 13:23 ` Juergen Gross
2015-06-16 13:29 ` George Dunlap
2015-06-16 13:49 ` Juergen Gross
2015-06-16 14:06 ` George Dunlap
2015-06-16 14:20 ` Juergen Gross
2015-06-16 14:37 ` George Dunlap
2015-06-17 11:34 ` Ian Campbell
2015-06-17 11:40 ` Juergen Gross
2015-06-18 6:20 ` Chun Yan Liu
2015-06-18 7:02 ` Juergen Gross
2015-06-18 8:50 ` Ian Campbell
2015-06-18 13:02 ` Juergen Gross
2015-06-16 15:38 ` George Dunlap
2015-06-16 11:01 ` George Dunlap
2015-06-16 11:12 ` Ian Jackson
2015-06-16 11:21 ` George Dunlap
2015-06-16 16:32 ` Ian Jackson
2015-06-16 16:39 ` George Dunlap
2015-06-16 16:51 ` Ross Philipson
2015-06-17 4:03 ` Jürgen Groß
2015-06-17 13:48 ` Ross Philipson
2015-06-15 17:47 ` George Dunlap
2015-06-23 10:18 ` Chun Yan Liu
2015-06-23 11:29 ` George Dunlap
2015-06-24 2:26 ` Chun Yan Liu
2015-06-10 3:20 ` [PATCH V4 4/7] libxl: add libxl_device_usb_assignable_list API Chunyan Liu
2015-06-10 3:20 ` [PATCH V4 5/7] xl: add pvusb commands Chunyan Liu
2015-06-12 7:37 ` Juergen Gross
2015-06-12 8:03 ` Chun Yan Liu
2015-06-12 8:22 ` Juergen Gross
2015-06-10 3:20 ` [PATCH V4 6/7] xl: add usb-assignable-list command Chunyan Liu
2015-06-10 3:20 ` [PATCH V4 7/7] domcreate: support pvusb in configuration file Chunyan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55880DCC.6070902@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=caobosimon@gmail.com \
--cc=cyliu@suse.com \
--cc=ian.campbell@citrix.com \
--cc=jfehlig@suse.com \
--cc=jgross@suse.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.