236 lines
7.5 KiB
Plaintext
236 lines
7.5 KiB
Plaintext
|
.\" This module is believed to contain source code proprietary to AT&T.
|
||
|
.\" Use and redistribution is subject to the Berkeley Software License
|
||
|
.\" Agreement and your Software Agreement with AT&T (Western Electric).
|
||
|
.\"
|
||
|
.\" @(#)p5 8.1 (Berkeley) 6/8/93
|
||
|
.\"
|
||
|
.\" $FreeBSD$
|
||
|
.SH
|
||
|
VII. TRAPS
|
||
|
.PP
|
||
|
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.
|
||
|
Unless other arrangements have been made,
|
||
|
an illegal action causes the system
|
||
|
to terminate the process and to write its
|
||
|
image
|
||
|
on file
|
||
|
.UL core
|
||
|
in the current directory.
|
||
|
A debugger can be used to determine
|
||
|
the state of the program at the time of the fault.
|
||
|
.PP
|
||
|
Programs that are looping, that produce unwanted output, or about which
|
||
|
the user has second thoughts may be halted by the use of the
|
||
|
.UL interrupt
|
||
|
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
|
||
|
.UL core
|
||
|
file.
|
||
|
There is also a
|
||
|
.UL quit
|
||
|
signal
|
||
|
used to force an image file to be produced.
|
||
|
Thus programs that loop unexpectedly may be
|
||
|
halted and the remains inspected without prearrangement.
|
||
|
.PP
|
||
|
The hardware-generated faults
|
||
|
and the interrupt and quit signals
|
||
|
can, by request, be either ignored or caught by a 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.
|
||
|
.SH
|
||
|
VIII. PERSPECTIVE
|
||
|
.PP
|
||
|
Perhaps paradoxically,
|
||
|
the success of
|
||
|
the
|
||
|
.UX
|
||
|
system
|
||
|
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 other author
|
||
|
and several colleagues,
|
||
|
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,
|
||
|
the system
|
||
|
had proved useful enough to persuade management to
|
||
|
invest in the \*sPDP\*n-11/45,
|
||
|
and later in the
|
||
|
\*sPDP\*n-11/70 and Interdata 8/32 machines,
|
||
|
upon which it developed to its present form.
|
||
|
Our goals throughout the effort,
|
||
|
when articulated at all, have always been to build
|
||
|
a comfortable relationship with the machine
|
||
|
and to explore ideas and inventions in operating systems
|
||
|
and other software.
|
||
|
We have not been faced with the need to satisfy someone
|
||
|
else's requirements,
|
||
|
and for this freedom we are grateful.
|
||
|
.PP
|
||
|
Three considerations that influenced the design of
|
||
|
.UX
|
||
|
are visible in retrospect.
|
||
|
.PP
|
||
|
First:
|
||
|
because 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 noninteractive use, while the converse is not true.
|
||
|
.PP
|
||
|
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 also a certain elegance of design.
|
||
|
This may be a thinly disguised version of the ``salvation
|
||
|
through suffering'' philosophy,
|
||
|
but in our case it worked.
|
||
|
.PP
|
||
|
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.
|
||
|
Because 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.
|
||
|
.PP
|
||
|
The aspects of
|
||
|
.UX
|
||
|
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, less than a page long,
|
||
|
that buffers a number of characters
|
||
|
and reads or writes them all at once.
|
||
|
.PP
|
||
|
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.
|
||
|
.PP
|
||
|
Given the requirement
|
||
|
that all programs should be usable with any file or
|
||
|
device as input or output,
|
||
|
it is also desirable
|
||
|
to push device-dependent considerations
|
||
|
into the operating system itself.
|
||
|
The only alternatives seem to be to load,
|
||
|
with all programs,
|
||
|
routines for dealing with each device,
|
||
|
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.
|
||
|
.PP
|
||
|
Likewise,
|
||
|
the process-control scheme and the command interface
|
||
|
have proved both convenient and efficient.
|
||
|
Because 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 that 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.
|
||
|
.SH
|
||
|
Influences
|
||
|
.PP
|
||
|
The success of
|
||
|
.UX
|
||
|
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.
|
||
|
.PP
|
||
|
The
|
||
|
.UL fork
|
||
|
operation, essentially as we implemented it, was
|
||
|
present in the \*sGENIE\*n time-sharing system.
|
||
|
.[
|
||
|
lampson deutsch 930 manual 1965 system preliminary
|
||
|
.]
|
||
|
On a number of points we were influenced by Multics,
|
||
|
which suggested the particular form of the I/O system calls
|
||
|
.[
|
||
|
multics input output feiertag organick
|
||
|
.]
|
||
|
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.
|
||
|
.[
|
||
|
bobrow burchfiel tenex
|
||
|
.]
|