Streams TTY: how is this assigned?

[stephen.a.rago]

In article <1294 at adds.newyork.NCR.COM>, tanya at adds.newyork.NCR.COM (Tanya Katz) writes:
> 
> I have written an software multiplexor that channels data to/from
> a single process from/to many ttys.
> When the multiplexor device is opened it sets up the terminal as
> the process group leader thus enabling the process to receive
> signals from the driver.

I hope you mean that the mux device is set up as the controlling TTY,
not the terminal device.  Otherwise, signals won't work.  BTW, what do
you do if one terminal device hangs up?

> The O_NDELAY flag is enabled upon open.
> According to the documentation, read should return 0 when no characters
> are available, but it returns -1 with errno set to EAGAIN, indicating
> that the stream head does not see the mux as a streams TTY device.
> 
> 1> How can I change this behaviour?

If you are running System V Release 3.2 or later, in your mux open routine,
send an M_SETOPTS message to the stream head with the SO_NDELON flag set.
This will enable non-STREAMS tty semantics for nonblocking reads and writes.
Check stream.h to see if this flag is defined.

> 2> Would someone explain how the kernel decides which devices are TTY devices?

In SVR3.x, a stream is a stream is a stream.  The kernel does not distinguish
TTY devices from others, except that by setting up a controlling TTY, you
enable signals to the process group and /dev/tty to operate.

In SVR4, another M_SETOPTS flag (SO_ISTTY) was added to indicate that the
stream is acting as a terminal.  Then controlling terminal assignment is
handled at a higher layer and not by the driver.

Steve Rago
sar at attunix.att.com