Re: Enhance perf to support KVM

From: Avi Kivity <avi@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Paolo Bonzini <pbonzini@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>,
	Arnaldo Carvalho de Melo <acme@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>
Subject: Re: Enhance perf to support KVM
Date: Sun, 07 Mar 2010 16:17:35 +0200	[thread overview]
Message-ID: <4B93B57F.8090706@redhat.com> (raw)
In-Reply-To: <20100302171752.GB28538@elte.hu>

On 03/02/2010 07:17 PM, Ingo Molnar wrote:
> * Paolo Bonzini<pbonzini@redhat.com>  wrote:
>
>    
>> On 02/26/2010 03:23 PM, Ingo Molnar wrote:
>>      
>>> I do think tools/X and tools/libc would make quite a bit of sense - this is
>>> one of the better design aspects of FreeBSD et al. It's a mistake that it's
>>> not being done.
>>>        
>> I don't see what it would buy to have tools/libc.  You cannot force users to
>> update kernel-space and user-space in lockstep (Apple forced you to do that
>> sometimes when I used Macs at work, and it was very very inconvenient), so
>> it's not like libc would be able to always assume the latest system calls.
>> There is (relatively) a lot of backwards-compatibility code in libc; it's
>> ugly code, but you have to live with it.
>>      
> If glibc was part of the kernel repo with a klibc alike approach we wouldnt
> have such problems: the kernel would provide the system library and that's it.
> You'd not want to upgrade them separately, just like you generally wouldnt
> want to upgrade your memory management code separately from the scheduler
> either.
>
> The same argument could be made in a reverse fashion with just about any part
> of the kernel: 'it would be better to upgrade the ext3 driver separately' -
> etc. It's similar to all the classic microkernel versus monolithic kernel
> arguments.
>    

No, that's Documentation/stable_api_nonsense.txt.  It's perfectly 
possible to have a filesystem driver that is decoupled from the kernel, 
yet both are in the same address space.

> There are costs with increasing size and increasing integration - but fact is
> that we can manage a 13+ MLOC kernel just fine and the benefits of an
> integrated approach far outweigh the costs.
>
> In my experience it's far better to have one project for 'infrastructure'
> bits: developed, tested and offered as one coherent entity in essence. A bit
> like how Xorg does it.
>
> These many splintered kernel facilities are historical legacies in essence
> (from the times when there was no single usable free OS available), and
> over-modularization has many costs and few advantages.
>    

You're probably right for core libraries, but I don't think a GUI for 
kvm qualifies.  A server oriented application, maybe.

-- 
error compiling committee.c: too many arguments to function