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

Michael S. Tsirkin mst at redhat.com
Mon Sep 22 12:10:00 UTC 2014


On Mon, Sep 22, 2014 at 12:50:14PM +0100, Alex Bligh wrote:
> 
> 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.

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
> 
> 
> 




More information about the libvir-list mailing list