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/