Commit | Line | Data |
---|---|---|
9ddf7a71 DR |
1 | .s1 |
2 | 7. Traps | |
3 | .es | |
4 | The \*sPDP\*n-11 hardware detects a number of program faults, | |
5 | such as references to non-existent memory, unimplemented instructions, | |
6 | and odd addresses used where an even address is required. | |
7 | Such faults cause the processor to trap to a system routine. | |
8 | When an illegal action is caught, | |
9 | unless other arrangements have been made, | |
10 | the system terminates the process and writes the | |
11 | user's image | |
12 | on file \fIcore\fR in the current directory. | |
13 | A debugger can be used to determine | |
14 | the state of the program at the time of the fault. | |
15 | .pg | |
16 | Programs which are looping, which produce unwanted output, or about which | |
17 | the user has second thoughts may be halted by the use of the | |
18 | .ft I | |
19 | interrupt | |
20 | .ft R | |
21 | signal, which is generated by typing the ``delete'' | |
22 | character. | |
23 | Unless special action has been taken, this | |
24 | signal simply causes the program to cease execution | |
25 | without producing a core image file. | |
26 | .pg | |
27 | There is also a \fIquit\fR signal which | |
28 | is used to force a core image to be produced. | |
29 | Thus programs which loop unexpectedly may be | |
30 | halted and the core image examined without prearrangement. | |
31 | .pg | |
32 | The hardware-generated faults | |
33 | and the interrupt and quit signals | |
34 | can, by request, be either ignored or caught by the process. | |
35 | For example, | |
36 | the Shell ignores quits to prevent | |
37 | a quit from logging the user out. | |
38 | The editor catches interrupts and returns | |
39 | to its command level. | |
40 | This is useful for stopping long printouts | |
41 | without losing work in progress (the editor | |
42 | manipulates a copy of the file it is editing). | |
43 | In systems without floating point hardware, | |
44 | unimplemented instructions are caught | |
45 | and floating point instructions are | |
46 | interpreted. | |
47 | .s1 | |
48 | 8. Perspective | |
49 | .es | |
50 | Perhaps paradoxically, | |
51 | the success of \*sUNIX\*n | |
52 | is largely due to the fact that it was not | |
53 | designed to meet any | |
54 | predefined objectives. | |
55 | The first version was written when one of us | |
56 | (Thompson), | |
57 | dissatisfied with the available computer facilities, | |
58 | discovered a little-used \*sPDP\*n-7 | |
59 | and set out to create a more | |
60 | hospitable environment. | |
61 | This essentially personal effort was | |
62 | sufficiently successful | |
63 | to gain the interest of the remaining author | |
64 | and others, | |
65 | and later to justify the acquisition | |
66 | of the \*sPDP\*n-11/20, specifically to support | |
67 | a text editing and formatting system. | |
68 | When in turn the 11/20 was outgrown, | |
69 | \*sUNIX\*n | |
70 | had proved useful enough to persuade management to | |
71 | invest in the \*sPDP\*n-11/45. | |
72 | Our goals throughout the effort, | |
73 | when articulated at all, have always concerned themselves | |
74 | with building a comfortable relationship with the machine | |
75 | and with exploring ideas and inventions in operating systems. | |
76 | We have not been faced with the need to satisfy someone | |
77 | else's requirements, | |
78 | and for this freedom we are grateful. | |
79 | .pg | |
80 | Three considerations which influenced the design of \*sUNIX\*n | |
81 | are visible in retrospect. | |
82 | .pg | |
83 | First: | |
84 | since we are programmers, | |
85 | we naturally designed the system to make it easy to | |
86 | write, test, and run programs. | |
87 | The most important expression of our desire for | |
88 | programming convenience | |
89 | was that the system | |
90 | was arranged for interactive use, | |
91 | even though the original version only | |
92 | supported one user. | |
93 | We believe that a properly-designed | |
94 | interactive system is much more | |
95 | productive | |
96 | and satisfying to use than a ``batch'' system. | |
97 | Moreover such a system is rather easily | |
98 | adaptable to non-interactive use, while the converse is not true. | |
99 | .pg | |
100 | Second: | |
101 | there have always been fairly severe size constraints | |
102 | on the system and its software. | |
103 | Given the partially antagonistic desires for reasonable efficiency and | |
104 | expressive power, | |
105 | the size constraint has encouraged | |
106 | not only economy but a certain elegance of design. | |
107 | This may be a thinly disguised version of the ``salvation | |
108 | through suffering'' philosophy, | |
109 | but in our case it worked. | |
110 | .pg | |
111 | Third: nearly from the start, the system was able to, and did, maintain itself. | |
112 | This fact is more important than it might seem. | |
113 | If designers of a system are forced to use that system | |
114 | they quickly become aware of its functional and superficial deficiencies | |
115 | and are strongly motivated to correct them before it is too late. | |
116 | Since all source programs were always available | |
117 | and easily modified on-line, | |
118 | we were willing to revise and rewrite the system and its software | |
119 | when new ideas were invented, discovered, | |
120 | or suggested by others. | |
121 | .pg | |
122 | The aspects of \*sUNIX\*n | |
123 | discussed in this paper exhibit clearly | |
124 | at least the first two of these | |
125 | design considerations. | |
126 | The interface to the file | |
127 | system, for example, is extremely convenient from | |
128 | a programming standpoint. | |
129 | The lowest possible interface level is designed | |
130 | to eliminate distinctions | |
131 | between | |
132 | the various devices and files and between | |
133 | direct and sequential access. | |
134 | No large ``access method'' routines | |
135 | are required | |
136 | to insulate the programmer from the | |
137 | system calls; | |
138 | in fact all user programs either call the system | |
139 | directly or | |
140 | use a small library program, only tens of instructions long, | |
141 | which buffers a number of characters | |
142 | and reads or writes them all at once. | |
143 | .pg | |
144 | Another important aspect of programming | |
145 | convenience is that there are no ``control blocks'' | |
146 | with a complicated structure partially maintained by | |
147 | and depended on by the file system or other system calls. | |
148 | Generally speaking, the contents of a program's address space | |
149 | are the property of the program, and we have tried to | |
150 | avoid placing restrictions | |
151 | on the data structures within that address space. | |
152 | .pg | |
153 | Given the requirement | |
154 | that all programs should be usable with any file or | |
155 | device as input or output, | |
156 | it is also desirable | |
157 | from a space-efficiency standpoint | |
158 | to push device-dependent considerations | |
159 | into the operating system itself. | |
160 | The only alternatives seem to be to load | |
161 | routines for dealing with each device | |
162 | with all programs, which is expensive in space, | |
163 | or to depend on some means of dynamically linking to | |
164 | the routine appropriate to each device when it is actually | |
165 | needed, | |
166 | which is expensive either in overhead or in hardware. | |
167 | .pg | |
168 | Likewise, | |
169 | the process control scheme and command interface | |
170 | have proved both convenient and efficient. | |
171 | Since the Shell operates as an ordinary, swappable | |
172 | user program, | |
173 | it consumes no wired-down space in the system proper, | |
174 | and it may be made as powerful as desired | |
175 | at little cost. | |
176 | In particular, | |
177 | given the framework in which the Shell executes | |
178 | as a process which spawns other processes to | |
179 | perform commands, | |
180 | the notions of I/O redirection, background processes, | |
181 | command files, and user-selectable system interfaces | |
182 | all become essentially trivial to implement. | |
183 | .s2 | |
184 | 8.1 Influences | |
185 | .es | |
186 | The success of \*sUNIX\*n lies | |
187 | not so much in new inventions | |
188 | but rather in the full exploitation of a carefully selected | |
189 | set of fertile ideas, | |
190 | and especially in showing that | |
191 | they can be keys to the implementation of a small | |
192 | yet powerful operating system. | |
193 | .pg | |
194 | The | |
195 | .it fork | |
196 | operation, essentially as we implemented it, was | |
197 | present in the Berkeley time sharing system\*r. | |
198 | On a number of points we were influenced by Multics, | |
199 | which suggested the particular form of the I/O system calls\*r | |
200 | and both the name of the Shell and its general functions. | |
201 | The notion that the Shell should create a process | |
202 | for each command was also suggested to us by | |
203 | the early design of Multics, although in that | |
204 | system it was later dropped for efficiency reasons. | |
205 | A similar scheme is used by \*sTENEX\*n\*r. |