View Single Post
Old 19-06-2021, 11:36   #22
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8222
Quote:
Originariamente inviato da jepessen Guarda i messaggi
Touche'... Si vede che sono al primo picco del grafico Dunning-Kruger... Vado a cercare un buon libro sui sistemi operativi per studiare meglio l'argomento monolitico vs microkernel... Qualche consiglio (italiano o inglese non fa differenza)?
Non troverai niente di meglio del Tanenbaum. E si, lo so che come libro universitario è molto superficiale. Ma usa un linguaggio semplice proprio per far capire i concetti in maniera chiara.

Comunque sia, vedo dai commenti che c'è un bel pò di confusione. La questione stabilità non riguarda i servizi, che girano in userspace, ma i driver ( e mi riferisco anche ai filesystem, network stack, ecc... ). Cioè parliamo di decine ( e spesso centinaia ) di milioni di righe di codice, magari scritte in C.

Sulla questione eleganza, non è che il codice di un microkernel è bello da vedere, ma è decomposto in moduli isolati, sui quali è facile ragionare e spesso è possibile verificarne l'aderenza alle specifiche in maniera formale ( cioè matematicamente ).

Prendete seL4 per esempio. Già parti con un kernel il cui funzionamento è formalmente verificato e quindi hai enormi certezze sul fatto che l'implementazione sia corretta. E per il fatto di essere microkernel, ogni altro componente deve usare le API e i meccanismi imposti per comunicare col kernel.

E' un bel lavoro di semplificazione e separazione delle competenze. Si può ragionare sulle interazioni ad alto livello, la cui correttezza è garantita da meccanismi di IPC semplici, quindi facili da debuggare e in conclusione molto stabili.

Provate a fare lo stesso con un kernel monolitico. E questo discorso riguarda qualsiasi tipo di software. Per questo i browser hanno adottato la politica di separare le tab in processi distinti. La modularizzazione non è solo un modo di renderlo il codice bello da vedere, ma di dare al programmatore la capacità di ragionare sulle interazioni tra i vari componenti.

Lo scotto da pagare è una necessaria progettazione a monte. Cioè niente "hacking" e programmazione agile.
pabloski è offline   Rispondi citando il messaggio o parte di esso
 
1