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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] qapi-visit: Honor prefix of discriminator enum
Date: Tue, 08 Mar 2016 09:28:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> writes:

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

Maybe it is, but I'm not sure.  The existing visit_enum_type() forces
discipline: you can't just use whatever property of the type you like.
Discipline is good until you overdo it and it becomes a straightjacket.

Let's not worry about it now, but concentrate on keeping the existing,
lengthy QAPI queue moving.



reply via email to

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