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

On Mon, Sep 22, 2014 at 05:24:55PM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" <berrange(a)redhat.com&gt; writes: > > > On Mon, Sep 22, 2014 at 02:36:55PM +0300, Michael S. Tsirkin 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(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. > > > > Yeah, this is not good. Any single machine type name should have > > fixed semantics - having two different semantics depending on build > > options means mgmt apps can no longer simply compare the machine > > type name to determine if it is a match with the same name on a > > different host. > > You're right. However, this particular horse left the barn a long time > ago: the pc-* machine types differ in qemu-kvm and upstream QEMU. > > Sure, when qemu-kvm was merged back into QEMU, its machine type variants > were dropped. But they live on in various downstreams that just like > QEMU had to pick between compatibility with upstream QEMU and qemu-kvm, > but unlike QEMU picked compatibility with qemu-kvm. > > So this patch does *not* break any management apps by letting them "no > longer simply compare the machine type name to determine if it is a > match with the same name on a different host". They never could for > these messed up machine types, at least not without knowing exactly what > kind of QEMU runs on the hosts in question. > > All this patch does is adding another facet to "exactly what kind of > QEMU". Right, but IMHO doing it at compile-time is wrong. If distros want compatiblity with both sometimes, what then? Build two binaries with different flags? Should be a runtime option that management sets after (somehow?) figuring out what's going on, on source. How does it do that? Not sure - but I'm sure destination distro has no way to figure it out.