OPERATING SYSTEM

Goal: The task of an operating system (OS)
 is to
   - make it easy to run programs
   - provide a convenient, standardized interface to hardware
       and other programs
   - manages shared resources on the computer
      such as: time (in the CPU), memory, devices


Other goals
   - have minimal overhead
   - it should protect user programs and user information
   - should 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 (user mode)
          -> trap handler
              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:
  + simple to implement
  + good performance


Disadvantages:
  - complex code, so hard to maintain
  - crash of any part of system crashes everything (whole 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, well-defined interfaces between layers
  + easier to debug


Disadvantages
  - designing the layers is hard (takes experience)
  - passing informtion through layers can take time




           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 is more portable
  + better security and reliability


Disadvantages:
  - more internal communication in the OS, ==> worse performance
  - design 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 being run (or is ready to run)
     an activity or series of activities

A process is also called a *task*

OS Goal: give each process the illusion that it is running all by
         itself on the computer

Characteristics:
  - it is active (running or waiting to run)
  - has its own memory (address space, registers, stack, heap,
                        files, etc.)
  - has various permissions





         PROGRAM VS. PROCESS

Is a program a process and vice versa?
  no, a process is running (or runnable)
      a program is a description




How does a program become a process?
  the loader put it in memory,
  the OS allocates a PCB and PAS for it,
  then the OS calls it (dispatches to it)



      PROCESS CONTROL BLOCK (PCB)

def: a *process control block (PCB)* is
     a data structure in the OS (a record)
     that the OS uses to manage processes
     aka: "process descriptor" or "context"


Typical information in a PCB:
    - process ID

    - mode (user or system)
    - priority (for scheduling)
    - code address

    - state (running, waiting, etc.)
    - PAS info
    - BP and SP of the runtime stack
    - PC and other registers
    - files open
    - etc.





        PROCESS ADDRESS SPACE

def: a *process address space* is
     area of memory assigned to a process by the OS


Layout (in Unix):

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


         PROCESS STATE

def: a *process state* represents the
     the activity of a process

Examples:

 Ready: (can be run, but isn't now)

 Running: (using the CPU)

 Waiting: (waiting for I/O to finish)

 Suspended: (temporarily waiting for CPU)

 End: (halted, finished)

 Abend: (terminated by doing something bad)

     AN OS AS AN EVENT-DRIVEN PROGRAM

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