This is the mail archive of the
mailing list for the glibc project.
Re: [GLIBC Patch v2] inet: avoid redefinition of some structs in kernel
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Cong Wang <amwang at redhat dot com>
- Cc: netdev at vger dot kernel dot org, "David S. Miller" <davem at davemloft dot net>, Thomas Backlund <tmb at mageia dot org>, libc-alpha at sourceware dot org, YOSHIFUJI Hideaki <yoshfuji at linux-ipv6 dot org>
- Date: Mon, 19 Aug 2013 14:11:09 -0400
- Subject: Re: [GLIBC Patch v2] inet: avoid redefinition of some structs in kernel
- References: <1376558891-26221-1-git-send-email-amwang at redhat dot com> <1376558891-26221-2-git-send-email-amwang at redhat dot com> <520E4995 dot 5090101 at redhat dot com> <1376875250 dot 2742 dot 2 dot camel at cr0>
On 08/18/2013 09:20 PM, Cong Wang wrote:
> On Fri, 2013-08-16 at 11:47 -0400, Carlos O'Donell wrote:
>> On 08/15/2013 05:28 AM, Cong Wang wrote:
>>> 2013-08-13 Carlos O'Donell <email@example.com>
>>> Cong Wang <firstname.lastname@example.org>
>>> * sysdeps/unix/sysv/linux/bits/in.h
>>> [_UAPI_LINUX_IN6_H]: Define __USE_KERNEL_IPV6_DEFS.
>>> * inet/netinet/in.h: Move in_addr definition and bits/in.h inclusion
>>> before __USE_KERNEL_IPV6_DEFS uses.
>>> * inet/netinet/in.h [!__USE_KERNEL_IPV6_DEFS]: Define IPPROTO_MH, and
>>> [__USE_KERNEL_IPV6_DEFS]: Don't define any of IPPROTO_*, in6_addr,
>>> sockaddr_in6, or ipv6_mreq.
>> Given that this is a user visible change could you please file
>> a glibc bugzilla bug in sourceware so we can track the commit and so
>> that future users can reopen the bug to discuss any defects?
> Done, http://sourceware.org/bugzilla/show_bug.cgi?id=15850
>> Then you need to add the BZ# to the ChangeLog, and whomever
>> commits this for you will mark it fixed in the NEWS. We should
>> also write up a NEWS blurb for this since it's the first explicit
>> header coordination of it's kind and we should highlight that
>> so developers take note and help us coordinate more headers.
> Should I resend this patch with BZ# included?
No need. But the final ChangeLog should have the BZ# in it, and the
committer will add it to the NEWS list of bugs fixed in 2.19.