Re: [libc-alpha] Re: [open-source] Re: Wish for 2002

[Linus Torvalds <torvalds at transmeta dot com>]

On 9 Jan 2002, Thomas Bushnell, BSG wrote:
> Kaz Kylheku <kaz@ashi.footprints.net> writes:
> >
> > strlcpy and strcat are not in common use.  They are de jure
> > nonstandard, and de facto nonportable.
>
> So what?  glibc has plenty of functions that are nonstandard, and a
> jillion bogus ones that are standard and essentially unused dead
> weight.

I agree.

However, YOU seem to think that this is an argument for adding more of
them.

While _I_ think it's an argument for trying to make glibc go on a diet.

One of the problems (I think) is that it's always more fun to do new
things than to go back and revisit old code and old decisions. So it's
really hard to get to the point where you say "screw it, I'm going to FIX
this thing".

And that, of course, has nothing to do with glibc per se. Every project
(including, very much, the kernel) tends to have the same problem.

> Perhaps we need a way to enable large libraries of mostly-unused
> functions to avoid the fragmentation problems that Linus thinks are so
> critical.

One approach that has been popular in the past, is to split off libraries,
and not have one large one. Separate libdns, libcurses, libthread, etc.
The problem with that approach is that it only works if things are truly
independent - once you have to load multiple libraries due to
interdependencies you just lost all the advantages and made up a few
disadvantages of your own.

It gets even worse when glibc is so eager to inline stuff. The glibc
header files are _way_ too aggressive in this regard (mostly noticeable on
the C++ side, actually). Inlining is fine if something is executed
millions of times and you can use the inlining to generate code that is a
few cycles faster, but inlining is really bad if it makes the binary
larger and the few cycles you save aren't enough to offset the overhead of
loading bigger libraries.

> It shouldn't take any longer to map a very large file as a very short
> one in the kernel; if it does now, then that's a problem that should
> (eventually) be fixed.  (I'm not trying to argue it should have any
> special priority.)

That is a _fundamentally_ flawed argument.

Bigger mappings do actually take longer to set up and tear down.  One
issue is the increased number of page faults: a _dense_ mapping is always
cheaper than a larger and less dense mapping (because the program needs
the same functions - so a dense mapping will cause fewer page faults).

However, even if you were to fault in the same number of pages, the
smaller mapping wins at unmap time - you have fewer virtual addresses to
go through to unmap.

> Not at all.  My point is that it was once the goal of glibc to have
> all the functions from BSD, regarding that as a de facto standard as
> important as Posix.  Somewhere along the line, the idea that glibc
> should be *superb* got lost, and now it's ok if glibc is merely
> adequate.

It always looks like a good idea to be large when you are small.

But at some point the dynamic changes. If you're getting large enough that
everything works with you, and large enough that the _problems_ of being
large are becoming more obvious, you have to realize that you MUST behave
differently than you used to behave.

Small is _good_. As Albert Einstein said: make it as simple as you can,
but no simpler. glibc used to (a long time ago) be "too simple". It
absolutely does NOT count as "too simple" any more.

Intelligence: the ability to make educated guesses about the future from
past knowledge - see where you are going, and ACT on it.

Not intelligence: doing the same mistake over and over, even after it no
longer makes sense.

No, glibc is _not_ *superb*. Quite frankly, I _wince_ when I see code
generated for glibc quite often.

> No, certainly not.  It's because we should make our library better
> than everyone else's if we can.

Bigger is _NOT_ the same thing as better. Really.

			Linus