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

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