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

[Alex Bligh]

On 22 Sep 2014, at 12:36, Michael S. Tsirkin <mst at redhat.com> 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 <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.

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.

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.

I'm not quite sure why you say "legacy management
applications". 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.
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