Hardware emulation module

If a Stream supports a terminal interface, a driver or module that understands all ioctls to support terminal semantics (specified by termio and termios) is needed. If there is no hardware driver that understands all ioctl commands downstream from the ldterm module, a hardware emulation module must be placed downstream from the ldterm module. The function of the hardware emulation module is to understand and acknowledge the ioctls that may be sent to the process at the Stream head and to mediate the passage of control information downstream. The combination of the ldterm module and the hardware emulation module behaves as if there were a terminal on that Stream.

The hardware emulation module is necessary whenever there is no tty driver at the end of the Stream. For example, it is necessary in a pseudo-tty situation where there is process-to-process communication on one system and in a network situation where a termio interface is expected (for example, remote login) but there is no tty driver on the Stream.

Most actions taken by the hardware emulation module are the same regardless of the underlying architecture. However, some actions differ depending on whether the communication is local or remote and whether the underlying transport protocol supports the remote connection.

Each hardware emulation module has an open, close, read queue put procedure, and write queue put procedure.

The hardware emulation module does the following:

• Processes, if appropriate, and acknowledges receipt of the following ioctls on its write queue by sending an M_IOCACK message back upstream: TCSETA, TCSETAW, TCSETAF, TCSETS, TCSETSW, TCSETSF, TCGETA, TCGETS, and TCSBRK.

• Acknowledges the Extended UNIX Code (EUC) ioctls.

• If the environment supports windowing, it acknowledges the windowing ioctls TIOCSWINSZ, TIOCGWINSZ, and JWINSIZE. If the environment does not support windowing, an M_IOCNAK message is sent upstream.

• If any other ioctls are received on its write queue, it sends an M_IOCNAK message upstream.

• When the hardware emulation module receives an M_IOCTL message of type TCSBRK on its write queue, it sends an M_IOCACK message upstream and the appropriate message downstream. For example, an M_BREAK message could be sent downstream.

• When the hardware emulation module receives an M_IOCTL message on its write queue to set the baud rate to 0 (TCSETAW with CBAUD set to B0), it sends an M_IOCACK message upstream and an appropriate message downstream; for networking situations this probably is an M_PROTO message, which is a TPI T_DISCON_REQ message requesting the transport provider to disconnect.

• All other messages (M_DATA, and so forth) not mentioned here are passed to the next module or driver in the Stream.

The hardware emulation module processes messages in a way consistent with the driver that exists below.