From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Enhance perf to support KVM Date: Sun, 07 Mar 2010 16:17:35 +0200 Message-ID: <4B93B57F.8090706@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> <20100302171752.GB28538@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49670 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753237Ab0CGOTS (ORCPT ); Sun, 7 Mar 2010 09:19:18 -0500 In-Reply-To: <20100302171752.GB28538@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 03/02/2010 07:17 PM, Ingo Molnar wrote: > * Paolo Bonzini 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