The time has come for a kernel interfacing library layer

[Joerg Sonnenberger]

On Sun, May 08, 2005 at 09:18:55AM -0700, Matthew Dillon wrote:
> 
> :>     Joerg, to make this work I need two other things:
> :> 
> :>     * We need to have the kernel automatically setup the initial TLS
> :>       space.
> :
> :Why? Do you want to completely eliminate the syscall wrappers from libc?
> :That's going to add problems later I fear. I'd instead change it the
> :interface between library layer and syscall functions in libc to always
> :provide a pointer to errno as argument. That would solve the problems
> :e.g. with RTLD too.
> :
> :Joerg
> 
>     I considered providing a poiner to errno, but it would mean changing
>     the int $0x80 algorithm which right now assumes that the arguments are
>     a certain offset relative to the call stack.

int $0x80 on the other hands put the output errno into a special register.
For normal system calls, this would mean one more copy of the arguments.
Actually, this would be the perfect point to move the sys message processing
to and eliminate the problems we currently have e.g. when passing 64bit
values in by value. The userland part would prepare the message as structure
and the kernel just do a copyin of the right size.

>     It's easier to simply require that a pointer to errno be stored in
>     the TLS (via i386/include/tls.h).

That would making using this abstraction mechanism e.g. for the linux
emulation impossible. That's a goal I'd like to keep and hopefully we
agree on that :)

>     Basically as far as libc or rtld is concerned, they simply link
>     against another library called 'libsys' (rtld gets its own, which we
>     make the one libc uses part of the crt link sequence).  This library
>     will contain the system calls in a specially-named section.  The
>     kernel will then remap the section as appropriate.  We have the option
>     of making the section a BSS section (so it takes up no space in the
>     actual linked program), or making the section a code section with real
>     'default' syscall entry points in it.

Adding another library is problematic for code which wants to static link
manually. Since we need a certain level of backwards compatibility anyway
in libc, it should be placed there.

One problem with making it an ELF section is the extensibility, what
if we run out of space? E.g. a shared library could not just use a
new syscall, when libc has run out of space in the section.

Joerg