[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.