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

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Jan 16, 2013 at 03:45:27PM -0500, David Miller wrote:
> From: Rich Felker <dalias@aerifal.cx>
> Date: Wed, 16 Jan 2013 15:42:12 -0500
> 
> > It's a bug for the kernel uapi headers to define any type, macro, or
> > structure tag that's supposed to be defined by libc.
> 
> But we've provided these types in the kernel headers for decades, and
> if we stop exporting them we equally risk breaking existing builds
> that are working properly.
> 
> So you can't just say, "get rid of the kernel header definitions of
> these things", that simply won't work.
> 
> Every "solution" proposed thus far breaks things for somebody, that's
> why this issue hasn't been addressed in any way yet.

Well the uapi header transition is supposed to be a chance for
cleaning up the historical mess, no? I don't claim this can be done
without breaking anything, but my experience has been that most
programs affected are already doing multiple things wrong. Perhaps
uapi should be split into two sets of headers:

1. Headers that define linux-specific stuff intended to be used
through direct interfaces with the kernel where no libc interaction is
involved.

2. Headers that define the kernel versions of the interfaces libc is
also responsible for.

Then, set 2 would be completely uninstalled for most people; it would
only be kept around for use by libc implementations that want to just
wrap the kernel headers. Set 1 would always be installed, and would be
the published API for kernel features.

Rich