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

[Michael S. Tsirkin]

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.

So a flag might be better, but if we want to be compatible
with qemu-kvm, poking at argv[0] still better than configure.


> > It might make sense to also set -enable-kvm and
> > change default CPU to kvm64 in this case.
> 
> Yup.