gordoni@chook.ua.oz (Gordon Irlam) (03/16/90)
I have modified the Minix tty driver on the PC to support virtual
consoles, and have been running the modified version for a few months
now.
I will be posting the patches for this to comp.os.minix in around a
month's time. They will be posted relative to the Minix 1.5.5 kernel.
The patches will allow the IBM PC Minix 1.5.5 kernel sources to be
patched to allow multiple ttys to be associated with the system's
primary display and keyboard. At any time a single tty is associated
with the physical console. Keys are defined to allow the tty
currently associated with the physical console to be changed. The
number of virtual consoles is fixed and can only be altered by
recompiling the kernel and building a new boot disk.
Once you have installed the virtual console patches you will be able
to have multiple login sessions using the primary display and switch
between them using the function keys.
F5 is used to cycle from one virtual console to the next. This is
particularly convenient if you only have two virtual consoles as you
can use F5 to toggle between them.
The keys F1 through F4 are used to switch directly to any one of the
first 4 virtual consoles. If you have fewer than 4 virtual consoles
some of these keys will have no effect. The keys previously bound to
F1 through F3 are now bound to F6 through F8. F6 toggles the
scrolling mode, F7 lists the process table, and F8 lists the memory
map. This takes a bit of getting used to.
When you switch virtual consoles the previous virtual console is
hidden from view, but output can still be written to it, and programs
can still read characters that have been buffered as input to that
virtual console. If you want to stop a program from running you can
press ctrl-S before switching screens. This will stop the program
when it next tries to output something.
With regards, Eric Smith's (ersmith@uwovax.uwo.ca) comments that such
code does not belong in the kernel, and that pseudo-tty's are much
more flexible, I tend to agree. Nonetheless placing the code directly
in the kernel is precisely what I have done. I still however feel my
changes are worthwhile as they substantially clean up the tty driver;
separating generic tty code from the code that implements a particular
class of tty device. This should help in the implementation of
pseudo-tty's by anyone who has the desire and energy. The
implementation of virtual consoles using pseudo-tty's is however not
entirely trivial as it requires code to emulate the escape codes for a
vt100, or whatever, and also the presence of a select system call.
In my opinion however pseudo-tty's and select are also an ugly way of
doing things, and a much nicer way would be to utilize Minix's message
passing facilities. A terminal would then be represented simply as a
message port identifier. And an application would not know whether it
was communicating with the kernel or another user process. This
however raises issues such as how to enforce restrictions on the
passing of messages between user processes (the denotation of ports by
capabilities that are protected by their sparseness would be the
nicest way of doing this). This however goes beyond the original goal
of Minix of providing a simple Unix compatible system that can run on
a pc.
Gordon Irlam
Adelaide, Australia.
(gordoni@cs.ua.oz.au).