Class 16
CS372H
20 March 2012

On the board
------------

1. Last time
2. Exokernel vs. L3
3. Tanenbaum/Torvalds
4. Midterm review

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

1. Last time

    --exokernel

2. compare L3 to exokernel

    (ignore for now that exokernel claims better performance than L3;
    this is likely an artifact.)

    --what is exokernel's key performance argument?

    --what is L3's?

    --are these compatible?

3. Tanenbaum/Torvalds debates

    --what did you think of Tanenbaum's predictions?

	"Microkernels have won" 

	"Writing a monolithic system in 1991 is a truly poor idea" 

	"[MIPS] will gradually take over from the 80x86 line...
	They will run old MS-DOS programs by interpreting the 80386 in
	software."
	    (Actually, he's sort of right in that the architecture of modern
	    CISC CPUs is a MIPS core that "interprets" the x86 in
	    microcode.)

	"I think it is a gross error to design an OS for any specific
	architecture, since that is not going to be around all that
	long." 

	"Of course 5 years from now that will be different, but 5 years from now 
	everyone will be running free GNU on their 200 MIPS, 64M
	SPARCstation-5." 

    --please summarize the argument that the two are having about
    portability
   
	--AST says: you don't want to have to redesign the kernel for
	each new hardware platform.

	--Linus says:

	    --the entire job of an OS is to abstract the hardware, so
	    how could the OS ever avoid being hardware-specific?

	    --plus, you do want to redesign large parts for each new
	    hardware platform. it makes it easier to get the first
	    version running if you can use the features of the
	    architecture.

	    --the real porting problem is application portability to new
	    OSes, and if you keep the OS interface to applications the
	    same, then this problem doesn't arise. put differently, the
	    kernel/HW interface code is a tiny fraction of all of the
	    code in a systems project (you gotta count the compiler, the
	    text editors, the utilities, the windowing system, etc.)

    --which side do you agree with?
 
	--which is more portable: Linux or Minix, in the context of this
	debate?
   
	--(obviously in the end Linux wound up being portable, since it
	seems to run everywhere.)

    --what would Liedtke say? ("IPC performance is the master")

    --summarize the argument about microkernels vs. monolithic

	--AST argues that microkernels are cleaner and better, for the
	usual reasons.

	--Linus implies that they're harder to build to perform well,
	and implicitly that they may be harder to get working in general
	_and_ that he has an actual system that is monolithic and works,
	so why not use it?

	    ["your job is being a professor and researcher: That's one
	    hell of a good excuse for some of the brain-damages of
	    minix. I can only hope (and assume) that Amoeba doesn't suck
	    like minix does."]

    --what about code size?

	--Turns out that core Linux _is_ small, so the term
	"microkernel" is to some extent marketing.

    --In the end it comes down to pedagogical exercise (Minix) versus
    useful tool (Linux):
    
	--"Linux wins heavily on points of being available now." (right!
	software has a time value.)

	--"Linux is not being written as a teaching tool, or as an
	abstract exercise. It is being written to allow people to run
	GNU-type software _today_." (by Michael Kaufman)

	--Ken Thompson is classic here:

	    "viewpoint may be largely unrelated to its usefulness. Many
	    if not most of the software we use is probably obsolete
	    according to the latest design criteria. Most users could
	    probably care less if the internals of the operating system
	    they use is obsolete. They are rightly more interested in
	    its performance and capabilities at the user level.
	     
	    I would generally agree that microkernels are probably the
	    wave of the future. However, it is in my opinion easier to
	    implement a monolithic kernel. It is also easier for it to
	    turn into a mess in a hurry as it is modified."


4. Midterm review

Ground rules

--75 minute exam

    --at 70 minutes, you have to stay seated; do not get up and distract
    your classmates.

    --you must hand your exam to me (we are not going to collect them).
    the purpose of this is to give everyone the same amount of time.
    
    --at 78 minutes, I will walk out of the room and won't accept any
    exams when I leave

    --thus you must hand in your exam at time x minutes, where:
	x <= 70 OR
	75 <= x < 78 

--bring ONE two-sided sheet of notes; formatting requirements listed on
Web page

Material

--Readings (papers, articles, Web sites; see course Web page, the
column called "Reading assignment")

--Labs

--Homeworks

--Lectures

    --Operating systems: what are they?

	--goals, purpose

    --PC architecture, x86 instructions, gcc calling conventions

    --virtual memory

	--segmentation (how does it work in general? on the x86?)

	--paging (how does it work in general? on the x86?)

	    virtual address: [10bits  10bits  12bits]

	--entry in pgdir and page table:

	    [20 bits  more bits   bottom 3 bits]

	--protection (user/kernel | read/write |  present/not)

	--what's a TLB?
	
	--how does JOS handle virtual memory for the kernel? for user
	processes?

	--page faults (their uses and costs)

	--page replacement (why is it needed, and what are the
	considerations)

	--the limits of caching
    
    --privileged vs unprivileged mode

    --user-level / kernel interaction: how does the kernel get invoked?
	--by user programs (system calls)
	--by hardware interrupts

    --processes

	--what are they? (registers, address space, etc.)

	--how do they get created? fork()/exec()

	--context switches (when? how?)

    --process control in Unix

	--shell, pipes, file descriptors

	--fork/exec separation

    --Unix
    
	--mechanics

	--perspective


    --threads

	--user-level vs. kernel

	--how implemented? swtch(), separate registers, separate
	stacks (which applies to both user-level and kernel)

    --concurrency

	--big unit; see lecture notes from February 21 for
	summary (not going to review it here in depth)

	--lots of things can go wrong: safety problems, liveness
	problems, etc.

	--What's the plan for dealing with these problems?

	    --safety problems: build concurrency primitives that get
	    help from hardware (atomic instructions, turning off
	    interrupts, etc.) and move up to higher level abstractions
	    that are easy to program with

	    --liveness problems: most common is deadlock, and we
	    discussed strategies for avoiding it. other problems too:
	    starvation, priority inversion, etc.

	--lots of trade-offs and design decisions.

	--lots of "advice". some is literally advice; some is actually
	required practice in this class.

	--alternatives to concurrency

    --software safety + Therac-25

    --linking/loading

	--what does a process look like in memory?

	--what problem is linking solving? (latex + page numbering
	example)

	--what are the mechanics of linking/loading/etc.? 

    --Jon's lecture on binary rewriting

    --SFI and sandboxing

    --kernel design

	--monolithic, microkernel, exokernel: what are these?

	--microkernels:
	    --Liedtke paper on IPC performance in L3
	    --Tanenbaum/Torvalds discussion

	--exokernels:
	    --The Exokernel paper