make /usr/bin/qemu the native arch

Hi,

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.

See attached patch.

Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

@@ -43,11 +43,7 @@
 QEMU_USER=qemu-$(TARGET_ARCH2)
 # system emulator name
 ifdef CONFIG_SOFTMMU
-ifeq ($(TARGET_ARCH), i386)
-QEMU_SYSTEM=qemu$(EXESUF)
-else
 QEMU_SYSTEM=qemu-system-$(TARGET_ARCH2)$(EXESUF)
-endif
 else
 QEMU_SYSTEM=qemu-fast
 endif

@@ -531,6 +527,13 @@
 install: all 
 ifneq ($(PROGS),)
 	$(INSTALL) -m 755 -s $(PROGS) "$(DESTDIR)$(bindir)"
+ifeq ($(ARCH), $(TARGET_ARCH2))
+ifdef _WIN32
+	mv "$(DESTDIR)$(bindir)/qemu-system-$(TARGET_ARCH2)$(EXESUF)" "$(DESTDIR)$(bindir)/qemu$(EXESUF)"
+else
+	ln -s qemu-system-$(TARGET_ARCH2)$(EXESUF) "$(DESTDIR)$(bindir)/qemu$(EXESUF)"
+endif
+endif
 endif
 
 ifneq ($(wildcard .depend),)

Management tools for QEMU will have come to rely on existing semantics of /usr/bin/qemu being i386. Changing this for merely cosmetic reasons would cause significant technical complications because tools would then have to try and detect whether /usr/bin/qemu were native or i386. Thus I see no real functional/technical benefit to changing it, and plenty of downside.

Dan.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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...

Not cosmetic, logic...

See my previous why?! ;)

If it's more logic, you have a functional benefit. And for the downside, I don't see them except for non-logic assumptions ;)

Regards,
Ricardo Almeida

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 really a viable answer to my point, which is that by renaming the binary there will be added complexity in any tools using qemu, for zero functional improvement.

There was logic with existing naming scheme too, merely different logic than what is proposed. A rename is merely changing logic for cosmetic reasons.

Because there is no qemu-system-i386 binary

If there was no historical precedent with all previous QEMU releases naming it qemu then it'd not be an issue. Since there is historical precedent, changing it will create unneccessary complexity for any tool which wishes to manage QEMU instances. Changing the logic behind binary name alone is *not* a functional benefit, it is merely cosmetic.

Dan.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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).

Cheers,
Andrzej

How about just deprecating it? For example, we could make /usr/bin/qemu be a script with:

#!/bin/bash
echo "warning: $0 is deprecated, use qemu-system-i386 instead" exec qemu-system-i386 $@

It's not just cosmetic. I recall you sent me some benchmarks (too bad they didn't make it to the list, and I somehow lost that mail), but they were done on i386 (which remains unaffected). On x86_64, results are different (specially if you have setup kqemu which only works with qemu-system-x86_64).

Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.