From: "Chun Yan Liu" <cyliu@suse.com>
To: Ian Campbell <ian.campbell@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Juergen Gross <JGross@suse.com>, Jim Fehlig <JFEHLIG@suse.com>,
Simon Cao <caobosimon@gmail.com>, Wei Liu <wei.liu2@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)
Date: Mon, 22 Jun 2015 20:43:51 -0600 [thread overview]
Message-ID: <55895487020000660004BF39@relay2.provo.novell.com> (raw)
In-Reply-To: <55880DCC.6070902@eu.citrix.com>
>>> On 6/22/2015 at 09:29 PM, in message <55880DCC.6070902@eu.citrix.com>, George
Dunlap <george.dunlap@eu.citrix.com> wrote:
> 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?
Fine to me.
>
> -George
>
>
next prev parent reply other threads:[~2015-06-23 2:43 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 ` Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API) George Dunlap
2015-06-22 14:14 ` 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 [this message]
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=55895487020000660004BF39@relay2.provo.novell.com \
--to=cyliu@suse.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JFEHLIG@suse.com \
--cc=JGross@suse.com \
--cc=caobosimon@gmail.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.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.