All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	qemu-devel@nongnu.org, "Eduardo Habkost" <eduardo@habkost.net>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Yanan Wang" <wangyanan55@huawei.com>
Subject: Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary
Date: Thu, 27 Apr 2023 09:33:41 +0100	[thread overview]
Message-ID: <ZEozZX/eH7BzUrWl@redhat.com> (raw)
In-Reply-To: <CABgObfbqD+C4aME0yApeb_9dWA=22Yz+oi_7ECUtf6A4McHrhA@mail.gmail.com>

On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote:
> On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > I wonder if we should take this a step further and rename qemu-system-x86_64
> > > to qemu-system-x86!  Distros can if they wish create symlinks to both
> > > qemu-system-i386 and qemu-system-x86_64.
> >
> > I can't help feeling this just creates a new upgrade burden for distros
> > for no obvious win.
> 
> We can create the symlinks on install as well during the deprecation
> period. It doesn't have to be done by distros.

What's the actual win though ?  Why would anyone want to create guests
using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64
still exist indefinitely for backwards compat.  What does having a
qemu-system-x86 add that can't be achieve just though hardlink
between the two existing binaries ?

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:[~2023-04-27  8:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 13:38 [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary Thomas Huth
2023-04-25 13:38 ` [RFC PATCH 1/3] cpu: Add a way to detect 32-bit mode from argv0 Thomas Huth
2023-04-25 13:38 ` [RFC PATCH 2/3] target/i386/cpu: Allow to limit the 64-bit binary to 32-bit mode only Thomas Huth
2023-04-25 13:38 ` [RFC PATCH 3/3] docs/about/deprecated: Deprecate the qemu-system-i386 binary Thomas Huth
2023-10-06  9:38   ` Philippe Mathieu-Daudé
2023-04-26 10:59 ` [RFC PATCH 0/3] " Paolo Bonzini
2023-04-27  8:13   ` Thomas Huth
2023-04-27  8:25     ` Paolo Bonzini
2023-04-27  8:28   ` Daniel P. Berrangé
2023-04-27  8:31     ` Paolo Bonzini
2023-04-27  8:33       ` Daniel P. Berrangé [this message]
2023-04-27  9:06         ` Paolo Bonzini
2023-04-27 12:12         ` Thomas Huth
2023-04-27 12:22           ` Daniel P. Berrangé
2024-06-19 10:09   ` Philippe Mathieu-Daudé

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=ZEozZX/eH7BzUrWl@redhat.com \
    --to=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.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.