From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7lbV-00008j-S4 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:24:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7lbR-00051w-5b for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:24:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7lbR-00051s-0R for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:24:37 -0400 Date: Wed, 24 Jun 2015 16:24:25 +0200 From: "Michael S. Tsirkin" Message-ID: <20150624162113-mutt-send-email-mst@redhat.com> References: <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> <20150623232725-mutt-send-email-mst@redhat.com> <20150624141818.GT3134@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150624141818.GT3134@thinpad.lan.raisama.net> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , Andreas =?iso-8859-1?Q?F=E4rber?= , rth@twiddle.net On Wed, Jun 24, 2015 at 11:18:18AM -0300, Eduardo Habkost wrote: > On Tue, Jun 23, 2015 at 11:28:06PM +0200, Michael S. Tsirkin wrote: > > On Tue, Jun 23, 2015 at 02:42:37PM -0300, Eduardo Habkost wrote: > > > On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas F=E4rber 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 wer= e in > > > > vain because libvirt now wants to start their own versioning syst= em 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 > > "Users will be hurt because they'll run untested configurations" > > seems like a valid reason. >=20 > I trust libvirt developers to test their CPU definitions as carefully a= s > we test ours. Maybe someone can do a write-up explaining how do requirements and needs differ? So far, it looks like gratituos code duplication based on a mis-understanding, or highly unlikely theoretical what-if scenarious. Basing our stable interfaces on such grounds might not be a good idea. > --=20 > Eduardo