The time has come for a kernel interfacing library layer

[Matthew Dillon]

:>     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).

:>     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.

    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.

    I think a better way would be to have the kernel be responsible for 
    mapping over the section for anything it loads directly, and then MFC
    that mapping code to the 1.2.x-RELEASE kernel as well.   It would be
    fairly non-invasive... if the kernel doesn't see the section, it would
    not do the mapping.  The mapping itself would be trivial... just a
    direct mmap() of the file.

: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

    Since this is BSS space we are talking about, we can theoretically
    reserve a fairly large chunk of change for the extension.  e.g. like a
    megabyte.

    There are alternatives.  

    * We can separately mmap the extension.  This would require relocating
      the JMPs and I don't want to do that.

    * We can use the linker map to place this section at the end of the BSS
      area, and the kernel can just SBRK the required additional space. 
      That's a fairly aweful hack and I don't really want to do that either.

    I'm sure there other things that I haven't thought up of yet.

    Personally speaking, I don't mind reserving a megabyte or two of VA.
    We are going to want to have some reserved address space anyway for
    other things, such as shared memory for the userland signal critical 
    section.  We dont eat another page directory entry until we exceed 4MB
    so its basically free.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>