All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Cc: qemu-devel@nongnu.org, richard.henderson@linaro.org,
	stefanha@redhat.com, "Michael Roth" <michael.roth@amd.com>,
	pbonzini@redhat.com, berrange@redhat.com,
	peter.maydell@linaro.org, thuth@redhat.com, jsnow@redhat.com,
	philmd@linaro.org, "Alex Bennée" <alex.bennee@linaro.org>,
	devel@lists.libvirt.org, "Victor Toso" <victortoso@redhat.com>
Subject: Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common
Date: Wed, 07 May 2025 09:55:13 +0200	[thread overview]
Message-ID: <87msbokg7y.fsf@pond.sub.org> (raw)
In-Reply-To: <f2972cb4-4266-4835-9548-706983dc611f@linaro.org> (Pierrick Bouvier's message of "Tue, 29 Apr 2025 12:15:39 -0700")

Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:

[...]

> I don't think we should think too much ahead for languages other than C, 
> for one, two, and even three reasons :)

I agree that thinking ahead too much is a bad habit.  So is thinking
ahead too little :)

> - First, it's already broken because we rely on ifdef that won't be 
> there in Rust or Go.

I don't think it's broken.  QAPI 'if' translates straightforwardly to C
#if, but that doesn't mean it cannot be translated to conditional
compilation / metaprogramming in other languages.

In fact, the value of 'if' used to be C constant expressions suitable
for use with #if, and we changed it to its current form specifically to
enable Rust work, in merge commit c83fcfaf8a5.  Marc-André's was trying
to develop Rust bindings back then, and if I remember correctly this
change was enough to let him implement 'if' with Rust.

> - Second, it's code, we can just change it later if needed.

True!

> - Third, those json are consumed only by QEMU (right?), so we are free 
> to write/modify them as we want.

Also true.  

> The only thing that must stay the same is what we expose to the consumer 
> in the schema, and which commands we expose in qemu.

We may evolve the external interface as long as we honor our
compatibility promise.

You're aiming for "no change at all" there.  I understand why that's
desirable.  But if it should turn out that a bit of compatible change
simplifies the job, we can take the simpler route.

[...]



  reply	other threads:[~2025-05-07  7:56 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24 18:33 [RFC PATCH 0/3] single-binary: make QAPI generated files common Pierrick Bouvier
2025-04-24 18:33 ` [RFC PATCH 1/3] qapi: add weak stubs for target specific commands Pierrick Bouvier
2025-04-24 18:52   ` Pierrick Bouvier
2025-04-24 18:33 ` [RFC PATCH 2/3] qapi: always expose TARGET_* or CONFIG_KVM code Pierrick Bouvier
2025-04-24 18:33 ` [RFC PATCH 3/3] qapi: make all generated files common Pierrick Bouvier
2025-04-24 20:31   ` Philippe Mathieu-Daudé
2025-04-24 21:08   ` Richard Henderson
2025-04-24 20:43 ` [RFC PATCH 0/3] single-binary: make QAPI " Philippe Mathieu-Daudé
2025-04-24 21:15   ` Richard Henderson
2025-04-24 22:22   ` Pierrick Bouvier
2025-04-24 20:44 ` Philippe Mathieu-Daudé
2025-04-25  7:35 ` Daniel P. Berrangé
2025-04-25 20:39   ` Pierrick Bouvier
2025-04-28  8:37     ` Daniel P. Berrangé
2025-04-28 15:54       ` Pierrick Bouvier
2025-04-25 22:16   ` Philippe Mathieu-Daudé
2025-04-26  4:53     ` Markus Armbruster
2025-04-25 15:38 ` Markus Armbruster
2025-04-25 21:07   ` Pierrick Bouvier
2025-04-25 21:13     ` Pierrick Bouvier
2025-04-26  6:21     ` Markus Armbruster
2025-04-28 16:05       ` Pierrick Bouvier
2025-04-29  7:43         ` Markus Armbruster
2025-04-29  8:37           ` Daniel P. Berrangé
2025-04-29 19:26             ` Pierrick Bouvier
2025-05-07 11:21             ` Markus Armbruster
2025-04-29 19:15           ` Pierrick Bouvier
2025-05-07  7:55             ` Markus Armbruster [this message]
2025-05-07 11:32               ` Daniel P. Berrangé
2025-05-07 19:00                 ` Pierrick Bouvier
2025-05-07 18:54               ` Pierrick Bouvier
2025-04-28 10:25     ` Peter Krempa
2025-04-28 16:18       ` Pierrick Bouvier
2025-04-28  8:55   ` Peter Krempa
2025-04-28 11:07     ` Markus Armbruster
2025-04-28 12:48       ` Philippe Mathieu-Daudé
2025-04-28 16:35       ` Pierrick Bouvier
2025-04-29  8:23         ` Markus Armbruster
2025-04-29  9:20           ` Thomas Huth
2025-04-29  9:32             ` Daniel P. Berrangé
2025-04-29  9:39               ` Philippe Mathieu-Daudé
2025-04-29 19:48             ` Pierrick Bouvier
2025-04-30  5:40               ` Thomas Huth
2025-04-30  6:18                 ` Pierrick Bouvier
2025-04-29  9:35           ` Philippe Mathieu-Daudé
2025-04-29  9:47             ` Daniel P. Berrangé
2025-04-29 19:57             ` Pierrick Bouvier
2025-04-29 20:11               ` Pierrick Bouvier
2025-04-29 12:04           ` BALATON Zoltan
2025-04-28 18:14 ` Stefan Hajnoczi
2025-04-28 19:25   ` Pierrick Bouvier
2025-04-28 19:54     ` Stefan Hajnoczi
2025-04-28 21:35       ` Pierrick Bouvier
2025-05-07 23:19 ` Pierrick Bouvier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87msbokg7y.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=devel@lists.libvirt.org \
    --cc=jsnow@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=victortoso@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.