> 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. Well...sort of. > B) There is no way for the usermode userspace process to > allocate memory. I don't really see a clean way to fix > this: 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B