From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwLV3-0001Ts-GY for qemu-devel@nongnu.org; Tue, 10 Nov 2015 21:51:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwLV0-0005tA-70 for qemu-devel@nongnu.org; Tue, 10 Nov 2015 21:51:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwLUz-0005su-V0 for qemu-devel@nongnu.org; Tue, 10 Nov 2015 21:51:02 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id D513442E5DD for ; Wed, 11 Nov 2015 02:51:00 +0000 (UTC) References: <1446791754-23823-1-git-send-email-eblake@redhat.com> <1446791754-23823-30-git-send-email-eblake@redhat.com> <871tbzdwol.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <5642AD0E.9050003@redhat.com> Date: Tue, 10 Nov 2015 19:50:54 -0700 MIME-Version: 1.0 In-Reply-To: <871tbzdwol.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Eg39iJD9E3Br7eITDL59MtxLC5sv5QriJ" Subject: Re: [Qemu-devel] [PATCH v10 29/30] cpu: Convert CpuInfo into flat union List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Eg39iJD9E3Br7eITDL59MtxLC5sv5QriJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/09/2015 08:22 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> When qapi type CpuInfo was originally created for 0.14, we had >> no notion of a flat union, and instead just listed a bunch of >> optional fields with documentation about the mutually-exclusive >> choice of which instruction pointer field(s) would be provided >> for a given architecture. But now that we have flat unions and >> introspection, it is better to segregate off which fields will >> be provided according to the actual architecture. With this in >> place, we no longer need the fields to be optional, because the >> choice of the discriminator serves that role. >> >> This has an additional benefit: the old all-in-one struct was >> the only place in the code base that had a case-sensitive >> naming of members 'pc' vs. 'PC'. Separating these spellings >> into different branches of the flat union will allow us to add >> restrictions against future case-insensitive collisions, and >> make it possible for a future qemu to decide whether to enable >> case-insensitive QMP. >> ## >> # @query-cpus: >=20 > CpuInfo is only used as return type of query-cpus. >=20 > If I understand the change correctly, the value of query-cpus is not > changed at all. Its introspection, however, is. Almost. The output of query-cpus gains a new 'arch':'FOO' string per cpu, saying which branch of the flat union is in use. But as it is output-only, adding a new output field shouldn't break any existing clients (because QMP already documents that clients should ignore new fields); and since the struct is output-only, it can't break any input fields. I probably can spell that out better in the commit message, though. Oh, and I need to update qmp-commands.hx, as part of my v11 spin. >=20 > Do we need this to make 2.5? It's true that the introspection will change (instead of seeing flat optional members, you now have to chase down variants). But I don't think it is pressing enough to rush into 2.5; the change is backwards-compatible no matter when we do it, and introspection clients are going to have to get used to the idea of chasing down different paths to find all members of a struct (that is, if we don't change this until 2.6, I'm sure it won't be the last case of introspection changing while keeping QMP wire format back-compatible as formerly non-variant fields become variant). >=20 > Any other messy optionals that should really be (flat) unions? >=20 Possibly. /me goes and audits all 0.14 interfaces... add_client is an input command, but it would be nicer as a flat union (we can't do that until commands can take unions; but that happens as part of my pending queue for netdev_add), so that's not going to make 2.5= =2E client_migrate_info looks odd, since it requires 'protocol':'str' to be the value 'spice'. Probably several functions that take or produce a finite set of strings that should be using enums, but conversion from 'str' to 'enum' is backwards-compatible according to QMP wire format. Doing it sooner rather than later makes introspection nicer. But I didn't spot any other obvious commands from that far back with mutually-exclusive optional parameters, and certainly nothing else with case clashes. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Eg39iJD9E3Br7eITDL59MtxLC5sv5QriJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWQq0PAAoJEKeha0olJ0NqRXsH/1NACbzpmdS3Nx2ebt5brT8R AJ9eMvjEhch1nbwJdSwbVxZKUaKRIkJ0cxU5B3tPFhggAhMX6pY4ITGsVR2J9OvQ p6FR5wZHdtlJihvcAO/eKATCUXPYQNlw1Q4tj7m7m7HkM0HpLjQOroGYVo/aPe1w bC7fx2PgcELlU1Lhzd4MxJsCxTv0K7KOb05oVMLaNOQjVE58vNMKOFvRCAXNe+MA wClkKCD0l+p+fstakb1k2edl6Ant+FfsnNNN/235NWUMMWJgxDrHnsnidTXAmFat +mAIyDZAmLFqy0X2pb1JEwvmAko86JY/kZrjMjV5vc1FSnUO/YvqB6GGEVS4gWw= =gHJS -----END PGP SIGNATURE----- --Eg39iJD9E3Br7eITDL59MtxLC5sv5QriJ--