Re: Virtualizing Console Resources

Hi,

David Jeske wrote:
>
> 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.

I remember that feeling :-) Anyway the best ideas always come after 2AM :-)

> 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 lot of this sounds very similar to the code Gavin Nichol's been working on
for MADO - I'd really like to see this done for the text consoles as well
though (please someone write a keyboard driver that can take different
keymaps - I'm quite used to transposing UK to US but it's a real pain).

> 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).

Well Andy and I discussed the performance a little when I rewrote the serial
mouse code to use the rs232 server. In practice the benefits of using the
specialised rs232 server and the simplification of the mouse code have made
this worthwhile. I suspect the same may be true for what you're sugesting.

FWIW I did a lot of performance analysis a couple of weeks back, but the
perf1 program in the 1.3.2 release should give a fair idea of the impact.
On my DX4-100 486 with no L2 cache I get a context switch time of 207 us, so
there's room for improvement (handling small messages efficiently would be
useful).

> 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)

One of the things Gavin's mentioned before is that by using this sort of
technique MADO will virtualise /dev/bitblt and thus run any app built to
drive bitblt direct.

                        Regards,
                        Dave
Received on Mon Dec 12 04:12:19 1994