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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list