Re: [Qemu-devel] [PATCH v4 10/10] qapi: Populate info['name'] for each entity

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 03/08/2016 09:46 AM, Markus Armbruster wrote:
>> Eric Blake <address@hidden> writes:
>> 
>>> Every non-implicit entity is associated with an 'info'
>>> dictionary, but it is not easy to reverse-engineer the name of
>>> the top-most entity associated with that 'info'.  Our use of
>>> 'case_whitelist' (added in commit 893e1f2) is thus currently
>>> tied to the owner of a member instead; but as the previous patch
>>> showed with CpuInfo, this requires whitelist exceptions to know
>>> how an implicit name will be generated.
>> 
>> Why is that a problem?
>
> Not necessarily a bad problem, but a bit annoying. If a developer
> modifies a .json file and adds an improper name, then they will get an
> error message that tells them that they need to fix their naming
> conventions (hmm, the error message doesn't even point them to the
> whitelist - see args-member-case.err).

I'd consider that a feature :)  I don't want anyone adding to that white
list.

>                                         If the developer figures out
> that the whitelist will let them avoid the error, they still have to
> figure _what_ name to add to the whitelist, and without this patch, they
> have to determine the generated name for the implicit struct

Still feature...

>                                                              (which may
> not be constant, since we are discussing about alternative names earlier
> in the series other than something that flattens to a public 'struct
> _obj_...' in violation of file-local naming scope).

Whoever messes with the generated names gets to update the whitelist.

>                                                      The goal is thus to
> make the whitelist tied only to names mentioned in the .json file,
> rather than dragging generated implicit names into the mix.
>
> But it is cosmetic; we could live without the patch and stick to
> generated names in the whitelist, just as easily.

Let's drop this patch.

If we find a truly compelling use for info['name'] later, we can revisit
it if you like, because then it's almost free.

[...]