From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: Enhance perf to support KVM
Date: Tue, 2 Mar 2010 18:24:13 +0100
Message-ID: <20100302172413.GD28538@elte.hu>
References: <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>
 <4B8D48F1.7020605@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
	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: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.mail.elte.hu ([157.181.151.9]:43636 "EHLO mx2.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752433Ab0CBRYd (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 2 Mar 2010 12:24:33 -0500
Content-Disposition: inline
In-Reply-To: <4B8D48F1.7020605@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Paolo Bonzini <pbonzini@redhat.com> wrote:

> 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.

That is not what i was suggesting though.

I am suggesting a klibc-alike approach, where glibc is not on the filesystem 
but mapped by the kernel, basically as an extension of the standard vDSO.

We always have most of glibc paged in all the time, so there's no real RAM 
usage difference.  (and ultra-embedded would sure make use of this to trim RAM 
usage in fact.)

That way the C library comes with the kernel. New kernel, new/updated system 
library.

	Ingo