Marc-André Lureau <[email protected]> writes:
> Hi
>
> On Fri, Sep 11, 2026 at 5:16 PM Markus Armbruster <[email protected]> wrote:
>>
>> I'm reviewing just the documentation right now. I'll look at the
>> remainder later.
>>
>> Documentation updates are commonly at least as hard as generator
>> changes, if not harder. Please don't be discouraged by my remarks!
>>
>> Marc-André Lureau <[email protected]> writes:
>>
>> > New QAPISchemaGenTypeInfoVisitor produces per-module
>> > qapi-type-infos-*.h/c files. Each file declares QAPITypeInfo constants
>> > pairing the QAPI type name with its masked introspection name.
>> >
>> > Signed-off-by: Marc-André Lureau <[email protected]>
>> > ---
>> > docs/devel/qapi-code-gen.rst | 107 +++++++++++++++++++++++++-
>> > meson.build | 1 +
>> > scripts/qapi/backend.py | 2 +
>> > scripts/qapi/introspect.py | 2 +-
>> > scripts/qapi/type_infos.py | 178
>> > +++++++++++++++++++++++++++++++++++++++++++
>> > 5 files changed, 285 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst
>> > index b1cc5b5f0db1..d176238fc2ef 100644
>> > --- a/docs/devel/qapi-code-gen.rst
>> > +++ b/docs/devel/qapi-code-gen.rst
[...]
>> The final sentence talks about types not reachable from commands or
>> events, and hints at QOM use. I feel the former is a distraction here.
>> Regarding the latter: we need to say more about QOM introspection than
>> "[types] may also be used by QOM". Before this series, query-qmp-schema
>> is the only QAPI introspection game in town, and this section explains
>> it. Afterwards, there's also qom-list, qom-list-properties,
>> qom-list-get. I fear doing them justice will require some rewriting.
>> Maybe just add a FIXME comment for now?
>
> added
[...]
>> > +
>> > +All user-defined and array types are included in introspection, even when
>> > +they are not reachable from a command or event. Their type info therefore
>> > +always provides the introspection cross-reference.
>>
>> I'm not sure I understand this paragraph. What are you trying to
>> convey?
>
> I expressed the motivation: type info allows cross-referencing with
> the introspection schema. But I can drop it too.
We can cover this when we document QOM introspection to resolve the
FIXME mentioned above.
>> > +
>> > +Example::
>> > +
>> > + $ cat qapi-generated/example-qapi-type-infos.h
>> > + [Uninteresting stuff omitted...]
>> > +
>> > + #ifndef EXAMPLE_QAPI_TYPE_INFOS_H
>> > + #define EXAMPLE_QAPI_TYPE_INFOS_H
>> > +
>> > + #include "qapi/qapi-builtin-type-infos.h"
>> > +
>> > + extern const QAPITypeInfo UserDefOne_type_info;
>> > +
>> > + extern const QAPITypeInfo UserDefOneList_type_info;
>> > +
>> > + #endif /* EXAMPLE_QAPI_TYPE_INFOS_H */
>> > + $ cat qapi-generated/example-qapi-type-infos.c
>> > + [Uninteresting stuff omitted...]
>> > +
>> > + const QAPITypeInfo UserDefOne_type_info = {
>> > + .name = "UserDefOne",
>> > + .masked_name = "1",
>> > + .list = &UserDefOneList_type_info,
>> > + };
>> > +
>> > + const QAPITypeInfo UserDefOneList_type_info = {
>> > + .name = "UserDefOneList",
>> > + .masked_name = "[1]",
>> > + };
>> > +
>> > + [Uninteresting stuff omitted...]
>>
>> For me, it actually generates masked names "0" and "[0]". Is the
>> mapping to masked names stable?
>
> it is not, as you know by design, it depends on registration order
Sorry, I phrased my question poorly. Does it depend just on
registration order? If yes, the mapping changes only when the schema
changes, which is desirable for diffing generator output.
[...]
