From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNVQ4-0007z0-Ez for qemu-devel@nongnu.org; Mon, 07 Nov 2011 15:03:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNVQ3-0006Ow-4C for qemu-devel@nongnu.org; Mon, 07 Nov 2011 15:03:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNVQ2-0006OV-SG for qemu-devel@nongnu.org; Mon, 07 Nov 2011 15:03:47 -0500 References: <4EB6AE34.2000907@redhat.com> <4EB6BAED.2030400@redhat.com> <4EB6BEFA.6000303@codemonkey.ws> <20111106183132.GA4500@thunk.org> <20111106231953.GD4500@thunk.org> <20111107175942.GA9395@elte.hu> From: fche@redhat.com (Frank Ch. Eigler) Date: Mon, 07 Nov 2011 15:03:00 -0500 In-Reply-To: <20111107175942.GA9395@elte.hu> (Ingo Molnar's message of "Mon, 7 Nov 2011 18:59:42 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ingo Molnar Cc: Arnaldo Carvalho de Melo , Alexander Graf , Ted Ts'o , Peter Zijlstra , "kvm@vger.kernel.org list" , qemu-devel Developers , Vince Weaver , "linux-kernel@vger.kernel.org List" , Pekka Enberg , Blue Swirl , Pekka Enberg , Avi Kivity , =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FAm=3DE9rico=3F=3D?= Wang , Linus Torvalds Ingo Molnar writes: > [...] >> It's problem enough that there's no way to know what version of the >> perf_event abi you are running against and we have to guess based >> on kernel version. This gets "fun" because all of the vendors have >> backported seemingly random chunks of perf_event code to their >> older kernels. > > The ABI design allows for that kind of flexible extensibility, and > it's one of its major advantages. > > What we *cannot* protect against is you relying on obscure details of > the ABI [...] Is there some documentation that clearly spells out which parts of the perf syscall userspace ABI are "obscure" and thus presumably changeable? > [...] The usual ABI rules also apply: we'll revert everything that > breaks the ABI - but for that you need to report it *in time* [...] If the ABI is so great in its flexible extensibility, how come it can't be flexibly extended without having to passing the burden of compatibility testing & reversion-yawping to someone else? - FChE