Userapi, Reflection

[Lewis, Todd]

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.

-----Original Message-----
From: Galen Sampson [mailto:galen_sampson at xxxxxxxxx] 
Sent: Tuesday, November 04, 2003 1:37 AM
Subject: Re: Userapi, Reflection


Matthew Dillon wrote:
>     Ah, ok.  Now I understand.  Let me throw another log onto the fire...
>     the proxy code we are talking about is like a pesonality module.  The
>     idea is for it to be managed by the kernel.
> 
>     Under the proxy system for IA32 I would make int 0x80 actually be a 
>     userspace interrupt that points to the proxy code rather then pop into
>     the kernel.
> 
>     This gives us a great deal of control over how we manage the proxy
code.
>     We could, in fact, change-out the proxy code on the fly, but I think
>     it would probably be safest to just change it out with regards to new
>     exec's.
> 
>     We wouldn't need a monitor program per-say.  If there is a prototype
>     file that is used to generate most proxy calls, similar to the way
>     our system calls are generated now, then instead of HUPing we would
>     simply run a DragonFly program which compiles the new proxy image and
>     'installs' it in the kernel.   The kernel would then map it to new
user
>     processes (read-only) as appropriate for the particular proxy being
>     requested.
> 
>     So the result is that the syscall personality modules could be
upgraded
>     without rebooting.
> 
>     Is that what you are thinking?  n' is a good term.
> 
    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 
into each process?).  It is "managed" by the kernel in that the kernel 
knows where in each process to put it, where (disk/memory) the original 
resides, and how to map a personality (possibly personality set) based 
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