[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."
On 04/11/2017 05:53 AM, Andrew Cooper wrote: On 10/04/17 19:48, Boris Ostrovsky wrote:The following is meant as a real question without any prejudice: How old a Xen version do we want to support in the Linux kernel? - Only those being still maintained (meaning getting security fixes)Definitely not this. 4.4 is the oldest version receiving official XSA patches and it's only 3 years old.- Versions max. X years after getting last security fixes (what value of X?) - From version Y on (what value of Y?) - All versions which we can think of I think we should answer this question in order to know what we can remove in the Linux kernel without breaking something.Ideally, "All versions which we can think of", unless it becomes too difficult. In that case, I would switch to "From version Y" where Y is not troublesome to support (and older than the oldest supported Xen release).So Oracle, for example, officially supports its virtualization product for 8 to 10 years. Which means that 10 years after a product is released it is possible to see new version of Linux on such a product (although realistically vendors may generally support more limited sets of guests). If we are to follow this line of reasoning Xen 3.4 needs to be supported --- it was released in 2009.Citrix XenServer is also 10 years. From what I understand, SUSE are still supporting Xen 3.2 based products, which is the same kind of vintage. I think the right thing is indeed to revert 72a9b186292 (and therefore da72ff5bfcb02). Any objections? The only possible remaining issue is that kernels not using vector callbacks running on post-4.0 Xen won't work. But we always use callbacks if they are available (and they are post 4.0). -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |