Re: [ANNOUNCE] linux-libc-headers 2.6.3.0

[Krzysztof Halasa <khc@pm.waw.pl>]

Mariusz Mazur <mmazur@kernel.pl> writes:

> We do. Abi changes are rather rare so keeping them as a separate tree
> wouldn't 
> add too much work for subsystem maintainers, and it would be a Good Thing 
> (tm) to have one place where the whole current abi can be seen.

Sure. One place, yes. But separate header sets are IMHO too much crazy.

> One thing to 
> note is that linux headers duplicate many structures and definitions that 
> should be (and are) provided by glibc. This causes collisions. My current 
> practice is to clear offending linux headers of their content, and simply 
> include appropriate libc headers (with a nice warning) from them.

Is it the kernel which is based on glibc, or is it glibc (and the rest of
the userland as glibc isn't that special) using the kernel interface?

The kernel doesn't need glibc at all, I don't know why do you want it
to require some external headers to compile.
Should the kernel behave differently when compiled with different glibc
header sets? :-)

IMHO all the defines should be in the kernel tree. Glibc can and should
use them, as it uses the ABI.

> I can say that about 60-80% of current linux headers do not have proper 
> separation of kernel only code (counting in headers that are kernel only,
> but 
> have no visible signs of that fact)

No doubt.

> and adding that separation would take a 
> while. And even if successfull, it would add significant maintainer burden
> to 
> keep the whole thing working (it would probably look like crap too).

Don't think so. Anyway, there is no other acceptable option. The kernel
must compile without glibc headers (without any external headers, to
be precise) - as it doesn't need any external software to work.

The open question (of much less importance) is if we want to keep
the existing include/ layout or to move public parts to include/linux-abi
etc. It still has to reside in the kernel tree, though. I'd go with the
former for now as it requires less work. OTOH the latter might be
cleaner.

> And we have to remember 2.4 compatibilities (which linux-libc-headers
> have) - 
> is 2.6 kernel a place for them?

Examples?
If they are part of kernel API/ABI, then of course they are still used
by 2.6 kernel and they need to be there. If they aren't used by the
kernel (old #define names for instance) they should go to glibc headers
(#ifndef xxx #define xxx etc.).
-- 
Krzysztof Halasa, B*FH