[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch

From: andrzej zaborowski
Subject: Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
Date: Wed, 11 Jul 2007 20:54:14 +0200

On 08/07/07, Daniel P. Berrange <address@hidden> wrote:
On Sun, Jul 08, 2007 at 06:04:51PM +0100, Ricardo Almeida wrote:
> On 7/8/07, Daniel P. Berrange <address@hidden> wrote:
> >On Sun, Jul 08, 2007 at 02:21:02PM +0200, Robert Millan wrote:
> >> Shouldn't /usr/bin/qemu be an alias for qemu-system-$(ARCH), where
> >$(ARCH) is
> >> the native architecture?  Defaulting to i386 doesn't make much sense
> >nowadays,
> >> specially since x86_64 is gradually obsoleting it.
> >
> >Management tools for QEMU will have come to rely on existing semantics of
> >/usr/bin/qemu being i386.
> Why?! If they rely on 386 I think they should directly use
> qemu-system-i386... If they manage in an architecture independent way
> then use the qemu link...

Rely on a binary which doesn't currently exist ? A fresh checkout & build
of qemu cvs  does not produce any qemu-system-i386 binary. So that's not

Maybe it's a good idea to make qemu-system-i386 a symlink to qemu or
the other way, for now, and after some time do what Ricardo proposed,
which is more logical. After all qemu has already broken commandline
backwards compatibility many times and probably will do more times.

And here's one of my usual strange but fun ideas: make "qemu" a
wrapper that reads a number of first bytes of the
harddisk/cdrom/kernel image or whatever media was given, and applies a
heuristic to decide what architecture the instructions would be best
interpreted as. The "file" program likely already contains a sample of
such heuristic.

(A similar idea with reusing "file" code was for vvfat to detect what
OS is on a given partition and fake an MBR respective to the OS).


reply via email to

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