Newsgroup: it.comp.os.dibattiti
Titolo: Perchè venne scelto un kernel monolitco?

Mi chiedo, alla luce delle recenti critiche portate da alcuni user di questo
ng al kernel di Linux, il perchč Linus Torvalds scelse un'architettura
monolotica al posto di quella microkernel.
Poichč, a quanto pare, architetturalmente parlando il kernel di Linux non č
dei migliori: si sta pensando di riprogettarlo oppure no? Chi dovrebbe
prendere questa decisione? Se effettivamente l'attuale architettura del
kernel crea problemi, in che modo ciņ potrą ripercuotersi in futuro?
Nessuno sta facendo valutazioni del genere?
Attendo vostre risposte.
Grazie.
-- 
Jenny ti voglio bene e ti amerņ per sempre

 un'architettura monolotica al posto di quella microkernel.
Perchè è la strada più semplice e nel contempo quella che fornisce
un buon rapporto funzionilità/prestazioni.
Ed un micro-kernel è per ora troppo complesso da gestire senza
uno staff di buoni architetti.
Saluti.

Gabriele Del Giovine wrote:


Quoto.
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 Saluti.
Quindi LInux non ha alle spalle gente con esperienza nell'architettura
microkernel? Oppure non c'è uno staff perfettamente coordinato a lavorare
sul kernel?
Se non sbaglio i vari sviluppatori del kernel di Linux lavorano per le
società più disparate, e comunicano tra di loro sfruttando la rete - email,
ml e via dicendo.
Questa secondo te è una limitazione pesante nello sviluppo di un
microkernel?
E, comunque, un microkernel in quanto tale non dovrebbe essere più semplice
da progettare e scrivere?
Scusa le molte domande, ma non sono esperto nel campo anche se questo
argomento mi affascina.
-- 
Jenny ti voglio bene e ti amerò per sempre

 monolotica al posto di quella microkernel.
Perche` funziona, a differenza, purtroppo, dei uK.
bye,
-- 
piergiorgio

> Perche` funziona, a differenza, purtroppo, dei uK.
Non ho capito. I micro non funzionano? E QNX allora?
-- 
Jenny ti voglio bene e ti amerò per sempre


Aggiungerei: e BeOS? (parlandone da vivo ovviamente)
Ma non glielo ricordare.... La verità fa male....
Saluti
Vegeta

 Non ho capito. I micro non funzionano? E QNX allora?
Hai mai visto QNX su di un server o su di un desktop?
bye,
-- 
piergiorgio

 Ma non glielo ricordare.... La verità fa male....
Dimmi un uK general purpose, che sia usato, si intende.
bye,
-- 
piergiorgio

 da progettare e scrivere?
Il problema più grande sono le performance. Comunque, ti
consiglio di dare un occhiata a questo:
http://www.cbbrowne.com/info/microkernel.html
Interessante la tesi che i microkernel falliscono perchè si
tenta di emulare le funzionalità di Unix.
In effetti, i microkernel che funzionano veramente bene
(BeOS e QNX) non sono degli Unix.


BeOS sarebbe stato l'ideale.
QNX se avesse più supporto lo potrebbe essere
benissimo.
Che ne pensi di Mac OsX?
P.S.
Una considerazione: il microkernel *puro* effettivamente
non funziona.
Ma i sistemi operativi che fanno dei compromessi (cioè
microkernel salvo qualche componente che si mantiene
in kernel mode per ragioni di prestazioni), sembrano
funzionare molto meglio di Linux. Ecco perchè ti
citi il kernel darwin derivato da Mach che gira sotto
Mac OsX.
Saluti
Vegeta

 non funziona.
Scusa perchè non funziona?
QNX non è microkernel puro?
Cmq per rispondere a P.Sartor: forse il microkernel è più difficile da
implementare rispetto al monolitico ed in ambito desktop non ve ne è la
necessità.


 non funziona.
hai mai visto pistachio? Funziona eccome, casomai potrai dire che non fa
molto, perché poveretto, è un microkernel.

 (BeOS e QNX) non sono degli Unix.
ma hai mai visto l'homepage di qnx? 
La prima cosa che ti dicono è che è posix compliant e che implementa le
specifiche unix.

 Mac OsX.
Sembrano? Abbiamo numeri o cosa?
Allo stato attuale, in termini prestazionali, per applicazioni
generiche, il kernel monolitico presenta vantaggi indubbi.
Che poi uno specifico kernel possa essere fatto male o bene,
indipendentemente dall'architettura, questo e` un'altra storia.
Come diceva l'autore di irqtune, una Ferrari non messa a punto
e comunque piu` veloce di un maggiolino perfettamente regolato.
bye,
-- 
piergiorgio

 necessità.
Ed in ambito server?
Comunque si, alla fine e` piu` difficile da _implementare_ e
non e` neanche detto ne valga la pena in generale.
Certo il design e` molto attraente e merita considerazione.
Il problema principale, gia` detto qui diverse volte, e` che
le CPU *non* sono ottimizzate per uK, cioe` non forniscono
un sopporto decente per le condizioni di lavoro di un uK.
Detto cio`, se segui lo sviluppo del kernel Linux, noterai
come l'evoluzione vada per quella strada, cioe` come sempre
piu` pezzi del kernel vengano spostati in user space, oppure
resi modulari nel kernel (kernel thread).
bye,
-- 
piergiorgio

 specifiche unix.
invece sulla home page di Vegeta dicono che e` implementa le specifiche
TROLL 2.0 :)))
-- 
RiK0
 Il sonno del teschio genera troll, e il quoting li manifesta.

 da progettare e scrivere?
No. E` molto complesso, perche` consiste di piu` parti che devono
comunicare fra loro con messaggi. E se scritto male porta chiaramente
degli overhead da paura.
Anche scritto bene puo` essere piu` 'lento' di un kernel monolitico.
Ragion per cui oggi spesso si adotta un microkernel 'parziale' (XNU,
Windows, NeXT -- mi pare -- ).


 Non vorrei correlare la sua morte con la sua architettura.
La sua morte e` dovuta ad altre ragioni... non certo alla qualita` del
progetto.



A)bort, R)etry, I)nfluence with large hammer.

 progetto.
Puo` essere, ma anche no... :-)
bye,
-- 
piergiorgio

 TROLL 2.0 :)))
rotfl :-))))))))

 sconvolgere il codice.
Attenzione, non facciamo confusione: un kernel modulare e'
sempre un kernel monolitico. Al piu', se parliamo di kernel
threads, possiamo essere piu' vicini a determinati concetti.


 ma hai mai visto l'homepage di qnx? 
Se e' per questo anche BeOS e' (era?) POSIX compliant
Henryx

 Puo` essere, ma anche no... :-)
Prima che Be morisse, BeOS era semplicemente adorato da tutti. Questo
vorrà pur dire qualcosa...
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 vorrà pur dire qualcosa...
Che e` un grande rimpianto ma morto comunque :P
-- 
Valentino Volonghi aka Dialtone
Linux User #310274, Proud Gentoo User
Blog: 
http://vvolonghi.blogspot.com
Home Page: 
http://xoomer.virgilio.it/dialtone/

 usarlo in applicazioni diverse dall'embedded?
E se invece la gestisce?
Saluti.

 Che e` un grande rimpianto ma morto comunque :P
Senza dubbio, ma qui si insinua che sia morto per via della sua
architettura.


 architettura.
Probabile. Quello che Piergiorgio voleva dire, immagino, e` che non
importa che architettura fosse, e` morto e basta, per cui non vale come
esempio di 'bellezza' di un uK.


threads, possiamo essere piu' vicini a determinati concetti.
Sě, ma se usi i moduli caricabili a runtime hai, in ambito monolitico,
la migliore approssimazione possibile del microkernel, per lo meno da
un punto di vista "filosofico" (Ovvio che architetturalmente siamo
lontanissimi...).

 lontanissimi...).
Bofh, la migliore approssimazione... Stai "attaccando" un pezzo di
kernel che andra' a ring 0, relinkando dinamicamente il modulo nello
spazio di indirizzamento del kernel. Non stai lanciando un server di
ambiente che operera' come processo sul microkernel, in user mode...
Apposta dicevo che i kernel threads si assomigliano un po' di piu',
seppure ancora abbastanza alla lontana.


 esempio di 'bellezza' di un uK.
Argomentazione decisamente pretestuosa, mi sembrano concetti del tutto
slegati :-). Come puoi fare un'equazione "bellezza = longevità"?
Ma, bada bene, io in questo discorso non ho intenzione di entrare, perché
si finisce sempre per ripetere i soliti luoghi comuni (ossia: i
microkernel sono inefficienti; ma poi nessuno dice quanto e perché non
possono essere migliorati più di un tot). Con questi presupposti, si
possono dire solo sciocchezze, quindi io mi asterrò.
Saluti.


 non è dei migliori:
adesso sono tutti praticamente uguali, in realtà. Il kernel è un 
problema risolto, adesso si guarda avanti