[libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm

[Michael S. Tsirkin]

On Tue, Sep 23, 2014 at 09:59:17AM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst at redhat.com> writes:
> 
> > On Mon, Sep 22, 2014 at 05:32:16PM +0200, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" <mst at redhat.com> 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 <alex at alex.org.uk>
> >> >
> >> > 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