OPERATING SYSTEM

Goal: The task of an operating system (OS)
 is to
   - make it easy to run programs
   - provide a standard, convenient interface
      between programs and the hardward
   - manage sharing of computer's resources


Other goals:
   - have minimal overhead (high performance)
   - protect users and applications
        from each other
   - be reliable (not crash)

General approach: virtualization, i.e.,
  abstraction of physical resources
  defines APIs for them = system calls


     SOME HISTORY OF OPERATING SYSTEMS
       
Early days: human operator ran jobs
            OS = libraries for I/O

1960s: protection via system calls

       imagine library that can read
         any part of a disk drive:
         Is any information safe then?

   System calls:
      hardware tracks privilege level
         users run in "user mode"
         OS runs in "kernel mode"
      call to system involves:
         a trap (in user code)
          -> trap handler (in kernel)
              starts kernel mode
              checks permissions
         return-from-trap instruction
          => back to user code (user mode)

Multiprogramming (1970s, Unix):
      OS switches between tasks:
      - timesharing and interactivity
      - start of memory protection
      - issues of concurrency
      

   WAYS TO ORGANIZE AN OS: MONOLITHIC

No distinctions, boundaries between
user and OS programs, all can directly
use the BIOS drivers

    [Application Programs]
        |        |    |     
        v        v    |
    [Systems progs]   |
        |        |    |
        v        |    |
    [OS drivers] |    |
        |        |    |
        v        v    v
    [BIOS device drivers]


Advantages:
   very flexible
   very simple to implement
   good performance


Disadvantages:
   complex code in the OS, hard to maintain
   crash of anything crashes the entire OS



             LAYERED OS
 
Each layer can only use 1 layer below it

            [Application Programs]
                    |
                    v
             [Layer N: OS calls]
                    |
                   ...
                    |
                    v
             [Layer 1: OS kernel]
                    |
                    v
             [Layer 0: hardware]

Advantages:
    + easier to maintain the OS code
    + well-defined interface for each layer
    + easier to debug

Disadvantages
    - designing the layers is hard
    - passing data through the layers can be slow



           MICRO-KERNEL OS

Layers,
  but with kernel as small as possible.
Non-essential components
  become (user-space) apps

            [Application Programs]
                    |
                    v
             [Layer L: OS calls]
                    |
                   ...
                    |
                    v
            [Layer 1: micro-kernel]
                    |
                    v
             [Layer 0: hardware]

Advantages:
   - OS becomes more portable
   - better security and reliability

Disadvantages:
   - more internal communication in the OS
       so performance is worse
   - design is even harder



            MODULAR OS

Kernel has set of basic services,
  other services added as dynamic modules.
Each module has defined API,
  but any module can call any other module



            PROCESS

def: a *process* in an OS is
    a program that is running or can be run

A process is also called a *task*

OS Goal:
   give the illusion that the process has
      the whole computer to itself


Characteristics:
   - can be active
   - has its own memory
   - has various permissions



         PROGRAM VS. PROCESS

Is a program a process and vice versa?
    a process is loaded into memory
    a process is executing (or able to be)


How does a program become a process?
    by loading it
       allocates a control block in the OS
       and an address space
       and then dispatching to it



      PROCESS CONTROL BLOCK (PCB)

def: a *process control block (PCB)* is
       a data structure that the OS uses
       to manage processes


Typical information in a PCB:

    might contain:
        process ID (or name)
	mode (user or kernel)
	priority (for scheduling)
        state (running, waiting, etc.)
	code or pointers to the code
	FP and SP of the runtime stack,
	   PC and other register values
	files that are open






        PROCESS ADDRESS SPACE

def: a *process address space* is
         an area of memory given to the process



Layout (in Unix):

     |-------------------|
     |      Stack        |
     |        |          |
     |        v          |
     |                   |
     |                   |
     |-------------------|
     |                   |
     |        ^          |
     |        |          |
     |      Heap         |
     |-------------------|
     |                   |
     |      Data         |
     |                   |
     |-------------------|
     |                   |
     |      Text         |
     |                   |
     |-------------------|


         PROCESS STATE

def: a *process state* represents the
      activity that the process is doing

Examples:

 Ready:

 Running:

 Waiting:

 Suspended:

 End:

 Abend:
 

     AN OS AS AN EVENT-DRIVEN PROGRAM

                            [Suspended]
                            ^        /
                 dispatch   |stop   resume
  create         /-----\    |      v
    *---> [Ready]      |--> [Running]
            ^   ^         /  |   || EXIT
            |   \---------   /   | \->[End]
         I/O|       timer   /SIO |
      interrupt            /     |trap
             \--[Waiting]-/      v
                              [Abend]