Class 1
CS 372H
17 January 2012

On the board
------------
CS372H: Introduction to Operating Systems: Honors
Instructor: Michael Walfish
TA: Jason Wolfe
http://www.cs.utexas.edu/~mwalfish/classes/s12-cs372h

1. Introduction and goals
2. What is an operating system? Why study them? How will we study them?
3. Course mechanics and admin
4. Examples and history

---------------------------------------------------------------------------

1. Introduction and goals

    --Hello
	
    --Introduce Jason

    --Class goals

	a. learn how operating systems work
	    --in part by building one

	b. learn advanced topics in systems
	
	c. engage the research literature

2. What is an operating system? Why study them? How will we study them?

    --What is an OS?
    --Why study them?
    --How will we study them?

    A. What is an OS?

    [draw picture of hardware (memory, CPU, disk, I/O), OS, user-level
    programs]

    [OS includes OS services: processes, virtual memory, file system
    (file contents, directories and file names), security, networking,
    inter-process communication, time, terminals, etc.]

    --definition: An operating system implements a virtual machine that
    is (ideally) easier to program than the raw hardware

    --layer of software; usually has to deal with the messy details of
    the hardware

	    --In some sense: OS is just a software engineering problem:
	    how do you convert what the hardware gives you into
	    something application programmers want? 

	    --Job of OS: provide services to user-level programs

    --hardware consists of resources:

	CPU, memory, disk, I/O devices

	did I leave anything out?

	hardware is nasty!
	    --consider what is involved in getting things to the disk.....
 
    --this software is classically described as doing two things:

	* managing the resources of the machine 
	    --example: scheduling -- give every process some of the CPU

	* abstracting the hardware 
	    --hide details of hardware (OS gets dirty; programmers don't)

    --so who cares about these things?

	--well, resource management means that one bad program doesn't
	screw up another. OS does:
	    --multiplexing
	    --isolation and protection
	    --sharing
 
	--and abstracting the hardware is about convenience and
	portability
	    --you really don't want applications to have to program the
	    bare hardware
		--would lead to lots of repeated code
		--and unclear how to run more than one application at
		once, particularly more than one that are mutually
		distrustful.

    --what are examples of managing resources and providing abstractions?

	memory, scheduling, file systems, I/O

	* memory:

	    movl 0x1247, %edx   [means "get contents of 0x1247 and put in %edx"]

	    --abstraction: user program thinks it is reading from
	    0x1247; it is not

		--more generally, user program thinks it has a linear,
		contiguous address space; it does not

	    --isolation: user program can't write to another user's memory

	    ***these are different points***

	* scheduling:

	    --abstraction: process has the illusion that it is running
	    continuously; it is not

	    --isolation: user program that is hogging CPU gets switched
	    out in favor of another user's program

	    ***these are different points*** 
		--you could imagine telling the user program that it was
		getting switched out


	* file systems:

	    --abstraction: illusion file is continuous array of
	    bytes; it's not

		fd = open("/tmp/foo", WR_ONLY)
		rc = write(fd, "abc...z", 26)

		abstractions here:
		    --files
		    --file descriptors
		applications see these abstractions through system calls

	    --isolation: user program can't write to a file unless
	    it has permission


	* I/O:

	    --abstracting the hardware:
    
		example:

		    # fd = open("/dev/audio", WR_ONLY);
		    # write(fd, <some audio samples>, ....);

		    versus

		    outb(0x74, 123)
		    outb(0x83, ....)
		    .....
		    
		--note:
		
		    --operating system makes the device look like a
		    file!  (obvious in hindsight. not at the time this
		    design idea entered).
		    advantages:
			--files and device I/O use same programming
			--names have same syntax and meaning, so
			programs can take either as a parameter. that
			is, the **same** program works, whether it's
			being asked to read or write a file or I/O.
			--above, we could have had
			    open("/dev/tty", WR_ONLY) or
			    open("/tmp/foo", WR_ONLY) and the 
				rest of the code would have been
				unaffected

	    --managing resources: what happens if every process tries to
	    write to the screen at once?

	result of abstraction and resource management:
	    --applications are easier to write
	    --impact of bugs reduced
	    --machine's resources shared, which is an efficiency gain

    B. Why study them? (Why is OS design+implementation hard or
    interesting?)

	a. ideas are everywhere: resource management and abstraction,
	for example.

	b. understand fundamental design trade-offs

	    --between performance and simplicity
	    --between putting functions in hardware or software

	    --code must be efficient (so low-level?) ...
	    --...but abstract/portable (so high-level?)

	    --code must be powerful (so many features?)
	    --...but simple (thus a few composable building blocks?)

	    --another trade-off: between security and convenience

	    --and there are difficult interactions:
		--among features 
		--among behaviors: scheduler and memory allocator

	    --etc.

	c. useful to know "how things work". peek under the hood.

	d. at the same time, there are still unsolved problems!

	    --OS security is sort of a joke. people defend their
	    operating systems by deploying firewalls.

	    --multicore: yes, the operating systems run, but there's an
	    argument that perhaps the abstractions should be different
	    (interaction between caches and address space abstractions)

	e. implementation-wise:
	    --the environment can be unforgiving (can have weird h/w, no
	    debugger, ...)

    C. What level will we study at?
	a. Learn how stuff works
	b. Learn specific techniques 
	    --time-tested solutions to hard problems
	    --avoid "hacks"
	c. Learn how to approach problems
	d. not a priority: details of deployed OSes (e.g., details of
	    Linux), but we may sometimes use these as examples

3. Course mechanics and admin

    --write on the board:

	course Web page: please check it every day. primary way that we
	will communicate

	components of the course:
	    --lectures 
	    --discussion days
	    --reading
	    --labs 
	    --exams
	    --homeworks

	grading 

	policies

    --lectures: 

	--please ask questions!

	--will write on board; paces lecture

	--will put lecture notes online

	--no laptops

    --discussion days:

	--explicitly interactive

	--you will be called on

	--don't show up if you haven't done the reading....

	--...but you're graded in part on attendance

    --reading: see Web page.

	--assigned textbook? not sure. depends on your backgrounds.

    --labs: 

	--centerpiece of the course. very awesome set of labs: JOS!!

	    --exposes low-level interface (sometimes the hardware) to
	    user-level programs (few abstractions provided by the
	    kernel, but you will build them in user space.)

	    --does implement protection and resource management

	--unlike much OS courseware, this one will boot on an x86!!!

	    --and was recently made to work on multicore hardware!
	
	--**you will use pair programming from lab 3 onward **

	--ADVICE and NOTES

	    --lab 1: lots to learn; not much code to write.

	    --lab 1 is easier than the others. 

	    --people in the past thrown by the difference between lab 1
	    and lab 2, so we have made a small piece of lab 2 due
	    earlier to allow you to get calibrated

	    --I used to tell people, "Start early". Now I say, "Start on
	    time".

	    --Regardless, you need to allocate time. The people last
	    year who tried to squeeze in the assignments often ran into
	    trouble.

	    --Last, I'm expecting you to feel challenged by the labs.
	    This work pushes students. For better or worse, getting
	    pushed can be painful. So if you find that the labs are
	    causing pain, that probably means you're learning....

    --exams:
	
	--ad-hoc quizzes

	--in-class midterm 

	--final during finals week

    --grading:

	--labs: 35%

	--midterm: 15%

	--final: 40%

	--discussion days: 10%

    --policies: please see the Web page

    --help on the labs: please ask for lab, but please make sure that
    you've really thought through your question on your own.	

	--excessive use of the "email for help" feature will lead to
	rate-limiting

4. Examples and history

     --1960s: batch systems

	--IBM 7094, from early 1960s 
	    --Fortran Monitor System
	    --jobs + libraries + monitor routine that killed jobs taking
	    more than their time estimate

	--you've all heard of punchcards

	--kind of a long edit/run/debug cycle

    --1960s: CTSS: first time-sharing system

	--now multiple programs could run at once!

	--opens the door to interactivity

	--everyone gets a terminal!!

    --mid 1960s: project MAC at MIT builds Multics

	--time-sharing but expensive

	--the model was like an electric power plant: all of
	Massachusetts gets a Multics machine, etc.

	--Multics a collaboration between MIT and Bell Labs

	--Issues: complex, expensive, slow.

	    --announced in 1963; ran in 1969

    --1969 to early 1970s: Unix (from Thompson and Ritchie at Bell Labs)

	--goal was to run on cheap hardware. PDP-7

	--eventually got a PDP-11: only $40k! (which was $173k in 2008
	dollars)

	--small system: 9000 LOC

    --Eventually, Thompson and Ritchie decide they need a new
    programming language to write Unix in

	--So C gets born

    --Unix took over the world.

	--Its abstractions are still in use everywhere

	--(Which is arguably depressing)

	--great example of a small number of mechanisms going very far
	(high ratio of capabilities to mechanism)
	
	    a. stuff was added to Unix in the 1980s, at Berkeley

	    b. Andy Tanenbaum: "System 7 was a dramatic improvement
	    over its predecessors, and over its successors as well".

    --meanwhile, in the 1970s, at Xerox PARC, people are trying to build
    the personal computer....

	--keep in mind that at the beginning of this era, telling
	someone that you were going to build a personal computer was
	like telling them that you would have a personal nuclear reactor

	--computers were totally slow when they started, but those
	designers knew that computers would be fast, so they started building
	the thing people want and worried later about performance

	--eventually led to the graphical interfaces we have today as
	well as modern technology


    --JOS!

    --Notes about the history of OSes
	    
	--in the early days of PCs, they didn't do a bunch of things
	that JOS will do!

	    --when computers stopped having tons of users, there was
	    less need for protection and isolation.

	--now of course, we need those features, and modern OSes
	have them.

	--seems to be true that as a new device gets an OS, it gradually
	recapitulates the history of the others: starts with no OS, then
	a primitive one, etc., etc.

	--this is reason why studying "obsolete" concepts could be
	useful: because they won't be obsolete on some new platform,
	e.g., phones, sensors, smart cards

 
--distribute surveys