qemu-devel
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]