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.
qobject is fundamental to all the QAPI related generated code. Why should that remain tight to QEMU proper?