DragonFly kernel List (threaded) for 2005-05
Re: The time has come for a kernel interfacing library layer
:> 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
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.
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
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.