> > Presumably your user-mode kernel would want to run binaries
> > for the same arch it was built for, and have a way to reroute
> > syscalls to the pseudo-kernel rather than the real kernel.
>
> PTRACE_SYSCALL. annul the syscall. do what you want to the target
> process.
Ooh, I like it. A second program could work as a proxy, making the syscall
look more 'normal' to the user-mode kernel. Replace copy_from_user, etc.,
with the ptrace equivalents in arch/userspace.
> > Worse yet, I see no obvious way for this 'user-mode' kernel to do
> > the necessary memory remapping it would need for its processes.
> > Being run inside of the same real process, they would have the
> > same view on memory.
>
> In my view of the world, every process would be a direct child of
> the user-mode kernel (UMK). The UMK would handle the pseudo-parent-
> and-child relationships by proxy'ing syscalls such as wait and
> ptrace.
That helps with the problem of memory maps, but it has the downside that
the real kernel wants to do things like scheduling. Can the ptrace
interface let us interrupt a task when a "timer interrupt" occurs?
> I have no clue how to handle things like device drivers, but I have
> some of the puzzle pieces for the syscall filtering layer for a UMK.
I assume you mean the kernel-hardware side and not the user-kernel side
(which is handled as soon as you have the syscall proxying in place).
This part is relatively easy, I think. It's an app. It's allowed to open
files. Have a file with a UMK to real device mapping, including mapping
block devices to real drives or files and you're in good shape. If we want
to go further and give real access to hardware, which might be useful when
debugging a new driver, I/O is easy, user-DMA is being worked on, and
interrupts could conceivably been down with downcalls (ew) or wacky signal
semantics, though neither would fit the normal definitions of "fast". Fast
here is probably not terribly important, since we're in a debugging
environment.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/