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

[Daniel P. Berrange]

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