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? Ian. [0] https://access.redhat.com/articles/3078 [1] http://wiki.xen.org/wiki/Xen_Release_Features
I think we need to continue suppoorting XenD driver for a while, but at least you can simplify the code shared with libxl.
Regards, Daniel