From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYETG-0002f5-PO for qemu-devel@nongnu.org; Thu, 10 Apr 2014 08:52:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYETB-0001Hd-OM for qemu-devel@nongnu.org; Thu, 10 Apr 2014 08:52:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYETB-0001H4-C2 for qemu-devel@nongnu.org; Thu, 10 Apr 2014 08:52:41 -0400 Message-ID: <534693D5.20603@redhat.com> Date: Thu, 10 Apr 2014 06:51:33 -0600 From: Eric Blake MIME-Version: 1.0 References: <5346921A.2050705@redhat.com> <4FBBA28F-184E-45A4-A7B8-6F4ED4EFC205@suse.de> In-Reply-To: <4FBBA28F-184E-45A4-A7B8-6F4ED4EFC205@suse.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CS4AclOtxPagX5MFFaoaV1Jg2i4G3cRaw" Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , "Michael S. Tsirkin" , Michael Roth , QEMU Developers , Anthony Liguori , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CS4AclOtxPagX5MFFaoaV1Jg2i4G3cRaw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/10/2014 06:46 AM, Alexander Graf wrote: >=20 > On 10.04.2014, at 14:44, Eric Blake wrote: >=20 >> 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 th= e >> 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? >=20 > Which way works better for you? I'd be perfectly fine with reverting th= e patch. Libvirt is the only reason that path is there in the first place= =2E 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). >=20 >=20 > Alex >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --CS4AclOtxPagX5MFFaoaV1Jg2i4G3cRaw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTRpPVAAoJEKeha0olJ0Nqv90IAKde/pb4wreQLle1P49Wl29b 7MR2OlCjm+42AOz/NEg27ZAnnRGGPNSP2bvxzYDQSGLBxhg/DwMG6RjWKCltIQX7 sWsypCfXSVGGrIgYSmSy/jXEy6mkBscjQ4U2kMsI9TvgJMMUKNjsbqXkic8DPBiq Fcd/fmaQQW6JTnGNqXHWMnoAidnagB1ypfZaw/Pd4hpWOhjr52MG4yHQPHHLyqgW 1CLQWEc/HULn43jqBHzvKoDRptGKhYbRrWPfgHOJpYHmYsqHho5v8N2JcsfN5ntj 1nrtHLZRaiQMcDHuT3FspwdkHRN+cLUwIoHey+cCvpUkS3p1cUzcve5C2Lsalxg= =LRGh -----END PGP SIGNATURE----- --CS4AclOtxPagX5MFFaoaV1Jg2i4G3cRaw--