lezione 4 la struttura dei sistemi operativi - di-srv.unisa.itcicalese/so/2014/lecture4_2014.pdf ·...

14
1 Lezione 4 La Struttura dei Sistemi Operativi 4.2 2 Introduzione Funzionamento di un SO La Struttura di un SO Sistemi Operativi con Struttura Monolitica Progettazione a Livelli di un SO

Upload: trinhthien

Post on 20-Feb-2019

215 views

Category:

Documents


0 download

TRANSCRIPT

1

Lezione 4 La Struttura dei Sistemi Operativi

4.2 2

Introduzione

•  Funzionamento di un SO •  La Struttura di un SO •  Sistemi Operativi con Struttura Monolitica •  Progettazione a Livelli di un SO

2

4.3 3

Introduzione (cont.)

•  Macchine Virtuali •  SO basati su Kernel •  SO basati su Microkernel •  Alcuni Esempi

4.4 4

Funzionamento di un SO

•  Boot procedure –  analisi della configurazione—tipo di CPU, dimensione

della memoria, dispositivi I/O, dettagli di altro hw – Carica parti di SO in memoria, inizializzazione delle DS

•  Durante la computazione, interrupt : – Un evento: completamento di I/O; fine di time-slice – System call da un process (software interrupt)

•  Routine di gestione degli Interrupt: – Opera il context save – Attiva il gestore dell’evento (event handler)

•  Scheduler seleziona un processo

3

4.5 5

Funzionamento di un SO

Schema di funzionamento di un SO

4.6 6

Funzionamento di un SO (funzioni)

Funzione Descrizione

Gestione dei processi Generazione e terminazione dei processi, scheduling

Gestione della memoria Allocazione e deallocazione della memoria, swapping, gestione della memoria virtuale

Gestione dell’I/O Servizi per gli interrupt I/O, operazioni di inizio I/O, ottimizzazione delle prestazioni dei dispositivi I/O

Gestione dei file Creazione, memorizzazione e accesso ai file

Sicurezza e protezione Prevenire interferenze tra processi e risorse

Gestione della rete Invio e ricezione di dati attraverso la rete

Funzioni di un SO

4

4.7 7

Struttura di un SO

•  Politiche e Meccanismi •  Portabilita’ ed Espandibilita’ del SO

4.8 8

Politiche e Meccanismi

•  Nella scelta di come il SO eseguira’ una funzione, I progettisti lavorano su due livelli: – Politiche: Principi di funzionamento del OS

•  Determinano COSA dovrebbe essere fatto – Meccanismi: Azioni necessarie per implementare una

politica •  Determinano COME fare e ne sono l’implementazione

•  Esempio: – Scheduling Round-robin e’ una politica – Meccanismo: mantenere una coda di processi pronti e

operare il dispatching dei processi

5

4.9 9

Portabilita’ ed Espandibilita’ del SO

•  Porting: adattare un software per l’uso su hw diverso •  Portabilita’: il grado di facilita’ con cui un programma

software e’ portabile –  Inversamente proporzionale alla difficolta’ di porting

•  Porting di un SO: modifiche al codice dipendente dall’architettura per funzionare sul nuovo HW – Esempi di dati e istruzione di un SO dipendenti

dall’architettura: •  Interrupt vector, informazioni di protezione della memoria,

istruzioni di I/O, etc.

4.10 10

Portabilita’ ed Espandibilita’ del SO (cont.)

•  Espandibilita’: facilita’ nell’aggiunta di nuove funzionalita’ – Espandibilita’ di un SO e’ necessaria per due ragioni:

•  Incorporare nuovo HW in a sistema di calcolo – Nuovi dispositivi di I/O o adattatori di rete

•  Offrire nuove funzionalita’ –  I primi SO non erano strutturati per assicurare

espandibilita’ di alcun tipo –  I moderni SO permettono almeno l’aggiunta di device

driver •  Anche offrendo funzionalita’ di plug-and-play

6

4.11 11

Sistemi Operativi con Struttura Monolitica

•  Tipica dei primi SO – SO strutturato come un unico strato di software tra

l’utente e la macchina (hardware)

Schema della struttura di un SO monolitico

4.12 12

Sistemi Operativi con Struttura Monolitica (cont.)

•  Problemi tipici della struttura monolitica: – SO completamente interfacciato con la macchina

•  Codice dipendente dall’architettura presente in ogni parte del SO

– bassa portabilita’ •  Testing e debugging complesso

– Alti costi di manutenzione e sviluppo

•  Strutture Alternative: – Struttura a Livelli – Struttura basata sul Kernel – Struttura basata su Microkernel

7

4.13 13

•  Il gap semantico si riduce: – Usando una macchina con istruzioni complesse – Simulando tale macchina in uno strato software del SO

Progettazione a Livelli di un SO Definizione: Gap Semantico differenza in “complessita’” tra le operazioni necessarie alle applicazioni e le operazioni fornite dall’hardware

gap semantico tra istruzioni del SO e istruzioni macchina

4.14 14

Progettazione a Livelli di un SO (cont.)

•  Le Routine di un livello usano solo le funzioni del livello direttamente inferiore – Attraverso l’interfaccia offerta da esso

Progettazione a livelli: macchina estesa

8

4.15 15

Esempio: Struttura del sistema multiprogrammato THE

Funzionalita’ nei livelli nel sistema multiprogrammato THE

Livello Descrizione

Livello 0 Allocazione del processore e multiprogrammazione

Livello 1 Gestione della memoria

Livello 2 Comunicazione tra console e processi

Livello 3 Gestione dell’I/O

Livello 4 Processi degli utenti

4.16 16

Progettazione a Livelli di un SO (cont.)

•  Problemi: –  Funzionamento rallentato dalla struttura a livelli – Difficolta’ nella strutturazione dei livelli

•  Problema: come ordinare livelli che interagiscono – Tipicamente risolto dividendo le funzionalita’ di un livello in

due sottolivelli tra i quali vanno i livelli interdipendenti

– Stratificazione delle funzionalita’ del SO •  Progettazione complessa •  Perdita di efficienza, rallentamento •  Espandibilita’ piu’ complessa

9

4.17 17

SO basati su Virtual Machine

•  Diverse classi di utenti richiedono servizi differenti •  Un SO Virtual machine (VM OS) crea diverse macchine

virtuali –  una macchina virtuale (VM) e’ una risorsa virtuale – Ogni VM e’ allocata ad un utente, che puo’ usare un

qualsiasi SO •  Su ogni VM gira un diverso SO ospite

•  VM OS gira sulla macchina reale – Schedula i SO ospiti –  La distinzione tra modalita’ utente e privilegiata della CPU

causa difficolta’ nell’uso di un VM OS

4.18 18

Example: Structure of VM/370

10

4.19 19

SO a Macchine Virtuali (cont.)

•  Virtualizzazione: mappa interfacce e risorse di una VM sulle interfacce e risorse della macchina host (reale) – Virtualizzazione piena puo’ ridurre la sicurezza – Quasi-virtualizzazione sostituisce ad istruzioni non

virtualizzabili altre istruzioni facilmente virtualizzabili •  Il codice di un SO ospite viene modificato in modo da

evitare uso di istruzione non virtualizzabili, questo lo si ottiene mediante:

– Porting del sistema ospite per operare sotto il VM OS

4.20 20

SO a Macchine Virtuali (cont.)

•  VM vengono usate anche senza un VM OS: – Virtual Machine Monitor (VMM)

•  Anche detto hypervisor •  Es., VMware e XEN

– Macchine Virtuali per linguaggi di programmazione •  Pascal negli anni 70

– Ridotte prestazioni •  Java

–  Java virtual machine (JVM) garantisce sicurezza ed affidabilita’

– Migliori prestazioni se implementata in hardware

11

4.21 21

SO basati su Kernel

•  Motivazioni storiche per la struttura basata su kernel: portabilita’ e convenienza nella progettazione ed implementazione delle routine nonkernel – Meccanismi implementati in kernel, politiche al di fuori

•  SO basati su Kernel hanno bassa espandibilita’

Schema di un SO basato su kernel

4.22 22

SO basati su Kernel (cont.)

Funzione SO Descrizione

Gestione dei processi Salvataggio contesto, dispatch, gestione code di scheduling

Comunicazione tra processi

Invio e ricezione di messaggi tra processi

Gestione della memoria Allocazione e deallocazione della memoria, swapping, gestione della memoria virtuale

Gestione dell’I/O Operazioni di inizio I/O, interruzione per completamento I/O, recovery da errori I/O

Gestione dei file Apertura file, lettura/scrittura dei dati

Sicurezza e protezione Aggiunta di informazioni di autenticazione per nuovi utenti, informazioni per la protezione dei file

Gestione della rete Invio e ricezione di dati mediante messaggi

Funzioni tipiche e servizi offerti dal kernel

12

4.23 23

Evoluzione della struttura a Kernel

•  Moduli Kernel caricabili – Kernel progettato come insieme di moduli

•  Moduli interagiscono attraverso interfacce – Kernel di base caricato al boot

•  Altri moduli caricati solo quando servono – Risparmio di memoria

– Usati per implementare device drivers e nuove system calls

•  User-level device drivers –  Facilita’ di sviluppo, debugging, versatitilita’ –  L’efficienza e’ assicurata mediante struttre HW e SW

4.24 24

SO basati su Microkernel

•  Il microkernel fu sviluppato nei primi anni ‘90 per aumentare la portabilita’, espandibilita’ e affidabilita’ dei kernel

•  Un microkernel e’ un nucleo essenziale del codice del SO – Contiene solo un sottoinsieme dei meccanismi

tipicamente inclusi in un kernel – Supporta solo un piccolo insieme di system calls,

altamente verificate e testate – Codice meno essenziale e’ fuori dal kernel

13

4.25 25

SO basati su Microkernel (cont.)

•  Microkernel non include scheduler e gestore della memoria

•  Tali moduli sono eseguiti come server

Struttura di un SO basato su Microkernel

4.26 26

SO basati su Microkernel (cont.)

•  Varianti anche molto diverse dei servizi inclusi in un microkernel

•  SO con microkernel di prima generazione: fino al 50% di peggioramento del throughput –  L4 microkernel (solo 7 sys-call)

•  IPC piu’ efficiente eliminando controlli di validita’ e utilizzando servizi per il microkernel in HW

•  Perdita in performance solo del 5%

16

4.31 31

Sommario

•  Portabilita’ •  Espandibilita’

•  Una funzionalita’ di un SO si basa su una politica e alcuni meccanismi

•  I primi SO erano a struttura monolitica

4.32 32

Sommario (cont.)

•  Struttura a livelli basata sul principio dell’astrazione progrssiva per ridurre la complessita di progettazione

•  The virtual machine operating system (VM OS) supporta il funzionamento di diversi SO insieme sullo stesso computer – Crea una macchina virtuale per ogni utente

•  In una struttura a kernel, il kernel e’ il nucleo del SO, che chiama routine nonkernel routines per implementare operazioni su processi e risorse

•  Un microkernel e’ la parte essenziale del nucleo del codice SO –  I moduli per le politiche come processi server