[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50F95DF3.7080602@redhat.com>
Date: Fri, 18 Jan 2013 14:36:35 +0000
From: Pedro Alves <palves@...hat.com>
To: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
CC: "Carlos O'Donell" <carlos@...temhalted.org>,
Mike Frysinger <vapier@...too.org>,
David Miller <davem@...emloft.net>, libc-alpha@...rceware.org,
bhutchings@...arflare.com, amwang@...hat.com, tmb@...eia.org,
eblake@...hat.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, libvirt-list@...hat.com,
tgraf@...g.ch, schwab@...e.de
Subject: Re: 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.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists