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

"Michael S. Tsirkin" <mst(a)redhat.com&gt; writes: > On Mon, Sep 22, 2014 at 05:32:16PM +0200, Markus Armbruster wrote: >> "Michael S. Tsirkin" <mst(a)redhat.com&gt; 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(a)alex.org.uk&gt; >> > >> > 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.