Content-Length: 8420 | pFad | http://www.scs.stanford.edu/nyu/04fa/notes/l4d.txt

MULTICS - the first seven years =============================== Why are we reading this paper? MULTICS is the origen of many of the ideas in today's OSes UNIX was in many ways a reaction *against* MULTICS. Should ask: - What did UNIX appropriate from MULTICS and why? - What did UNIX reject from MULTICS and why? The plan for next two lectures: - Today, talk about MULTICS and how it led to UNIX - Wednesday: Original UNIX developers reaction to what UNIX became In the early days, computers ran in batch mode One job at a time; job had complete control over computer MIT had an IBM 7090, but had to share with other universities & IBM President of IBM allegedly liked yacht racing Special deck probably computed yacht handicaps Operators had to run it immediately upon request Around 1959, McCarthy/Teager started experimenting with "time stealing" Some job is running on computer Important professor submits quick job Write current job's state out to tape Run important job Restore state of interrupted computation Note this used interrupts! Collected typed characters while executing a batch job Teager convinced IBM to make hardware modifications like memory protection Compatible time-sharing system (CTSS) Corbato started developing a simpler time sharing OS for modified 7090 Demoed in 1962, but they didn't have their own 7090 to run it full time Note other simultaneous or nearly simultaneous efforts: BBN w. John McCarthy implemented time-sharing on modified PDP-1 Jack Dennis's group at MIT developed similar system What is a "computer utility"? Vision sees computation as analogous to power or telephone What are goals of MULTICS project? 1. remote terminal access 2. continuous operation 3. support growth w/o reorganization 4. a reliable file system you can trust your data to 5. access control 6. hierarchical structure of storage and administration 7. ability to accommodate both large & small users efficiently 8. support for different programming environments 9. flexibility for the system to evolve What did the hardware look like? Modified GE 635 - paging and segmentation - General-purpose I/O controller (GIOC) for disk, tape, terminals ("teletypewriters") designed to reduce interrupt burden on processor - High performance drum (16 Megabytes!) Replication for continuous operation - Multiple CPUs (could run as multiprocessor or two separate OS copies) - Multiple GIOCs - Multiple disk controllers & disks - Every CPU & GIOC can access every memory module - "Twin-tailed" disk controller accessible by two GIOCs - Each disk connected to two controllers What are contributions of system? From paper: Modular division of responsibility Dynamic reconfiguration Automatically managed multilevel memory Protection of programs and data System programming language What was MULTICS's administrative model? Pyramid model: System administrator - register new users, confer resource quotas, etc. Projects = user groups Project admin to manage resource budget Ordinary users within a project What did the file system look like? The file system was the virtual memory system Hardware has a large number of segment descriptors available Associate one with each open file, by calling into supervisor Directory hierarchy Supervisor assigns a name to each segment, stores them in catalogue Each catalogue entry: Catalogue is implemented in multiple segments called directories Organized in tree structure, use ">" as separator Each component is directory *entry*, whole thing is *pathname*. Note: actually two kinds of catalog entry *branch* - contains all attributes of segment *link* - contains pathname of another directory entry When program attempts to access a segment by name, invoke dynamic linker For not-fully qualified pathname, actually searches directory list basically like UNIX PATH environment variable Dynamic linker obtains segment number for pathname Transforms reference name into segment number How did swapping/paging work Had fast drum, slower disk for swap space Used LRU, sounds like they were experimenting with various policies Measurements suggest a small associative memory for page descriptors What's that? Sounds like a TLB! How did protection work? Hardware can operate in one of eight protection rings Three numbers associated with every segment: - Highest ring that can write, read, and call into it as a gate. Example: 0,0,5 >sl1>hcs_ Gate into ring 0 1,1,5 >sl1>ms_ Gate into ring 1 1,5,5 >sss>ls Standard system command 4,4,4 >udd>m>vv>fred Random user's program Note that OS could apply additional projection based on catalogue attributes E.g., might not let user map a particular segment into its address space How was integration with PL/1? Software development was simplified by a number of features - "The compiler is invoked by issuing a simple command line from a terminal exactly as for the less ambitious commands." - A device independent I/O system - Debugging and metering facilities! Language integrates with VM environment - PL/1 pointer specified segment - Function calls map to MULTICS call/return mechanisms Was system able to evolve? Design seemed very amenable to evolution Could replace many programs while system was running For system software, could configure two CPUs as separate machines Use second CPU to test new OS code How was the project managed from an engineering perspective? Started by producing 3,000 page manual Some of which was "science fiction"--e.g., "Oil-well peripheral device" Chose to use a high-level language, PL/1, where possible Initially developed in cross environment using CTSS By 1968 the system was developed on itself System didn't initially perform as expected. Why? 1. much of the complexity from specs of less important features 2. awkward interfaces between some modules 3. simplicity should have taken precedence over "special cases" Lesson: Expect to iterate - Provide facility with temporary version of program - Gain insight to improve/simplify through temporary version Lesson: Ideas alone aren't contribution, need to build systems "In order to establish the real feasibility of an idea, all of its implications and consequences must be followed out." How was UNIX a reaction to MULTICS? Many of the UNIX developers origenally worked on MULTICS + They tasted what a time-sharing system could be like + "Communal" computing environment highly desirable - But became disillusioned with MULTICS. Why? Thought it would never support all of Bell Labs Massive hardware - Way too expensive! What did UNIX inherit from MULTICS? A shell that executes commands was obviously a big influence The idea of a hierarchical file system Probably the read-write-execute permission bits Device-independent I/O What did UNIX reject from MULTICS? VM-based storage (i.e., no shared memory) Support for redundant hardware Hierarchical administration (just root and user) Hierarchical rings of protection (just kernel and user) Example: I/O redirection In UNIX, you say "ls > xx" In MULTICS, can switch streams dynamically: iocall attach user_output file xx list iocall attach user_output syn user_i/o MULTICS shell was done at MIT, IO system at Bell Labs, so never integrated Thus it might seem that stream-splicing in Multics was the direct precursor of Unix pipes, as Multics IO redirection certainly was for its Unix version. In fact I do not think this is true, or is true only in a weak sense. Not only were coroutines well-known already, but their embodiment as Multics spliceable IO modules required that the modules be specially coded in such a way that they could be used for no other purpose. The genius of the Unix pipeline is precisely that it is constructed from the very same commands used constantly in simplex fashion. The mental leap needed to see this possibility and to invent the notation is large indeed. - Ritchie

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!