Messages in this thread | | | Date | Mon, 5 Aug 2002 22:44:15 +0200 | From | Richard Zidlicky <> | Subject | Re: context switch vs. signal delivery [was: Re: Accelerating user mode |
| |
On Mon, Aug 05, 2002 at 03:46:07PM +0200, Udo A. Steinberg wrote: > On Sat, 03 Aug 2002 10:29:42 -0500 > Jeff Dike <jdike@karaya.com> wrote: > > > alan@redhat.com said: > > > the alternatives like a seperate process and ptrace are not pretty either > > I have implemented a usermode version of the Fiasco µ-kernel that uses > a seperate process for the kernel and one process for each task. The kernel > process attaches to all tasks via ptrace. > When the kernel wants to change the MM of a task it puts some trampoline code > on a page mapped into each task's address space and has the task execute that > code on behalf of the kernel. > With that setup we have complete address space protection without all the > trouble of jail at the expense of a few context switches for each mmap, munmap > or mprotect operation.
very interesting, what is the handiest way to do "syscalls" in this model? Ptrace is still basically signal driven so I would expect it has still some unnecessary overhead?
> I would also very much like an extension that would allow one process to modify > the MM of another, possibly via an extended ptrace interface or a new syscall. > Also it would be nice if there was an alternate way to get at the cr2 register, > trap number and error code other than from a SIGSEGV handler.
that's what signals are for, too bad they are slow.
> > Then, the current UML tracing thread would handle the kernel side of things > > and sit in its own address space nicely protected from its processes. > > Yes. I already have this part working for our kernel, so it's not just theory. > I believe things could run yet another bit faster if we didn't have to do the > trampoline map operations.
they are very expensive because of the way ptrace accesses the other process memory, did you try a piece of shared memory ?
Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |