iproute2 & other software

iproute2 & other software

[Loganaden Velvindron]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi All,

Stephen (iproute2) sent me a mail telling me that he rejected my patch to
iproute2 for musl support:

1st reply:
"
I was waiting for others who had more to say on this.
Ok with providing small fixes, but can't really guarantee iproute to
work with other libraries.
"

& 2nd is :
"
Sorry, I have to reject this.
All include files in include/linux come from headers automatically
generated from upstream
Linux source. This is the only way to ensure long term ABI/API consistency
with kernel.

Either fix musl or submit patches to upstream kernel and get them merged.
"

Can we look into providing somekind of compatibility layer for header files
so that it's easier to get upstream projects like iproute2 to support musl ?

Kind regards,
//Logan
C-x-C-c

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

Re: iproute2 & other software

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]


> On Mar 2, 2016, at 11:19 AM, Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> Hi All,
> 
> Stephen (iproute2) sent me a mail telling me that he rejected my patch to iproute2 for musl support:
> 
> 1st reply:
> "
> I was waiting for others who had more to say on this.
> Ok with providing small fixes, but can't really guarantee iproute to
> work with other libraries.
> "
> 
> & 2nd is :
> "
> Sorry, I have to reject this.
> All include files in include/linux come from headers automatically generated from upstream
> Linux source. This is the only way to ensure long term ABI/API consistency
> with kernel.
> 
> Either fix musl or submit patches to upstream kernel and get them merged.
> “

Where is your patch.

> 
> Can we look into providing somekind of compatibility layer for header files so that it's easier to get upstream projects like iproute2 to support musl ?
> 
> Kind regards,
> //Logan
> C-x-C-c
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: iproute2 & other software

[Loganaden Velvindron]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Wed, Mar 2, 2016 at 8:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> > On Mar 2, 2016, at 11:19 AM, Loganaden Velvindron <loganaden@gmail.com>
> wrote:
> >
> > Hi All,
> >
> > Stephen (iproute2) sent me a mail telling me that he rejected my patch
> to iproute2 for musl support:
> >
> > 1st reply:
> > "
> > I was waiting for others who had more to say on this.
> > Ok with providing small fixes, but can't really guarantee iproute to
> > work with other libraries.
> > "
> >
> > & 2nd is :
> > "
> > Sorry, I have to reject this.
> > All include files in include/linux come from headers automatically
> generated from upstream
> > Linux source. This is the only way to ensure long term ABI/API
> consistency
> > with kernel.
> >
> > Either fix musl or submit patches to upstream kernel and get them merged.
> > “
>
> Where is your patch.
>
>
Rejected patch here:

https://patchwork.ozlabs.org/patch/586121/

[-- Attachment #2: Type: text/html, Size: 1593 bytes --]

Re: iproute2 & other software

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 1401 bytes --]


> On Mar 2, 2016, at 12:39 PM, Loganaden Velvindron <loganaden@gmail.com> wrote:
> 
> 
> 
> On Wed, Mar 2, 2016 at 8:37 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> 
> > On Mar 2, 2016, at 11:19 AM, Loganaden Velvindron <loganaden@gmail.com <mailto:loganaden@gmail.com>> wrote:
> >
> > Hi All,
> >
> > Stephen (iproute2) sent me a mail telling me that he rejected my patch to iproute2 for musl support:
> >
> > 1st reply:
> > "
> > I was waiting for others who had more to say on this.
> > Ok with providing small fixes, but can't really guarantee iproute to
> > work with other libraries.
> > "
> >
> > & 2nd is :
> > "
> > Sorry, I have to reject this.
> > All include files in include/linux come from headers automatically generated from upstream
> > Linux source. This is the only way to ensure long term ABI/API consistency
> > with kernel.
> >
> > Either fix musl or submit patches to upstream kernel and get them merged.
> > “
> 
> Where is your patch.
> 
> 
> Rejected patch here:
> 
> https://patchwork.ozlabs.org/patch/586121/ <https://patchwork.ozlabs.org/patch/586121/>
> 

The change needs a bit more description of the problem its trying to fix.
Concern is if it will still work with glibc or uclibc on linux
one way you could keep functionality same for existing libcs
is to ifdef these files with #ifdef __GLIBC__

[-- Attachment #1.2: Type: text/html, Size: 2722 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: iproute2 & other software

[Rich Felker]

On Wed, Mar 02, 2016 at 12:44:51PM -0800, Khem Raj wrote:
> 
> > On Mar 2, 2016, at 12:39 PM, Loganaden Velvindron <loganaden@gmail.com> wrote:
> > 
> > 
> > 
> > On Wed, Mar 2, 2016 at 8:37 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> > 
> > > On Mar 2, 2016, at 11:19 AM, Loganaden Velvindron <loganaden@gmail.com <mailto:loganaden@gmail.com>> wrote:
> > >
> > > Hi All,
> > >
> > > Stephen (iproute2) sent me a mail telling me that he rejected my patch to iproute2 for musl support:
> > >
> > > 1st reply:
> > > "
> > > I was waiting for others who had more to say on this.
> > > Ok with providing small fixes, but can't really guarantee iproute to
> > > work with other libraries.
> > > "
> > >
> > > & 2nd is :
> > > "
> > > Sorry, I have to reject this.
> > > All include files in include/linux come from headers automatically generated from upstream
> > > Linux source. This is the only way to ensure long term ABI/API consistency
> > > with kernel.
> > >
> > > Either fix musl or submit patches to upstream kernel and get them merged.
> > > “
> > 
> > Where is your patch.
> > 
> > 
> > Rejected patch here:
> > 
> > https://patchwork.ozlabs.org/patch/586121/ <https://patchwork.ozlabs.org/patch/586121/>
> > 
> 
> The change needs a bit more description of the problem its trying to fix.
> Concern is if it will still work with glibc or uclibc on linux
> one way you could keep functionality same for existing libcs
> is to ifdef these files with #ifdef __GLIBC__

Indeed, I don't think the patch makes sense as submitted. MAXPATHLEN
is a deprecated, nonstandard form of PATH_MAX and should not be used
at all; adding #include <sys/param.h>, a messy legacy header with a
hodgepodge of junk in it, is making the codebase worse rather than
better.

Removing #include <linux/in.h> and #include <linux/in6.h> is probably
correct, but you should check and explain that all the types used from
these headers are already defined by standard headers (netinet/in.h?)
and that including the redundant Linux headers at best creates a risk
of conflict and if nothing else is useless.

Rich

Re: iproute2 & other software

[Szabolcs Nagy]

* Loganaden Velvindron <loganaden@gmail.com> [2016-03-02 19:19:13 +0000]:
> "
> Sorry, I have to reject this.
> All include files in include/linux come from headers automatically
> generated from upstream
> Linux source. This is the only way to ensure long term ABI/API consistency
> with kernel.
> 
> Either fix musl or submit patches to upstream kernel and get them merged.
> "
> 
> Can we look into providing somekind of compatibility layer for header files
> so that it's easier to get upstream projects like iproute2 to support musl ?
> 

in theory the correct solution is to fix the kernel headers
so they don't collide with posix types in libc headers.

in practice old kernel headers should work too and it's unlikely
that a complete uapi fix would be accepted into linux any time
soon so applications should avoid including both libc and kernel
headers into the same tu.

unfortunately glibc added workarounds into libc and uapi headers
that make it seem as if mixing linux and libc headers work, so
now application programmers don't have the incentive to fix this.

musl cannot use the same workarounds because they use ifdef __GLIBC__
(which is a major bug for linux uapi headers to depend on):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h

Re: iproute2 & other software

[Rich Felker]

On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote:
> * Loganaden Velvindron <loganaden@gmail.com> [2016-03-02 19:19:13 +0000]:
> > "
> > Sorry, I have to reject this.
> > All include files in include/linux come from headers automatically
> > generated from upstream
> > Linux source. This is the only way to ensure long term ABI/API consistency
> > with kernel.
> > 
> > Either fix musl or submit patches to upstream kernel and get them merged.
> > "
> > 
> > Can we look into providing somekind of compatibility layer for header files
> > so that it's easier to get upstream projects like iproute2 to support musl ?
> > 
> 
> in theory the correct solution is to fix the kernel headers
> so they don't collide with posix types in libc headers.
> 
> in practice old kernel headers should work too and it's unlikely
> that a complete uapi fix would be accepted into linux any time
> soon so applications should avoid including both libc and kernel
> headers into the same tu.
> 
> unfortunately glibc added workarounds into libc and uapi headers
> that make it seem as if mixing linux and libc headers work, so
> now application programmers don't have the incentive to fix this.
> 
> musl cannot use the same workarounds because they use ifdef __GLIBC__
> (which is a major bug for linux uapi headers to depend on):
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h

Would it help for us to define the __UAPI_DEF_* macros? If so I'd be
happy to look at a patch doing that. I don't think we should honor
them for suppressing definitions in libc (i.e. for supporting
inclusion of uapi headers _before_ libc ones) but it seems like we
could support inclusion of the uapi headers _after_ libc ones by doing
this with very little effort or maintenance cost.

Rich

Re: iproute2 & other software

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2016-03-02 18:30:50 -0500]:
> On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote:
> > * Loganaden Velvindron <loganaden@gmail.com> [2016-03-02 19:19:13 +0000]:
> > > "
> > > Sorry, I have to reject this.
> > > All include files in include/linux come from headers automatically
> > > generated from upstream
> > > Linux source. This is the only way to ensure long term ABI/API consistency
> > > with kernel.
> > > 
> > > Either fix musl or submit patches to upstream kernel and get them merged.
> > > "
> > > 
> > > Can we look into providing somekind of compatibility layer for header files
> > > so that it's easier to get upstream projects like iproute2 to support musl ?
> > > 
> > 
> > in theory the correct solution is to fix the kernel headers
> > so they don't collide with posix types in libc headers.
> > 
> > in practice old kernel headers should work too and it's unlikely
> > that a complete uapi fix would be accepted into linux any time
> > soon so applications should avoid including both libc and kernel
> > headers into the same tu.
> > 
> > unfortunately glibc added workarounds into libc and uapi headers
> > that make it seem as if mixing linux and libc headers work, so
> > now application programmers don't have the incentive to fix this.
> > 
> > musl cannot use the same workarounds because they use ifdef __GLIBC__
> > (which is a major bug for linux uapi headers to depend on):
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h
> 
> Would it help for us to define the __UAPI_DEF_* macros? If so I'd be

no, because they are defined unconditionally in libc-compat.h,
however we could define _UAPI_LIBC_COMPAT_H to make the conflicting
type definitions disappear.

but that is still fragile: any libc header would disable all
typedefs, while in glibc the checks are more fine grained.

we could also submit a linux patch to make the non-__GLIBC__
case more reasonable (e.g. check for existing definition of
the macros).

> happy to look at a patch doing that. I don't think we should honor
> them for suppressing definitions in libc (i.e. for supporting
> inclusion of uapi headers _before_ libc ones) but it seems like we
> could support inclusion of the uapi headers _after_ libc ones by doing
> this with very little effort or maintenance cost.
> 
> Rich

Re: iproute2 & other software

[Rich Felker]

On Thu, Mar 03, 2016 at 11:10:06AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2016-03-02 18:30:50 -0500]:
> > On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote:
> > > * Loganaden Velvindron <loganaden@gmail.com> [2016-03-02 19:19:13 +0000]:
> > > > "
> > > > Sorry, I have to reject this.
> > > > All include files in include/linux come from headers automatically
> > > > generated from upstream
> > > > Linux source. This is the only way to ensure long term ABI/API consistency
> > > > with kernel.
> > > > 
> > > > Either fix musl or submit patches to upstream kernel and get them merged.
> > > > "
> > > > 
> > > > Can we look into providing somekind of compatibility layer for header files
> > > > so that it's easier to get upstream projects like iproute2 to support musl ?
> > > > 
> > > 
> > > in theory the correct solution is to fix the kernel headers
> > > so they don't collide with posix types in libc headers.
> > > 
> > > in practice old kernel headers should work too and it's unlikely
> > > that a complete uapi fix would be accepted into linux any time
> > > soon so applications should avoid including both libc and kernel
> > > headers into the same tu.
> > > 
> > > unfortunately glibc added workarounds into libc and uapi headers
> > > that make it seem as if mixing linux and libc headers work, so
> > > now application programmers don't have the incentive to fix this.
> > > 
> > > musl cannot use the same workarounds because they use ifdef __GLIBC__
> > > (which is a major bug for linux uapi headers to depend on):
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h
> > 
> > Would it help for us to define the __UAPI_DEF_* macros? If so I'd be
> 
> no, because they are defined unconditionally in libc-compat.h,
> however we could define _UAPI_LIBC_COMPAT_H to make the conflicting
> type definitions disappear.
> 
> but that is still fragile: any libc header would disable all
> typedefs, while in glibc the checks are more fine grained.

That sounds viable (we never want _any_ kernel definitions that
conflict with standard ones) but I don't like the mechanism (poking at
their multiple-inclusion-guard macro). Likewise I don't like how
they're peeking at libc's private multiple-inclusion-guard macros.

> we could also submit a linux patch to make the non-__GLIBC__
> case more reasonable (e.g. check for existing definition of
> the macros).

I think that sounds more reasonable.

What would be ideal would be a macro we could define from features.h
or even stdc-predef.h that says "libc defines all the standard types;
we don't want kernel headers trying to define them", which the kernel
headers would honor via:

#ifdef _LIBC_DEFINES_STD_TYPES
#include <netinet/in.h>
#else
/* their own definitions */
#endif

but I suspect that would be controversial on the kernel side.

Rich

Re: iproute2 & other software

[Kylie McClain]

[-- Attachment #1: Type: text/plain, Size: 3416 bytes --]

On Thu, Mar 3, 2016 at 11:00 AM, Rich Felker <dalias@libc.org> wrote:
> On Thu, Mar 03, 2016 at 11:10:06AM +0100, Szabolcs Nagy wrote:
>> * Rich Felker <dalias@libc.org> [2016-03-02 18:30:50 -0500]:
>> > On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote:
>> > > * Loganaden Velvindron <loganaden@gmail.com> [2016-03-02 19:19:13 +0000]:
>> > > > "
>> > > > Sorry, I have to reject this.
>> > > > All include files in include/linux come from headers automatically
>> > > > generated from upstream
>> > > > Linux source. This is the only way to ensure long term ABI/API consistency
>> > > > with kernel.
>> > > >
>> > > > Either fix musl or submit patches to upstream kernel and get them merged.
>> > > > "
>> > > >
>> > > > Can we look into providing somekind of compatibility layer for header files
>> > > > so that it's easier to get upstream projects like iproute2 to support musl ?
>> > > >
>> > >
>> > > in theory the correct solution is to fix the kernel headers
>> > > so they don't collide with posix types in libc headers.
>> > >
>> > > in practice old kernel headers should work too and it's unlikely
>> > > that a complete uapi fix would be accepted into linux any time
>> > > soon so applications should avoid including both libc and kernel
>> > > headers into the same tu.
>> > >
>> > > unfortunately glibc added workarounds into libc and uapi headers
>> > > that make it seem as if mixing linux and libc headers work, so
>> > > now application programmers don't have the incentive to fix this.
>> > >
>> > > musl cannot use the same workarounds because they use ifdef __GLIBC__
>> > > (which is a major bug for linux uapi headers to depend on):
>> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h
>> >
>> > Would it help for us to define the __UAPI_DEF_* macros? If so I'd be
>>
>> no, because they are defined unconditionally in libc-compat.h,
>> however we could define _UAPI_LIBC_COMPAT_H to make the conflicting
>> type definitions disappear.
>>
>> but that is still fragile: any libc header would disable all
>> typedefs, while in glibc the checks are more fine grained.
>
> That sounds viable (we never want _any_ kernel definitions that
> conflict with standard ones) but I don't like the mechanism (poking at
> their multiple-inclusion-guard macro). Likewise I don't like how
> they're peeking at libc's private multiple-inclusion-guard macros.
>
>> we could also submit a linux patch to make the non-__GLIBC__
>> case more reasonable (e.g. check for existing definition of
>> the macros).
>
> I think that sounds more reasonable.
>
> What would be ideal would be a macro we could define from features.h
> or even stdc-predef.h that says "libc defines all the standard types;
> we don't want kernel headers trying to define them", which the kernel
> headers would honor via:
>
> #ifdef _LIBC_DEFINES_STD_TYPES
> #include <netinet/in.h>
> #else
> /* their own definitions */
> #endif
>
> but I suspect that would be controversial on the kernel side.
>
> Rich

I had patches to take care of this stuff in the kernel headers, I've just
been procrastinating sending them into the lkml, if anyone else feels like
handling this. I really don't want to deal with the lkml.

They were originally adapted from the patches that Sabotage, Void, Alpine, etc.
use for their headers, but they needed some updating for the latest git master.

[-- Attachment #2: 0001-libc-compat.h-set-definitions-only-if-kernel-is-undefined.patch --]
[-- Type: application/octet-stream, Size: 1897 bytes --]

From 6d2039ee6b8de23d47be95bc18d3b3ba3f75c0df Mon Sep 17 00:00:00 2001
From: Kylie McClain <somasis@exherbo.org>
Date: Wed, 20 Jan 2016 22:14:49 -0500
Subject: [PATCH] libc-compat.h: Set definitions only if __KERNEL__ is
 undefined

Rather than check if __GLIBC__ is defined, this uses a different method
of checking if the structs, etc. can be defined by instead checking for
a lack of __KERNEL__ being defined. Since __KERNEL__ is defined in kernel
things, we can use this check for the same effect as #ifdef __GLIBC__,
without having to put a dependency on the libc being used defining it,
as is the case with non-glibc libraries.

This patch was originally authored by
David Heidelberger <david.heidelberger@ixit.cz>, who I got permission from
to resubmit adapted for any changes since the time he submitted them.

Original patch: https://lkml.org/lkml/2014/3/14/274
---
 include/uapi/linux/libc-compat.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 7d024ce..cf92f97 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -48,8 +48,8 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H
 
-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We're used from userspace, */
+#ifndef __KERNEL__
 
 /* Coordinate with glibc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
@@ -115,7 +115,7 @@
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
  * that we need. */
-#else /* !defined(__GLIBC__) */
+#else /* __KERNEL__ */
 
 /* Definitions for in.h */
 #define __UAPI_DEF_IN_ADDR		1
@@ -138,6 +138,6 @@
 /* Definitions for xattr.h */
 #define __UAPI_DEF_XATTR		1
 
-#endif /* __GLIBC__ */
+#endif /* __KERNEL__ */
 
 #endif /* _UAPI_LIBC_COMPAT_H */

[-- Attachment #3: 0002-kernel.h-only-include-sysinfo.h-on-glibc.patch --]
[-- Type: application/octet-stream, Size: 1202 bytes --]

From 7e0edd566d7554fd4a2f30f32ca442854d22df93 Mon Sep 17 00:00:00 2001
From: Kylie McClain <somasis@exherbo.org>
Date: Wed, 20 Jan 2016 22:19:44 -0500
Subject: [PATCH] kernel.h: Only include sysinfo.h on glibc

Including sysinfo.h is unneeded on non-glibc libraries; on musl libc,
any header that uses kernel.h, and also uses sys/sysinfo.h will hit
redefinition errors of structs within sysinfo.h.

Rather than removing the inclusion, it is #ifdef'd away so that only
glibc uses it, in order to not break their headers.

This patch was originally authored by
David Heidelberger <david.heidelberger@ixit.cz>, who I got permission from
to resubmit adapted for any changes since the time he submitted them.

Original patch: https://lkml.org/lkml/2014/3/14/269
---
 include/uapi/linux/kernel.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/kernel.h b/include/uapi/linux/kernel.h
index 321e399..e8ff821 100644
--- a/include/uapi/linux/kernel.h
+++ b/include/uapi/linux/kernel.h
@@ -1,7 +1,9 @@
 #ifndef _UAPI_LINUX_KERNEL_H
 #define _UAPI_LINUX_KERNEL_H
 
+#ifdef __GLIBC__
 #include <linux/sysinfo.h>
+#endif
 
 /*
  * 'kernel.h' contains some often-used function prototypes etc

[-- Attachment #4: 0003-fix-struct-redefinition-errors-when-using-netinet-in.h.patch --]
[-- Type: application/octet-stream, Size: 3952 bytes --]

From 9c22ca92621c7527cf2aecd6dfb65c30a36aeeff Mon Sep 17 00:00:00 2001
From: Kylie McClain <somasis@exherbo.org>
Date: Wed, 20 Jan 2016 22:25:44 -0500
Subject: [PATCH] Fix struct redefinition errors when using netinet/in.h

When using non-glibc libraries, they may define their own structs in
netinet/in.h, which we also attempt to define.

For glibc, we define __UAPI_DEF_ETHHDR=1 so that it is allowed to use
the kernel headers' definition of the ethhdr struct. If not glibc, we
will define __UAPI_DEF_ETHHDR=0 so that if_ether.h's inclusion does
not attempt to redefine the ethhdr struct, which on non-glibc libraries
such as musl libc, are defined by the libc's netinet/in.h.

This patch was originally authored by
David Heidelberger <david.heidelberger@ixit.cz>, who I got permission from
to resubmit adapted for any changes since the time he submitted them.

Original patches:
https://lkml.org/lkml/2014/3/14/274 https://lkml.org/lkml/2014/3/14/266
---
 include/uapi/linux/if_ether.h    |  4 +++-
 include/uapi/linux/libc-compat.h | 24 +++++++++++-------------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index ea9221b..279c301 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -22,6 +22,7 @@
 #define _UAPI_LINUX_IF_ETHER_H
 
 #include <linux/types.h>
+#include <linux/libc-compat.h>
 
 /*
  *	IEEE 802.3 Ethernet magic constants.  The frame sizes omit the preamble
@@ -135,11 +136,12 @@
  *	This is an Ethernet frame header.
  */
 
+#if __UAPI_DEF_ETHHDR
 struct ethhdr {
 	unsigned char	h_dest[ETH_ALEN];	/* destination eth addr	*/
 	unsigned char	h_source[ETH_ALEN];	/* source ether addr	*/
 	__be16		h_proto;		/* packet type ID field	*/
 } __attribute__((packed));
-
+#endif
 
 #endif /* _UAPI_LINUX_IF_ETHER_H */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index cf92f97..8ca6895 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -51,10 +51,16 @@
 /* We're used from userspace, */
 #ifndef __KERNEL__
 
-/* Coordinate with glibc netinet/in.h header. */
+#ifdef _NETINET_IF_ETHER_H /* musl */
+#define __UAPI_DEF_ETHHDR 0
+#else /* glibc uses __NETINET_IF_ETHER_H, and includes the kernel header. */
+#define __UAPI_DEF_ETHHDR 1
+#endif
+
+/* Coordinate with libc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
 
-/* GLIBC headers included first so don't define anything
+/* libc headers included first so don't define anything
  * that would already be defined. */
 #define __UAPI_DEF_IN_ADDR		0
 #define __UAPI_DEF_IN_IPPROTO		0
@@ -64,15 +70,7 @@
 #define __UAPI_DEF_IN_CLASS		0
 
 #define __UAPI_DEF_IN6_ADDR		0
-/* The exception is the in6_addr macros which must be defined
- * if the glibc code didn't define them. This guard matches
- * the guard in glibc/inet/netinet/in.h which defines the
- * additional in6_addr macros e.g. s6_addr16, and s6_addr32. */
-#if defined(__USE_MISC) || defined (__USE_GNU)
 #define __UAPI_DEF_IN6_ADDR_ALT		0
-#else
-#define __UAPI_DEF_IN6_ADDR_ALT		1
-#endif
 #define __UAPI_DEF_SOCKADDR_IN6		0
 #define __UAPI_DEF_IPV6_MREQ		0
 #define __UAPI_DEF_IPPROTO_V6		0
@@ -80,10 +78,10 @@
 #define __UAPI_DEF_IN6_PKTINFO		0
 #define __UAPI_DEF_IP6_MTUINFO		0
 
-#else
+#else /* defined(_NETINET_IN_H) */
 
 /* Linux headers included first, and we must define everything
- * we need. The expectation is that glibc will check the
+ * we need. The expectation is that the libc will check the
  * __UAPI_DEF_* defines and adjust appropriately. */
 #define __UAPI_DEF_IN_ADDR		1
 #define __UAPI_DEF_IN_IPPROTO		1
@@ -93,7 +91,7 @@
 #define __UAPI_DEF_IN_CLASS		1
 
 #define __UAPI_DEF_IN6_ADDR		1
-/* We unconditionally define the in6_addr macros and glibc must
+/* We unconditionally define the in6_addr macros and libc must
  * coordinate. */
 #define __UAPI_DEF_IN6_ADDR_ALT		1
 #define __UAPI_DEF_SOCKADDR_IN6		1

[-- Attachment #5: 0004-fix-struct-redefinition-errors-when-using-netinet-tcp.h.patch --]
[-- Type: application/octet-stream, Size: 1704 bytes --]

From b21c598a396678831dc34baad800a940f883b3cd Mon Sep 17 00:00:00 2001
From: Kylie McClain <somasis@exherbo.org>
Date: Tue, 9 Feb 2016 18:58:55 -0500
Subject: [PATCH] Fix struct redefinition errors when using netinet/tcp.h

When using non-glibc libraries, they may define their own structs in
netinet/tcp.h, which we also attempt to define.

If not glibc, we will define __UAPI_DEF_TCPHDR=0 so that tcp.h's
inclusion does not attempt to redefine the tcphdr struct, which on
non-glibc libraries such as musl libc, are defined by the libc's netinet/tcp.h.
---
 include/uapi/linux/libc-compat.h | 6 ++++++
 include/uapi/linux/tcp.h         | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 8ca6895..f508429 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -57,6 +57,12 @@
 #define __UAPI_DEF_ETHHDR 1
 #endif
 
+#ifdef _NETINET_TCP_H /* musl */
+#define __UAPI_DEF_TCPHDR 0
+#else /* glibc uses _NETINET_TCP_H, but does not include the kernel header. */
+#define __UAPI_DEF_TCPHDR 1
+#endif
+
 /* Coordinate with libc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
 
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index 65a77b0..2cbd606 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -20,7 +20,9 @@
 #include <linux/types.h>
 #include <asm/byteorder.h>
 #include <linux/socket.h>
+#include <linux/libc-compat.h>
 
+#if __UAPI_DEF_TCPHDR
 struct tcphdr {
 	__be16	source;
 	__be16	dest;
@@ -55,6 +57,7 @@ struct tcphdr {
 	__sum16	check;
 	__be16	urg_ptr;
 };
+#endif
 
 /*
  *	The union cast uses a gcc extension to avoid aliasing problems

[-- Attachment #6: 0005-libc-compat.h-set-definitions-only-if-kernel-is-undefined.patch --]
[-- Type: application/octet-stream, Size: 1897 bytes --]

From 6d2039ee6b8de23d47be95bc18d3b3ba3f75c0df Mon Sep 17 00:00:00 2001
From: Kylie McClain <somasis@exherbo.org>
Date: Wed, 20 Jan 2016 22:14:49 -0500
Subject: [PATCH] libc-compat.h: Set definitions only if __KERNEL__ is
 undefined

Rather than check if __GLIBC__ is defined, this uses a different method
of checking if the structs, etc. can be defined by instead checking for
a lack of __KERNEL__ being defined. Since __KERNEL__ is defined in kernel
things, we can use this check for the same effect as #ifdef __GLIBC__,
without having to put a dependency on the libc being used defining it,
as is the case with non-glibc libraries.

This patch was originally authored by
David Heidelberger <david.heidelberger@ixit.cz>, who I got permission from
to resubmit adapted for any changes since the time he submitted them.

Original patch: https://lkml.org/lkml/2014/3/14/274
---
 include/uapi/linux/libc-compat.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 7d024ce..cf92f97 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -48,8 +48,8 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H
 
-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We're used from userspace, */
+#ifndef __KERNEL__
 
 /* Coordinate with glibc netinet/in.h header. */
 #if defined(_NETINET_IN_H)
@@ -115,7 +115,7 @@
 /* If we did not see any headers from any supported C libraries,
  * or we are being included in the kernel, then define everything
  * that we need. */
-#else /* !defined(__GLIBC__) */
+#else /* __KERNEL__ */
 
 /* Definitions for in.h */
 #define __UAPI_DEF_IN_ADDR		1
@@ -138,6 +138,6 @@
 /* Definitions for xattr.h */
 #define __UAPI_DEF_XATTR		1
 
-#endif /* __GLIBC__ */
+#endif /* __KERNEL__ */
 
 #endif /* _UAPI_LIBC_COMPAT_H */

Re: iproute2 & other software

[Szabolcs Nagy]

* Kylie McClain <somasissounds@gmail.com> [2016-03-03 11:12:09 -0500]:
> On Thu, Mar 3, 2016 at 11:00 AM, Rich Felker <dalias@libc.org> wrote:
> > On Thu, Mar 03, 2016 at 11:10:06AM +0100, Szabolcs Nagy wrote:
> >> * Rich Felker <dalias@libc.org> [2016-03-02 18:30:50 -0500]:
> >> > On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote:
> >> > > musl cannot use the same workarounds because they use ifdef __GLIBC__
> >> > > (which is a major bug for linux uapi headers to depend on):
> >> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h
> >> >
> >> > Would it help for us to define the __UAPI_DEF_* macros? If so I'd be
> >>
> >> no, because they are defined unconditionally in libc-compat.h,
> >> however we could define _UAPI_LIBC_COMPAT_H to make the conflicting
> >> type definitions disappear.
> >>
> >> but that is still fragile: any libc header would disable all
> >> typedefs, while in glibc the checks are more fine grained.
> >
> > That sounds viable (we never want _any_ kernel definitions that
> > conflict with standard ones) but I don't like the mechanism (poking at
> > their multiple-inclusion-guard macro). Likewise I don't like how
> > they're peeking at libc's private multiple-inclusion-guard macros.
> >
> >> we could also submit a linux patch to make the non-__GLIBC__
> >> case more reasonable (e.g. check for existing definition of
> >> the macros).
> >
> > I think that sounds more reasonable.
> >
> > What would be ideal would be a macro we could define from features.h
> > or even stdc-predef.h that says "libc defines all the standard types;
> > we don't want kernel headers trying to define them", which the kernel
> > headers would honor via:
> >
> > #ifdef _LIBC_DEFINES_STD_TYPES
> > #include <netinet/in.h>
> > #else
> > /* their own definitions */
> > #endif
> >
> > but I suspect that would be controversial on the kernel side.
> >
> > Rich
> 
> I had patches to take care of this stuff in the kernel headers, I've just
> been procrastinating sending them into the lkml, if anyone else feels like
> handling this. I really don't want to deal with the lkml.
> 

if you submit such patches please cc them to linux-api@vger.kernel.org
there is more chance to get meaningful discussion there.

(in general you might want to use scripts/get_maintainers.pl from the
kernel tree to make sure all interested parties see the patch, unfortunately
that does not handle linux-api list correctly, but that's the right place
for discussing such changes.)

> They were originally adapted from the patches that Sabotage, Void, Alpine, etc.
> use for their headers, but they needed some updating for the latest git master.


-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We're used from userspace, */
+#ifndef __KERNEL__

this change is not ok, they are trying to check whether
glibc or kernel headers were included first, not whether
user space or kernel space code is being compiled.

i think it is better to leave the glibc parts alone, because
then we need to coordinate with both the kernel and glibc.


btw openwall does not seem to archive binary attachments,
but gmail marked your patches as application/octet-stream,
may be you can change some setting (or change the file
extension) to get them archived.

Re: iproute2 & other software

[Rich Felker]

On Thu, Mar 03, 2016 at 06:01:24PM +0100, Szabolcs Nagy wrote:
> * Kylie McClain <somasissounds@gmail.com> [2016-03-03 11:12:09 -0500]:
> > On Thu, Mar 3, 2016 at 11:00 AM, Rich Felker <dalias@libc.org> wrote:
> > > On Thu, Mar 03, 2016 at 11:10:06AM +0100, Szabolcs Nagy wrote:
> > >> * Rich Felker <dalias@libc.org> [2016-03-02 18:30:50 -0500]:
> > >> > On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote:
> > >> > > musl cannot use the same workarounds because they use ifdef __GLIBC__
> > >> > > (which is a major bug for linux uapi headers to depend on):
> > >> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h
> > >> >
> > >> > Would it help for us to define the __UAPI_DEF_* macros? If so I'd be
> > >>
> > >> no, because they are defined unconditionally in libc-compat.h,
> > >> however we could define _UAPI_LIBC_COMPAT_H to make the conflicting
> > >> type definitions disappear.
> > >>
> > >> but that is still fragile: any libc header would disable all
> > >> typedefs, while in glibc the checks are more fine grained.
> > >
> > > That sounds viable (we never want _any_ kernel definitions that
> > > conflict with standard ones) but I don't like the mechanism (poking at
> > > their multiple-inclusion-guard macro). Likewise I don't like how
> > > they're peeking at libc's private multiple-inclusion-guard macros.
> > >
> > >> we could also submit a linux patch to make the non-__GLIBC__
> > >> case more reasonable (e.g. check for existing definition of
> > >> the macros).
> > >
> > > I think that sounds more reasonable.
> > >
> > > What would be ideal would be a macro we could define from features.h
> > > or even stdc-predef.h that says "libc defines all the standard types;
> > > we don't want kernel headers trying to define them", which the kernel
> > > headers would honor via:
> > >
> > > #ifdef _LIBC_DEFINES_STD_TYPES
> > > #include <netinet/in.h>
> > > #else
> > > /* their own definitions */
> > > #endif
> > >
> > > but I suspect that would be controversial on the kernel side.
> > >
> > > Rich
> > 
> > I had patches to take care of this stuff in the kernel headers, I've just
> > been procrastinating sending them into the lkml, if anyone else feels like
> > handling this. I really don't want to deal with the lkml.
> > 
> 
> if you submit such patches please cc them to linux-api@vger.kernel.org
> there is more chance to get meaningful discussion there.
> 
> (in general you might want to use scripts/get_maintainers.pl from the
> kernel tree to make sure all interested parties see the patch, unfortunately
> that does not handle linux-api list correctly, but that's the right place
> for discussing such changes.)
> 
> > They were originally adapted from the patches that Sabotage, Void, Alpine, etc.
> > use for their headers, but they needed some updating for the latest git master.
> 
> 
> -/* We have included glibc headers... */
> -#if defined(__GLIBC__)
> +/* We're used from userspace, */
> +#ifndef __KERNEL__
> 
> this change is not ok, they are trying to check whether
> glibc or kernel headers were included first, not whether
> user space or kernel space code is being compiled.
> 
> i think it is better to leave the glibc parts alone, because
> then we need to coordinate with both the kernel and glibc.

Yes, I'd like to second that I don't think these patches should be
submitted in their current form. They may be suitable for making the
headers work right on musl-based dists for now, but the changes to
preprocessor logic are not actually correct, and my guess is that
proposing something that we can't argue is correct (or at least is
best-possible) is going to hurt our chances of getting upstream
acceptance.

Rich