Userapi, Reflection

[Galen Sampson]

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