* Paolo Bonzini <pbonz...@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.
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.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
