Marc-André Lureau <[email protected]> writes: > Hi > > On Wed, Sep 9, 2026 at 2:00 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. >> > >> > The fields are populated in following commits. >> > >> > 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 000000000000..97eb1d7bf490 >> > --- /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. >> > + * @masked_name: Name of the type in the QAPI introspection schema, >> > assigned by >> > + * scripts/qapi code generator (e.g. "368"). >> > + * NULL for implicit types. >> >> I believe the last sentence is inaccurate. I can't see any QAPITypeInfo >> for implicit types, nor can I see any where .masked_name is null. > > Only QType, but since it has no use we can drop it from generation for now.
Yes. QType is a weird special case. >> We discussed this in review of v2. You asked whether I think it should >> be mandatory, but I neglected to answer (my apologies), so you didn't >> change anything for now. Fair. >> >> If we really want to permit null, we need a more accurate comment. If >> we don't, we can simply drop the sentence. >> >> I guess the remaining motivation to permit null here comes from QOM >> introspection [PATCH 08]. There, you add optional member @qapi-type to >> ObjectPropertyInfo, documented to be absent if the type does not occur >> in the output of query-qmp-schema. >> >> @qapi-type is optional so we can QAPIfy QOM properties one by one. >> Three cases: >> >> 1. Not QAPIfied: the property's ObjectPropertyInfo has no QAPITypeInfo >> (member .qapi_type is null). @qapi-type is absent. >> >> 2. Fully QAPIfied: it has a QAPITypeInfo, and its .masked_name is >> non-null. @qapi-type is .masked_name. >> >> 3. Badly QAPIfied: it has a QAPITypeInfo, but it's useless: .masked_name >> is null. @qapi-type is absent. >> >> The code to compute @qapi-type is written the obvious way, and the >> obvious way just works for all three cases. Regardless, I don't think >> case 3 has a right to exist :) Why would we bother to tack a >> QAPITypeInfo to ObjectPropertyInfo when it's useless? > > ok, let's make masked_name mandatory > >> The only reason I can imagine is QAPIfication in two steps where the >> first one tacks on the QAPITypeInfo, and the second one adds its >> .masked_name. We go to case 2 via case 3. But why would we do step one >> without step 2? And if we do both, why not swap their order? >> >> Am I missing something? > > No, any other review in the series before I send a new revision? :) Just sent one. I'll work my way through this, but I can't predict how quickly. Do feel free to send new revisions. [...]
