STREAMS

[1] An important concept in STREAMS is the ability to push drivers – custom code modules which can modify the functionality of a network interface or other device – together to form a stack.

This I/O system was ported to System V Release 3 by Robert Israel, Gil McGrath, Dave Olander, Her-Daw Che, and Maury Bach as part of a wider framework intended to support a variety of transport protocols, including TCP, ISO Class 4 transport, SNA LU 6.2, and the AT&T NPACK protocol (used in RFS).

POSIX.1-2008 with TC1 (IEEE Std 1003.1, 2013 edition) has designated STREAMS as 'marked obsolescent'[14][15] meaning that said functionality may be removed in a future version of the specification.

In Version 7 Unix, a command was connected to a terminal (keyboard and screen, or keyboard and printer) through a mechanism called the line discipline, which would buffer a single line of input, i.e., wait for the user to press the Return key before sending input to the program for processing; this allowed simple error correction.

Programs could "push" a new module onto one end of the chain to change the behavior of a terminal or other character device.

[17][18]: 348–350 The actual Streams modules live in kernel space on Unix, and are installed (pushed) and removed (popped) by the ioctl system call.

For example, to install the aforementioned line discipline on a file descriptor fd referring to a terminal device, one would write (in C):[18]: 347 To perform input/output on a stream, one either uses the read and write system calls as with regular file descriptors, or a set of STREAMS-specific functions to send control messages.

[19] Ritchie admitted to regretting having to implement Streams in the kernel, rather than as processes, but felt compelled to do so for reasons of efficiency.