Newsgroup: it.comp.os.dibattiti
Titolo: Open Source: il microkernel è meglio del monolitico?


http://punto-informatico.it/p.asp?i=39234
La situazione sarebbe migliore se Linux avesse un microkernel come
Minix? E' una mezza idea, ma credo di sě.
Ciao
PV

 Minix? E' una mezza idea, ma credo di sì.
No, non ci sarebbe capito più niente da un pezzo.
Sarebbe stato un modello impossibile da gestire e coordinare
dato che avrebbe richiesto un livello di complessità molto superiore
a quello attualmente gestibile dalla comunità.
Saluti.

  a quello attualmente gestibile dalla comunità.
esatto, esattamente il motivo per cui, Linus e Tanenbaum, litigarono
quando usci' la prima ver. di Linux.
-- 
 ___       | 
 |_|       |  Usa Linux e non dirai piu':
 | |ndry   |  Il PC fa quello che ca**o gli pare!
           | 

 Minix? E' una mezza idea, ma credo di sì.
IMHO, ormai, non fa alcuna differenza pernsare ai "forse" e agli "e
se...". Se vuoi, puoi costruire una macchina del tempo e, una volta
tornato al 1992, puoi provare a convincere Torvalds.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

quando usci' la prima ver. di Linux.
Proprio a questo ho pensato... che "linux è obsoleto".
Ma siamo sicuri di questa "complessità"? Abbiamo visto come la
complessità è cresciuta con il kernel monolitico... non con il
microkernel, e Mach sembra funzionare molto bene.
Ciao
PV

On Sun, 03 Mar 2002 19:24:13 GMT, 
pov...@yahoo.it
 (Michele Povigna)
wrote:

Diciamo anche che sono più efficienti: un tal Neutrino è real-time,
abbiamo constatato. Se fosse Posix, lo preferirei a Linux.
Mach ci dimostra su PowerPC che un microkernel va alla grande (vi
ricordate poi il "vecchio" Win NT).
A questo proposito, permettetemi questa citazione:
"OS/2 3.0 was in the very early stages of development and was intended
at the time to be a network server version of the operating system. It
was also intended to be platform independent. Because the operating
system would be built on top of a microkernel, it would not need to be
aware of the type of hardware on which it was running and therefore
could run on Intel processors as well as Motorola, SUN, and DEC, chips
with only a change of the microkernel hardware abstraction layer."
Ciao
PV

 Proprio a questo ho pensato... che "linux è obsoleto".
Guarda che essere obsoleto non significa essere inefficiente.
Linux, che è il kernel, è tutto tranne che inefficiente. E' molto semplice.
Quando dovrà fare quello che gli hanno chiesto di fare diventerà
inefficiente ed non mantenibile.
Saluti.

 ricordate poi il "vecchio" Win NT).
Mach e` lento, purtroppo.
Questa e` una discussione ricorrente, i uK sono
ottimi design, eleganti e funzionali, purtroppo
le attuali CPU non sono fatte per i uK e le
prestazioni, alla fine, nel caso generale,
risultano inferiori al kernel monolitico.
bye,
-- 
  Piergiorgio Sartor

 risultano inferiori al kernel monolitico.
Non esiste il "caso generale", esistono le buone e cattive implementazioni.
Fabio Alemagna

 Minix? E' una mezza idea, ma credo di sì.

"Gabriele Del Giovine" <cicci...@cicciopalladotcom.dotcom> ha scritto
nel messaggio news:a5tnj1$mjm$1...@fe2.cs.interbusiness.it...

Non ne sarei così sicuro. La comunità (piuttosto esigua) che ruota
attorno
a Darwin, la controparte open source di MacOS X, riesce a produrre
codice in quantità costante e buona qualità senza trovare in Mach uno
elemento di complicazione (la complessità non è mai un problema in sè).
Insomma, non mi pare che si possa generalizzare così allegramente.
Marco

 Non esiste il "caso generale", esistono le buone e cattive implementazioni.
Ma tu leggi quello che scrivo?
Il "caso generale" e` riferito alle
applicazioni.
Es. un server web e` diverso da un controller
per condizionatori, sono casi specifici.
Pero` puo pensare ad un "caso generale" o, se
preferisci, "generico".
Cioe` un OS che deve potenzialmente fare un
po' di tutto.
bye,
-- 
  Piergiorgio Sartor

 po' di tutto.
Ripeto: esistono buone e cattive implementazioni. Un OS a microkernel 
può essere più performate di uno monolitico, dipende da quali criteri 
adotta e da come è scritto. Non esiste nessun teorema che dimostri la 
maggiore efficienza di un kernel monolitico rispetto ad un microkernel. 
Almeno per ora.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
"Ogni cosa è vaga in una misura di cui non ci si rende conto finché non
  si cerca di renderla precisa"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 maggiore efficienza di un kernel monolitico rispetto ad un microkernel.
Esistono correnti implementazioni di CPU, che
non facilitano la struttura uK.
Qualora dovessero cambiare le CPU, probabilmente
il uK potrebbe diventare una soluzione proponibile,
ma per gli attuali x86 (e compagni) e per le richieste
medie degli OS, i uK non sono ancora soluzioni adatte.
Speriamo in un futuro piu` roseo.
bye,
-- 
  Piergiorgio Sartor

 non facilitano la struttura uK.
Mmm... ovvero?
Fabio Alemagna


 Mmm... ovvero?
Avevo gia` scritto di questa cosa, comunque, il problema e`
innanzi tutto il numero contex switch, che sarebbe da ridurre
al minimo, cosa che non avviene affatto nei uK.
Le CPU attuali sono pensate per avere kernel monolitici,
che quando entrano in supervisor mode, ci restano per
abbastanza tempo da rendere trascurabile l'overhead del
contex switch.
Alcune CPU piu` moderne adottano tecniche come gli
shadow register, cioe` un set di registri separati
da usarsi solo in supervisor mode, senza appoggiarsi
allo stack. Il che favorisce i uK, ovviamente.
Altra cosa e` la possibilita` di congelare la cache,
poche CPU hanno questa feature, che risulta utile
per i uK, dato che sarebbe possibile avere *tutto* il
uK in cache, sempre disponibile, con tutti i vantaggi
del caso.
Ancora, HW supported IPC, i uK fanno molto uso di IPC,
per definizione, se la cosa fosse supportata in HW
(pochissime CPU lo fanno) i uK ne trarrebbero vantaggi.
Ovviamente gli ultimi due punti non darebbero benefici
ad un kernel monolitico e quindi non sono implementate.
Il che ci porta, ovviamente, in un circolo vizioso.
Il problema piu` grosso e` la diffusione di questi
disgraziati x86.
Se il mercato delle CPU fosse piu` volatile, sicuramente
avremmo molto piu` supporto per uK e quindi molti piu`
uK in circolazione.
bye,
-- 
  Piergiorgio Sartor

 elemento di complicazione (la complessità non è mai un problema in sè).
Appunto, la comunità è piccola e riesce a coordinarsi.
Il problema è che la comunità di Linux in conseguenza delle sue dimensioni
comincia a non avere più una struttura organizzativa a matrice
ma comincia a sembrare una burocrazia divisionale.
Saluti.



"Linux is obsolete" era il titolo del thread su comp.os.minix... non
una mia opinione.
Ciao
PV

</PREMESSA>
ROTFL! Linus Torvalds dice: "*The minix microkernel implementation is
essentially single-threaded* (and fundamentally so, partly due to the
message passing primitives - they couldn't queue a message), which
means that once you have multiplekernel services depending on each
others you end up having to be _very_ careful about deadlocks.  What
was supposed to be a simple system becomes a nightmare of call
graphs.."
http://yarchive.net/comp/minix.html
Ciao
PV

prestazionali.
QNX Microkernel Architecture
* All device drivers are independent processes
* All processes provided with memory protection _*via virtual memory*_
* Microkernel provides process scheduling, IPC, interrupt handling and
low-level network access
http://www.aoc.nrao.edu/Real_Time/qnx/tsld004.htm
Basta?
Ciao
PV

 
Ah ecco siamo ancora al paleolitico! Microkernel=piu' context switch.
Mai sentito parlare di migrating threads?
Certo che comunque hai ragione, nelle nuove cpu si aggiungono sempre istruzioni multimediali,
mai nessuno che pensi di buttar via tutti i meccanismi obsoleti di system
call e memoria virtuale.

 
Beh aspetta che sia pronto HURD con il modulo emulazione devices di
linux... poi si puo' finalmente SCEGLIERE!

 linux... poi si puo' finalmente SCEGLIERE!
Ehm.
Quanti anni sono che si aspetta HURD? Ho perso il conto.


 
Ma scherziamo?
Adesso non ci si capisce piu' niente! Linus che perde le patch, due che
si scannano per la VM, varie versioni etc.
Non vedete quanto e' rallentato lo sviluppo, per uscire la 2.4 ci ha
messo una vita, la 2.6 quando uscira'?
Proprio non capisco, la caratteristica principale del microkernel e' che
E' FACILE da gestire, per quello che tutti i ricercatori lo preferiscono.
Infatti ai tempi dei dibattiti microkernel/monolitico tutti confrontavano
le prestazioni, ma invece andava confrontata la facilita' di sviluppo.
Faccio un esempio:
sia gnome che kde prevedono la possibilita' di navigare dentro file
.tar.gz o .zip come se fossero file system.
Ora questo causa due difetti:
1) duplicazione di codice: sia il team di gnome e di kde ha dovuto
scrivere codice per navigare dentro gli archivi compressi.
2) non generalizzazione. Se io uso bash invece di kde o gnome devo andare
a mano con unzip e tar.
Tutto questo perche'? Perche' il file system per archivi compressi
dovrebbe essere inserito nel kernel. Ma allora apriti cielo! Molti
protesterebbero perche' il kernel diventerebbe "bloated"! Infatti molti
hanno protestato per l'inserimento di un web server nel kernel.
Invece su HURD aggiungere dei file system che fanno cose banali non e' un
problema, perche', essendo microkernel, TUTTI i filesystem sono fuori dal
kernel!
E aggiungerne uno in piu' non aggiunge complessita'!
Cioe' dico vi rendete conto la differenza fra aggiungere un pezzo al
kernel di linux (bisogna sapere un sacco di cose, le chiamate di sistema
tipo malloc non sono disponibili, non bisogna consumare troppa cpu,
etc.) o fra aggiungere un modulo ad un microkernel, modulo che gira a
livello utente?

 
Non e' colpa mia se ci lavorano in 10 al massimo!
Alle cose belle ci lavorano in pochi! Guardate anche GNUStep...

 with only a change of the microkernel hardware abstraction layer."
Linux gira su una dozzina di piattaforme e oltre, NetBSD piu' di 40.
Se il design e' buono, un kernel monolitico non ha difficolta' ad essere 
multipiattaforma.
-- 
Lorenzo

 meccanismi obsoleti di system call e memoria virtuale.
Con che cosa vorresti sostituire syscall e VM? 
-- 
Lorenzo

 livello utente?
Aggiungere un fs a Linux non e' una cosa difficile, anzi si puo' dire che 
non e' mai stato cosi' facile.
fs/ramfs/inode.c e' un fs completo, POSIX compatibile, 8Kb di codice.
-- 
Lorenzo

 Basta?
No, non basta.
bye,
-- 
piergiorgio

 Mai sentito parlare di migrating threads?
Non risolvi mica il problema.
bye,
-- 
piergiorgio

No, non basta.
"45) Does QNX support virtual memory?
Yes.  Don't confuse this with a swap file though.  Virtual memory only
refers to the mapping of real physical memory through a MMU.  QNX
operates in the protected mode of the Intel processors, and makes use
of LDT and GDT selectors to provide memory mapping to physical memory.
Use of virtual memory also allows QNX to provide shared memory on a
per-process basis as well as memory protection between processes, and
even the processes that make up the OS itself."
http://schoenbrun.com/~mba/faq.htm
Ora sì? (l'importante è lo yes, no?)
Ciao
PV

le prestazioni, ma invece andava confrontata la facilita' di sviluppo.
Questo è quello che intendevo io. Altrimenti, cosa mi ricollegavo a
fare alla "balcanizzazione" del kernel, se il discorso riguardava le
prestazioni del micro contro il monolitico?
Ciao
PV

 Alle cose belle ci lavorano in pochi! Guardate anche GNUStep...
Con la differenza che, mentre da GNUstep e` saltato fuori WindowMaker,
da HURD non ho visto saltar fuori nulla. ;-)


 kernel!
Ti sei perso l'abstraction layer introdotto da Al Viro per i Filesystem.
Scrivere un fliesystem per Linux non e` mai stato cosi` facile: ci sono
diversi esempi di FS in userspace (uno mi pare anche in Python o Perl,
adesso non ricordo).
Se leggi la lkml, ti sei limitato a quattro thread oppure hai letto solo
i subject, di la verita`.


fs/ramfs/inode.c e' un fs completo, POSIX compatibile, 8Kb di codice.
E' stato faticoso scrivere quegli 8Kb? Non parliamo dal punto di vista
del'utente, ma dello sviluppatore...
Ciao
PV

 del'utente, ma dello sviluppatore...
Dovresti chiederlo ad Al Viro. ;-)
Per quanto ne so, e` stata dura perche' la patch e` stata scritta per
rimpiazzare il vecchio sistema in maniera pressoche' indolore, in
diverse release.
Se nel '92 ci fosse stato qualcuno che si prendeva la briga di scrivere
un layer di astrazione per i filesystem come quello attuale, sarebbe
stato piu` facile di quanto non sia stato cambiarlo, a causa
dell'inferiore complessita` del kernel di allora.
E qui ritorno a dire quanto detto all'inzio del thread: se qualcuno ha
una macchina del tempo e vuole tornare nel '92 e convincere Linus a fare
un microkernel, puo` farlo. IMHO, *adesso*, non vale la pena ragionarci
sopra, anche perche' non si puo` cambiare.


 Ora sě? (l'importante č lo yes, no?)
Come ho scritto altrove, non specificano
cosa ci facciano con la MMU, ne` come sia
realizzata la cosa (ovviamente).
bye,
-- 
piergiorgio


E' stato faticoso scrivere un VFS che ti permette di implementare un fs
in 8Kb, questo si, ma il VFS si scrive una volta sola.
In altre parole, non confondere chi sviluppa i "framework" da chi 
implementa le "istanze".
Se non sei ancora convinto conta il numero dei filesystem in fs/
-- 
Lorenzo

 sopra, anche perche' non si puo` cambiare.
Se non ricordo male ci fu un MkLinux, anche se credo che ormai si e' 
arenato.
-- 
Lorenzo

 
http://yarchive.net/comp/minix.html
Sarei curioso di sapere come si comporta un uk attuale
su macchine SMP e NUMA.
-- 
Lorenzo

 
Senti non iniziamo con le offese personali. Io patchavo il kernel di
linux e modificavo il file system di minix quando tu eri ancora in fasce.

 
Allora: windowmaker non ha NIENTE di GNUStep, tranne il look. L'autore
l'ha fatto in C usando librerie standard di X.
Se guardi su 
www.osnews.com
 tempo fa c'era una intervista a uno
sviluppatore hurd che fa notare che siamo a buon punto, in quanto possono
riciclare i driver di linux tramite un'emulazione e hanno implementato
quasi tutte le api posix. Gira X, ma mancano ancora GNOME e KDE in quanto
usano i threads e non hanno ancora finito la libreria.
Se comprate la distribuzione italiana linuxespresso trovate anche HURD
pronto da installare.



Oh meno male che qualcuno mi capisce!
Ma volete capire che sviluppare _dentro_ al kernel e' difficile?
Mica potete chiamare tutte le system call che volete!
Mica potete allocare tutta la ram che volete!
Mica potete consumare tutta la cpu che volete!
Mica potete contare sul multitasking preempitive!
Mica etc. etc.
E poi aggiungo che se vi prendete la liberta' di aggiungere parti
"potenzialmente" inutili, come il server http, vi prendete anche un sacco
di proteste!
Andate a cercare su 
www.osnews.com
 l'intervista allo sviluppatore hurd e
leggetevela!



Beh io intendevo dire sostituire le istruzioni attuali con altre piu'
moderne che seguano la tendenza dei programmi attuali di essere divisi in
piu' librerie dove ogni libreria potrebbe avere capabilities diverse.
Sul sito della SGI c'era un esempio chiamato D11 che era praticamente il
progetto di riscrivere X11 ma come libreria. Nel momento che un programma
chiamava questa libreria acquisiva i permessi di scrittura sulla memoria
video, ma solo mentre eseguiva il codice di questa libreria. Piu' o meno
si puo' fare anche con le CPU attuali, ma con un set di istruzioni
specifico verrebbe sicuramente meglio.

 
Lo risolvero' solo al 99% pazienza...

 Mica etc. etc.
E meno male. Sai che confusione ci sarebbe, altrimenti?
Vincoli rigorosi sono sempre necessari, quando si fa qualcosa di cosi`
complicato. E se si vuole aggiungere qualcosa, si deve *dimostrare* che
serve e che si puo` implementare in maniera decente. Casualmente, al
momento cruciale della dimostrazione, alcune delle patch piu` esoteriche
cadono in NULL.


prestazionali.
Non conosco la situazione attuale, ma ricordo di aver letto tempo fa
che stavano lavorando verso tale possibilita'.
Ovviamente per applicazioni che non necessitano del real time.
ciao, acc.   
a...@libero.it

 Mach ci dimostra su PowerPC che un microkernel va alla grande
Questo e' vero.
///
Linux ppc 2.2.17-0.6.1 vs. Mac OS X 10.1.2 (Power Macintosh G3):
http://space.tin.it/scienza/bxmgi/root/linux_benchmarks.txt
http://space.tin.it/scienza/bxmgi/root/macosx_benchmarks.txt
Mac OS X 10.1.3 (iBook):
http://space.tin.it/scienza/bxmgi/root/macosx_rootmarks.txt

 Lo risolvero' solo al 99% pazienza...
Non lo risolvi affatto.
Quando scrivo di contex switch, mi riferisco
al passaggio user mode -> supervisor mode
della CPU, che avviene sempre e comunque,
non e` risolto dai migrating thread, mi pare.
bye,
-- 
  Piergiorgio Sartor

 E' FACILE da gestire, per quello che tutti i ricercatori lo preferiscono.
Facile da gestire quando c'è una OTTIMA definizione delle interfacce
ed un'idea di quello che si sta cercando di ottenere.
Il problema che si appalesa con Linux  è che non si sa cosa si vuole
ottenere.
Saluti.

Piergiorgio Sartor wrote:

Questo passaggio avviene sempre e comunque anche ORA. In realtà il 
problema dei microkernel non è tanto il context switch, quanto le 
serializzazioni non necessarie.
Nemesis (
http://nemesis.sourceforge.net
) risolve brillantemente questo 
problema.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
"Ogni cosa è vaga in una misura di cui non ci si rende conto finché non
  si cerca di renderla precisa"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 serializzazioni non necessarie.
Cioe`? Cosa intendi?
bye,
-- 
  Piergiorgio Sartor

 Cioe`? Cosa intendi?
Code di messaggi, essenzialmente. Richieste che potrebbero essere svolte 
in parallelo ma che invece vengono serializzate.
Nemesis risolve brillantemente questo problema, facendo girare la 
maggior parte del codice dei filesystems e device drivers nel contesto 
dell'applicazione che ne fa uso. In questo modo si raggiungono due scopi 
primari: alta modularità del sistema, con componenti rimpiazzabili a run 
time, e basso, bassissimo numero di context switch.


 time, e basso, bassissimo numero di context switch.
Uhm, ma cosi` consenti all'applicazione di accedere
a parti critiche del sistema.
Se questa rimpiazza parti del FS (cosa possibile,
dato che sono nello stesso spazio) puo` causare
danni notevoli al sistema.
Questo e` poi il motivo del supervisor mode, cioe`
avere un ambiente controllato, totalmente indipendente
dal contesto utente e quindi sicuro.
bye,
-- 
  Piergiorgio Sartor

 dal contesto utente e quindi sicuro.
é un concetto antiquato, oltre che limitato. La sicurezza non si ottiene 
solo con il supervisor mode.


 solo con il supervisor mode.
Non ho scritto "solo", ma senza dubbio avere questa
separazione rende il sistema a sicurezza intrinseca.
bye,
-- 
  Piergiorgio Sartor

 ///
[SNIP]
Interessante.
Comunque, si tratta sembre di un microkernel che tiene molti servizi in
kernel space. Non so quanto influisca.
-- 
):E...

 separazione rende il sistema a sicurezza intrinseca.
Non vedo come.


 Non vedo come.
Per il semplice fatto che il kernel non
puo` essere modificato dall'utente, in
questo modo.
Quindi tutta la roba critica sta in un
unico punto, ad accesso limitato.
bye,
-- 
  Piergiorgio Sartor

 disgraziati x86.
:)
-- 
):E...

 Non risolvi mica il problema.
Cosa sono?
-- 
):E...

 unico punto, ad accesso limitato.
quello che fa il filesystem ext2 nel kernel di linux lo posso fare anche 
io "a mano" in user mode. Se ho accesso ad una partizione ci ho accesso 
comunque, e non ho certo bisogno di usare un FS per distruggerla.


 linux e modificavo il file system di minix quando tu eri ancora in fasce.
Si parlava di offese personali, eh?


 l'ha fatto in C usando librerie standard di X.
Perche' deve funzionare anche a prescindere da GNUStep:
[dal README di WindowMaker]
Window Maker was designed keeping integration with GNUstep in mind and
is the "official" window manager for it. It is also part of the GNU
project (
www.gnu.org
) Read more about GNUstep further on this file.


 comunque, e non ho certo bisogno di usare un FS per distruggerla.
No, ma se il FS e` nel tuo user space, vuol dire
che puoi anche fare il "cat" che descrivi sopra.
Quel "cat" non lo puoi fare solo se:
1) l'accesso al disco e` in kernel space
2) il task "driver" e` privilegiato (ha un suo user space)
3) crei un meccanismo di autenticazione per l'accesso nel tuo user space
4) varie & eventuali.
In termini di prestazioni i punti 2) e 3) non
presentano alcun vantaggio (anzi) rispetto ad 1).
Sono concettualmente migliori, ma, ancora una volta,
finche le CPU saranno pensate per 1), le altre
soluzioni saranno piu` complicate e meno efficienti.
bye,
-- 
  Piergiorgio Sartor

 arenato.
Il kernel era stato scritto per i processori della serie 68k. Apple non lo
segue piu' da un pezzo (si e' concentrata su Darwin), ed il sito
(
mklinux.org
), da quello che ho visto non viene piu' aggiornato da circa
due anni.
-- 
):E...

     Prendi Risultato di A, di B e di C.
Voto a favore. Non trovo particolarmente complicato e incomprensibile
questo codice.
Certo, ci sono cose intrinsecamente complicate. Ma e' anche vero che
spesso la difficolta' nell'usare certi strumenti e' nell'esser costretti a
cambiare le proprie abitudini. Faccio un esempio. Tempo fa lessi di alcuni
programmatori che su BeOS trovavano difficolta' nella stesura del codice
per quello che consideravano un eccessivo uso del multithreading. In
pratica, non gradivano il fatto che il sistema aprisse automaticamente
delle thread (ad esempio all'apertura di una finestra), il che comportava
di doversi preoccupare della concorenza.
La cosa mi aveva meravigliato. Non trovavo cosi' problematico considerare
che non si poteva fare affidamento su una automatica rientranza del codice
all'interno dell'applicazione. Anzi, questo, a mio avviso, ti spinge a
ragionare di piu' sul codice e a dargli una struttura migliore. Aggiungo,
chi usa correttamente le tecniche di programmazione OO dovrebbe avere
minori difficolta' a scrivere codice rientrante.
Ma queste lamentele avevano una ragione meno evidente. Leggendo
attentamente si scopriva che questi programmatori, nella maggior parte dei
casi, dovevano portare su BeOS applicazioni scritte per altri sistemi, in
cui il problema della concorrenza e' meno sentito.
-- 
):E...

 cui il problema della concorrenza e' meno sentito.
Piu` che altro e` risolto a monte...
bye,
-- 
  Piergiorgio Sartor

 arenato.
Yep, troppo lento, se confrontato con il kernel monolitico.
bye,
-- 
  Piergiorgio Sartor

 comunque, e non ho certo bisogno di usare un FS per distruggerla.
Ma il punto e' che tu NON devi avere accesso a questa partizione... in nessun
modo. Altrimenti e' una evidente falla nella sicurezza, comunque la metti, in
qualunque sistema tu stia operando...
Nell'esempio che hai riportato, anche gli mtools richiedono che /dev/fd* sia
accessibile dagli utenti...
Se tu fai in modo che il fs in user mode stia nello stesso spazio di
indirizzamento del processo che richiede l'uso del fs, fai in modo che anche
un errore fortuito o doloso dello stesso processo, in user mode, possa
compromettere il filesystem... mentre in un filesystem in user mode, ma che
gira in un processo separato (come un server del microkernel, appunto), tale
problema non si puo' porre... ma naturalmente si ripropone il problema di
qualche context-switch in piu' rispetto ad un kernel monolitico (eppure in
passato ho chiesto se c'erano maggiori context-switch in un microkernel, e mi
si rispose che non era cosi'...).
bye G.L.

 compromettere il filesystem... 
Non necessariamente, il tutto dipende da COME è gestito il tutto. 
Nemesis è molto particolare in questo, ed è tanto sicuro quanto i più 
sicuri degli altri sistemi.
I nemesis i filesystem e i device drivers sono divisi in due componenti: 
una che gestisce eventi "out-of-band", ed un'altra che gestisce eventi 
"normali". La prima gira in un contesto separato, è un processo a parte, 
mentre la seconda gira nel contesto del chiamante. Questa separazione, 
sommata al fatto che comunque tutto il testo delle componenti è 
read-only, ne fa un sistema sicuro.
Invito te, e gli altri interessati all'argomento, a leggere la 
documentazione di Nemesis. Ricordo che Nemesis non è un OS messo su da 
qualche hacker qualsiasi, è un progetto che è stato portato avanti da 4 
università, finanziato dalla UE.


realizzata la cosa (ovviamente).
Altro tentativo (sei mooolto testardo, ma anche io NON scherzo!):
http://www.qnx.com/literature/nto_sysarch/proc.html#MEMMAN
Ciao
PV

 università, finanziato dalla UE.
Non ho capito una cosa: se usa una system-wide page table, come fa a 
implementare la protezione della memoria tra processi?
Protezione tra processo e kernel e' possibile perche' ogni page table entry 
ha un bit user/supervisor, ma non c'e' nessun altro campo che permette di 
distiguere tra piu' processi utente.  Al massimo puoi usare un bit 
read/read-write, ma non e' sufficiente.
Ovviamente ti sto parlando di x86 che e' l'architettura che conosco meglio 
ma credo che il discorso sia valido anche per le altre.
Ah, forse modifica la page table ad ogni context switch settando o 
resettando il bit raead/write per ogni entry?
Se e' cosi' pero' non e' vero che il context switch e' piu' economico.
-- 
Lorenzo

su macchine SMP e NUMA.
Il microkernel l4 è SMP su Alpha, VSTa (interessante quasi come QNX,
anche se non l'ho ancora provato) su x86.
http://www.cse.unsw.edu.au/~disy/L4/
http://www.zendo.com/vsta/
How the SMP microkernel works:
http://support.qnx.com/support/docs/neutrino_qrp/sys_arch/smp.html
Per i NUMA, abbi pazienza (devo ancora iniziare le ricerche...)
Ciao
PV

Lorenzo Allegrucci wrote:

Nemesis usa un unico spazio virtuale per tutti i processi, ma non mi 
pare usi un unica translation table. Semplicemente tutte le translation 
tables hanno lo stesso "layout", ma le protezioni sono differenti.
l'accoppiata k_activate/k_restore, che implementano il task switching in 
nemesis, ammontano a poche linee di codice, e non mi pare che facciano 
quello che tu ipotizzi qui sopra.
I le funzioni di cui parlo si trovano in
     k_activate: nemesis-2.0beta4/master/ntsc/ix86/intel/kernel.c
     k_restore:  nemesis-2.0beta4/master/ntsc/ix86/intel/khead.S


 
Dicesi anche: MIGRATING THREADS...

 sicuro.
No e' qui l'errore: nel kernel normale hai un calderone di cose che
girano si' in supervisor mode, ma tutte assieme! Quindi, per esempio, un bug nel
driver X della scheda di rete puo' rovinare i dati del file system,
magari non tanto da bloccare il kernel, ma da farti accorgere che i tuoi
file sono diventati inservibili...
Invece immagina di avere un demone hd+filesystem, che e' un pezzo di
codice che gira in modalita' UTENTE, ma che ha avuto in concessione
permanente dal microkernel la pagina di memoria dove ci sono i registri
che controllano il bus ide. In questo caso questo codice puo' accedere
all'hardware, ma senza chiamare il kernel, e un bug in questo codice non
rovinerebbe altre parti del sistema. Ovviamente il programma utente
dovrebbe fare una chiamata di sistema per accedere a questo gestore, cosa
che fai ugualmente nei kernel monolitici.

 anche dopo
Piergiorgio, io mi arrendo, ammetto a questo punto che le mie idee sono antiquate.
Ho letto qualcosa sulla struttura di nemesis: se le cpu recenti (relativamente)
hanno caratteristiche tali da supportare una siffatta innovativa struttura di os,
dovro' sicuramente ripassare e studiare qualcosa in piu'...
bye G.L.

 che fai ugualmente nei kernel monolitici.
Quello che non riesco a spiegare (forse) e` che
nel kernel monolitico, per via di come sono concepite
le CPU, si ha un *ottimo* bilanciamento tra funzionalita`
e prestazioni.
In kernel space sta tutto quello che serve, e non di piu`,
per avere un sistema efficiente ed affidabile.
Con CPU diverse, puo` essere che i uK siano una soluzione
migliore, per ora, in classe x86, no.
bye,
-- 
  Piergiorgio Sartor

 
http://www.qnx.com/literature/nto_sysarch/proc.html#MEMMAN
Qui specificano meglio, ma parlano di Neutrino,
non dei precedenti QNX.
bye,
-- 
  Piergiorgio Sartor

 Per i NUMA, abbi pazienza (devo ancora iniziare le ricerche...)
Intendevo "come scalano" su macchine n-way con n 2,4,8 e oltre.  Numeri :)
Lo so che i uk hanno un multithreading piu' naturale, per certi versi, ma 
mi chiedevo se il message-passing (e non solo quello) possa in qualche modo 
ferirne le prestazioni, specie su macchine NUMA dove la comunicazione 
internodo e' molto piu' costosa dei SMP.
-- 
Lorenzo

 tables hanno lo stesso "layout", ma le protezioni sono differenti.
Uhm, quindi dovrebbe avere page tables separate per ogni processo
(come di norma) e ogni page table fa un mapping 1:1, ho capito bene?
Questo modello sembra conservare la protezione e allo stesso tempo
ogni processo ha la stessa visione della memoria fisica, cioe' tutti
processi concordano che l'indirizzo virtuale 0xDEADBEEF corrisponda 
all'indirizzo fisico 0xDEADBEEF.
Se quanto sopra e' vero, allora il costo dei context switch e' minimizzato 
dalla condivisione della memoria che e' facilitata dal mapping 1:1.
Tuttavia, il costo del singolo context switch non cambia.
In altre parole, Nemesis usa la condivisione della memoria quasi come i 
kernel monolitici :)
-- 
Lorenzo

tables hanno lo stesso "layout", ma le protezioni sono differenti.
Ho letto la documentazione sul sito, e benché non abbia capito tutto,
mi sembra un progetto molto carino e anche ben avviato.
Due cose vorrei sapere, visto che sembri abbastanza "dentro":
1) È ancora sviluppato?
2) Che licenza usa?
-- 
Saluti,
    Mardy
http://castellina.org/interlingua

2) Che licenza usa?
Nemesis Free License.
testo integrale in
http://www.cl.cam.ac.uk/Research/SRG/netos/old-projects/nemesis/releaseguide/releaseguide.html#SECTION00020000000000000000
Ho faticato a trovarla per la ragione sopra...
Ciao
PV

 all'indirizzo fisico 0xDEADBEEF.
Scusa, ma in questo caso non vi e` un piccolo
problema con lo swap in/out delle pagine?
Queste potrebbero (o dovrebbero poter) finire
ovunque in memoria, non conservando piu` la
mappatura 1:1 iniziale.
Oppure ho capito male?
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

Capito male... il fatto che lo spazio


 kernel monolitici :)
Innanzi tutto, se due processi hanno la translation table con le stesse 
protezioni, non c'è bisogno di cambiarla; in secondo luogo anche se il 
costo del context switch può essere simile, è il numero di context 
switch necessari, rispetto ad un normale OS a microkernel, che 
diminuisce drasticamente.
Inoltre, grazie alla unicità dello spazio virtuale, le cache del 
processore non devono essere invalidate ad ogni context switch, e la TLB 
ne giova parecchio pure.


Piergiorgio Sartor wrote:

Se le premesse fossero valide, avresti ragione, ma siccome non lo sono... ;)


non dei precedenti QNX.
E allora? Anche io parlavo di Neutrino...
Piuttosto, ho visto altra roba interessante:
http://www.oncoresystems.com/
"OnCore OS Capabilities: 
        Full MMU-based Dynamic Virtual Memory environment ..."
Cosa ne dici?
Ciao
PV

 essere per forza 0xDEADBEEF.
Ma i processi hanno tutti indirizzi virtuali diversi?
Come risolvi il problema page in/out?
bye,
-- 
piergiorgio

 Cosa ne dici?
Che stressano troppo il fatto che usano la MMU.
Nel link su Neutrino, anche QNX dice che usare
la MMU e` un problema, solo che si puo` trovare
sempre un compromesso tra prestazioni e sicurezza.
La questione non si aggira, se vuoi il massimo dal
uso della MMU, ti ritrovi con un certo overhead.
Probabilmente con le moderne CPU, non e` un problema
sentito, data l'elevata velocita`.
bye,
-- 
piergiorgio


No ho capito male io, non e' un mapping 1:1 speculare.
Questo comunque cambia poco, la questione centrale e' i processi sono tutti 
d'accordo su dove si trovi un _certo_ indirizzo fisico che non e' 
necessariamente uguale a quello virtuale.
-- 
Lorenzo

 ne giova parecchio pure.
 
Ho il sospetto che alcune architetture devono invalidare tutti i TLB.
-- 
Lorenzo

 X non gira in kernel space...
Credo che intendesse X come "incognita"... come per dire "un driver
qualunque" e
non X-Windows... ;-)
Marco

 necessariamente uguale a quello virtuale.
OK, ma se non mi sbaglio il problema
delle pagine in e out resta, dato che
con questa soluzione ogni processo si
trova in un suo spazio, si virtuale, ma
fisso, dato che non sembra possibile una
mappatura completamente libera.
bye,
-- 
piergiorgio

 non X-Windows... ;-)
Ops, forse ho saltato qualche parola... :-)
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

No, siccome non c'è mapping 1:1 si può rimappare qualsiasi indirizzo a 
qualsiasi altro, pur se c'è un unico spazio virtuale.


 qualsiasi altro, pur se c'è un unico spazio virtuale.
Ma non in tempi diversi.
Cioe` se ho la mappatura x->y adesso,
questa e` fissa, mi pare di capire,
non puo` piu` essere modificata.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

E perchè mai non potrebbe essere modificata? In ogni caso, nemesis 
supporta lo swapping su disco, quindi...


 Ho il sospetto che alcune architetture devono invalidare tutti i TLB.
E perchè mai? Lo spazio virtuale rimane lo stesso.


 supporta lo swapping su disco, quindi...
Perche` cambierebbe per tutti i processi,
o no?
bye,
-- 
piergiorgio

 o no?
Sì, e allora?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
"Ogni cosa è vaga in una misura di cui non ci si rende conto finché non
  si cerca di renderla precisa"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 E perchè mai? Lo spazio virtuale rimane lo stesso.
Lo spazio virtuale rimane lo stesso, il memory mapping attuale no.
Almeno una parte dei TLB devono essere invalidati, quelli aggiunti oltre lo 
spazio comune, o "locali" secondo un'altra denominazione.
E' nel codice di master/ntsc/x86/intel/mmgmt.c:k_swppdom()
-- 
Lorenzo

 E' nel codice di master/ntsc/x86/intel/mmgmt.c:k_swppdom()
Certo, ma vuoi mettere che comunque non devi invalidarli tutti?


 Sě, e allora?
Mi suona strano, non mi e` chiaro perche`.
Magari funziona anche.
bye,
-- 
piergiorgio

  Piergiorgio Sartor
</QUOTE>
Io parlavo solo di Neutrino... non ho provato altri QNX, e
generalmente non chiamo in causa sistemi che non conosco. 
Ciao
PV

 Vediamo... un post era cosě:
Prendi quello originale... ;-)
bye,
-- 
piergiorgio

 Certo, ma vuoi mettere che comunque non devi invalidarli tutti?
Infatti io ho detto che potrebbe essere un compromesso interessante, se 
solo si potesse provarlo su strada.
-- 
Lorenzo

 Mi suona strano, non mi e` chiaro perche`.
Piu` che altro mi chiedo: se tutti i processi
hanno lo stesso spazio virtuale, vuol dire che,
se ho capito bene, ad ogni allocazione di memoria,
si deve *cercare* nello spazio virtuale un'area
libera, dopo di che si devono cercare le pagine
libere nello spazio fisico (e mapparle).
Per prima cosa potrebbe succedere che, pur essendoci
spazio virtuale libero, questo magari potrebbe
essere frammentato, cosi` da far fallire l'allocazione,
secondariamente mi pare si usi una doppia ricerca
di informazioni, cosa discutibile.
In generale mi domando come sia possibile
sottoutilizzare la MMU, che gia` fornisce il
minimo indispensabile, ed avere le stesse
funzionalita`/prestazioni di un sistema che
fa un uso completo della MMU.
Oppure non ho capito come funziona... :-)
bye,
-- 
piergiorgio

 Interessante.
"While I could go into a long story here about the relative merits of 
the two designs, suffice it to say that among the people who actually 
design operating systems, the debate is essentially over. Microkernels 
have won. The only real argument for monolithic systems was performance, 
and there is now enough evidence showing that microkernel systems can be 
just as fast as monolithic systems (e.g., Rick Rashid has published 
papers comparing Mach 3.0 to monolithic systems) that it is now all over 
but the shoutin`." (Andy Tanenbaum)
Linus vs. Tanenbaum:
http://root.cern.ch/root/Linus_vs_Tanenbaum.html

 ricordate poi il "vecchio" Win NT).
Mach e` lento, purtroppo.
Questa e` una discussione ricorrente, i uK sono
ottimi design, eleganti e funzionali, purtroppo
le attuali CPU non sono fatte per i uK e le
prestazioni, alla fine, nel caso generale,
risultano inferiori al kernel monolitico.
bye,
-- 
  Piergiorgio Sartor
</QUOTE>
Ciao
PV

 monolitici).
Ehm, scusa, ma non ho capito...
bye,
-- 
  Piergiorgio Sartor

Ehm, scusa, ma non ho capito...
In quel post, incluso integralmente fra i tag <QUOTE> io parlo solo di
Neutrino e Mach... eri stato tu a tirare in ballo altri QNX, riguardo
ai quali non ho niente da dire perchè non li conosco.
Poi, tu mi avevi risposto con un ";-)" così io ho detto: controlla con
gli occhiali (e un sorriso, magari) "8-)" quello che c'è scritto.
Infine, muk è il mio sostituto per il vostro uk (che mi fa pensare
"united kingdom?"), e in effetti il nome della lettera greca è mu. A
volte anche mi, ma è solo questione di storpiatura della sua pronuncia
originale (la y greca si pronuncia come la "ue" (u+umlaut) tedesca -
dovresti sapere la pronuncia avendo un .de nell'indirizzo...)
Basta?
Ciao
PV

 Infine, muk è il mio sostituto per il vostro uk (che mi fa pensare
OK, questo era chiaro, piu` o meno.
Pero`, proprio per essere pignuoli, era uK non uk.
bye,
-- 
  Piergiorgio Sartor

Pero`, proprio per essere pignuoli, era uK non uk.
Parlavo dal punto di vista fonetico... che non è case-sensitive!
Io ho finito il discorso, se vuoi l'ultima parola, accomodati. :-)
(tanto per smentire le accuse di infantilismo) ;-D
Ciao
PV