All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.