Re: Enhance perf to support KVM

Avi Kivity
2010-03-07T14:19:18Z

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