Re: [RFC PATCH 0/3] Deprecate the qemu-system-i386 binary

[Paolo Bonzini]

On 4/27/23 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.  What does having a
> qemu-system-x86 add that can't be achieve just though hardlink
> between the two existing binaries ?

That the two existing binaries can also be removed sooner or later.

Even if we add a QMP-only binary, qemu-system-* would be a nicer 
interface for developers and for quick-and-dirty launch of guests 
(including usecases such as kvm-unit-tests).  Libvirt is not even 
available on Windows and I think on any non-Linux system?  So having a 
qemu-system-x86 that has the same defaults as qemu-qmp-x86 is useful for 
developers.

That said, most people are really using qemu-kvm and not 
qemu-system-{i386,x86_64}.  On one hand it'd be nice if qemu-kvm's 
default machine type changed away from "-M pc", on the other hand that 
would have consequences on CLI backwards-compatibility. :(

Paolo