minnie.tuhs.org/unixen.tar/unixen/PDP-11/Trees/V6/usr/doc/unix/p5

Text File | 1975-06-26 | 7.0 KB | 206 lines

.s1
7. Traps
.es
The \*sPDP\*n-11 hardware detects a number of program faults,
such as references to non-existent memory, unimplemented instructions,
and odd addresses used where an even address is required.
Such faults cause the processor to trap to a system routine.
When an illegal action is caught,
unless other arrangements have been made,
the system terminates the process and writes the
user's image
on file \fIcore\fR in the current directory.
A debugger can be used to determine
the state of the program at the time of the fault.
.pg
Programs which are looping, which produce unwanted output, or about which
the user has second thoughts may be halted by the use of the
.ft I
interrupt
.ft R
signal, which is generated by typing the ``delete''
character.
Unless special action has been taken, this
signal simply causes the program to cease execution
without producing a core image file.
.pg
There is also a \fIquit\fR signal which
is used to force a core image to be produced.
Thus programs which loop unexpectedly may be
halted and the core image examined without prearrangement.
.pg
The hardware-generated faults
and the interrupt and quit signals
can, by request, be either ignored or caught by the process.
For example,
the Shell ignores quits to prevent
a quit from logging the user out.
The editor catches interrupts and returns
to its command level.
This is useful for stopping long printouts
without losing work in progress (the editor
manipulates a copy of the file it is editing).
In systems without floating point hardware,
unimplemented instructions are caught
and floating point instructions are
interpreted.
.s1
8. Perspective
.es
Perhaps paradoxically,
the success of \*sUNIX\*n
is largely due to the fact that it was not
designed to meet any
predefined objectives.
The first version was written when one of us
(Thompson),
dissatisfied with the available computer facilities,
discovered a little-used \*sPDP\*n-7
and set out to create a more
hospitable environment.
This essentially personal effort was
sufficiently successful
to gain the interest of the remaining author
and others,
and later to justify the acquisition
of the \*sPDP\*n-11/20, specifically to support
a text editing and formatting system.
When in turn the 11/20 was outgrown,
\*sUNIX\*n
had proved useful enough to persuade management to
invest in the \*sPDP\*n-11/45.
Our goals throughout the effort,
when articulated at all, have always concerned themselves
with building a comfortable relationship with the machine
and with exploring ideas and inventions in operating systems.
We have not been faced with the need to satisfy someone
else's requirements,
and for this freedom we are grateful.
.pg
Three considerations which influenced the design of \*sUNIX\*n
are visible in retrospect.
.pg
First:
since we are programmers,
we naturally designed the system to make it easy to
write, test, and run programs.
The most important expression of our desire for
programming convenience
was that the system
was arranged for interactive use,
even though the original version only
supported one user.
We believe that a properly-designed
interactive system is much more
productive
and satisfying to use than a ``batch'' system.
Moreover such a system is rather easily
adaptable to non-interactive use, while the converse is not true.
.pg
Second:
there have always been fairly severe size constraints
on the system and its software.
Given the partially antagonistic desires for reasonable efficiency and
expressive power,
the size constraint has encouraged
not only economy but a certain elegance of design.
This may be a thinly disguised version of the ``salvation
through suffering'' philosophy,
but in our case it worked.
.pg
Third: nearly from the start, the system was able to, and did, maintain itself.
This fact is more important than it might seem.
If designers of a system are forced to use that system
they quickly become aware of its functional and superficial deficiencies
and are strongly motivated to correct them before it is too late.
Since all source programs were always available
and easily modified on-line,
we were willing to revise and rewrite the system and its software
when new ideas were invented, discovered,
or suggested by others.
.pg
The aspects of \*sUNIX\*n
discussed in this paper exhibit clearly
at least the first two of these
design considerations.
The interface to the file
system, for example, is extremely convenient from
a programming standpoint.
The lowest possible interface level is designed
to eliminate distinctions
between
the various devices and files and between
direct and sequential access.
No large ``access method'' routines
are required
to insulate the programmer from the
system calls;
in fact all user programs either call the system
directly or
use a small library program, only tens of instructions long,
which buffers a number of characters
and reads or writes them all at once.
.pg
Another important aspect of programming
convenience is that there are no ``control blocks''
with a complicated structure partially maintained by
and depended on by the file system or other system calls.
Generally speaking, the contents of a program's address space
are the property of the program, and we have tried to
avoid placing restrictions
on the data structures within that address space.
.pg
Given the requirement
that all programs should be usable with any file or
device as input or output,
it is also desirable
from a space-efficiency standpoint
to push device-dependent considerations
into the operating system itself.
The only alternatives seem to be to load
routines for dealing with each device
with all programs, which is expensive in space,
or to depend on some means of dynamically linking to
the routine appropriate to each device when it is actually
needed,
which is expensive either in overhead or in hardware.
.pg
Likewise,
the process control scheme and command interface
have proved both convenient and efficient.
Since the Shell operates as an ordinary, swappable
user program,
it consumes no wired-down space in the system proper,
and it may be made as powerful as desired
at little cost.
In particular,
given the framework in which the Shell executes
as a process which spawns other processes to
perform commands,
the notions of I/O redirection, background processes,
command files, and user-selectable system interfaces
all become essentially trivial to implement.
.s2
8.1 Influences
.es
The success of \*sUNIX\*n lies
not so much in new inventions
but rather in the full exploitation of a carefully selected
set of fertile ideas,
and especially in showing that
they can be keys to the implementation of a small
yet powerful operating system.
.pg
The
.it fork
operation, essentially as we implemented it, was
present in the Berkeley time sharing system\*r.
On a number of points we were influenced by Multics,
which suggested the particular form of the I/O system calls\*r
and both the name of the Shell and its general functions.
The notion that the Shell should create a process
for each command was also suggested to us by
the early design of Multics, although in that
system it was later dropped for efficiency reasons.
A similar scheme is used by \*sTENEX\*n\*r.