Architettura Sistemi Operativi Sommario

Sistemi Operativi
(modulo di Informatica II)
Architettura
Patrizia Scandurra
Università degli Studi di Bergamo
a.a. 2008-09
Sommario
Obiettivi di un sistema operativo
Concetti di base sui sistemi operativi
Funzioni di un sistema operativo
Servizi e chiamate di sistema
Funzionamento Dual-Mode
Programmi di sistema
Struttura di un sistema operativo
Implementazione e avvio del sistema operativo
Obiettivi (1)
Astrazione
Alzare il livello di astrazione dei componenti del sistema di
elaborazione (macchina di von Neumann)
Astrazione del comportamento
Semplificazione dell’uso
Gestione ottimizzata
Obiettivi (2)
Virtualizzazione
Creazione di un’immagine del sistema di elaborazione dedicata a
ciascun programma in esecuzione
Indipendenza dalla presenza di altri programmi
Semplificazione nella implementazione dei programmi applicativi e
dell’uso delle risorse
Funzione principale di un SO
Un SO fornisce l’ambiente per l’esecuzione dei
programmi
Più in dettaglio …..
Funzioni (1)
Gestione del processore
---> Gestione dei processi
Un processo è un programma in esecuzione
Creazione e terminazione dei processi
Sospensione e riattivazione dei processi
Schedulazione dei processi
Sincronizzazione tra processi
Gestione di situazioni di stallo (deadlock)
Comunicazioni tra processi
Funzioni (2)
Gestione della memoria centrale
--->
Processi
in memoria centrale
per esecuzione
Multiprogrammazione
Allocazione e deallocazione della memoria
ai processi
Caricamento e scaricamento di processi
e di loro porzioni in memoria centrale
Protezione della memoria centrale
Funzioni (3)
Gestione delle periferiche
--->
omogeneità di interazione
Configurazione e inizializzazione
Interfaccia generale e omogenea
Gestione ottimizzata dei dispositivi di I/O, memorizzazione di
massa e rete informatica
Protezione delle periferiche
Bufferizzazione
Caching
Funzioni (4)
Gestione del file system
--->
file e albero del file system
File e directory
Creazione e cancellazione
Lettura e scrittura
Copiatura
Ricerca
Salvataggio e ripristino
Protezione e sicurezza
Funzioni (5)
Gestione dell’interfaccia utente
---> interazione con utenti e
processi attraverso istruzioni di controllo
Interprete dei comandi o shell
(programma che legge ed interpreta istruzioni di controllo)
a livello utente
a livello programmi (chiamate di sistema)
Librerie
Gestione degli errori e dei malfunzionamenti
Servizi del sistema operativo (1)
Il SO fornisce servizi ai programmi e agli utenti dei programmi
Elaborazione
il sistema deve potere caricare un programma in memoria e eseguirlo
Operazioni di I/O – in generale gli utenti non possono controllare
direttamente i dispositivi di I/O; è il SO che deve fornire i mezzi per
compiere le operazioni di I/O
Manipolazione del file system – i programmi devono poter leggere,
scrivere, creare e cancellare i file
Servizi del sistema operativo (2)
Comunicazione fra processi in esecuzione sullo stesso computer o in
esecuzione su computer differenti collegati fra loro in rete
Le comunicazioni possono avvenire attraverso
una memoria condivisa o
attraverso scambio di messaggi
Rilevamento degli errori – il sistema assicura un calcolo corretto
per individuare errori
nella CPU
nell’hardware della memoria,
nei dispositivi di I/O e nei programmi dell’utente
Servizi del sistema operativo (3)
Esistono servizi aggiuntivi per una gestione efficiente del sistema
Allocazione delle risorse – quando ci sono più utenti o più processi
contemporaneamente in funzione, le risorse devono essere assegnate a
ciascuno di loro
Contabilità (accounting)– mantiene traccia di quali utenti usano le risorse
e di quale tipo e genere di risorse si tratta per stilare statistiche d’uso o
per la contabilità
Protezione e sicurezza – implica la garanzia che tutti gli accessi alle
risorse del sistema siano controllati
Chiamate di sistema (1)
Chiamata di sistema: interazione elementare tra un programma
utente e il SO
Con le chiamate di sistema i programmi utente accedono ai servizi
del SO disponibili come istruzioni in:
linguaggio assembler
linguaggi di programmazione di più alto livello come C e C++
permettono alle chiamate di sistema di avvenire direttamente
Java non lo permette
poiché una chiamata di sistema è specifica del SO e dà come risultato
un codice specifico della piattaforma
tuttavia se richiesto, è possibile attraverso metodi nativi
Java può richiamare metodi scritti in un altro linguaggio (C o
C++) che eseguono la chiamata di sistema
Chiamate di sistema (2)
Le chiamate di sistema possono richiedere lo scambio di
informazioni (parametri) tra un programma e il SO
Lo scambio dei parametri avviene in generale in 3 modi:
1.
attraverso i registri
attuabile solo se il numero dei parametri non supera quello dei registri
2.
attraverso una tabella in memoria, e l’indirizzo della tabella
viene passato come parametro in un registro
Usato da Linux
3.
attraverso una memoria provvisoria detta pila (stack) posti dal
programma e prelevati dal SO
Soluzione preferita, perché non limitano il numero o la lunghezza dei
parametri
System call / API di Unix
(API = Application Programmer's Interface)
System call / API di Windows
Relazione tra funzioni di API e system call ignota e comunque non fissa
Presumibili funzioni API in relazione 1-1 con system call: Win32 API
Programmi di sistema
La visione del SO offerta agli utenti è definita in genere dai programmi
di sistema piuttosto che dalle effettive chiamate di sistema
I programmi di sistema forniscono un ambiente opportuno per la
gestione delle risorse e lo sviluppo di applicazioni
Gestione dei file
Informazioni di stato (data, ora, spazio su disco, ecc..)
Modifica dei file (es. programmi elaborazioni testo)
Supporto ai linguaggi di programmazione (compilatori, assemblatori,
debugger, ecc..)
Caricamento ed esecuzione dei programmi
Comunicazioni (posta elettronica, login remoto, ecc..)
SO e programmi utente (1)
Il software utente può dunque essere:
1. applicativo o
2. di sistema cioè “di base” (es. shell)
La seconda categoria non va confusa con il SO!
SO e programmi utente (2)
Differenze tra sw utente e il SO:
il sw utente, anche se di sistema, non accede direttamente alle risorse
fisiche
il sw utente è eseguito con la CPU in user mode (se disponibile);
ciò impedisce:
l’accesso diretto alle risorse fisiche, nonché
manomissioni del SO
viceversa il SO, eseguito con la CPU in kernel mode, non ha
limiti nell’accesso all’hardware
Funzionamento Dual-Mode (1)
L’hardware deve fornire un supporto per differenziare almeno tra due
modi di funzionamento
1. User mode – la CPU sta eseguendo codice di un utente
2. Kernel mode (anche supervisor mode, system mode, monitor
mode) – la CPU sta eseguendo codice del sistema operativo
La CPU ha un Mode bit che indica in quale modo si trova: kernel
(0) o user (1)
Funzionamento Dual-Mode (2)
Protezione dei registri da accessi erronei/intenzionali
L'accesso completo all'hardware solo in modo kernel
Passaggio controllato da modo utente a modo kernel
interruzioni
chiamate di sistema (system call) – trap/fault
Interruzioni (1)
(a)
(b)
(a) passi necessari per inizializzare un dispositivo e ricevere una
interruzione
(b) come viene interrotta la CPU
Interruzioni (2)
Passi necessari alla gestione di una interruzione:
1. CPU rileva l’interruzione e legge l’indirizzo del dispositivo (device) su
bus
salvataggio PC/PSW sullo stack, passaggio in modo kernel
2. L’indirizzo del dispositivo viene usato come indice nella tabella dei
gestori delle interruzioni (interrupt vector)
3. Il gestore selezionato prende il controllo e svolge le operazioni
necessarie
4. Quando il gestore termina
ripristino PC/PSW , ritorno in modo utente
si esegue l’istruzione successiva a quella interotta
Chiamate di Sistema (System Call) (1)
Gli 11 passi necessari per effettuare la chiamata di sistema
read (fd, buffer, nbytes)
Chiamate di Sistema (System Call) (2)
Dettaglio dell’esecuzione di read (fd, buffer, nbytes)
1-3. Salvataggio dei parametri sullo stack
4. Chiamata della funzione di libreria read()
5. Caricamento del codice della system call in un registro fissato Rx
6. Esecuzione TRAP
passaggio in kernel mode, salto al codice del dispatcher
7-8. Selezione della SC secondo il codice in Rx
9. Ritorno alla funzione di libreria
ripristino user mode, caricamento PC
10-11. Ritorno al codice utente (nel modo usuale)
Struttura di un sistema operativo
Come sono organizzate le varie componenti di un SO?
Sistema monolitico
Sistema stratificato
Sistema a microkernel
Sistema a moduli funzionali
Sistema a macchine virtuali
Sistema client/server
Struttura monolitica (1)
Molti SO commerciali non hanno una struttura ben definita
procedure di servizio compilate in un unico oggetto
ogni procedura può chiamare tutte le altre
ogni processo esegue parzialmente in modo kernel
system call bloccanti
Struttura monolitica (2)
Spesso nascono come sistemi piccoli, semplici e limitati, per poi
crescere al di là dello scopo originario
L’MS-DOS ne è un esempio
Funzionava su un hardware limitato (l’8088 dell’Intel)
SO molto vulnerabile perché lascia libertà ai programmi applicativi di
accedere direttamente all’hardware
Un altro esempio di SO con struttura semplice è l’originario Unix
anch’esso inizialmente limitato dall’hardware
La struttura dell’MS-DOS
Le interfacce e i livelli di funzionalità non sono ben separati
Ad es. i programmi applicativi possono accedere alle procedure di I/O
di base per scrivere direttamente sullo schermo e sui dischi
Struttura del sistema UNIX (1)
UNIX consiste di due parti separabili:
1. Programmi di sistema
2. Nucleo (kernel):
Consiste in qualsiasi parte si trovi sotto l’interfaccia di chiamata di
sistema e sopra l’hardware fisico
Un’enorme quantità di funzioni combinate in un solo livello:
gestione del file-system, schedulazione della CPU, gestione della
memoria, ecc..
Struttura del sistema UNIX (2)
Struttura stratificata (1)
Il SO è diviso in un certo numero di strati (livelli, o layers), ognuno
costruito sulla sommità dello strato inferiore
Lo strato inferiore (il livello 0) è l’hardware; quello più elevato (il livello
N) è l’interfaccia utente
Struttura stratificata (2)
Vantaggi/svantaggi:
Ogni strato offre una virtualizzazione di un certo numero di funzioni
(macchina virtuale)
La dipendenza dall’hardware è limitata al livello più basso
(portabilità)
La portabilità si paga con minor efficienza perché una chiamata di
sistema deve attraversare più strati
La struttura a strati di IBM OS/2
Una nicchia nel settore bancario, ma attualmente lo sviluppo di IBM OS/2
è congelato ed il supporto tecnico è cessato (dal 31 Dic 2006)
Struttura a microkernel
Sposta il maggior numero di funzionalità possibili dal kernel allo spazio
utente
La comunicazione tra moduli avviene tramite lo scambio di messaggi
Vantaggi/svantaggi:
Facilità di estendere il SO (lasciando invariato il microkernel)
Maggiore portabilità del SO da un’architettura HW a un’altra
Maggiore affidabilità e sicurezza (meno codice viene eseguito in
modalità kernel)
I microkernel possono soffrire di calo di prestazioni per l’aumento di
sovraccarico di funzioni di sistema
La struttura di Mach OS
Struttura ibrida (alla base di molti sistemi commerciali come Mac OS X)
Struttura a strati dove uno strato il microkernel Mach (sviluppato presso
la Carnegie Mellon University) e l’altro il kernel BSD (Berkely SW
Distribution)
In aggiunta a Mach e a BSD, esistono anche moduli caricabili
dinamicamente (estensioni del kernel)
Struttura modulare
Moderna metodologia di progetto che realizza kernel modulari
attraverso tecniche object-oriented
ogni componente core è separata e interagisce con le altre attraverso
interfacce ben note
ogni componente è caricabile dinamicamente nel kernel al momento del
boot e/o durante l’esecuzione
Simile alla struttura a strati, ma con maggiore flessibilità
Simile alla struttura a microkernel ma più efficiente perchè i moduli
non richiedono l’invio di messaggi per la comunicazione
I moduli caricabili di Sun Solaris
Struttura a macchine virtuali (1)
L’approccio a strati trova il suo logico sbocco nel concetto di
macchina virtuale
Questa tratta l’hardware e il SO come se fossero tutto
hardware
Una macchina virtuale fornisce un’interfaccia che è
identica al puro hardware sottostante
Il SO crea l’illusione che un processo abbia un proprio processore
ed una propria memoria (virtuale)
Struttura a macchine virtuali (2)
Il computer fisico condivide le risorse per generare
macchine virtuali
La schedulazione della CPU può dare l’impressione che gli utenti
abbiano un proprio processore dedicato
Lo spooling e il file system possono fornire lettori di schede e
stampanti in linea virtuali
Un normale terminale time-sharing fornisce la funzione di console
all’operatore di una macchina virtuale
Struttura a macchine virtuali (3)
Non-virtual Machine
Virtual Machine
Ogni macchina virtuale può eseguire il proprio SO
Struttura a macchine virtuali (4)
Vantaggi/svantaggi
Comporta la completa protezione delle risorse di sistema perchè ogni
macchina virtuale è isolata da tutte le altre
Questo isolamento, tuttavia, non permette la condivisione diretta delle risorse
Una macchina virtuale è uno strumento perfetto per l’emulazione di altri
SO o lo sviluppo di nuovi SO
Tutto si svolge sulla macchina virtuale, invece che su quella fisica, quindi non c’è
pericolo di fare danni
Le normali operazioni di sistema raramente fanno sì che si debba interrompere lo
sviluppo del sistema
Difficile da implementare in quanto richiede molto lavoro per creare un
esatto duplicato della macchina sottostante
La Java Virtual Machine (JVM) (1)
I programmi Java compilati sono bytecode indipendenti dall’architettura
ed eseguiti da una Java Virtual Machine
La Java Virtual Machine (JVM) (2)
La JVM consiste di:
un caricatore di classi (class loader)
class verifier e interprete software
Struttura client/server (1)
Un processo utente (processo client) richiede un servizio (ad es.
lettura di un file) ad un processo di SO (processo server)
Client e server operano in modalità utente
I processi server realizzano le politiche di gestione delle risorse
Il kernel include i dati che descrivono un processo e realizza i
meccanismi di comunicazione tra processi
Struttura client/server (2)
Vantaggi/svantaggi
Modularità: suddivisione della funzionalità del SO in moduli
Portabilità: separazione tra politiche e meccanismi
Le politiche determinano che cosa sarà fatto
I meccanismi determinano come fare qualcosa
La separazione tra politica e meccanismo permette la max flessibilità se le
decisioni della politica sono da cambiare in seguito
Perdita di efficienza: comunicazione sistemi client-server
Windows NT 3.0 adottava un modello ispirato al client/server
Studiato in ambito accademico (MACH, Minix)
Modello client/server nei sistemi
distribuiti
Più calcolatori tra loro collegati, ciascuno con una propria copia del
kernel ed un certo numero di processi client e/o server
I processi client richiedono servizi inviando le richieste tramite il kernel
Caratteristiche dei moderni SO
Architettura a micro-kernel
SO semplice, detto (micro-)kernel
Multi-threading
Suddivisione di uno stesso processo in flussi paralleli
Multi-processing simmetrico
Più processori che condividono memoria e dispositivi di I/O,
comunicano tramite bus, possono effettuare le stesse operazioni
SO distribuiti
Sistemi multi-computer
Implementazione del SO
Tradizionalmente scritti in linguaggio assembler,oggi
possono essere scritti in linguaggi ad alto livello
un codice scritto in un linguaggio ad alto livello:
può essere scritto più velocemente
è più compatto
è più facile da capire e da mettere a punto
Un SO è molto più se è scritto in un linguaggio ad alto livello
I SO basati sui linguaggi si affidano alla sicurezza del linguaggio
Java è considerato un linguaggio sicuro
Linguaggi ritenuti sicuri sono utili per implementare SO su HW limitati
(palmari, smart card, ecc..) che non hanno protezione fornita da HW
Generazione del SO
I SO sono progettati per funzionare su di una classe di macchine;
ma deve essere configurato per ogni HW specifico
Il programma SYSGEN (SystemGeneration) recupera l’informazione
riguardante la configurazione specifica dell’HW
Avvio (boot) del SO (1)
I passi sono:
Accensione
Esecuzione del BIOS (POST e inizializzazioni)
Esecuzione del bootstrap program (caricamento del kernel SO)
Controllo del sistema da parte del SO
Bootstrap program o bootstrap loader – codice contenuto nella memoria a sola
lettura (ROM) in grado di individuare il kernel, caricarlo nella memoria
centrale e iniziarne l’esecuzione
Avvio (boot) del SO (2)
Dove risiede il kernel SO?
Nelle tradizionali console giochi e PDA, il SO risiede in memorie
ROM-like (firmware)
costoso
non facilmente modificabile (anche se protetto da virus)
più lento eseguire da ROM che da RAM
In generale, il SO è nel disco (in una partizione detta attiva) ed
il bootstrap program è in memoria ROM
Il bootstrap program si avvale di un frammento di codice (che sà in
quale parte del disco si trova il SO) che risiede in un blocco del disco ad
una posizione fissa (tipicamente 0) – boot block
La partizione del disco che contiene il boot block è detta di avvio