Re: tn3270, mset and map3270

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Mar 08, 2010 at 04:31:03AM -0500, der Mouse wrote:
 > >> Not so much Unix-derived; other OSes also tend to expect serial
 > >> lines to carry characters rather than keystrokes [...]
 > > Well, yes.  But only Unix has this enshrined in the tty subsystem.
 > 
 > VMS did, and presumably does, too.  Anything which has "special
 > characters" of any sort (input line editing, signal-or-equivalent
 > generation, etc) must have something of the sort.

I don't know how VMS's tty subsystem works, but it certainly works
differently, because you can e.g. reconnect to sessions after being
hung up on.

 > > Elsewhere (e.g. in DOS, AmigaOS, etc.) a serial port is something
 > > that sends octets, and you can run anything you want over it without
 > > getting in (much) trouble.  In Unix owing to some poor early design
 > > decisions you need a special-case kernel hack to support each new
 > > such application.
 > 
 > You do?  Ever hear of raw mode?  -icanon -ocanon -isig, mostly (there
 > may be a few other bits that have to be turned off) in stty(1)-speak;
 > it's not hard to turn a serial line into a raw octet channel.

Yes, if the model you want is a raw octet channel provided to a user
program, and you're willing to invest the time it takes for a
nonspecialist to figure out termios and how to use it to really turn
the tty layer completely off.

However, if you want something that involves the kernel, it's line
discipline time.

 > > Especially when I have my system architect hat on and I'm thinking
 > > about other concerns as well, like vt bombs.
 > 
 > There is nothing that can be done about those unless you completely
 > break the use of serial lines to carry arbitrary octet sequences, which
 > will also exclude many non-user-interaction uses of serial lines.  I
 > suppose that doesn't matter, since they too shouldn't be using the
 > system the way they are?
 > [...]
 > >>>> [...] ship a copy of libtermcap [...] with my application.
 > >>> [...] accomplish no more than redboxing on a tcpip network. :-)
 > >> [...], I don't see the similarity.
 > > Emitting in-band terminal control signals to a screen device that
 > > doesn't support in-band signalling is fairly useless.
 > 
 > I don't quite get it.  I raelly see only two interpretations.
 > 
 > (1) You propose to drop support for conventional terminals attached to
 > serial lines (which perforce use in-band control) and redesign all
 > terminal emulator equivalents to speak to your curses[%] implementation
 > via some mechanism other than the one used for text content, thus doing
 > away with in-band escape sequences[$] entirely.
 > 
 > (2) You propose to somehow make your curses[%] implementation
 > sufficiently special that it can emit escape sequences[$] to terminals
 > or emulators, but applications not using it will produce some other
 > effect if they try.

Nope... it is a sign of how deeply ingrained the design mistake is
that you don't see that any alternative approach is possible.

In Unix, all serial ports are ttys and all ttys are serial ports. Both
directions of this implication are wrong.

The abstract interface for a screen-mode application should be a
screen. When there's legacy hardware involved, converting the screen
representation into updates composed of terminal control sequences
should be done by system software, not applications.

Using termcap to write ESC[2J or whatever into some position in a
memory-mapped screen, as you propose, won't cause the screen to clear.
But if you blank the whole thing when it's connected to a VT100,
ESC[2J should come out the other end. The application gets a sane
interface, the VT100 is happy, and you can't be vt-bombed. Meanwhile,
everyone else who isn't using a VT100 doesn't have to pay the overhead
of curses computing screen updates or deal with the assorted legacy
problems.

The downside of this approach is that if you want to be able to run
screen-mode programs from a serial console (as opposed to just log in
on serial-connected terminals) the realities of the system structure
require that curses be moved into the kernel as a device driver. This
is not entirely desirable for assorted reasons. (Although it is
perfectly *appropriate*, as curses is and always has been abstraction
code for controlling hardware devices.)

You don't have to worry about NetBSD adopting such an architecture
anytime soon, for binary compat reasons if nothing else, but I think
it's foolish to lock yourself into a position that can't work in such
an environment. From time to time the industry does manage to shake
off this or that piece of legacy infrastructure.

 > You wrote, upthread, that the motivation behind this was to "find and
 > kill" all code that used termcap or terminfo rather than whatever
 > interfaces you propose to bless instead.  That option is not available.

Yes, it is. Realistically, most non-legacy screen-mode applications
use curses; most people who have a legacy screen-mode program written
using raw termcap would be happy to take modernization patches; and
I'm pretty sure a well-designed line-mode library would get fairly
rapid uptake.

Of course you can maintain your own private legacy infrastructure if
that's what you want, but like with all such things you really need to
consider whether you're tilting at windmills.

-- 
David A. Holland
dholland%netbsd.org@localhost