operating systems paulo marques departamento de eng. informática universidade de coimbra...

44
Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra [email protected] 2006/200 7 1. Introduction

Post on 20-Dec-2015

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

OperatingSystems

Paulo MarquesDepartamento de Eng. InformáticaUniversidade de [email protected]

2006

/200

7

1. Introduction

Page 2: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

2

Disclaimer

This slides and notes are heavily based on the companion material of [Silberschatz05].The original material can be found at: http://codex.cs.yale.edu/avi/os-book/os7/slide-dir/index.html

In some cases, material from [Stallings04] may also be used. The original material can be found at: http://williamstallings.com/OS/OS5e.html

The respective copyrights belong to their owners.

Page 3: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

3

What’s an Operating System?

Hardware

Operating System

User Applications

Page 4: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

4

What Operating Systems Do

Controls and coordinates use of hardware among various applications and users The OS is a resource allocator: it manages all resources

and decides between conflicting requests for efficient and fair resource use

OS is a control program: controls execution of programs to prevent errors and improper use of the computer

Page 5: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

5

Two Modes of Operation

User Mode

Kernel Mode

UNIX Operating System Structure

Page 6: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

6

Input/Output versus CPU Usage

I/O devices and the CPU can execute concurrently Each device controller is in charge of a particular

device type Each device controller has a local buffer CPU moves data from/to main memory to/from

local buffers I/O is from the device to local buffer of controller Device controller informs CPU that it has finished

its operation by causing an interrupt

Page 7: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

7

Interrupt Timeline

Page 8: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

8

Interrupt Operation

Interrupt transfers control to the interrupt service routine generally, through the interrupt vector, which contains the addresses of all the service routines

Interrupt architecture must save the address of the interrupted instruction and the relevant context of the executing program

Incoming interrupts are disabled while another interrupt is being processed to prevent a lost interrupt

A trap is a software-generated interrupt caused either by an error or a user request

An operating system is interrupt driven

Page 9: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

9

Interrupt Operation (2)

The operating system preserves the state of the CPU by storing registers and the program counter

Determines which type of interrupt has occurred: polling vectored interrupt system

Separate segments of code determine what action should be taken for each type of interrupt

Page 10: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

10

Different Types of I/O

Page 11: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

11

Different Types of I/O (2)

After I/O starts, control returns to user program only upon I/O completion: Wait instruction idles the CPU until the next interrupt Wait loop (contention for memory access) At most one I/O request is outstanding at a time,

no simultaneous I/O processing or even CPU processing

After I/O starts, control returns to user program without waiting for I/O completion: System call – request to the operating system to allow user

to wait for I/O completion Device-status table contains an entry for each I/O device

indicating its type, address, and state Operating system indexes into I/O device table to determine

device status and to modify table entry to include interrupt Multiple outstanding I/O operations over time.

Also, CPU processing can carry on.

Page 12: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

12

Device Status Table

Page 13: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

13

Direct Memory Access (DMA)

Used for high-speed I/O devices able to transmit information at close to memory speeds

Device controller transfers blocks of data from buffer storage directly to main memory without CPU intervention

Implies the capability of arbitrating the system bus

Only one interrupt is generated per block, rather than the one interrupt per byte

Page 14: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

14

DMA (2)

Page 15: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

15

Storage Hierarchy

Caches, Buffers and a Storage Hierarchy are Essential

Page 16: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

16

Storage Hierarchy

A great part of this hierarchy is controlled by the Operating System Cache Management Policies Buffer Management Policies Memory Management Policies

Principles of Locality: - Temporal Locality - Spatial Locality

Page 17: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

17

Protection

Dual Mode of Operation “User Mode” and “Kernel Mode” In “User Mode” only common instructions can be performed (e.g.

arithmetic and logic). In “Kernel Mode” can do anything. A mode bit contains the current mode of operation Kernel mode assumed on traps and on interrupts

I/O Protection All I/O Instructions are privileged.

For doing I/O a trap into the operating system must be generated.

Memory Protection Each program can only access its memory

CPU Protection The CPU must remain in control of the Operating System, even if

the applications don’t want to let go.

Page 18: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

18

Dual Mode of Operation

Page 19: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

19

System Calls, Traps and Interrupts

Operating System

Interrupts

TrapsSystem calls

Page 20: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

20

Structure of a System Call

Page 21: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

21

Example with a “Hello World” Application!

The “strace” program is very useful: It allows you to see what system calls are made and with

what parameters!

#include <stdio.h>

int main() { printf(“Hello World\n”); return 0;}

Page 22: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

22

“strace” in Action!

Page 23: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

23

System Call Implementation

Typically, a number associated with each system call System-call interface maintains a table indexed according

to these numbers The system call interface invokes intended system

call in OS kernel and returns status of the system call and any return values

The caller needs to know nothing about how the system call is implemented Just needs to obey an API and understand what the OS will

do as a result call Most details of OS interface are hidden from the

programmer by the API

Page 24: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

24

System Call Example (Win32 API)

Quick Question:Why use function libraries instead of system calls??

Page 25: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

25

System Call Implementation (2)

Often, more information is required than simply the identity of the desired system call Exact type and amount of information vary according to OS

and call Three general methods used to pass parameters to

the OS Simplest: pass the parameters in registers

In some cases, there may be more parameters than registers Parameters stored in a block, or table, in memory, and

address of block passed as a parameter in a register This approach is taken by Linux and Solaris

Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system

Block and stack methods do not limit the number or length of parameters being passed

Page 26: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

26

System Call Parameter Passing

Page 27: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

27

Memory Protection

Each program must only be able to access its own memory Segmentation Virtual Memory (Mostly Used Today)

Segmentation is based on having a base pointer and a limit for each process running Any access made outside of its “space” generates a trap

and normally leads to the process being killed

Virtual Memory is based on having a table that translates “virtual addresses” into real ones Normally, there is such a table for each process Each process sees all the address space An access made to an non existing page generates a trap

and normally leads to the process being killed

Page 28: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

28

Segmentation

Page 29: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

29

Virtual Memory

0 0

4Gb 4Gb

Address Spaceof Process A

Address Spaceof Process B

1000 1000

Physical Memory0

256Mb5000

Address TranslationTable

Disk

(simplified)

Page 30: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

30

Multiprogramming

Multiprogramming: maintaining several jobs in memory, active at the same time, so that when the current program can no longer run (for example because it’s blocked waiting for I/O), another is available to run

Optimizes resource utilization: CPU and I/O

CPU

Time Multiplexed CPU

E.g. Windows 95/98!

Page 31: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

31

Multitasking

Multitasking is an extension of multiprogramming in which the execution of the active programs is time-sliced: Each program runs for a short period of time, then

another is run. When a program is running and is forcibly replaced by

another, typically with a higher priority, it is said to have been preempted, thus the term Preemptive Operating Systems

Page 32: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

32

Multitasking

For implementing multitasking, a non-maskable interrupt must connected to a hardware timer Every few milliseconds (e.g. 100ms), the interrupt causes

atask (or process) switch

total = 0;for (int i=0; i<20000; i++) total = total + i;

printf(“total=%d\n”, total);

while (!feof(fd)){ if (fscanf(fd, “%d”, &d) == 1) printf(“%d\n”, d);}

(...)User Level

Kernel LevelInterrupt Handler

Page 33: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

33

Important Note

Although they are both quite heavy!

Mode Switch != Task Switch

Page 34: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

34

Nowadays…

Windows XP, Linux 2.6.xx: Preemptive multitasking operating systems using

virtual memory Each process thinks it has the whole computer for itself

“Virtual Machine”

Page 35: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

35

Operating System Architecture and Structures

Currently, there are two dominant architectures…

Microkernel: Moves as much as possible from the kernel into “user”

space Communication takes place between user modules

using message passing

Benefits: Easier to extend a microkernel Easier to port the operating system to new architectures More reliable (less code is running in kernel mode) More secure

Detriments: SLOW: Performance overhead of user space to kernel space

communication

Page 36: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

36

Operating System Architecture and Structures

Currently, there are two dominant architectures…

Monolithic: 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; a large number of functions for one level

Benefits: FAST!

Detriments: Less reliable (more code is running in kernel mode) Less secure No so easy to port to new architectures (… it depends)

Page 37: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

37

Operating System Architecture and Structures

Most modern operating systems implement kernel 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

Benefits It’s easier to extend the operating system Allows to isolate functionality in well defined software

entities, making the OS more maintainable and reliability

Page 38: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

38

Kernel Modules in Solaris

Page 39: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

39

Operating System Architecture and Structures

Virtual Machines

Facet A: “Abstract Machine” with a certain ISA (e.g. Java, MS.NET) Good for portability, allowing running the same

unmodified application in different physical architectures

Facet B: Software that allows different operating systems to be run

in parallel giving them the illusion of “having a whole machine” (e.g. VMWARE, Xen)

Allows for server consolidation, software testing, software fault tolerance, etc.

Page 40: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

40

Microsoft .NET CLR

The CLRvirtual machine

Host Operating System

Hardware

.NET Application

Page 41: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

41

VMWARE Architecture

Page 42: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

42

Operating System Booting

Every time the computer wakes up, it starts executing code at a certain address On your PC, it’s address 0x000FFFF0!

At that address there is no RAM! What’s mapped there it’s an EPROM with the BIOS!

The BIOS contains a small program that performs a certain number of functions: Executes the POST test (Power On Self Test)… Looks and initializes the Graph Card… and other devices (…) Locates the device where to boot from… (assume a disk) Tries to execute the code at cylinder 0, head 0, sector 1!

At the first sector of the disk resides the MBR: Master Boot Record

Page 43: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

43

Operating System Booting (2)

The program in the MBR checks the primary partition table of the disk

If it finds a primary partition marked active, it starts executing the code of its volume boot sector

This volume boot sector normally consists in a boot loader which, eventually, loads the code of the operating system and starts to execute it

The operating system has to setup all the necessary data structures (e.g. special registers of the processor).

The last step before entering its “main execution stage” is switching to protected mode

And… that’s it!

Page 44: Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra pmarques@dei.uc.pt 2006/2007 1. Introduction

44

Reference

Chapter 1: Introduction 1.1, 1.2, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9

Chapter 2: Operating Systems Structures All chapter 2! 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9,

2.10