Kernel<->Userspace API issue

Kernel<->Userspace API issue

[Russell King]

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

Re: Kernel<->Userspace API issue

[H. Peter Anvin]

Followup to:  <20030418092755.A25177@flint.arm.linux.org.uk>
By author:    Russell King <rmk@arm.linux.org.uk>
In newsgroup: linux.dev.kernel
>
> 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.
> 

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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

Re: Kernel<->Userspace API issue

[Dr. David Alan Gilbert]

* Russell King (rmk@arm.linux.org.uk) 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/abi
> or 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   |_______/