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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Fri, Dec 04, 2015 at 02:19:33PM +0000, Ian Campbell wrote:
> 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?

Yeah, that sounds reasonable. Would let us drop all Xen 3.x support
essentially.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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