[Top][All Lists]

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

Re: [Qemu-devel] [RFC PATCH 13/36] block: introduce block job error

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 13/36] block: introduce block job error
Date: Wed, 11 Jul 2012 18:10:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

Il 15/06/2012 19:50, Eric Blake ha scritto:
>> >  { 'type': 'BlockJobInfo',
>> >    'data': {'type': 'str', 'device': 'str', 'len': 'int',
>> > -           'offset': 'int', 'paused': 'bool', 'speed': 'int'} }
>> > +           'offset': 'int', 'paused': 'bool', 'speed': 'int',
>> > +           'io-status': 'BlockDeviceIoStatus'} }
> Again, when adding members to output-only types compared to a previous
> release, should we be marking the additions as optional, as in:
> '*io-status': 'BlockDeviceIoStatus'
> to indicate that the member may not be present when talking to older qemu?

I don't think so, but still we should add it to the documentation.

If in the future we will generate code that exports the types, these
should not be indicated as optional IMHO.  Optional is more like a JSON
null value (in fact in Javascript a['nonexistent'] is null).  Instead,
we should add a new notation indicating that this could have a default
value (false in the case of 'paused', 'ok' here), and the generated code
would synthesize the default value if the JSON lacks the item.

This could be used also in some commands.  We mark some arguments as
optional, but it would be easier to present them as having a default
value.  In particular, in a C API likely you would prefer to map such
cases to one C arguments rather than a pair "has_foo"+"foo".


reply via email to

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