Carlos O'Donell wrote:
On 01/18/2013 05:44 AM, Pedro Alves wrote:
On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger <vapier@gentoo.org> wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell <carlos@systemhalted.org> Date: Wed, 16 Jan 2013 21:15:03 -0500
+/* If a glibc-based userspace has already included in.h, then we will not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The + * ABI used by the kernel and by glibc match exactly. Neither the kernel + * nor glibc should break this ABI without coordination. + */ +#ifndef _NETINET_IN_H +
I think we should shoot for a non-glibc-centric solution.
I can't imagine that other libc's won't have the same exact problem with their netinet/in.h conflicting with the kernel's, redefining structures like in6_addr, that we'd want to provide a protection scheme for here as well.
yes, the kernel's use of __GLIBC__ in exported headers has already caused problems in the past. fortunately, it's been reduced down to just one case now (stat.h). let's not balloon it back up. -mike
I also see coda.h has grown a __GLIBC__ usage.
In the next revision of the patch I created a single libc-compat.h header which encompasses the logic for any libc that wants to coordinate with the kernel headers.
It's simple enough to move all of the __GLIBC__ uses into libc-compat.h, then you control userspace libc coordination from one file.
How about just deciding on a single macro/symbol both the kernel and libc (any libc that needs this) define? Something like both the kernel and userland doing:
#ifndef __IPV6_BITS_DEFINED #define __IPV6_BITS_DEFINED ... define in6_addr, sockaddr_in6, ipv6_mreq, whatnot #endif
Hmm, how should we handle future structs/enums then? For example, if I want to have in6_flowlabel_req{} defined in glibc, what should we do? We probably want to have __LIBC_HAS_STRUCT_IN6_FLOWLABEL_REQ defined. --yoshfuji