qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] qapi: Drop qapi-gen --unmask option


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 2/2] qapi: Drop qapi-gen --unmask option
Date: Tue, 03 Jul 2018 07:51:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 07/02/2018 01:48 PM, Markus Armbruster wrote:
>> Eric Blake <address@hidden> writes:
>>
>>> Now that we have useful access to the type name as a comment
>>> in the generated qapi-introspect.c, we don't need to regenerate
>>> code with a temporary -u option just to get at type names.
>>>
>>> Signed-off-by: Eric Blake <address@hidden>
>>
>> I occasionally feed output of query-qmp-schema to ad hoc Python scripts.
>> My last one searched for object types containing non-string members
>> (directly or indirectly).  -u remains useful there, and having to
>> recompile is not a problem.  I'd prefer to keep it.
>
> Would it be any easier to argue for the removal of -u if the generated
> output resembled:
>
> { "ret-type", QLIT_QSTR("1") /* Foo */ },
>
> that is, sticking in the comment everywhere the type name is mangled
> to an integer, rather than just once per type?

Doesn't help with my use case.  Let me elaborate on it.

My ad hoc Python script gets the output of query-qmp-schema like this:

    pipe = subprocess.Popen('socat %s STDIO' % qmp_socket,
                            shell=True,
                            stdin=subprocess.PIPE, stdout=subprocess.PIPE)
    (out, err) = pipe.communicate('{ "execute": "qmp_capabilities" }\n'
                                  '{ "execute": "query-qmp-schema" }\n')
    # three lines: greeting, output of qmp_capabilities, query-qmp-schema
    return json.loads(out.split('\n')[2])['return']

This returns an abstract syntax tree, represented in Python the obvious
way.  I can then explore it in Python, say search for object types with
certain properties.  For example, commit 2860b2b2cb8:

    Thus, the flaw puts an artificial restriction on the QAPI schema: we
    can't have potentially empty objects and arrays within
    BlockdevOptions, except when they're optional and "empty" has the same
    meaning as "absent".

--> Our QAPI schema satisfies this restriction (I checked), but it's a
    trap for the unwary, and a temptation to employ awkward workarounds
    for the wary.  Let's get rid of it.

I checked with a Python script that read the schema as shown above.
Without -u, I'd have to revert the identifier hiding.  I could certainly
write some more Python to read the mapping from the generated C, but
that feels like busy work.



reply via email to

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