Domenico Cotroneo » 7.Architetture a Microkernel

Sommario della lezione

• Benefici dei Microkernel
• Meccanismi di base
• Esempi di Microkernel
  • Minix 3
  • Mach

Meccanismi e strategie

Quali funzionalità devono essere implementate nel microkernel e quali all’esterno?
Un possibile criterio è definire due componenti del SO per la gestione di ogni risorsa:

• i meccanismi per consentire la gestione;
• le strategie di gestione (realizzate attraverso i meccanismi).

Ad es., per la gestione dei processi possiamo distinguere:

• il cambio di contesto (meccanismo);
• l’algoritmo di scheduling (strategia).

Meccanismi e strategie

L’insieme dei meccanismi costituisce di fatto il microkernel, unico componente a girare in modo privilegiato.

Le strategie sono implementate come processi di sistema, ed eseguono come normali applicazioni.

Facilmente modificabili ed estensibili.

Microkernel vs architettura a livelli

Microkernel vs architettura a livelli

Nelle architetture a livelli molti moduli del SO sono parte integrante del kernel.

Le modifiche apportate ad un livello possono avere serie ripercussioni sui livelli adiacenti.

Il malfunzionamento a runtime di una delle funzionalità di un livello può comportare il crash dell’intero sistema operativo.

Benefici delle architetture a microkernel

Interfacce uniformi: tutte le invocazioni di servizio avvengono mediante un’unica interfaccia: lo scambio di messaggi.

Estensibilità: la modifica o aggiunta di funzionalità richiede la modifica o aggiunta di processi applicativi (i server), non del kernel.

• Ad es., diversi file system per dispositivi esterni possono essere implementati da diversi file server.

Flessibilità: il sistema può essere facilmente adattato a scopi diversi.

• Nuove funzionalità possono essere aggiunte, mentre le funzionalità non necessarie possono essere rimosse.

Benefici delle architetture a microkernel

Portabilità: la maggior parte del codice dipendente dall’hardware è nel microkernel:

• meno cambiamenti necessari in caso di porting.

Affidabilità

• Un piccolo microkernel può essere testato rigorosamente.
• L’uso di poche e ben definite interfacce aumenta le possibilità di produrre codice di buona qualità.
• Il malfunzionamento di un processo di sistema a runtime non pregiudica il funzionamento del sistema operativo.

Supporto all’elaborazione distribuita: il microkernel può astrarre facilmente la rete:

• un client può invocare un servizio senza sapere su quale macchina risiede.

Svantaggi delle architetture a microkernel

Prestazioni: invocare un servizio attraverso lo scambio di messaggi è generalmente più oneroso di una semplice service call in un sistema modulare.

Una possibile soluzione consiste nel reintegrare nel microkernel servizi o driver critici, invocati spesso
(approccio seguito da Windows e parzialmente da Mach)

… al costo di rendere il microkernel più complesso rinunciando ad alcuni dei suoi vantaggi.

Meccanismi di base

Un microkernel deve fornire almeno i seguenti meccanismi di base:

• Context switch;
• Low level memory management;
• Interprocess communication;
• I/O and interrupt management.

Questi meccanismi dipendono direttamente dall’hardware e sono la base per il funzionamento di applicazioni e server.

Low level memory management

Nel microkernel: funzioni base per il mapping tra memoria logica e memoria fisica e per implementare i meccanismi di protezione a livello di processo.

All’esterno: allocazione, condivisione, gestione dello spazio libero, swapping, ecc.

Esempio: Mach External Pager.

Low level memory management

Un possibile set minimo di funzioni per la gestione della memoria offerte dal microkernel:

• Grant: un processo può chiedere di cedere parte del suo spazio a favore di un altro processo;
• Map: un processo può chiedere di condividere parte del suo spazio con un altro processo;
• Flush: un processo può chiedere di recuperare lo spazio ceduto o condiviso in precedenza.

All’inizio, il kernel alloca tutto lo spazio disponibile ad un processo fittizio di sistema (base system process).
Quando un nuovo processo entra in esecuzione, lo spazio viene ceduto (granted) dal processo fittizio al nuovo processo, e recuperato (flushed) alla sua terminazione.

Interprocess Communication

Il meccanismo di base per la comunicazione tra processi in un microkernel è lo scambio di messaggi.

Il microkernel offre le funzionalità base per inviare e ricevere messaggi.

Un messaggio è composto da un header, che identifica i processi mittente e destinazione, e da un corpo, che contiene i dati da trasferire.

Il sistema operativo Minix 3

Sviluppato inizialmente come strumento di supporto alla didattica.

E’ basato su un’architettura a micro-kernel:

• il kernel è formato da appena 4k linee di codice contro 2.5M di sistemi modulari come Linux.

Il kernel contiene solamente:

1. schedulatore dei processi;
2. gestiore degli interrupt;
3. gestore dell’MMU;
4. driver del clock di sistema;
5. strutture per l’IPC.

Tutti gli altri componenti del sistema operativo sono realizzati come processi eseguiti nello spazio utente!

Minix 3: motivazioni

Minix 3 nasce nel tentativo di rendere un sistema operativo altamente affidabile.

Studi recenti hanno evidenziato che il 70% dei fallimenti di un OS sono dovuti a bachi nei drivers forniti da terze parti.

• Es. In Windows XP i drivers sono responsabili dell’85% di tutti i crash di sistema.

Minix3 cerca di ridurre l’occorrenza di questi eventi:

• riducendo il codice del kernel;
• portando i driver nel contesto di processi in spazio utente.

In questo modo un driver malfunzionante, non può danneggiare altri che se stesso!

Struttura di Minix 3

Livello Kernel

La maggior parte del kernel è scritta in linguaggio C.

Tuttavia esiste una piccola parte è scritta in Assembler che gestisce:

• il contex-switch tra processi;
• la manipolazione della MMU.

I livelli superiori sono visti dal kernel come come un unico livello, abilitato ad eseguire solo istruzioni user-mode, senza poter sforare il proprio spazio di indirizzamento.

Ogni livello ha però dei propri privilegi.

Ad esempio la possibilità di poter effettuare delle kernel-calls è destinate principalmente ai processi drivers.

Livello Drivers

I drivers comunicano con i processi di livello superiore attraverso primitive per lo scambio di messaggi (overhead rispetto a drivers integrati nel kernel).

L’aggiunta di una nuovo dispositivo non necessita né la ricompilazione né il riavvio del sistema: basta solo avviare il nuovo processo driver!

Ogni driver è organizzato in modo da presentare una parte dipendente dall’hardware e una parte indipendente.

La parte indipendente dall’hardware è in comune ai dispositivi della stessa natura (es. block devices) ed è incapsulata nei server di sistema (ai livelli superiori).

Es. di I/O driver per Minix

Interrupt handling

Per tutti i device, ad eccezione del clock, viene richiamato lo stesso interrupt handler chiamato generic_handler che provvede a risvegliare i device driver di competenza il cui valore è contenuto nel campo proc_nr_e della struttura hook
Il caricamento di questa struttura viene effettuato dalla procedura put_irq_handler richiamata, su richiesta dei singoli driver, dal system task
Put_irq_handler inserisce nella ISR table i campi:

• tipo del messaggio da inoltrare;
• processo da notificare.

Livello dei Processi Server

I server implementano le system call a livello utente e possono essere invocati tramite scambio di messaggi.
L’invocazione tramite scambio di messaggi è mascherata ai processi utente da comuni chiamate a funzioni, conformi all’interfaccia POSIX.
I server non possono fare operazioni di I/O direttamente, ma devono invocare i driver opportuni.
I server possono anche comunicare con il kernel, attraverso kernel calls servite dal System task.

Esempi di Server

Il Process Manager (PM) implementa le system call per la gestione dei processi (fork, exec, exit, segnali, ecc.).

Il File System (FS) implementa le system call per la gestione dei file (read, write, mount, chdir, ecc.).

L’Information Server (IS) fornisce informazioni di stato circa i driver e server attivi sul sistema.

Il Reincarnation Server (RS) gestisce il ciclo di vita dei driver ed è progettato per rendere il sistema tollerante ai guasti dei driver.

• Se un driver fallisce durante il suo funzionamento, l’RS rileva il fallimento, forza la terminazione del driver (se non già terminato), e avvia una nuova copia del driver.

La struttura di Mac OS X

Darwin e XNU

Darwin è considerato il core di Mac OS X.
E’ costituito da una serie di librerie di utilità e dal kernel XNU.
XNU a sua volta è basato su:

• un microkernel Mach;
• una variante del sistema operativo Berkeley Software Distribution (BSD), in particolare FreeBSD 5.

Mach

Mach è il core di XNU, ed implementa le seguenti funzionalità base:

• astrazione hardware (in parte);
• gestione del processore (scheduling multithreading e SMP);
• gestione della memoria di basso livello;
• meccanismi IPC base (scambio messaggi);
• supporto all’elaborazione real-time;
• supporto allo sviluppo dei driver tramite l’I/O kit.

BSD

XNU contiene una sostanziale quantità di codice derivante da BSD, in parte adattato per permettere l’interazione con il Mach e l’I/O kit.
BSD rende le system call di Mac OS X conformi allo standard POSIX, e quindi compatibili con i SO UNIX, e Linux.
BSD offre i seguenti servizi/funzionalità

• il modello dei processi nello stile UNIX (PCB, PID, ecc.);
• gli user Ids, i permessi e le politiche base della sicurezza;
• le API e le system call POSIX, inclusi i POSIX Threads;
• lo stack TCP/IP, le socket BSD;
• lo strato VFS (Virtual File System) e numerosi file system;
• i meccanismi IPC System V e POSIX.

Processi e thread

I processi BSD sono “mappati” su task Mach.

Il task Mach è l’unità base di allocazione delle risorse.

Ad un task possono essere associati più flussi di esecuzione (thread, di livello kernel).

I thread vivono nel contesto di un task, e rappresentano l’unità fondamentale di schedulazione presa in considerazione dal microkernel.