Re: [ANNOUNCE] linux-libc-headers 2.6.3.0

[Krzysztof Halasa]

Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx> writes:

> For current kernels, the "official" method is to have cleaned up
> copies of the kernel headers shipped with glibc and placed in
> /usr/include/linux and /usr/include/asm.

Not sure about it being "official".
It may make sense if it's a distribution - many users don't install
kernel sources. Still, from a technical point of view, it should be
a straight copy of kernel includes - we don't want to maintain two
separate sets, do we?

>  The "real" headers will
> often work, but not always,

Then they should be fixed.
I.e. parts for internal kernel use should be wrapped with #ifdef __KERNEL__.
Personally I consider every kernel header which prevents successful
user space compilation buggy.

> To complicate things, if you add new stuff to the kernel (new ioctl
> commands, etc.) then your app needs to either link against the "real"
> headers, or else duplicate the definitions.
>
> Its kind of a mess.

Precisely. This is why we need just one header set.

> In an ideal world there would be clean "userspace" headers shipped
> with the kernel, and the kernel would then use those headers plus the
> kernel-only stuff.

Not sure about it. How is it different from clean "kernel" headers
shipped (obviously) with the kernel?


The "non-problem" here is, IMHO, that the cleaning of kernel headers
is quite trivial, and thus nobody is interested :-)
-- 
Krzysztof Halasa, B*FH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/