Re: [RFC PATCH] qapi: Generate QAPI files using qapi/ for generated header paths

[Philippe Mathieu-Daudé]

On 7/8/24 14:01, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Wed, Aug 07, 2024 at 01:21:25PM +0200, Markus Armbruster wrote:
> > > Daniel P. Berrangé <berrange@redhat.com> writes:
> > >
> > > > On Wed, Aug 07, 2024 at 12:50:26PM +0200, Markus Armbruster wrote:
> > > > > Daniel P. Berrangé <berrange@redhat.com> writes:
> > >
> > > [...]
> > >
> > > > > > It is confusing that we have both shared stuff and QMP schema
> > > > > > only stuff under the same location.
> > > > >
> > > > > Which stuff in which location?
> > > >
> > > > There are multiple directories with 'qapi' in their name
> > > >
> > > >   - $SRC/include/qapi - all generic stuff for any consumer of QAPI
> > > >   - $SRC/qapi - impl of generic stuff from $SRC/include/qapi, but
> > > >                 also the QMP schema for machine emulator
> > > >   - $BUILD/qapi - generated code for QMP schema for machine emulator
> > >
> > >     - scripts/qapi - the generator code
> > >
> > > > I find it confusing that we have both generic QAPI code and the main
> > > > machine emulator QMP schema in directories sharing the same 'qapi'
> > > > name.
> > >
> > > Got it.
> > >
> > > Lack of separation between generic C infrastructure and specific schema
> > > hasn't really annoyed me.  Possibly because the two are, for better or
> > > worse, joined at the hip.  Except for the use of "qapi:" in commit
> > > message titles; there I've at times felt a slight urge to distinguish
> > > between schema work, C infrastructure work, and generator work.
> > >
> > > Of course, other people's confusion trumps my non-annoyance.
> >
> > When we first introduced the QAPI/QMP schema for system emulator of
> > course it was fine, since we didn't have QGA usage.
>
> Actually, qga's QAPI schema (commit e3d4d25206a) predates the main QAPI
> schema (commit e3193601c84) by a few weeks.
>
> >                                                      Now days we have
> > a dedicate $SRCDIR/system directory for the system emulators, so I
> > wonder if its worth putting the system emulator schemas in there
> > instead ? Caveat is that the QSD also uses some of this schema.
>
> Another caveat is that much QAPI code, both infrastructure and
> generated, has bled into programs other than qemu-system-FOO.

qapi/qapi-types-foo.h is OK since we to share libcommon.a.

I'm not sure about qapi/qapi-visit-foo.h, maybe due to qtests?
There was also some code pulled by QOM properties, althougth not used.

> $ gdb -batch -ex "info sources" bld/qemu-i386 | tr ',' '\012' | sed -n 
> '/qapi/s,^.*/qemu/,,p'
> bld/qapi/qapi-types-machine-common.h
> bld/qapi/qapi-types-machine.h
> include/qapi/util.h
> bld/qapi/qapi-builtin-types.h
> bld/qapi/qapi-types-error.h
> bld/qapi/qapi-types-common.h
> bld/qapi/qapi-types-run-state.h
> include/qapi/error.h
> bld/qapi/qapi-visit-machine.h
> include/qapi/visitor.h
> bld/qapi/qapi-builtin-visit.h
> bld/qapi/qapi-types-replay.h
> include/qapi/qmp/qobject.h
> include/qapi/qmp/qlist.h
> include/qapi/qmp/qdict.h
> bld/qapi/qapi-events-qdev.h
> include/qapi/qmp/qbool.h
> include/qapi/qmp/qnum.h
> include/qapi/qmp/qstring.h
> include/qapi/forward-visitor.h
> include/qapi/string-output-visitor.h
> include/qapi/string-input-visitor.h
> include/qapi/qobject-input-visitor.h
> bld/qapi/qapi-types-authz.h
> bld/qapi/qapi-types-crypto.h
> bld/qapi/qapi-types-sockets.h
> bld/qapi/qapi-types-block-core.h
> bld/qapi/qapi-types-qom.h
> include/qapi/qmp/qjson.h
> bld/qapi/qapi-visit-qom.h
> include/qapi/qobject-output-visitor.h
> bld/qapi/qapi-builtin-visit.c
> bld/qapi/qapi-types-common.c
> bld/qapi/qapi-visit-common.h
> include/qapi/dealloc-visitor.h
> bld/qapi/qapi-visit-common.c
> bld/qapi/qapi-visit-machine.c
> bld/qapi/qapi-visit-machine-common.h
> bld/qapi/qapi-types-qom.c
> bld/qapi/qapi-visit-qom.c
> bld/qapi/qapi-visit-crypto.h
> bld/qapi/qapi-visit-block-core.h
> bld/qapi/qapi-visit-authz.h
> bld/qapi/qapi-visit-sockets.h
> bld/qapi/qapi-visit-sockets.c
> bld/qapi/qapi-events-qdev.c
> bld/qapi/qapi-emit-events.h
> bld/qapi/qapi-types-qdev.h
> bld/qapi/qapi-visit-qdev.h
> include/qapi/compat-policy.h
> include/qapi/qmp-event.h
> qapi/qapi-dealloc-visitor.c
> include/qapi/qmp/qnull.h
> include/qapi/visitor-impl.h
> bld/qapi/qapi-types-compat.h
> qapi/qapi-forward-visitor.c
> qapi/qapi-util.c
> qapi/qapi-visit-core.c
> bld/trace/trace-qapi.h
> qapi/trace-events
> bld/trace/trace-dtrace-qapi.h
> qapi/qobject-input-visitor.c
> qapi/qobject-output-visitor.c
> qapi/string-input-visitor.c
> qapi/string-output-visitor.c
> qapi/qmp-dispatch.c
> include/qapi/qmp/dispatch.h
> qapi/qmp-event.c
> qapi/qmp-registry.c
> include/qapi/qmp/json-parser.h
> include/qapi/qmp/json-writer.h
> bld/qapi/qapi-builtin-types.c
> bld/qapi/qapi-visit-authz.c
> bld/qapi/qapi-visit-block-core.c
> bld/qapi/qapi-types-job.h
> bld/qapi/qapi-visit-job.h
> bld/qapi/qapi-visit-crypto.c
> bld/qapi/qapi-types-error.c
> bld/qapi/qapi-visit-job.c
> bld/qapi/qapi-visit-machine-common.c
> bld/qapi/qapi-types-machine.c
> bld/qapi/qapi-types-sockets.c
> bld/qapi/qapi-visit-qdev.c
> bld/trace/trace-qapi.c
> bld/qapi/qapi-types-authz.c
> bld/qapi/qapi-types-block-core.c
> bld/qapi/qapi-types-crypto.c
> bld/qapi/qapi-types-job.c
> bld/qapi/qapi-types-machine-common.c

At least there are no qapi/qapi-commands-foo.[ch]!