From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Scalable Event Channel ABI design (draft A) Date: Wed, 6 Feb 2013 11:32:41 +0000 Message-ID: <51123F59.6030901@eu.citrix.com> References: <51111BCA.3010207@citrix.com> <1360077399.7477.148.camel@zion.uk.xensource.com> <51115636.6080907@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51115636.6080907@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: Keir Fraser , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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