[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
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@xxxxxxxxx> 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |