DragonFly kernel List (threaded) for 2003-11
Re: Userapi, Reflection
Matthew Dillon wrote:
Ah, ok. Now I understand. Let me throw another log onto the fire... 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.
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.
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.