>> * the kprocdev framework. all i/o into devip, devfs, and devdraw
>> is marshalled and handed off to a kproc running in a different
>> pthread, so that blocking i/o won't block the cpu0 pthread,
>> which is the only one that can run vx32. this means that
>>
> why can only one thread run vx32?
i think i found part of the answer just now. see the comment above
9vx/main.c:^setsigsegv
> * the kprocdev framework. all i/o into devip, devfs, and devdraw
> is marshalled and handed off to a kproc running in a different
> pthread, so that blocking i/o won't block the cpu0 pthread,
> which is the only one that can run vx32. this means that
> all
There's not likely anything in the guts of vx32 that hasn't been done
before. What's new is the fact that we managed to package it up in
a way that runs on a variety of out-of-the-box OS'es with
neither kernel modifications nor special privileges on any x86.
That portability is key to being able t
