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
> > @@ -0,0 +1,32 @@
> > +/*
> > + * SPDX-License-Identifier: GPL-2.0-or-later
> > + */
> > +
> > +#ifndef QAPI_TYPE_INFO_H
> > +#define QAPI_TYPE_INFO_H
> > +
> > +#include "qapi/util.h"
> > +
> > +/**
> > + * QAPITypeInfo - QAPI type metadata
> > + *
> > + * @name: QAPI type name (e.g. "str", "OnOffAuto", "int32List").
> > + * QOM uses this as the property type string.
> > + * @schema_name: Name of the type in the QAPI introspection schema,
> > assigned by
> > + * scripts/qapi/introspect.py (e.g. "368"). NULL for builtin types
> > not
> > + * individually present in the schema.
>
> "Schema" is ambiguous here: there's the QAPI schema
> (e.g. qapi/qapi-schema.json and its sub-modules), and the SchemaInfo
> returned by query-qmp-schema. Could well lead to confusion.
>
> What about @masked_name?
works for me
>
> > + * @lookup: QEnumLookup for this type, or NULL for non-enum types.
> > + * visit_type_enum(), qapi_enum_parse(), and qapi_enum_lookup()
> > + * all rely on it.
>
> Not yet. Either mention that in the commit message, or add the member
> later, when the comment is correct.
>
> > + * @list: The list-type counterpart, or NULL if none exists.
> > + * str_type_info.list points to strList_type_info. qdev array
> > + * properties follow this to find the list type for their element.
>
> Likewise.
ok
>
> > + */
> > +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.
