From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10640 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: [PATCH] support including linux inet headers if libc ones are included first Date: Tue, 18 Oct 2016 16:28:52 -0400 Message-ID: <20161018202852.GA20098@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" X-Trace: blaine.gmane.org 1476822571 14792 195.159.176.226 (18 Oct 2016 20:29:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 20:29:31 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10653-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 18 22:29:27 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bwb0V-0000zW-22 for gllmg-musl@m.gmane.org; Tue, 18 Oct 2016 22:29:07 +0200 Original-Received: (qmail 7977 invoked by uid 550); 18 Oct 2016 20:29:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7941 invoked from network); 18 Oct 2016 20:29:05 -0000 Content-Disposition: inline Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10640 Archived-At: --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'd like to apply something like the attached patch to fix the longstanding issue of kernel network headers conflicting with the libc ones. I know some people have patched this on the kernel side by removing the defined(__GLIBC__) check in linux/libc-compat.h, but that (1) pokes at libc internals, namely the inclusion-guard names, (2) pretends to work if the kernel headers are included first, but actually doesn't, and (3) they have glibc-specific logic for some of the ipv6 fields that are only optionally-exposed, whereas musl always exposes them (because they're in a reserved namespace). I have no interest in trying to support the case where the kernel headers were included first, since they may have all sorts of gratuitous problems we'd have to work around (and maintain workarounds for) in their definitions of the types. But simply suppressing the kernel headers' definitions of network types via reserved-namespace __UAPI_* macros seems reasonable. Comments? Rich --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="inet-uapi-compat.diff" diff --git a/include/netinet/in.h b/include/netinet/in.h index f6bb77b..0d4d04a 100644 --- a/include/netinet/in.h +++ b/include/netinet/in.h @@ -385,6 +385,21 @@ struct ip6_mtuinfo { #define IPV6_RTHDR_TYPE_0 0 +#define __UAPI_DEF_IN_ADDR 0 +#define __UAPI_DEF_IN_IPPROTO 0 +#define __UAPI_DEF_IN_PKTINFO 0 +#define __UAPI_DEF_IP_MREQ 0 +#define __UAPI_DEF_SOCKADDR_IN 0 +#define __UAPI_DEF_IN_CLASS 0 +#define __UAPI_DEF_IN6_ADDR 0 +#define __UAPI_DEF_IN6_ADDR_ALT 0 +#define __UAPI_DEF_SOCKADDR_IN6 0 +#define __UAPI_DEF_IPV6_MREQ 0 +#define __UAPI_DEF_IPPROTO_V6 0 +#define __UAPI_DEF_IPV6_OPTIONS 0 +#define __UAPI_DEF_IN6_PKTINFO 0 +#define __UAPI_DEF_IP6_MTUINFO 0 + #ifdef __cplusplus } #endif --7AUc2qLy4jB3hD7Z--