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

Document Information

Preface

Part I Application Programming Interface

1.  Overview of STREAMS

What Is STREAMS?

STREAMS Definitions

Stream as a Data Path

Stream Head

STREAMS Module

STREAMS Device Driver

STREAMS Data

Message Queues

Communicating With a STREAMS Device

STREAMS Multiplexing

STREAMS Polling

Message Transfer Flow Control

When to Use STREAMS

How STREAMS Works--Application Interface

Opening a Stream

Closing a Stream

Controlling Data Flow

Simple Stream Example

How STREAMS Works at the Kernel Level

Creating the Stream Head

Message Processing

Structure of a STREAMS Device Driver

Message Components

Message Queueing Priority

Structure of a Message Queue

Configuring Multiplexed Streams

Multithreading the Kernel

Service Interfaces

Manipulating Modules

Protocol Portability

Protocol Substitution

Protocol Migration

Module Reusability

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

D.  STREAMS FAQ

Glossary

Index

Manipulating Modules

With STREAMS, you can manipulate modules from the user application level, interchange modules with common service interfaces, and change the service interface to a STREAMS user process. These capabilities yield further benefits when working with networking services and protocols:

The following examples show the benefits of STREAMS capabilities for creating service interfaces and manipulating modules. These examples are only illustrations and do not necessarily reflect real situations.

Protocol Portability

Figure 1-6 shows how an X.25 protocol module can work with different drivers on different machines by using compatible service interfaces. The X.25 protocol module interfaces are Connection Oriented Network Service (CONS) and Link Access Protocol – Balanced (LAPB).

Figure 1-6 Protocol Module Portability

Diagram demonstrates that the same protocol module can be used by different drivers on different machines.

Protocol Substitution

You can alternate protocol modules and device drivers on a system if the alternates are implemented to an equivalent service interface.

Protocol Migration

Figure 1-7 shows how STREAMS can move functions between kernel software and front-end firmware. A common downstream service interface lets the transport protocol module be independent of the number or type of modules below it. The same transport module will connect without modification to either an X.25 module or X.25 driver that has the same service interface.

By shifting functions between software and firmware, you can produce cost-effective, functionally equivalent systems over a wide range of configurations. This means you can swiftly incorporate technological advances. The same transport protocol module can be used on a lower-capacity machine, where economics preclude the use of front-end hardware, and also on a larger scale system where a front-end is economically justified.

Figure 1-7 Protocol Migration

Diagram shows that the protocol layer can be included in a driver rather than in a separate module.

Module Reusability

Figure 1-8 shows the same canonical module (for example, one that provides delete and kill processing on character strings) reused in two different streams. This module would typically be implemented as a filter, with no service interface. In both cases, a TTY interface is presented to the stream's user process because the module is nearest the stream head.

Figure 1-8 Module Reusability

Diagram shows reuse of the same canonical module in two different streams.