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é <berra...@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
