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

[Eric Blake]

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

> 
>> While we have a ._pretty_owner() that maps from implicit names
>> back to a human readable phrase, that produces more than just a
>> plain top-level entity name.  What's more, the current use of
>> ._pretty_owner() is via .check_clash(), which can be called on
>> the same member object more than once (once through the
>> standalone type, and a second time when used as a base class of
>> a derived tpye); if a clash is only introduced in the derived
>> class, using ._pretty_owner() to report the error on behalf of
>> the base class named in member.owner seems wrong.  Therefore,
>> we need a new mechanism.
> 
> Now I'm confused.  Are you fixing suboptimal error messages?

No, I was trying to document why ._pretty_owner() (which is our only
pre-exisiting map from Python objects back to pretty type names) is
insufficient for the task at hand (namely, what is the pretty name of
the type to add to the whitelist, if we don't want generated implicit
names in the whitelist).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature