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.mayd...@linaro.org> > wrote: > > > On Thu, 11 Aug 2022 at 11:09, Marc-André Lureau > > <marcandre.lur...@gmail.com> wrote: > > > On Thu, Aug 11, 2022 at 1:05 PM Markus Armbruster <arm...@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 :|