From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW2OY-0002is-9S for qemu-devel@nongnu.org; Mon, 22 Sep 2014 08:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW2OS-0006PS-5z for qemu-devel@nongnu.org; Mon, 22 Sep 2014 08:07:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW2OR-0006L3-VR for qemu-devel@nongnu.org; Mon, 22 Sep 2014 08:07:00 -0400 Date: Mon, 22 Sep 2014 15:10:00 +0300 From: "Michael S. Tsirkin" Message-ID: <20140922121000.GL14882@redhat.com> References: <1411310339-27733-1-git-send-email-alex@alex.org.uk> <1411310339-27733-3-git-send-email-alex@alex.org.uk> <20140922113655.GI14882@redhat.com> <9532E4EE-C926-4A57-A77C-66A9F4352B1A@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9532E4EE-C926-4A57-A77C-66A9F4352B1A@alex.org.uk> Subject: Re: [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Ryan Harper , Serge Hallyn , "quintela@redhat.com" , Libvirt , Serge Hallyn , "qemu-devel@nongnu.org" , Alexander Graf , Cole Robinson , Amit Shah , Bruce Rogers , Andreas =?iso-8859-1?Q?F=E4rber?= , "Serge E. Hallyn" On Mon, Sep 22, 2014 at 12:50:14PM +0100, Alex Bligh wrote: > > On 22 Sep 2014, at 12:36, Michael S. Tsirkin wrote: > > > On Sun, Sep 21, 2014 at 03:38:59PM +0100, Alex Bligh wrote: > >> Add a configure option --enable-pc-1-0-qemu-kvm and the > >> corresponding --disable-pc-1-0-qemu-kvm, defaulting > >> to disabled. > >> > >> Rename machine type pc-1.0 to pc-1.0-qemu-git. > >> > >> Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm > >> or pc-1.0-qemu-git depending on the value of the config > >> option. > >> > >> Signed-off-by: Alex Bligh > > > > I have to say, this one bothers me. > > We end up not being able to predict what does pc-1.0 > > reference. > > The whole point is to make it easy for distributions to make > pc-1.0 do an appropriate thing for them, an appropriate thing > being what their previous release(s) meant by pc-1.0. Sadly, > pc-1.0 means more than one thing - on Ubuntu it really means > "qemu-kvm's pc-1.0" and on other systems (and upstream) it > means "qemu-git's pc-1.0". This is horrible, but it's not > the fault of this patch, is simply current reality. Right > now, you can't tell what pc-1.0 does anyway, as it does a > different thing on Ubuntu Precise to Ubuntu Trusty (for instance). > > If we're going to provide compatibility to the machine type > name level (which is the purpose here) then sadly we need > something like this. Ack for "something" but not like this, I suspect. > As for 'not being able to predict', actually post this patch > the situation is far clearer, as '-M ?' tells you exactly > what pc-1.0 will do, by showing what it's an alias for. > > > Users also don't get qemu from git so I don't see > > why does git make sense in the name? > > Agree with that, but I couldn't think of anything better. > 'qemu-upstream'? 'qemu'? > > > Legacy management applications invoked qemu as qemu-kvm - > > how about detecting that name and switching > > the machine types? > > It might make sense to also set -enable-kvm a > > Sadly that is not true. For instance on Ubuntu Precise > it's invoked as qemu-system-x86_64 by at least one > management application known to me. Well change it to call qemu-kvm then :) Also what happens if you install qemu as well? Does it conflict? > I'm not quite sure why you say "legacy management > applications". Because any non legacy one can be patched. > This applies to /any/ management application. > Unless we're going to burden every management application > with this problem, we need to fix it. > > Just as a reminder, the ./configure value defaults to > off, which means there is no change in current behaviour. Yes but this still perpetuates the mess. If you prefer using -M pc-1.0, add a new property and teach management to set it. But no silent compile-time behind the scenes changes please. > Only if the ./configure value is changed does it result > in the behaviour of pc-1.0 changing, and that is evident > from the help line. And it's possible to specify a specific > variant of 1.0 (irrespective of the default) from the > command line. > > -- > Alex Bligh > > >