Deficiencies in Unix TTY and PTY drivers

[Jon Olson]

We have recently developed a  multiplexor board which  has eight RS232
ports.    This board  which  allows   a  single RS232   port  on a SUN
workstation to support seven ports (the eighth port on the multiplexor
board connects to the RS232 port on the SUN).

A MUX  daemon  on the SUN  provides the interface software between the
single RS232 port and seven pseudo-terminal (pty) ports.  Although the
interface was simple to develop and debug there are a few shortcomings
with the  `tty'  and  `pty'   drivers which would   be useful  in this
application (and many other applications).

  1) I  have found that SUNOS  3.4 does not support hardware (CTS/RTS)
     handshaking    on   RS232  lines.     Although  the     dedicated
     microprocessor on  the  MUX  board can  handle 19,200  baud input
     without  flow-control, the  standard Unix TTY  driver (either the
     old  or new discipline)  cannot.   What  I need  is  for Unix  to
     generate  a ~RTS  whenever the  input  buffers  are  in danger of
     overflowing.  Since  the  MUX must pass   any  binary information
     through the  TTY port,  ^S/^Q  handshaking  would   require messy
     encoding of the data stream.

  2) The  standard TTY driver  does not  have  sufficient buffering to
     accept  large data  packets.  I have  limited the size of packets
     sent  to  the SUN  to 64 bytes  to overcome  this limitation.  It
     would  be useful to  have   an `ioctl' which  configures a  large
     buffer for a TTY port.

  3) I tried  the `bk' driver but it  doesn't  work with the  `select'
     system call.  When  given a  file descriptor of  a tty  using the
     `bk' line discipline, `select' always returns immediately even if
     there is no data to be input.

  4) The  `pty' driver has  a  TIOCPKT mode  which  gives one   of the
     following control flags.

	TIOCPKT_FLUSHREAD
        TIOCPKT_FLUSHWRITE
        TIOCPKT_STOP
        TIOCPKT_START
        TIOCPKT_DOSTOP

     Ultrix (DEC's Unix) has an extra (very useful) control flag which
     SUN  leaves out, TIOCPKT_IOCTL,  which  indicates  that the slave
     process has executed an ioctl operation.   This allows the master
     to manipulate the device to emulate the ioctl operation  that the
     slave just performed.

Any comments on hardware handshaking or high-speed input of data over
RS232 lines would be appreciated.

-- 
Jon Olson, Modular Mining Systems
USENET:     {ihnp4,allegra,cmcl2,hao!noao}!arizona!modular!olson
INTERNET:   modular!olson at arizona.edu