From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Vjq-0006sZ-66 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:28:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7Vjm-0003CM-Rn for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:28:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Vjm-0003CG-Mz for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:28:10 -0400 Date: Tue, 23 Jun 2015 23:28:06 +0200 From: "Michael S. Tsirkin" Message-ID: <20150623232725-mutt-send-email-mst@redhat.com> References: <20150623173048-mutt-send-email-mst@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150623174237.GL3134@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 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 were in > > vain because libvirt now wants to start their own versioning system t= o > > 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. "Users will be hurt because they'll run untested configurations" seems like a valid reason. > --=20 > Eduardo