qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qapi-visit: Honor prefix of discriminator enum


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] qapi-visit: Honor prefix of discriminator enum
Date: Mon, 7 Mar 2016 16:23:42 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 02/17/2016 05:05 AM, Markus Armbruster wrote:
> Let's check for completeness.  Calls of c_enum_const():
> 
> * QAPISchemaEnumType.c_null() and (with your patch) gen_visit_union()
>   call it like
> 
>     c_enum_const(TYPE.name, MEMBER, TYPE.prefix)
> 
>   where MEMBER is a member of enumeration type TYPE.
> 
>   As your patch shows, the prefix is easy to forget.  A safer function
>   would take just TYPE and MEMBER:
> 
>     TYPE.c_member(MEMBER)
> 

I took a look at this email again today, and while it still sounds like
a nice action, I wasn't able to get it done quickly (certainly not 2.6
material, at any rate).

> * gen_event_send() calls
> 
>     c_enum_const(event_enum_name, name)
> 
>   where name is member of the enum type named event_enum_name.  That's
>   okay because the type is auto-generated without a prefix.  Regardless,
>   we could do something like
> 
>     schema.lookup_type(event_enum_name).c_member(name)
> 
>   Requires actually constructing the type, which is probably a good idea
>   anyway, because it gets us the necessary collision checks.  Replacing
>   global event_enum_name by event_enum_type would be nice then.  Out of
>   scope for this patch.
> 
> * gen_enum_lookup() and gen_enum() work on name, values, prefix instead
>   of the type.  I figure they do to support qapi-event.py.  If we clean
>   it up to create the type, these functions could use the type as well,
>   and then c_enum_const() could be dropped.

Well, they also do it to support qapi-types.py, where the
visit_enum_type() visitor callback has already broken things out into
name/values/prefix instead of providing a type, and where we don't have
easy access to the schema to do schema.lookup_type(name).

As I've worked more with the visitors, I'm really wondering if
visit_enum_type(self, type, info) would be a saner callback interface
than visit_enum_type(self, type.name, info, type.values, type.prefix)

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