std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/03/86)
From: dave%garfield.mun.cdn%ubc.csnet@RELAY.CS.NET (David Janes)
Date: Sun, 2 Nov 86 11:29:02 pst
The tty driver should provide a character i/o interface to the outside
world, and nothing else.
SIGWINCH, SIGSTOP, SIGCONT, etc. all have a similar purpose: to
inform the user process that there has been a change in the `environment'
that the process is using. (The real purpose of SIGCONT, besides
putting a process back in run queue, is to inform a process that its
output screen has been dirtied.) In addition to signals, ioctls have been
added to ask the tty driver about it's environment: how big is my screen,
and so on. All these are currently implemented as tty driver `aids', and
really have no place there.
The Solution: an `environment' file should be available for
every tty device (including pseudo-ttys.)
All changes to the tty's environment are reflected into this
file. If the window size is changed (by whatever), the window
size part of that file is modified. If the screen is `dirtied',
a `dirty screen' flag is set, and so on.
The environment file is a normal UNIX file. Some programs like init,
and so on may need to be modified to keep this file with the
right protections and so on, but this is basically minor.
Processes (including the kernel for some implementations) which change
the environment of the tty merely update this file when they
make those changes.
One kernel change must be added. A SIGIO signal should be
sent when this file is modified to all interested processes (who
declare the interest via `fnctl' or some similar mechanism.)
This change can be justified outside the concept of `environments'
as a reasonable extension to the SIGIO facility.
The stopping and restarting of processes can be implemented
sensibly and independantly of this scheme.
NOTES:
[1] this could be added to system V to make job control as `nice'
to the user as Berkeley job control, and still be entirely backwards
compatable.
[2] window management process (even if implemented in the kernel)
simply write their changes to the environment file if
the screen size gets changed.
[3] simple window management, which doesn't redraw screens,
can be implemented under the same scheme. Thus, many styles
of `job control' (in the broad sense) may be implemented.
dave
--
.o.o. The UUCP: {utcsri,ihnp4,allegra,philabs}!garfield!dave
.:O:. Mercenary CDNNET: David Janes <dave@garfield.mun.cdn>
.o.o. Programmer "There can only be one!"
Volume-Number: Volume 8, Number 24