Domenico Cotroneo » 3.Architettura di un SO

Sommario

• Funzionalità di un SO
• Architetture dei SO

Funzionalità di un SO

Virtualizzazione risorse hardware (fornitore di servizi)

• file system;
• gestione devices etc…

Gestione e Coordinamento

• meccanismi di protezione;
• meccanismi per la comunicazione;
• gestore risorse.

SO come macchina virtuale

Kernel

E’ quella parte del SO che risiede in memoria principale.
Contiene le funzioni più utilizzate del SO.
Chiamato anche nucleo.

Kernel

Al livello kernel (nucleo) la macchina virtuale realizzata dal SO:

• possiede tante unità centrali quanti sono i processi (processori virtuali);
• non possiede meccanismi di interruzione;
• possiede istruzioni di sincronizzazione e scambio di messaggi tra processi che operano sui processori virtuali.

Livello gestione della memoria

Al livello gestione della memoria la macchina virtuale realizzata dal SO:

• consente di far riferimento a spazi di indirizzi virtuali;
• garantisce la protezione;
• consente in taluni casi di ignorare se il programma e/o i dati siano fisicamente residenti in memoria centrale o su memoria di massa (disco).

Livello gestione periferiche

Al livello gestione periferiche la macchina virtuale realizzata dal SO:

• dispone di periferiche dedicate ai singoli processi;
• maschera le caratteristiche fisiche delle periferiche;
• gestisce parzialmente i malfunzionamenti delle periferiche.

Livello file system

Al livello file system la macchina virtuale realizzata dal S.O.

• gestisce blocchi di informazioni su memoria di massa strutturati logicamente;
• ne controlla gli accessi;
• ne gestisce l’organizzazione.

….due domande

Come è invocato un Sistema Operativo (qual è il flusso di controllo)?

Qual è l’architettura di un Sistema Operativo?

Elementi Fondamentali di un SO

Sistemi Operativi Interrupt-Driven

I sistemi operativi sono guidati dalle interruzioni (sincrone ed asincrone).
Gran parte del nucleo viene eseguito come interrupt handler.
Gli interrupt (sia hardware che software) guidano l’avvicendamento dei processi.

System Call (richiesta di servizio)

Qualunque richiesta di un servizio di sistema (ad es. l’apertura di un file, la lettura dati da un file, la comunicazione con un altro processo ecc…) deve essere inoltrata attraverso una system call.

La funzione di una system call, perciò, consiste nel soddisfare le richieste di un determinato servizio di sistema o di acquisizione di una certa risorsa.

Categorie di System Call

• Controllo di processo.
  • Es. load, execute, allocate mem, free mem
• Manipolazione dei file.
  • Es. create, delete, open, close, read
• Gestione dei dispositivi.
  • Es. request device, read, write
• Gestione delle informazioni.
  • Es. get time, set time
• Comunicazione.
  • Es. create communication connection, send, receive

System Call (esecuzione)

L’esecuzione di una system call, da parte di un processo-utente, corrisponde all’attivazione di una parte del Kernel a favore dello stesso processo, per espletare il servizio o per acquisire la risorsa richiesta.
Quando il kernel, o parte di esso, viene eseguito a favore di un processo ai fini dell’acquisizione di una risorsa, si dice che tale processo viene eseguito in kernel mode.
Una volta acquisita la risorsa dal kernel, il processo-utente ritorna nello stato user mode.
La transizione dallo stato user mode a quello di kernel mode viene effettuata mediante la chiamata di una delle system call; mentre la transizione inversa avviene all’atto della chiamata di return della system call stessa.

System Call

Tipicamente le librerie run time dei linguaggi di programmazione rendono disponibili apposite routine di interfaccia che trasformano una tradizionale chiamata di procedura in una SVC, con scambio dei parametri tramite registri del processore e/o specifiche aree di memoria.
Ad esempio il linguaggio C e il C++ consentono di eseguire direttamente da programma le chiamate di sistema, usando delle apposite funzioni di libreria.
Microsoft Windows rende disponibili le S.C. tramite l’API Win32 (application programmer interface).

SO in esecuzione …

La CPU carica il “boot program” dalla ROM (ad es. dal BIOS¹ di un PC).
Boot program:

• esamina/Controlla la configurazione del calcolatore (# di CPU, quantità di memoria, numero e tipologia di dispositivi hardware etc.);
• costruisce un struttura dati che descrive la configurazione hardware del sistema;
• carica il nucleo del Sistema Operativo (kernel) , fornendogli la configurazione creata al punto b.

¹ E’ un software indispensabile per il boot del PC. Acronimo di “Basic Input/Output System”, il bios è un software built-in che contiene un insieme di minimale di procedure, tra cui un caricatore, driver della tastiera, del video, del disco e una serie di handler di periferiche contenute nella piastra madre. Tipicamente Il BIOS è contenuto in una ROM montata sulla piastra madre.
Siccome la RAM è più veloce della ROM, molti produttori sviluppano sistemi nei quali il BIOS è copiato da ROM a RAM ogni volta che il computer è riavviato. Questa tecnica è nota come “shadowing”. Molti PC moderni dispongono di un BIOS su memorie flash, il che significa che il BIOS può essere modificato e configurato, se necessario.

SO in esecuzione …

Inizializzazione del SO:

• inizializ. della struttura dati del kernel;
• inizializzazione dei dispositivi hardware;
• creazione di un certo numero di processi, fondamentali per l’utilizzo stesso del SO (ad es. getty in UNIX, Windowing system in NT).

Dopo che i processi di base sono stati creati,il SO può eseguire dei programmi utente, se disponibili,altrimenti il SO esegue il cosiddetto “idle loop“.

SO in esecuzione …

idle loop:

• il SO esegue un ciclo infinito (UNIX);
• il SO esegue alcune operazioni di background per la gestione del sistema stesso (profiling, log rotating etc…);
• il SO può sospendere il processore e configurare lo stato del sistema in “low-power mode” (notebooks).

Il SO si “sveglia” a seguito di :

• Interruzioni da dispositivi hardware;
• Eccezioni generate da programmi utente;
• “System calls” invocate da programmi utente.

Due modi di esecuzione:

• user mode: Modo di esecuzione ristretto (applications);
• supervisor mode: Accesso non ristretto ad ogni risorsa (OS).

SO in esecuzione

Interrupts

I disp. Hardware invocano il SO ad un predefinita locazione.
IL SO salva lo stato del programma utente.
Il SO identifica il dispositivo che ha causato l’interrupt.
IL SO esegue la routine associata all’interrupt.
Il SO recupera lo stato del programma utente (se possibile) oppure assegna la CPU ad un altro.
IL SO esegue l’istruzione RTI per restituire il controllo al programma utente.
Il programma utente continua la sua esecuzione esattamente dallo stesso punto in cui era stato sospeso.
Punto chiave: Nessuna di queste operazioni è “visibile” al programma utente.

Exceptions

Anche in questo caso la risorsa che ha provocato un’eccezione invoca il SO ad una locazione predefinita;
Il SO identifica la causa dell’eccezione (ad es., “divide by 0″).
Se il programma utente ha specificato un “exception handler”, allora il SO configura il programma utente in modo che possa chiamare il suo handler.
IL SO esegue l’istruzione RTI per restituire il controllo al programma utente.
Se il programma utente non ha specificato un handler, allora il SO “uccide” il processo e affida il controllo della CPU ad un altro programma utente, se disponibile.
Punto chiave: gli effetti delle eccezioni sono visibili al programma utente e causano un’alterazione del flusso di controllo.

System Calls

Il programma utente esegue un istruzione di trap (system call).
L’effetto di questa istruzione è quello di invocare il SO ad un predeterminata locazione (trap handler).
Il SO identifica il servizio richiesto e i parametri (ad es. open(filename, O_RDONLY)).
Il SO esegue il servizio richiesto.
Il SO configura un registro atto a contenere i risultati del servizio.
Il SO esegue un RTI per restituire il controllo al programma utente.
Il programma utente riceve i risultati e continua la sua elaborazione.
Punto Chiave: al programma utente, la system call appare come un normale funzione di libreria che può essere eseguito sotto il suo controllo.

Architettura dei Sistemi Operativi

Il SO è un programma di notevole complessità e dimensione.
E’ quindi fondamentale applicare durante il suo progetto e realizzazione le più sofisticate tecniche proprie dell’ingegneria del software, al fine di garantire:

• correttezza;
• modularità;
• facilità di manutenzione;
• efficienza di esecuzione;
• ecc.

Architetture monolitiche

I primi sistemi operativi erano costituiti da un unico programma, senza particolari suddivisioni.
Il SO era costituito da un insieme di procedure di servizio, solitamente scritte in assembler, a ciascuna delle quali corrispondeva una system call.
Approccio adeguato per sistemi semplici e non multiprogrammati, come MS-DOS.
Approccio inadeguato al crescere della complessità dei sistemi multiprogrammati.

• L’ IBM OS-360, SO batch multiprogrammato costituito da oltre un milione di istruzioni macchina, ha continuato a produrre errori per molto tempo durante tutto l’arco della sua vita.

Architetture modulari

Sistemi operativi realizzati secondo le tecniche della programmazione strutturata.
Il SO è organizzato in moduli, ognuno destinato ad offrire una delle funzionalità del sistema, e caratterizzato da:

• interfaccia: specifica le funzionalità offerte e il modo in cui utilizzarle;
• corpo: contiene l’implementazione del modulo.

Ogni modifica all’implementazione, che mantiene inalterata la sua interfaccia, non ha influenza sul resto del sistema.

Esempi di architetture modulari:UNIX

Esempi di architetture modulari:Linux

Strutturato come una collezione di moduli caricabili che possono essere collegati o scollegati dal kernel a runtime

Componenti del kernel Linux

Architetture a microkernel

I gestori delle risorse sono particolari processi di sistema, spesso indicati come server (file server, terminal server, printer server, …).
Quando un processo applicativo (client) deve usare una risorsa, deve interagire con un server attraverso i meccanismi di comunicazione forniti dal microkernel.

Vantaggi: maggiore modularità, portabilità, estensibilità.
Svantaggi: perdita di efficienza legata alle frequenti comunicazioni inter-processo.

Esempi: Mac OS, MINIX 3, Windows (microkernel ibrido).

Windows Vista Architecture

Struttura modulare per renderlo più flessibile.
Basata su un’architettura a microkernel ibrida:

• non è puramente un’architettura a microkernel;
• …anche se la maggior parte delle funzionalità sono eseguite all’esterno del microkernel;
• tutti i moduli esterni sono caricati dinamicamente e quindi possono essere rimossi, aggiornati, o sostituiti senza riscrivere (o ricompilare) tutto il sistema.