Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

On 01/18/2013 02:24 PM, YOSHIFUJI Hideaki wrote: >>>> 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? Include the glibc header first? Or is this some other use case? The point wasn't that you'd have only one macro for all structs/enums (you could split into __IPV6_IN6_ADDR_DEFINED, __IPV6_SOCKADDR_IN6_DEFINED, etc.) but to have the kernel and libc agree on guard macros, instead of having the kernel do #ifdef __GLIBC__ and glibc doing #ifdef _NETINET_IN_H. But as Carlos says, the devil is in the details, and I sure am not qualified on the details here.