STREAMS-UX Programmer's Guide (February 2007)

Multiplexing
STREAMS Multiplexor
Chapter 5
124
Ioctl Processing in a Multiplexor
For M_IOCTL processing, the upper-half of the multiplexor must follow the same rules as drivers. It must
always process an M_IOCTL message from the stream head and acknowledge it with a M_IOCACK/M_IOCNAK. If
the upper-half of the multiplexor does not understand the ioctl, it must send an M_IOCNAK upstream.
In addition, all STREAMS multiplexing drivers must handle the ioctls I_LINK/I_PLINK and
I_UNLINK/I_PUNLINK messages so that they can build and dismantle a multiplexing configuration.
Ioctl processing is not applicable to the lower-half of the multiplexor. This is because a stream linked under
a multiplexor will not be accessible to anything other than that multiplexor.
Flush Handling in a Multiplexor
On receiving an M_FLUSH message, the upper-half of the multiplexor behaves like a driver and the lower-half
of the multiplexor behaves like a stream head.
On receiving an M_FLUSH message from a stream linked underneath it at a lower read queue, the lower-half of
the multiplexor will flush the lower read queue, if FLUSHR is set, and unsets FLUSHR. If FLUSHW is not set, it
frees the message. Otherwise, it flushes the corresponding lower write queue and sends the M_FLUSH message
downstream.
To handle M_FLUSH messages received at a upper write queue, the upper half of the multiplexor flushes the
upper write queue if FLUSHW is set and unsets FLUSHW flag. If FLUSHR is not set, it frees the message.
Otherwise, it flushes the corresponding upper read queue and sends the M_FLUSH message upstream.
Flow Control in a Multiplexor
When multiple streams are feeding a stream, or a single stream is feeding multiple streams in a multiplexor
configuration, one or more of the receiving streams can be flow controlled. If the multiplexor implements flow
control, the sending streams should enqueue the messages on their own queues and process them when they
are back-enabled.
Unlike the rest of the stream, the queues in the upper and the lower-half of the multiplexor are not linked
together through q_next pointers. The absence of the direct linkage between the upper and lower streams
means that the flow control has to be handled by special code in the multiplexing driver. To implement flow
control, multiplexors must have a lower write service procedure and an upper read service procedure.
Typically, the multiplexor’s lower write service procedure will be enabled when the write side of a stream
linked under a multiplexor has its flow control lifted. The lower write service procedure must then enable all
the upper write queues that were blocked from sending messages downstream when the lower stream was
flow controlled.
The multiplexor’s upper read service procedure is enabled when the read side of the multiplexor stream has
its flow control lifted. The upper read service procedure must then enable all the lower read queues that were
blocked from sending messages upstream to the stream that was flow controlled.
The decision to block all the sending streams when one or more receiving streams are flow controlled is
multiplexor-implementation specific.