/share/doc/psd/01.cacm/p1

  1.\" This module is believed to contain source code proprietary to AT&T.
  2.\" Use and redistribution is subject to the Berkeley Software License
  3.\" Agreement and your Software Agreement with AT&T (Western Electric).
  4.\"
  5.\"	@(#)p1	8.1 (Berkeley) 6/8/93
  6.\"
  7.\" $FreeBSD$
  8.OH 'The UNIX Time-Sharing System''PSD:1-%'
  9.EH 'PSD:1-%''The UNIX Time-Sharing System'
 10.ds n \s+2
 11.hw above-mentioned
 12.ds s \s-2
 13.ds m \v'-.3'.\v'.3'
 14.TL
 15The UNIX
 16Time-Sharing System\f1\s10\v'-.2n'*\v'.2n'\s0\fP
 17.AU
 18D. M. Ritchie and K. Thompson
 19.AB
 20.FS
 21* Copyright 1974,
 22Association for Computing Machinery, Inc.,
 23reprinted by permission.
 24This is a revised version of an article
 25that appeared in Communications of the \*sACM\*n,
 26.IT 17 ,
 27No. 7 (July 1974), pp. 365-375.
 28That article was a
 29revised version of a paper presented
 30at the Fourth \*sACM\*n Symposium on Operating
 31Systems Principles,
 32\*sIBM\*n Thomas J. Watson Research Center,
 33Yorktown Heights,
 34New York,
 35October 15-17, 1973.
 36.FE
 37.UX
 38is a general-purpose, multi-user, interactive
 39operating system for the larger Digital Equipment Corporation
 40\*sPDP\*n-11 and
 41the Interdata 8/32 computers.
 42It offers a number of features
 43seldom found even in larger operating
 44systems, including
 45.IP i
 46A hierarchical file system incorporating
 47demountable volumes,
 48.IP ii
 49Compatible file, device, and inter-process I/O,
 50.IP iii
 51The ability to initiate asynchronous processes,
 52.IP iv
 53System command language selectable on a per-user basis,
 54.IP v
 55Over 100 subsystems including a dozen languages,
 56.IP vi
 57High degree of portability.
 58.LP
 59This paper discusses the nature
 60and implementation of the file system
 61and of the user command interface.
 62.AE
 63.NH
 64INTRODUCTION
 65.PP
 66There have been four versions of
 67the
 68.UX
 69time-sharing system.
 70.hy 12
 71The earliest (circa 1969-70) ran on
 72the Digital Equipment Corporation \*sPDP\*n-7 and -9 computers.
 73The second version ran on the unprotected
 74\*sPDP\*n-11/20 computer.
 75The third incorporated multiprogramming and ran
 76on the \*sPDP\*n-11/34, /40, /45, /60, and /70 computers;
 77it is the one described in the previously published version
 78of this paper, and is also the most widely used today.
 79.hy 14
 80This paper describes only the
 81fourth, current
 82system that runs on the \*sPDP\*n-11/70 and the
 83Interdata 8/32 computers.
 84In fact, the differences among the various systems is
 85rather small;
 86most of the revisions made to the originally published version of this
 87paper,
 88aside from those concerned with style,
 89had to do with details of the implementation of the file system.
 90.PP
 91Since
 92\*sPDP\*n-11
 93.UX
 94became operational
 95in February, 1971,
 96over 600 installations have been put into service.
 97Most of them are engaged in applications such as
 98computer science education,
 99the preparation and formatting of documents
100and other textual material,
101the collection and processing of trouble data
102from various switching machines within the Bell System,
103and recording and checking telephone service
104orders.
105Our own installation is used mainly for research
106in operating systems, languages,
107computer networks,
108and other topics in computer science, and also for
109document preparation.
110.PP
111Perhaps the most important achievement of
112.UX
113is to demonstrate
114that
115a powerful operating system for interactive use
116need not be expensive either in equipment or in human
117effort:
118it
119can run on hardware costing as little as $40,000, and
120less than two man-years were spent on the main system
121software.
122We hope, however, that users find
123that the
124most important characteristics of the system
125are its simplicity, elegance, and ease of use.
126.PP
127Besides the operating system proper, some major programs
128available under
129.UX
130are
131.DS
132.nf
133C compiler
134Text editor based on \*sQED\*n
135.[
136qed lampson
137.]
138Assembler, linking loader, symbolic debugger
139Phototypesetting and equation setting programs
140.[
141cherry kernighan typesetting mathematics cacm
142.]
143.[
144kernighan lesk ossanna document preparation bstj
145%Q This issue
146.]
147.fi
148.in +3n
149.ll -5n
150.ti -3n
151Dozens of languages including
152Fortran 77, Basic, Snobol, \*sAPL\*n, Algol 68, M6, \*sTMG\*n, Pascal
153.in
154.ll
155.DE
156There is a host of maintenance, utility, recreation and novelty programs,
157all written locally.
158The
159.UX
160user community, which numbers in the thousands,
161has contributed many more programs and languages.
162It is worth noting that the system is totally self-supporting.
163All
164.UX
165software is maintained on
166the
167system;
168likewise, this paper and all other
169documents
170in this issue
171were generated and formatted by the
172.UX
173editor and text formatting
174programs.
175.SH
176II. HARDWARE AND SOFTWARE ENVIRONMENT
177.PP
178The \*sPDP\*n-11/70 on which the Research
179.UX
180system is installed is a 16-bit
181word (8-bit byte) computer with 768K bytes of core memory;
182the system kernel
183occupies 90K bytes
184about equally divided between code
185and data tables.
186This system, however, includes a very large number of
187device drivers
188and enjoys a generous allotment
189of space for I/O buffers and system tables;
190a minimal system capable of running the software
191mentioned above can
192require as little as 96K bytes
193of core altogether.
194There are even larger installations;
195see the description of the
196\*sPWB/UNIX\*n systems,
197.[
198dolotta mashey workbench software engineering
199.]
200.[
201dolotta haight mashey workbench bstj
202%Q This issue
203.]
204for example.
205There are also much smaller, though somewhat restricted,
206versions of the system.
207.[
208lycklama microprocessor bstj
209%Q This issue
210.]
211.PP
212Our own \*sPDP\*n-11 has two
213200-Mb moving-head disks
214for file system storage and swapping.
215There are 20 variable-speed
216communications interfaces
217attached to 300- and 1200-baud data sets,
218and an additional 12 communication lines
219hard-wired to 9600-baud terminals and
220satellite computers.
221There are also several 2400- and 4800-baud
222synchronous communication interfaces
223used for machine-to-machine file transfer.
224Finally, there is a variety
225of miscellaneous
226devices including
227nine-track magnetic tape,
228a line printer,
229a voice synthesizer,
230a phototypesetter,
231a digital switching network,
232and a chess machine.
233.PP
234The preponderance of
235.UX
236software is written in the
237abovementioned C language.
238.[
239c programming language kernighan ritchie prentice-hall
240.]
241Early versions of the operating system were written in assembly language,
242but during the summer of 1973, it was rewritten in C.
243The size of the new system was about one-third greater
244than that of the old.
245Since the new system not only became much easier to
246understand and to modify but also
247included
248many functional improvements,
249including multiprogramming and the ability to
250share reentrant code among several user programs,
251we consider this increase in size quite acceptable.
252.SH
253III. THE FILE SYSTEM
254.PP
255The most important role of
256the system
257is to provide
258a file system.
259From the point of view of the user, there
260are three kinds of files: ordinary disk files,
261directories, and special files.
262.SH
2633.1 Ordinary files
264.PP
265A file
266contains whatever information the user places on it,
267for example, symbolic or binary
268(object) programs.
269No particular structuring is expected by the system.
270A file of text consists simply of a string
271of characters, with lines demarcated by the newline character.
272Binary programs are sequences of words as
273they will appear in core memory when the program
274starts executing.
275A few user programs manipulate files with more
276structure;
277for example, the assembler generates, and the loader
278expects, an object file in a particular format.
279However,
280the structure of files is controlled by
281the programs that use them, not by the system.
282.SH
2833.2 Directories
284.PP
285Directories provide
286the mapping between the names of files
287and the files themselves, and thus
288induce a structure on the file system as a whole.
289Each user has a directory of his own files;
290he may also create subdirectories to contain
291groups of files conveniently treated together.
292A directory behaves exactly like an ordinary file except that it
293cannot be written on by unprivileged programs, so that the system
294controls the contents of directories.
295However, anyone with
296appropriate permission may read a directory just like any other file.
297.PP
298The system maintains several directories
299for its own use.
300One of these is the
301.UL root
302directory.
303All files in the system can be found by tracing
304a path through a chain of directories
305until the desired file is reached.
306The starting point for such searches is often the
307.UL root .
308Other system directories contain all the programs provided
309for general use; that is, all the
310.IT commands .
311As will be seen, however, it is by no means necessary
312that a program reside in one of these directories for it
313to be executed.
314.PP
315Files are named by sequences of 14 or
316fewer characters.
317When the name of a file is specified to the
318system, it may be in the form of a
319.IT path
320.IT name ,
321which
322is a sequence of directory names separated by slashes, ``/\^'',
323and ending in a file name.
324If the sequence begins with a slash, the search begins in the
325root directory.
326The name
327.UL /alpha/beta/gamma
328causes the system to search
329the root for directory
330.UL alpha ,
331then to search
332.UL alpha
333for
334.UL beta ,
335finally to find
336.UL gamma
337in
338.UL beta .
339.UL \&gamma
340may be an ordinary file, a directory, or a special
341file.
342As a limiting case, the name ``/\^'' refers to the root itself.
343.PP
344A path name not starting with ``/\^'' causes the system to begin the
345search in the user's current directory.
346Thus, the name
347.UL alpha/beta
348specifies the file named
349.UL beta
350in
351subdirectory
352.UL alpha
353of the current
354directory.
355The simplest kind of name, for example,
356.UL alpha ,
357refers to a file that itself is found in the current
358directory.
359As another limiting case, the null file name refers
360to the current directory.
361.PP
362The same non-directory file may appear in several directories under
363possibly different names.
364This feature is called
365.IT linking ;
366a directory entry for a file is sometimes called a link.
367The
368.UX
369system
370differs from other systems in which linking is permitted
371in that all links to a file have equal status.
372That is, a file does not exist within a particular directory;
373the directory entry for a file consists merely
374of its name and a pointer to the information actually
375describing the file.
376Thus a file exists independently of any
377directory entry, although in practice a file is made to
378disappear along with the last link to it.
379.PP
380Each directory always has at least two entries.
381The name
382``\|\fB.\|\fP'' in each directory refers to the directory itself.
383Thus a program
384may read the current directory under the name ``\fB\|.\|\fP'' without knowing
385its complete path name.
386The name ``\fB\|.\|.\|\fP'' by convention refers to the parent of the
387directory in which it appears, that is, to the directory in which
388it was created.
389.PP
390The directory structure is constrained to have the form
391of a rooted tree.
392Except for the special entries ``\|\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP'', each directory
393must appear as an entry in exactly one other directory, which is its
394parent.
395The reason for this is to simplify the writing of programs
396that visit subtrees of the directory structure, and more
397important, to avoid the separation of portions of the hierarchy.
398If arbitrary links to directories were permitted, it would
399be quite difficult to detect when the last connection from
400the root to a directory was severed.
401.SH
4023.3 Special files
403.PP
404Special files constitute the most unusual feature of the
405.UX
406file system.
407Each supported I/O device
408is associated with at least one such file.
409Special files are read and written just like ordinary
410disk files, but requests to read or write result in activation of the associated
411device.
412An entry for each special file resides in directory
413.UL /dev ,
414although a link may be made to one of these files
415just as it may to an ordinary file.
416Thus, for example,
417to write on a magnetic tape
418one may write on the file
419.UL /dev/mt .
420Special files exist for each communication line, each disk,
421each tape drive,
422and for physical main memory.
423Of course,
424the active disks
425and the memory special file are protected from
426indiscriminate access.
427.PP
428There is a threefold advantage in treating
429I/O devices this way:
430file and device I/O
431are as similar as possible;
432file and device names have the same
433syntax and meaning, so that
434a program expecting a file name
435as a parameter can be passed a device
436name; finally,
437special files are subject to the same
438protection mechanism as regular files.
439.SH
4403.4 Removable file systems
441.PP
442Although the root of the file system is always stored on the same
443device,
444it is not necessary that the entire file system hierarchy
445reside on this device.
446There is a
447.UL mount
448system request with two arguments:
449the name of an existing ordinary file, and the name of a special
450file whose associated
451storage volume (e.g., a disk pack) should have the structure
452of an independent file system
453containing its own directory hierarchy.
454The effect of
455.UL mount
456is to cause
457references to the heretofore ordinary file
458to refer instead to the root directory
459of the file system on the removable volume.
460In effect,
461.UL mount
462replaces a leaf of the hierarchy tree (the ordinary file)
463by a whole new subtree (the hierarchy stored on the
464removable volume).
465After the
466.UL mount ,
467there is virtually no distinction
468between files on the removable volume and those in the
469permanent file system.
470In our installation, for example,
471the root directory resides
472on a small partition of one of
473our disk drives,
474while the other drive,
475which contains the user's files,
476is mounted by the system initialization
477sequence.
478A mountable file system is generated by
479writing on its corresponding special file.
480A utility program is available to create
481an empty file system,
482or one may simply copy an existing file system.
483.PP
484There is only one exception to the rule of identical
485treatment of files on different devices:
486no link may exist between one file system hierarchy and
487another.
488This restriction is enforced so as to avoid
489the elaborate bookkeeping
490that would otherwise be required to assure removal of the links
491whenever the removable volume is dismounted.
492.SH
4933.5 Protection
494.PP
495Although the access control scheme
496is quite simple, it has some unusual features.
497Each user of the system is assigned a unique
498user identification number.
499When a file is created, it is marked with
500the user \*sID\*n of its owner.
501Also given for new files
502is a set of ten protection bits.
503Nine of these specify
504independently read, write, and execute permission
505for the
506owner of the file,
507for other members of his group,
508and for all remaining users.
509.PP
510If the tenth bit is on, the system
511will temporarily change the user identification
512(hereafter, user \*sID\*n)
513of the current user to that of the creator of the file whenever
514the file is executed as a program.
515This change in user \*sID\*n is effective only
516during the execution of the program that calls for it.
517The set-user-\*sID\*n feature provides
518for privileged programs that may use files
519inaccessible to other users.
520For example, a program may keep an accounting file
521that should neither be read nor changed
522except by the program itself.
523If the set-user-\*sID\*n bit is on for the
524program, it may access the file although
525this access might be forbidden to other programs
526invoked by the given program's user.
527Since the actual user \*sID\*n
528of the invoker of any program
529is always available,
530set-user-\*sID\*n programs
531may take any measures desired to satisfy themselves
532as to their invoker's credentials.
533This mechanism is used to allow users to execute
534the carefully written
535commands
536that call privileged system entries.
537For example, there is a system entry
538invokable only by the ``super-user'' (below)
539that creates
540an empty directory.
541As indicated above, directories are expected to
542have entries for ``\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP''.
543The command which creates a directory
544is owned by the super-user
545and has the set-user-\*sID\*n bit set.
546After it checks its invoker's authorization to
547create the specified directory,
548it creates it and makes the entries
549for ``\fB\|.\|\fP'' and ``\fB\|.\|.\|\fP''.
550.PP
551Because anyone may set the set-user-\*sID\*n
552bit on one of his own files,
553this mechanism is generally
554available without administrative intervention.
555For example,
556this protection scheme easily solves the \*sMOO\*n
557accounting problem posed by ``Aleph-null.''
558.[
559aleph null software practice
560.]
561.PP
562The system recognizes one particular user \*sID\*n (that of the ``super-user'') as
563exempt from the usual constraints on file access; thus (for example),
564programs may be written to dump and reload the file
565system without
566unwanted interference from the protection
567system.