Newsgroup: it.comp.os.linux.development
Titolo: kernel monolitico o microkernel?

--
Salve a tutti,
spero che riusciate a chiarirmi alcuni concetti sulla differenza tra kernel
monolitico e microkernel. Linus Trovalds so che ha sempre fatto il tifo per
i kernel monolitici e che al momento della nascita di Linux subì non poche
critiche proprio per aver scelto un kernle monolitico invece di un
microkernel. Poi dalla versione 2 del kernel è possibile caricare
dinamicamente i moduli. Questo dovrebbe significare che il kernel è
diventato microkernel, eppure è anche possibile includere tutti i servizi
direttamente nel kernel e non come moduli. Quindi? Come va considerato il
kernle di Linux?
Ma poi questi moduli sono effettivamente la stessa cosa di un driver in
ambiente windows oppure ci sono delle differenze?
Grazie a tutti.

ambiente windows oppure ci sono delle differenze?
Una Ferrari e' un'automobile come una Punto, pero' ci sono delle
differenze.

 ambiente windows oppure ci sono delle differenze?
Non sono molto esperto, anche se mi interesso di programmazione... pero' non
mi sono ancora interessato a fare un sistema operativo :):)
Comunque, in linea di massima i driver (almeno secondo la definizione
comune) non sono esattemente come i moduli.
I driver, sono comunque un eseguibile esterno che comunica al kernel la zona
di memoria, in cui può trovare la periferica, ed hanno il vantaggio che una
volta compilati, li puoi portare in un sistema equivalente senza per questo
ricompilarli, mentre mi risulta che questo sia impossibile in un Kernel
linux.
Sebbene le ditribuzioni, installano un Kernel già compilato, in realtà hanno
ovviato al problema, compilando tutti le parti del kernel linux (a parte le
fondamentali), come moduli, per cui, caricano di volta in volta, solo i
necessari.
Però se io ho un kernel compilato con le opzioni che voglio io, dubito che
posso andare a prendere un modulo compilato di un altro kernel, e sperare
che funzioni.
Questo perchè in fase di compilazione, il Kernel linux, sà che ha a
disposizione un modulo che può essere caricato o meno.

 monolitico e microkernel.
microkernel:
le sezioni critiche del kernel sono ridotte per evitare il fenomeno del
software lockout nei sistemi multiprocessor

 software lockout nei sistemi multiprocessor
scusate ho scritto una fessereia
la definizione di sopra è riferita a sistemi a nucleo minimo
microkernel? cosa significa questa parola ?
mi sforzerò a dare una definizione mettendolo in contrapposizione con il
kernel monolitico:
nel modello monolitico le funzioni di gestione delle risorse sono realizzate
nel nucleo.
L'alternativa (microkernel?) consiste nell'utilizzare i processi medesimi
per svolgere le funzioni di gestione, mentre nel kernel si limita a
realizzare le funzioni essenziali riguardanti i processi (scheduling,
paradigmi di comunicazione inter-processo)
anche se spesso il termine microkernel ci si riferisce a s.o.(monolitici o
meno) utilizzati in piccoli dispositivi...  cell, palmari,ecc
che microkernel significa che occupa poca memoria?

 Grazie a tutti.
ciao
   Andrea Pollini

paradigmi di comunicazione inter-processo)
Unico appunto: spesso un microkernel ha lo scheduler esterno, e inserito
come processo a priorita' e privilegi elevati. 
-- 
"Unix is user friendly, it's just selective 
about who its friends are."

sponsorizzate per ricercare in questo campo.
Fu un thread su comp.os.minix, e Torvalds non dice questo.


non ricordo bene cosa, qualcuno ha in giro quei post "storici"?
In realta' tutto nacque da un post di Andrew Tanenbaum, un
conosciutissimo professore di Computer Science alla Vrije
Universiteit di Amsterdam e grosso esperto di sistemi
operativi, nonche' inventore di Minix.
Egli scrisse (nel Gennaio del '92) un post su comp.os.minix,
che gia' dal subject si annunciava abbastanza provocatorio
("LINUX e' obsoleto"), nel quale descrisse le differenze tra
kernel monolitico e microkernel, concludendo che tra coloro
che progettano i moderni sistemi operativi la scelta e' gia'
definitiva, ovvero "il microkernel ha vinto".
Gli parve anche opportuno affermare che progettare Linux era
una idea misera per quei tempi e che (paragone scritto da
lui) progettare un sistema monolitico negli anni '90
significava tornare indietro di 20 anni ("E' come prendere
un programma C e riscriverlo in BASIC").
Ovviamente una provocazione del genere (forse neanche
voluta, visto che si stava parlando in un ng dedicato a
Minix) fu raccolta in pieno da Torvalds che rispose in modo
piuttosto ostile.
Visto che aveva tratto spunto da Minix per progettare il suo
Linux, poteva fare a meno di affermare che Minix fosse
"cerebroleso" e che Linux gli fa le scarpe in tutto e per
tutto.
In ogni caso, era d'accordo sul fatto che i so a microkernel
fossero migliori e ammetteva i molti limiti (per allora) del
suo sistema operativo, benche' ritenesse Minix ancora piu'
limitato.
Ovviamente il dibattito ando' altalenando, tra frasi
spocchiose di Tanenbaum ("Ringrazia che non sei un mio
studente. Non otterresti un punteggio alto per una tale
progettazione :-)") e frasi piu' o meno "insolenti" di
Torvalds.
Tra parentesi, tra i vari interventi ci furono diversi
autorevoli autori, tra cui Ken Thompson (co-inventore di
UNIX) il quale si espresse affermando che l'essere obsoleto
di un software (rifacendosi al subject di Tanenbaum) non e'
poi cosi' correlato all'utilita' dello stesso.
Affermava che, per quanto vero fosse che i microkernel
andavano spazzando via i monolitici, questi ultimi erano
piu' facili da implementare.
Tutta la discussione si spinse sul piano della portabilita'
dei sistemi operativi (Tanenbaum non riteneva Linux
abbastanza portabile) e sulla natura (monolitica o
microkernel) degli stessi, senza raggiungere mai un punto
d'accordo (ovviamente).
Probabilmente l'errore piu' grosso di Linus (che si e'
scontrato con uno dei colossi della ricerca nel campo dei
sistemi operativi) e' stato quello di non capire che Minix
e' un sistema operativo didattico, mantenuto a livelli
estremamente semplici, proprio per essere meglio compreso.
Probabilmente non meritava attacchi cosi' duri.
In ogni caso, sarebbe interessante sentire il parere di
Tanenbaum ai giorni nostri :)
--
Andrea Laforgia (mica uno qualunque...)

 ha scritto nel messaggio
news:slrn9p4046....@localhost.localdomain...


 come processo a priorita' e privilegi elevati.
domanda se lo scheduler è un processo...
chi effettua lo scheduling  del processo scheduler?
"processo a priorità e privilagi elevati" da chi viene definito così?
processo scheduler stesso o dal kernel?

chi effettua lo scheduling  del processo scheduler?
Domanda: se il sistema operativo gestisce l'allocazione della RAM, come
fa ad allocarla per se stesso? :)


 fa ad allocarla per se stesso? :)
il s.o. non è un processo...
o meglio è presente in ogni processo (le routine,strutture dati del kernel
sono presenti nello spazio di indirizzamento di ogni processo)
e adesso rispondi alla mia domanda chi effettua lo scheduling  del processo
scheduler?

scheduler?
Con il cazzo che rispondo, il tuo tono e' un pochino troppo pretenzioso
per i miei gusti. E la risposta e' scritta nella domanda di cui sopra,
sforzati che non puo' che farti bene.


Con il cazzo che rispondo
Uela' ... non sarebbe il caso di una camomilla ? :)


 sforzati che non puo' che farti bene.
ma tu non mi rispondi... o forse non hai l'umiltà per dire non lo so
rispondi a questa
il descrittore del processo scheduler dove si trova?

 ha scritto nel messaggio
news:3b955d4b...@news.tin.it...


 sforzati che non puo' che farti bene.
a parte che il tono mi pare un po' troppo arrogante, cmq anche a me era 
venuto lo stesso dubbio, quindi provo a riformulare la domanda in maniera 
piu' cortese, se e' questo che vuoi:
hai detto che lo scheduler e' un processo con elevata priorita': ma la 
priorita' e' un attributo che serve allo scheduler per decidere ogni quanto 
richiamare i processi, quindi come puoi vedere e' un serpente che si morde 
la coda. Domanda: come fa il kernel a richiamare lo scheduler (un processo 
come gli altri) se e' lo scheduler a richiamare i processi?
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

dimostratot) di poter scrivere un Minix migliore.
Be', scrivere un Minix migliore, per le motivazioni gia'
dette (Minix e' un sistema didattivo) non era poi cosi'
difficile.  Il post iniziale, comunque, che ha avviato il
dibattito, fu di Tanenbaum che era appena tornato dagli
Stati Uniti.


come gli altri) se e' lo scheduler a richiamare i processi?
Il kernel richiama lo scheduler:
- ogni quanto di tempo;
- ogni volta che una syscall imposta apposita variabile;
Cioe' quello che e' esterno al kernel e' la politica di gestione dei
processi, ma il kernel sa che esiste uno scheduler.


il descrittore del processo scheduler dove si trova?
In Linux non esiste, nei sistemi a microkernel non serve. Il fatto che
tu stia parlando di questo conferma che non hai capito di cosa stiamo
parlando. 


 processi, ma il kernel sa che esiste uno scheduler.
secondo te... fammi indovinare... in windows lo scheduler č il taskmanager?

 parlando.
stiamo parlando... chi siete tu ... il tuo cervello... e il tuo amico
immaginario?
ma voglio capire
allora riepilogo la tua archittetura
il kernel è un processo in comunicazione con altri processi  lo scheduling è
svolta da un'altro processo... in introdurrei anche processo gestione
memoria... per allocare la memora...(visto che hai un fissa sulla cosa)
cmq il kernel sa dove sono... non si sa come ma lo sa...
infatti esiste la chiamata knonsochecavolodiprocesso() che ristuisce un
puntatore struttura dati chiamata
questoanchesepuosembrareundescrittorenonloè
sbaglio qualcosa?

sbaglio qualcosa?
Tutto, e non ho tempo da perdere, per cui cerca di essere costruttivo.


secondo te... fammi indovinare... in windows lo scheduler č il taskmanager?
Addio.


 informatici fa comodo pensare che esista.
adesso non si parla + di architettura di sistemi operativi
ma di impianti... impianti di riscaldamento.... inpianti elettrici...
idraulici... no!
impianti informatici!!!! wow

 Addio.
"Ramon al cuore ... Ramon mira al cuore..."

 Addio.
"Ramón al cuore ... Ramón mira al cuore... non ci riesci Ramón?! cosa ti
succede Ramón?"

"Ramon al cuore ... Ramon mira al cuore..."
Potreste continuare per e-mail ? 
Grazie.


succede Ramón?"
BASTAAAAA !!!


 kmalloc!!!!"
Basta. Ne' a me ne' agli altri frequentatori interessa questo battibecco.
Anyway il descrittore del ps scheduler non esiste perche' lo scheduler non
e' un processo ma parte del kernel. Cmq una buona introduzione allo
scheduler la trovi in Linux Kernel Internals, pag 19.
Il capitolo gratis di Understanding The Linux Kernel e' appunto quello dello
scheduler.
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
           -<! Failure is not an option...it's bundled with Microsoft !>-


Io , io , voglio rispondere io ... :)
Allora :
Lo scheduler , che in un microkernel e' un processo a livello utente ,
decide in base alla priorita' quale processo lanciare , quindi manda
un messaggio al loader , che gira a livello kernel , e che quindi
puo' avere pieno accesso all'hardware , dicendo fai partire il processo
pippo .
Il loader conserva i dati del processo attualmente in eseguzione
(lo scheduler , e questa e' la risposta alla tua domanda) e poi fa partire
il processo pippo .
Quando pippo termina il controllo ritorna al loader , che ripristina il
processo di cui aveva conservato i dati , ovvero lo scheduler , che
continua a fare il suo lavoro .
Lo scheduler non ha priorita' , o ha la priorita' piu' elevata , mettila
come vuoi , la sostanza non cambia ...
Ciao


Vedi please la mia risposta ad Antonio Cuni , stesso 3D , vorrei
sapere che ne pensi ...