Re: [Qemu-devel] [PATCH RFC v2 14/47] qapi-tests: New tests for union, alternate command arguments

[Eric Blake]

On 07/21/2015 06:43 AM, Eric Blake wrote:
> On 07/01/2015 02:22 PM, Markus Armbruster wrote:
>> A command's 'data' must be a struct type, given either as a
>> dictionary, or as struct type name.
>>
>> Existing test case data-int.json covers simple type 'int'.  Add test
>> cases for type names referring to union and alternate types.
> 
> We could probably relax things to allow a union (which is always a
> dictionary on the wire), but I agree that allowing an alternate type is
> not appropriate (the goal here is that we require a dictionary).  But
> it's also easier to be conservative now and relax later.
> 

>> +++ b/tests/qapi-schema/args-alternate.json
>> @@ -0,0 +1,4 @@
>> +# we do not allow alternate arguments
>> +# TODO should we support this?
> 
> I see no reason to allow a non-dictionary in QMP, so this TODO could be
> dropped.

Or, to be clear, we document that arguments is always a dictionary, for:
{ "execute":"command", "arguments":{} }. Allowing an alternate would
break that, so it is a different level of change to allow an alternate
(change the QMP protocol) than what it would be to allow a union (the
QMP protocol is unchanged).  Not that we can't do it if we ever have a
reason, it's just that I don't see it being worth a TODO statement.

> 
>> +++ b/tests/qapi-schema/args-union.json
>> @@ -0,0 +1,4 @@
>> +# FIXME we should reject union arguments
>> +# TODO should we support this?
>> +{ 'union': 'Uni', 'data': { 'case1': 'int', 'case2': 'str' } }
>> +{ 'command': 'oops', 'data': 'Uni' }
> 
> This, on the other hand, seems valid from the wire format (it will
> always be a dictionary).  I guess the problem is that we generate a C
> function signature based by calling out each member of the dictionary -
> but how do you do that for a union?  So I see what you are doing:
> marking that this test currently passes the parser, but then causes
> problems for generating C code, so we should either reject it up front,
> or fix the generator.  The FIXME documents what you will do later in the
> series (reject it up front) and the TODO documents what we can do down
> the road (fix the generator to allow it).

See also 32/47 - events have the same problem.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature