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