RE: Userapi, Reflection

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Maybe I'm misunderstanding, I don't understand why code needs to be in the
:kernel.  Why not just, at run-time, link in the appropriate
:syscall-decoder/rewriter depending on the personality of the binary?  New
:syscalls for linux would just require updating
:/lib/libpersonality_linux.so...
:
:Also, Matt, when you're talking about 0x80 being a userspace interrupt,
:would that require rewriting the binary, valgrind-style, or is there some
:hardware trick that could be used, or is there some other way?  My
:understanding of x86 is that 0x80 always context-switches into the kernel,
:but I am a novice in such matters.

    int 0x80 is controlled by the interrupt descriptor table on x86.  The
    interrupt descriptor table is a kernel-managed array of interrupt
    vectors.   The target ring is controlled on an entry by entry basis so
    it should be fairly easy to simply make the target ring for int 0x80
    'userland', pointing to the personality code designated for that userland
    process.  The actual interface into the DFly kernel will be int 0x81,
    which is the syscall messaging interface.

:    I guess I wasn't quite sure what you meant by "managed by the 
:kernel".  I think I might be getting the idea now though.  There would 
:be a set of "personalities" the kernel knows about.  Each personality 
:cooresponds to a software platform dragonfly will emulate.  Perhaps you 
:could map in a set a personalities into a single process, 
:(POSIX_personailty, LINUX_personality) in an attemt at code reuse.  This 
:personality code is very similar to a dynamic library, except the kernel 
:will do that mapping on exec and within the kernel, not with ld.  Even a 
:static binary would get this code mapped in (as the kernel is mapped 
:into each process now..it is right?...if so why is the kernel mapped 

    Right.  The kernel would be responsible for mapping the personality
    module into the userland memory space.  The actual code would only be
    exeucted by userland.  The mapping would certainly be shared.  In IA32
    the kernel VM is, in fact, part of the user VM space (this is not true
    on other cpus), but the kernel VM space is not normally accessible to
    userland (segfault if you try to access it).  The personality mapping
    would be placed at the top of user memory, just above the stack.  It
    will probably be easiest for me to move the top of stack down a little
    to make room.

:on metadata stored in the binary being exec'd.
:    If you wanted to add emulation to dragonfly you would write the 
:personality, compile the personality, and "install" the personality into 
:the kernel.  "Installing" into the kernel would be providing the kernel 
:with the location of the peronality, and the necessary information to 
:map from binary executable metadata to the personality you are 
:installing.  When you change a personality, you would notify the kernel 
:of the change.   The next process that was exec'd would get this newly 
:modified/added peronality mapped in, while the others would continue to 
:operate as before (nothing would change for them at all).
:    Yes, I was thinking that it should be possible to update emulation 
:on a running system.  This obviously accompilshes that.
:
:Regards,
:Galen

    Exactly.  The personality could simply be stored in a file in /usr/lib,
    but it would like a 'fixed address' static binary or it would be like
    a KLD.  The kernel would be told where the personality file is and
    which personality it corresponds to.  There could be many files registered
    with the kernel in this manner.  The kernel would automatically map 
    the appropriate file to a fixed address in userspace for every program
    exec'd by the kernel.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>