DragonFly kernel List (threaded) for 2003-11
Re: Userapi, Reflection
: 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.
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
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
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
So the result is that the syscall personality modules could be upgraded
Is that what you are thinking? n' is a good term.