DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Userapi, Reflection

From: Galen Sampson <galen_sampson@xxxxxxxxx>
Date: Mon, 03 Nov 2003 22:37:11 -0800
Cc: dillon@xxxxxxxxxxxxx

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

    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
    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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]