From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8662 Path: news.gmane.org!not-for-mail From: Rich Felker 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 11:10:49 -0400 Message-ID: <20151013151048.GQ8645@brightrain.aerifal.cx> 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 1444749078 32187 80.91.229.3 (13 Oct 2015 15:11:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 15:11:18 +0000 (UTC) Cc: Rob Landley , Aboriginal Linux , musl To: Denys Vlasenko Original-X-From: musl-return-8674-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 13 17:11:17 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 1Zm1EJ-00033c-C5 for gllmg-musl@m.gmane.org; Tue, 13 Oct 2015 17:11:07 +0200 Original-Received: (qmail 9228 invoked by uid 550); 13 Oct 2015 15:11:05 -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 8177 invoked from network); 13 Oct 2015 15:11:04 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:8662 Archived-At: On Tue, Oct 13, 2015 at 02:10:24PM +0200, Denys Vlasenko wrote: > > The other direction, suppressing kernel headers' definition of the > > structs, is what we want to work, but they've restricted their logic > > for that to only work when __GLIBC__ is defined. :( > > Yes, you will have to do by hand the thing which kernel > automagically does for glibc - namely, define to 0: > > >> #undef __UAPI_DEF_SOCKADDR_IN > >> /* tell kernel to not define the struct */ > >> #define __UAPI_DEF_SOCKADDR_IN 0 > >> #endif > > > We could do something like this but then we would need to keep up with > > the list of all the __UAPI defines we need to suppress unwanted kernel > > definitions. > > Looking at libc-compat.h, this list is at the moment only about > 13 defines long: > > #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_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 Thanks for making the list! For the time being I don't think it would be too objectionable to simply define these in musl. Does anyone else have an opinion on it? > > What if we could get the kernel to change the #if defined(__GLIBC__) > > to #if defined(__GLIBC__) || defined(__UAPI_DONTNEED_DEFS) or similar, > > so that there would only be one macro we need to define, and the > > kernel would then use the same logic it uses with glibc to suppress > > all of these. > > Or ask kernel to remove "define to 0" glibc hack and ask glibc to > do its own job. Why one libc should have preferential treatment? Well they don't want regressions; changing this would make old versions of glibc break. Presumably before all this UAPI "cleanup" (I'm not sure it can really be called "clean" though) there was some other mechanism that prevented things from breaking when they were included with glibc. In any case current versions of glibc would be broken by a change now. This type of interdependency is part of why I think the whole thing (trying to make kernel headers for stuf that's already defined in libc usable from userspace) was a bad idea to begin with. > Or ask kernel to stop using structures with userspace names. > This should not be that hard: > > struct __kernel_sockaddr_in {...} > #if __KERNEL__ > # define sockaddr_in __kernel_sockaddr_in > #endif Yes but then some patchup would be needed for uClibc and other libcs that actually want the kernel to define the structs. This would work better if the #define was in the other direction: # define __kernel_sockaddr_in sockaddr_in and done _before_ declaration of the structure, so that the actual struct tag would end up being the desired name in this case (both for kernel-internal and for uClibc, etc. use). Rich