Virtualizing Console Resources

I was just thinking over the whole "virtual console" thing and I came
up with another idea which I belive may be possible and desirable in
VSTa. Please give it a little leway, it's 4:47am, I could not sleep,
and I have an exam at 8am in the morning. I had to get this out of my
head or bust.

A virtual console server could provide a namespace via namer
where each "console" directory would contain a directory for each
"console driver" available.

For example, if you had a "kbd","mouse",and "vt100", the virtual console
would provide multiplexed version of these devices as con1/kbd, con1/mouse,
con1/vt100 as well as con2/kbd,con2/mouse,con2/vt100 (and so on). In this
way, any devices present could be made virtual without changes to the
virtual driver. (I'm presuming that there is a way to easily lookup names
in the namer, and that the virtual driver could just lookup a specific
directory in the namer where console devices would be put and then mimic
these devices repeatedly for each "con#" directory. If this is incorrect,
please point this out, as I have not investigated it specifically.)

A glaring advantage of this situation is that it becomes incredibly easy
to merely mount con# into the "union" /dev/ of a person's private namespace.
In that way, applications run in a client namespace will have easy access
to the traditional /dev/mouse, /dev/console (/dev/vt100 in my above case),
/dev/kbd (well, this is normally /dev/console too I suppose, this is
more to make a point) unknowing that they are multiplexed. There is no
added complication burdened onto the indivual drivers.

A glaring disadvantage, it just looks like it would incur lots of overhead.
A keyboard stroke would have to go through 2 message passes before it
ends up at a user level. Likewise for all strictly message pass resources.
Is this an overburden? I'm not sure, I don't know how the performance
numbers stack up. It probably would be less of a burden if the kernel
has code to make efficient small message passes via copy instead of remap.
(Andy talked about this in one of his previous mailing list mesages).

Forgive me if this is totally off the wall.. I was trying to think of
a way to better the unix system way of fighting over /devs when using virtual
console type setups, as well as providing an easy support for virtualized
server based graphical services. (i.e. as an example, /dev/bitblit should
be able to be virtualized through this type of setup as well)

Thoughts?

-- 
jeske_at_uiuc.edu    + David Jeske(N9LCA)<A HREF="http://www.cen.uiuc.edu/~jeske/">
NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008
    User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) </A>