From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: Enhance perf to support KVM
Date: Tue, 02 Mar 2010 18:20:49 +0100
Message-ID: <4B8D48F1.7020605@redhat.com>
References: <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B87B407.2070309@redhat.com> <20100226124646.GB19476@elte.hu> <4B87C494.4090306@redhat.com> <20100226131614.GB2518@elte.hu> <4B87D4FB.2060200@redhat.com> <20100226142318.GE23422@elte.hu> <4B8D40CB.1090905@redhat.com> <20100302171250.GF4779@ghostprotocols.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ingo Molnar <mingo@elte.hu>, Avi Kivity <avi@redhat.com>,
	"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>, ming.m.lin@intel.com,
	sheng.yang@intel.com, Jes Sorensen <Jes.Sorensen@redhat.com>,
	KVM General <kvm@vger.kernel.org>,
	Zachary Amsden <zamsden@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arjan van de Ven <arjan@infradead.org>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:15271 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751391Ab0CBRVn (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 2 Mar 2010 12:21:43 -0500
In-Reply-To: <20100302171250.GF4779@ghostprotocols.net>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 03/02/2010 06:12 PM, Arnaldo Carvalho de Melo wrote:
> You imply lockstep updates because both are on the same source tree? I
> don't see why that would be required, there is an ABI contract to be
> respected no matter where the sources for the signatories live.

It's not about ABIs, it's about not being able to rely exclusively on 
new syscalls or flags (one for all: SOCK_NONBLOCK) because people can 
run new glibc on old kernels.

If libc had this luxury, it would possibly make a lot more sense to have 
it in the kernel tree.  But it doesn't.

Also, setting up a testing environment for glibc is not trivial, and the 
intersection of people that care about developing the kernel _and_ glibc 
is probably too small and opinionated to make this easier.

>I could've done both the kernel and userspace bits in the same patch.

You could add a glibc submodule to your git tree, and ask on the git 
list for help adding some kind of multi-destination support to 
git-{format-patch,send-email}.

Paolo