qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
	"Peter Krempa" <pkrempa@redhat.com>,
	qemu-devel@nongnu.org, richard.henderson@linaro.org,
	stefanha@redhat.com, "Michael Roth" <michael.roth@amd.com>,
	pbonzini@redhat.com, peter.maydell@linaro.org, jsnow@redhat.com,
	philmd@linaro.org, "Alex Bennée" <alex.bennee@linaro.org>,
	devel@lists.libvirt.org
Subject: Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common
Date: Tue, 29 Apr 2025 10:32:28 +0100	[thread overview]
Message-ID: <aBCcrJxQTOFKoeJQ@redhat.com> (raw)
In-Reply-To: <3024f643-f4df-4342-8d9f-d5929e3ec2e5@redhat.com>

On Tue, Apr 29, 2025 at 11:20:59AM +0200, Thomas Huth via Devel wrote:
> On 29/04/2025 10.23, Markus Armbruster wrote:
> ...
> > I don't wish to derail this thread, but we've been dancing around the
> > question of how to best fix the target for some time.  I think we should
> > talk about it for real.
> > 
> > Mind, this is not an objection to your larger "single binary" idea.  It
> > could be only if it was an intractable problem, but I don't think it is.
> > 
> > You want the single binary you're trying to create to be a drop-in
> > replacement for per-target binaries.
> > 
> > "Drop-in replacement" means existing usage continues to work.
> > Additional interfaces are not a problem.
> > 
> > To achieve "drop-in replacement", the target needs to be fixed
> > automatically, and before the management application can further
> > interact with it.
> > 
> > If I understand you correctly, you're proposing to use argv[0] for that,
> > roughly like this: assume it's qemu-system-<target>, extract <target>
> > first thing in main(), done.
> > 
> > What if it's not named that way?  If I understand you correctly, you're
> > proposing to fall back to a compiled-in default target.
> > 
> > I don't think this is going to fly.
> 
> I tend to disagree. For normal users that consume QEMU via the distros, the
> check via argv[0] should be good enough. For developers, I think we can
> assume that they are adaptive enough to use an additional "-target" option
> in case they mis-named their binary in a bad way.

> > Developers rename the binary all the time, and expect this not to change
> > behavior.  For instance, I routinely rename qemu-FOO to qemu-FOO.old or
> > qemu-FOO.COMMIT-HASH to let me compare behavior easily.
> 
> Developers should already be aware that this can cause trouble, since e.g.
> the qtests are deriving the target architecture from the binary name
> already. See the qtest_get_arch() function.

Even if we want to allow developers to rename binaries, we don't have to
allow an arbitrary choice of naming. We could define an accepted pattern
for naming that people must follow.

eg we could allow for clearly distinguished suffixes (ie append '-SUFFIX')
so that

  qemu-system-x86_64-fishfood

is acceptable while

  qemu-system-fishfood
  qemu-system-x86_64fishfood

would be an unsupported scenarios.

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



  reply	other threads:[~2025-04-29  9:33 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
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é [this message]
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=aBCcrJxQTOFKoeJQ@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@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=pkrempa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).