Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
Management tools for QEMU will have come to rely on existing semantics of /usr/bin/qemu being i386. 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 $@ Changing this for merely cosmetic reasons [...] 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.
Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
On 08/07/07, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Sun, Jul 08, 2007 at 06:04:51PM +0100, Ricardo Almeida wrote: On 7/8/07, Daniel P. Berrange [EMAIL PROTECTED] 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). Cheers, Andrzej
Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
On Sun, Jul 08, 2007 at 02:21:02PM +0200, Robert Millan wrote: 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. 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 -=|
Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
On 7/8/07, Daniel P. Berrange [EMAIL PROTECTED] 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... Changing this for merely cosmetic reasons would Not cosmetic, logic... cause significant technical complications because tools would then have to try and detect whether /usr/bin/qemu were native or i386. See my previous why?! ;) Thus I see no real functional/technical benefit to changing it, and plenty of downside. 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
Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
On Sun, Jul 08, 2007 at 06:04:51PM +0100, Ricardo Almeida wrote: On 7/8/07, Daniel P. Berrange [EMAIL PROTECTED] 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 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. Changing this for merely cosmetic reasons would Not cosmetic, logic... There was logic with existing naming scheme too, merely different logic than what is proposed. A rename is merely changing logic for cosmetic reasons. cause significant technical complications because tools would then have to try and detect whether /usr/bin/qemu were native or i386. See my previous why?! ;) Because there is no qemu-system-i386 binary Thus I see no real functional/technical benefit to changing it, and plenty of downside. If it's more logic, you have a functional benefit. And for the downside, I don't see them except for non-logic assumptions ;) 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 -=|
