Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote:
> On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Tue, Feb 09, Luis R. Rodriguez wrote:
> > 
> > > Thanks so it seems the other option is to bump the release, can that
> > > be decided? What's the process for deciding that?
> > 
> > Which release should be bumped?
> 
> In so far as TLS is concerned:
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> f40d55081667a716312b9a8b6e13835c4074f56b
> v1.0-rc0~325
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> 7d2a929feba319c18603e324b1750830d6c8b7a1
> v1.5.0-rc0~660
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> d321e1e526810
> v2.5.0-rc0~125^2~2
> 
> As for the other fix I backported for the existing release carried:
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> 98d23704138e0be17a3ed9eb2631077bf92cc028
> v1.1-rc0~785
> 
> I wanted to see what is the current version on Xen for
> qemu-xen-traditional-dir-remote thing, is this the right way to check
> what version is on /tools/qemu-xen-traditional-dir-remote ?
> 
> mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
> (git::dummy)$ cat VERSION
> 0.10.2
> 
> If so.. I'm scared.

qemu-xen-traditional Device Model is the old Xen fork which is maintained
only in order to support old VMs which expect the hardware environment
provided by that old version of QEMU.

The default Device Model since Xen 4.3 has been "qemu-xen", which is our
name for QEMU upstream. Xen 4.6 shipped with a bundled QEMU 2.2.1, but
users (and distros) are free to supply their own (see configure's --with-
system-qemu option) instead.

Hopefully it is clear therefore why just upgrading qemu-xen-traditional to
a newer QEMU is not an option (or rather, that already exists and is the
default via qemu-xen)

If you aren't interested in supporting VMs installed on very old versions
of Xen then it would be reasonable to:
    ./configure --disable-qemu-traditional
and avoid it all together.

So far as making qemu-xen-trad compatible with gcc5 while still retaining
support for building on the oldest platforms we want to support (whatever
those are) I have no real opinion, but it seems some sort of
abstraction/shim layer would be needed to satisfy both cases.

Ian.