Un Kernel tradizionale è solitamente monolitico. Ciò significa che
annuncio pubblicitario
Un Kernel tradizionale è solitamente monolitico. Ciò significa che contiene lo scheduler, la gestione della memoria virtuale, i gestori di file system, i driver necessari per il controllo di tutte le periferiche collegate. Questo tipo di Kernel è decisamente più complesso da progettare, da manutenere, da aggiornare, ma è anche più veloce, più efficiente. La sua evoluzione è costituita dai Kernel "modulari" (Onion Skin), che pur mantenendo una loro unica organicità, tengono separati al loro interno i servizi di scheduling, della gestione della memoria virtuale e del file system. Il micro Kernel invece porta avanti una filosofia completamente diversa, privilegiando l’idea che più è leggero e minimale il Kernel che guarda alla macchina fisica e più portabile sarà il sistema operativo e minore il costo della manutenzione e con aggiornamenti meno invasivi. La filosofia del micro Kernel ebbe il suo apice negli anni ’90, e vide in prima fila Tanenbaum, un docente universitario olandese di Amsterdam. Tanenbaum e Torvalds hanno lavorato entrambi sulla base della impostazione del sistema Unix, ma con finalità ed esiti diversi. Il primo ha creato Minix,, un sistema operativo a micro Kernel gratuito, scritto a scopo didattico, che permetteva agli studenti universitari del professore di studiare un Kernel simile a Unix. In Minix la teoria del micro Kernel è fedelmente implementata e la gestione della memoria e il file system, ed altro ancora, sono moduli di sistema operativo che vengono eseguiti addirittura nello spazio utente e non nello spazio Kernel. Ciò significa che Tanenbaum ha veramente minimizzato il micro Kernel rendendolo estremamente leggero, affidabile, con la possibilità di svolgere su di esso un’efficacissima e semplice manutenzione. Non solo: un micro Kernel si avvia in pochi secondi con hardware meno performante di altri sistemi monolitici più pesanti e complessi che necessitano di molto più tempo per essere caricati. La sua diffusione è stata limitata, senz’altro, perché ogni modifica o miglioria doveva, per la licenza contrattuale pensata per la sua diffusione, essere sottoposta all’approvazione di Tanenbaum. Torvalds invece non ha scritto un micro Kernel, bensì un Kernel monolitico ispirato a Unix e, probabilmente, a Minix. La licenza era però totalmente libera e ciò ha scatenato energie infinitamente maggiori attorno al suo progetto. Ricapitolando possiamo concludere che i processori possono operare in due modalità: modo Utente modo Kernel Nel modo Utente il processore si trova ad operare in un mondo virtuale dove le risorse non sono più quelle fisiche vere, ma quelle create dal Kernel per l’Utente. Non si accorge degli altri programmi concorrenti e vede risorse maggiori di quelle reali (ad esempio la memoria centrale). Nel modo Kernel il processore vede ed esegue procedure nel mondo vero della macchina fisica. Creare quindi dei Kernel monolitici significa scrivere gran parte del codice del sistema operativo che verrà eseguito in modo Kernel. Creare dei micro Kernel significa invece ridurre al minimo il codice del sistema operativo che verrà eseguito in modo Kernel e spostare verso il modo Utente buona parte del restante sistema da realizzare. Come esempio possiamo immaginare il codice che gestisce i files: il file system. Esso è composto da varie funzionalità: quelle legate al dispositivo hardware e che consentono semplicemente di leggere e scrivere sul disco, quelle che trattano l’organizzazione dei dati sul disco e quindi di dove possono essere rintracciate o archiviate le informazioni, quelle che gestiscono i dati e i files che devono essere conservati nel disco. Nel Kernel Linux si ritrovano tutte le funzionalità sopra indicate. Linux quindi si fa carico di gestire con il Kernel sia la parte di interazione elettronica con il disco, che la sua organizzazione fisica e logica. In Linux troviamo: driver del dispositivo fisico driver (modulo) del formato del filesystem (ext2, ext3, fat, etc.) livello astratto del filesystem, uguale per ogni formato Nel caso di un micro Kernel invece vi troveremmo solo il primo driver mentre le altre due parti della gestione del file system sarebbero affidate a programmi da svolgersi nello spazio utente. Ciò permetterebbe di “personalizzare” una parte del funzionamento tipico di un Sistema Operativo per classi di utenti poiché il vero e proprio Kernel del Sistema sarebbe ridotto al minimo. Questo approfondimento si conclude con altre due considerazioni. Nonostante i vantaggi potenziali dell’architettura a micro Kernel (gestione più flessibile del sistema e manutenzione ridotta), questa è rimasta disattesa nelle soluzioni commerciali. Infatti Linux è monolitico e pure NT, il vero e proprio nuovo sistema di Microsoft che ha soppiantato il DOS, partito con l’intento di perseguire la linea del micro Kernel, è di fatto un monolitico perché tutti i moduli che stanno sopra il micro Kernel di NT, girando in modalità Kernel, di fatto, sono parte integrante del Kernel stesso. Nei due modelli a confronto quello arancione è l’insieme dei processi che verrà eseguito in modalità Kernel e quindi non in modalità utente. Come si vede a destra molte funzioni del Kernel monolitico sono poste a livello utente sebbene siano parte integrante del sistema operativo. Applicazioni utente 1 IPC , File System Schedulatore, Memoria Virtuale Device Drivers, Dispatcher 1 2 Applicazioni Utente File System Device Drivers Unix Server Basic IPC, Schedulatore, Memoria Virtuale Hardware Hardware KERNEL MONOLITICO Micro KERNEL Inter Process Communication (Comunicazione tra processi) è il modulo che permette la comunicazione e lo scambio di dati tra processi. 2 Modulo del Sistema Operativo che effettua realizza effettivamente il passaggio del Processore da un processo ad un altro su segnalazione dello schedulatore. Per questo motivo il dispatcher deve essere il più rapido possibile.
