glibc 2, and Linux 2.x

Teunis Peters (
Wed, 30 Jul 1997 10:53:20 -0600 (MDT)

On Wed, 30 Jul 1997, Richard Henderson wrote:

> > Some applications must interface directly to the kernel.
> > (arpd, kerneld, various network tools...)
> > How can they work if header files are incompatible?
> They supply their own. Witness modutils. There's really no other way
> to live with multiple kernel trees, and the interface _cannot_ change
> so quickly as to keep the kernel headers and the application headers
> continually out of sync. Otherwise you break binaries right and left
> and no one likes that either.

It's pretty hard to keep all apps up-to-date in any respect. For the most
part enough compatibility has been kept through the years to say 'since
all the changable bits are in linux anyways we'll just work with that'.

You're saying this is not duable anymore. Hrm... Hard to say.

Sure wish glibc could keep up with the kernel.

> > This is crazy I think.
> Straw men all. At issue is
> (1) The desire to provide surgically clean namespaces for
> ISO C, POSIX, and XPG4.

I suppose this would be nice. It's nice to compile code for other Unixes
on Linux. Sure wish the other unixen weren't dying out...
[I don't see many unix boxes around here - there's a couple of old SCO
boxes floating around town and an unstable sun, but that's about it].

> (2) We don't want to worry about what kernel's headers are
> installed so that things work properly.

GOOD idea! ('specially for those people who can't afford 20+ megs of
kernel source and have to rely on other people for workable binaries)

> (3) Linus doesn't want to be prevented from some particular
> cleanup because of what it might do to libc.

EXCELLENT! (I can support this :)

> (4) The desire to present a constant binary interface in the
> face of a number of planned kernel changes.

Hrm - is there any plans to make glibc releases MUCH faster so glibc can
keep up with kernel? huh huh please? (I mean - the include files should
NEVER change in glibc unless some bug is found. But the linux-lib
interface might change a lot so....)

> We've been over and over this issue. Userland programs not
> using kernel headers is the only sensible solution. This is
> not just some bogus rule of thumb I came up with on the spur
> of the moment.

1. Are linux's capabilities being sacrificed for the ghost of portability?
[will we lose things like joystick support? pnp? video? lowlevel fs?]
2. Is this an efficient interface? (eg. linux's asm/string.h)
3. Are there any use/stability increases? (other than glibc-support for

- Teunis