Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Domenico Cotroneo » 7.Architetture a Microkernel


Sommario della lezione

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

Microkernel

“A microkernel is a small OS core that provides the foundation for modular extension”.
Termine generico per indicare una filosofia di progettazione dei sistemi operativi secondo cui:

  • solo le funzioni di SO assolutamente essenziali devono risiedere nel kernel;
  • i servizi meno essenziali risiedono all’esterno del kernel ed eseguono in modalità utente.

Approccio reso popolare dal suo uso nel Mach OS, sviluppato negli anni ‘80 alla Carnegie Mellon University, USA, e che rappresenta oggi il cuore del Mac OS X.


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:

  • 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: un’architettura client-server

I processi di sistema sono spesso indicati come server.

Altri processi (client) accedono ai servizi offerti dai server attraverso i meccanismi di inter-process communication (IPC) del microkernel, basati sullo scambio di messaggi.


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.

I/O and Interrupt Management

Il microkernel intercetta le interruzioni, ma non le gestisce direttamente…

  • Alla ricezione di un interrupt, il kernel genera un messaggio e lo invia al processo correntemente associato con l’interrupt.

I driver possono essere implementati come processi esterni che attendono messaggi dalle periferiche e colloquiano attraverso I/O memory mapped.

Driver:
do {

 waitFor(msg, sender)

if (sender = my_int) {

read/write I/O;
reset interrupt;

}
else . . . ;

} while (true);


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: il Clock task

Il kernel schedula i processi e gestisce le transizioni tra gli stati di funzionamento (new, ready, blocked…)

Contiene due moduli: Clock task e System task.
Il Clock task è un particolare driver di I/O che interagisce con l’hardware che genera i segnali di tempificazione.

Non è accessibile dal livello utente, è può essere usato solo dal kernel.
E’ il kernel che notifica ai processi interessati lo scadere di un timer.


Livello Kernel: il System task

Una delle funzioni principali del kernel di Minix3 è quella di fornire un insieme di kernel calls per i drivers nello spazio utente.

Le kernel calls (diverse dalle system calls) permettono ai processi drivers eseguiti nello spazio utente di accedere ad istruzioni privilegiate, come ad es. la lettura e la scrittura su porte di I/O, la copia di dati tra spazi di indirizzamento…ecc.

Queste chiamate sono implementate dal System Task.

System task e Clock task vengono schedulati come due processi distinti, anche se condividono lo stesso spazio di indirizzamento.


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 sono incapsulati da processi eseguiti in user-mode.
L’unico driver che eseguito in kernel mode è il driver del clock di sistema.
In questo modo ogni driver può accedere solo al proprio spazio di indirizzamento grazie alla MMU.
I drivers accedono all’hardware attraverso le kernel calls.

  • Es. Lettura di un array di porti di I/O.
  • Accesso ai registri di un dispositivo.

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).

Driver e Server

  1. Un processo che vuole leggere un file manda un messaggio al server del File system (FS).
  2. FS, che svolge il ruolo di device-independent code, invia la richiesta al driver .
  3. Il Driver inoltra la richiesta al system task, via kernel call.
  4. Il kernel avvia l’operazione e trasferisce i dati tra i processi.

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.

Scheduling dei processi in Minix

Round robin su 16 code a priorità differenti.

Quando un processo viene bloccato senza aver esaurito il suo quanto di tempo, una volta risvegliato, viene rimesso in testa alla coda.
Nelle code sono presenti solo processi ready.
Le code da 0 a 4 sono destinate ai system task.
Algoritmo di scheduling:

  • individua la coda di priorità più alta non vuota e manda in esecuzione il processo in testa alla coda;
  • il processo IDLE garantisce “la terminazione” di questo algoritmo.

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.

I materiali di supporto della lezione

Stallings, “Operating Systems” 6th ed., par. 4.3

Tanembaum “Operating Systems” 3rd ed., par. 2.5.1

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion