using VM/386 to multiplex window sessions is rather like virtualising the Unix system call layer to allow several IP stacks. it seems just a little heavy-handed. there is actually little difference between multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned: mainly configuration and a few small policy differences.
I don't think he was suggesting a seperate DomU per user, but rather a seperate (virtual) graphics device per user. I think the xen approach will be to use the VNC protocol to provide access to DomU graphics. I don't see why multiple VNC's couldnt be supported.
the host owner (/dev/hostowner) owns all devices, including cap(3), which works well in existing use `as intended', but for non-overlapping shared use of a single-user terminal would probably require something to set hostowner when it switches to a given user's session.
Why not just change permissions on the various devices that a user would want to access (ie. mouse, video and audio). Or probably better -- just multiplex these and provide a virtual device. How hard would it be to make a generic multiplexer that took in a filesystem prototype file and then virtualized access to each of the devices for a number of children processes?
the more serious problem is that there isn't a good paint program.
Nor internet chess client ;-) Tim Newsham http://www.lava.net/~newsham/
