Newsgroup: it.comp.os.dibattiti
Titolo: Microkernel e kernel monolitici.

Qual'e' la differenza tra un 'microkernel' ed un kernel 'monolitico' ?
Scusate l'ignoranza.
Grazie.

 Scusate l'ignoranza.
Il microkernel contiene al più la gestione della memoria, dei processi
(ed eventualmente threads) e l'IPC.
tutti i drivers, filesystems, e altre cose che di solito si trovano nei
SO girano al di fuori del kernel, come processi, o come librerie
richiamate da altri processi.
I kernels monolitici, invece, come dice la parola stessa sono "tutti
d'un pezzo", nel senso che tutte le cose di cui sopra sono inscindibili
dal vero e proprio cuore del SO. Al massimo possono essere
"modularizzate", come avviene in linux ed in altri unix, ma una volta
caricati entrano a far parte attiva del kernel, essendo *in potenza*
pericolosi per la stabilità stessa del kernel: se c'è un bug in un
modulo ne risente tutto il kernel.
ciao,
Fabio Alemagna

librerie richiamate da altri processi.
Una cosa, pero`, mi sono sempre  chiesto: se i binari di questi processi
sono sul  filesystem... nel  microkernel dovra` per  lo meno  esserci il
codice del filesystem! Oppure c'e` un "escamotage" a cui non ho pensato?
(-:
-- 
  _      ___ ____
 | | /| / (_)_  /
 | |/ |/ / / / /_	ANTI-SPAM WARNING:
 |__/|__/_/ /___/	the e-mail address is fake.
 
Bianco e blu, neve e aria
Nella purezza di due soli colori,
tra cielo e terra c'è un mondo
dove esiste solo pace.             (Wiz)

 (-:
L'"escamotage" consiste nel caricare insieme sia il kernel, sia almeno
un filesystem. Nello stesso modo in cui carichi il kernel carichi pure
il filesystem, solo che una volta caricato il filesystem gira come
processo, non nel contesto del kernel. Ancora meglio se il sistema
operativo sta in ROM, come nell'AmigaOS: anche lì i filesystems sono dei
processi.
Quì puoi vedere come è strutturato QNX:
http://www.qnx.com/literature/nto_sysarch/intro.html#MICROKERNELARCH
Ciao,
Fabio Alemagna

Grazie a tutti per le risposte.
Continuerei con un altro quesito: ha senso prediligere un S.O. a
microkernel su macchine RISC piuttosto che su macchine CISC,
(intendendo per CISC solo la filosofia con cui ci si approccia in
assembler alla macchina) ?

 assembler alla macchina) ?
Se si considera la programmazione "assembly" (cioe` tu
che programmi in assembly) i RISC non hanno senso alcuno.
I RISC hanno senso se si considera la programmazione da
compilatore, cioe` da C.
Secondo me, se scendi a livello cosi` basso, cioe`
l'assembly, ha piu` senso considerare particolari
come la cache e la gestione della stessa.
Ad es. alcune CPU hanno la possibilita` di congelare
una parte della cache. In caso di uK (microkernel) puo`
essere utile questa feature, perche` consente di mantenere
in cache tutto il uK, cioe` la parte che richiede tempi
di risposta piu` bassi possibile (i.e. interrupt).
bye,
--
  Piergiorgio Sartor

compilatore, cioe` da C.
[slurp]
Questa tua affermazione mi sembra molto discutibile...
ciao, acc
a...@libero.it

 microkernel puo' stare tranquillo anche se non 'congeli' la cache.
Affatto, se hai ad es. 32KB cache programma ed esegui un SW
di 1MB puo` star sicuro che la cache viene ripulita del tutto
in un attimo.
"Congelare" la cache significa proprio bloccare tutto
li` dentro, evitando ogni dubbio sul fatto che altro
codice possa "scalzare" il vecchio.
bye,
--
  Piergiorgio Sartor

 Questa tua affermazione mi sembra molto discutibile...
Discutiamone...
bye,
--
  Piergiorgio Sartor

 Un caso interessante sono i processori VLIW, 
spiega di più di questi processori, per favore.
E dei processori sparc che mi sai dire?
Ciao
-- 
Non c'è più forza nella normalità: c'è solo monotonia.

 E dei processori sparc che mi sai dire?
Non molto, a suo tempo avevo il manuale Cypress degli
Sparc, che parlava maggiormente di HW che di SW.
Comunque erano loro che riportavano che il principale
vantaggio dei RISC sta nel fatto che e` facile avere
compilatori ottimizzanti, piu` facile che non nei CISC.
A questo riguardo non riportavano neanche l'assembly,
scrivendo che non vi era bisogno, dato che si sarebbero
utilizzati i compilatori.
Credo siano RISC abbastanza puri, prestazioni piuttosto
elevate (con relativi consumi elevati) anche e soprattutto
in FP, dove pero` vi erano strane discrepanze con l'FP
del Pentium (non buggato) come "qualita`" di risultati
(i.e. l'unita` FP del Pentium era piu` precisa).
bye,
--
  Piergiorgio Sartor


Il Crusoe della Transmeta e' un esempio di processore VLIW
-- 
Sidewinder  
---------------------------------------------------------------------
English literature's performing flea.
		-- Sean O'Casey on P.G. Wodehouse
---------------------------------------------------------------------

costo di produzione inferiore.
Be....a dire il vero io queste cose le ho studiate e mi sembra che
inizialmente la differenza tra un CISC ed un RISC fosse nell'adottare
una logica microprogrammata nel primo caso e completamente 'cablata'
nel secondo caso; questo portava ad avere piu' istruzioni con basse
prestazioni nel primo caso e meno istruzioni ad alte prestazioni nel
secondo caso, in pratica due filosofie diverse che (almeno
inizialmente) non seguivano una logica economica, e le CPU piu'
costose erano RISC, almeno per cio' che riguarda il mondo dei medi e
grandi elaboratori.
Con quanto viene dopo sono d'accordo, anzi mi e' stato chiarificante.

Ho qualche dubbio sulla validita' della filosofia VLIW: l'unico vero
vantaggio sta nel fatto che, avendo a disposizione istruzioni piu'
lunghe e flessibili ve ne saranno meno (numericamente) nel codice
assembly prodotto dal compil. che, inoltre, dovra' stare molto attento
alla sequenza in cui le mette e quest'ultimo fatto equivale ad
ottimizzare un compilatore il che puo' essere fatto anche per altre
architetture.
Il problema e' che ottimizzare per CISC porta a miglioramenti non
troppo evidenti mentre nel caso del VLIW i miglioramenti si vedono
molto.
Ultimamente, pero', i processori RISC hanno molte unita' di esecuzione
le quali, fra l'altro, sono anche molto potenti, quindi e' possibile
ottimizzare molto i compilatori anche per questa architettura e penso
che ragionandoci un po' si riesca ad ottenere qualcosa di piu' che con
i VLIW, ma non ho voglia di ragionarci per cui finisco qui.
Sono accetti pareri vari.

 i VLIW, ma non ho voglia di ragionarci per cui finisco qui.
Come ho scritto sopra e` questione di costi, l'area di silicio
necessaria per un RISC o per un CISC e` enormemente superiore,
tutto qua, niente di piu`, niente di meno.
bye,
--
  Piergiorgio Sartor

 grandi elaboratori.
Il fatto di avere logica cablato o microprogrammata non cambia
il tipo di processore.
Cioe` un CISC puo` essere dei due tipi, cosi` come un RISC, anche
se nel secondo caso e` piu` difficile.
Se ci atteniamo alle definizioni:
Complex Instruction Set Computer == CISC
Reduced Instruction Set Computer == RISC
con l'estensione:
Reduced Instruction Set Cycle == RISC
In questo secondo caso ci cascano molte CPU, tra cui
anche gli attuali P-xyz.
Per quel che riguarda il costo, ti assicuro che e` proprio
cosi`, fu una valutazione iniziale di HP, che voleva produrre
una propra CPU e valuto` la migliore soluzione, all'epoca...
bye,
--
  Piergiorgio Sartor

 Cioe` un P xyz che costa 500.000 lire verrebbe a costare 50.000.
scusa,  ma ci  sono  processori in  vendita di  questo  tipo? Mi  spiego
meglio:  esistono  dei  compter  in  vendita che  si  basino  su  questi
processori?


 processori?
Non ancora, la tecnologia in questione e` usata da poco.
Come sempre partendo da settori periferici (se cosi` si puo`
dire), come i DSP (ricordiamoci che i DSP tradizionali possono
essere visti come dei RISC).
In questo caso, essendo lo spazio dei problemi relativamente
limitato, si puo` progettare un core efficiente per risolvere
bene (ed a basso costo) quei problemi.
Il progetto IA-64 (Itanium) e` il primo tentativo di portare
i VLIW a livello piu` general purpose.
Ci riusciranno? Non so, vederemo.
E` possibile? Forse si, tutto girera` attorno al rapporto
cost/prestazioni, se riescono a fare un buon lavoro puo`
essere che le prossime generazioni di CPU saranno VLIW.
bye,
--
  Piergiorgio Sartor

processori?
I futuri thinkpad ibm basati sul transmeta crusoe
-- 
Sidewinder  
---------------------------------------------------------------------
Too much is just enough.
		-- Mark Twain, on whiskey
---------------------------------------------------------------------

 processori?
Scusa dimenticavo la prima domanda.
Si ci sono processori in vendita di questo tipo, come
scritto altrove, soprattutto tipo DSP o simili.
Quindi, ad es., senza MMU.
Sui link che ho postato, quello TI, ci sono anche i
prezzi per le varie versioni, pare.
bye,
--
  Piergiorgio Sartor

essere che le prossime generazioni di CPU saranno VLIW.
Qualche tempo fa si parlava di $4000 per un sistema Itanium.
Non credo che nel breve e nel medio periodo sia una soluzione
conveniente, anche perche` quando Itanium si affermera` sara`
uscito l'Alpha 21364 :-)
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(address rot13 encoded)

Comunque vorrei tornare al secondo argomento trattato:
Se io volessi sviluppare un OS a microkernel e potessi scegliere due
tipi di CPU sulle quali farlo girare: una RISC (come le attuali
motorola G4) ed una CISC (come le attuali x86, intendendo per CISC
quello che si vede da fuori) che a grosso modo possono fornirmi
prestazioni simili se programmate in modo ottimale la mia scelta
cadrebbe su RISC.
Se invece dovessi sviluppare un OS a kernel mono. la mia scela sarebbe
CISC.
Il motivo ti tale scelta e' molto astratto e non tiene in
considerazione molti fattori tecnici: 
-la filosofia dei RISC e' quella di avere un gran numero di piccole
istruzioni eseguite molto velocemente;
- la filosofia dei CISC e' quella che predilige la possibilita' di
avere poche istruzioni complicate e di poterle eseguire piu'
'lentamente' rispetto alla precedente.
Un microkernel ha un'idea di fondo che assomiglia molto a quella del
RISC mentre un kernel monolitico ha un'idea di fondo piu' simile a
quella del CISC:
-il microkernel e' un piccolo sistema molto veloce che svolge poche
operazioni ma le 'chiamate' a questo sistema sono molto piu' frequenti
perche' i processi sono in maggioranza esterni ad esso.
-il kernel monolitico e' un sistema che deve svolgere un gran numero
di operazioni che risultano inevitabilmente piu' lente di quelle del
precedente, pero' ha il vantaggio di poter rispondere con maggior
ritardo alle chiamate esterne in quanto quest'ultime sono inferiori
numericamente.
Il principio molto astratto e' questo: i due modi di pensare visti
sopra sono complementari e se dovessi costruire un sistema lo farei
con pezzi simili o uguali fra loro e non complementari: l'ingresso' di
un pezzo e' gia' complementare alla sua uscita, per cui pezzi
complementari hanno ingresso ed uscita anticomplementari (simili o
uguali) e non permettono una unione felice.
Chiaramente un principio del genere potrebbe fare un po' ridere a chi
lavora nel settore perche' esisto molti problemi pratici che fanno le
effettive differenze ma   "se tutto fosse teorico la teoria avrebbe
senso pratico".
Ciao.

senso pratico".
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy


 uguali) e non permettono una unione felice.
Non ci siamo.
Per poter far un uK (micro kernel) decente, serve il supporto HW,
cioe` della CPU, per alcune cosette, quali:
HW semaphore
HW queueing
Fast Contex Switch
Backup Register Set (opzionale, ma meglio se c'e`)
Questo e` assolutamente indipendente dal modello di
programmazione della CPU, RISC, CISC, VLIW o quello che
ti pare.
Capisco che il modello "frattale" sia attraente, ma le case
si costruiscono con i mattoni, non con piccole casette.
bye,
--
  Piergiorgio Sartor

 Ho qualche dubbio sulla validita' della filosofia VLIW: l'unico vero
L'idea del VLIW secondo me e' questa: ormai al giorno d'oggi si possono
mettere tantissimi transistor in una CPU e quindi si possono mettere
tante unita' intere e/o floating point e/o speciali. L'ISA si deve
quindi adeguare con delle istruzioni che riforniscano in continuazione
queste unita' e che siano semplici da decodificare perche' nei CISC
ormai il collo di bottiglia e' il tempo di decodifica delle istruzioni e
di ricerca delle dipendenze, operazioni che non si possono
parallelizzare (infatti l'ultimo trucco dell'Intel nel Willamette e'
quello di utilizzare una cache con le istruzioni _gia'_ decodificate e
riordinate). 
Io personalmente preferisco avere una CPU con una unita' di decodifica
semplice e due o tre unita' intere in piu' che il contrario. Tanto anche
se il compilatore ci mette delle ore non c'e' problema in quanto il
lavoro lo fa una volta sola.
Mario Giammarco
mgiam...@cs.unibo.it



Be..... io ripeto che tutto questo 'casino' nei processori con
filosofia RISC non viene neanche affrontato perche' non ve ne e' il
bisogno.
OK devono mandar giu' molte piu' istruzioni per unita' di tempo, ma
questo e' un problema gia' superato.

--
In fondo la mia era solo una supposizione molto astratta per poter
scegliere tra l'uno o l'altro dei supporti hardware con un minimo di
criterio, se poi tu dici che e' completamente indifferente allora ti
attieni alla teoria classica.

 istruzioni>.
una volta ne avevano poche, ora.. guarda i PPC...
Ciao,
Fabio Alemagna

 attieni alla teoria classica.
Direi che dipende molto dal problema.
Allo stato attuale direi che RISC va bene, e` sicuramente
una tecnologia piu` moderna dei classici x86.
bye,
--
  Piergiorgio Sartor

riordinate). 
Il trucco e` vecchio, gia` il K6 ce l'aveva.


una volta ne avevano poche, ora.. guarda i PPC...
Sono relativamente tante ma tutte buone, perche` sono ortogonali.


 Sono relativamente tante ma tutte buone, perche` sono ortogonali.
Non relativamente, ma assolutamente :)
Non sto criticano, comunque. Quello che voglio dire che ormai della
concezione originaria dei processori RISC è rimasto poco.
Oggi i risc hanno queste caratteristiche:
* le istruzioni lavorano solamente su registri, tranne quelle dedicate
proprio alla memoria.
* le istruzioni hanno tutte la stesa lunghezza
Ciao,
Fabio Alemagna

 questo e' un problema gia' superato.
Il problema da risolvere pero' e' questo: hai 25 milioni di transistor
da riempire, cosa ci metti dentro? Tante unita' intere e floating point?
E come le riempi?



Be non capitera' mai che io progetti un processore, ma se prorio
dovessi, direi che converrebbe mettere tante unita' parallele quante
ritengo siano utili, cercando di risparmiare transistor il piu'
possibile, facendo quindi un layout tale da consentire la maggior
velocita' possibile.
Ti ricordo che piu' piccola e' l'area di silicio piu' basse sono le
probabilita'di errore nella produzione, e quindi piu' in basso posso
spingermi con le dimensioni dei transistor e, di conseguenza, piu'
alta sara' la freq. a cui posso far lavorare il mio processore.
Ciao.

 alta sara' la freq. a cui posso far lavorare il mio processore.
IMHO si può usare anche l'approccio inverso, aumentando il numero delle
unità e tenendo bassa la velocità di clock, il risultato non cambia.
Anzi, l'aumento della frequenza tende a creare nel tempo benefici sempre
minori (all'interno della medesima architettura),c ome già discusso
abbondantemente nel NG, mentre migliorare l'architettura stessa porta
senz'altro maggiori benefici, epperò costa di più.
Neno.