Re: [PATCH v2 11/15] qemu-common: move scripts/qapi

[Daniel P . Berrangé]

On Thu, Aug 11, 2022 at 02:50:01PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Aug 11, 2022 at 2:22 PM Peter Maydell <peter.maydell@linaro.org>
> wrote:
> 
> > On Thu, 11 Aug 2022 at 11:09, Marc-André Lureau
> > <marcandre.lureau@gmail.com> wrote:
> > > On Thu, Aug 11, 2022 at 1:05 PM Markus Armbruster <armbru@redhat.com>
> > wrote:
> > >> Your moves tear closely related code apart.  This is going to be a drag
> > >> for developers in general and maintainers in particular.
> > >>
> > >> Ergonomics suffer when related code is in multiple places.  Having to
> > >> switch between directories and remember where is what will a constant
> > >> low-level pain.  Things that used to be simple & quick, like git-grep
> > >> qapi/*.c, become more involved.
> > >>
> > >
> > > It's inevitable when a project grows. QEMU is already a very large
> > project. Over the years, we have structured the project, by moving things
> > and splitting in subdirectories. Imho, this is actually helpful in many
> > ways, and we got used to it easily hopefully.
> >
> > I agree with this. But generally we've tried to do that by
> > having the subdirectory splitting and naming match the
> > structure of the codebase. The exception, which I strongly
> > dislike, is that contrib/ is a grabbag of random stuff.
> > subprojects/ is starting to feel like it is also turning
> > into "place where random stuff ends up"...
> >
> 
> Yes, most of contrib/* should probably be standalone projects. If only we
> had some kind of common library/subproject :)
> 
> subproject/* is a meson *cough* convention (imposed location for
> subprojects). If we don't want to depend on external released libraries,
> that's just the way it is.
> 
> 
> >
> > > Do you see fundamental reasons why qemu-ga or (qemu-img, qemu-nbd,
> > storage-daemon, virtiofsd, vhost-user-*, *helper, ivshmem* etc) need to be
> > tight to qemu code, release and management process? I am not saying it's
> > time to move them out of qemu project, but I believe it's helpful to have
> > code that is structured and can be compiled indepently.
> > >
> > > And by having "standalone" subprojects, we can more easily evolve in new
> > directions, without touching the rest of the projects.
> >
> > As Markus says, your branch ends up moving most of qobject into
> > qemu-common/. We are never going to let that out of QEMU proper,
> > because we are never going to allow ourselves to be tied to API
> > compatibility with it as an external library. So anything that
> >
> 
> Why is that? We do it with a lot of dependencies already, with stable APIs.
> 
> Furthermore, we don't "have to" be tied to a specific ABI/API, we can
> continue to link statically and compile against a specific version. like
> with libvfio-user today.
> 
> And at this point, I am _not_ proposing to have an extra "qemu-common"
> repository. I don't think there are enough reasons to want that either.
> 
> 
> 
> > needs qobject is never going to leave the QEMU codebase. Which
> >
> means that there's not much gain from shoving it into subproject/
> > IMHO.
> 
> 
> (just to be extra clear, it's qobject not QOM we are talking about)
> 
> qobject is fundamental to all the QAPI related generated code. Why should
> that remain tight to QEMU proper?

Neither qobject nor QOM have ever been designed to be public APIs.
Though admittedly qobject is quite a bit simpler as an API, I'm
not convinced its current design is something we want to consider
public. As an example, just last month Markus proposed changing
QDict's implementation

https://lists.gnu.org/archive/html/qemu-devel/2022-07/msg00758.html


If we want external projects to be able to take advantage of QAPI,
the bare minimum we need to be public is a QAPI parser, from which
people can then build any code generators desired.

We don't neccessarily need the current QAPI C code generator. There
could be a new C generator that didn't use qobject, but instead used
some standard GLib types like GHashTable/GList instead of QDict/QList.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|