Architettura dei sistemi Operativi

descrive quali sono le varie componenti del so e come queste sono collegate tra loro

L'architettura dei so da diversi punti di vista

• servizi forniti (visione utente non tanto la persona quanto i programmi)
• interfaccia di sistema (visione programmatore)
• componenti di sistema (visione progettista so)

Componenti di un sistema operativo

 Gestione dei processi  Gestione della memoria principale: ram o mem interna processore  Gestione della memoria secondaria: dischi  Gestione file system: stato che si colloca al disopra della mem secondaria e ci permette di vedere le cose nella mem secondaria  Gestione dei dispositivi di I/O  Supporto multiuser: moduli all'interno del so che creano l'astrazione multiutente (sono info di corredo che vengono aggiunte per creare multiutenti)  Networking  Inter Process Communication (IPC)

Gestione processi

• un processo e' un programma in esecuzione (l'attivita di un programma in esecuzione).
• il sistema operativo e' responsabile delle seguenti attivita'
  • creazione e terminazione dei processi
  • sospensione e riattivazione dei processi
  • gestione deadlock
  • comunicazione tra processi
  • sincronizzazione tra processi

Memoria Principale

• e' un array di byte indirizzabili singolarmente
• ci sono istruzioni per accedere a un singolo byte o di piu fino al (non ho capito) es. un processore da x64 puo accedere a 1-16-64 byte in blocchi
• è un deposito di dati facilmente accessibile alla CPU (econdiviso con i controller dei dispositivi di I/O se DMA)

il sistema operativo e' responsabile delle seguenti attivita:

• tenere traccia di quali parti della mem sono usate da chi
• decidere quali processi caricare quando diventa disponibile spazio in mem
• allocare e deallocare lo spazio di memoria quando necessario
• usare mem secondaria per ampliare la mem principale (vitual memory, swap) se una pagina non viene usata da un po viene messa in mem secondaria

Memoria Secondaria

Poiché la memoria principale è volatile e troppo piccola per contenere tutti i dati e tutti i programmi in modo permanente, un computer è dotato di memoria secondaria  In generale, la memoria secondaria è data da hard disk, dischi ottici, dischi allo stato solido, etc. Si accede a blocchi (nella mem primaria si accede a byte)

Il sistema operativo e' responsabile delle seguenti attivita riguardanti la gestione della memoria secondaria:

• gestione partizionamento
• gestione dell'accesso efficiente e affidabile (RAID) Nota: raid viene usato per velocita'. Si usa per sparpagliare i dati su vari dischi cosi da ridurre il tempo di ritardo medio delle richieste. Facendo raid semplice si va piu veloci come performance ma si ottiene un sistema piu fragile i dischi si rompono prima
• ordinamento efficiente delle richieste (disk scheduling)

Gestione dell'I/O

Un interfaccia per la gestione dei device driver Un insieme di driver per dispositivi hw specifici Un sistema di gestione buffer per il caching delle informazioni

Per ogni op di io un dirver va in funzione due volte (alla fine dell'op di io quando deve essere inviato l'interrrupt e per la richiesta )

Gestione del file system

Un file e' l'astrazione informatica di un archivio di dati (il concetto di file e' indipendente dal media sul quale viene memorizzato) Un file system e' composto da un insieme di file un fs e' anche quello contenuto in una chiavetta (quando si fa mount viene visto il file system della chiavetta) Il sistema operativo e' responsabile delle seguenti attivita':

• creazione e cancellazione file
• creazione e cancellazione di directory
• manipolazione di file e directory
• codifica dei file system su una sequenza di blocchi

Supporto multiuser - protezione

Il termine protezione si riferisce al meccanismo per controllare gli accessi dei processi alle risorse del sistema e degli utenti Il meccanismo di protezione sw deve:

• gestire l'identita' del proprietario del processo (uid gid)
• gestire chi può fare cosa (per ogni utente per ogni risorsa memorizzare cosa puo’ essere fatto e cosa no)
• Fornire un meccanismo di attuazione della protezione

Networking

• consente
  • di fare comunicare processi in esecuzione su piu elaboratori
  • di condividere risorse
• quali servizi
  • protocolli di comunicazione a basso livello
  • ip
  • tcp,udp
• servizi di comunicazione ad alto livello
  • file system distribuiti (nfs,smb)

Architettura dei sistemi operativi - struttura del programma sistema operativo

Sommario

 Sistemi con struttura semplice  Sistemi con struttura a strati  Microkernel  Macchine virtuali  Progettazione di un sistema operativo

Ora vediamo come le componenti del so sono collegate tra loro

progettazione di un so: sistemi molto efficienti sono poco modulari  sistemi molto modulari sono meno efficienti

Struttura dei so

Divisi in due grandi famiglie

• struttra semplice
• struttura a strati

Sistemi a struttura semplice (o senza struttura)

• in alcuni casi sono so che non hanno struttura progettata a priori
• possono essere descritti come una collezione di procedure, ognuna delle quali puo chiamaer altre procedure
• tipicamente sono so semplici e limitati

MS-DOS Free-DOS

MS-DOS

• Commenti  le interfacce e i livelli di funzionalità non sono ben separati  le applicazioni possono accedere direttamente alle routine di base per fare I/O  come conseguenza, un programma sbagliato (o "maligno") può mandare in crash l'intero sistema
• Motivazioni:  i progettisti di MS-DOS erano legati all'hardware dell'epoca  8086, 8088, 80286 non avevano la modalità protetta (kernel)

nessun controllo di accessi in memoria (l'uso piu comune sel tsr era quello di inserire dei virus, lol) I giochi cercavano di bypassare il so e accedere direttamente alle risorse (es gpu) Un errore del programma (visto che non cerano controllo di accessi in memoria) poteva causare il crash del sistema

UNIX Le prime versioni facevano un po cagare diviso in due parti (kernel e programmi di sistema) Il kernel e' delimitato:

• in basso dall'hw
• in alto dal livello delle system call

Motivazioni

• anche Unix inizialmente fu limitato dalle limitazioni hardware…
• … ma ha un approccio comunque più strutturato

Sistemi con struttura dati a strati

Il so e' strutturato tramite un insieme di strati (layer)

Ogni strato: e' basato sugli strati inferiori offre servizi agli strati superiori

Motivazioni: il vantaggio principale e'la modularita:

• encapsulation e data hiding
• abstract data types Vengono semplificate le frasi di implementazione, debugging e ristrutturazione del sistema

Esempi:

The O.S. (Dijkstra) 5) Programmi utente 4) Gestione I/O 3) Console device/driver 2) Memory management

1. CPU Scheduling
2. Hardware

Venus os 6) Programmi utente 5) Device driver e scheduler 4) Memoria virtuale 3) Canali di I/O 2) CPU Scheduling

1. Interprete di istruzioni
2. Hardware

Problema dei sistemi con struttura a strati

• tendono a essere meno efficienti (ogni stato tende ad aggiungere overhead)
• occorre studiare accuratamente la struttura dei layer
  • le funzionalita previste al layer N devono essere implementate utilizzando esclusivamente i servizi dei livelli inferiori
• in alcuni casi questa limitazione puo essere difficile da superare
• esempio: meccanismi di swapping di memoria
  • Win: swap area è un file in memoria
  • Linux: swap area ha una partizione dedicata

risultato: si tende a trovare un compromesso tra i due mondi

OS/2 Nota: scrivi due righe su window subsystem for linux Computer HW/SW architecture (Myers) Grafico di myers ISA e'il codice macchina per fare le op macchina (instruction set architucture) Alla fine l'hw e' linguaggio

politiche e meccanismi

Separazione della politica dai meccanismi

• la politica decide cosa deve essere fatto
• i meccanismi attuano la decisione

E un concetto fondamentale di software engineering

• la componente che prende le decisioni politiche puo essere completamente diversa da quella che implementa i meccanismi
• rende possibile
  • cambiare la politica senza cambiare i meccanismi
  • cambiare i meccanismi senza cambiare la politica

Nei sistemi a microkernel (si chiamano cosi perche cercano di fare fare meno cose al kernel) si implememntano nei kernel

Esempio: MINIX

• il gestore della memoria è un processo esterno al kernel decide la memoria da allocare ai processi ma non accede direttamente alla memoria del sistema può accedere però alla propria memoria (è un processo come tutti gli altri)
• quando deve attuare delle operazioni per implementare la politica decisa lo fa tramite chiamate specifiche al kernel (system task)

Controesempio: MacOS <=9 (non Mac OS X)

• in questo sistema operativo, politica e meccanismi di gestione dell'interfaccia grafica sono stati inseriti nel kernel
• svantaggi: - un bug nell'interfaccia grafica puo mandare in crash lintero sistema Windows 9x non e'differente

Organizzazione del kernel

Esistno 3 categorie principali di kernel

Kernel Monolitici

• Un aggregato unico (e ricco) di procedure di gestione mutuamente coordinate e astrazioni dell’HW

Micro Kernel

• Semplici astrazioni dell’HW gestite e coordinate da un kernel minimale, basate un paradigma client/server, e primitive di message passing

Kernel Ibridi

• Simili a Micro Kernel, ma hanno componenti eseguite in kernel space per questioni di maggiore efficienza

(+ ExoKernel, AnyKernel)

Organizzazione del kernel

Kernel Monolitici

• Un insieme completo e unico di procedure mutuamente correlate e coordinate System calls Implementano servizi forniti dal kernel, tipicamente realizzati in moduli eseguiti in kernel mode

Esiste modularità, anche se l’integrazione del codice, e il fatto che tutti i moduli sono eseguiti nello stesso spazio, è tale da rendere tutto l’insieme un corpo unico in esecuzione

Organizzazione del kernel

Kernel Monolitici:

Efficienza

• L’alto grado di coordinamento e integrazione delle routine permette di raggiungere ottimi livelli di efficienza

Modularità

• I più recenti kernel monolitici (Es. LINUX) permettono di effettuare il caricamento (load) di moduli eseguibili a runtime
• Possibile estendere le potenzialità del kernel, solo su richiesta
• Esempi di Kernel monolitici: LINUX, FreeBSD UNIX

Microkernel o sistemi client/server

problema: i kernel continuano a crescere in complessita idea: rimuover dal kernel tutte le parti non essenziali e implementarle come processo a livello utente Esempio: per accedere a un file un processo interagisce con il processo gestore del file system Un kernel perfetto avrebbe solo 2 system calls (send e recieve) Es: AIX, BeOS, L4, Mach, Minix, MorphOS, QNX, RadiOS, VSTa cosa si perde? efficienza (tante richieste)

Quali funzionalità deve offrire un microkernel?

• funzionalità minime di gestione dei processi e della memoria
• meccanismi di comunicazione per permettere ai processi clienti di chiedere servizi ai processi serventi

La comunicazione è basata su message passing il microkernel si occupa di smistare i messaggi fra i vari processi

Quelli di gnu volevano fare un microkernel, avevano fatto tutto il sistema ma mancava il kernel. Linus riusci per opportunita e tempo a batterli

System call di un s.o. basato su microkernel Tramite queste due system call, è possibile implementare l'API standard di gran parte dei sistemi operativi

int open(char* file, ...)
{
msg = < OPEN, file, ... >;
send(msg, file-server);
fd = receive(file-server);
return fd;
}

Vantaggi

• il kernel risultante è molto semplice e facile da realizzare
• il kernel è più espandibile e modificabile
  • per aggiungere un servizio: si aggiunge un processo a livello utente, senza dover ricompilare il kernel
  • per modificare un servizio: si riscrive solo il codice del servizio stesso
• il s.o. è più robusto
  • se per esempio il processo che si occupa di un servizio cade, il resto del sistema può continuare ad eseguire
• sicurezza
  • è possibile assegnare al microkernel e ai processi di sistema livelli di sicurezza diversi
• adattabilità del modello ai sistemi distribuiti
  • la comunicazione può avvenire tra processi nello stesso sistema o tra macchine differenti

Minix: Il kernel è dato dal gestore dei processi e dai task i task sono thread del kernel

Confronto tra kernel monolitici e microkernel

• Monolitico
  • Considerato obsoleto nel 1990…
  • È meno complesso gestire il codice di controllo in un’unica area di indirizzamento (kernel space)
  • È più semplice realizzare la sua progettazione (corretta)
• Micro Kernel
  • Più usato in contesti dove non si ammettono failure
  • Es. QNX usato per braccio robot Space shuttle
  • N.B. Flamewar tra L. Torwalds e A. Tanembaum riguardo alla soluzione migliore tra Monolitico e Micro Kernel https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate

Kernel Ibridi

Kernel Ibridi (Micro kernel modificati)

• Si tratta di micro kernel che mantengono una parte di codice in “kernel space” per ragioni di maggiore efficienza di esecuzione
• …e adottano message passing tra i moduli in user space N.B.
• i kernel Ibridi non sono da confondere con Kernel monolitici in grado di effettuare il caricamento (load) di moduli dopo la fase di boot.

Windows NT e derivati

Windows NT è dotato di diverse API

• Win32, OS/2, Posix Le funzionalità delle diverse API sono implementate tramite processi server

ExoKernel (kernel di sistemi operativi a struttura verticale)

Approccio radicalmente modificato per implementare O.S. Motivazioni

• Il progettista dell’applicazione ha tutti gli elementi di controllo per decisioni riguardo alle prestazioni dell’HW
• Dispone di Libreria di interfacce connesse all’ExoKernel
• Es. User vuole allocare area di memoria X o settore disco Y

Limiti

• Tipicamente non vanno oltre l’implementazione dei servizi di protezione e multiplazione delle risorse
• Non forniscono astrazione concreta del sistema HW

AnyKernel

Driver in user space

• I driver possono essere caricati in user space
• Rapido/sicuro sviluppo di driver
• Il concetto può essere esteso a file system e stack di rete

Macchine virtuali

E' un approccio diverso al multitasking

• invece di creare l'illusione di molteplici processi che posseggono la propria CPU e la propria mememoria…
• si crea l'astrazione di un macchina virtuale
  Le macchine virtuali
• emulano il funzionamento dell'hardware
• è possibile eseguire qualsiasi sistema operativo sopra di esse

Vantaggi:

• consentono di far coesistere so differenti
• possono fare funzionare so monotask in un sistema multitask e sicuro (es. linux in macos o windows e viceversa)

Svantaggi:

• soluzioni inefficienti
• istruzioni hw di virtualizzazione (istruzioni VMX)
• difficile condividere risorse

es. storici IBM VM, la macchina virtuale java o python