From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbasZ-00067V-SD for qemu-devel@nongnu.org; Fri, 27 Mar 2015 16:29:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbasU-0004uj-MG for qemu-devel@nongnu.org; Fri, 27 Mar 2015 16:29:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbasU-0004uX-Eo for qemu-devel@nongnu.org; Fri, 27 Mar 2015 16:29:14 -0400 Message-ID: <5515BD96.8010202@redhat.com> Date: Fri, 27 Mar 2015 14:29:10 -0600 From: Eric Blake MIME-Version: 1.0 References: <1427227433-5030-1-git-send-email-eblake@redhat.com> <1427227433-5030-23-git-send-email-eblake@redhat.com> <87mw2ybefw.fsf@blackfin.pond.sub.org> In-Reply-To: <87mw2ybefw.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RTfVUGxJHSKSijbjOdtbeeoL75ml1iULj" Subject: Re: [Qemu-devel] [PATCH v5 22/28] qapi: Whitelist commands that don't return dictionary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, lcapitulino@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, wenchaoqemu@gmail.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RTfVUGxJHSKSijbjOdtbeeoL75ml1iULj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/27/2015 10:19 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> ...or an array of dictionaries. Although we have to cater to >> existing commands, returning a non-dictionary means the command >> is not extensible (no new name/value pairs can be added if more >> information must be returned in parallel). By making the >> whitelist explicit, any new command that falls foul of this >> practice will have to be self-documenting, which will encourage >> developers to either justify the action or rework the design to >> use a dictionary after all. >> >> Signed-off-by: Eric Blake >> --- >=20 > Thinking on introspection, I started to wonder whether there's actually= > a command returning a union, yet. So I applied the appended stupid > patch on top, and found the following commands returning (list of) > non-struct type: >=20 > * qapi-schema.json: >=20 > 'ringbuf-read' built-in type 'str' > 'human-monitor-command' built-in type 'str' > 'query-migrate-cache-size' built-in type 'int' > 'query-tpm-models' enum type 'TpmModel' More precisely, "array of enum type 'TpmModel'" (or "list", depending on whether we go with JSON array/object terminology, or QObject dict/list). I wonder if it is worth trying to tweak the error message to more precisely track when I strip away the [] earlier in check_type to still report sane messages about 'array of ...' if a later check fails. > 'query-tpm-types' enum type 'TpmType' > 'query-memory-devices' union type 'MemoryDeviceInfo' >=20 > * qga/qapi-schema.json: >=20 > 'guest-sync-delimited' built-in type 'int' > 'guest-sync' built-in type 'int' > 'guest-get-time' built-in type 'int' > 'guest-file-open' built-in type 'int' > 'guest-fsfreeze-status' enum type 'GuestFsfreezeStatus' > 'guest-fsfreeze-freeze' built-in type 'int' > 'guest-fsfreeze-freeze-list' built-in type 'int' > 'guest-fsfreeze-thaw' built-in type 'int' > 'guest-set-vcpus' built-in type 'int' Good - your patch found all of my whitelists, plus... >=20 > The sole example for union is 'MemoryDeviceInfo'. It has one case %-} Yeah, MemoryDeviceInfo as a union currently has only one type, but it was done that way in case we add other memory devices. So it was actually quite forward-thinking. =2E..one additional thing. But returning (an array of) a union should be= okay (it is a dictionary, and therefore extensible); this patch was only about flagging non-dictionaries. [side note: again, my idea of renaming 'type' into 'struct' in the .json files would make it easier to talk about "complex types" as the set of "struct" and "union" types, rather than the current confusion of deciding if "type" means all meta-types or just struct meta-types.] --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --RTfVUGxJHSKSijbjOdtbeeoL75ml1iULj 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/ iQEcBAEBCAAGBQJVFb2WAAoJEKeha0olJ0NqcREH/2fwrlpBMnKkhtw2xweurLG3 YiGMGqDJS50d2BADQ5WEOrW+0HiUq5YTPKI9ZlSNSkidkz/BkapsQz3/Dit7X6tk YEYtgwylcpRJY3IBVfy8/mkuPBuxhbXmL7vnHKwDdQXps1Z86KXYSJcIqFXQz9Zm IBRtgj0QFI4Q9wttwt5QU3TYIyozZB8JLCZr9XoORPiOaEZXY8sJMyk+KXKUaZMK GmDChOpz4jhIl4UmQumIj3xbJe+SYKhzkINujzcDPweOnUm888TCPGDLJWOXaOBV E9d26pBuzjJ6yvgvlaHyGkGfMOhxbO04HXcFVdMqSvHosoEmlX9eJxSQb82xnlA= =FHSk -----END PGP SIGNATURE----- --RTfVUGxJHSKSijbjOdtbeeoL75ml1iULj--