[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.