|
|
1.1 root 1: .\" @(#)mpxio.5 4.1 (Berkeley) 5/15/85
2: .\"
3: .TH MPXIO 5
4: .AT 3
5: .SH NAME
6: mpxio \- multiplexed i/o
7: .SH SYNOPSIS
8: .B #include <sys/mx.h>
9: .PP
10: .B #include <sgtty.h>
11: .SH DESCRIPTION
12: Data transfers on
13: mpx files
14: (see
15: .IR mpx (2))
16: are multiplexed by
17: imposing
18: a record structure on the io stream.
19: Each record represents data
20: from/to
21: a particular channel or
22: a control or status message associated with a particular channel.
23: .PP
24: The prototypical data record read from an mpx file is as follows
25: .PP
26: .in +.5i
27: .nf
28: struct input_record {
29: short index;
30: short count;
31: short ccount;
32: char data[];
33: };
34: .PP
35: .fi
36: where
37: .I index
38: identifies the channel,
39: and
40: .I count
41: specifies the number of characters in
42: .I data.
43: If
44: .I count
45: is zero,
46: .I ccount
47: gives the size of
48: .I data,
49: and the record is a control or status message.
50: Although
51: .I count
52: or
53: .I ccount
54: might be odd,
55: the operating system aligns records
56: on short (i.e. 16\-bit) boundaries
57: by skipping bytes when necessary.
58: .PP
59: Data written to an mpx file must be formatted as an array
60: of record structures defined as follows
61: .PP
62: .in +.5i
63: .nf
64: struct output_record {
65: short index;
66: short count;
67: short ccount;
68: char *data;
69: };
70: .fi
71: .PP
72: where the data portion of the record is referred
73: to indirectly and the other cells have the same interpretation
74: as in
75: .I input_record.
76: .PP
77: The
78: control messages listed below may be read from
79: a multiplexed file descriptor.
80: They are presented as two 16-bit integers:
81: the first number is the message code
82: (defined in
83: .IR <sys/mx.h> ),
84: the second is an optional parameter meaningful
85: only with M_WATCH, M_BLK, and M_SIG.
86: .PP
87: .TP "\w'M_WATCH 'u"
88: M_WATCH
89: a process `wants to attach' on this channel.
90: The second parameter is the 16-bit
91: user-id of the process that executed the open.
92: .TP
93: M_CLOSE
94: the channel is closed.
95: This message is generated when the last
96: file descriptor referencing
97: a channel is closed.
98: The
99: .I detach
100: command
101: (see
102: .IR mpx (2)
103: should be used in response to this message.
104: .TP
105: M_EOT
106: indicates logical end of file on a channel.
107: If the channel is joined to a typewriter,
108: EOT (control-d)
109: will cause the M_EOT message
110: under the conditions specified in
111: .IR tty (4)
112: for end of file.
113: If the channel is attached to a process,
114: M_EOT will be generated whenever the process
115: writes zero bytes on the channel.
116: .TP
117: M_BLK
118: if non-blocking mode has been enabled on an
119: mpx file descriptor
120: .I xd
121: by executing
122: .IR "ioctl(xd, MXNBLK, 0)" ,
123: write operations on the file are truncated in the kernel
124: when internal queues become full.
125: This is done on a per-channel basis:
126: the parameter
127: is a count of the number of characters
128: not transferred to the channel on which
129: M_BLK is received.
130: .TP
131: M_UBLK
132: is generated for a channel
133: after M_BLK when the internal queues have
134: drained below a threshold.
135: .TP
136: M_SIG
137: is generated instead of a normal asynchronous
138: signal on channels that are joined to typewriters.
139: The parameter is the signal number.
140: .PP
141: Two other messages may be generated by the kernel.
142: As with other messages, the first
143: 16-bit quantity is the message code.
144: .br
145: .TP "\w'M_IOCTL 'u"
146: M_OPEN
147: is generated in conjunction with
148: `listener' mode (see
149: .IR mpx (2)).
150: The uid of the calling process follows the message code
151: as with M_WATCH.
152: This is followed by a null-terminated string
153: which is the name of the file being opened.
154: .TP
155: M_IOCTL
156: is generated for a channel connected
157: to a process
158: when that process executes the
159: .I "ioctl(fd, cmd, &vec)"
160: call on the channel file descriptor.
161: The M_IOCTL code is followed by
162: the
163: .I cmd
164: argument given to
165: .I ioctl
166: followed by
167: the contents of the structure
168: .I vec.
169: It is assumed,
170: not needing a better compromise at this time,
171: that the length of
172: .I vec
173: is determined by
174: .I "sizeof (struct sgttyb)"
175: as declared in
176: .IR <sgtty.h> .
177: .in -1i
178: .PP
179: Two control messages are understood by the operating system.
180: M_EOT may be sent through an mpx file to a channel.
181: It is equivalent to propagating a zero-length record
182: through the channel;
183: i.e. the channel is allowed to drain and the process or
184: device at the other end receives a zero-length
185: transfer before data starts flowing through the channel again.
186: M_IOANS can also be sent through a channel to reply to a M_IOCTL.
187: The format is identical to that received from M_IOCTL.
188: .SH SEE ALSO
189: mpx(2)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.