Re: [libvirt] [PATCH LIBVIRT v1 1/2] libxl: Correct value for xendConfigVersion to xen{Parse, Format}ConfigCommon

On Fri, 2015-12-04 at 10:01 +0000, Daniel P. Berrange wrote: > On Thu, Dec 03, 2015 at 11:13:06PM -0700, Jim Fehlig wrote: > > On 11/26/2015 09:59 AM, Ian Campbell wrote: > > > libxlConnectDomainXMLFromNative calls both xenParseXM and xenParseXL > > > with cfg->verInfo->xen_version_major, however AFAICT they both > > > (either > > > inherently, or through there use of xenParseConfigCommon expect a > > > value from xenConfigVersionEnum (which does not correspond to > > > xen_version_major). > > > > I recall being a little apprehensive about using xen_version_major when > > writing > > the code, and apparently that was justified. But now that we are > > revisiting > > this, I wonder if we care about these old xend config versions at all. > > Is anyone > > even running Xen 3.0.x, or 3.1.x, particularly with a newish libvirt? > > IMO we > > could drop all of this xend config nonsense and go with the code > > associated with > > the last xend config version, i.e. XEND_CONFIG_VERSION_3_1_0. > > > > And while mentioning dropping support for these old xend config > > versions, do I > > dare mention dropping the xend driver altogether? :-) It will certainly > > need to > > be done some day. Question is whether that's a bit premature now. > > We just decided to drop QEMU driver code supporting for RHEL-5 vintage > distros, requiring RHEL-6 as minimum. So I think it is entirely reasonable > to drop Xen driver code supporting similar vintage XenD.  That would > certainly simplify or even eliminate the current crazy xend_config_version > code we have RHEL 6.0 looks[0] to have been release on 2010-11-09, which was in the middle of Xen 4.0 and 4.1[1]. 4.0 seems like a decent enough cut off point (and is what is in Debian oldstable AKA Wheezy, FWIW) plus it is after the currently latest XEND_CONFIG_VERSION, so all that code could be removed. Shall I respin this series with that as a precursor?