Hardware Emulation Module

If a stream supports a terminal
interface, a driver or module that understands all ioctls is needed
to support terminal semantics (specified by termio(7I) and termiox(7I). 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
line-discipline 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. Together,
the line-discipline module and the hardware emulation module behave as if there was
an actual terminal on that stream.

The hardware emulation module is necessary whenever there is no TTY driver at
the end of the stream. For example, the module is necessary in a pseudo-TTY situation
where there is process-to-process communication on one system (discussed in STREAMS-based Pseudo-Terminal Subsystem), or in
a network situation where a termio interface is expected (for example,
remote login) but there is no TTY driver on the stream.

Most of the actions taken by the hardware emulation module are the same regardless
of the underlying architecture. However, there are some actions that are different,
depending on whether the communication is local or remote and whether the underlying
transport protocol is used to support the remote connection.

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.

If the environment supports windowing, it acknowledges the windowing TIOCSWINSZ, TIOCGWINSZ, and JWINSIZEioctl(2)s. If the environment does not support
windowing, an M_IOCNAK message is sent upstream.

If another ioctl(2) is
received on its write queue, it sends an M_IOCNAK message upstream.
It doesn't pass any unrecognized ioctls to the slave driver.

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 will
probably be an M_PROTO message, which is a TPI T_DISCON_REQ message
requesting the transport provider to disconnect.

All other messages (M_DATA, for instance) 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.