STREAMS-UX Programmer's Guide (February 2007)

Modules and Drivers
STREAMS Module
Chapter 4
95
Service Procedure
The following example shows a generic service procedure:
int
mod_rsrv(q)
queue_t *q;
{
mblk_t *mp;
while ((mp = getq(q)) != NULL) {
/* check for flow control */
if (!(mp->b_datap->db_type >= QPCTL) &&
!canputnext(q) {
putbq(q,mp);
return;
}
/* Process the message */
switch (mp->b_datap->db_type) {
case M_DATA:
...
...
}
} /* while */
}
Module Specific Design Guidelines
In addition to the guidelines listed in the “Design Guidelines” section in this chapter, the module developers
should follow these guidelines:
• If a module does not understand a message type it must forward the message to the next component on
the stream.
• For reusability, module design should stay independent of the underlying device or driver functionality.
• If the module acts on a M_IOCTL message, it must send a M_IOCACK or M_IOCNAK in response to the
IOCTL. Instead, if the module does not understand the IOCTL, it must pass the M_IOCTL message to the
next component in the stream.
• Filter modules pushed between a service user and a service provider must not alter the contents of the
M_PROTO or M_PCPROTO block in messages. The contents of the data block can be modified, however the
message boundaries must be preserved.