Re: [Qemu-devel] [PATCH RFC v2 47/47] qapi-introspect: Hide type names

[Eric Blake]

On 07/28/2015 12:24 PM, Markus Armbruster wrote:
> Eric Blake <address@hidden> writes:
> 
>> On 07/01/2015 02:22 PM, Markus Armbruster wrote:
>>> To eliminate the temptation for clients to look up types by name
>>> (which are not ABI), replace all type names by meaningless strings.
>>>
>>> Reduces output of query-schema by 9 out of 80KiB.
>>
>> I'm not sure whether I like this or not.  It does make sense from the
>> perspective of forcing clients to stick to ABI queries, but makes it a
>> bit harder to navigate things except by automated scripts.
> 
> Yes.  I'm not sure it's a good idea.  If we decide to hide types this
> way, then I'd find an option to generate without type hiding useful.

As in, an optional boolean flag to the QMP command that requests whether
to get compact output with hidden names vs. full output with qapi names
exposed (but then, are we storing TWO copies of the introspection
strings)?  Or merely as in the generated qmp-introspect.c file having
strategic comments so that reading _that_ file lets you see the type
names, even if they don't get passed on to the end user?


> What the patch adds:
> 
> Move the introspection information for the non-types out of the way
> before the loop, append the information on types afterwards.  The result
> is now in jsons rather than self.jsons (see the next patch hunk).

I did notice that; pre-patch interleaved commands and types all
according to a global namespace, while post-patch sank all types to the
bottom.  Interestingly enough, if libvirt is going to query what
features a command has, it will first find the command (in the first
half of the returned array), then resolve the types used by that command
until it learns if the member is present (whether new enum value or
added dictionary member) - so there is that slight optimization that if
we guarantee that types are always output last, then libvirt doesn't
have to start generating its own hash table lookup of types until the
first type is seen, after already learning everything it needed from the
earlier command listings.

> 
> Why it does that:
> 
> With the funny typenames, sorting everything by name results in a mess.
> Keeping non-types and types separate is less of a mess.

You do have a point there - as soon as we introduce name aliases, the
aliases are unlikely to sort in the same manner as the original types,
particularly if we generate the aliases based solely on what order we
detected that those particular types were in use.

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

signature.asc
Description: OpenPGP digital signature