From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7m7U-0000It-SD for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:57:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7m7R-00085g-J9 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:57:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7m7R-00085Z-EG for qemu-devel@nongnu.org; Wed, 24 Jun 2015 10:57:41 -0400 Date: Wed, 24 Jun 2015 16:57:36 +0200 From: "Michael S. Tsirkin" Message-ID: <20150624165140-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> <20150623231818-mutt-send-email-mst@redhat.com> <20150624141651.GS3134@thinpad.lan.raisama.net> <20150624161820-mutt-send-email-mst@redhat.com> <558AC021.1080403@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <558AC021.1080403@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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Eduardo Habkost On Wed, Jun 24, 2015 at 04:35:13PM +0200, Andreas F=E4rber wrote: > Am 24.06.2015 um 16:19 schrieb Michael S. Tsirkin: > > On Wed, Jun 24, 2015 at 11:16:51AM -0300, Eduardo Habkost wrote: > >>> IMHO -M pc is not supposed to mean "can break at any time". > >> > >> It means "it may have new host-side requirements and may become runn= able > >> in your host (or require additional command-line flags to run) at an= y time". > >=20 > > That would be pretty bad. I don't think we ever had such cases in pra= ctice. >=20 > Why is that bad or unexpected? If you install new software, it may have > new dependencies. QEMU would be no different from other software there. That's just basic compatibility. If I run using same flags, I expect compatible behaviour. How would you like it if each time you update bash, all your scripts had to stop working, unless you specify a specific compability flag in scripts, in which case you miss (some) bugfixes? Or if you found code snippets and they can't both work. Why? Because snippet 1 says request version 2.4 compatibility and another says use ver= sion 2.5 compatibility, so you can't use both. Each time you break command line compatibility, you invalidate an unknown chunk of useful documentation somewhere. > Yesterday Eduardo said it was about having a fixed version installed an= d > therein switching from a legacy machine to a newer machine. In that cas= e > the dependencies existed ever since installation but were not > immediately visible to the end user due to our stability guarantees. >=20 > Andreas >=20 > --=20 > SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; H= RB > 21284 (AG N=FCrnberg)