From: George Dunlap <george.dunlap@eu.citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, Wei Liu <wei.liu2@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Scalable Event Channel ABI design (draft A)
Date: Wed, 6 Feb 2013 11:32:41 +0000 [thread overview]
Message-ID: <51123F59.6030901@eu.citrix.com> (raw)
In-Reply-To: <51115636.6080907@citrix.com>
On 05/02/13 18:57, David Vrabel wrote:
> What to do here is a non-trivial decision. Possible options include:
>
> 1. Merge the 3-level ABI for 4.3. Work on the FIFO-based ABI in
> parallel, aiming to get this in for 4.4. This means maintaining 3 event
> channel ABIs in Xen.
>
> 2. Slip the 4.3 release for 2-3 months and merge the FIFO-based ABI in.
>
> 3. Status quo. Defer extending the event channel ABI to 4.4.
>
> The preferable option may be to:
>
> 4. Get the 3-level ABI to a mergable state. In parallel develop a
> prototype of the FIFO-based ABI. When the prototype is ready or the 4.3
> freeze is here, evaluate it and make a decision then.
Just to clarify, the difference between #1 and #4 is that in #4 we hold
off on the merge, to delay committing to a specific course of action
until later?
That seems at first blush to be a pretty safe option. But I think it's
worth pointing out that in practice the end result is likely to be that
we just go with #1 eventually anyway: if the FIFO ABI can't be finished
in 4 months giving it all our effort, can we really expect it to be
finished in any less time while polishing up the 3-level ABI?
I was going to say, "There's no particular reason to merge the 3-level
ABI sooner rather than later", but of course there is: it allows
considerably longer and wider testing.
No conclusion here, just adding to the mix of things to consider. :-)
-George
next prev parent reply other threads:[~2013-02-06 11:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 17:52 Scalable Event Channel ABI design (draft A) David Vrabel
2013-02-04 19:59 ` Keir Fraser
2013-02-05 14:48 ` David Vrabel
2013-02-05 15:16 ` Wei Liu
2013-02-05 18:05 ` George Dunlap
2013-02-05 18:57 ` David Vrabel
2013-02-05 19:03 ` Wei Liu
2013-02-06 11:32 ` George Dunlap [this message]
2013-02-06 13:53 ` Keir Fraser
2013-03-14 19:20 ` David Vrabel
2013-02-05 15:49 ` Keir Fraser
2013-02-05 15:54 ` David Vrabel
2013-02-05 16:11 ` Ian Campbell
2013-02-05 18:02 ` Keir Fraser
2013-02-06 9:38 ` Ian Campbell
2013-02-06 10:41 ` Keir Fraser
2013-02-06 10:42 ` Wei Liu
2013-02-06 10:52 ` Ian Campbell
2013-02-06 11:09 ` Wei Liu
2013-02-05 16:11 ` Keir Fraser
2013-02-06 11:46 ` Jan Beulich
2013-02-04 21:07 ` Wei Liu
2013-02-04 22:16 ` Keir Fraser
2013-02-05 18:36 ` David Vrabel
2013-02-05 16:10 ` Ian Campbell
2013-02-05 18:18 ` David Vrabel
2013-02-06 9:35 ` Ian Campbell
2013-02-06 9:13 ` Ian Campbell
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=51123F59.6030901@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=david.vrabel@citrix.com \
--cc=keir.xen@gmail.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.