cos`e` un sistema operativo le chiamate di sistema

COS'E' UN SISTEMA OPERATIVO
Il Sistema Operativo come macchina estesa
Guardando le cose dall'alto (utente) al basso (macchina), la funzionalità del S.O. è quella di mettere a disposizione
dell'utente una comoda interfaccia, cioè presentare all'utente una macchina estesa o una macchina virtuale, che sia più
facile da programmare dell'hardware sottostante.
In questo senso il S.O. fornisce una varietà di servizi, di cui i programmi possono usufruire attraverso istruzioni speciali
dette chiamate di sistema come vedremo più avanti.
Il Sistema Operativo come gestore delle risorse
Guardando le cose dal basso verso l'alto, il compito del S.O. è quello di gestire un'allocazione ordinata delle risorse
hardware ai vari programmi che competono tra loro nell 'usarle. La gestione delle risorse comporta la loro condivisione
sotto due aspetti: rispetto al tempo e rispetto allo spazio.
Quando una risorsa è condivisa rispetto al tempo, programmi e utenti diversi fanno a turno nell’usarla.
Per esempio con un solo processore e più programmi che devono essere eseguiti su di esso, il S.O. prima alloca il
processore ad un programma e, quando questo è stato in esecuzione per un tempo sufficiente, un altro programma
prende in uso il processore e così via. Determinare come la risorsa sia condivisa nel tempo è compito del S.O.
Un altro esempio di condivisione nel tempo è la condivisione della stampante.
L 'altro tipo di condivisione è rispetto allo spazio: invece di alternarsi, ad ognuno viene assegnata parte della
risorsa.
Per esempio, la memoria centrale è normalmente ripartita fra diversi programmi in esecuzione, così che possono
stare in memoria contemporaneamente. Supponendo che ci sia abbastanza memoria per più programmi, è più
efficiente mantenerli in memoria tutti insieme, piuttosto che assegnare tutta la memoria ad uno di essi.
Indubbiamente questo crea problemi di equità, protezione e altri ed è dovere del S.O. risolverli.
Un'altra risorsa che è condivisa rispetto allo spazio è il disco.
LE CHIAMATE DI SISTEMA
La maggior parte delle CPU hanno due modalità: modalità kernel e modalità utente. Generalmente un flag nel Registro
di Stato (PSW) controlla la modalità e quando è in esecuzione in modalità kernel la CPU può eseguire qualunque
istruzione nel suo set di istruzioni ed usare ogni caratteristica dell 'hardware.
Il Sistema Operativo viene eseguito in modalità kernel e questo gli permette l' accesso completo all'hardware.
I programmi utente invece vengono eseguiti in modalità utente e questo permette di eseguire solo una parte del set di
istruzioni e di accedere solo ad una parte delle risorse hardware.
Per ottenere servizi dal S.O. un programma deve eseguire una chiamata di sistema o system call che esegue una trap al
kernel ed invoca il S.O.: l'istruzione TRAP cambia da modalità utente a modalità kernel ed avvia il S.O.
Il S.O. riesce a capire cosa vuole il processo chiamante esaminando i parametri, dopodiche esegue la chiamata di
sistema e restituisce il controllo all'istruzione seguente alla chiamata di sistema. In un certo senso, eseguire una
chiamata di sistema è come eseguire una chiamata di procedura speciale, solo che le chiamate di sistema entrano a far
parte del kernel, mentre le chiamate di procedura no.
Per rendere più chiaro il meccanismo della chiamata di sistema, esaminiamo la chiamata di sistema read che, come
viene gestita da UNIX , chiede tre parametri:
il descrittore di file (fd) che individua il file,
l' indirizzo del buffer cioè l' area di memoria temporanea
il numero di byte da leggere.
Dato che i meccanismi per eseguire una chiamata di sistema sono fortemente dipendenti dalla macchina, e spesso
devono essere espressi in codice assembler, viene fornita una procedura di libreria con lo stesso nome della chiamata di
sistema read per rendere possibile l' esecuzione di chiamate di sistema da programmi scritti in C.
La chiamata di read da un programma in C potrebbe essere:
cont = read (fd, &buffer, nbyte)
e restituire in cont il numero di byte letti.
Le chiamate di sistema vengono eseguite in una sequenza di passi che esaminiamo seguendo l' esecuzione della read.
Prima di chiamare la procedura read che effettivamente esegue la chiamata di sistema read, il programma
chiamante mette i parametri sullo stack. (passi 1,2,3 nella figura)
Poi viene la chiamata alla procedura di libreria read che è la normale istruzione di chiamata di procedura usata per
richiamare tutte le procedure (passo 4).
http://guidepc.altervista.org
La procedura di libreria generalmente mette il numero di chiamata di sistema in un posto noto al S.O. ad esempio
in un registro (passo 5).
Successivamente esegue una istruzione TRAP per passare dalla modalità utente a modalità kernel ed inizia
l'esecuzione ad un indirizzo fisso all'interno del kernel (passo 6).
Il codice del kernel comincia ad esaminare il numero di chiamata di sistema, quindi la smista al corretto gestore
della chiamata di sistema, generalmente attraverso una tabella di puntatori a gestori delle chiamate di sistema
(passo 7).
A questo punto viene eseguito il
gestore della chiamata (passo 8).
Una volta che il gestore ha
completato il suo lavoro, il
controllo può essere restituito alla
procedura di libreria nello spazio
utente, all'istruzione che segue la
TRAP (passo 9).
Si ritorna poi al programma utente
nel solito modo delle procedure
(passo 10).
Per completare il lavoro il
programma utente libera lo stack
come fa per ogni chiamata di
procedura aumentando il valore
dello SP di quanto basta per
rimuovere i parametri posti sullo
stack prima della chiamata a read
(passo 11 ).
Al passo 9 abbiamo detto "il controllo
può essere restituito alla procedura di
libreria" perche la chiamata di sistema può bloccare il programma chiamante impedendogli di continuare, ad esempio
se il programma chiamante sta provando a leggere da tastiera e non è ancora stato scritto nulla. In questo caso il S.O.
cerca se qualche altro processo può essere eseguito e solo quando l'input da tastiera è disponibile viene ripresa l'
esecuzione dei passi 9-11.
Vedere “Il processo”
Principali chiamate di sistema
Un gruppo di chiamate si occupa della gestione dei processi.
In particolare per creare un nuovo processo il processo "padre" tramite una chiamata di sistema crea un duplicato di se
e per attendere la terminazione del processo "figlio" utilizza un'altra chiamata di Isistema.
Molte chiamate di sistema sono collegate al file system.
In particolare le chiamate per leggere e scrivere un file precedute dalle chiamate per aprire e chiudere il file stesso.
Ci sono poi le chiamate relative alla gestione delle directory come mkdir e rmdir e le chiamate, utilizzate solo in UNIX
per fondere due file system in uno solo.
In UNIX ci sono un centinaio di chiamate di.sistema.e, per ogni chiamata di sistema, c'è approssimativamente una
procedura di libreria che viene chiamata per attivarla.
Con Windows, la situazione è diversa: le chiamate di libreria e le vere chiamate di sistema sono spaiate. Microsoft ha
definito un insieme di procedure le Win32 API (Application Program Interface: Interfaccia tra applicazioni e
programmi). Il numero di queste API è estremamente ampio, dell'ordine delle migliaia: molte invocano chiamate di
sistema ma un considerevole numero viene eseguito nello spazio utente.
In UNIX la GUI viene completamente eseguita nello spazio utente, mentre Win32 API ha un ampio numero di
chiamate per la gestione delle finestre che, se il sottosistema grafico viene eseguito nel kernel, sono vere chiamate di
sistema.
STRUTTURA DI UN SISTEMA OPERATIVO
Sistemi a livelli vedi pag 179-181 di Garavaglia Petracchi.
Macchine virtuali
L 'idea utilizzata nel sistema VM/370, è quella di separare nettamente le due funzioni del S.O. quella di fornire la
multiprogrammazione e quella di fornire una macchina estesa.
http://guidepc.altervista.org
Il cuore del sistema, detto monitor della macchina virtuale gira direttamente sull 'hardware e si occupa della
multiprogrammazione, fornendo al livello superiore più macchine virtuali.
Queste macchine virtuali non sono macchine estese ma copie esatte del semplice hardware, incluse le modalità
kernel/utente, l'input/output, le interruzioni e tutto ciò che possiede una vera macchina.
poiche ogni macchina virtuale è identica al vero hardware, ciascuna può far girare qualunque S.O. in particolare alcune
macchine virtuali possono eseguire un S.O. a singolo utente detto CMS (Conversational Monitor System).
Quando un programma CMS esegue una chiamata di sistema, la chiamata viene passata al S.O. nella sua macchina
virtuale con una TRAP e non al VM/370, proprio come se il S.O. girasse su una macchina reale e non su una macchina
virtuale. Il CMS eseguirà le istruzioni per eseguire la chiamata e queste istruzioni vengono catturate con una TRAP dal
VM/370 che le esegue come una parte della sua simulazione.
Operando una separazione completa delle funzioni di multiprogrammazione e di presentazione di una macchina estesa,
ciascuno dei due pezzi può essere più flessibile e più facile da mantenere.
L 'idea di macchina virtuale è usata quando viene eseguito un programma MS-DOS su un Pentium. Intel ha fornito sul
Pentium una modalità virtuale 8086: in questo modo la macchina si comporta come un 8086 e questa modalità è
utilizzata da Windows per eseguire programmi MS-DOS che vengono lanciati in modalità 8086 virtuale. Finchè
eseguono normali istruzioni, vengono eseguiti direttamente sull'hardware, mentre quando un programma prova a fare
una TRAP al sistema operativo per eseguire una chiamata di sistema, si verifica una TRAP al monitor della macchina
virtuale. Notiamo che questo approccio non corrisponde perfettamente a quello del VM/370 perche in questo caso non
viene emulato un Pentium ma solo l'8086.
Un'altra area dove vengono utilizzate le macchine virtuali è per eseguire programmi Java. Quando fu creato il
linguaggio di programmazione Java, fu creata anche una macchina virtuale la JVM (Java Virtual Machine). Il
compilatore Java produce codice per la JVM che viene eseguito da un interprete JVM software. Il vantaggio di questo
approccio è che il codice JVM può essere inviato via Internet ad un altro calcolatore che abbia un interprete e qui
eseguito.
Ovvero, mentre compilando normali exe con un compilatore come C, si sceglie con che set di istruzioni compilarlo
(Win32, Unix…), un programma Java viene sempre compilato con un linguaggio specifico, chiamato ByteCode,
trasformato dalla JVM a seconda del S.O. in uso.
Exokernel
Andando un passo avanti i ricercatori del MIT hanno costruito un sistema che dà ad ogni utente un clone del calcolatore
reale ma con un sottoinsieme delle risorse. A livello più basso, in esecuzione in modalità kernel, c'è un programma
chiamato exokernel, il cui compito è allocare risorse alle macchine virtuali e controllarne i tentativi di utilizzo delle
risorse per essere sicuri che nessuna macchina stia tentando di utilizzare le risorse di un'altra.
Il vantaggio di questo sistema è che risparmia un livello di mapping: negli altri sistemi ogni macchina virtuale pensa di
avere il proprio disco con i blocchi che vanno da 0 a qualche massimo, per cui il monitor della macchina virtuale deve
mantenere delle tabelle per convertire gli indirizzi del disco, mentre con l' exokernel questa conversione non è
necessaria perche deve solo tener traccia di quale macchina è stata assegnata a quale risorsa.
Modello client-server
Il sistema VM/370 guadagna molto in semplicità perche sposta la parte di codice che implementa la macchina estesa ad
un livello più alto, il CMS. Tuttavia il programma VM/370 è ancora un programma complesso perche la simulazione di
molte 370 virtuali non è semplice.
Una tendenza dei moderni S.O. è quella di sviluppare ulteriormente l'idea di spostare il codice verso livelli superiori
lasciando un minimo microkernel.
Si implementano la maggior parte delle funzioni del S.O. attraverso processi utente e per richiedere un servizio, come
la lettura di un blocco di un file un processo utente (detto processo client) spedisce la richiesta ad un processo server
che esegue il servizio e restituisce la risposta.
Il kernel si occupa solo della gestione della comunicazione tra client e server, dividendo il S.O. in parti, ciascuna delle
quali gestisce solo un aspetto del sistema, come ad esempio la gestione dei file, quella dei processi o della memoria,
ogni parte diventa piccola e maneggevole.
Un vantaggio del modello client-server è la sua adattabilità ad essere utilizzato su un sistema di elaboratori collegati in
rete.
http://guidepc.altervista.org