From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWLLe-0007RM-Ht for qemu-devel@nongnu.org; Tue, 23 Sep 2014 04:21:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWLLU-0007yz-Ib for qemu-devel@nongnu.org; Tue, 23 Sep 2014 04:21:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWLLU-0007xu-B2 for qemu-devel@nongnu.org; Tue, 23 Sep 2014 04:21:12 -0400 Date: Tue, 23 Sep 2014 11:24:13 +0300 From: "Michael S. Tsirkin" Message-ID: <20140923082413.GB16527@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> <871tr37jsv.fsf@blackfin.pond.sub.org> <20140922172135.GC11272@redhat.com> <87oau6wywa.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87oau6wywa.fsf@blackfin.pond.sub.org> 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: Markus Armbruster Cc: Ryan Harper , Serge Hallyn , "quintela@redhat.com" , Libvirt , Serge Hallyn , qemu-devel@nongnu.org, Alexander Graf , Alex Bligh , Cole Robinson , Amit Shah , Bruce Rogers , Andreas =?iso-8859-1?Q?F=E4rber?= , "Serge E. Hallyn" On Tue, Sep 23, 2014 at 09:59:17AM +0200, Markus Armbruster wrote: > "Michael S. Tsirkin" writes: > > > On Mon, Sep 22, 2014 at 05:32:16PM +0200, Markus Armbruster wrote: > >> "Michael S. Tsirkin" writes: > >> > >> > 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. > >> > > >> > Users also don't get qemu from git so I don't see > >> > why does git make sense in the name? > >> > > >> > Legacy management applications invoked qemu as qemu-kvm - > >> > how about detecting that name and switching > >> > the machine types? > >> > >> Ugh! I like that even less than a configure option. > > > > configure options are tested even less than runtime ones: > > each distro has to pick up a set of options and all > > users are stuck with it. > > So let's assume Ubuntu sets this and something is broken. How is a > > Fedora user to test this? Find out configure flags that Ubuntu uses > > and rebuild from source? It's hard to get people to triage bugs as it > > is. > > That's why changing behaviour in subtle ways depending on > > configure options is a very bad idea. > > All it changes is a default machine type. I wouldn't classify that as > "very bad". Fortunately, our difference of opinion doesn't matter, > because the conclusion of the thread is "leave it to the distros". > > > So a flag might be better, but if we want to be compatible > > with qemu-kvm, poking at argv[0] still better than configure. > > That I do consider a genuinely bad idea. > > Example of usage messed up by it: I symlink from my ~/bin to executables > in various build trees. If one of these programs changed behavior > depending on what it finds in argv[0], I'd have to know *exactly* how it > matches argv[0] to choose suitable names for my symlinks. > > The name "qemu-kvm" is not a useful indicator of compatibility with the > qemu-kvm fork of QEMU anyway. There are programs out there calling > themselves qemu-kvm that aren't compatible with the qemu-kvm fork. And > there are programs out there that are compatible, but call themselves > something else. I think the approach v4 takes is reasonable, though. I didn't look at the implementation yet. -- MST