qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] full introspection support for QMP


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP
Date: Wed, 03 Jul 2013 16:45:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 03/07/2013 14:54, Anthony Liguori ha scritto:
>> So, qapi-schema.json has to be readable/writable _mostly_ by humans.
>> That it is valid JSON is little more than a curious accident, because
> 
> I can assure you that it wasn't an accident.

Sure, it is not.  But when designing the right API for a QMP client, it
doesn't matter if it is or not.  If QMP used ASN.1 or something like
that as the wire protocol, we would not use JSON just for the schema,
would we?

> The plan had been to start
> with what the output of a "human friendly" parser would be and then
> eventually introduce a more IDL like syntax.
> 
> qapi-schema.json is valid JSON.  It's a stream of objects.  It's a
> stream of objects instead of a list to favor readability but that's
> really the only compromise.

So far so good.

>> overall the syntax greatly favors humans rather than computers.  A
>> format designed for computers would have a schema such that no parsing
>> tasks (however small---I'm thinking of the "list of" and "optional"
>> syntaxes) would be left after parsing the JSON.
> 
> Here is how I would handle "processing" qapi-schema.json:
> 
> 1) Put all types, unions, and enums in their own dictionary
> 2) Put commands in a dictionary

Agreed.

> To answer:
> 
> A) Is 'type' valid?
>    - bool('type' in type_dict)
> 
> B) Does 'type' have optional parameter 'foo':
>    - bool('*foo' in type_dict['data'])

Does 'type' have argument 'foo':

   bool('foo' in type_dict['data']) or
     bool('*foo' in type_dict['data'])

(as a QMP client I want to send the argument, I don't care if it is
optional or not) and here the abstraction is already falling, IMHO.  It
should be one of these:

  'foo' in type_dict['data'].fields
  'foo' in type_dict['data']['fields']

> C) Does 'enum' have 'value'
>    - bool('value' in enum_dict['data'])
> 
> D) Does 'command' have 'parameter'
>    - bool('parameter' in command_dict['data'])

What is the type of 'parameter' in command:

    command_dict['data']['parameter'] or
       command_dict['data']['*parameter']

It should be something like these:

    command_dict['data'].arguments['parameter'].type
    command_dict['data']['arguments']['parameter']['type']

>> The example that Eric sent is not something that I would find easy to
>> read/write.  qapi-schema.json instead is more than acceptable.
> 
> I don't think the example Eric sent is any easier to parse
> programmatically.

It is, see the above examples.

> That's the problem I have here.  I don't see why we
> can't have both a human readable and machine readable syntax.

It is machine readable, but that doesn't mean it constitutes a nice API.

Paolo

> Furthermore, qapi.py is an existence proof that we do :-)
> 
> Regards,
> 
> Anthony Liguori
> 
>>
>> Paolo
> 




reply via email to

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