Re: [PATCH v2 01/53] qapi: add QAPITypeInfo struct definition

[Markus Armbruster <armbru@redhat.com>]

Marc-André Lureau <marcandre.lureau@redhat.com> 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 <marcandre.lureau@redhat.com>
> ---
>  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?

> + * @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.

> + */
> +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.


[*] The QAPI generator has an option to make it have only the unmasked
names.  Occasionally convenient when messing around.