[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD/usermode (Was: CVS commit: src)
> This all seems simple and elegant enough, but it does not (quite) work:
> A) It still requires a new system call on the outer kernel.
> *Perhaps* this could be avoided by using ptrace, which might
> be simpler with this approach because the rule is simple:
> just say no to all system calls.
> B) There is no way for the usermode userspace process to
> allocate memory. I don't really see a clean way to fix
ptrace can support this too. It can let sbrk/mmap through, but tell
the usermode kernel as it does so. Or it can consult with the usermode
kernel first, and then let them through in a possibly modified form.
> 2) Using ptrace to allow, but validate, sbrk and mmap
> arguments seems questionable at best. How would
> this interact with the NetBSD VM system in the
> usermode kernel?
"With difficulty". :) I am confident this could be dealt with; if
necessary, sbrk and mmap could be intercepted and turned into different
calls of some sort. SysV shm calls? mmap() of /proc/something?
I've long thought that something akin to SCM_RIGHTS should exist for
passing memory regions between unrelated processes. That would come in
extremely handy here. (But given how badly SCM_RIGHTS got botched, it
probably would end up exploding somehow.)
> 4) How exactly does the usermode kernel _end_ the
> usermode userspace processes in a clean way?
Use ptrace to force it to call exit(), and let the exit() call through
to the real kernel. Or just use PT_KILL.
> Working through it makes me really wonder whether there's _any_
> portable way to do this stuff.
Sure - by instruction-level emulation if naught else. (Not a great
way, but it certainly can work.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |