Using Messages in the Example

Edit online

This section describes the messages that can be used in the example.

The getstrm process has issued a getmsg system call and is sleeping until the arrival of a message from the stream head. Such a message would result from the driver detecting activity on the associated tty port.

An incoming call arrives at port 1 and causes a ring-detect signal in the modem. The driver receives the ring signal, answers the call, and sends upstream an M_PROTO message containing information indicating an incoming call. The getstrm process is notified of all incoming calls, although it can choose to refuse the call because of system limits. In this idle state, the getstrm process will also accept M_PROTO messages indicating, for example, error conditions such as detection of line or modem problems on the idle line.

The M_PROTO message containing notification of the incoming call flows upstream from the driver into the CHARPROC module. The CHARPROC module inspects the message type, determines that message processing is not required, and passes the unmodified message upstream to the stream head. The stream head copies the message into the getmsg buffers (one buffer for control information, the other for data) associated with the getstrm process and wakes up the process. The getstrm process sends its acceptance of the incoming call with a putmsg system call, which results in a downstream M_PROTO message to the driver.

Then, the getstrm process sends a prompt to the operator with a write subroutine and issues a getmsg system call to receive the response. A read subroutine could have been used to receive the response, but the getmsg system call allows concurrent monitoring for control (M_PROTO and M_PCPROTO) information. The getstrm process will now sleep until the response characters, or information regarding possible error conditions detected by modules or driver, are sent upstream.

The first response, sent upstream in an M_DATA block, indicates that the code set is ASCII and that canonical processing is requested. The getstrm process implements these options by pushing the CANONPROC module onto the stream, above the CHARPROC module, to perform canonical processing on the input ASCII characters.

The response to the next prompt requests even-parity checking. The getstrm process sends an I_STR operation to the CHARPROC module, requesting the module to perform even-parity checking on upstream characters. When the dialog indicates that protocol-option setting is complete, the getstrm process creates an application process. At the end of the connection, the getstrm process will pop the CANONPROC module and then send an I_STR operation to the CHARPROC module requesting that module restore the no-parity idle state (the CHARPROC module remains on the stream).

As a result of the above dialogs, the terminal at port 1 operates in the following configuration:
  • ASCII, even parity
  • Echo
  • Canonical processing
In similar fashion, an operator at a different type of terminal on port 2 requests a different set of options, resulting in the following configuration:
  • EBCDIC
  • No echo
  • Canonical processing

The resultant streams for the two ports are shown in the Asynchronous Terminal STREAMS diagram (Figure 1). For port 1, the modules in the stream are CANONPROC and CHARPROC.

Figure 1. Asynchronous Terminal STREAMS. This diagram shows port 1 and port 2. Both streams have a user process in the user space. The processes receive and transmit to a stream head which extends from the user space into the kernel space. Each stream head transmits and receives a CANONPROC shown below it. In port 1, CANONPROC has a connection to and from CHARPROC, and CHARPROC receives and transmits to a queue pair below it. In port 2, CANONPROC receives and transmits to ASCEBC, and ASCEBC receives and transmits to a modified CHARPROC. This modified CHARPROC receives and transmits to a queue pair below it. Below the queue ports (yet unconnected from the queue pair) is a raw tty driver. Port 1 is on the left below the driver and port 2 is on the right. There are bidirectional arrows between the ports and the driver; dashed lines continue from these arrows through the driver.
Asynchronous Terminal STREAMS

For port 2, the resultant modules are CANONPROC, ASCEBC, and CHARPROC. The ASCEBC module has been pushed on this stream to translate between the ASCII interface at the downstream side of the CANONPROC module and the EBCDIC interface at the upstream output side of the CHARPROC module. In addition, the getstrm process has sent an I_STR operation to the CHARPROC module in this stream requesting it to disable echo. The resultant modification to the CHARPROC function is indicated by the word "modified" in the right stream of the diagram.

Because the CHARPROC module is now performing no function for port 2, it usually would be popped from the stream to be reinserted by the getstrm process at the end of the connection. However, the low overhead of STREAMS does not require its removal. The module remains on the stream, passing unmodified messages between the ASCEBC module and the driver. At the end of the connection, the getstrm process restores this stream to its idle configuration by popping the added modules and then sending an I_STR operation to the CHARPROC module to restore the echo default.

Note: The tty driver shown in the Asynchronous Terminal STREAMS diagram (Figure 1) handles minor devices. Each minor device has a distinct stream connected from user space to the driver. This ability to handle multiple devices is a standard STREAMS feature, similar to the minor device mechanism in character I/O device drivers.