Newsgroup: it.comp.os.dibattiti
Titolo: kernel monolitico o microkernel

processi, ma il kernel sa che esiste uno scheduler.
ultima domanda senza risposta:
come fa il kernel a sapere e dare una priorità e privilegi allo scheduler...
il kernel ha un'altro scheduler intero?

 insulti)
che balle! anche qua!!!
Non che la discussione non sia interessante, ma il tono che ha preso la
rende intollerabile!
-- 
Non c'č piů forza nella normalitŕ, c'č solo monotonia.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com
 - The #1 Newsgroup Service in the World!
-----==  Over 90,000 Newsgroups - 16 Different Servers! =-----

 ha scritto nel messaggio
news:9n0sbr$oji$2...@nreadb.inwind.it...

una risposta ricevuta su it.comp.os.linux.development
"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
http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html
e' appunto quello dello scheduler."
altri link.
http://www.linuxdoc.org/LDP/lki/
http://linux.interpuntonet.it/doc/ldp/tlk-0.8-3.html/kernel/processes.html

 il kernel ha un'altro scheduler intero?
Non saprei... ma si potrebbe ipotizzare che lo scheduler venga richiamato
ad intervalli di tempo fissi del system timer e che aggiorni una process table
condivisa con il kernel. In questo caso non avrebbe bisogno di controllo
da parte del kernel e comunicherebbe con questo solo per via indiretta (con
tecniche varie).
Marco

 rende intollerabile!
che la cosa sia legata?!
discussione interessante => qualcuno rende il tono intollerabile
si parla spesso di caratteristiche e prestazione di sistema, processi,
multithreading,ecc
ma chi ne vuole veramente parlare?
(quante volte avete letto "ma è meglio Beos, Qnx , Windows ecc?")
solitamente quando non si parla di qualcosa è per due motivi...
o non si conoscono
o non si vuole conoscere
in fondo il thread era nato x un dubbio(che tuttora ho)
"che cosa sono i microkernel che caratteristiche hanno?"

 tecniche varie).
cmq: la cosa  rimane ambigua... per due motivi
1."ma si potrebbe ipotizzare che lo scheduler venga richiamato ad intervalli
di tempo fissi del system timer..." ma non dovrebbe essere un processo...
avviene la commutazione di contesto?se si come avviene?
2."e che aggiorni una process table condivisa con il kernel"...
quindi la process table rimane all'interno del  kernel?

 "che cosa sono i microkernel che caratteristiche hanno?"
mi sa che ti conviene farti una salto su 
hurd.swlibero.org
 . Lì trovi
"Verso una nuova strategia per la progettazione dei Sistemi Operativi"
che ti spiega un esempio di s.o. basato su microkernel.
Così capisci la differenza.
-- 
Non c'è più forza nella normalità, c'è solo monotonia.


 Così capisci la differenza.
da quello che ho capito la parola microkernel si definisce un insieme molto
eterogeneo di s.o.
- 
http://www.cs.arizona.edu/people/bridges/os/microkernel.html-
con la caratteristica di occupare poca memoria , pochissima
memoria(nanokernel?) e di offrire poche funzionalità...
(lo scheduling è una di queste poche funzionalità...)
le "altre funzionalità" possono essere affidate a processi server
come mi sembra di capire nel caso del Hurd
http://hurd.swlibero.org/traduzioni/design.html

 memoria(nanokernel?) e di offrire poche funzionalità...
un microkernel non è tale perché sta sotto un certo numero di kb di
dimensione.
Vedi quello di nt che pur essendo un microkernel è più grosso del mio
kernel 
del protatile....
Per il resto è giusto.
Penso, ma non sono sicuro che sia possibile estrarre anche lo scheduler
dal kernel.
e questo era il discorso sull'altro ng.


 e questo era il discorso sull'altro ng.
che si possa realizzare lo scheduler come modulo esterno è possibile
ma che "spesso un microkernel ha lo scheduler esterno, e inserito
come processo a priorita' e privilegi elevati." come è stato detto su
it.comp.os.linux.development è una stupidaggine...
chi effettua la commutazione di contesto di questo processo scheduler?

 quindi la process table rimane all'interno del  kernel?
Era solo un'ipotesi quella di una tabella condivisa. Per quanto ti posso dire puoi avere
un'area di memoria condivisa, una forma di comunicazione privilegiata tra scheduler e
kernel e tra thread e scheduler, quello che ti viene in mente. Non è pensabile di
ridurre soluzioni ancora abbondantemente in fase di ricerca ad uno stereotipo. Un
tentativo di threading preemptive su Mac, RedShed, aggiunge uno scheduler esterno
ed una tabella dei thread esterna al kernel e acceduta da questo a tempi definiti.
Mi pare di poter dire che il problema, con uno scheduler esterno, sia nel dominio del
"quando" più che del "come".
In ufficio ho un po' di documentazione su Vassal. Adesso sono a casa malato, quando
torno se ti interessa ti spedisco quel che ho (ma se cerchi sul sito dei laboratori di
ricerca Microsoft dovresti trovare tutto). E' un punto di partenza. Se vuoi saperne
di più ed hai accesso ad una biblioteca universitaria vai a cercare quel white paper che
ti avevo citato.
Marco

 wrote in message news:9n5ssv$gtr$1...@nreada.inwind.it...

Invece potrebbe non esserlo se consideri che il kernel mantiene le funzionalità
minime per la gestione dei thread... il fatto è che si occuperebbe solo di un
particolare task: lo scheduler esterno (come fa Vassal in certe configurazioni
o KeyKOS. Non ne cito altri per non fare confusione...).
Non dimentichiamoci che il kernel ha la necessità di schedulare anche le
proprie attività (la soluzione Linux al problema non va considerata perchè
Linux è un kernel monolitico... Anzi, da questa discussione dovremmo
escludere del tutto Linux). Può capitare (e capita, non può non capitare...) che
due task interni tentino di accedere alle stesse strutture dati. Il principio
che il kernel stesso non può essere preempted cambia nei contesti di
kernel non monolitici in "se non thread propri da thread propri"; i puristi
adesso faranno storie, ma la situazione è esattamente questa ed è il motivo
per cui le operazioni fondamentali di scheduling non escono dal contesto del
kernel ma solo le logiche di scheduling: il kernel schedula ma il chi, il come
e il quando lo decide lo scheduler esterno.
Marco

funzionalità"
Se sei curioso di sapere che funzionalità offra ntoskrnl.exe, qui c'è 
una ricostruzione del source tree estratta dalla versione di debug:
http://www.sysinternals.com/ntw2k/info/xpsrctree.shtml
Contiene delle cose, come PnP, che in un microkernel non dovrebbero 
esserci, ma che nondimeno sono vitali al boot del sistema (all'avvio il 
kernel può presupporre che solo ntoskrnl.exe e hal.dll esistano, e 
nient'altro).

 Ecco ad esempio il sorgente di una periferica NULL "da manuale":
ooops! vedi tu la fretta, alle volte...
http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/reactos/services/dd/null/

 chi effettua la commutazione di contesto di questo processo scheduler?
sinceramente: non ne ho la minima idea.


 
http://www.sysinternals.com/ntw2k/info/xpsrctree.shtml
sito molto interessante mancano solo i sorgenti :-)
leggo NTOSKNL contiene tutti i subsystems executive(processi di sistema?!)
di Windows XP
incluso il Cache Manager, Memory Manager, Process Manager, Object Manager
and I/O Manager e include anche il Kernel nel quale vengono implementati i
meccanismi di sincronizzazione di NT
credo che la parte kernel sia solo un parte del NTOSKNL
quella nel tree sia ke(Kernel) + hals (Hardware Abstraction Layers)
ma è difficile dirlo...

 e il quando lo decide lo scheduler esterno.
ok mi hai convinto... :-)
lo scheduler non schedula ma  gestisce solo la politica di scheduling.
quindi in un ipotetico kernel minimale possone esserci soltanto
-una struttura dati che contiene i descrittori dei processi in attesa che
gli venga assegnato un processore(codapronti)
-una struttura dati che contiene i descrittori dei processi che attendono un
evento di sincronizzazione (codaattesa)
-schedulatore (senza politica di schedulazione)
    ad esempio che prende sempre il primo processo della codapronti lo fa
passare in esecuzione...
-primitive per sincronizzazione dei processi
la politica di scheduling puņ essere svolta da un processo esterno che
"vede" la codapronti del kernel
scusate le semplificazioni :-)