1MPXIO(5) File Formats Manual MPXIO(5)
2
6 mpxio - multiplexed i/o
7
9 #include <sys/mx.h>
10 #include <sgtty.h>
12
14 Data transfers on mpx files (see mpx(2)) are multiplexed by imposing a
15 record structure on the io stream. Each record represents data
16 from/to a particular channel or a control or status message associated
17 with a particular channel.
18 The prototypical data record read from an mpx file is as follows
20 struct input_record {
22 short index;
23 short count;
24 short ccount;
25 char data[];
26 };
27 where index identifies the channel, and count specifies the number of
29 characters in data. If count is zero, ccount gives the size of data,
30 and the record is a control or status message. Although count or
31 ccount might be odd, the operating system aligns records on short (i.e.
32 16-bit) boundaries by skipping bytes when necessary.
33 Data written to an mpx file must be formatted as an array of record
35 structures defined as follows
36 struct output_record {
38 short index;
39 short count;
40 short ccount;
41 char *data;
42 };
43 where the data portion of the record is referred to indirectly and the
45 other cells have the same interpretation as in input_record.
46 The control messages listed below may be read from a multiplexed file
48 descriptor. They are presented as two 16-bit integers: the first num‐
49 ber is the message code (defined in <sys/mx.h>), the second is an
50 optional parameter meaningful only with M_WATCH and M_BLK.
51 M_WATCH - a process `wants to attach' on this channel. The second
53 parameter is the 16-bit user-id of the process that executed
54 the open.
55 M_CLOSE - the channel is closed. This message is generated when
56 the last file descriptor referencing a channel is closed.
57 The detach command (see mpx(2) should be used in response to
58 this message.
59 M_EOT - indicates logical end of file on a channel. If the chan‐
60 nel is joined to a typewriter, EOT (control-d) will cause the
61 M_EOT message under the conditions specified in tty(4) for
62 end of file. If the channel is attached to a process, M_EOT
63 will be generated whenever the process writes zero bytes on
64 the channel.
65 M_BLK - if non-blocking mode has been enabled on an mpx file
66 descriptor xd by executing ioctl(xd, MXNBLK, 0), write opera‐
67 tions on the file are truncated in the kernel when internal
68 queues become full. This is done on a per-channel basis: the
69 parameter is a count of the number of characters not trans‐
70 ferred to the channel on which M_BLK is received.
71 M_UBLK - is generated for a channel after M_BLK when the internal
72 queues have drained below a threshold.
73 Two other messages may be generated by the kernel. As with other mes‐
75 sages, the first 16-bit quantity is the message code.
76 M_OPEN - is generated in conjunction with `listener' mode (see
78 mpx(2)). The uid of the calling process follows the message
79 code as with M_WATCH. This is followed by a null-terminated
80 string which is the name of the file being opened.
81 M_IOCTL - is generated for a channel connected to a process when
82 that process executes the ioctl(fd, cmd, &vec) call on the
83 channel file descriptor. The M_IOCTL code is followed by the
84 cmd argument given to ioctl followed by the contents of the
85 structure vec. It is assumed, not needing a better compro‐
86 mise at this time, that the length of vec is determined by
87 sizeof (struct sgttyb) as declared in <sgtty.h>.
88 Two control messages are understood by the operating system. M_EOT may
90 be sent through an mpx file to a channel. It is equivalent to propa‐
91 gating a zero-length record through the channel; i.e. the channel is
92 allowed to drain and the process or device at the other end receives a
93 zero-length transfer before data starts flowing through the channel
94 again. M_IOCTL can also be sent through a channel. The format is
95 identical to that described above.
96 MPXIO(5)