#! | 567 lines | 567 code | 0 blank | 0 comment | 0 complexity | 7c685e2d2e5a2e35437df48ec73fa30f MD5 | raw file
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.