it 344: operating systems winter 2010 module 3 operating system components and structure chia-chi...

39
Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng [email protected] u 265G CTB

Upload: francis-park

Post on 28-Dec-2015

215 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

IT 344: Operating

Systems

Winter 2010

Module 3

Operating

System

Components and

Structure

Chia-Chi [email protected]

du265G CTB

Page 2: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

“Those who disregard the lessons of history are destined to repeat them.”

- George Santayana

Page 3: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

• Keep up with the reading schedule• Quiz1 - Tue Jan 26 (in class & timed) on processes

and threads

• Project #1 demo

04/19/23 3

Page 4: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 4

OS structure

• The OS sits between application programs and the hardware– it mediates access and abstracts away ugliness– programs request services via exceptions (traps or faults)– devices request attention via interrupts

OS

P1

P2 P3P4

D1D2 D3

D4

exceptioninterrupt

dispatch

start i/o

Page 5: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 5

Hardware (CPU, devices)

Application Interface (API)

Hardware Abstraction Layer

File Systems

Memory Manager

Process Manager

Network Support

Device Drivers

Interrupt Handlers

Boot & Init

JavaPhotoshopFirefox

Ope

ratin

g S

yste

mP

ortableU

ser

App

s

Acrobat

Page 6: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 6

Memory Management

I/O System

Secondary Storage Management

File System

Protection System

Accounting System

Process Management

Command Interpreter

Information Services

Error Handling

Page 7: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 7

Major OS components

• processes (& threads)• memory• I/O• secondary storage• file systems• protection• accounting• shells (command interpreter, or OS UI)• GUI• networking

Page 8: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

OS Services (What things does the OS do?)

• Services that (more-or-less) map onto components– Program execution (process management)

• How do you execute concurrent sequences of instructions?– I/O operations

• Standardized interfaces to extremely diverse devices– File system manipulation

• How do you read/write/preserve files?• Looming concern: How do you even find files???

– Communications• Networking protocols/Interface with CyberSpace?

• Cross-cutting capabilities– Error detection & recovery– Resource allocation– Accounting– Protection

Page 9: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 9

Process management

• An OS executes many kinds of activities:– users’ programs– batch jobs or scripts– system programs

• print spoolers, name servers, file servers, network daemons, …

• Each of these activities is encapsulated in a process– a process includes the execution context

• PC, registers, VM, OS resources (e.g., open files), etc…

• plus the program itself (code and data)

– the OS’s process module manages these processes• creation, destruction, scheduling, …

Page 10: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 10

Program/processor/process

• Note that a program is totally passive– just bytes on a disk that encode instructions to be run

• A process is an instance of a program being executed by a (real or virtual) processor– at any instant, there may be many processes running copies

of the same program (e.g., an editor); each process is separate and (usually) independent

– Linux: ps -auwwx to list all processes

process A process B

code stack PC

registers

code stack PC

registers

page tables

resources

page tables

resources

Page 11: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 11

States of a user process

running

ready

blocked

exception

interruptdispatch

interrupt

Page 12: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 12

Process operations

• The OS provides the following kinds operations on processes (i.e., the process abstraction interface):– create a process– delete a process– suspend a process– resume a process– clone a process– inter-process communication (IPC)– inter-process synchronization– create/delete a child process (subprocess)

Page 13: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 13

Memory management

• The primary memory (or RAM) is the directly accessed storage for the CPU– programs must be stored in memory to execute– memory access is fast (e.g., 60 ns to load/store)

• but memory doesn’t survive power failures

• OS must:– allocate memory space for programs (explicitly and

implicitly)– deallocate space when needed by rest of system– maintain mappings from physical to virtual memory

• through page tables

– decide how much memory to allocate to each process• a policy decision

– decide when to remove a process from memory• also policy

Page 14: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 14

I/O

• A big chunk of the OS kernel deals with I/O– hundreds of thousands of lines in Windows

• The OS provides a standard interface between programs (user or system) and devices– file system (disk), sockets (network), frame buffer (video)

• Device drivers are the routines that interact with specific device types– encapsulates device-specific knowledge

• e.g., how to initialize a device, how to request I/O, how to handle interrupts or errors

• examples: SCSI device drivers, Ethernet card drivers, video card drivers, sound card drivers, …

• Note: Windows has > 35,000 device drivers!

Page 15: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 15

Secondary storage

• Secondary storage (disk, tape) is persistent memory– often magnetic media, survives power failures (hopefully)

• Routines that interact with disks are typically at a very low level in the OS– used by many components (file system, VM, …)– handle scheduling of disk operations, head movement, error

handling, and often management of space on disks

• Usually independent of file system– although there may be cooperation– file system knowledge of device details can help optimize

performance• e.g., place related files close together on disk

Page 16: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 17

File systems

• Secondary storage devices are crude and awkward– e.g., “write 4096 byte block to sector 12”

• File system: a convenient abstraction– defines logical objects like files and directories

• hides details about where on disk files live

– as well as operations on objects like read and write• read/write (logical) byte ranges instead of (physical) blocks

• A file is the basic unit of long-term storage– file = named collection of persistent information

• A directory is just a special kind of file– directory = named file that contains names of other files and

metadata about those files (e.g., file size)

Page 17: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 18

File system operations

• The file system interface defines standard operations:– file (or directory) creation and deletion– manipulation of files and directories (read, write, extend,

rename, protect, …)– copy– lock

• File systems also provide higher level services– accounting and quotas– backup (must be incremental and online!)– (sometimes) indexing or search– (sometimes) file versioning

Page 18: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 19

Protection

• Protection is a general mechanism used throughout the OS– all resources needed to be protected

• memory

• processes

• files

• devices

• CPU time

• …

– protection mechanisms help to detect and contain unintentional errors, as well as preventing malicious destruction

Page 19: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 20

Command interpreter (shell)

• A particular program that handles the interpretation of users’ commands and helps to manage processes– user input may be from keyboard (command-line interface),

from script files, or from the mouse (GUIs)– allows users to launch and control new programs

• On some systems, command interpreter may be a standard part of the OS (e.g., MS DOS, Apple II)

• On others, it’s just non-privileged code that provides an interface to the user– e.g., bash/csh/tcsh/zsh on UNIX

• On others, there may be no command language– e.g., “classic” MacOS (9 and earlier)

Page 20: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 21

Accounting

• Keeps track of resource usage– both to enforce quotas

• “you’re over your disk space limit”

– or to produce bills• timeshared computers like mainframes or super computers

• hosted services

GUI … Networking … etc.

Page 21: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 22

OS structure

• It’s not always clear how to stitch OS modules together:

Memory Management

I/O System

Secondary Storage Management

File System

Protection System

Accounting System

Process Management

Command Interpreter

Information Services

Error Handling

Page 22: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 23

OS structure

• An OS consists of all of these components, plus:– many other components– system programs (privileged and non-privileged)

• e.g., bootstrap code, the init program, …

• Major issue:– how do we organize all this?– what are all of the code modules, and where do they exist?– how do they cooperate?

• Massive software engineering and design problem– design a large, complex program that:

• performs well, is reliable, is extensible, is backwards compatible, …

Page 23: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 24

Page 24: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Operating Systems Structure

• What is the organizational principle?– Simple

• Only one or two levels of code– Layered

• Lower levels independent of upper levels– Microkernel

• OS built from many user-level processes– Modular

• Core kernel with Dynamically loadable modules

Page 25: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Simple Structure • MS-DOS – written to provide the most functionality in the

least space– Not divided into modules– Interfaces and levels of functionality not well separated

Page 26: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

UNIX: Also “Simple” Structure

• UNIX – limited by hardware functionality• Original UNIX operating system consists of two

separable parts:– Systems programs– The kernel

• Consists of everything below the system-call interface and above the physical hardware

• Provides the file system, CPU scheduling, memory management, and other operating-system functions;

• Many interacting functions for one level

Page 27: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

UNIX System Structure

User Mode

Kernel Mode

Hardware

Applications

Standard Libs

Page 28: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 30

Monolithic design

• Major advantage:– cost of module interactions is low (function call)

• Disadvantages:– hard to understand– hard to modify– unreliable (no isolation between system modules)– hard to maintain

• What is the alternative?– find a way to organize the OS in order to simplify its design

and implementation

Page 29: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Layered Structure• Operating system is divided many layers (levels)

– Each built on top of lower layers– Bottom layer (layer 0) is hardware– Highest layer (layer N) is the user interface

• Each layer uses functions (operations) and services of only lower-level layers– Advantage: modularity Easier debugging/Maintenance– Not always possible: Does process scheduler lie above or below

virtual memory layer?• Need to reschedule processor while waiting for paging• May need to page in information about tasks

• Important: Machine-dependent vs independent layers– Easier migration between platforms– Easier evolution of hardware platform– Good idea for you as well!

Page 30: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Layered Operating System

Page 31: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 33

Layering

• The traditional approach is layering– implement OS as a set of layers– each layer presents an enhanced ‘virtual machine’ to the layer above

• The first description of this approach was Dijkstra’s THE system– Layer 5: Job Managers

• Execute users’ programs

– Layer 4: Device Managers• Handle devices and provide buffering

– Layer 3: Console Manager• Implements virtual consoles

– Layer 2: Page Manager• Implements virtual memories for each process

– Layer 1: Kernel• Implements a virtual processor for each process

– Layer 0: Hardware

• Each layer can be tested and verified independently

Page 32: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 34

Problems with layering

• Imposes hierarchical structure– but real systems are more complex:

• file system requires VM services (buffers)

• VM would like to use files for its backing store

– strict layering isn’t flexible enough

• Poor performance– each layer crossing has overhead associated with it

• Disjunction between model and reality– systems modeled as layers, but not really built that way

Page 33: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 35

Hardware Abstraction Layer

• An example of layering in modern operating systems

• Goal: separates hardware-specific routines from the “core” OS– Provides portability– Improves readability

Core OS(file system, scheduler,

system calls)

Hardware AbstractionLayer

(device drivers, assembly routines)

Page 34: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 36

Microkernels

• Goal:– minimize what goes in kernel– organize rest of OS as user-level processes

• Popular in the late 80’s, early 90’s– recent resurgence of popularity. Why?

• This results in:– better reliability (isolation between components)– ease of extension, porting and customization– poor performance (user/kernel boundary crossings)

• First microkernel system was Hydra (CMU, 1970)– Follow-ons: Mach (CMU), Chorus (French UNIX-like OS),

OS X (Apple), in some ways NT (Microsoft)

Page 35: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Microkernel Structure

• Moves as much from the kernel into “user” space– Small core OS running at kernel level– OS Services built from many independent user-level processes

• Communication between modules with message passing• Benefits:

– Easier to extend a microkernel– Easier to port OS to new architectures– More reliable (less code is running in kernel mode)– Fault Isolation (parts of kernel protected from other parts)– More secure

• Detriments:– Performance overhead severe for naïve implementation

Page 36: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 38

Microkernel structure illustrated

hardware

microkernel

system processes

user processes

low-level VMcommunication

protection

processor control

file system

thread mgmt

networking

schedulingpaging

firefox powerpoint

apache

user mode

kernel

Page 37: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Modules-based Structure• Most modern operating systems implement modules

– Uses object-oriented approach– Each core component is separate– Each talks to the others over known interfaces– Each is loadable as needed within the kernel

• Overall, similar to layers but with more flexible

Page 38: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

Administrivia

• HW1 past due• HW2 due next Tuesday• Next week: process and thread

– Keep up with the reading schedule

• Project 1 – start now!– Demo your product during Lab hours in week #6

• Lab feedback

04/19/23 40

Page 39: IT 344: Operating Systems Winter 2010 Module 3 Operating System Components and Structure Chia-Chi Teng ccteng@byu.edu 265G CTB

04/19/23 41

IT 344

• In this class we will learn:– what are the major components of most OS’s?– how are the components structured?– what are the most important (common?) interfaces?– what policies are typically used in an OS?– what algorithms are used to implement policies?

• Philosophy– you may not ever build an OS– but as a computer engineer you need to understand the

foundations– most importantly, operating systems exemplify the sorts of

engineering design tradeoffs that you’ll need to make throughout your careers – compromises among and within cost, performance, functionality, complexity, schedule …