qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ricardo Almeida <ric.almeida@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
Date: Sun, 8 Jul 2007 21:16:18 +0100	[thread overview]
Message-ID: <20070708201618.GA21405@redhat.com> (raw)
In-Reply-To: <8a6cde920707081004j42b61cf5sc887b0c6ef636991@mail.gmail.com>

On Sun, Jul 08, 2007 at 06:04:51PM +0100, Ricardo Almeida wrote:
> On 7/8/07, Daniel P. Berrange <berrange@redhat.com> 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  -=| 

  reply	other threads:[~2007-07-08 20:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-08 12:21 [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch Robert Millan
2007-07-08 16:35 ` Daniel P. Berrange
2007-07-08 17:04   ` Ricardo Almeida
2007-07-08 20:16     ` Daniel P. Berrange [this message]
2007-07-11 18:54       ` andrzej zaborowski
  -- strict thread matches above, loose matches on Subject: below --
2007-08-01 19:53 Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070708201618.GA21405@redhat.com \
    --to=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ric.almeida@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).