qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 19/19] qapi: New QMP command query-schema fo


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH RFC 19/19] qapi: New QMP command query-schema for QMP schema introspection
Date: Fri, 01 May 2015 15:41:28 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 04/02/2015 11:29 AM, Markus Armbruster wrote:

> 
> * Implicit type definitions are made explicit, and given
>   auto-generated names.  These names start with ':' so they don't
>   clash with the user's names.
> 
>   Example: a simple union implicitly defines an enumeration type for
>   its discriminator.

Given that I just tripped over a bug in my series where I failed to
consider that '*name' and 'name' should be considered the same, I'm
wondering if we should first update the parse engine to flatten
shorthand into a canonical form (that is, get to a point where we have a
list of all names and their C counterparts), rather than having to tweak
lots of places in the backends to repeatedly make the same translations
over and over again (stripping off leading '*', converting qapi
'default' into C 'q_default', converting qapi 'a-b' into C 'a_b', etc.).

I bet some of the backend generator gets simpler if the front end reuses
your work to get into a canonical form on initial parse.


> +++ b/scripts/qapi-introspect.py
> @@ -0,0 +1,430 @@

> +
> +def make_implicit_enum_type(name, role, values):
> +    name = ':enum-%s-%s' % (name, role)

Evidence of my python newbie-ness:

Here, you are using string formatting (as in 'pattern' % arguments), in
other patches, I've seen you use concatenation (would look like ':enum-'
+ name + '-' + role).  Is there any rhyme or reason why one form should
be considered over the other?

-- 
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]