back

Allo sviluppatore non rimane che studiare bene l'interfaccia (costituita dalle system call proposte) per poter sviluppare il proprio software applicativo; si è soliti procedere alla stesura di un insieme di librerie che, sfruttando i servizi offerti dal Kernel, semplifichino ulteriormente l'architettura, il tutto nel pieno rispetto del principio di astrazione. Il cammino è semplice: dal sottosistema X.Org, passando per i toolkit basati su di esso (Qt e Gtk per citarne alcuni) per giungere infine ai vari Desktop Environment con le relative applicazioni utilizzate dagli utenti nel quotidiano.

Il modello presentato (ovviamente semplificato) costituisce il classico Sistema Operativo a cui gli utenti di Debianizzati sono abituati. Alla domanda: "Che cosa è il Kernel?" è ora facile rispondere: "Il software che gestisce interamente la macchina, sul quale, attraverso astrazioni successive, si appoggiano tutti i programmi utilizzati dall'utente".

Vediamo le conseguenze che presenta la scelta di adottare una simile soluzione all'interno di un Sistema Operativo.
La totale condivisione delle risorse permette innanzitutto di ottimizzare le procedure interne, ottenendo prestazioni superiori a tutte le altre soluzioni poichè l'accesso all'hardware avviene in maniera diretta, utilizzando sempre istruzioni privilegiate.

L'architettura di un Kernel Monolitico, seppur confusionale, è più semplice; gli sviluppatori possono utilizzare qualsiasi risorsa con estrema libertà, non hanno bisogno di introdurre procedure ausiliarie; se occorre, per esempio, accedere ad un campo del PCB possono farlo direttamente. Inoltre i programmatori di alto livello si ritrovano ad essere del tutto svincolati dalla gestione della macchina. Questi sono forse gli aspetti che hanno giocato il ruolo di maggior rilievo nel successo dell'approccio "Monolitico" alla progettazione di un Kernel; il costo di progetto è sempre uno dei principali discriminanti nello sviluppo di una tecnologia.

La scelta di raggruppare l'intera gestione della macchina in un unico file eseguibile porta diversi svantaggi, primo fra tutti l'impossibilità di modificarne la struttura durante l'esecuzione. Qualora risultasse necessario introdurre o cambiare dei moduli, poichè, per esempio, si è sostituito un dispositivo all'interno del calcolatore, non sarebbe possibile farlo se non ricompilando la totalità dei sorgenti. Un software una volta compilato non è più modificabile, occorre ricompilare i sorgenti ex-novo.
In secondo luogo al crescere dei dispositivi supportati e delle tecnologie incluse, consegue l'aumento della dimensione del file binario ottenuto; è opportuno quindi operare un bilanciamento fra i servizi che si intendono proporre e il contenimento del peso in Byte.
Un Kernel Monolitico pertanto è fortemente statico e tenderà sempre a crescere di dimensione all'avanzare del suo sviluppo.

back