| Skip Navigation Links | |
| Exit Print View | |
|
STREAMS Programming Guide Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
STREAMS Programming Guide Oracle Solaris 11.1 Information Library |
Part I Application Programming Interface
2. STREAMS Application-Level Components
3. STREAMS Application-Level Mechanisms
4. Application Access to the STREAMS Driver and Module Interfaces
7. STREAMS Framework - Kernel Level
8. STREAMS Kernel-Level Mechanisms
11. Configuring STREAMS Drivers and Modules
14. Debugging STREAMS-based Applications
B. Kernel Utility Interface Summary
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.
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.
A procedure that is called when a module is popped from a stream or when a driver is closed.
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.
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.
A STREAMS mechanism that regulates the rate of message transfer within a stream and from user space into a stream.
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.
A direction of data flow going from a driver toward the stream head. Also called read side and upstream.
A STREAMS module that performs termio canonical and non-canonical processing. It shares some termio processing with a driver in a STREAMS terminal subsystem.
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.
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.
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.
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.
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.
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.
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.
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.
A software driver, not directly associated with a physical device, that performs functions internal to a stream such as a multiplexer or log driver.
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.
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.
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.
A message queue in a module or driver containing messages moving upstream. Associated with the read system call and input from a driver.
A direction of data flow going from a driver towards the stream head. Also called upstream and input side.
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 Oracle Solaris operating environment process scheduling.
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.
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.
An entity in a service interface that responds to request primitives from the service user with response and event primitives.
An entity in a service interface that generates request primitives for the service provider and consumes response and event primitives.
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.
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.
A stream component furthest from the user process that contains a driver.
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.
A mechanism used for bidirectional data transfer implemented using STREAMS, and sharing the properties of STREAMS-based devices.
A STREAMS-based device used in a terminal subsystem.
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.
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.
A message queue in a module or driver containing messages moving downstream. Associated with the write system call and output from a user process.
A direction of data flow going from the stream head toward a driver. Also called downstream and output side.
|