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