Lecture #2

Administrivia

• Resources about shell/user-level stuff

  • noodle around UW web sites
  • see CSS 390 notes
  • linuxfest northwest 2013 presentation
  • 1e9 tutorials on the interwebs
  • informal tutorial during office hours

• Lab 1 skeleton was locked out

  • fixed & apologies for any inconvenience
  • note on commenting style: overly verbose for pedagogical reasons
    • don't mimic the style

• Labs 2-4: not quite ready yet

Our Story So Far

• Abstractions let us build large-scale systems

• Choice of algorithm, implementation language, compiler flags, & low-level implementation details can make dramatic differences in performance

  • in extreme cases, months-long computation may be reduced to seconds
  • not always posible: some problems are intrinsically hard (i.e. computationally expensive)

• Most of the time, programmer time is more expensive than computer time

• Some cases where performance matters (not exhaustive):

  • large-scale systems (massive infrastructure costs)
  • tiny-scale systems (resource-constrained, eg. embedded)
  • real-time systems (hard performance requirements, often embedded)
  • operating systems (performance bottlenecks in the OS affect everything)

• Real-time systems: hard (i.e. must-be-met) deadlines on computation

  • late result may be worse than no result at all
  • examples:
    • oil refinery: not closing valve on time -> boom!
    • rocket: not correcting attitude deviation, veers off course -> boom!
    • self-driving car applies brakes late -> splat!

• Zavie story: in the 1980s, research weather models were producing decent 10-day forecasts--3 days late

  • weather forecasting is a hard deadline, but not what we traditionally think of as real-time

• Payroll systems have hard deadlines

  • also not generally considered real-time

• History: how we got to where we are (from single-process to batch to multi-processing)

• Operating systems: no standard definition

  • kernel + system support programs, or just kernel?
  • resource allocator (traffic cop) or hardware mediator?

• Key concerns:

  1. efficient use of hardware resources
     • device drivers
     • user-level access via system request (sysreq) calls
  2. process management
     • creation/teardown
  3. scheduling (time slices) - concurrency management
  4. file systems (data structure on top of storage)
  5. networking
     • low-level protocols
  6. safety/security & convenience

• Layered model TODO: diagram

• Processor modes

  • normal/user (restricted)
    • no direct access to hardware
    • MMU (memory management unit): segmented or virtual memory
  • privileged
    • direct access to hardware
    • MMU: real memory mode

• Processes make system calls/requests/traps to ask kernel for something

  • "context switch"

Layered Model (cont.)

TODO: diagram

Kernel vs. User Mode

• Processor (CPU) operates in 2 (or more) modes

  • user (normal mode) AKA restricted
  • privileged/supervisor/kernel mode

• User mode

  • non-privileged operations only
  • no direct access to hardware
  • segmented or virtual memory (MMU: memory management unit)

• Kernel mode

  • all operations
  • direct access to hardware
  • real memory mode (MMU)

• On system startup (bootstrap): processor is in supervisor mode

  • kernel loads, initiates 1st userland process
    • load program code & data into memory
    • constructs internal (kernel) data structure representing process
      • a process is a data structure to the kernel
  • kernel transfers control to process #1 via special instruction
    • context switch to user
  • userland process (so far, only one process) executes until either
    1. process makes system request (trap)
    2. interrupt occurs (e.g. hardware event)
    3. (special case of #2): timer interrupt
       • time slice

• Interrupt/trap transfers control back to kernel & switches processor back to supervisor mode

  • kenel handles interrupt or user request (e.g. initiates disk I/O operation)
  • kernel then checks its prcess table for "runnable" processes & chooses (schedules) one
  • kernel transfers control back to scheduled process & switches to user mode

Switching Between User & Supervisor Mode

• Power on/reset: processor is initially in supervisor mode
  • processor begins executing instruction at well-defined memory address (boot loader)
    • bootstrapping (https://en.wikipedia.org/wiki/Bootstrapping): akin to pulling oneself up by one's bootstraps
• Special instruction (e.g. IRET) to switch to user mode

• User --> supervisor mode

  • trap instruction
  • illegal instruction
  • access to illegal address (segmentation violation, bus error)
  • interrupt
    • hardware signal: I/O device, timer

• Trap/interrupt: program counter jumps to address contained in interrupt vector

  • target address is Interrupt service Routine (ISR)

• ISR may disable (mask) interrupts while serving current interrupt

  • we want to keep this brief
  • critical section

• Non-maskable/priority interrupt: cannot be masked

• Kernel -> user mode

  • special instruction, e.g. IRET
  • set special register (processor status word)

But, What's a Kernel?

• Core program

  • always runing
  • manages hardware, filesystem(s), processes, etc.

• Leaky abstraction (muddying the model):

  • kernel functions may be supported by userland daemon processes
    • not everything needs to run in supervisor mode

• Userland processes interact with kernel via system calls (traps)

  • section 2 vs. section 3 of the Unix manual (system calls vs. C library functions)
    • both look like function calls in C
    • good interview question: starting point for a discussion of operating systems

• Want kernel to be small & fast

  • provide minimal (orthogonal) set of operations
  • reality: kernels are not so small any more
    • Unix had dozens of system calls; Linux has 100s
  • embedded real-time systems tend to be leaner

• I/O: core functions implemented with 4 calls: open, close, read n bytes & write n bytes

  • formatted I/O (e.g. printf, <<, etc.) implemented in userland library functions
    • library function converts data to sequence of bytes
    • string operaitons do not require direct access to hardware

• Kernel is responsible for:

  • process management: create, schedule, terminate (userland) processes
    • memory protection: prevent one process from reading/writing another process's memory
      • malicious code
      • bugs (e.g. "wild" pointers)
  • filesystems (safety & security)
  • device drivers: hardware interface (I/O)
  • networking (low-level protocols)
  • accounting
    • there was a time when "time-share" systems were billed by the CPU-second
    • these times have returned as "cloud services"

• Compiler support: non-standard language features

  • intrinsics: function calls recognized by the compiler, which generates specific code
  • inline assembly
  • must compile Windows with Visual Studio; must compile Linux with gcc

Userland Processes

• Process: essentially a running program

  • intial working definition; we'll refine this later

• Kernel starts up initial process, process #1

  • but where do other processes come from? spoiler alert: process #1 is called init

• init reads config file(s), makes system calls to ask kernel to create other processes

  • system services (daemons), e.g. print server, cron
  • window system
  • login (getty)

• init --> getty --> login --> bash (shell)

Process Management

• Process is (essentially) running program: how to create & tear down processes?

• Program startup

  • program (executable file)
    • includes "static data"
  • argument vector (list of strings)
    • no intrinsic meaning to system
      • up to specific program to interpret
    • conventions: -f --flag --key=value filename...
      • exceptions: specfic programs (examples)
  • pre-opened files (magic, which we'll discuss shortly)
    • conventions: 0 (stdin, cin, ...), 1 (stdout, cout, ...), 2 (stderr, cerr, ...)

• Exit status

  • 0 = success ("true" in shell)
  • non-zero = failure ("false" in shell)
  • C/C++ standard define
    • EXIT_SUCCESS = 0
    • EXIT_FAILURE = 1
    • Unix allows byte value: 0..255
    • some programs use non-zero exit status to communicate result (not necessarily failure)
      • grep: found/not-found
      • test: boolean expression

• Plus other stuff not important right now

• Unix design decision: separate process creation from program invocation

  • fork(): clone current process (the one that called fork)
    • parent: original process
    • child: newly-created process
    • both processes are identical (including open files) except for process id (pid) # & return-value of fork
    • fork returns int value (like all system calls)
      • <0: fork failed
      • =0: child process
      • >0: parent process (value is pid of child process)
    • tree of processes: process #1 (init) is root
      • there is no process #0

• When child process terminates, kernel holds child's exit status value until parent process collects it

  • parent collects child status via wait/waitpid system calls
    • poor choice of names, but we're stuck with it
    • indefinite wait or polling (return immediately)
      • wait doesn't necessarily wait
  • optionally, parent may ask kernel to send signal (software analog of interrupt) when child terminates
  • until parent calls wait, kernel maintains child's entry in process table
    • all other child resources are deallocated (freed up)
    • child is in zombie state (interview questions)
  • if parent dies first, child becomes orphan
    • orphans are adopted by process 1 (init)
    • init's other function is to reap orphan zombies

System Calls (Linux)

• Design principles:

  • minimal set of orthogonal operations (original 1970s Unix had dozens of system calls, modern Linux has 100s)
  • uniform file interface (mostly)

• In C (API layer), system calls look like ordinary function calls

  • RTFM to determine which ones are system calls

• Examples

  • process control: fork, exec, wait, signal, kill
  • file management: rename, unlink, chmod, chown
  • file operations: open, close, read, write, lseek
  • device operations: open, close, read, write, ioctl
  • networking: bind, listen, connect, send, read, write
  • inter-process communication: signal, kill, pipe, shmget, mmap
  • misc: umask, getpid, getppid, getcwd, chdir

• Arguments to/results from system calls typically stored in registers

  • register holds integer/pointer value

• Return values from system calls are integers

  • <0: failure
  • 0: ok (if no other meaningful result)
  • ≥0: result for specific calls, e.g.
    • file descriptor (index into table)
    • process id (index into table)

File Descriptors

• File descriptor: small integer representing open file

  • literally: index into kernel data structure (table/array)
  • handle/token into opaque data structure (pointer-like)

• Convention:

  • 0: standard input (formatted by standard libaray as stdin or cin, or...)
  • 1: standard output (stdout, cout,...)
  • 2: standard error (stderr, cerr,...)

• Most programs expect files 0, 1, 2 to be pre-opened

  • shell reads command (text), calls fork
  • child process replaces file descriptors 0, 1, 2 (if necessary), then calls exec
  • parent calls wait to get child exit status
    • user can access exit status in shell variable $?

• C library:

  • fopen returns FILE* object (handle into userland library object)
    • internally, calls open which returns file descriptor
  • fileno returns file descriptor for given FILE* object
  • fdopen takes open file descriptor, wraps new FILE object around it & returns FILE*

Pipes

• Common paradigm (pattern): producer-consumer

• Output of one program is input to another

  • program 1 writes file; program 2 reads file

• Problems:

  • program 2 has to wait for program 1 to finish before it can start
  • inefficient to write to disk

• Solution: pipe

  • write to/read from kernel buffer (memory)
  • producer blocks when pipe is full
  • consumer blocks when pipe is empty
  • otherwise, both processes proceed concurrently

• data "flows" between processes

  • dataflow

• pipe system call returns pair of open file descriptors for producer (writer) & consumer (reader)

  • open files (descriptors) stay open across fork & exec
    • this means pipes can only work for descendants of the process that creates the pipe
      • other techniques are available for unrelated processes
  • shell syntax provides convenient way to connect standard output program 1 to standard input of program 2
    • most common way pipes are used