Chapter 2 STREAMS Application-Level Components

This chapter shows how to construct, use, and dismantle a Stream using STREAMS-related system calls. It provides a general discussion of the relationship between STREAMS components in a simple Streams example.

STREAMS Interfaces

The Stream head provides the interface between the Stream and an application program. After a Stream has been opened, STREAMS-related system calls let a user process insert and delete (push and pop) modules. That process can then communicate with and control the operation of the Stream head, modules, and drivers. The Stream head handles most system calls so that the related processing does not have to be incorporated in a module or driver.

STREAMS System Calls

Table 2-1 offers an overview of some basic STREAMS-related system calls.

Action Summary

The open(2) system call recognizes a STREAMS special file and creates a Stream to the specified driver. A user process can receive and send data on STREAMS files using read(2) and write(2) in the same way as with traditional character files. ioctl(2) lets users perform functions specific to a particular device. STREAMS ioctl(2) commands (see the streamio(7I) man page) support a variety of functions to access and control Streams. The final close(2) on a Stream dismantles it.

The poll(2) system call provides a mechanism for multiplexing input/output over a set of file descriptors that reference open files. putmsg(2) and getmsg(2) and the putpmsg(2) and getpmsg(2) send and receive STREAMS messages, and can act on STREAMS modules and drivers through a service interface.

Opening a STREAMS Device File

One way to construct a Stream is to open(2) a STREAMS special file. If the open call is the initial file open, a Stream is created. (There is one Stream for each major or minor device pair.) If this open is not the initial open of this Stream, the open procedures of the driver and all pushable modules on the Stream are called.

Sometimes a user process needs to connect a new Stream to a driver regardless of which minor device is used to access the driver. Instead of the user process polling for an available minor device node, STREAMS provides a facility called clone open. If a STREAMS driver is implemented as a clone device, a single node in the file system may be opened to access any unused device that the driver controls. This special node guarantees that the user is allocated a separate Stream to the driver for every open call. Each Stream is associated with an unused major or minor device, so the total number of Streams that can connect to a particular clone driver is limited to the number of minor devices configured for the driver.

Clone devices are used, for example, in a networking environment where a protocol pseudo-device driver requires each user to open a separate Stream to establish communication.

You can open a clone device in two ways. The first is to create a node with the major number of the clone device (--) and a minor number corresponding to the major number of the device to be cloned. For example /dev/ps0 might have a major number of 50 and a minor number of 0 for normal opens. The clone device may have a major number of 40. By creating a node /dev/ps with a major number of 40 and a minor number of 50, a clonable device is created. In this case, the driver is passed a special flag (CLONEOPEN) that tells it to return a unique minor device number.

The second way is to have the driver open itself as a clone device, that is, the driver returns a unique minor number.

When a Stream is already open, further opens of the same device result in the open routines of all modules and the driver on the Stream being called. In this case, a driver is opened and a module is pushed on a Stream. When a push occurs the module open routine is called. If another open of the same device is made, the open routine of the module is called, followed by the open routine of the driver. This is opposite to the initial order of opens when the Stream is created.

STREAMS also offers autopush. On an open(2) system call, a preconfigured list is checked for modules to be pushed. All modules in this list are pushed before the open(2) returns. For more information see the autopush(1M) and sad(7D) man pages.

Initializing Details

There is one Stream head per Stream. The Stream head, which is initiated by the first open call, is created from a data structure and a pair of queue structures. The content of the Stream head and queues is initialized with predetermined values, including the Stream head processing procedures.

Queueing

STREAMS queues are allocated in pairs. One queue is always the upstream or read-side; the other is the downstream or write-side. These queues hold the messages, and tell the kernel which processing routines apply to each message passing through a module. The queue structure type is queue_t. Fields in the queue data structure are detailed in queue(9S).

Adding and Removing Modules

As part of constructing a Stream, a module can be added (pushed) with an I_PUSHioctl(2) (see streamio(7I)) call. The push inserts a module beneath the Stream head. Because of the similarity of STREAMS components, the push operation is similar to the driver open.

Each push of a module is independent, even in the same Stream. If the same module is pushed more than once on a Stream, there are multiple occurrences of the module in the Stream. The total number of pushable modules that may be contained on any one Stream is limited by the kernel parameter nstrpush.

An I_POPioctl(2) (see streamio(7I)) system call removes (pops) the module immediately below the Stream head. The pop calls the module close procedure. On return from the module close, any messages left on the module's message queues are freed (deallocated). Then, the Stream head connects to the component previously below the popped module and releases the module's queue pair. I_PUSH and I_POP enable a user process to dynamically
alter the configuration of a Stream by pushing and popping modules as required. For example, a module may be removed and a new one inserted below the Stream head. Then the original module can be pushed back after the new module has been pushed.

Closing the Stream

The last close to a STREAMS device dismantles the Stream. Dismantling consists of popping any modules on the Stream and closing the driver. Before a module is popped, the close(2) may delay to allow any messages on the write message queue of the module to be drained by module processing. Similarly, before the driver is closed, the close(2) may delay to allow any messages on the write message queue of the driver to be drained by driver processing. If O_NDELAY (or O_NONBLOCK, see open(2) and fcntl(2)) is clear, close(2) waits up to 15 seconds for each module to drain and up to 15 seconds for the driver to drain. The default close delay is 15 seconds, but this can be changed on a per-Stream basis with the I_SETCLTIMEioctl(2).

Closing Delay Details

The delay is independent of any delay that the module or driver's close routine itself chooses to impose. If O_NDELAY (or O_NONBLOCK) is set, the pop is performed immediately and the driver is closed without delay.

Messages can remain queued, for example, if flow control is inhibiting execution of the write queue service procedure. When all modules are popped and any wait for the driver to drain is completed, the driver close routine is called. On return from the driver close, any messages left on the driver's queues are freed, and the queue and Stream head structures are released.

Inserting Modules

An application can insert various modules into a Stream to process and manipulate data that pass between a user process and the driver. In the example, the character conversion module receives a command and a corresponding string of characters from the user. All data passing through the module is inspected for instances of characters in this string. Whatever operation the command requires is performed on all characters that match the string. Code fragments with explanations follow in Example 2-1.

The first step is to establish a Stream to the communications driver and insert the character conversion module. This is accomplished by first opening (fd = open) then calling ioctl(2) to push the chconv module, as shown in the sequence of system calls in Example 2-2.

Example 2-2 Pushing a Module

The I_PUSHioctl(2) call directs the Stream head to insert the character conversion module between the driver and the Stream head. The example illustrates an important difference between STREAMS drivers and modules. Drivers are accessed through a node or nodes in the file system, in this case /dev/term/a, and are opened just like other devices. Modules, on the other hand, are not devices. Identify modules through a separate naming convention, and insert them into a Stream using I_PUSH or autopush. Figure 2-1 shows
creation of the Stream.

Figure 2-1 Pushing the Character Conversion Module

Modules are stacked onto a Stream and removed from a Stream in last-in, first-out (LIFO) order. Therefore, if a second module is pushed onto this Stream, it is inserted between the Stream head and the character conversion module.

Module and Driver Control

The next step in this example is to pass the commands and corresponding strings to the character conversion module. This can be accomplished by calling ioctl(2) to invoke the character conversion module as shown in the next example.

Example 2-3 uses the conventional I_STRioctl(2), an indirect way of passing commands and data pointers. Example 2-4 shows the data structure for I_STR.

Instead of I_STR, some systems support transparent ioctls in which calls can be made directly. For example, a module calls I_PUSH. Both modules and drivers can process ioctls without requiring user programs to first encapsulate them with I_STR (that is, the ioctls in the examples would look like ioctl(fd,DELETE,"AEIOU");). This style of call works only for modules and drivers that have been converted to use the new facilities that also accept the I_STR form.

In Example 2-3 the module changes all uppercase vowels to lowercase, and deletes all instances of either uppercase or lowercase "x". ioctl(2) requests are issued indirectly, using I_STRioctl(2) (see streamio(7I)). The argument to I_STR
must be a pointer to a strioctl structure, which specifies the request to be made to a module or driver. This structure is described in streamio(7I) and has the format shown in Example 2-4.

Specifies the number of seconds an I_STR request should wait for an acknowledgment before timing out.

ic_len

The number of bytes of data to accompany the request.

ic_dp

Points to the data. In the example, two separate commands are sent to the character-conversion module:

The first command sets ic_cmd to the command XCASE and sends as data the string "AEIOU"; it converts all uppercase vowels in data passing through the module to lowercase.

The second command sets ic_cmd to the command DELETE and sends as data the string "xX"; it deletes all occurrences of the characters "x" and "X" from data passing through the module.

For each command, the value of ic_timout is set to zero, which specifies the system default timeout value of 15 seconds. ic_dp points to the beginning of the data for each command; ic_len is set to the length of the data.

I_STR is intercepted by the Stream head, which packages it into a message, using information contained in the strioctl structure, then sends the message downstream. Any module that cannot process the command in ic_cmd passes the message further downstream. The request is processed by the module or driver closest to the Stream head that understands the command specified by ic_cmd. ioctl(2) blocks up to ic_timout seconds, waiting for the target module or driver to respond with either a positive or negative acknowledgment message. If an acknowledgment
is not received in ic_timout seconds, ioctl(2) fails.

Note -

Only one ioctl(2) can be active on a Stream at one time, whether or not it is issued with I_STR. Further requests will block until the active ioctl(2) is acknowledged and the system call concludes.

The strioctl structure is also used to retrieve the results, if any, of an I_STR request. If data is returned by the target module or driver, ic_dp must point to a buffer large enough to hold that data, and ic_len is set on return to indicate the amount of data returned.

Example 2-5 Process Input

Notice that the character-conversion processing was realized with no change to the communications driver.

exit(2) dismantles the Stream before terminating the process. The character conversion module is removed from the Stream automatically when it is closed. Alternatively, remove modules from a Stream using I_POPioctl(2) described in streamio(7I). This call removes the topmost module on the Stream, and enables a user
process to alter the configuration of a Stream dynamically by popping modules as needed.

Several other ioctl(2) requests support STREAMS operations, such as determining if a given module is on a Stream, or flushing the data on a Stream. streamio(7I) describes these requests.