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

[Eric Blake]

On 07/29/2015 03:34 AM, Markus Armbruster wrote:

>>>> 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?
> 
> I was thinking of optionally unhidden type names, for when you messed up
> the output, and the stupid hidden type names make it hard to see what
> exactly's wrong.  I.e. the option is merely a development aid.

Ah, an option to qapi-introspect.py that says to generate the file
differently, but which is not normally enabled and therefore not exposed
to the QMP end user.  That, or unconditional strategic comments, both do
the trick for me.

> 
>>> 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.
> 
> I'm reluctant to complicate the contract with such a promise, though.

Concur. If we aren't going to guarantee sorting, then we also should not
guarantee that all commands come before any types, but that the overall
output is just an entire lookup dictionary where any entry can hold any
metatype.

> 
> I guess I'd simply slurp in the JSON, then do a quick pass over the
> resulting data structure to build an index.

Yep, that's probably what I'll have to code into libvirt.

> 
> That's the easy order.  Other orders are possible, but they're extra
> work.  Best to keep things simple.

Simplest for qemu is no order at all (and the client has to take on the
burden of sorting things as desired).  Not always the smartest (if every
client wants to sort, we've pushed a lot of duplicated work onto each
client instead of doing the work ourselves), but we have right up until
2.5 is released to commit to our decision of whether to sort in qemu or not.

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

signature.asc
Description: OpenPGP digital signature