STREAMS Definitions

The capitalized word "STREAMS" refers to the STREAMS programming model and facilities. The word "Stream" refers to an instance of a full-duplex path using the model and facilities between a user application and a driver.

Stream

A Stream is a data path that passes data in both directions between a STREAMS driver in kernel space, and a process in user space. An application creates a Stream by opening a STREAMS device (see Figure 1-1).

Stream Head

A Stream head is the end of the Stream nearest the user process. It is the interface between the Stream and the user process. When a STREAMS device is first opened, the Stream consists of only a Stream head and a STREAMS driver.

Module

A STREAMS module is a defined set of kernel-level routines and data structures. A module does "black-box" processing on data that passes through it. For example, a module converts lowercase characters to uppercase, or adds network routing information. A STREAMS module is dynamically pushed on the Stream from user level by an application. Full details on modules and their operation are covered in Chapter 10, Modules.

Driver

A character device driver that implements the STREAMS interface. A STREAMS device driver exists below the Stream head and any modules. It can act on an external I/O device, or it can be an internal software driver, called a pseudo-device driver. The driver transfers data between the kernel and the device. The interfaces between the driver and kernel are known collectively as the Solaris 7 Device Driver Interface/Driver Kernel Interface (Solaris 7 DDI/DKI). The relationship between the driver and the rest of the UNIX kernel is explained in Writing Device Drivers. Details of device drivers are explained in Chapter 9, STREAMS Drivers.

Messages

The means by which all I/O is done under STREAMS. Data on a Stream is passed in the form of messages. Each Stream head, STREAMS module, and driver has a read side and a write side. When messages go from one module's read side to the next module's read side they are said to be traveling upstream. Messages passing from one module's write side to the next module's write side are said to be traveling downstream. Kernel-level operation of messages is discussed in "Messages".

Queues

A container for messages, each Stream head, driver, and module has its own pair of queues, one queue for the read side and one queue for the write side. Messages are ordered into queues, generally on a first-in, first-out basis (FIFO), according to priorities associated with them. Kernel-level details of queues are covered in "Queues".

Figure 1-2 Messages Passing Using Queues

streamio

To communicate with a Streams device, an application's process uses read(2), write(2), getmsg(2), getpmsg(2), putmsg(2), putpmsg(2), and ioctl(2) to transmit or receive data on a Stream.

From the command line, configure a Stream with autopush(1M). From within an application, configure a Stream with ioctl(2) as described in streamio(7I).

The ioctl(2) interface performs control operations on and through device drivers that cannot be done through the read(2) and write(2) interfaces. ioctl(2) operations include pushing and popping modules on and off the Stream, flushing the Stream, and manipulating signals and options. Certain ioctl(2) commands for STREAMS operate on the whole Stream, not just the module or driver. The streamio(7I) manual page describes STREAMS ioctl(2) commands. Chapter 4, STREAMS Driver and Module Interfaces details inter-Stream communications.

Multiplexing

The modularity of STREAMS allows one or more upper Streams to route data into one or more lower Streams. This process is defined as multiplexing (mux). Example configurations of multiplexers start in "Multiplexing".

Polling

Polling within STREAMS allows a user process to detect events occurring at the Stream head, specifying the event to look for and the amount of time to wait for it to happen. An application might need to interact with multiple Streams. The poll(2) system call allows applications to detect events that occur at the head of one or more Streams. Chapter 3, STREAMS Application-Level Mechanisms describes polling.

Flow Control

Flow control regulates the rate of message transfer between the user process, Stream head, modules, and driver. With flow control, a module that cannot process data at the rate being sent can queue the data to avoid flooding modules upstream with data. Flow control is local to each module or driver, and is voluntary. Chapter 8, Messages - Kernel Level describes flow control.