From: Eric Blake <eblake@redhat.com>
To: Fam Zheng <famz@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
akong@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters
Date: Mon, 05 May 2014 21:09:13 -0600 [thread overview]
Message-ID: <53685259.2030109@redhat.com> (raw)
In-Reply-To: <20140506013011.GA1574@T430.nay.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
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
>
> In data definition, we allow inline sub-structure:
>
> { 'type': 'VersionInfo',
> 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
> 'package': 'str'} }
>
> If we allow properties as a dict, we need to disambiguate properly from the
> above case. Proposing:
>
> 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.
>
> Where MAGIC should NOT be something that is a valid NAME from current schema.
> Some ideas:
>
> - 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.
>
> - Non-string: current NAME must be a string, any type non-string could be
> distinguished from NAME, like number, bool, null, []. But its meaning could
> be confusing to reviewer.
>
> - Special symbol: we can define a dedicate symbol for this, like the literal
> 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.
>
> Personally, I think empty str '' makes more sense for me. What do you think?
>
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.
>
> Thanks,
> Fam
>
>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-05-06 3:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1398764656-27534-1-git-send-email-famz@redhat.com>
[not found] ` <1398764656-27534-2-git-send-email-famz@redhat.com>
[not found] ` <535F9E40.8010407@redhat.com>
2014-05-05 8:33 ` [Qemu-devel] [PATCH v2 1/2] qapi: Allow decimal values Markus Armbruster
[not found] ` <1398764656-27534-3-git-send-email-famz@redhat.com>
[not found] ` <20140429112436.GE4835@noname.str.redhat.com>
[not found] ` <535FA06F.2060603@redhat.com>
2014-05-04 3:14 ` [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters Fam Zheng
2014-05-05 9:51 ` Markus Armbruster
2014-05-05 15:13 ` Eric Blake
2014-05-05 11:06 ` Markus Armbruster
2014-05-05 15:18 ` Eric Blake
2014-05-05 17:34 ` Markus Armbruster
2014-05-05 23:03 ` Eric Blake
2014-05-06 9:55 ` Markus Armbruster
2014-05-06 12:35 ` Eric Blake
2014-05-06 15:09 ` Markus Armbruster
2014-05-06 1:30 ` Fam Zheng
2014-05-06 3:09 ` Eric Blake [this message]
2014-05-06 5:11 ` Fam Zheng
2014-05-06 11:57 ` Markus Armbruster
2014-05-06 11:53 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53685259.2030109@redhat.com \
--to=eblake@redhat.com \
--cc=akong@redhat.com \
--cc=armbru@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.