STREAMS blocks a user process that issues an ioctl(2) and causes the stream head to generate an M_IOCTL </function> message. The process remains blocked until one of the following occurs:
A module or a driver responds with an M_IOCACK (ack, positive acknowledgment) message or an M_IOCNAK (nak, negative acknowledgment) message.
No message is received and the request times out.
The ioctl(2) is interrupted by the user process.
For an I_STR, the STREAMS module or driver that generates a positive acknowledgment message can also return data to the process in the message. An alternate means to return data is provided with transparent ioctl(2). If the stream head does not receive a positive or negative acknowledgment message in the specified time, the ioctl(2) call fails.
A module that receives an unrecognized M_IOCTL </function> message must pass it on unchanged. A driver that receives an unrecognized M_IOCTL must produce a negative acknowledgment.
The two STREAMS ioctl(2) mechanisms, I_STR and transparent, are described next. (Here, I_STR means the streamio(7I) I_STR command and implies the related STREAMS processing unless noted otherwise.) I_STR has a restricted format and restricted addressing for transferring ioctl(2)-related data between user and kernel space. It requires only a single pair of messages to complete ioctl(2) processing. The transparent mechanism is more general and has almost no restrictions on ioctl(2) data format and addressing. The transparent mechanism generally requires that multiple pairs of messages be exchanged between the stream head and module to complete the processing.
This is a rather simplistic view. There is nothing preventing a given ioctl(2) from being issued either directly (transparent) or by means of I_STR. Furthermore, ioctl(2) issued through I_STR potentially can require further processing of the form typically associated with transparent ioctl(2).