The time has come for a kernel interfacing library layer

[Joerg Sonnenberger]

On Sun, May 08, 2005 at 10:49:12AM -0700, Matthew Dillon wrote:
> :>     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 :)
> 
>     Remember, this layer is a userland layer... the errno mapping I'm
>     talking about only applies to DragonFly executables.  A linux
>     emulation or a FreeBSD emulation or other emulation would have to
>     operate by emulating the actual system calls.  I still want to do 
>     *that* in userland, but it basically requires doing an upcall back
>     into a conversion layer which then executes in userland, or alternatively
>     a virtualization of the system call interface (which is also possible).

The question is whether the handling of errno should be part of the syscall
interface contract between kernel [ / kernel interface library] and userland
or not. If we put that entirely into libc, we can use alternative
implementations e.g. of TLS without breaking anything. That's one of the
reasons I'd avoid making the rtld depend on TLS, the rest of the userland
can do pretty much arbitrary things with %gs and I could even think of
uses which make perfect sense [mplayer and similiar stuff comes to mind]. 

> :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.
> 
>     We can do that, but the problem is that if we reserve 64 bytes per system
>     call the ELF section is going to be fairly big (~28KB).  So if the
>     section contains real code, that would bloat all of our static binaries
>     by 28KB.

Symbol versioning can be used to select the necessary code for static
binaries, ideally 0 bytes of course. If we keep the idea of cerror, it
boils down to one additional jump, not more. The code could / should be
implemented in something like the GOT and not be made PIC if we want to
save some cycles.

[about size of mapping] Making it not too small is the only real option
we have if we don't force a lot of contraints on the output generated
e.g. by ld, which would also mean additional local hacks.

Joerg