[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.
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, (continued)
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Markus Armbruster, 2015/02/04
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Peter Maydell, 2015/02/04
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Markus Armbruster, 2015/02/04
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Daniel P. Berrange, 2015/02/04
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Peter Maydell, 2015/02/04
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Paolo Bonzini, 2015/02/04
- Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels,
Markus Armbruster <=
Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Dr. David Alan Gilbert, 2015/02/04
Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Eric Blake, 2015/02/04
Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Dr. David Alan Gilbert, 2015/02/05
Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels, Paolo Bonzini, 2015/02/04