From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 16/16] xen/events: use the FIFO-based ABI if available Date: Wed, 16 Oct 2013 14:49:48 +0100 Message-ID: <525E997C.2080306@citrix.com> References: <1381236555-27493-1-git-send-email-david.vrabel@citrix.com> <1381236555-27493-17-git-send-email-david.vrabel@citrix.com> <525C4663.70907@oracle.com> <525D906C.5080401@citrix.com> <525DA7E7.8020009@oracle.com> <525E607D.8040900@citrix.com> <525E9413.70907@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <525E9413.70907@oracle.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: Boris Ostrovsky Cc: Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 16/10/13 14:26, Boris Ostrovsky wrote: > On 10/16/2013 05:46 AM, David Vrabel wrote: >> >> The majority of the risk in this series is the refactoring patches and >> not the new ABI code so an option to disable it wouldn't really help. >> >> Also, if we are not confidant that a feature is production ready that we >> need knobs to turn it off then we shouldn't merge it. > > I disagree. If this were the case then hardware wouldn't have chicken > bits and there wouldn't exist half of "no*" options to kernel, for example. > > We are introducing a rewrite of a critical component of the system. It > has bugs (by definition) and there should be a way to fall back to an > implementation that presumably has fewer bugs. Ok. David