From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJTrn-0002Cp-4b for qemu-devel@nongnu.org; Sat, 02 Jul 2016 18:58:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJTrk-0005dM-0X for qemu-devel@nongnu.org; Sat, 02 Jul 2016 18:58:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJTrj-0005cO-Nq for qemu-devel@nongnu.org; Sat, 02 Jul 2016 18:58:23 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D09BFC0624A5 for ; Sat, 2 Jul 2016 22:58:21 +0000 (UTC) References: <1463784024-17242-1-git-send-email-eblake@redhat.com> <1463784024-17242-14-git-send-email-eblake@redhat.com> <87h9ct2qwi.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: <5778470C.3000608@redhat.com> Date: Sat, 2 Jul 2016 16:58:20 -0600 MIME-Version: 1.0 In-Reply-To: <87h9ct2qwi.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uqwA3lrBUoxadIqUBumCcmQ20feARVJbL" Subject: Re: [Qemu-devel] [PATCH v7 13/15] net: Complete qapi-fication of netdev_add List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Jason Wang , "Daniel P. Berrange" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uqwA3lrBUoxadIqUBumCcmQ20feARVJbL From: Eric Blake To: Markus Armbruster Cc: qemu-devel@nongnu.org, Jason Wang , "Daniel P. Berrange" Message-ID: <5778470C.3000608@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 13/15] net: Complete qapi-fication of netdev_add References: <1463784024-17242-1-git-send-email-eblake@redhat.com> <1463784024-17242-14-git-send-email-eblake@redhat.com> <87h9ct2qwi.fsf@dusky.pond.sub.org> In-Reply-To: <87h9ct2qwi.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/16/2016 07:40 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> We finally have all the required pieces for doing a type-safe >> representation of netdev_add as a flat union, where the >> discriminator 'type' now selects which additional members may >> appear in the "arguments" JSON object sent over QMP, while >> making no changes to the set of previously-valid QMP commands >> that would work, and without breaking command line parsing. >=20 > Isn't it amazing that you pulled this off without a compatibility break= ? No command line compatibility break, but in testing, I _did_ notice a potential QMP break [it's hard to argue whether it is a break, given that it was previously undocumented - I don't know if any QMP clients were actually relying on loose behavior]: Pre-patch: {'execute':'netdev_add', 'arguments':{'id':'net1', 'type':'hubport', 'hubid':1}} {"return": {}} {'execute':'netdev_add', 'arguments':{'id':'net2', 'type':'hubport', 'hubid':"2"}} {"return": {}} Post-patch: {'execute':'netdev_add', 'arguments':{'id':'net1', 'type':'hubport', 'hubid':1}} {"return": {}} {'execute':'netdev_add', 'arguments':{'id':'net2', 'type':'hubport', 'hubid':"2"}} {"error": {"class": "GenericError", "desc": "Invalid parameter type for 'hubid', expected: integer"}} I'm half-tempted to claim that we should update the QMP spec to say that our parser is ALWAYS loose (anywhere a built-in scalar type is listed in introspection, whether bool or integer, the parser will always accept an equivalent string on input - but output will always be the named type), and then relax qmp-input-visitor accordingly. In fact, danpb has already proposed patches that allow "parse-string-as-int" as intentional behavior, although under the guise of a new visitor rather than tweaking qmp-input-visitor - so it just becomes a question of do we do it in limited situations, or always. "Be liberal in what you accept" comes to mind. And as a followon thought: if we DO update the QMP spec to state that we always accept a string in place of an integer, then we also have the luxury of stating that accepting a string "inf" for a QAPI 'number' is valid (even though strict JSON will not let us pass a bare-word inf) - and that hits back on my proposal of whether we want to accept bare-word inf on input as an extension, and whether outputting a string "inf" when we specified a QAPI type of 'number' would be acceptable (since we would be canonicalizing input "2" into output 2, going the other direction and canonicalizing input inf into output "inf" is a bit easier to justify). But given that it is soft freeze time, I guess we need to be conservative at what changes we want to support at this phase of development. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --uqwA3lrBUoxadIqUBumCcmQ20feARVJbL 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/ iQEcBAEBCAAGBQJXeEcMAAoJEKeha0olJ0NqAMwH/3ajhw4j0j0iI9yLP/exOK5B Qwr/JQqhvFBv+SiU95zUwESpASCwryP86lDQd+At6iJ+MQzTkCkgMGcij1HzVo8K 8GLzHnJ9bEiKB5dN2vyWAcuuQF6GaUK900D9CjpoOvVCKShd/7NYtVxQPZLqP8c4 nQk5YSzFCdYuqBb3jOILJhc22ahzL6o4LJWy0Ylw/a2/0OS5vS2V2SorYDQoELW4 pLjJap/Rg7aEmjWUtJzYruH7qg4wOx2L8C3+Yf6oJiP1lSJGyT3UwtV5gq+CNaYP s9ya0YIQyhEm7N2JEH2SxDG0jw+DXaoSFHF82126lsxEgR2dCUGbLzdW8oZp4v8= =qEjO -----END PGP SIGNATURE----- --uqwA3lrBUoxadIqUBumCcmQ20feARVJbL--