Forum Ubuntu-it

Divilinux ha scritto: io sto leggendo qualcosa di interessante su uno dei 345 linux pro che ho sotto il letto (che e' diventato per questo un letto a castello) riguardo lo scheduling in real-time..ma va oltre le mie competenze..

Scheduling real time è quello dei sistemi real-time (tipo centrali nucleari)? Posta le parti ingarbugliate e facci annodare il cervello un po' anche a noi

Ciao,

per chi fosse interessato ad approfondire segnalo:

http://www.minix3.org/

http://www.gnu.org/software/hurd/hurd.html

http://www.gnu.org/software/hurd/gnumach.html

http://os.inf.tu-dresden.de/L4/

ciao,

Luca Cappelletti

un articolo interessante, forse ot. boh..mah..tanto e' tardi e tutti dormono.
http://natonelbronx.wordpress.com/2007/ ... e-windows/

ryuujin ha scritto: un articolo interessante, forse ot. boh..mah..tanto e' tardi e tutti dormono.
http://natonelbronx.wordpress.com/2007/ ... e-windows/

Decisamente interessante!! Anche perché può risultare comprensibile anche a chi è profano su queste cose.

Se ho capito bene, riassumendo (... e chiudendo un occhio sull'uso di termini tecnici inappropriati):
I programmi girano in due aree ben definite kernel-space e user-space. Tutto quello che gira in user-space, in caso di malfunzionamento , non compromette l'uso del sistema nella sua globalità perché il kernel con tutti i sui applicativi che agiscono alla base del sistema nel kernel-space continuano a garantirne il funzionamento.

Da qui le grosse differenze fra microkernel e kernel monolitico:
Microkernel: kernel ridotto al minimo, i vari servizi se ne stanno al di fuori nello user-space. Teoricamente si ha maggiore stabilità del kernel (e del sistema) dato che gli applicativi rimangono in user-space, però si complica enormemente il “dialogo” fra kernel e resto del sistema.

Kernel monolitico: i servizi sono inglobati nel kernel-space.
Questo semplifica il dialogo fra kernel e resto del sistema. Però un malfunzionamento in un solo applicativo del kernel può mettere a rischio il funzionamento di tutto il sistema.

Linux è un kernel modulare e al suo interno possono essere aggiunti o tolti dei moduli, che però agiranno sempre in kernel-space, quindi rimane a tutti gli effetti un kernel monolitico.
“Esistono però alcuni driver che funzionano in user-space come i driver di stampa”.

Provo a cercare una logica sulle componenti esterne al kernel Linux che in teoria dovrebbero essere interne.
A quanto si è visto tenere più cose esterne al kernel dovrebbe garantire più stabilità. Però Linus & company suppongo si siano ritrovati a tirar su un qualcosa che potesse funzionare in tempi accettabili. Quindi la minor complessità di un kernel monolitico (al di la delle proprie preferenze) ne avrà decretato il successo. Anche la difficoltà nello sviluppo di Hurd dovrebbe esserne una conferma.
Tuttavia alcune cose... avranno ben pensato di tenerle esterne. Per esempio X. In effetti avere l'interfaccia grafica inglobata nel kernel sarebbe stato un suicidio.
Quindi quello che rimane esterno al kernel sarà li o perché ritenuto troppo rischioso, o magari (molto banalmente... forse troppo) perché qualcuno si è preso la briga di creare tale componente.
Andrebbero intervistati i diretti interessati (yes)

Osservazione: il kernel di Windows, detto kernel ibrido, a quanto pare è un microkernel che gestisce tutto in kernel-space ???...... complimenti!

I programmi girano in due aree ben definite kernel-space e user-space.

In genere questo è ottenibile (non sò se è il caso di linux, ma credo di sì) tramite un bit che se settato indica che si è in modalità kernel. Le tipologie di istruzioni che possono essere eseguite in tale modalità sono tutte le istruzioni eseguibili in modo utente più quelle ritenute "a più alto rischio". Questo spiega anche perchè quando avviene una richiesta ad una risorsa (come può essere l'allocazione di ulteriore memoria, oppure la creazione di un file) non viene effettutata direttamente dal programma utente, ma viene invocato il sistema operativo che è l'unico in grado di effettuare richieste privilegiate utilizzando il modo kernel.

Quindi quello che rimane esterno al kernel sarà li o perché ritenuto troppo rischioso, o magari (molto banalmente... forse troppo) perché qualcuno si è preso la briga di creare tale componente.

Secondo me è un bene che sia così per stabilità, ma anche per una maggiore versatilità, un kernel dovrebbe fornire solo i servizi essenziali, visto che altre componenti potrebbero non essere utili all'utente (vedi interfacce grafiche)
o magari in futuro potrebbero essere rimpiazzate senza stravolgere il kernel (sostituire il server X con il nuovissimo server Y che ancora non esiste (rotfl)) . Insomma le scelte di linux si dimostrano sensate.

Secondo me una ragione plausibile è la storia di questi componenti. Ad esempio X è un server. Puoi usarlo persino da una macchina diversa da quella su cui gira (in effetti all'inizio è nato per questo). Insomma X lo devi vedere come un server Http o ftp o pop3 solo che invece di gestire pagine internet, directory e file remoti o caselle e-mail, gestisce la grafica. E lo stesso, più o meno, vale per cups.

i conti iniziano a tornare....

quindi pero la famosissima lotta linus (sostenitore dei monolitici) VS tanebaum (sostenitore dei microkernel) finisce in sostanziale pareggio...

mmm forse...