The UNIX Time-Sharing System Mosharaf Chowdhury EECS 582 – W1611/11/16.
-
Upload
heather-lloyd -
Category
Documents
-
view
223 -
download
0
description
Transcript of The UNIX Time-Sharing System Mosharaf Chowdhury EECS 582 – W1611/11/16.
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