[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151013151048.GQ8645@brightrain.aerifal.cx>
Date: Tue, 13 Oct 2015 11:10:49 -0400
From: Rich Felker <dalias@...ifal.cx>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: Rob Landley <rob@...dley.net>,
Aboriginal Linux <aboriginal@...ts.landley.net>,
musl <musl@...ts.openwall.com>
Subject: Re: Re: musl and kernel headers [was Re: system-images 1.4.2:
od is broken; bzip2 is missing]
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
