JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
STREAMS Programming Guide
search filter icon
search icon

Document Information


Part I Application Programming Interface

1.  Overview of STREAMS

2.  STREAMS Application-Level Components

3.  STREAMS Application-Level Mechanisms

4.  Application Access to the STREAMS Driver and Module Interfaces

5.  STREAMS Administration

6.  Pipes and Queues

Part II Kernel Interface

7.  STREAMS Framework - Kernel Level

8.  STREAMS Kernel-Level Mechanisms

9.  STREAMS Drivers

10.  STREAMS Modules

11.  Configuring STREAMS Drivers and Modules

12.  Multithreaded STREAMS

13.  STREAMS Multiplex Drivers

Part III Advanced Topics

14.  Debugging STREAMS-based Applications

Part IV Appendixes

A.  Message Types

B.  Kernel Utility Interface Summary

C.  STREAMS-Based Terminal Subsystem






A STREAMS locking mechanism that prevents the removal of STREAMS modules with the I_POP ioctl. Anchors are placed on STREAMS modules by adding the [anchor] flag to autopush configuration files or by directly calling the I_ANCHOR ioctl.


A STREAMS mechanism that enables a prespecified list of modules to be pushed automatically onto the stream when a STREAMS device is opened. This mechanism is used only for administrative purposes.


To enable (by STREAMS) a preceding blocked queue's service procedure when STREAMS determines that a succeeding queue has reached its low-water mark.


A queue's service procedure that cannot be enabled due to flow control.

clone device

A STREAMS device that returns an unused major/minor device when initially opened, rather than requiring the minor device to be specified by name in the open call.

close routine

A procedure that is called when a module is popped from a stream or when a driver is closed.

controlling stream

A stream above the multiplexing driver used to establish the lower connections. Multiplexed stream configurations are maintained through the controlling stream to a multiplexing driver.


Device Driver Interface. An interface that facilitates driver portability across different UNIX system versions.

device driver

A stream component whose principle functions are handling an associated physical device and transforming data and information between the external interface and stream.


Driver–Kernel Interface. An interface between the UNIX system kernel and different types of drivers. It consists of a set of driver-defined functions that are called by the kernel. These functions are entry points into a driver.


A direction of data flow going from the stream head toward a driver. Also called write side and output side.


A module that forms the stream end. It can be a device driver or a pseudo-device driver. It is a required component in STREAMS (except in STREAMS-based pipe mechanism), and physically identical to a module. It typically handles data transfer between the kernel and a device and does little or no processing of data.


A term used to describe scheduling of a queue's service procedure.


First in, first out. A term used in STREAMS for named pipes. This term is also used in queue scheduling.

flow control

A STREAMS mechanism that regulates the rate of message transfer within a stream and from user space into a stream.

hardware emulation module

A module required when the terminal line discipline is on a stream but there is no terminal driver at the end of the stream. This module recognizes all ioctls necessary to support terminal semantics specified by termio and termios.

input side

A direction of data flow going from a driver toward the stream head. Also called read side and upstream.

line discipline

A STREAMS module that performs termio canonical and non-canonical processing. It shares some termio processing with a driver in a STREAMS terminal subsystem.

lower stream

A stream connected below a multiplexer pseudo-device driver, by means of an I_LINK or I_PLINK ioctl. The far end of a lower stream terminates at a device driver or another multiplexer driver.

master driver

A STREAMS-based device supported by the pseudo-terminal subsystem. It is the controlling part of the pseudo-terminal subsystem (also called ptm).


One or more linked message blocks. A message is referenced by its first message block and its type is defined by the message type of that block.

message block

A triplet consisting of a data buffer and associated control structures, an msgb structure and a datab structure. It carries data or information, as identified by its message type, in a stream.

message queue

A linked list of zero or more messages connected together.

message type

A defined set of values identifying the contents of a message.


A defined set of kernel-level routines and data structures used to process data, status, and control information on a stream. It is an optional element, but there can be many modules in one stream. It consists of a pair of queues (read queue and write queue), and it communicates to other components in a stream by passing messages.


A STREAMS mechanism that enables messages to be routed among multiple streams in the kernel. A multiplexing configuration includes at least one multiplexing pseudo-device driver connected to one or more upper streams and one or more lower streams.

named stream

A stream, typically a pipe, with a name associated with it by way of a call to fattach (that is, a mount operation). This is different from a named pipe (FIFO) in two ways: a named pipe (FIFO) is unidirectional while a named stream is bidirectional; a named stream need not refer to a pipe but can be another type of a stream.

open routine

A procedure in each STREAMS driver and module called by STREAMS on each open system call made on the stream. A module's open procedure is also called when the module is pushed.

packet mode

A feature supported by the STREAMS-based pseudo-terminal subsystem. It is used to inform a process on the master side when state changes occur on the slave side of a pseudo-TTY. It is enabled by pushing a module called pckt on the master side.

persistent link

A connection below a multiplexer that can exist without having an open controlling stream associated with it.


See STREAMS-based pipe.


A term used when a module that is immediately below the stream head is removed.

pseudo-device driver

A software driver, not directly associated with a physical device, that performs functions internal to a stream such as a multiplexer or log driver.

pseudo-terminal subsystem

A user interface identical to a terminal subsystem except that there is a process in place of a hardware device. It consists of at least a master device, slave device, line-discipline module, and hardware emulation module.


A term used when a module is inserted in a stream immediately below the stream head.

pushable module

A module put between the stream head and driver. It performs intermediate transformations on messages flowing between the stream head and driver. A driver is a non-pushable module.

put procedure

A routine in a module or driver associated with a queue that receives messages from the preceding queue. It is the single entry point into a queue from a preceding queue. It may perform processing on the message and will then generally either queue the message for subsequent processing by this queue's service procedure, or will pass the message to the put procedure of the following queue.


A data structure that contains status information, a pointer to routines processing messages, and pointers for administering a stream. It typically contains pointers to a put and service procedure, a message queue, and private data.

read queue

A message queue in a module or driver containing messages moving upstream. Associated with the read system call and input from a driver.

read side

A direction of data flow going from a driver towards the stream head. Also called upstream and input side.

remote mode

A feature available with the pseudo-terminal subsystem. It is used for applications that perform the canonical and echoing functions normally done by the line discipline module and TTY driver. It enables applications on the master side to turn off the canonical processing.


A STREAMS Administrative Driver that provides an interface to the autopush mechanism.


To place a queue on the internal list of queues that will subsequently have their service procedure called by the STREAMS scheduler. STREAMS scheduling is independent of the Solaris operating environment process scheduling.

service interface

A set of primitives that define a service at the boundary between a service user and a service provider and the rules (typically represented by a state machine) for allowable sequences of the primitives across the boundary. At a stream/user boundary, the primitives are typically contained in the control part of a message; within a stream, in M_PROTO or M_PCPROTO message blocks.

service procedure

A routine module or driver associated with a queue that receives messages queued for it by the put procedure of that queue. The procedure is called by the STREAMS scheduler. It may perform processing on the message and generally passes the message to the put procedure of the following queue.

service provider

An entity in a service interface that responds to request primitives from the service user with response and event primitives.

service user

An entity in a service interface that generates request primitives for the service provider and consumes response and event primitives.

slave driver

A STREAMS-based device supported by the pseudo-terminal subsystem. It is also called pts and works with a line discipline module and hardware emulation module to provide an interface to a user process.

standard pipe

A mechanism for the unidirectional flow of data between two processes where data written by one process becomes data read by the other process.


A kernel aggregate created by connecting STREAMS components, resulting from an application of the STREAMS mechanism. The primary components are the stream head, the driver, and zero or more pushable modules between the stream head and driver.

stream end

A stream component furthest from the user process that contains a driver.

stream head

A stream component closest to the user process. It provides the interface between the stream and the user process.


A kernel mechanism that provides the framework for network services and data communication. It defines interface standards for character input/output within the kernel, and between the kernel and user level. The STREAMS mechanism includes integral functions, utility routines, kernel facilities, and a set of structures.

STREAMS-based pipe

A mechanism used for bidirectional data transfer implemented using STREAMS, and sharing the properties of STREAMS-based devices.

TTY driver

A STREAMS-based device used in a terminal subsystem.

upper stream

A stream that terminates above a multiplexer. The beginning of an upper stream originates at the stream head or another multiplexer driver.


A direction of data flow going from a driver towards the stream head. Also called read-side and input side.

water mark

A limit value used in flow control. Each queue has a high-water mark and a low-water mark. The high-water mark value indicates the upper limit related to the number of bytes contained on the queue. When the queued character reaches its high-water mark, STREAMS causes another queue that attempts to send a message to this queue to become blocked. When the characters in this queue are reduced to the low-water mark value, the other queue is unblocked by STREAMS.

write queue

A message queue in a module or driver containing messages moving downstream. Associated with the write system call and output from a user process.

write side

A direction of data flow going from the stream head toward a driver. Also called downstream and output side.