Re: [Xen-devel] [PATCH 16/16] xen/events: use the FIFO-based ABI if available

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 10/16/2013 05:46 AM, David Vrabel wrote:
> On 15/10/13 21:39, Boris Ostrovsky wrote:
> > On 10/15/2013 02:58 PM, David Vrabel wrote:
> > > On 14/10/13 20:30, Boris Ostrovsky wrote:
> > > > On 10/08/2013 08:49 AM, David Vrabel wrote:
> > > > > @@ -1636,7 +1637,13 @@ void xen_callback_vector(void) {}
> > > > >       void __init xen_init_IRQ(void)
> > > > >     {
> > > > > -    xen_evtchn_2l_init();
> > > > > +    int ret;
> > > > > +
> > > > > +    ret = xen_evtchn_fifo_init();
> > > > > +    if (ret < 0) {
> > > > > +        printk(KERN_INFO "xen: falling back to n-level event
> > > > > channels");
> > > > > +        xen_evtchn_2l_init();
> > > > > +    }
> > > > Should we provide users with ability to choose which mechanism to use?
> > > > Is there any advantage in staying with 2-level? Stability, I guess,
> > > > would be one.
> > > If someone can demonstrate a use case where 2-level is better then we
> > > could consider an option.  I don't think we want options for new
> > > software features just because they might be buggy.
> > I think we should always try to have a way to force old behavior when a
> > new feature is introduced. If a user discovers a bug we don't want them
> > to wait for a fix when a simpler solution is possible. I can see that
> > having this option in the kernel may be a bit too much but is there at
> > least an option to force 2-level in the hypervisor?
> 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.
-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel