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: Andreas Jaeger <aj at suse dot com>
- Cc: Cong Wang <amwang at redhat dot com>, 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: Fri, 16 Aug 2013 11:44:35 -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> <520E461B dot 8040406 at suse dot com>
On 08/16/2013 11:32 AM, Andreas Jaeger wrote:
> On 08/15/2013 11:28 AM, Cong Wang wrote:
>> From: Carlos O'Donell <email@example.com>
>> - Synchronize linux's `include/uapi/linux/in6.h'
>> with glibc's `inet/netinet/in.h'.
>> - Synchronize glibc's `inet/netinet/in.h with linux's
>> - Allow including the headers in either other.
>> - First header included defines the structures and macros.
> Let me first say that I really love where this is going and would love
> to see more of this work.
The plan would be to eventually tackle more of the conflicting headers
in a uniform way.
> Will this work with older kernels as well? Meaning: Can I compile
> today's user land programs with a new glibc and Kernel 3.10? My reading
> of the patch assumes it does but I would like to hear that you tested it.
You can indeed take a new glibc, and a new kernel, and old programs
that previously failed to compile will now work. The ABI is maintained
and the headers coordinate.
I did not test this explicitly except through the small test case
I wrote which permutes inclusion order and the use of various
structures defined in the headers.
The only quibble one could have is with Linux. In that if you
include the Linux headers first you will get more definitions than
required by POSIX e.g. s6_addr16 and s6_add32. However as I note
in the comment this is not a violation of POSIX since POSIX says
"at least the following member" and that holds true.
> The patch itself looks fine, thanks,
Thanks for reviewing.
If the kernel patches get accepted I will check these into
glibc 2.19 for Cong.