From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YczlP-00083f-Dn for qemu-devel@nongnu.org; Tue, 31 Mar 2015 13:15:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YczlK-0002gd-F6 for qemu-devel@nongnu.org; Tue, 31 Mar 2015 13:15:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YczlJ-0002gG-Pc for qemu-devel@nongnu.org; Tue, 31 Mar 2015 13:15:37 -0400 Date: Tue, 31 Mar 2015 19:15:33 +0200 From: Kevin Wolf Message-ID: <20150331171533.GE4748@noname.redhat.com> References: <1427227433-5030-1-git-send-email-eblake@redhat.com> <1427227433-5030-2-git-send-email-eblake@redhat.com> <20150331150958.GB4748@noname.redhat.com> <551AD434.8070203@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <551AD434.8070203@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 01/28] qapi: Document type-safety considerations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: armbru@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, wenchaoqemu@gmail.com, lcapitulino@redhat.com --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 31.03.2015 um 19:07 hat Eric Blake geschrieben: > On 03/31/2015 09:09 AM, Kevin Wolf wrote: > > Am 24.03.2015 um 21:03 hat Eric Blake geschrieben: > >> Go into more details about the various types of valid expressions > >> in a qapi schema, including tweaks to document fixes being done > >> later in the current patch series. Also fix some stale and missing > >> documentation in the QMP specification. > >> > >> Signed-off-by: Eric Blake >=20 > >> +A flat union definition specifies a complex type as its base, and > >> +avoids nesting on the wire. In this case, the fields of the complex > >> +type are included as top-level fields of the union dictionary in the > >> +QMP wire format, and the 'discriminator' field must be the name of an > >> +enum-typed member of the base type. An example definition is: > >=20 > > Adding full context: > >=20 > > { 'type': 'BlockdevCommonOptions', 'data': { 'readonly': 'bool' } } > > { 'union': 'BlockdevOptions', > > 'base': 'BlockdevCommonOptions', > > 'data': { 'raw': 'RawOptions', > > 'qcow2': 'Qcow2Options' } } >=20 > Oh, yikes. I even outlawed this type of "simple union with base class" > later in the series, since no one was using it, and since it gets in the > way of my desire to move towards "simple union with type-safe enum > branching". I'll have to revisit that text and document an actual flat > union in v6. There is already an example for a real flat union. You just need to drop this one and probably change the text around it a bit. Kevin --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVGtY1AAoJEH8JsnLIjy/WfUEP/0EoGluykqFFeFMKQNuPhJ0k hPnW657bSii9FJqT0uv6sx4pvzUNGtqEG+6mI5uBgdYhfc7fNwzCu8VkTSLXQTNe NTliAY5KYy5Y20XFe3k5moQywXNNU35yVpm+xJbHSw0jW81IAaMBLor78+948lAh bv5nxiSXKsilzIm0DZU167DV+Uv6FC4oblXUetxe8tyBgpygupuIa2Y5v0e028ec Ks4L1SEXJZIIps18NSZna93IDNs8w2bLD97fqMK1ZZLe1EcuIukWR14rKX4K9D7o BWGJFsGCaG3YJERc4fKTU5odKzMvICYWD9jZVuXjqrNgaBREFbE9I9shjw74Nbu9 wGceqk/dclaGGd3IGsCM6QctFI72BeIOATa+lSaaTNLpKzgGJAyC9QYBorz/1Rfn 0+LBadR2KyNJMCdoIzRz662Gf9jK86PSthmunV3cX0EoSmGOhHzeiGDO2zdbytor DqXRmfO9zrVPdc9ep9/0Jyy6W0xFr7T3fFf0q2pRSGKb3tEOidVIKQ+jEo0LXxWI ZTodlttY8U43N+mnD1ImhtlKrOFoNr5oeE70TC3bbjqv3P9Tuf44ld0YTmheLkbQ WkTupZB9rygn2yfCF0UiEHglVcnC7pYIQHfsdNmoqFMfJi6+Wu1cE2RW3KHqmNI9 yZVpgzO9YcnyhCAmBOPN =AeKL -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU--