STREAMS-UX Programmer's Guide (February 2007)
Differences Between STREAMS/UX and System V Release 4 STREAMS
HP-UX Changes to Message Types
Appendix E
275
HP-UX Changes to Message Types
STREAMS/UX supports all the message types as in SVR 4.2. However STREAMS/UX differs from SVR4.2
STREAMS only in the way it behaves on the receipt of M_HANGUP message at the stream head for controlling
terminals. For the controlling terminals, the stream head sends a SIGHUP signal to the foreground process
group and not the controlling terminal when it receives a M_HANGUP message.
In addition, STREAMS/UX also offers a the following message types:
Ordinary or Low Priority Message Types
M_TRAIL
This message is generated and sent upstream by a driver following the M_HANGUP message to mark the end of
data after an M_HANGUP message. The M_TRAIL message will be processed at the stream head only if the
preceding M_HANGUP message sent by the driver contained the 2-byte TRAIL_TOKEN.
High Priority Message Types
M_CLOSE
This message is generated by the stream head to notify the driver of close(2) when the driver specifies
C_ALLCLOSES in the d_flags field of it's drv_ops_t structure. When the C_ALLCLOSES flag is set, STREAMS
sends an M_CLOSE message downstream and waits for a reply from the driver. The stream will be
dismantled only if the reply (M_CLOSE_REPL) for the M_CLOSE message has MSGLASTCLOSE set in the b_flag
else close(2) returns without dismantling the stream.
M_CLOSE_REPL
This message is generated by the driver in response to the M_CLOSE message sent to it by the stream head.
When the flag C_ALLCLOSES is set, it is the responsibility of driver to keep track of the information about the
number of opens/closes for this device and accordingly set the MSGLASTCLOSE in b_flag in the message
M_CLOSE_REPL if it wants the stream associated with device to be dismantled.
Changes to M_HANGUP
STREAMS/UX differs from SVR4.2 STREAMS in the way it behaves on the receipt of an M_HANGUP message
at the stream head for controlling terminals. STREAMS/UX differs from SVR4.2 STREAMS in the way it
behaves on the receipt of an M_HANGUP message at the stream head for controlling terminals. For the
controlling terminals on receiving an M_HANGUP message at stream head, the stream head sends a
SIGHUP signal to the foreground process group and not the controlling terminal.
If an M_TRAIL message type is used to mark the end of data after the M_HANGUP message, then the M_HANGUP
message must contain the 2-byte TRAIL_TOKEN.