Userapi, Reflection

[Matthew Dillon]

:...
:    The non-native binary will trap to the kernel.  Its notion of how
:arguments should be arranged is going to occur.  If it thinks its system
:call arguments should be registers, they will be in registers.  If it
:thinks its system call arguments should be on the stack, they will be on
:the stack.  If a kernel receives one of these calls it shouldn't have to
:do anything but forward a trap frame to the user level process acting as
:a proxy.  This proxy will gather up the arguments from the frame into a
:system call message, and send it natively.
:
:How reflection might be used:
:    Reflection could be useful in the "gather up the arguments into a
:system call message" stage (a.k.a. emulation stage).  Reflection would
:be used here to generate the code that shims the arguments into a
:message.  Say linux 2.6 comes out and you would like to emulate it.  Say
:linux 2.6 adds a system call.  Instead of modifying the code of the
:proxy itself, you add the prototype to its configuration file, send
:SIGHUP, poof! The new system call is now supported for emulation.
:
:    Hopefully that is somewhat clear.  It may very well be the case that
:the emulation will need to do a series of things besides just gather
:arguments.  In this case it would not make much sense to use reflection
:because the proxy's configuration file would get complex, and you might
:as well write the code.  Also, system calls aren't added or modified all
:that often, and so once again it might not be worth it to add all of
:this complexity.  However, if the emulation is generic enough, then it
:might be worth it.
:
:Regards,
:Galen

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>