From: Pedro Alves <palves@redhat.com>
To: "Carlos O'Donell" <carlos@systemhalted.org>
Cc: Mike Frysinger <vapier@gentoo.org>,
David Miller <davem@davemloft.net>,
libc-alpha@sourceware.org, bhutchings@solarflare.com,
yoshfuji@linux-ipv6.org, amwang@redhat.com, tmb@mageia.org,
eblake@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, libvirt-list@redhat.com,
tgraf@suug.ch, schwab@suse.de
Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
Date: Fri, 18 Jan 2013 10:44:53 +0000 [thread overview]
Message-ID: <50F927A5.5060409@redhat.com> (raw)
In-Reply-To: <CAE2sS1jMhnRcoo1oe7wQ+SP=40u9mkps6vXua8TQQ4Tbf2qKOQ@mail.gmail.com>
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
So whichever the application includes first, wins.
Too naive? I didn't see this option being discarded, so
not sure it was considered.
--
Pedro Alves
next prev parent reply other threads:[~2013-01-18 10:46 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-13 18:38 if_bridge.h: include in6.h for struct in6_addr use Thomas Backlund
2013-01-13 20:05 ` Thomas Backlund
2013-01-14 23:57 ` [libvirt] " Eric Blake
2013-01-15 10:03 ` the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi (was: Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use) Thomas Backlund
2013-01-15 10:03 ` [libvirt] the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi (was: " Thomas Backlund
2013-01-15 10:11 ` the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi (was: Re: [libvirt] " Cong Wang
2013-01-15 10:55 ` the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi Thomas Backlund
2013-01-16 5:51 ` Cong Wang
2013-01-16 6:06 ` Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h> Cong Wang
2013-01-16 14:21 ` YOSHIFUJI Hideaki
2013-01-16 15:47 ` Ben Hutchings
2013-01-16 17:04 ` Mike Frysinger
2013-01-16 17:10 ` Ben Hutchings
2013-01-16 17:28 ` Mike Frysinger
2013-01-16 18:59 ` David Miller
2013-01-16 19:22 ` Mike Frysinger
2013-01-16 19:25 ` David Miller
2013-01-17 3:40 ` Cong Wang
2013-01-17 3:55 ` [libvirt] " Jike Song
2013-01-17 6:59 ` Cong Wang
2013-01-17 7:02 ` Cong Wang
2013-01-16 18:57 ` David Miller
2013-01-16 19:29 ` Mike Frysinger
2013-01-17 2:15 ` Carlos O'Donell
2013-01-17 3:10 ` YOSHIFUJI Hideaki
2013-01-17 3:15 ` David Miller
2013-01-18 4:20 ` Mike Frysinger
2013-01-18 4:22 ` Carlos O'Donell
2013-01-18 4:34 ` Mike Frysinger
2013-01-18 10:44 ` Pedro Alves [this message]
2013-01-18 13:35 ` Carlos O'Donell
2013-01-18 14:24 ` YOSHIFUJI Hideaki
2013-01-18 14:36 ` Pedro Alves
2013-01-18 14:54 ` Carlos O'Donell
2013-01-21 0:54 ` Mike Frysinger
2013-01-17 3:22 ` YOSHIFUJI Hideaki
2013-01-18 4:13 ` Carlos O'Donell
2013-01-16 21:45 ` David Miller
2013-01-17 1:58 ` Carlos O'Donell
2013-01-17 2:05 ` David Miller
2013-01-17 10:57 ` Jan Engelhardt
2013-01-18 4:14 ` Mike Frysinger
2013-01-18 4:55 ` David Miller
2013-01-18 5:27 ` Mike Frysinger
2013-03-13 15:17 ` [libvirt] if_bridge.h: include in6.h for struct in6_addr use Kumar Gala
2013-03-13 16:24 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50F927A5.5060409@redhat.com \
--to=palves@redhat.com \
--cc=amwang@redhat.com \
--cc=bhutchings@solarflare.com \
--cc=carlos@systemhalted.org \
--cc=davem@davemloft.net \
--cc=eblake@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=libvirt-list@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=schwab@suse.de \
--cc=tgraf@suug.ch \
--cc=tmb@mageia.org \
--cc=vapier@gentoo.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.