[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels

From: Markus Armbruster
Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels
Date: Thu, 05 Feb 2015 08:57:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 4 February 2015 at 16:33, Markus Armbruster <address@hidden> wrote:
>> Peter Maydell <address@hidden> writes:
>>> On 4 February 2015 at 13:49, Markus Armbruster <address@hidden> wrote:
>>>> Remind me: what GLib version are we targeting, and why?
>>> Our current minimum is 2.12 (or 2.20 in Windows specific code),
>>> and the reason is RHEL5/Centos 5.
>> Any idea when we can move on?
>> Don't get me started on the wisdom of developing or deploying upstream
>> QEMU on RHEL-*5*.
> Not all of QEMU's use cases are KVM-using VM deployments, not all
> compute cluster deployments are primarily directed to that, and
> not all industries rev their supported OS platforms very fast.
> For instance the EDA tools industry only added RHEL6 support
> in 2012 for new design starts, and given the typical length of
> a project it's not that implausible to still have RHEL5.

If you can compile upstream QEMU, compiling GLib shouldn't be an
insurmountable obstacle.

> That said, we don't have to insist on supporting the most
> ancient version of everything ever, and now might be a reasonable
> time to move forward. I wouldn't want to move further forward
> than RHEL6's version, though.

Fair enough.

> Moving beyond 2.22 would be awkward for me in that my OSX
> box only has 2.22 because fink doesn't have anything newer.
> I could probably deal with that somehow (switching to some
> other package system, probably).
> Debian stable is "2.33.12+really2.32.4-5" and oldstable
> is "2.24.2-1" (and if my googling is right is an LTS release).
> Ubuntu Lucid (LTS release) is 2.24; Precise (also LTS)
> is 2.32.
> Daniel says RHEL6 has 2.28.
> That suggests to me that we could reasonably advance to
> 2.22 or 2.24 if it seemed beneficial, but not beyond that.
> Is there anything particularly worthwhile that would get us?

"Worthwhile" is in the eye of the beholder.  Chaining ourselves to 7+
year-old libraries means we get to work around annoyances (quick grep:
commit f8833a3 01a2050), we compromise on testing when the libraries are
actually old[*] (commit 9d41401), and certain improvements won't get
done because they're too much of a bother (commit 02c4f26).  These are
all paper cuts.  Is suffering them worthwhile?

[*] Rule of thumb: if you want to run an upstream version of X, run it
under an OS the upstream developers actually use every day, or do your
own testing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]