[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [PATCH v2 11/15] qemu-common: move scripts/qapi
Date: Thu, 11 Aug 2022 15:35:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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:


>> > 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.

Basically scripts/qapi/ less the code generators.

Not sure a subproject would be a good fit.

Shot from the hip: could the build process spit out something external
projects could consume?  It's how "consumables" are commonly delivered.
E.g. .so + a bunch of headers.  Sometimes that gets packaged.  Sometimes
it gets copied into the consuming tree ("vendored").

> 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.

Yes, that should be possible.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]