Linux kernel headers violate RFC2553
Felix von Leitner
thus exports the wrong API to user land.
Here is what RFC2553 mandates:
struct ipv6_mreq {
struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
unsigned int ipv6mr_interface; /* interface index */
};
...and here is what include/linux/in6.h declares:
struct ipv6_mreq {
/* IPv6 multicast address of group */
struct in6_addr ipv6mr_multiaddr;
/* local IPv6 address of interface */
int ipv6mr_ifindex;
};
Note the ipv6mr_ifindex instead of the correct ipv6mr_interface.
This wrong name is only used twice in net/ipv6/ipv6_sockglue.c, so it should be
trivial to fix.
Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David S. Miller
Felix von Leitner writes:
> glibc works around this, but the diet libc uses the kernel headers and
> thus exports the wrong API to user land.
Don't user kernel headers for userspace.
Kernel headers and user headers are distinctly different namespaces,
and you have pointed out only one of many places where we use
different names/structures/etc. for some kernel networking headers
vs. what userspace wants.
Later,
David S. Miller
da...@redhat.com
Felix von Leitner
> > glibc works around this, but the diet libc uses the kernel headers and
> > thus exports the wrong API to user land.
> Don't user kernel headers for userspace.
What choice do I have?
Duplicate everything and then be out of sync when the specs change?
Using glibc-2.1.* for IPv6 did not work for 2.4 kernels for more than
ONE YEAR because of this, then glibc 2.2 became available. I am not
willing to follow this shining example of "Linux brokenness" that is
still being laughed about by avid BSD followers.
I hereby volunteer to submit patches for all places where the kernel
headers are not RFC compliant. The kernel headers are actually
_intended_ to be used from user space, as kernel specific parts are
escaped using "#ifdef __KERNEL__" all over the place. What reason would
there be for this if the kernel headers were not used from user space?
Even when using glibc the kernel headers are included in most programs.
> Kernel headers and user headers are distinctly different namespaces,
> and you have pointed out only one of many places where we use
> different names/structures/etc. for some kernel networking headers
> vs. what userspace wants.
Then, with all due respect, those places should be fixed.
There is no excuse for sloppy code and sloppy interfaces. At any rate,
"don't use our code, then" is not a valid excuse in my humble opinion.
Felix
David S. Miller
>
> What choice do I have?
I didn't say anything about choice, I said "don't use kernel headers
for userspace". What part of it do you not understand.
It was decided long ago that keeping the kernel headers up to snuff
with "user space standard of the day" was not in our interests, so we
don't have "#if _POSIX == 19940XXX" type crap all over the kernel
headers.
In fact, in some headers the structures and names are purposely not
what userspace wants. In this way nobody is likely to get the ill
conception that they are meant in any way to be used by userspace.
Later,
David S. Miller
da...@redhat.com
Linus Torvalds
Felix von Leitner <lei...@fefe.de> wrote:
>Thus spake David S. Miller (da...@redhat.com):
>> > glibc works around this, but the diet libc uses the kernel headers and
>> > thus exports the wrong API to user land.
>> Don't user kernel headers for userspace.
>
>What choice do I have?
>Duplicate everything and then be out of sync when the specs change?
Yes.
Even more preferably - write user-space headers that have _only_ the
minimum amount of code in them. The kernel headers have a lot of cruft
that is kernel-only, and that means that if you compile user space using
them, your compiles will be slower than they should be.
The basic issue is that the kernel will _refuse_ to follow the
"namespace of the day" rules of C89, C99, POSIX, BSD, SuS, GNU .. the
list goes on. The kernel headers are not meant to be used in user space,
and will not have the strict namespace rules that a lot of standards
spend so much time playing with.
There aren't that many things that are actually useful in the kernel
headers anyway. Most of them (like the IPv6 stuff) are really specified
in other places in the first place.
Linus
Oliver Xymoron
> The basic issue is that the kernel will _refuse_ to follow the
> "namespace of the day" rules of C89, C99, POSIX, BSD, SuS, GNU .. the
> list goes on. The kernel headers are not meant to be used in user space,
> and will not have the strict namespace rules that a lot of standards
> spend so much time playing with.
Add something like this to linux/config.h in 2.5?
#if !defined(__KERNEL__) || !defined(__KERNEL_ME_HARDER__)
#warning "Using kernel headers in userspace apps is unsupported."
#warning "Don't come crying to us when it breaks."
#endif
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."