Marc-André Lureau <[email protected]> writes:
> giHi
>
> On Fri, Jul 31, 2026 at 3:43 PM Markus Armbruster <[email protected]> wrote:
>>
>> Marc-André Lureau <[email protected]> writes:
>>
>> > Introduce a minimal struct that pairs a QAPI type's internal name with
>> > its "masked" introspection name. Generated constants of this type will
>> > let QOM property registration carry a reliable reference to the QAPI
>> > schema and possibly other associated data.
>> >
>> > Signed-off-by: Marc-André Lureau <[email protected]>
>> > ---
>> > include/qapi/qapi-type-info.h | 32 ++++++++++++++++++++++++++++++++
>> > 1 file changed, 32 insertions(+)
>> >
>> > diff --git a/include/qapi/qapi-type-info.h b/include/qapi/qapi-type-info.h
>> > new file mode 100644
>> > index 00000000000..a7a470af731
>> > --- /dev/null
>> > +++ b/include/qapi/qapi-type-info.h
[...]
>> > + */
>> > +typedef struct QAPITypeInfo {
>> > + const char *name;
>> > + const char *schema_name;
>> > + const QEnumLookup *lookup;
>> > + const struct QAPITypeInfo *list;
>> > +} QAPITypeInfo;
>> > +
>> > +#endif /* QAPI_TYPE_INFO_H */
>>
>> This is somewhat related to SchemaInfo, which is also meta-data about
>> QAPI types (and also commands and events).
>>
>> SchemaInfo only has the masked name[*]. It has a reference from array
>> type to element type instead of the other way round. Everything else in
>> QAPITypeInfo is also in SchemaInfo, I believe.
>>
>> So far, QEMU uses SchemaInfo only around qmp_query_qmp_schema().
>> qmp_query_qmp_schema() a SchemaInfoList on the fly from something else,
>> and the QMP core (it's only caller) then converts it via QObject to a
>> string reply.
>>
>> Now I need to digress into history a bit.
>>
>> The value of query-qmp-schema is fixed at compile time. My initial
>> version simply generated the fixed reply as string. Efficient, because
>> it doesn't build a (bulky!) QObject reply. Also a bit hacky.
>>
>> This got in the way of QAPI 'if' conditionals, so commit 7d0f982b
>> switched to a pointer-less variation of the QObject that can be
>> generated as data more easily: QLitObject[]. query-qmp-schema converts
>> this to QObject every time it runs. The QLitObject[] would be awkward
>> to use for anything else.
>>
>> End of digression.
>>
>> I wonder whether it could make sense to have a single repository of QAPI
>> type meta data, usable both for query-qmp-schema and for your QOM work.
>> Something QOM could use about as easily as QAPITypeInfo, and
>> query-qmp-schema could convert to its reply.
>>
>> At this time, this is an idea phrased as a question. Is it a good idea?
>> I'm not sure. Even if it is, I'm not sure it should be implemented
>> right away. I'm just sharing the idea.
>
> I am not sure what you mean by "a single repository of QAPI type
> metadata". Whatever it is, I don't think it is required for this
> series. If you mean that we could generate one big structure holding
> all QAPI metadata, that sounds challenging and it's not clear to me
> what the benefit would be, beside a bit of memory saving.
The information in QAPITypeInfo is a strict subset of the information
returned by query-qmp-schema. This makes QAPITypeInfo redundant from a
pure information point of view.
However, the information returned by query-qmp-schema is encoded in a
way that makes it unwieldy for anything else: it's a big QLitObject.
All you can do with it is convert it to a big QObject. And all we do
with that is convert to a big JSON string we send to the QMP client. We
could extract a QAPITypeInfo from the big QObject on the fly, but it
would be rather cumbersome.
The QLitObject data structure is an implementation choice. We changed
our choice in the past, we could change it again. The question / idea I
wanted to share: could we choose a single data structure that supports
both QAPI/QMP introspection (query-qmp-schema) and QAPI/QOM
introspection (what your series adds)?
I don't think it would be all that difficult, just a good chunk of work.
A bit of a yak-shave perhaps.
Again, I'm just throwing out an idea. If you'd like to run with it, go
ahead. If not, that's perfectly fine, too.
>> [*] The QAPI generator has an option to make it have only the unmasked
>> names. Occasionally convenient when messing around.
