Re: tn3270, mset and map3270

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> It also occurred to me, after I sent that, that ptys (which have
>> been around a fairly long time) are ttys but not serial ports.
> They are imitation serial ports.

Not really.  They're imitation ttys.

> Consider for example:

>    valkyrie% tty
>    /dev/pts/33
>    valkyrie% stty -a
>    speed 38400 baud; 24 rows; 80 columns;
>       :

> 38400 baud, eh?

Right.  That's a botch in the tty interface, in that there is no value
for that field for "there is no serial line backing this tty; speed
figures are meaningless".  You almost certainly can transfer data
through that pty substantially faster than 38400 bits per second.

> Nowdays you can't e.g. turn on and off RTS/CTS handling on them, but
> I don't think that's always been the case.

You can under 4.0.1, in the sense of twiddling the crtscts bit, but I
don't think it does anything any more than changing the baud rate
setting does.

>>>>> [...separate full-screen and glass-tty interfaces...]
>>>> [Full-screen on a serial line] could be done with the help of a
>>>> program which speaks "serial terminal" out one side and
>>>> "full-screen interface" (whatever that turns out to be) out the
>>>> other.
>>> Not for the console,
>> I don't see serial console as being any different from any other
>> serial line in this respect.
> The console is different because it's the console: there can't be
> bits of userland between it and programs running on it, or you end up
> with serious problems booting single-user.

You do?  So, you're saying that script(1) doesn't work on the console,
or that its existence causes problems booting single-user?

Neither one matches my experience, and script(1) is actually a decent
proxy for what I was talking about: if you want to run a full-screen
program on a serial line - console or not - you use a script-like
utility which runs on a serial line and sets up a full-screen interface
for the use of some other command, as in

console% fullscreen nethack

Of course, fullscreen(1) would be setting up a full-screen interface
instead of the tty interface script(1) sets up today.

> [...] I think for robustness reasons I would choose to put the driver
> logic in the kernel.

Perhaps amusingly, it's mostly for robustness reasons that I think it
does not belong in the kernel.  I would very much prefer that all the
hair that will be entailed - terminal types, the database that we
currently keep in /usr/share/misc/termcap, and the code that's
currently in libcurses - be in userland; I don't think it belongs in
the kernel any more than (say) the C compiler does.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B