Google Fuchsia usa un microkernel. Qual è la differenza e perché è rilevante

Google Fuchsia usa un microkernel. Qual è la differenza e perché è rilevante

Google Fuchsia è un nuovo sistema operativo in sviluppo con una particolarità: utilizza Zircon, un microkernel. L'approccio progettuale è piuttosto differente rispetto ai sistemi operativi più diffusi, che usano perlopiù modelli ibridi. Vediamo come un approccio a microkernel potrebbe garantire a Google maggiore controllo sulle sue piattaforme come Android e Chrome OS

di pubblicato il nel canale Sistemi Operativi
Google
 

Non accade tutti i giorni che un nuovo sistema operativo venga distribuito su migliaia o addirittura milioni di dispositivi di uso comune. Ciò è, però, quanto è avvenuto con Fuchsia, un sistema sviluppato da Google e ora impiegato sui dispositivi Nest. La particolarità di Fuchsia sta nel suo kernel, Zircon, che è un microkernel e per questo si differenzia dagli altri sistemi maggiormente diffusi. Ci sono vantaggi e svantaggi in questo approccio, che storicamente è stato motivo di divisione tra esponenti di spicco del mondo dell'informatica.

Cos'è un kernel e come funziona, in breve (o quasi)

Zircon è, come abbiamo detto, un microkernel (anche se Google non è chiara su questo punto e talvolta afferma che non lo sia). Per capire perché ciò sia importante dobbiamo, però, fare qualche passo indietro per capire cos'è un kernel, quali compiti svolge e come.

"Kernel" significa "nocciolo" o "seme" ed è dunque il cuore, l'elemento al centro del sistema operativo. Il kernel è, in termini molto semplicistici, il programma che si occupa di gestire il computer e le sue risorse. I sistemi operativi nascono dall'esigenza di dividere le risorse di un computer tra più programmi: in un'epoca in cui esistevano grandi computer dedicati a calcoli specialistici, la programmazione avveniva pensando di avere a disposizione tutte le risorse della macchina perché così effettivamente era, ma col tempo ci si rese conto che un computer poteva eseguire più operazioni in contemporanea in ambiti diversi (ad esempio, mentre il processore era impegnato a fare calcoli, si potevano caricare le schede perforate o stampare i risultati di un programma eseguito precedentemente). Questa idea si espanse all'uso del computer da parte di molteplici utenti contemporaneamente e, dunque, all'uso di più programmi.

Già, ma come è possibile permettere l'uso contemporaneo di un computer a più programmi, se c'è un solo processore? L'idea fu quindi quella di creare un programma che fungesse da supervisore (e da qui nacque successivamente l'idea di un ipervisore per la virtualizzazione dei sistemi operativi). Questo supervisore doveva creare l'illusione che il programma in esecuzione avesse il controllo della macchina e ne avesse a disposizione tutte le risorse; per farlo, si pensò di spezzettare l'esecuzione dei programmi, alternandoli e dividendo le risorse del computer in fasi (input, esecuzione, output...). Ci si rese altresì conto che era possibile mettere a disposizione delle funzionalità che permettevano di accedere alle risorse della macchina senza che i programmatori dovessero ogni volta riscrivere il codice per farlo. In altre parole, si arrivò alla creazione di un sistema operativo, che altro non è che un'astrazione dell'hardware e delle funzionalità a disposizione della macchina.

Il kernel è la componente fondamentale di un sistema operativo perché è il programma che si occupa di sovrintendere tutti gli altri: oggigiorno assegna tempo di processore a ciascun processo, decidendo per quanto tempo deve essere eseguito prima di dare il turno a un altro, e si occupa di gestire le operazioni riservate come l'assegnazione di spazio di memoria, la lettura e la scrittura dal disco e così via. Vecchi sistemi operativi come Mac OS usavano invece una modalità detta "cooperativa", per cui era il programmatore dell'applicativo a dover esplicitamente "lasciare spazio" agli altri programmi.

Da diverso tempo i kernel sono eseguiti in una modalità diversa (kernel space) rispetto a quella dei programmi normali (user space). Ci si rese conto ben presto, infatti, che un programmatore malintenzionato avrebbe potuto compromettere il funzionamento del kernel se questo fosse stato eseguito con gli stessi permessi dei programmi comuni, e per lo stesso motivo non era possibile lasciare il controllo di operazioni chiave come l'allocazione della memoria o le operazioni sul disco ai programmi comuni: per capire perché ciò sia importante basta immaginare la possibilità di riscrivere una porzione di memoria di un altro programma con codice malevolo, ad esempio per far sì che il browser invii le credenziali della banca a un certo indirizzo. Giovenale chiedeva "quis custodiet ipsos custodes?", ovvero "chi controlla i controllori?", e il problema era proprio questo: creare un garante della correttezza del kernel, oppure isolare il kernel. Fu scelta la seconda opzione, più semplice e pratica.

Resta, però, un problema da risolvere: cosa succede se c'è un errore nel kernel? È qui che le strade si separano: l'approccio dei kernel monolitici, scelto ad esempio da UNIX, BSD e Linux (quest'ultimo non più realmente monolitico da tempo), è quello di contenere al proprio interno tutte le funzionalità in un unico blocco che prova a risolvere un eventuale problema internamente e, in caso di fallimento, semplicemente di arrendersi e di forzare il riavvio della macchina (ad esempio con un kernel panic); i microkernel, invece, spostano alcune delle funzionalità chiave in server esterni al kernel vero e proprio così che, se un server va in crash, è possibile riavviarlo senza compromettere la stabilità dell'intera macchina. Un server può, ad esempio, gestire elementi del sistema come i driver, l'accesso ai file system, la gestione della rete e così via. Il microkernel si occupa, dunque, solo della gestione della memoria, dei processi, dei thread e della comunicazione tra processi (IPC, inter-process communication). Tra i microkernel usati commercialmente ricordiamo: QNX, impiegato da BlackBerry; Exec, usato da AmigaOS; EKA2, usato da Symbian. A livello accademico sono di particolare rilevanza Minix, Mach e L4. Windows NT e XNU, il kernel alla base di macOS, sono entrambi ibridi che contengono molti elementi architetturali dei microkernel.

Il vantaggio principale dei kernel monolitici sta nella velocità: essendo tutto contenuto nello stesso programma, non c'è bisogno di effettuare i context switch, ovvero le operazioni necessarie al passaggio da un processo all'altro e che sono decisamente costose da un punto di vista temporale. Tali operazioni rappresentano, per di più, tempo "buttato": non viene fatto nulla di utile o produttivo. Un microkernel, invece, deve fare continui context switch e affidarsi all'IPC per gestire componenti diverse del sistema e per questo ha prestazioni inferiori.

Per usare una metafora non del tutto realistica, possiamo immaginare un kernel monolitico come l'unico supervisore di un impianto produttivo: si occupa di gestire tutti i macchinari, di programmare la produzione, di effettuare la manutenzione e di garantire che tutto avvenga nel rispetto delle regole; è estremamente efficiente e riesce a svolgere tutti i suoi compiti molto bene, ma nel caso in cui si ammali l'impianto si ferma (il bus factor è pari a 1). Un microkernel, invece, è un supervisore che dà istruzioni a vari responsabili: la comunicazione con essi richiede più tempo rispetto all'esecuzione diretta del supervisore unico, ma dall'altro lato è possibile sostituirli senza fermare tutto.

Chi volesse approfondire la questione può fare riferimento all'ottimo testo Operating Systems: Three Easy Pieces di Remzi Arpaci-Dusseau e Andrea Arpaci-Dusseau, liberamente scaricabile dal sito ufficiale.

Zircon: un microkernel per tutti?

Zircon è rilevante perché è pensato per operare su molteplici dispositivi, da quelli IoT fino ai computer, e rappresenta per molti versi un rimpiazzo del kernel Linux. È stato introdotto per la prima volta su un prodotto commerciale il 25 maggio 2021, quando è stato reso disponibile per Google Nest Hub; è lecito prevedere che verrà usato su molteplici altri dispositivi in futuro.

Nello specifico, Fuchsia potrebbe rimpiazzare Android e Chrome OS per come li conosciamo ora. Come è stato fatto per il Nest Hub, così potrebbe accadere anche per altri dispositivi: l'interfaccia utente e le applicazioni rimarrebbero gli stessi, ma le componenti di sistema cambierebbero radicalmente. Ciò darebbe a Google un maggiore controllo sullo sviluppo dei sistemi, che attualmente dipendono da Linux. Si tratta, comunque, solo di ipotesi e al momento non ci sono sufficienti prove che questo sia il piano di Google, per quanto un articolo di Bloomberg del 2018 affermi che ci sia la volontà di portare Fuchsia su smartphone e portatili entro il 2023. Tale articolo aveva previsto che Google avrebbe lanciato Fuchsia sui dispositivi IoT "entro tre anni" e tale previsione si è rivelata azzeccata, dunque c'è motivo per credere che anche il resto possa essere corretto.

Un aspetto particolarmente interessante di un approccio a microkernel è che è teoricamente possibile creare dei driver in user space che non richiedono necessariamente un aggiornamento se cambia il sistema operativo. In questo modo sarebbe possibile avere smartphone che vengono aggiornati per diversi anni anche in assenza di supporto da parte dei produttori dell'hardware. In questo modo Google potrebbe teoricamente emulare il modello di Windows Phone, in cui è lei stessa a gestire gli aggiornamenti del sistema, superando l'attuale frammentazione estrema che caratterizza il panorama di Android.

Per chi fosse curioso, è già possibile provare Fuchsia e Zircon: dahliaOS è una distribuzione di Fuchsia che è possibile provare già ora sul proprio hardware. È disponibile sul sito ufficiale del progetto, dove è possibile scaricarne delle immagini installabili e consultare l'elenco dei dispositivi compatibili.

L'aspetto forse più interessante di tutta la vicenda è che Google sembra puntare a un cambiamento "sotto il cofano" che sia invisibile all'utente, grazie (anche) all'uso di programmi scritti in linguaggi portabili come Java e Flutter/Dart. Se Google riuscisse davvero a cambiare completamente il sistema sottostante per lasciare intatte le applicazioni, avrebbe raggiunto un risultato estremamente significativo a livello tecnico (e commerciale). Quanto ciò sarà possibile dipenderà anche dalla gestione dei rapporti di potere presenti tra le varie divisioni all'interno di Google.

30 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
supertigrotto17 Giugno 2021, 19:11 #1
Se non sbaglio,quando c'era la sfida monolitico vs micro ,vinceva il monolitico per via che si usavano CPU monocore,dagli ultimi dati che ho letto,il microkernel con le CPU multicore sono diventati scattanti,a tal punto che la differenza fra monolitico e microkernel non si nota nemmeno.
Fra l'altro Mach viene usato su macchine CNC per evitare disastri nelle lavorazioni,essendo pure RealTime.
In effetti,il sistema operativo e relativo kernel,come concetto ,era stato creato decenni fa,quando le CPU erano quasi totalmente diverse da quelle moderne,quindi un cambio di paradigma ci starebbe.
demon7717 Giugno 2021, 19:28 #2
Originariamente inviato da: supertigrotto
Se non sbaglio,quando c'era la sfida monolitico vs micro ,vinceva il monolitico per via che si usavano CPU monocore,dagli ultimi dati che ho letto,il microkernel con le CPU multicore sono diventati scattanti,a tal punto che la differenza fra monolitico e microkernel non si nota nemmeno.
Fra l'altro Mach viene usato su macchine CNC per evitare disastri nelle lavorazioni,essendo pure RealTime.
In effetti,il sistema operativo e relativo kernel,come concetto ,era stato creato decenni fa,quando le CPU erano quasi totalmente diverse da quelle moderne,quindi un cambio di paradigma ci starebbe.


In effetti, da ciò che ho capito dall'articolo ad oggi è molto più conveniente l'uso di microkernel visto che si hanno i vantaggi citati mentre gli svantaggi vengono fortmente mitigati dalla presenza ormai ovunque di CPU multicore che sono appunto perfette per una gestione in stile microkernel.

Mi pare di capire anche che zircon è di fatto un sistema completamente nuovo che nulla ha a che vedere con Linux..
Mi chiedo se sarà competitivo rispetto a linux visto che comunque su linux ci hanno lavorato per anni ed anni un esercito di programmatori in tutto il pianeta..
demonsmaycry8417 Giugno 2021, 20:23 #3
oddio per un momento ho pensato di tornare a leggere uno di quegli articoli che si trovavano su riviste come microcomputer anche se non tecnico come allora che dire finalmente qualcosa di un pò più approfondito e non del solito tenore "google vuole fuchsia perchè il reparto marketing ha visto che il viola va di moda" ...ok no sarei ingeneroso ma mi è piaciuto molto rispetto al solito

detto questo dopo quello che ha fatto apple con rosetta di fronte ad un incremento di performance sui soc si potrebbe attutire la ricaduta della mancanza di app native. L'evoluzione di smartphone , ipad e tutti i dispositivi con arm pone la necessità di muoversi verso SO più moderni e modulari che possano venire ritagliati sull hw di destinazione.
boboviz17 Giugno 2021, 23:17 #4
Se sento parlare di microkernel il primo ricordo che mi viene è Hurd.
E non è un bel ricordo, eh.
frankie17 Giugno 2021, 23:42 #5
C'era un sito, parallelo a HWU di anni orsono, una volta lo avevo tra i preferiti, poi è sparito. Era molto tecnico, ma efficace. Mi piacerebbe ritrovarlo con la wayback machine. Solo che non ricordo il nome.

EDIT: dopo un giro al pensatoio (...) ho trovato: lithium.it
https://web.archive.org/web/2007081...Itemid=99999999
TheGaiden18 Giugno 2021, 00:00 #6
io non ne so molto (diciamo nulla) ma sarei curioso di conoscere qualche dettaglio in più sul "passaggio" del kernel linux da monolitico a microkernel (e mi viene da pensare alla famosa lite con Tanenbaum).
qualcuno potrebbe spiegarmi?
grazie!!
lollo918 Giugno 2021, 07:21 #7
Originariamente inviato da: TheGaiden
io non ne so molto (diciamo nulla) ma sarei curioso di conoscere qualche dettaglio in più sul "passaggio" del kernel linux da monolitico a microkernel (e mi viene da pensare alla famosa lite con Tanenbaum).
qualcuno potrebbe spiegarmi?
grazie!!


infatti si tratta di un'antica confusione tra microkernel e monolitici modulari.
non c'è nessun "passaggio a microkernel"

Linux non è un microkernel sotto nessun aspetto, anzi è monolitico fino al midollo per precisa scelta. la famosa lite infatti verteva anche su questo aspetto tra le tante cose: veniva rimproverato a Linux di "nascere vecchio", e sinceramente Tanenbaum non aveva tutti i torti all'epoca.

quello che linux ha guadagno negli anni in aggiunta alla natura monolitica, è l'essere modulare, vale a dire che non deve necessariamente caricare tutto in un colpo solo per avviarsi ma può prendere pezzi di kernel al volo e farli girare in kernel space. le prestazioni restano alte ed scalare su multi CPU resta possible, non come un micro ma comunque infinitamente più di un mololitico "classico".

a livello di design non è mai stato in discussione che i micro siano più robusti ed eleganti, il problema sono sempre state le prestazioni
jepessen18 Giugno 2021, 09:09 #8
Mah, allo stato attuale non vedo nessun motivo per un PC "normale" il passaggio al microkernel... Il riavvio di un servizio non credo che sia comunque indolore, e il calo di prestazioni a mio avviso si fa sentire anche nei multicore. Il discorso dell'eleganza poi regge poco, un software e' fatto bene se funziona bene a mio avviso. Poi e' ovvio che se funziona bene in genere e' perche' e' ben organizzato, ma da qui all'eleganza del microkernel ce ne vuole.

Non a caso Google lo ha scelto non tanto per Android, ma per quei dispositivi IoT, come il Nest, dove alla pura potenza computazionale si preferisce l'affidabilita', quindi il fatto che in caso di crash di un servizio non si resetti l'intero dispositivo. Sinceramente comunque non credo siano piu' affidabili di un kernel linux monolitico. Ho come l'impressione che il microkernel, basato sui servizi, sia passato alla ribalta come conseguenza della nascita dei microservices in ambito server (docker etc), facendo tornare "di moda" il fatto di avere tanti piccoli programmi indipendenti invece di un solo grosso blocco, che puo' avere senso per grandi applicazioni (servizi web come amazon e netflix), e meno per applicazioni che girano sul singolo PC, come un kernel.
andbad18 Giugno 2021, 09:16 #9
Le discussioni tra micro e mono mi hanno sempre ricordato quelle tra RISC e CISC.

By(t)e
DanieleG18 Giugno 2021, 09:22 #10
Originariamente inviato da: supertigrotto
Se non sbaglio,quando c'era la sfida monolitico vs micro ,vinceva il monolitico per via che si usavano CPU monocore,dagli ultimi dati che ho letto,il microkernel con le CPU multicore sono diventati scattanti,a tal punto che la differenza fra monolitico e microkernel non si nota nemmeno.
Fra l'altro Mach viene usato su macchine CNC per evitare disastri nelle lavorazioni,essendo pure RealTime.
In effetti,il sistema operativo e relativo kernel,come concetto ,era stato creato decenni fa,quando le CPU erano quasi totalmente diverse da quelle moderne,quindi un cambio di paradigma ci starebbe.


Il monolitico vinse perché era più facile da gestire e programmare, molto più semplicemente. E infatti linux "esplose" per questo. Fosse nato come microkernel probabilmente sarebbe stato più "pulito", ma sarebbe rimasto un bel progettino di uno studente.
D'altronde di esempi così è piena la storia della tecnologia...

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^