Re: some console code checked in

[Roland McGrath]

Our chief concern to begin with is clean code reuse and consistency of the
terminal emulation for standard display devices.  Turning the interface
inside out doesn't lose that.

But I am still on the fence about what the proper structure really is.

First are some feature concerns, with a garnish of efficiency concerns that
are no doubt in fact negligible.  There are several things you get from
having the virtual terminal (the screen matrix) maintained in a common
layer independent of and "above" any particular display driver.  

The negligible efficiency concern is that you avoid duplication of the data
structures and the processing code path that maintain the screen matrix and
the state of escape sequence parsing.

You can have generic visual bell and screensaver modules that plug in at
the higher level interface.  They could use the character drawing
interfaces or use the escape sequence engine to do whatever (play ascii
movies, towers of hanoi, etc); the generic part can implement save/restore
state, and also inspection of the matrix so you can do ascii decayscreen
and the like.  Such hacks would work the same for any underlying display
driver(s) you might have (presumably a display driver could have its own
fancier graphics things and those would take over instead when turned on).

Similarly, you could have things like split-screen display of two virtual
terminals implemented generically at this layer (i.e. an interface like
"window" or newer versions of "screen").

You can dynamically detach and attach display drivers to a virtual screen.
New ones attaching can reconstruct the current screen matrix immediately
from the higher layer's state.  (The only other way is to replay an
arbitrarily long log of the output to process the escape sequences--but in
the general case you might need the entire output history.)  I see uses for
both the case of additional disparate display drivers attaching to spy on
another display, and the case of maintaining the virtual terminal screen
matrix while having no display driver attached at all, to be displayed when
one attaches.

There is surely more than one way to structure the code such that these
things are possible.  But all I have in mind at the moment is the
imposition of the central terminal emulation module.


Second, I am still of two minds about what "the right thing" is for the
console abstraction (actually, I'm two minds aware that in the end my mind
will just go to little pieces).  I was buying your argument for a while,
thinking about applications a la conserver where you are treating the
virtual console as you would a serial port (i.e. equivalent to a pty), as
well as the speech/Braille examples you mentioned.  But now I am thinking
more of applications a la screen, where there is a consistent virtual
terminal screen image maintained that can be attached (sequentially or
simultaneously) to multiple disparate players.  And for speech and Braille
interfaces, they might well have a virtual screen image in the canonical
sense and have in their own front ends scrolling or "panning" sort of
interfaces (screen has support for some Braille devices that appear to work
this way).

Ultimately where this should be heading is libchannel.  We want to
decompose the functionality we're implementing and provide flexible forms
of interconnection.  For example, say I have 11 physical displays.  On each
of the first 10 physical displays I would like to have 12 virtual terminals
and switch among those with hot keys.  On the 11th physical display I would
like to be able to see virtual terminal #1 of each of the first 10
displays, and switch among those virtual terminals with hot keys.  Now
generalize from there.

In the fully decomposed model, a terminal emulation module is a component
that connects takes asynchronous input events (a stream of bytes) and on
the other end provides a kind of storage interface (though one that
delivers immediate updates asynchronously to asynchronous readers).  You
can stick this in the middle or not, depending on what configuration you
want.

All these features are more than fancy enough not to worry about overmuch
now.  It's fine to impose a different sort of structure for now that gets
just the features you are working on now.  Keeping all the new code clean
and modular in the general sense means it won't be terribly painful to
restructure it later.