Kernel<->Userspace API issue
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?
Quoted 3 lines · Josh Fryman
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.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Followup to: <[email protected]> By author: Russell King <[email protected]> In newsgroup: linux.dev.kernel
Quoted 13 lines
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/abior some such.
Quoted 4 lines
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.
This is basically the "ABI headers" issue I have been harping on about for some time. It's a sizable job, though, and a matter of finding someone to do it.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Quoted 6 lines · * Russell King ([email protected]) wrote:
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/abior some such.
Yes!!! For those of us who need (for various reasons) to work below the level of GLibc it is currently a nightmare trying to pick apart the calling conventions for each syscall.
Of course it is not only syscalls; but also signal numbering and other constants.
(Oh bonus points for sharing as much of this between architectures as possible and just having the differences in architecture specific files).
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/