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.
>
> The fields are populated in following commits.
>
> Signed-off-by: Markus Armbruster <[email protected]>
> Signed-off-by: Marc-André Lureau <[email protected]>
> ---
>  include/qapi/qapi-type-info.h | 31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/include/qapi/qapi-type-info.h b/include/qapi/qapi-type-info.h
> new file mode 100644
> index 000000000000..6a6355568325
> --- /dev/null
> +++ b/include/qapi/qapi-type-info.h
> @@ -0,0 +1,31 @@
> +/*
> + * 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.
> + * @masked_name: Name of the type in the QAPI introspection schema, assigned 
> by
> + *        scripts/qapi code generator (e.g. "368").

I figure "in the output of query-qmp-schema" would be clearer.

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

"It" is ambiguous and easily misunderstod.

Correct interpretation: the QEnumLookup.

Incorrect interpretation: QAPITypeInfo member @lookup.

QAPITypeInfo member @lookup is actually used by QOM property stuff in
object.c.  Or rather will be: PATCH 15+17.

Do we need the second sentence?

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

This alludes to

    static const QAPITypeInfo *qdev_prop_qapi_type(const Property *prop)
    {
        if (prop->info->qapi_type) {
            return prop->info->qapi_type;
        }
        if (prop->info->element_info) {
            assert(prop->info->element_info->qapi_type);
            assert(prop->info->element_info->qapi_type->list);
            return prop->info->element_info->qapi_type->list;
        }
        return NULL;
    }

These array properties don't have prop->info->qapi_type set, and instead
retrieve it from their element type [PATCH 59].

Maybe something like "qdev array properties lack a QAPITypeInfo, and
instead use their element QAPITypeInfo's @list to find it."

Except all that isn't true at this point in the series.  Consider adding
it only when it is true.

Ignorant question: could we set their prop->info->qapi_type at creation
time?  No need for qdev_prop_qapi_type() then.  Hmm, I guess not, the
obvious patch (appended) fails with "initializer element is not
constant".

> + */
> +typedef struct QAPITypeInfo {
> +    const char *name;
> +    const char *masked_name;
> +    const QEnumLookup *lookup;
> +    const struct QAPITypeInfo *list;
> +} QAPITypeInfo;
> +
> +#endif /* QAPI_TYPE_INFO_H */


diff --git a/hw/core/qdev-prop-internal.h b/hw/core/qdev-prop-internal.h
index 40fa4bc63f..18d982a212 100644
--- a/hw/core/qdev-prop-internal.h
+++ b/hw/core/qdev-prop-internal.h
@@ -40,6 +40,7 @@ void default_prop_array(ObjectProperty *op, const Property 
*prop);
  */
 #define DEFINE_PROP_ARRAY_INFO(_elem_prop_info, _elem_type) \
     {                                                       \
+        .qapi_type = _elem_prop_info.qapi_type->list,       \
         .element_info = &(_elem_prop_info),                 \
         .element_size = sizeof(_elem_type),                 \
         .get = get_prop_array,                              \


Reply via email to