From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8660 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] Date: Tue, 13 Oct 2015 16:53:35 +0200 Message-ID: <20151013145335.GQ10551@port70.net> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1444748040 14757 80.91.229.3 (13 Oct 2015 14:54:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 14:54:00 +0000 (UTC) Cc: Rich Felker , Rob Landley , Aboriginal Linux To: musl@lists.openwall.com Original-X-From: musl-return-8672-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 13 16:53:50 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Zm0xY-0002WW-T1 for gllmg-musl@m.gmane.org; Tue, 13 Oct 2015 16:53:48 +0200 Original-Received: (qmail 23788 invoked by uid 550); 13 Oct 2015 14:53:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23770 invoked from network); 13 Oct 2015 14:53:46 -0000 Mail-Followup-To: musl@lists.openwall.com, Rich Felker , Rob Landley , Aboriginal Linux Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:8660 Archived-At: * Denys Vlasenko [2015-10-13 14:10:24 +0200]: > On Fri, Oct 9, 2015 at 9:46 PM, Rich Felker wrote: > >> Looking at kernel's libc-compat.h, it looks like you can get away > >> with using __UAPI_DEF_foo's like this? > >> > >> > >> #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1 > >> /* kernel already defined the struct, do nothing */ > >> #else > >> struct sockaddr_in { > >> ... > >> }; > > > > This would address the case where the kernel header is included first, > > but it's not a case I or most of the musl community wants to support, > > because there's no guarantee that the kernel's definitions of these > > structures will actually be compatible with use elsewhere in the libc > > headers, etc. > > If kernel's definition does not match yours, there is a much > bigger problem than "includes do not compile": > kernel and userspace definitions of these structs *must* match > (modulo harmless things like different typedef names for field types). > > So in this case either kernel or libc would need to be fixed. > why? in practice most types are c abi compatible with the kernel because translating the types at the syscall boundary is painful/impossible. but even with compatible binary representation there is plenty space for disagreement between kernel and libc on the source level. (of course code that includes both libc and kernel headers might not care about posix namespace violations or undefined behaviour in kernel headers..) and libc-compat does not cover all conflicting cases (i assume they just add workarouds when somebody hits a conflict), e.g. sys/inotify.h and linux/inotify.h are in conflict (and linux/inotify.h is not even standard c).