M_IOCDATA

The M_IOCDATA message is generated by the stream head and sent downstream as a response to an M_COPYIN or M_COPYOUT message. The message format is one M_IOCDATA message block followed by zero or more M_DATA blocks. The M_IOCDATA message block contains a copyresp(9S), defined in sys/stream.h.

#if     defined(_LP64)
struct copyresp {
	int      cp_cmd;          /* ioctl command (from ioc_cmd) */
	cred_t   *cp_cr;          /* full credentials (from ioc_cmd) */
	uint     cp_id;           /* ioctl id (from ioc_id) */
	uint     cp_flag;         /* see above */
	mblk_t   *cp_private;     /* private state information */
	caddr_t  cp_rval;         /* status of request: 0 -> success */
                           /*   non-zero -> failure */
};
#else
struct copyresp {
	int      cp_cmd;          /* ioctl command (from ioc_cmd) */
	cred_t   *cp_cr;          /* full credentials */
	uint     cp_id;           /* ioctl id (from ioc_id) */
	caddr_t  cp_rval          /* status of request: 0 -> success */
                           /*   non-zero -> failure */
	size_t   cp_pad1;
	uint     cp_pad2;
	mblk_t   *cp_private;     /* private state information */
	uint     cp_flag;         /* see above */
	int      cp_filler[3];
};
#endif  /* _LP64 */

The first three members of the structure correspond to those of the iocblk(9S) in the M_IOCTL message that allows the same message blocks to be reused for all of the related transparent messages (M_COPYIN, M_COPYOUT, M_IOCACK, M_IOCNAK). The cp_rval field contains the result of the request at the stream head. Zero indicates success and non-zero indicates failure. If failure is indicated, the module should not generate an M_IOCNAK message. It must abort all ioctl(2) processing, clean up its data structures, and return.

The cp_private field is copied from the cq_private field in the associated M_COPYIN or M_COPYOUT message. It is included in the M_IOCDATA message so the message can be self-describing. This is intended to simplify ioctl(2) processing by modules and drivers.

If the message is in response to an M_COPYIN message and success is indicated, the M_IOCDATA block is followed by M_DATA blocks containing the data copied in.

If an M_IOCDATA block is reused, any unused fields defined for the resultant message block should be cleared (particularly in an M_IOCACK or M_IOCNAK).

This message should not be queued by a module or driver unless it processes the data for the ioctl in some way.

M_IOCNAK

The M_IOCNAK message signals the negative acknowledgement (failure) of a previous M_IOCTL message. Its form is one M_IOCNAK block containing an iocblk(9S). The iocblk(9S) can contain a value in ioc_error to be returned to the user process in errno. Unlike the M_IOCACK, no user data or return value can be sent with this message. If any M_DATA blocks follow the M_IOCNAK block, the stream head ignores and frees them. When the stream head receives an M_IOCNAK, the outstanding ioctl(2) request, if any, fails. The format and use of this message type is described further under M_IOCTL.

M_PCPROTO

The M_IOCPROTO message is the same as the M_PROTO message type, except for the priority and the following additional attributes. When an M_PCPROTO message is placed on a queue, its service procedure is always enabled. The stream head allows only one M_PCPROTO message to be placed in its read queue at a time. If an M_PCPROTO message is already in the queue when another arrives, the second message is discarded and its message blocks freed.

This message is intended to allow data and control information to be sent outside the normal flow control constraints.

getmsg(2) and putmsg(2) refer to messages as high priority messages.

M_PCRSE

The M_PCRSE message is reserved for internal use. Modules that do not recognize this message must pass it on. Drivers that do not recognize it must free it.

M_PCSIG

The M_PCSIG message is the same as the M_SIG message, except for the priority. M_PCSIG is often preferable to M_SIG especially in TTY applications, because M_SIG may be queued while M_PCSIG is more likely to get through quickly. For example, if an M_SIG message is generated when the DEL (delete) key is pressed on the terminal and the user has already typed ahead, the M_SIG message becomes queued and the user does not get the call until too late, becoming impossible to kill or interrupt a process by pressing a delete key.

M_READ

The M_READ message is generated by the stream head and sent downstream for a read(2) if no messages are waiting to be read at the stream head and if read notification has been enabled. Read notification is enabled with the SO_MREADON flag of the M_SETOPTS message and disabled by use of the SO_MREADOFF flag.

The message content is set to the value of the nbyte parameter (the number of bytes to be read) in read(2).

M_READ notifies modules and drivers of the occurrence of a read. It also supports communication between streams that reside in separate processors. The use of the M_READ message is developer dependent. Modules may take specific action and pass on or free the M_READ message. Modules that do not recognize this message must pass it on. All other drivers may or may not take action and then free the message.

This message cannot be generated by a user-level process and should not be generated by a module or driver. It is always discarded if passed to the stream head.

SO_MREADOFF and M_STOP

The SO_MREADOFF and M_STOP messages request devices to start or stop their output. They are used to produce momentary pauses in a device's output, not to turn devices on or off.

The message format is not defined by STREAMS and its use is developer dependent. These messages may be considered special cases of an M_CTL message. These messages cannot be generated by a user-level process and each is always discarded if passed to the stream head.

SO_MREADOFFI and M_STOPI

The SO_MREADOFFI and M_STOPI messages are the same as SO_MREADOFF and M_STOP except that SO_MREADOFFI and M_STOPI are used to start and stop input.

M_UNHANGUP

The M_UNHANGUP message reconnects the carrier after it has been dropped.