Re: tn3270, mset and map3270

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

On Sun, Mar 14, 2010 at 05:03:30PM -0400, der Mouse wrote:
 > >> 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".

Right. That's the point.

 > > 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.

Can you? I'm pretty sure there's a batch of hardware-level serial port
ioctls that don't work on ttys, but maybe not, or maybe RTS/CTS isn't
one of them.

 > > 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?

I'm saying that if your console didn't work without script(1) going
you'd find it rather difficult to boot single-user.

 > > [...] 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.

Right. Depends which set of robustness concerns matters more. I tend
to believe that code that needs to be debugged generally can be (even
curses) and that therefore structural robustness concerns take
priority over bad code concerns, but many others disagree.

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