STREAMS-UX Programmer's Guide (February 2007)

Modules and Drivers
STREAMS Driver
Chapter 4
104
}
if (*mp->b_rptr & FLUSHR) {
*mp->b_rptr &= ~FLUSHW;
/* Flush the read queue if messages can be enqueued */
...
qreply(q, mp);
} else
freemsg(mp);
return;
default:
/* Free the message if the driver does not
* understand it.
*/
freemsg(mp);
return;
}
}
Inbound Processing
The read (2)system call is only seen by the stream head, which processes the system call. A STREAMS driver
will not be aware of this system call. When the driver is ready to send data upstream, it builds an appropriate
message and sends it to the read queue of the appropriate stream. The driver’s interrupt routine usually does
a putnext() on the driver’s read-side queue to send the message upstream. The message to be sent upstream
can be enqueued on the driver’s read-side queue, to be processed by the service procedure either to honor the
flow control mechanisms in STREAMS or to reduce the amount of time spent by the interrupt routine in
processing these messages.
A driver could optionally implement flow control and put the message on it’s own queue to be processed later
by the service procedure.
NOTE A driver may or may not define the read-side put and service procedures. This exception of not
having a read-side put procedure is only applicable to a driver.