Messages in this thread | | | Subject | Re: [ANNOUNCE] linux-libc-headers 2.6.3.0 | From | Krzysztof Halasa <> | Date | Mon, 01 Mar 2004 19:10:31 +0100 |
| |
Chris Friesen <cfriesen@nortelnetworks.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |