Re: The time has come for a kernel interfacing library layer

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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

    Well, if we go the cerror() route for the compatibility layer, that
    means this layer cannot just be mapped but instead must run through
    a relocation / ELF pass.

    We have one advantage here and that is that the userland program will
    have space reserved in the section code so, in fact, the userland
    program could *theoretically* do the relocations necessary to support
    cerror() itself, and then when we mmap() the actual compatibility
    layer we would simply retain those relocations.   

    In order for that to work the relocations would have to all be in one
    fixed section of code that can be copied out and copied back.  This will
    also cause another page to be COW'd for both static and dynamic binaries.

    I'm kinda on the fence here.  I like the cerror() idea, but I hate the
    fact that we then have to COW pages in the compat layer.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>