From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SSc-0004bD-N7 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:58:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7SSY-00021K-PF for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:58:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SSY-00021E-Kn for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:58:10 -0400 Date: Tue, 23 Jun 2015 18:58:05 +0100 From: "Daniel P. Berrange" Message-ID: <20150623175805.GS30318@redhat.com> References: <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <20150623162555.GL30318@redhat.com> <20150623183115-mutt-send-email-mst@redhat.com> <20150623164204.GM30318@redhat.com> <55898D94.4070702@suse.de> <20150623171324.GO30318@redhat.com> <5589976B.3060002@suse.de> <20150623174237.GL3134@thinpad.lan.raisama.net> <55899D82.3040904@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55899D82.3040904@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: mimu@linux.vnet.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Eduardo Habkost On Tue, Jun 23, 2015 at 07:55:14PM +0200, Andreas F=C3=A4rber wrote: > Am 23.06.2015 um 19:42 schrieb Eduardo Habkost: > > On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas F=C3=A4rber wrote: > >> In summary you seem to be saying that all the years we have spent > >> fiddling around with those mind-boggling compat_props in QEMU were i= n > >> vain because libvirt now wants to start their own versioning system = to > >> give users more degrees of freedom even when you can't articulate a > >> single concrete reason why users may want to do so. > >=20 > > I had a similar reaction when I learned about this libvirt > > expectation/requirement I was never aware of. But "we spent lots of > > effort trying to do things differently" doesn't seem like a valid > > justification for design decision. >=20 > True, but my expectation is that libvirt is a friendly wrapper around > QEMU using the mechanisms like -x.y we implemented for it and does not > stand up at random and says, like Dan, that it "wants" to have things > differently from now on, breaking all past assumptions and guarantees. FWIW, this isn't actually a change in opinion from the libvirt side. We never wanted CPU representation tied to machine types, even years back when the first qemu discussions in this area took place. We always wanted to be able to control CPU definition separately from the machine type. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|