"Michael S. Tsirkin" <mst@redhat.com> writes:
On Mon, Sep 22, 2014 at 05:32:16PM +0200, Markus Armbruster wrote:
"Michael S. Tsirkin" <mst@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@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.