Re: tn3270, mset and map3270

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

On Sat, Mar 13, 2010 at 08:41:52AM -0500, der Mouse wrote:
 >>>> In Unix, all serial ports are ttys and all ttys are serial ports.
 >>>> Both directions of this implication are wrong.
 >>> To the extent that the former is true, I agree with the latter.
 >>> But the former isn't quite true; for example, [Sun kbds/mice]
 > 
 > 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. Consider for example:

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

38400 baud, eh?

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.

 > >>> The downside of this approach is that if you want to be able to run
 > >>> screen-mode programs from a serial console [...] the realities of
 > >>> the system structure require that curses be moved into the kernel
 > >>> as a device driver.
 > >> I'm not so sure.  I don't see that as being necessary; it 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 also don't want a daemon in
there because it might die -- you get all the usual problems that
entails and if the daemon breaks the system console it becomes rather
hard to recover. None of this matters for serving ordinary logins with
a serial port daemon (any more than telnetd or sshd creates a problem)
but the console has to be somewhat privileged.

As you note, one could probably design some way to make this work such
that you could still boot single-user and just not be able to run
full-screen programs (which was historically often the case anyway for
single-user) but I think for robustness reasons I would choose to put
the driver logic in the kernel.

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