Subject: Re: header files state

From: "Kevin D. Kissell" <[email-masked]>
Date: Mon, 20 Mar 2000 10:30:26 +0100

>Linus has stated quite violantly that glibc should not include any
>kernel headers at all - and we're now including less and less
>headers.  But this process needs time and occasionally breaks older
>glibc's.

What is Linus' rationale for his position?   It's true that 
having includes "reaching in" from libc imposes constraints
on kernel designers, but failure to do so is guaranteed
to induce error - as we have seen.

            Kevin K.

---

From: Geert Uytterhoeven <[email-masked]>
Date: Mon, 20 Mar 2000 11:06:52 +0100 (MET)

> to induce error - as we have seen.

The rationale is that you don't need to install Linux kernel sources to compile
user space programs that don't rely on Linux-specific things.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: "William J. Earl" <[email-masked]>
Date: Mon, 20 Mar 2000 10:22:30 -0800 (PST)

> to induce error - as we have seen.

     In this particular case (MIPS-based systems), both glibc and the kernel 
attempt to be MIPS ABI compliant, so there is no real issue in having the
various definitions in two places, since there is an external reference,
just as there is for the processor itself.

     More generally, having a real ABI definition for the key system libraries,
such as libc, is a virtue; it reduces gratuitous "innovation".  Many architectures
have an ABI definition, at least for the basics.