![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to xindex.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / index / Junk|
Return to xindex.ms CVS log | Up to [Research Unix] / researchv10dc / vol2 / index / Junk |
1.1 root 1: .so ../ADM/mac
2: .Tm index
3: .XX 48 667 "Index"
4: .Tm index
5: .TL
6: Index
7: .AU
8: L. L. Cherry
9: .2C
10: .NH
11: Introduction
12: .PP
13: The part of the
14: .UX
15: operating system that deals with terminals
16: and other character devices
17: has always been complicated.
18: In recent versions of the system it has become even more so, for
19: two reasons.
20: .IP 1)
21: Network connections require protocols more ornate than are
22: easily accommodated in the existing structure.
23: A notion of ``line disciplines'' was only partially successful,
24: mostly because in the traditional system only one line discipline
25: can be active at a time.
26: .IP 2)
27: The fundamental data structure of the traditional character I/O system,
28: a queue of individual characters (the ``clist''),
29: is costly because it accepts and dispenses characters one at a time.
30: Attempts to avoid overhead by bypassing the mechanism entirely
31: or by introducing
32: .I "ad hoc
33: routines succeeded in speeding up the
34: code at the expense of regularity.
35: .LP
36: Patchwork solutions to specific problems were
37: destroying the modularity of this part of the system.
38: The time was ripe to redo the whole thing.
39: This paper describes the new organization.
40: .PP
41: The system described here runs on about 20 machines
42: in the Information Sciences Research Division of Bell Laboratories.
43: Although it is being investigated by other parts of Bell Labs,
44: it is not generally available.
45: .Tm overview
46: .NH
47: Overview
48: .PP
49: This section summarizes the nomenclature, components, and mechanisms
50: of the new I/O system.
51: .NH 2
52: .Tm streams
53: .I "Streams
54: .PP
55: A
56: .I "stream
57: is a full-duplex connection between a user's process and a device
58: or pseudo-device.
59: It consists of several linearly connected processing modules,
60: and is analogous to a Shell pipeline, except that
61: data flows in both directions.
62: The modules in a stream communicate almost exclusively
63: by passing messages to their neighbors.
64: Except for some conventional variables used for flow control, modules do not
65: require access to the storage of their neighbors.
66: Moreover, a module provides only one entry point to each neighbor, namely
67: a routine that accepts messages.
68: .PP
69: At the end of the stream closest to the process
70: is a set of routines that provide the interface to the rest of the system.
71: A user's
72: .I "write
73: and
74: I/O control requests are turned into messages sent to the stream,
75: and
76: .I "read
77: requests take data from the stream and pass it to the user.
78: At the other end of the stream is a
79: device driver module.
80: Here, data arriving from the stream is sent to the device;
81: characters and state transitions detected by the device are
82: composed into messages and sent into the stream towards the user program.
83: Intermediate modules process the messages in various ways.
84: .PP
85: The two end modules in a stream become connected automatically when
86: the device is opened;
87: intermediate modules are attached dynamically by request of the user's program.
88: Stream processing modules are
89: symmetrical; their read and write interfaces are identical.
90: .NH 2
91: .Tm queues
92: .I "Queues
93: .PP
94: Each stream processing module consists of a pair of
95: .Tm queues
96: .I "queues,
97: one for each direction.
98: A queue comprises not only a data queue proper, but also two routines
99: and some status information.
100: One routine is the
101: .I "put procedure,
102: which is called by its neighbor
103: to place messages on the data queue.
104: The other, the
105: .I "service procedure,
106: is scheduled to execute whenever there is work for it to do.
107: The status information includes a pointer to the next queue downstream,
108: various flags, and a pointer to additional state information required
109: by the instantiation of the queue.
110: .Tm queues
111: Queues are allocated in such a way that the routines associated with
112: one half of a stream module may find the queue associated with the other half.
113: (This is used, for example, in generating echos for terminal input.)
114: .NH 2
115: .Tm message blocks
116: .I "Message blocks
117: .Tm queues
118: .PP
119: The objects passed between queues are blocks obtained from an allocator.
120: Each contains a
121: .I "read pointer,
122: a
123: .I "write pointer,
124: and a
125: .I "limit pointer,
126: which specify respectively the beginning of information being passed, its end,
127: and a bound on the extent to which the write pointer may be increased.
128: .PP
129: The header of a block specifies its type; the most common blocks contain
130: data.
131: There are also control blocks of various kinds,
132: all with the same form as data blocks and obtained from the same
133: allocator.
134: For example, there are control blocks to introduce delimiters
135: into the data stream, to pass user I/O control requests, and to announce
136: special conditions such as line break and carrier loss on terminal
137: devices.
138: .PP
139: Although data blocks arrive in discrete units
140: at the processing modules,
141: boundaries between them are semantically insignificant;
142: standard subroutines may try to coalesce adjacent
143: data blocks in the same queue.
144: Control blocks, however, are never coalesced.
145: .NH 2
146: .Tm scheduling
147: .I "Scheduling
148: .PP
149: Although each queue module behaves in some ways like a separate process,
150: it is not a real process; the system saves no state information
151: for a queue module that is not running.
152: In particular queue processing routines do not block when they cannot proceed,
153: but must explicitly return control.
154: A queue may be
155: .I "enabled
156: by mechanisms described below.
157: When a queue becomes enabled, the system will, as soon as convenient,
158: call its service procedure entry,
159: which removes successive blocks
160: from the associated data queue, processes them, and places them on the
161: next queue by calling its put procedure.
162: When there are no more blocks to process, or when the next queue becomes
163: full, the service procedure returns to the system.
164: Any special state information must be saved explicitly.
165: .PP
166: Standard routines make enabling of queue modules largely automatic.
167: For example, the routine that puts a block on a queue
168: enables the queue service routine if the queue was empty.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.