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
Module developers should follow these guidelines:
If a module cannot process the message types, the message types must be passed to the next module.
The module that acts on an M_IOCTL message should send an M_IOCACK or M_IOCNAK message in response to the ioctl(2). If the module cannot process the ioctl(2), it should pass the M_IOCTL message to the next module.
Modules should not pertain to any particular driver but should be compatible with all drivers.
In general, modules should not require the data in an M_DATA message to follow a particular format, such as a specific alignment. This means modules can be arbitrarily pushed on top of each other in a sensible fashion. Not following this rule can limit module usability.
Filter modules pushed between a service user and a service provider should not alter the contents of the M_PROTO or M_PCPROTO block in messages. The contents of the data blocks can be changed, but the message boundaries must be preserved.
The htonl(3SOCKET) and ntohl(3SOCKET) conversion routines follow the XNS5 publications. The functions continue to convert 32-bit quantities between network byte order and host byte order.