DragonFly kernel List (threaded) for 2003-11
RE: Userapi, Reflection
Maybe I'm misunderstanding, I don't understand why code needs to be in the
kernel. Why not just, at run-time, link in the appropriate
syscall-decoder/rewriter depending on the personality of the binary? New
syscalls for linux would just require updating
Also, Matt, when you're talking about 0x80 being a userspace interrupt,
would that require rewriting the binary, valgrind-style, or is there some
hardware trick that could be used, or is there some other way? My
understanding of x86 is that 0x80 always context-switches into the kernel,
but I am a novice in such matters.
From: Galen Sampson [mailto:galen_sampson@xxxxxxxxx]
Sent: Tuesday, November 04, 2003 1:37 AM
Subject: Re: Userapi, Reflection
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
> 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
> processes (read-only) as appropriate for the particular proxy being
> So the result is that the syscall personality modules could be
> 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.