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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

On 04/10/2014 06:46 AM, Alexander Graf wrote:
> 
> On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> 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).

> 
> 
> Alex
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]