From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries) Date: Tue, 22 Sep 2015 22:31:57 +0100 Message-ID: References: <1436975173.32371.121.camel@citrix.com> <1442934190.10338.175.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1442934190.10338.175.camel@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: Ian Campbell Cc: Ian Jackson , Stefano Stabellini , Wei Liu , Roger Pau Monne , xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, 22 Sep 2015, Ian Campbell wrote: > (dropping minios-devel) > > Stefano, > > On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote: > > > > There are 3 series, against xen.git (15 patches), mini-os.git (5 > > patches) and qemu-xen-trad.git (5 patches). The patches against xen.git > > point to the patches in the other two trees via instructions to update > > the relevant Config.mk field. The perils of changing unstable > > interfaces! > > I started looking into making the appropriate changes to QEMU upstream to > use the new libraries directly. > > QEMU (in include/hw/xen/xen_common.h) includes compat shims for libxenctrl > versions back as far as 3.3.0. > > The main distinction is between pre-4.1.0 and 4.1.0 and later, since > various handles switching from int's to opaque pointers at that point, > meaning there are some typedefs and wrappers for things. > > My plan was to rework the QEMU code to use only the new library function > names for everything such that this becomes the default case (which makes > sense given these libraries are intended to be long term stable) and to > update the code in xen_common.h to bridge the gap to 4.6 and earlier. > > But I'm having to jump through some hoops in order to support the pre-4.1.0 > version of things. It's not impossible to support it, I'm sure, but things > would be a lot easier if we could just drop that support code. > > Can we consider dropping support for Xen 4.0 and earlier from upstream QEMU > at this point? > > Some data: Xen 4.0.0 was released in April 2010, the last point release was > 4.0.4 in August 2012 and we no longer do security support for it (for a > year or two now, I think). The oldest Xen version I build-test for every pull request is Xen 4.0.0, I think it is very reasonable to remove anything older than that. I am OK with removing Xen 4.0.0 too, but I would like a warning to be sent ahead of time to qemu-devel to see if anybody complains.