At 1:38 PM -0400 2001-07-14, Jeff Garzik wrote:
>Alan Cox wrote:
>> Jeff Garzik wrote:
>> > it would be nice to remove __KERNEL__ from at least the i386
>> > kernel headers in 2.5, and I think it's a doable task...
>>
>> That just generates work for the glibc folks when they are working
>>off copies
>> of kernel header snapshots as they need to
>
>It is a flag day change so it generates [a lot of] work once... it has
>always been policy that userspace shouldn't be including kernel
>headers. uClibc and now dietlibc are following this policy.
>
>IMHO we have made an exception for glibc for long enough...
I take it the policy JG is referring to applies to including any
kernel header files at all in userspace programs, and that __KERNEL__
removal is a mere consequence of that policy.
AC points out that syscall interfaces in glibc are a reasonable
exception to that policy.
What about a header like ethtool.h? Isn't its whole reason for
existing to provide a common ABI for ethtool.c and the various
drivers that support it?
Likewise sockios.h, which ethtool (and no doubt many others) also
#includes. Unless you're going to encapsulate all possible ioctl
interfaces into libc, sockios.h (for example) provides a piece of the
ABI that's needed by the user code, not just by libc. Why would it
make sense to require retyping of this stuff?
If, on the other hand, the argument is that user-kernel ABI
definitions should be isolated in their own headers, and not mixed up
(hence __KERNEL__), that's a much more restricted argument. My
impression is that this is *not* the argument though; is it?
-- /Jonathan Lundell. - 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/
This archive was generated by hypermail 2b29 : Sun Jul 15 2001 - 21:00:21 EST