Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors
From: Carlos O'Donell <hidden>
Date: 2017-03-04 01:24:25
Also in:
linux-alpha, linux-arm-kernel, linux-mips, linux-s390, linuxppc-dev, lkml, sparclinux
On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin [off-list ref] wrote:
On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote:quoted
On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann [off-list ref] wrote:quoted
On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin [off-list ref] wrote:quoted
Include <stddef.h> (guarded by #ifndef __KERNEL__) to fix asm/signal.h userspace compilation errors like this: /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' size_t ss_size; As no uapi header provides a definition of size_t, inclusion of <stddef.h> seems to be the most conservative fix available.[...]quoted
quoted
I'm not sure if this is the best fix. We generally should not include one standard header from another standard header. Would it be possible to use __kernel_size_t instead of size_t?In glibc we handle this with special use of __need_size_t with GCC's provided stddef.h. For example glibc's signal.h does this: # define __need_size_t # include <stddef.h>Just to make it clear, do you suggest this approach for asm/signal.h as well?
The kernel is duplicating userspace headers in the UAPI implementation and running into exactly the same problems we have already solved in userspace. We currently have no better solution than the "__need_*" interface for avoiding the duplication of the type definitions and the problems that come with that. I am taking this up with senior glibc developers on libc-alpha to see if we have a better suggestion. If you give me 72 hours I'll either have a better suggestion or the acknowledgement that my suggestion is the best practical solution we have. Note that in a GNU userspace stddef.h here comes from gcc, which completes the implementation of the C development environment that provides the types you need. The use of "__need_size_t" is a collusion between the components of the implementation and use by the Linux kernel would mean expecting something specific to a GNU implementation. I might suggest you use include/uapi/linux/libc-compat.h in an attempt to abstract away the GNU-specific magic for getting just size_t from stddef.h. That way you have documented the places that other runtime authors need to fill out for things to work. Cheers, Carlos.