qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Should we have a 2.0-rc3 ?


From: Alexander Graf
Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ?
Date: Thu, 10 Apr 2014 14:56:51 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0


On 10.04.14 14:51, Eric Blake wrote:
On 04/10/2014 06:46 AM, Alexander Graf wrote:
On 10.04.2014, at 14:44, Eric Blake <address@hidden> wrote:

On 04/10/2014 05:17 AM, Peter Maydell wrote:
So far I know of at least three fixes which should probably
go into 2.0:
* my fix for the configure stack-protector checks on MacOSX
* MST's pull request updating the ACPI test blobs
* MST says we need to update the hex files for ACPI too
   (otherwise you get a different ACPI blob depending on whether
    your build system had iasl or not, if I understand correctly)

Are there any others?
Yes.  The libvirt team is a bit annoyed that the pci bus naming was
changed for PPC but not all architectures, but without a proper QMP
command to probe which naming scheme is in effect.  We thought that the
naming scheme was going to be universally supplied for all arches, not
just PPC.

https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html

Is this something that can be quickly fixed (perhaps by reverting the
PPC patch until a more complete solution is ready), and if so, is it
worth doing for 2.0 proper, rather than waiting for 2.0.1?
Which way works better for you? I'd be perfectly fine with reverting the patch. 
Libvirt is the only reason that path is there in the first place.
Given the shortness of the timing, reverting for 2.0, and fixing it
properly after the release, may be the best path forward (that is, 2.0
will be no different than 1.7 for what libvirt has to special case,
whereas all future versions can be properly introspectable, so that
libvirt has less special casing than what it would need if 2.0 is a
one-off for PPC).

Works well for me.


Alex




reply via email to

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