[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for o

From: Eric Blake
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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

> 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: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]