From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhVkw-0005qx-Ml for qemu-devel@nongnu.org; Mon, 05 May 2014 23:09:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhVks-000538-0v for qemu-devel@nongnu.org; Mon, 05 May 2014 23:09:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhVkr-000533-Om for qemu-devel@nongnu.org; Mon, 05 May 2014 23:09:17 -0400 Message-ID: <53685259.2030109@redhat.com> Date: Mon, 05 May 2014 21:09:13 -0600 From: Eric Blake MIME-Version: 1.0 References: <1398764656-27534-1-git-send-email-famz@redhat.com> <1398764656-27534-3-git-send-email-famz@redhat.com> <8761lktrg3.fsf@blackfin.pond.sub.org> <20140506013011.GA1574@T430.nay.redhat.com> In-Reply-To: <20140506013011.GA1574@T430.nay.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ArOHoSsANn1BO3N9cfwRllQJitt4jLr11" Subject: Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Markus Armbruster Cc: Kevin Wolf , Peter Maydell , Michael Roth , qemu-devel@nongnu.org, Luiz Capitulino , akong@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ArOHoSsANn1BO3N9cfwRllQJitt4jLr11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2014 07:30 PM, Fam Zheng wrote: >> NAME: { 'type': TYPE, 'default': DEFAULT } >> >> where >> >> NAME: { 'type': TYPE } >> >> can be abbreviated to >> >> NAME: TYPE >=20 > In data definition, we allow inline sub-structure: >=20 > { 'type': 'VersionInfo', > 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'}, > 'package': 'str'} } >=20 > If we allow properties as a dict, we need to disambiguate properly from= the > above case. Proposing: >=20 > MAGIC: { 'name': NAME, 'type: TYPE, 'default': DEFAULT } Oh, good catch. The alternative is to drop all instances of inline sub-structs. Searching for 'data.*{.*{', I found only VersionInfo and PciBridgeInfo; I then did a full manual search of qapi-schema.json and only found the additional instance of PciDeviceInfo where the sub-struct is not on the same line as the initial { of the 'data'. Just getting rid of inlined sub-structs may be quite feasible. On a related vein, there are a number of types that aren't merely a string name. For example: { 'command': 'migrate-set-capabilities', 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } and similar, where we have an array type rather than a raw string type name. But at least with that, NAME: { 'type': [ 'array' ] } is still a reasonable parse. The problem with MAGIC:{'name'...} is that you need to express more than one parameter, but as a dict, you can't reuse the same MAGIC more than once. That is: 'data': { MAGIC : { 'name': 'qemu', 'type': { 'major'...} }, MAGIC : { 'name': 'package', 'type', 'str' } } } proves that you have to have two distinct MAGIC in the same 'data', so '' for both is out. >=20 > Where MAGIC should NOT be something that is a valid NAME from current s= chema. > Some ideas: >=20 > - Special string, that has invalid chars as a identifier, like '*', '%= ', '&', > etc, or simply an empty str ''. > Of course we need to enforce the checking and distinguishing in > scripts/qapi-types.py. >=20 > - Non-string: current NAME must be a string, any type non-string could= be > distinguished from NAME, like number, bool, null, []. But its meanin= g could > be confusing to reviewer. >=20 > - Special symbol: we can define a dedicate symbol for this, like the l= iteral > TYPE, in the schema. But this way we deviate more from JSON. Also, while we aren't strict JSON, it's nice that we're still fairly close to JSON5, and worth keeping that property. >=20 > Personally, I think empty str '' makes more sense for me. What do you t= hink? >=20 At this point, I'm leaning towards dropping support for unnamed inlined sub-structs. > Anyway we only add things, so we will keep the '*name' suger. >=20 > Thanks, > Fam >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ArOHoSsANn1BO3N9cfwRllQJitt4jLr11 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/ iQEcBAEBCAAGBQJTaFJZAAoJEKeha0olJ0NqvvkH/RF09UXwX68dK4G05fR4R+Og tWWdGo1uvAcg507MGGWTBwLc8HGkQ9UauFdKCygsAc9uiTFdM1/z1Ntp5CNVSE9c fM8mNmQFx1bWN06vyaCHoIfLRGf0dIvd1Sl28Zdm91gPjzBNVi+125oY+1uD1Ue9 toZoL3Cz8do3kzCaNQ2m6dGOmo219dAYEOf+QEI8JE6pRLxqRww4sjdC6xt26DNq rqWeRHNp4qSxLS6NCdW9rUNTX3+R9Sb0E2tL1aXR0P0qKfP8uUMdZ0Zm/TjQJiIg DzRNdFo4r41qvrIreTwXyBhj7X/SgZE3rf/Uo7Ysg25kHNsLUKMc+XfgfFZTSRk= =5EpJ -----END PGP SIGNATURE----- --ArOHoSsANn1BO3N9cfwRllQJitt4jLr11--