[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK1hOcM9hiHAwo-7Tkkydz72-euMmkeL7GieRsQH3Luc4cZB9Q@mail.gmail.com>
Date: Tue, 13 Oct 2015 14:10:24 +0200
From: Denys Vlasenko <vda.linux@...glemail.com>
To: Rich Felker <dalias@...ifal.cx>
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 Fri, Oct 9, 2015 at 9:46 PM, Rich Felker <dalias@...ifal.cx> 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.
> 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
> 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?
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
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.
