Newsgroup: it.comp.os.dibattiti
Titolo: Che fine ha fatto il microkernel?

 and kernel crashes in the beta have been infrequent.
Si ricollega ad alcune cose dette in questo gruppo a propostio dei 
microkernel. A questo punto il kernel del BeOS e' diventato un po' meno 
microkernel... o cosa?
Ciao

 microkernel... o cosa?
Così sembrerebbe... Ma credo che questo modo di fare non sia l'unico per
ottenere migliori prestazioni...
Voglio dire che non c'è per forza bisogno di utilizzare un processo
separato per lo stack di rete... basterebbe una libreria e tutto il
tempo perso nel taskswitching sarebbe evitato.
E resterebbe comunque un microkernel... Ma in ogni caso quello del BeOS
non è mai stato un vero microkernel
Ciao,
Fabio Alemagna

tempo perso nel taskswitching sarebbe evitato.
Eh? Credo che tu non abbia capito qualcosa riguardo a IP.
Come faresti a gestire il protocollo una volta che il programma che
usava il socket e` terminato?
E comunque servirebbe sempre un demone per gestire cose come ICMP.
-- 
ciao, |
Marco | "You're one of those condescending Unix computer users!"
      | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 E comunque servirebbe sempre un demone per gestire cose come ICMP.
Ma in quel caso il demone esiste in qualsiasi implementazione.
Saluti,
Fabio Alemagna

 Non proprio.
Mettetevi d'accordo allora
Saluti,
Fabio Alemagna

Se mi spieghi cosa intendi forse ti posso dare una risposta.
Mica facile se non sai come funziona TCP.
Comunque, ci sono delle cose da fare dopo che un programma ha finito di
usare un socket TCP, che normalmente fa il kernel.


 usare un socket TCP, che normalmente fa il kernel.
Normalmente lo fa il kernel... lo può fare solo il kernel od un processo
separato?
Sto chiedendo perchè non lo so. E vorrei saperlo, se non ti/vi scoccia
troppo dirmelo.
Saluti,
Fabio Alemagna

 Ma in quel caso il demone esiste in qualsiasi implementazione.
Non proprio.
--
Bye
Gianluca Zanelotto
Ducati ST2 "Red Devil"

 Mica facile se non sai come funziona TCP.
Non gli confondere la testa. Prima gli parli di IP, ora ti sposti su TCP.
Saluti.

 non è mai stato un vero microkernel
In che senso?

troppo dirmelo.
Vuoi un corso di TCP completo?


 Vuoi un corso di TCP completo?
No, stavo solo chiedendo delucidazioni su questo punto.
Vedi, su amiga il tutto è gestito tramite una libreria, quindi in
qualche modo si pò fare... Ma forse mi sfugge qualcosa.
Ciao,
Fabio Alemagna

Vedi, su amiga il tutto è gestito tramite una libreria, quindi in
Evidentemente si tratta di un concetto di libreria molto diverso da
quello di unix.


 quello di unix.
Ovviamente mi riferisco alle librerie condivise.
Ciao,
Fabio Alemagna

Ovviamente mi riferisco alle librerie condivise.
Allora non vedo come potrebbe funzionare TCP.


 Allora non vedo come potrebbe funzionare TCP.
In realtà il demone c'è pure lì, ma le applicazioni interagiscono con
una libreria.
Ciao,
Fabio Alemagna

In quel caso lo si puņ demandare il compito al demone... 
Se il programma viene ucciso con -9 come fa il demone a sapere che deve
fare qualcosa?


tempo perso nel taskswitching sarebbe evitato.
Mica vero. Tutte le funzioni di arbitraggio dovrebbero essere
centralizzate. I timeouts (per TCP) anche. Le reply, su porte
non aperte (TCP e UDP), se nessun programma le richiede, mica
le puo' mandare Pipone.
Quindi si', basta una libreria, ma poi la libreria se la deve
puppare il kernel. O un daemon permanente kernel level. Nell'
un caso e nell'altro, lo potremmo chiamare "modulo".
E abbiamo, che so, il modulo net-pf-10 :-)
Leonardo back to square one
Microsoft Outlook: R: Re: R: Re: R: Re: R: cosa vuoi replicare oggi?

 fare qualcosa?
Be', in effetti non ci avevo pensato... ma si potrebbe fare in maniera
tale che il kernel sia a conoscenza della presenza di un demone dedicato
allo stack di rete.
Mi spiego:
1) il demone si registra come "fornitore di servizi di rete".
2) il kernel viene a conoscenza della presenza del demone
3) il programma che usava la rete viene ucciso
4) il kernel allora invia la richiesta al demone di completare le
operazioni che bisogna effettuare in questo caso.
5) se il programma semplicemente non stava usando la rete il demone non
fa niente.
Questo potrebbe essere un modo...
Saluti,
Fabio Alemagna

 Questo potrebbe essere un modo...
Si, ma dove stanno le informazioni sullo stato della connessione
associato al programma?
Cioe` il demone sa, per ogni programma, in che stato e` il TCP/IP?
O lo sa il kernel?
Se lo sa il demone, vuol dire che questo prende parte attiva alla
gestione della connessione, i.e. ogni "variazione" dello stato gli
deve essere comunicata (per ogni processo).
Se lo sa il kernel... Stesso discorso, solo che invece di comunicare
ad un task si deve farlo con lo scheduler, i.e. vi e` un accesso al
kernel.
In entrambi i casi una parte del protocollo sta fuori libreria e
necessita task switch o context switch.
Con i rischi associati all'avere pezzi di un unico blocco "logico"
sparsi su diversi processi/task/librerie/API...
bye,
--
  Piergiorgio Sartor

Questo potrebbe essere un modo...
No, perche` il kernel non potrebbe sapere cosa il programma morto ha
gia` fatto e cosa c'e` ancora da fare.
