From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10721 Path: news.gmane.org!.POSTED!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: kernel header compatibility Date: Wed, 9 Nov 2016 20:28:32 -0500 Message-ID: <20161110012832.GA23888@nyan> References: <20161109011145.GA31880@nyan> <20161109013930.GI1555@brightrain.aerifal.cx> <20161109015423.GA1597@nyan> <20161109021456.GJ1555@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1478741661 25600 195.159.176.226 (10 Nov 2016 01:34:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Nov 2016 01:34:21 +0000 (UTC) User-Agent: Mutt/1.6.1 (2016-04-27) To: musl@lists.openwall.com Original-X-From: musl-return-10734-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 10 02:34:16 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 1c4eFi-0004gK-BY for gllmg-musl@m.gmane.org; Thu, 10 Nov 2016 02:34:06 +0100 Original-Received: (qmail 21590 invoked by uid 550); 10 Nov 2016 01:34:06 -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 21569 invoked from network); 10 Nov 2016 01:34:06 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20161109021456.GJ1555@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10721 Archived-At: Rich Felker wrote: > On Tue, Nov 08, 2016 at 08:54:23PM -0500, Felix Janda wrote: > > Rich Felker wrote: > > > On Tue, Nov 08, 2016 at 08:11:45PM -0500, Felix Janda wrote: > > > > The recent commit 04983f2272382af92eb8f8838964ff944fbb8258 (make > > > > netinet/in.h suppress clashing definitions from kernel headers) > > > > intends to address some of the conflicts between the kernel and musl > > > > libc headers. Namely it tries to allow the inclusion of kernel headers > > > > after libc header by defining __UAP_DEF_* macros. However this doesn't > > > > work because the relevant linux headers include , > > > > which unconditionally redefines the constants. For example > > > > > > Oh, how awful. I missed the whole bogus #else part after the #if > > > defined(__GLIBC__) block. > > > > > > > > #include > > > > #include > > > > > > > > leads to > > > > > > > > #define __UAPI_DEF_IN_ADDR 0 // from > > > > #define __UAPI_DEF_IN_ADDR 1 // from > > > > > > Conflicting defines should be an error already. > > > > Strangely gcc-6.2.0 just warns (and the warning is not displayed when > > it is in system headers). > > > > > > So we still get two conflicting definitions of struct in6_addr. > > > > > > > > > > > > By adding the hack "#define _LIBC_COMPAT_H" to , this > > > > particular example compiles. > > > > > > > > > > > > Maybe the kernel people can be convinced to add #ifdef guards around > > > > all of the (non glibc) __UAPI_* definitions in . > > > > > > I think they should, but I don't mind just suppressing the whole > > > header by defining _UAPI_LIBC_COMPAT_H if that works for all kernel > > > versions. It seems to; see: > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/libc-compat.h?id=cfd280c91253cc28e4919e349fa7a813b63e71e8 > > > > > > where the file was introduced. > > > > Note that for the actually installed kernel headers the "_UAPI" prefix > > is stripped from the include guard. For example "_UAPI__LINUX_KEYBOARD" > > becomes "__LINUX_KEYBOARD". > > > > Second, defining the include guard in would prevent > > from defining __UAPI_* constants for things > > actually missing from musl. For example, a recent would > > no longer define struct sockaddr_ipx when included after > > . > > Uhg. So there's really no fix except for the kernel to put #ifndef > around its definitions of individual macros, is there? I just noticed that glibc does not have #if !__UAPI_DEF_FOO guards despite the suggestions in . So they also don't seem to bother with making inclusion of libc headers after kernel headers safe. Because of this (no need to coordinate with glibc), it might be possible to fix the kernel to use the __UAPI macros in the opposite way (have a __UAPI_NODEF_FOO instead of __UAPI_DEF_FOO.) Then it would be possible to remove the #if !defined(GLIBC) case in . > Would you be willing to propose such a patch? I'd ack it. Yes. (I would sent to linux-devel@vger.kernel.org, and CC David Miller and the musl list.) Felix