Linux kernel headers violate RFC2553

glibc works around this, but the diet libc uses the kernel headers and 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

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
[email protected]

Thus spake David S. Miller ([email protected]):

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.

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

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
[email protected]

In article <[email protected]>,

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

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.."