lkml.org 
[lkml]   [2003]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BK PATCH] klibc for 2.5.64 - try 2

On Sat, 8 Mar 2003, Larry McVoy wrote:
>
> Actually, I think this libc is very useful and at the risk of depressing hpa
> even more, we may well link BitKeeper against it. We make no use of anything
> glibc specific since we run on all sorts of platforms and having libc be
> part of the image would be cool if it were small.

Mixing basic libraries on the same host can be a damn pain, which is one
reason why libraries have a hard time getting competition (and if they
don't have competition, they have little incentives to becomes smaller and
leaner and faster)

For example, I bet you'll find problems with simple things like
disagreements over configuration. Things like user/host lookups (NIS,
files, whatever?) etc. You'll get BK to behave differently from other
binaries because it uses a different library that is configured
differently..

And then there will be some feature that isn't there, because the klibc
people really don't care. So then you'll have a mixed environment..

Yeah, it sucks. A basic standard C library _should_ probably be so small
that it really doesn't make any real sense to have shared libraries for it
at all. But because of all the nasty corner cases for the "extended
functionality", you often end up wanting to lump a lot of new stuff into
the standard library, so you get all these connections that are hard to
break.

And nobody wants to have to add "-lresolv" (or even "-lm") etc to their
builds, so there's the user base too that by being lazy really advocates a
big library. And once it is big it really wants to be shared. And once
_that_ happens, you want even more to combine libraries that would
otherwise have been fine as two separate libs, since you don't want to
make the startup costs worse than they already are by having to mmap many
different files.

In short: some stuff would be better off static, simply because it's
smaller that way, and it helps startup costs if it can be all linked into
the binary. But it's _only_ smaller if you don't have to do the dynamic
linking _anyway_, which means that the cases where it really pays off are
only for the simple stuff.

And there's a _lot_ of simple stuff, but even then you have to live
together with stuff that isn't simple, so now the simple stuff has to live
by the rules of the complex stuff. And the complex stuff doesn't mind
doing complex things if it makes other things more convenient, so the
complex parts really don't care about living together with the small and
simple stuff.

Yeah, I'm pessimistic. It's just _damned_hard_ to be small any more, when
you have to live in harmony with projects that long since stopped caring
about the small stuff, because it just didn't even register on their
radar any more.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.042 / U:2.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site