glenda.party
term% ls -F
term% pwd
$home/manuals/unix_v8/4/mesg
term% cat index.txt
MESG(4)                    Kernel Interfaces Manual                    MESG(4)



NAME
       mesg, rmesg - message line discipline modules

SYNOPSIS
       #include <sys/stream.h>

DESCRIPTION
       After  the  mesg_ld  line discipline module has been pushed on a stream
       (see stream(4)), all data and control blocks appearing  on  the  stream
       are turned into structured messages to be read by the user process, and
       information written on the stream is interpreted  as  messages  in  the
       same  format.   The  rmesg_ld  line discipline is exactly the opposite:
       writes, and control operations, on the stream are turned into data mes‐
       sages, and arriving data messages are turned into controls.

       Messages  written on a stream are interpreted as containing a header of
       the form

            struct {
                 short     type;
                 short     size;
            };

       followed by the contents of the message.  The size is the size  of  the
       message  exclusive of header.  It is limited, but to a large number (at
       least 4KB).  Messages may be written piecemeal,  and  several  messages
       may  be  written  at  once,  but messages will be read at most one at a
       time.  If an impossible message is written, the stream is shut down.

       These message types are possible:

       M_DATA   (0) Ordinary data.

       M_BREAK  (01) A line break on an RS232-style  asynchronous  connection.
                No associated data.

       M_HANGUP (02)  When  received,  indicates  that the other side has gone
                away.  It is interpreted by the message processor as  well  as
                transmitted,  and  after it is read the stream is useless.  No
                associated data.

       M_DELIM  (03) A delimiter that introduces  a  record  boundary  in  the
                data.  No associated data.

       M_IOCTL  (06)  An  ioctl(4) request.  The associated data is an integer
                containing the ioctl code, followed by the object passed  with
                the ioctl call that generated the message.  It is mandatory to
                reply with M_IOCACK or M_IOCNAK.

       M_DELAY  (07) A real-time delay.  One byte of data, giving  the  number
                of sixtieths (fiftieths) of a second delay time.

       M_CTL    (010) Device-specific control message.

       M_SIGNAL (0101) Generate signal number given in the 1-byte message.

       M_FLUSH  (0102) Flush input and output queue if possible.

       M_STOP   (0103)  Stop  transmission  immediately (used, for example, in
                conjunction with XON-XOFF flow control.

       M_START  (0104) Restart transmission after M_STOP.

       M_IOCACK (0105) Positive acknowledgement of M_IOCTL  message.   At  the
                other  end,  any  included  data  will  be  stored through the
                pointer given in the ioctl call.

       M_IOCNAK (0106) Negative acknowledgement of M_IOCTL.  A 1-byte message,
                if  present,  will  be used as the return code for the failing
                ioctl.

       M_CLOSE  (0107) Used internally in Datakit call supervision.

SEE ALSO
       stream(4)

BUGS
       The format of arguments to M_IOCTL is  machine  dependent.   Sufficient
       unto the day is the nonportability thereof.
       If incorrectly formatted data is written to mesg, the stream may be ir‐
       retrievably clogged.



                                                                       MESG(4)