Dentro Debian Hurd
di Jerry Epplin
traduzione Giuseppe Sacco

Articolo pubblicato su Dr. Dobb's Journal dicembre 2000.

Dr. Dobb's Journal, Copyright © 2000, ha cortesemente autorizzato la pubblicazione della traduzione su diff  di quest'articolo disponibile in versione originale in lingua inglese.

Jerry Epplin sviluppa software per sistemi embedded, principalmente legati all'ambiente della medicina. Può essere contattato a jerryepplin@computer.org.

L'architettura modulare di Hurd facilita le personalizzazioni

Su Dr. Dobb's TechNetCast: Intervista al designer e architetto dello GNU Hurd project Thomas Bushnell.

Negli ultimi anni, Linux è passato dall'essere uno dei più oscuri sistemi operativi all'argomento più discusso nel mondo informatico in materia di sviluppo del software.
Adesso puoi vedere Linus Torvalds in TV, Red Hat Linux nel negozio di software sotto casa, articoli della stampa non specializzata riguardo la sfida che Linux sferra a Microsoft.
Allo stesso tempo sviluppatori software sono stati per molto tempo interessati a Linux, anche se principalmente lo sono stati per la sua apertura.
Il sistema operativo e molti tra gli applicativi che vi girano, sono aperti a chiunque voglia vederli, studiarli o modificarli.
La sua apertura è una manna per chiunque abbia bisogno o voglia studiare come è fatto dentro un sistema operativo vero.
Quando, anni fa, studiai i sistemi operativi, era solo un discorso puramente teorico, con attività pratiche limitate a piccoli progetti che implementavano versioni giocattolo di alcune caratteristiche dei sistemi operativi.
Grazie alla disponibilità di Linux (e di altri sistemi operativi liberi come FreeeBSD), gli studenti di oggi possono mettere le mani e modificare sistemi operativi popolari.
Se questi progetti sono ben fatti e soddisfano esigenze vere, possono essere poi inclusi nel sistema stesso e distribuiti a milioni di utenti. Questo è sicuramente un grosso incentivo per chi studia come sia fatto dentro un sistema operativo.

Nonostante tutti i suoi pregi di sistema operativo aperto, Linux -- o meglio il kernel Linux -- pone molti ostacoli a chi voglia modificarlo.
La prima nota che gli si fa riguarda la sua stazza, esso consiste infatti in migliaia di file di codice sorgente.
La quantità di funzionalità incluse nel kernel Linux è impressionante ma scoraggiante, da scheduling e gestione della memoria alla gestione della rete ad alto livello tutto incluso nel kernel.
Inoltre lo sviluppo del kernel è dominato da un'etica hacker che ha mantenuto tutta la documentazione all'esterno; gli stessi commenti nel codice sono visti con sospetto.
In questo ambiente, la velocità delle modifiche è prioritaria, mentre la comprensibilità per chi si voglia avvicinare è di minore importanza. I gestori del kernel stanno forse cercando di mantenere i sorgenti organizzati in una struttura razionale, ma la comprensione del kernel continua a scoraggiare chiunque non si sia dedicato a questa attività per parecchio tempo.

Per questa ragione il kernel Linux può essere considerato di vecchia concezione.
Esso è quello che si dice un kernel "monolitico"; vale a dire uno nel quale quasi tutte le funzionalità del sistema operativo siano incluse nel kernel stesso.
Quando una nuova funzionalità sia richiesta -- ad esempio, il supporto di un nuovo protocollo di rete -- non esiste alcun punto di appoggio per aggiungerla all'esterno del kernel, quindi la si deve inserire all'interno.
Le motivazioni per l'uso di questo modello sono storiche. Lo scopo originale di Linus Torvald era ambizioso per l'hardware disponibile all'epoca -- egli voleva implementare uno UNIX completo sull'hardware disponibile ai tempi del '386.
Questo scopo poteva essere raggiunto solo spremendo ogni possibile ciclo di clock del processore. Un kernel monolitico permette una comunicazione efficace tra le varie parti del sistema (perché sono tutte compilate assieme) ed è manutenibile se il numero di funzionalità rimane modesto. Man mano che si aggiungono funzionalità, la manutenibilità ne soffre.

Architetture Microkernel

Uno dei possibili approcci per gestire la complessità di un OS, è quello di basarsi su una architettura "microkernel", della quale lo Hurd è un valido esempio.
Anche se inizialmente era un progetto della Free Software Foundation, ormai lo Hurd ha catturato l'attenzione di parecchi altri gruppi.
(Lo Hurd è sempre chiamato "lo Hurd" e non semplicemente "Hurd." La parola sta per "Hird of UNIX-replacing daemons" Hird di demoni che sostituiscono UNIX Per maggiorni informazioni sulla genesi dello Hurd vedi http://www.cs.pdx.edu/~trent/gnu/hurd/.. D'altro canto "Hird" sta per "Hurd of interfaces representing depth" Hurd di interfacce che rappresentano la profondità).
Il lavoro sullo Hurd iniziò nel 1990, poco prima di Linux, con lo scopo di essere il pezzo principale del sistema operativo GNU.
A quel tempo il progetto GNU, come anche altri, aveva già duplicato, utilizzando un modello di sviluppo open-source, molte delle funzionalità di UNIX; specialmente compilatori e strumenti per sviluppare.
Lo scopo era produrre un ambiente operativo simile a UNIX, ma completamente open-source; poiché però il kernel del sistema operativo non era ancora stato sviluppato, il progetto Hurd naque appostimente.
Al contrario di Linux, lo Hurd non fu pensato per l'architettura del PC; fu ideato per essere portato sui vari minicomputer e workstation disponibili all'epoca. Per questo motivo il progetto GNU poté utilizzare un design più elengante, anche se meno efficiente, del kernel.

Un microkernel è quello costituito dal minimo numero di funzionalità necessarie. Questo includono la creazione e rimozione di processi, lo scheduling, la gestine della memoria e quella delle interruzioni. Tutto il resto, come la gestione della rete o le primitive per la comunicazione tre processi, vanno implementate esternamente al kernel, nello spazio utente.
La comunicazione tra il kernel e queste funzionalità esterne avviene tramite una interfaccia pulita; al contrario di quanto avviene in un kernel monolitico dove i vari componenti possono accedere alla struttura interna degli altri in qualsiasi modo. La tabella 1  elenca i vantaggi di un microkernel.

I vantaggi di una architettura basata su un micorkernel per quanto riguarda la manutenibilità e la modificabilità sono familiari per chiunque abbia seguito lo sviluppo del software negli ultimi 20 anni, sia che sia stato a livello OS o applicativo.
Dopotutto questo è equivalente alla programmazione orientata agli oggetti. Si tratta di definire delle interfacce pulite e chiare per accedere agli oggetti. In questo modo qualsiasi cambiamento all'interno dell'oggetto (nelle strutture dei suoi dati o nei suoi flussi di controllo) non farà danno a nessuno oggetto esterno che lo usi. Dall'altra parte, l'accesso agli attributi interni di una classe potrebbe permettere una esecuzione più veloce del codice che utilizza l'oggetto stesso, ma questa maggiore velocità non è in genere considerata ragione sufficiente in relazione all'aumento della complessità dell'oggetto.

L'attenzione alla modularità nello Hurd va oltre l'utilizzo di un microkernel. Organizza anche tutte le attività extra kernel in moduli chiamati server (o demoni; sono gli "UNIX-replacing daemons" riferiti nell'acronimo.) Ciascuno dei quali fornisce un insieme di servizi alle applicazioni utente. La comunicazione tra i demoni e con gli applicativi avviene tramite delle interfacce ben definite.

Potresti chiedere perché sia interessante avvicianrsi allo Hurd, uno dei tanti sistemi operativi minori esistenti oggi. Chiunque abbia studiato la teoria dei sistemi operativi potrebbe nominare dozzine di progetti basati su microkernel. La teoria dei microkernel prese l'avvento nelle università almeno 15 anni fa, sfociando in una miriade di sistemi operativi giocattolo, i resti dei quali si possono facilmente trovare oggi nel Web. Una volta completato il progetto i loro autori hanno spostato i loro interessi; i microkernel ormai non sono più considerati interessanti nel mondo accademico. Molti tra questi sistemi operativi avevano caratteristiche interessanti, ma forse nessuno ha mai avuti un uso diffuso. Potreste essere quindi tentati di metter lo Hurd assieme agli altri, ma alcuni fattori lo rendono invece separato dalla massa di sistemi operativi minori.

Prima di tutto, alcuni importanti protagonisti stanno spingendo affinché si creino alernative open-source a Linux. Inoltre la Free Software Foundation sta sponsorizzando il progetto.
La FSF ha il massimo rispetto perché è stata una delle prime a adottare la filosofia open-source e a continuare l'attività di sviluppo. Ma forse ancora più importante è il coinvolgimento nel progetto del gruppo Debian (http://www.debian.org/), che produce una delle più rispettate e utilizzate distribuzione di Linux.
La distribuzione Debian, (chiamata "Debian GNU/Linux" perché la maggior parte del lavoro che la gente crede venga da Linux è in realtà frutto di progetti GNU), è tenuta in alta considerazione da chi contribuisce a Linux. Potrebbe anche essere considerata il miglior Linux open-source, perché non è controllata da nessuna operazione commerciale che venda la distribuzione traendone profitto -- tutti i contribuenti a Debian sono volontari. Ad ogni modo il gruppo Debian prevede di rilasciare una distribuzione Debian GNU/Hurd che consista di tutti i pacchetti attualmente disponibili nella versione Linux, ma che si basi sullo Hurd come sistema operativo sottostante.
Questo sviluppo è significativo perché faciliterà il passaggio da Linux a Hurd per gli utenti. L'installazione e l'uso di Hurd saranno il più simile possibile ai corrispettivi Linux. Inoltre il coinvolgimento del gruppo Debian contribuisce ad assicurare che lo Hurd sia portato avanti come sviluppo e poi distribuito; il gruppo ha una lunga esperinza nel produrre sistemi operativi usabili.

Il secondo fattore che separa lo Hurd dagli altri sistemi operativi minori è il fatto che gli sviluppatori sono indirizzati verso una compatibilità totale con UNIX e inoltre hanno già una pianificazione per raggiungerla. Con il coinvolgimento di Debian questo vuol dire principalmente che Hurd sarà compatibile Linux.
Ricordo che lo scopo originale dello sviluppo dello Hurd da parte di FSF è di completare un sistema operativo simil UNIX completamente libero; tutto è già stato sviluppato eccetto il kernel.
Il progetto non sarà ritenuto completo fino a quando tutti i programmi GNU e gli strumenti di sviluppo non gireranno sotto il nuovo sistema operativo.
Per questo il gruppo Hurd è fortemente motivato a sviluppare un sistema operativo che possa eseguire applicazioni UNIX. Allo stesso modo il gruppo Debian vuole utilizzare i pacchetti Linux che ha già sviluppato.
La sola prospettiva di successo è quella di distribuire lo Hurd con una serie di applicazioni già sviluppate. Quindi è chiaro che chi partecipa al progetto è motivato a completare un sistema operatico completo e usabile; non stanno semplicemente sperimentando un giocattolo per scopi scientifici. Un esame attento dell'architettura dello Hurd rivelerà perché questo sistema operativo ha una attrattività che per alcuni sviluppatori supera quella di Linux.

Introduzione all'architettura dello Hurd

Come detto precedentemente lo Hurd consiste di un microkernel, che ne fa da cuore, e da una serie di server che lo circondano, che forniscono servizi alle applicazioni.
Uno dei fattori tenuti presente durante il disegno del microkernel è stata la sua intercambiabilità in modo tale che sia sostituibile con un altro; per esempio, uno che offra un diverso algoritmo per lo scheduling o per la gestione della memoria.
Per ora, comunque, lo Hurd è abbastanza legato al microkernel Mach, uno dei primi e tra i più conosciuti microkernel.
Mach esiste in varie versioni e varianti -- quella utilizzata dallo Hurd è GNU Mach, un Mach open source sviluppato come parte del progetto GNU. Attorno a Mach ci sono i server (vale a dire, demoni indipendenti con interfacce ben definite) e le applicazioni.

Il microkernel Mach

Mach è un microkernel molto conosciuto. Se hai seguito un corso di sistemi operativi negli ultimi 10 anni, probabilmente lo hai studiato. Mach è strutturato in maniera orientata agli oggetti -- i puristi diranno che è una forzatura in quanto è scritto in C e non ha né ereditarietà né polimorfismo. In ogni caso Mach può essere visto come costituito dalle seguenti classi: porte, messaggi, processi, processi leggeri, memoria virtuale. Come tutti i sistemi OO (orientati agli oggetti) le interfacce alle classi sono ben definite e stabili, in questo modo i cambiamenti interni alle classi non incidono sul codice che le usa.

Un processo Mach corrisponde più o meno ad un processo UNIX. È un ambiente di esecuzione che rappresenta le risorse utilizzate da un programma in esecuzione, come la memoria virtuale o i cicli del processore. Ma in contrasto con i tradizionali processi UNIX, un processo Mach non ha necessariamente un processo di esecuzione -- questi in Mach sono i processi leggeri e sono una classe separata. Ovviamente un processo è interessante solo se contiene almeno un processo leggero.
I processi leggeri in un contesto Mach sono gli stessi dei moderni sistemi operativi come UNIX o Windows -- un processo d'esecuzione che condivide la memoria e altre risorse con altri processi leggeri all'interno dello stesso processo. Mach è stato disegnato sin dalle fondamenta per essere un sistema altamente multithreated e per funzionare egregiamente su sitemi multi processore.
al contrario Linux naque con sistema oiperativo tradizionale orientato ai processi, con il multithreading e multiprocessing aggiunti solo di recente. L'uso del multithreading su Linux è stato possibile solo grazie alla diffusione della libreria C clig, mentre il supporto al multiprocessing non è ancora veramente completo.
In ogni caso Mach e lo Hurd sono stati disegnati per supportare questi concetti sin dall'inizio.

Il mezzo principale di comunicazione tra i processi Mach sono le porte. Una porta Mach è un qualcosa di analogo alle porte nel contesto delle comunicazioni basate su socket -- un canale di comunicazione tra due processi. Come le porte del costesto dei socket, quelle Mach sono state disegnate per comportarsi allo stesso modo sia che i processi girino sullo stesso processore, sia che girino su processori diversi, sia che siano su macchine differenti in una rete. Poiché le porte sono il mezzo predefinito per fare comunicare i processi si ha che le applicazioni possono molto facilmente scalare in modo da essere utilizzate in sistemi multiprocessori. Inoltre i dati che vengono comunicati in questo modo sono una forma di messaggi che è strutturata come un oggetto Mach. Infine Mach fornisce servizi per la gestione della memoria come anche funzionalità per con condividere momoria tra processi.

I server Hurd

Il microkernel Mach una serie di caratteristiche, ma dal punto di vista dello Hurd, non sono considerate molto importanti. Lo Hurd richiede solo che il microkernel fornisca le funzionalità di un kernel: schedulazione, creazione e rimozione di processi, IPC e gestione della memoria. Difatti in teoria un altro microkernel che fornisca queste funzionalità può essere sostituito al Mach, in modo facilitare la portabilità dello Hurd; ma attualmente Mach è l'unico kernel utilizzato dallo Hurd.
Oltre a questa base sul microkernel c'è un altro aspetto tecnico molto interessante dello Hurd, cioé il suo design multiserver. I vari server che stanno attorno al microkernel funzionano in modalità utente e forniscono servizi agli applicativi. Uno sguardo ad alcuni server hurd e altre sue caratteristiche ne chiarifica il disegno.

Il server di autenticazione fornisce l'identificazione degli utenti ai processi che vogliano comunicare con altri. Un processo può verificare l'identità di un altro connettendosi alla porta del server di autenticazione e usando i suoi servizi. Quindi il servier di autenticazione fornisce dei servizi essenziali per lo Hurd. Nota però che esso non ha uno status speciale -- è un programma che gira in modalità utente come tutti gli altri. Ciascuno può in pratica programmare e utilizzare un proprio server di autenticazione; altri utenti saranno liberi di utilizzarlo se si fidano oppure potranno ignorarlo.

Il server dei processi sostanzialmente fa da ponte tra il concetto dei processi UNIX e quello dei processi Mach. Lo UNIX POSIX definisce un concetto di processo che non è supportato dal Mach -- questa funzionalità mancante è implementata da questo server.
Inotre fornisce le informazioni pubbliche dei processi -- i processi possono registrarsi in questo server in modo che altri processi (come ad esempio il programma 'ps'di UNIX) possano ottenere queste informazioni su tutte le attività in corso. L'uso di questo server è facoltativo; un processo non ha l'obbligo di registrarsi, nel qual caso altri processi non mpotranno ottenerne informazioni.

Lo Hurd consiste di vari server, inclusi quelli per la comunicazione via socket, NFS, altri ancora. Vari server sono stati definiti e poi rimossi durante lo sviluppo di Hurd. Tieni presente che ogni utente può creare qualsiasi server a piacimento -- non è richiesto alcun permesso speciale.

Oltre a quello dei server un altro concetto chiave dello Hurd è quello dei traduttori.
Puoi pensare che i traduttori siano un concetto elegante per implementare quelli che sono i vari tipi di filesystem in UNIX, con caratteristiche quali mount point, dispositivi, collegamenti simbolici. Ogni file nella gerarchia Hurd ha associato un programma chiamato "translator" (traduttore.)
Quando un programma utente accede al file, il controllo è passato al traduttore che gestirà l'operazione. Se l'accesso è una lettura del file allora il traduttore richiederà il blocco al dispositivo. Se l'access è a un dispositivo allora il truduttore sarà il driver associato. Lo stesso vale per i collegamenti simbolici -- un traduttore può semplicemente ridirigere la chiamata a qualcun'altro nella gerarchia dei file.

Per quanto detto i traduttori non fornisco nulla a quello che già è nel filesystem UNIX, vale a dire un accesso unico a file, dispositivi e collegamenti.
Ma i traduttori Hurd possono essere applicati ad ogni tipo di dato. Un esempio è quello dell'accesso FTP. I file su un sistema remoto possono essere mappati come un file system locale (su, ad esmpio, /ftp/ftp.miodominio/com/pub/miofile) e copiati, cancellati e modificati con gli stessi comandi che si usano per i file locali. Il traduttore ovviamente tradurrà le normali funzionalità di accesso al file in operazioni FTP necessarie a soddisfare la richiesta origiaria.
Puoi facilmente immaginare altri traduttori utili. Dati strutturati gerarchicamente in una base di dati potranno essere scorsi utilizzando cat, ls, e coì via. Oppure un programma di amministrazione remota potrebbe essere implementato con tutti i computer della rete locale mappati in una sola directory locale. Cat potrebbe mostrarne i dati relativi alla rete, come ad esempio l'indirizzo IP. Le macchine che agiscono da gateway potrebbero essere directory -- eseguendo cd su queste macchine si potrebbe accedere ai computer in quella sottorete.
Come per i server, i traduttori non richiedono particolari privilegi. Chiunque può scriverli, testarli, e speriemntarli finché non saranno pronti per l'uso da parte di altri utenti.

Lo stato attuale dello Hurd

Per tutte le sue promesse, non è ancora il caso di raccomendare lo Hurd all'utente medio. Al momento della scrittura dell'articolo il sistema operativo manca ancora di alcune funzionalità di base e non è pensabile che si a utilizzabile da un utente medio ancora per un po' di tempo.
Attualmente lo Hurd non ha nulla che non possa essere fatto con Linux. Al contrario un hacker con esperienza su Linux sarà già in grado di gestire lo Hurd, e se siete interessati a contribuire allo sviluppo, alcune parti sono certamente da portare avanti. Per via della sua eleganza molti sviluppatori troveranno lo Hurd parecchio più facile da comprendere che Linux.

A parte la sua comprensiblità, il disegno modulare dello Hurd permette una infinita possibilità di personalizzazione. Abbiamo visto come server possano essere aggiunti o rimossi in maniera semplice e come il microckernel sia sostituibile. È facile immaginare varianti dello Hurd con ambienti particolari, specialmente per le applicazioni embedded.
Forse lo GNU Mach può essere rimpiazzato dal un microkernel real-time (un Mach real-time è già disponibile), e un certo numero di servizi non indispensabili potrebbero essere rimossi.
Con uno sforzo minimo, potremmo implementare un sistema operativo in tempo reale per una applicazione. Una particolare applicazione embedded che richieda un piccolo device per essere gestita potrebbe eliminare tutti i server in più, mentre una più complessa potrebbe richiederne di nuovi. Tutte le applicazioni possono essere sviluppate sulla versione del sistema opeartivo per PC da tavolo. Una delle attrattive di Linux è che offre la libertà di creare un proprio sistema operativo personalizzato. Lo Hurd ha la potenzialità di rendere questa libertà una possiblità pratica.

DDJ

codebytes: GNU Hurd with Thomas Bushnell
http://www.technetcast.com/tnc_play_stream.html?stream_id=381