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
 
30 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
frankie18 Giugno 2021, 09:32 #11
Se dal lato applicazioni sembra che sia rimasto tutto come prima, quali sono i vantaggi da passare dal kernel linux a fuchsia (a parte il controllo di Google)?
Intendo pratici, non teorici, cosa si è ottenuto?
jepessen18 Giugno 2021, 09:48 #12
Originariamente inviato da: frankie
Se dal lato applicazioni sembra che sia rimasto tutto come prima, quali sono i vantaggi da passare dal kernel linux a fuchsia (a parte il controllo di Google)?
Intendo pratici, non teorici, cosa si è ottenuto?


Che puoi scrivere driver demme@@a, tanto se crashano si riavvia il servizio e non crasha il computer...
lollo918 Giugno 2021, 10:10 #13
Originariamente inviato da: jepessen
...


sul fatto che l'eleganza formale conti poco sono d'accordo visto che si parla di strati a così basso livello, scritti e testati da tantissima gente con competenze al top. deve prima di tutto funzionare.
poi più in generale no, un SW che vive su side effect per dirne una non è solo inelegante, è difficilmente debuggabile ed i test sintetici sono lenti, costosi e meno affidabili. sono tutti costi che poi vanno pagati in qualche modo.

ad ogni modo, al giorno d'oggi queste distinzioni sul kernel lasciano un po' il tempo che trovano. i monolitici sono più performanti e qualunque aggiuntiva necessità di robustezza può essere soddisfatta in 2000 altre maniere. in fin dei conti roba come microservizi e contract testing è emersa anche per motivi di questo genere, tra i tanti.

certo che se poi uno deve programmare un rover marziano o l'avionica di un aereo forse il discorso cambia, ma sono casi limite
Pino9018 Giugno 2021, 10:30 #14
Il codice di Fuchsia ha molto in comune con Mbed e questo è solo un bene. Ho rubacchiato codice qua e là l'anno scorso e devo dire che il livello è altissimo.

Il mio hype è oltre 9000

PS I file scritti in assembly sono una manciata, giusto startup.s per qualche ISA o board, poi tutto il resto è in Go e per fortuna direi <3

PPS Zircon è un fot***o spettacolo
blackshard18 Giugno 2021, 16:44 #15
Originariamente inviato da: jepessen
Che puoi scrivere driver demme@@a, tanto se crashano si riavvia il servizio e non crasha il computer...


Nemmeno su kernel monolitico un servizio scritto male manda in crash il computer. Ci mancherebbe.

I "servizi" (intesi come demoni) non girano con i privilegi del kernel, ma sono normali processi userspace.

La differenza fra kernel monolitico e microkernel è tutta nello spazio del kernel stesso: il kernel monolotico tutto (core, IPC, MMU, IRQ handler, memory mapping, filesystem, ...) gira con gli stessi elevati privilegi del kernel, nel microkernel solo una piccola parte critica è il kernel a privilegi massimi e il resto, come driver di periferiche o filesystem, hanno privilegi meno elevati o addirittura girano in userspace.

Come in tutte le cose, ci sono vantaggi e svantaggi. Fra gli svantaggi c'è da mettere in conto l'overhead, e questo c'è sempre anche con cpu multicore (dove è pure peggio); fra i vantaggi una maggiore sicurezza, testabilità e stabilità.

edit: come già accennato in precedenza, nella definizione di monolitico/microkernel non entra nemmeno il discorso dei driver a "plugin"
jepessen18 Giugno 2021, 16:49 #16
Originariamente inviato da: blackshard
Nemmeno su kernel monolitico un servizio scritto male manda in crash il computer. Ci mancherebbe.

I "servizi" (intesi come demoni) non girano con i privilegi del kernel, ma sono normali processi userspace.

La differenza fra kernel monolitico e microkernel è tutta nello spazio del kernel stesso: il kernel monolotico tutto (core, IPC, MMU, IRQ handler, memory mapping, filesystem, ...) gira con gli stessi elevati privilegi del kernel, nel microkernel solo una piccola parte critica è il kernel a privilegi massimi e il resto, come driver di periferiche o filesystem, hanno privilegi meno elevati o addirittura girano in userspace.

Come in tutte le cose, ci sono vantaggi e svantaggi. Fra gli svantaggi c'è da mettere in conto l'overhead, e questo c'è sempre anche con cpu multicore (dove è pure peggio); fra i vantaggi una maggiore sicurezza, testabilità e stabilità.

edit: come già accennato in precedenza, nella definizione di monolitico/microkernel non entra nemmeno il discorso dei driver a "plugin"


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)?
maxsona18 Giugno 2021, 17:26 #17
Qualcuno ha provato questo dahliaOS?
kreijack18 Giugno 2021, 18:55 #18
Originariamente inviato da: lollo9
sul fatto che l'eleganza formale conti poco sono d'accordo visto che si parla di strati a così basso livello, scritti e testati da tantissima gente con competenze al top. deve prima di tutto funzionare.


Beh, deve essere anche facilmente manutenibile. Spezzare un kernel monolitico in più processi protetti tra loro (cosa che non mi sembra l'articolo abbia evidenziato), senz'altro aiuta.

Chi ha avuto esperienza sull'Amiga, ricorda perfettamente quanto fosse semplice accedere a tutte le strutture del suo OS (in quel caso non c'era alcuna protezione della memoria). Il prezzo da pagare fu una certa difficoltà dell'evolversi di AmigaOS perché per essere retro-compatibile non poteva cambiare più di tanto le strutture interne. Per la Commodore, anche il solo intervenire sull'HW era un problema per mantenere la compatibilità con quei programmi che accedevano direttamente ai registri delle periferiche.

Poi arrivarono (alle masse) i SO con protezione di memoria, e si ebbero due grandi vantaggi:
- i processi erano protetti tra di loro (e con l'hw)
- c'era un API ben definita (non si poteva accedere arbitrariamente al kernel, o per lo meno era molto più difficile)

Oggi il paragone è calzante: all'interno del kernel di Linux, è possibile accedere più o meno a tutte le strutture; questo consente una notevole flessibilità sviluppo al costo di fare danni.
Però appena le strutture interne cambiano, si rompe la compatibilità con i moduli out-of-tree.

C'è una importante differenza tra Linux e l'Amiga. Gli sviluppatori del kernel cambiano allegramente le strutture interne, e lo possono fare visto che il 90% dei driver sono già integrati in Linux. I driver out-of-tree (e.g. ZFS), sono considerati "cittadini di 2a classe", e "si devono adattare".

Chi usa in Linux i driver NVIDIA sa di cosa parlo.

Personalmente penso che un kernel monolitico sia più veloce da sviluppare. Ma mi aspetto che prima o poi crolli sotto la complessità di gestire (da un punto di vista dello sviluppo) la numerosità dei driver.

Un tempo pensavo che la differenza di prestazioni con i moderni processori tra un microkernel ed un kernel monolitico fosse trascurabile. Tanto alla fine nel 90% dei casi il processore "attende" un dato.

Ora con le moderne reti ed gli HD allo stato solido, non sono poi così sicuro.

Ovviamente se poi l'utente deve solo navigare con un browser, la latenza della rete è predominante.

Ciao
GB
blackshard18 Giugno 2021, 19:22 #19
Originariamente inviato da: jepessen
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)?


Ah mi spiace, sulla letteratura sono fermo a ciò che ho usato quando mi sono laureato, in particolare "I moderni sistemi operativi" di Tanenbaum (che sempre un lettura interessante) e altri che adesso perfino mi sfuggono tanto il tempo che è passato...
blackshard18 Giugno 2021, 19:45 #20
Originariamente inviato da: kreijack
Oggi il paragone è calzante: all'interno del kernel di Linux, è possibile accedere più o meno a tutte le strutture; questo consente una notevole flessibilità sviluppo al costo di fare danni.
Però appena le strutture interne cambiano, si rompe la compatibilità con i moduli out-of-tree.

C'è una importante differenza tra Linux e l'Amiga. Gli sviluppatori del kernel cambiano allegramente le strutture interne, e lo possono fare visto che il 90% dei driver sono già integrati in Linux. I driver out-of-tree (e.g. ZFS), sono considerati "cittadini di 2a classe", e "si devono adattare".

Chi usa in Linux i driver NVIDIA sa di cosa parlo.

Personalmente penso che un kernel monolitico sia più veloce da sviluppare. Ma mi aspetto che prima o poi crolli sotto la complessità di gestire (da un punto di vista dello sviluppo) la numerosità dei driver.


Secondo me bisogna fare dei distinguo.
Per come è organizzato Linux, succede quello che a cui hai accennato tu. Però non è una prerogativa dei kernel monolitici, quanto piuttosto del modo in cui Linux è sviluppato e gestito.

La compatibilità ABI di solito può cambiare ad ogni minor release (p.es da 5.10 a 5.11), ma questo non impensierisce i maggiori fruitori di sistemi Linux, che non sono gli utenti NVIDIA, bensì gente come Qualcomm, Broadcom, Freescale, etc...
Loro scelgono un kernel (solitamente uno LTS) e ci sviluppano sopra; lavorano su quello e solo con quello per lunghissimo tempo, infatti se guardi su qualsiasi telefono Android difficilmente troverai un kernel in versione 5.xx, buona parte sono ancora 4.xx o addirittura 3.xx (Il mio redmi 5 con Snapdragon 450 è su kernel 3.18)

Per i driver NVIDIA solitamente basta ricompilare il driver, altre volte cambia effettivamente l'ABI e serve mettere le mani nel codice; ma il fatto che l'ABI non sia stabile è una scelta di Linux di per se, non del kernel monolitico in generale, ed è dettata principalmente dal suo modello di sviluppo e dal suo target principale, che non sono i sistemi end-user desktop.

Sono anche piuttosto d'accordo che mettere tutti i driver sotto il grande ombrello Linux rende la cosa un pizzico problematica e poco gestibile alla lunga, ma bisogna anche tenere presente che, se sono cose grosse, la manutenzione la fanno generalmente le stesse aziende interessate sotto la supervisione di un "reggente".

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.
 
^