Kernel<->Userspace API issue

Russell King (rmk@arm.linux.org.uk)
Fri, 18 Apr 2003 09:27:55 +0100


A problem has recently been reported on the ARM lists regarding RT signal
handling. It appears that there is an issue between glibc and the kernel,
in that glibc has a different idea of the layout of structures passed
from the kernel than the kernel itself.

I think this is a case in point that our policy on "userspace must not
include kernel headers" is completely wrong when it comes to user
space interfaces. I believe we need is a clear set of defined user
space interface headers which contain the definition of structures and
numbers shared between user space and kernel space. ie, include/abi
or some such.

No, glibckernheaders (or whatever it is) is NOT the solution - that
just creates yet another set of header files to potentially go out
of sync.

Comments?

On Thu, Apr 17, 2003 at 10:23:51PM -0400, Josh Fryman wrote:
> any insights? is this an implementation issue, program error, or am i
> missing some arm-centric trick? or am i just stupid and doing something
> completely wrong?

Sigh. glibc seems to have a bug. This is the kernel's idea of ucontext:

struct ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct sigcontext uc_mcontext;
sigset_t uc_sigmask; /* mask last for extensibility */
};

and glibc's idea:

typedef struct ucontext
{
unsigned long int uc_flags;
struct ucontext *uc_link;
__sigset_t uc_sigmask;
stack_t uc_stack;
mcontext_t uc_mcontext;
long int uc_filler[5];
} ucontext_t;

God knows where glibc got this from - it hasn't changed certainly since
2.2 kernels. I suspect glibc has been wrong for some time.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/