EECS 582 – W16 1

The UNIX Time-Sharing System

Mosharaf Chowdhury

1/11/16

EECS 582 – W16 2

Time Sharing• As opposed to batch processing

• Submit jobs to queues to be processed one at a time• Non-interactive

• Divide a shared resource between multiple programs and users to lower the cost of computing• John McCarthy wrote a memorandum in 1959

• Early examples include• MIT CTSS (Compatible Time-Sharing System)• Berkeley Timesharing System• Dartmouth Time-Sharing System (DTSS)

1/11/16

EECS 582 – W16 3

Multics•Multiplexed Information and Computing Service

• Started in 1964 at MIT; led by Fernando Corbató w/ GE and Bell Labs

• Time-sharing operating system• Developed initially for GE-645 mainframe, a 36-bit machine w/

support for virtual memory• Hierarchical file system• Protection ring-based security• Access Control Lists (ACL)• …

• Bell Labs pulled out in 19691/11/16

EECS 582 – W16 4

UNIX

• Started by Ken Thompson and Dennis Ritchie in 1969

1/11/16

“UNIX was never a ‘‘project;’’ it was not designed to meet any specific need except that felt by its major author, Ken Thompson, and soon after its origin by the author of this paper, for a pleasant environment in which to write and use programs.”

- Dennis Ritchie, “The UNIX Time-sharing System – A Retrospective”

EECS 582 – W16 5

UNIX

• First version on DEC PDP-7 and PDP-9 (circa 1969-70)• Second version on unprotected DEC PDP-11/20• Third version w/ multiprogramming on PDP-11/40, 45

etc.• Described in today’s paper

• February, 1971: PDP-11 Unix first operational

1/11/16

EECS 582 – W16 6

PDP-11/40

1/11/16

• 16-bit word (8-bit byte)• 144K bytes core memory

• UNIX took 42K bytes• Minimal system 50K bytes

• Storage• 1M byte fixed-head disk• 4X 2.5M byte moving-head disk

cartridge• 1X 40M byte moving-head disk pack

• 14 variable speed communication interfaces• Many other attached devices

http://www.catb.org/esr/writings/taoup/html/graphics/kd14.jpg

EECS 582 – W16 7

Simplicity• Simple abstractions• Everything is a file

• Simple file system design• Hierarchical for

programming simplicity• Simple connectors• Pipes that look like files

• Simple maintenance• Self-maintained

1/11/16

“It is hoped, however, the users of UNIX will find that the most important characteristics of the system are its simplicity, elegance, and ease of use.”

- DR & KT, “The UNIX Time-Sharing System”

EECS 582 – W16 8

Influences• Berkeley Timesharing

System• Process forks

• Multics• I/O system calls

• Multics and TENEX• Shell and related

• CTSS• “…in essence a modern

implementation of MIT’s CTSS system…” – D. Ritchie

1/11/16

“The success of UNIX 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.”

- DR & KT, “The UNIX Time-Sharing System”

EECS 582 – W16 9

Key Concepts

• Names and namespaces• Directories, paths, and links

• Root, home, and current directory• Rooted tree and mounting sub-trees on leaves• Special files and access control

• Process management• System calls, address space, signals/interrupts

• User interface• Shell, I/O redirection, and pipes

1/11/16

EECS 582 – W16 10

Hierarchical Namespace

• Easy to traverse• Easy to modify/add/delete• Access control is simpler• Hierarchical as well

• Can be arbitrarily increased• Mount new drives!

1/11/16

EECS 582 – W16 11

Everything is a File

• Regular files• Special files• Devices• Networks

• Directories• Same as files, except when not• Keeps track of pointers to files, not actual content

• Simplifies linking!

1/11/16

EECS 582 – W16 12

I/O Calls

• Inspired by Multics• Primary functions• open, close, read, write, seek• Interface that has passed the test of time: haven’t effectively

changed yet!• BSD socket API is similar• open, close, send, recv

1/11/16

EECS 582 – W16 13

No Locks

1/11/16

“We take the view that locks are neither necessary nor sufficient, in our environment, to prevent interference between users of the same file. They are unnecessary because we are not faced with large, single-file data bases maintained by independent processes. They are insufficient because locks in the ordinary sense, whereby one user is pre- vented from writing on a file which another user is reading, cannot prevent confusion when, for example, both users are editing a file with an editor which makes a copy of the file being edited.”

- DR & KT, “The UNIX Time-Sharing System”

EECS 582 – W16 14

File System Implementation

• Thompson and Ritchie took special pride in their design of the file system• My opinion from the reading• Given the long-term impact, I think it’s justified!

• We’ll skip the details, and wait for next week when we read FFS

1/11/16

EECS 582 – W16 15

Execution

• Image is an execution environment• Container is the current parallel

• Process is the execution of the image• Program text is write-protected and shared between all

running processes of the same program• Created using fork• Inspired by Berkeley Timesharing System

1/11/16

EECS 582 – W16 16

Processes and the Kernel

• Process• Separate virtual address

space• Only one thread!

• Kernel• Mediator for accessing

shared resources and kernel services

1/11/16

P1 P2 P3

Kernel

Interactions via system calls and signals/interrupts

EECS 582 – W16 17

Pipes

• This is the ‘|’ when writing shell commands• Mechanism for inter-process communication• Using file descriptor• Again files!

• Allows to build large workflows by connecting separate programs• We do the same today

1/11/16

EECS 582 – W16 18

Worse is Better & End-to-End Arguments

1. Simplicity2. Ease of Use and Maintenance3. Consistency Across Interfaces4. Completeness of Design5. Correctness of Specification and Implementation6. Placement of Functionality

1/11/16

EECS 582 – W16 19

Next Class…

• System R

1/11/16