[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary |
Date: |
Thu, 27 Apr 2023 13:22:26 +0100 |
User-agent: |
Mutt/2.2.9 (2022-11-12) |
On Thu, Apr 27, 2023 at 02:12:59PM +0200, Thomas Huth wrote:
> On 27/04/2023 10.33, Daniel P. Berrangé wrote:
> > 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.
>
> We could deprecate the old wrappers at one point in time, so we would
> finally have a cleaner interface.
At the cost of breaking compat every single script and doc that
referrs to the historical binaries.
I think incompatible changes are worth it, but only if we associate
them with the a approach to qemu system emulator binaries, as that's
where we'll get a compelling benefit. Fiddling around with the
existing binaries is creating pain for little gain IMHO.
> > What does having a
> > qemu-system-x86 add that can't be achieve just though hardlink
> > between the two existing binaries ?
>
> We'd finally have a binary with saner default settings compared to the
> backlevel "pc" machine type that we have as a default now?
On the libvirt side we would have to ensure there was no change in
defaults regardles of what he QEMU binary did.
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 :|
- [RFC PATCH 1/3] cpu: Add a way to detect 32-bit mode from argv0, (continued)