From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 82003C28D13 for ; Mon, 22 Aug 2022 08:19:48 +0000 (UTC) Received: from localhost ([::1]:50592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQ2ew-0004C6-WA for qemu-devel@archiver.kernel.org; Mon, 22 Aug 2022 04:19:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQ2bc-0003Ij-HI; Mon, 22 Aug 2022 04:16:20 -0400 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:42663) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQ2ba-0007gL-5q; Mon, 22 Aug 2022 04:16:20 -0400 Received: by mail-lj1-x22e.google.com with SMTP id v10so9846523ljh.9; Mon, 22 Aug 2022 01:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=yYEGOsWoC9g9xfXQfkz9vofz7qOYVD3SIdNgqPXd3xc=; b=CcbM2zpmGvqauT7EZQmB6okyhvyd2bFGpfCWwikf15kwkOt43TfNzw/pCJjFRntriH yCM+2RcODlYiucRKYpJ2YuuNtWFcsS/z+sq57YU4pgSnNJF8dKPhgXEolQkZ3riqSQxn Ni6giKlsXXOZhBbvZ4FBHbNLUHlvEkFGhCaDddFCsdy9B8a1JMRuKtzD7KUFFV9ESBq/ MdwIswtRys1zN4in+YpylsNMy2Pnq7TmORNpU9kMYPJ5TpSlW+qYX6wkb1nvX9EIRVgo wyXbW/VByYXnXj7W6octM7PNXL5W23fe52z657RdinZ6V1FdfLVMFmi73iFIBYmU8xu9 QS+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=yYEGOsWoC9g9xfXQfkz9vofz7qOYVD3SIdNgqPXd3xc=; b=MvuSZEcPKNqp5AVwbkk+vhYr85MFYudJv8dgjhaHaUFOxJr3KOK7WqycB8wRyUPaaI Fb9gCZB4Y7anm+dAeQbTBIc8ia3/BF9D6D9qqwnThgHZ+9YJkrrPLXIFhA1x2AYfOmEb f/eFPplxBjZEEL7gloqcXoTn60Co9KAo3yv9mtXCbUk3KIXjnfbrKe0cjGJBKkDIjZBo Gwx5+/9gH443dpZOW2jCENw5GsGEmxdsRunqgL/9z26vUjcAtwX2p625upKabCMgjSZg pHBq7CR9NtYQhx9hhy3vyKD02Ys6TduR/cGsAoagpfcg0n1QA5c3ztC57pY0DUiPFLuX tavw== X-Gm-Message-State: ACgBeo2MnstA2L6o6YXWBIfjG41GJQWn4OxcsvgD70ZtzJaUHR+zgsJo prSSxWN/NVZLP6PScLvLhe8qIDbJnrm7Mv06ekI= X-Google-Smtp-Source: AA6agR5AAXLuDNsV//CGBVIw/U/Qe8gU07vJ7/YU1R3nGgCYDyvG8UxpiFARZ9K28T51y19oLSfQQdxloGSHQFDqDdQ= X-Received: by 2002:a2e:9049:0:b0:261:c790:948a with SMTP id n9-20020a2e9049000000b00261c790948amr2464864ljg.449.1661156174967; Mon, 22 Aug 2022 01:16:14 -0700 (PDT) MIME-Version: 1.0 References: <20220712093528.4144184-1-marcandre.lureau@redhat.com> <20220712093528.4144184-12-marcandre.lureau@redhat.com> <87pmhf86ew.fsf@pond.sub.org> <8735e38e6t.fsf@pond.sub.org> <87o7wr5ew9.fsf@pond.sub.org> <87o7wqoqc1.fsf@pond.sub.org> In-Reply-To: <87o7wqoqc1.fsf@pond.sub.org> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Mon, 22 Aug 2022 12:16:03 +0400 Message-ID: Subject: Re: [PATCH v2 11/15] qemu-common: move scripts/qapi To: Markus Armbruster Cc: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Peter Maydell , qemu-devel@nongnu.org, Eric Blake , Cleber Rosa , qemu-block@nongnu.org, Paolo Bonzini , Xie Yongji , Kyle Evans , John Snow , Michael Roth , Warner Losh , Kevin Wolf , "Dr. David Alan Gilbert" , Vladimir Sementsov-Ogievskiy , Laurent Vivier , Fam Zheng , Hanna Reitz Content-Type: multipart/alternative; boundary="000000000000b9b98d05e6d00fec" Received-SPF: pass client-ip=2a00:1450:4864:20::22e; envelope-from=marcandre.lureau@gmail.com; helo=mail-lj1-x22e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000b9b98d05e6d00fec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Thu, Aug 11, 2022 at 5:35 PM Markus Armbruster wrote= : > Daniel P. Berrang=C3=A9 writes: > > > On Thu, Aug 11, 2022 at 02:50:01PM +0400, Marc-Andr=C3=A9 Lureau wrote: > >> Hi > >> > >> On Thu, Aug 11, 2022 at 2:22 PM Peter Maydell > > >> 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. li= ke > >> 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. > > The generated code is used by qemu-ga & storage daemon, at least. They are the first potential consumers, after qemu. > Not sure a subproject would be a good fit. > (I won't repeat the arguments of structuring a project) > > 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"). > > Not sure I follow, but that's just the "install" step isn't it ? Sure, we could have a "qemu-devel", that ships qapi-gen, I guess. But then, you would expect stability/versioning. That's not what I am proposing (at least at this point), which is just about the build system and project structure, so we can build and work on subprojects independently. (for ex, in my wip branch, qemu-ga meson.build is 115 lines, doesn't need QEMU configure etc) > > 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. > > I can't see much benefit from doing that extra work. It would create two C APIs, making future bindings efforts more difficult etc. QObject is very much like GValue though (the naming is better too :), just like the QOM & GObject story. thanks --=20 Marc-Andr=C3=A9 Lureau --000000000000b9b98d05e6d00fec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Thu, Aug 11, 2022 at 5:35 PM Mar= kus Armbruster <armbru@redhat.com> wrote:
Da= niel P. Berrang=C3=A9 <berrange@redhat.com> writes:

> On Thu, Aug 11, 2022 at 02:50:01PM +0400, Marc-Andr=C3=A9 Lureau wrote= :
>> Hi
>>
>> On Thu, Aug 11, 2022 at 2:22 PM Peter Maydell <peter.maydell@linaro.org&= gt;
>> wrote:

[...]

>> > As Markus says, your branch ends up moving most of qobject in= to
>> > qemu-common/. We are never going to let that out of QEMU prop= er,
>> > because we are never going to allow ourselves to be tied to A= PI
>> > compatibility with it as an external library. So anything tha= t
>> >
>>
>> Why is that? We do it with a lot of dependencies already, with sta= ble APIs.
>>
>> Furthermore, we don't "have to" be tied to a specifi= c 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 "qem= u-common"
>> repository. I don't think there are enough reasons to want tha= t either.
>>
>>
>>
>> > needs qobject is never going to leave the QEMU codebase. Whic= h
>> > means that there's not much gain from shoving it into sub= project/
>> > IMHO.
>>
>>
>> (just to be extra clear, it's qobject not QOM we are talking a= bout)
>>
>> 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/archiv= e/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.


The generated code is used by qemu-ga = & storage daemon, at least. They are the first potential consumers, aft= er qemu.
=C2=A0
Not sure a subproject would be a good fit.

<= div>(I won't repeat the arguments of structuring a project)
=C2=A0

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


Not sure I follow, but that's just= the "install" step isn't it ?

Sure,= we could have a "qemu-devel", that ships qapi-gen, I guess. But = then, you would expect stability/versioning. That's not what I am propo= sing (at least at this point), which is just about the build system and pro= ject structure, so we can build and work on subprojects independently. (for= ex, in my wip branch, qemu-ga meson.build is 115 lines, doesn't need Q= EMU configure etc)

=C2=A0
> We don't neccessarily need the current QAPI C code generator. Ther= e
> could be a new C generator that didn't use qobject, but instead us= ed
> some standard GLib types like GHashTable/GList instead of QDict/QList.=

Yes, that should be possible.


I can't see much benefit from do= ing that extra work. It would create two C APIs, making future bindings eff= orts more difficult etc.

QObject is very much like= GValue though (the naming is better too :), just like the QOM & GObjec= t story.

thanks

--
Marc-Andr=C3=A9 Lureau
--000000000000b9b98d05e6d00fec--