Forum Ubuntu-it

sto facendo ora il corso di Sistemi operativi e sto studiado i kernel...

in teoria pare che ho capito .... ma poi applicando la teoria al kernel linux non mi tornano i conti...

quello che ho capito io è:
  - Kernel monolitico: HW Kernel SW
    - Kernel mode: meccanismi e strategie
    - User mode: software
  - Microkernel: HW Kernel Servers SW
    - Kernel mode: meccanismi
    - User mode: strategie e software

nel monolitico il software applicativo interagisce direttamente con il kernel ... mentre nel microkernel il software applicativo interagisce con dei processi detti server (server di stampa, server grafico) che gestiscono la risorsa...

partendo la presupposto che il kernel linux è monolitico (modulare)
1) perche esiste cups che sarebbe il server di stampa?
2) perche esiste X11 che sarebbe il server grafico?

credo ce ne siano altri ....

i componenti che permettono l'utilizzo delle risorse sono
kernel, driver, server, applicazioni
il kernel è in kernelmode in entrabe le architetture
le applicazioni sono in user mode in entrambe le architetture...
i driver dove sono per le 2 architetture?
e i server?

che confusione...

In attesa che qualche matusalemme ti dia le spiegazioni che cerchi...

ti posto un famoso "battibecco" tra Linus Torvald ed Andy Tanenbaum a proposito di Microkernel vs Monolithic Kernel. La discussione è di stampo tecnico e molto interessante... considerando poi che il primo è il papà di Linux, il secondo un affermato professore universitario ed esperto di architetture a microkernel.

Correva l'anno 1992 e Win 3.1 dominava il mercato PC anche se non ancora in maniera totale come oggi, Win 3.1 NT muoveva i primi passi nel mercato business, IBM con OS/2 varava il primo OS a 32 bit per PC, MAC deteneva il 40% del mercato statunitense con la prima serie di PowerBook... e Linux era in pieno sviluppo con appena 6 mesi di vita...

Bella la storia 

hai detto bene alcune cose, ma ti confondi.. cups è un servizio, il demone che gestisce la stampa non fa parte del kernel, lo stesso vale per molti altri servizi e software in generale. le architetture di cui hai parlato sono valide non solo per i kernel, ma per gli applicativi in generale. il kenrtel di linux è monolitico, e posono essere caricati dei moduli anche in esecuizione!

Parlando di kernel monolitico o microkernel...mi sono sempre chiesto una cosa....come faccio a vedere tutti i sorgenti?...quando si parla di "open source" parliamo della sola sorgente del kernel?perchè mi piacerebbe vederla completa anche se non ci capirò niente ma voglio provare il "gusto"

Con un archittettura microkernel vengono isolati i meccanismi dalle politiche. I meccanismi sono le funzionalità più basilari del sistema operativo, come ad esempio il cambio di contesto da un processo ad un altro o anche le funzionalità per la comunicazione tra processi e solo questi aspetti vengono a formare il kernel (il minimo indispensabile). Le politiche vengono viceversa gestite da processi dedicati che fungono da server. Un esempio di politica è lo schedulatore a breve termine che deve scegliere di volta in volta quale processo assegnare al processore. In pratica possiamo decidere di rimpiazzare una politica  rimpiazzando il processo che se ne occupava senza modificare di fatto il kernel (potremmo ad esempio voler rimpiazzare il nostro vecchio schema FIFO con un più performante Round Robin, ciò che varia è la politica).

anche lo scheduler a breve termine è un server?? pensavo dovessere ewsse molto veloce nell'esecuzione e che quindi fosse quasi ovìbbligatorio includerlo nel kernel..

i sorgenti del kernel scaricali... sono una 40 di Mb però..

ermes1 ha scritto: anche lo scheduler a breve termine è un server?? pensavo dovessere ewsse molto veloce nell'esecuzione e che quindi fosse quasi ovìbbligatorio includerlo nel kernel..

i sorgenti del kernel scaricali... sono una 40 di Mb però..

si grazie...da dove?se vado su kernel.org non so dove prenderli

swimmer..li ci sono vari mirror  ::) prendine uno a caso e scarica il kernel
io li prendo da qua ad esempio

http://www.kernel.org/pub/linux/kernel/v2.6/

Divilinux ha scritto: swimmer..li ci sono vari mirror  ::) prendine uno a caso e scarica il kernel
io li prendo da qua ad esempio

http://www.kernel.org/pub/linux/kernel/v2.6/

grazie per la risposta!senti...questo va bene? "linux-2.6.21.tar.gz " non ho bisogno delle patch vero?grazie ancora!

i kernel vanilla vanno bene tutti..e tutti cosi' come sono 
se hai un computer con hardware recente..senza andare troppo indietro..il 2.6.19.2 e' uno dei migliori (come dice Torvalds)..lo uso su tutti e tre i miei pc.. (yes)

anche lo scheduler a breve termine è un server?? pensavo dovessere ewsse molto veloce nell'esecuzione e che quindi fosse quasi ovìbbligatorio includerlo nel kernel..

Dipende anche in effetti dagli obiettivi che si vogliono raggiungere, è giusto un esempio per capire, può variare tutto da  sistema opertivo a sistema operativo, si può decidere valutando prò e contro. Integrato nel kernel dovrebbe risultare più veloce (dipende sempre poi da come viene implementato) però come server esterno può essere comunque una buona scelta perchè per qualsiasi variazione può essere rimpiazzato il server, che può essere fatto anche a "caldo" e nel caso di errori del server è possibile terminarlo e riavviarne uno nuovo garantendo maggiore stabilità.
In linux essendo monolitico è di sicuro integrato nel kernel.
Io non ho mai capito se il dibattito microkernel vs monolitico ha un vincitore assoluto, anche se credo che con i multiprocessori si andrà via via verso i microkernel.

Confermo, lo scheduler è integrato nel kernel Linux, si chiama CFQ (Completely Fair Queuing) ed era citato in uno dei tweak per velocizzare  Dapper

che in linux il kernel sia integrato nel kernel non avevo dubbi.... è un kernel monolitico

sintetizzando quello che dice jack84 :
nei microkernel si dividono i meccanismi dalle politiche: lo scheduler è una politica e va in usermode.. i meccanismi per assegnare il processo al processore sono invece nel kernel ... cosi si puo cambiare politica utilizzando le stesse funzioni per selezionare il processo da mettere in esecuzione sul processore... e questo vale per ogni cosa...

questo non avviene nei kernel monolitici...: meccanismi e politiche sono entrambi nel kernel... quindi lo scheduler è integrato nel kenrel ..

e fin qui tutto torna.... infatti in linux che è monolitico nel kernel ha lo scheduler...

la cosa che non mi torna...
1 perche in linux esistono delle politiche (cups e X) che non sono integrate nel kernel, essendo un monolitico non dovrebbe avere tutte le politiche nel kernel???
2 perche su winzoz che è un microkernel modificato ha i driver (che dovrebbero essere i meccanismi) fuori dal kernel? (quando istalli un driver non devi mica ricompilare il kernel...)

queste 2 cose proprio non mi tornano....

io ti ho risposto dicendoti che l'X non fa parte del kernel.. l'architettura di cui parli non è propria solo dei kernel, ma anche di un applicativo generico! tu confondi le applicazioni con il kernel...

per quanto riguarda i driver invece non so risponderti a livello teorico con precisione, ma penso che siano anch'essi server che agiscono in kernel mode tramite chiamate al microkernel.

nei microkernel si dividono i meccanismi dalle politiche: lo scheduler è una politica e va in usermode.. i meccanismi per assegnare il processo al processore sono invece nel kernel ... cosi si puo cambiare politica utilizzando le stesse funzioni per selezionare il processo da mettere in esecuzione sul processore... e questo vale per ogni cosa...

Aspetta un attimo... lo scheduler è quella parte del sistema operativo che si occupa di assegnare i processi al processore secondo una determinata politica. Rispiego meglio quello che volevo dire.Pensiamo un attimo a cosa ci occorre per realizzare tale funzione.
In primo luogo dobbiamo fornire al sistema operativo la nozione di processo che è fondamentale prima di mettere su qualsiasi politica di selezione dei processi. Il processo come programma in esecuzione è interamente fotografato da ciò che si trova all'interno del descrittore dei processi (detto anche process control block che contiene una copia dei registiri del processore). A questo punto dobbiamo disporre di una qualche funzionalità che ci permette di fare il cosidetto cambio di contesto, ovvero poter passare da un processo ad un altro in modo da disporre della multiprogrammazione e ciò lo possiamo ottenere salvando i pcb non in uso sulla memoria centrale. Senza queste funzionalità non possiamo attuare alcuna pollitica di scheduler dei processi, poichè per selezionarli è necessario che esistano i processi e che possano essere selezionati. Decidiamo di inserire queste funzionalità all'interno del kernel  e poi sviluppiamo un modulo a parte che si occuperà di scegliere di volta in volta il processo da sottomettere. Tale modulo comunicherà al kernel tramite un meccanismo di comunicazione i processi da sottomettere e sarà il kernel a occuparsene. Questo è solo un'esempio ci possono essere meccanismi analoghi per la gestione della memoria dell'I/O, ecc...

1 perche in linux esistono delle politiche (cups e X) che non sono integrate nel kernel, essendo un monolitico non dovrebbe avere tutte le politiche nel kernel???

cups e X non sono moduli strettamente necessario al funzionamento della macchina, potresti voler rimpiazzarli con altre cose, viceversa senza lo scheduler ad esempio la macchina non potrebbe funzionare, la linea di demarcazione tra moduli che potrebbero essere contenuti nel kernel in modo integrato non credo sia così netta, ma dipende dalle scelte e comunque si preferisce adottare un approccio più "divide et impera" nel senso che è meglio sforzarsi a realizzare qualcosa con meno funzionalità che però le fà bene piuttosto che mettere tutto insieme e non riuscire più a gestire nulla, se hai un po' di esperienza di programmazione dovresti capirlo. Pensa inoltre se per caso X o cups crashassero e fossero parte del kernel il sistema inevitabilmente si bloccherebbe, viceversa come moduli esterni basta riavviarli e il gioco è fatto!
Ops ho scritto un po' troppo, se qualcuno è riuscito ad arrivare fino a quaggiù è davvero bravo (rotfl)

io ci sono arrivato a leggere fino in fondo ....

volevo premettere che sono un discreto programmatore a oggetti (c++ e java) e che conosco l'architettura dei calcolatori a grandi linee... ad esempio so cosa è il cambio di contesto ...

il tuo ragionamento è giustissimo ma non risponde alla mia domanda...

la filosofia del "divide et impera" la conosco ma da quello che ho capito non è propria del monolitico .. o no?

cioè
il microkernel ha la filosofia del divite et impera
il monolitico ha la filosofia del "tutto nel kernel per maggiore efficenza"

sono daccordissimo sul fatto che se si mettesse ad esempio cups nel kernel e si dovesse impallare saresti costretto a riavviare la macchina e quindi è giusto cosi ...

quindi (in pratica) linux non è un monolitico al 100%
ma piu che altro è un monolitico con delle idee del microkernel...

da quello che ho capito:
un monolitico al 100% ha tutti i meccanismi e tutte le strategie nel kernel ... quindi il kernel ha sia le funzioni che permettono il cambio di contesto sia l'algoritmo che sceglie quale processo mandare in esecuzione; sia la funzione che permette di contattare la stampante per stampare sia l'algoritmo che sceglie cosa stampare prima .... e questo per tutto....

un microkernel al 100 % ha tutti i meccanismi nel kernel e tutte le strategie a livello di usermode.... quindi le funzioni per il cambio di contesto sono nel kernel ma l'algoritmo per la scelta del processo di andare in esecuzione è in usermode; la funzione che permette di contattare la stampante per stampare è nel kernel e l'algoritmo che sceglie cosa stampare prima è in usermode .... e questo per tutto....




e quindi il famosissimo scontro torvalds thanebaum si risolve che in pratica non ha raggione nessuno dei 2....
perche..
per il microkernel : non è possibbile realizzarlo al 100 % perche il sistema sarebbe troppo lento : vedi windows NT e company che sono partiti da un monolitico e man mano hanno integrato delle politiche dentro il kernel...
per il monolitico: non è possibbile realizzarlo al 100 % perche il sistema sarebbe "sul filo del rasoio" ovvero troppa robba è dentro il kernel e basta che se ne impalla 1 e bisogna riavviare....


dove sbaglio?

la filosofia del "divide et impera" la conosco ma da quello che ho capito non è propria del monolitico .. o no?

Ho dato una sbirciata al kernel linux, non è che ci ho capito molto, però è modulare pur essendo monolitico, non è che sia proprio un unico main enorme per capirci (anche perchè è arrivato a una tale complessità che sarebbe impossibile da gestire). Il fatto che sia monolitico è più riferita al fatto che a girare sia un unico processo che svolge i più disparati compiti.

quindi (in pratica) linux non è un monolitico al 100%

Be direi che è monolitico perchè è senzaltro più integrato rispetto a windows e mac os che hanno kernel ibridi (tra il modulare e il monolitico), anche perchè è impossibile integrare tutto nel kernel e tra l'altro avrebbe anche poco senso, perchè renderebbe il sistema oltre che instabile facilmente anche poco adattabile a esigenze specifiche (e se io X non lo volessi? Se preferissi usare una alternativa a CUPS?)

il monolitico ha la filosofia del "tutto nel kernel per maggiore efficenza"

Questo è da valutare e sinceramente mi piacerebbe saperlo (l'hai letto da qualche parte?), nel senso che se è vero che avere un kernel monolitico riduce la comunicazione tra processi ottenendo d fatto vantaggio  in quel senso un microkernel ha il vantaggio di poter eseguire le operazioni dei processi server nello spazio utente, senza dover passare in modo kernel per poi dovervi tornare. Di fatto questa operazione non è certo onerosa come un cambio di contesto però è comunque un vantaggio. Probabilmente la risposta è semplicemente che dipende dalle implementazioni.

dove sbaglio?

Non te lo so dire se non sono giunti a una soluzione loro, non credo sia facile arrivarci. Si hanno dei vantaggi nell'uno e nell'altro e più che con quale dei due si procede ciò che conta è la qualità del codice. Forse se si inizia a scrivere un sistema operativo ora ha più senso scrivere un microkernel che risulta essere più versatile, stabile e adatto alle architetture multiprocessore moderne (kernel e server possono essere eseguiti in parallelo, viceversa con il monolitico và in esecuzione solo il kernel se non ci sono altre applicazioni pronte il processore resta inutilizzato in parte)

2 perche su winzoz che è un microkernel modificato ha i driver (che dovrebbero essere i meccanismi) fuori dal kernel? (quando istalli un driver non devi mica ricompilare il kernel...)

Be perchè la distinzione non è poi così netta e dipende dai vantaggi che se ne derivano, come hai detto te non c'è bisogno di ricompilare il kernel (anche perchè per fare una cosa simile dovresti fare una telefonatina alla microsoft ) e quindi questa è la soluzione che si è ritenuta più idonea. Non ho la più pallida idea di come funzioni, provo a dare un'ipotesi, magari è implementato come metodo nel kernel un tipo di controller generico in grado di dialogare con lo specifico modulo che gestisce il singolo hardware.
Sono stato anche più prolisso di prima e spero che qualcuno possa chiarirci i dubbi.
Non è che qualche moderatore potrebbe sticcare per un po' questo topic da aumentargli la visibilità per un po'

per evitare che devi riscrivere tutto questo ogni volta? 
io lo stikko..mi assumo la responsabilita' (tanto poi lo so che sto sbagliando  :-[)

per evitare che devi riscrivere tutto questo ogni volta?  Grin
io lo stikko..mi assumo la responsabilita' (tanto poi lo so che sto sbagliando  Embarrassed)

Be sì in effetti non è bello ricominciare sempre da capo il discorso
Magari può essere interessante approfondire se qualcuno che ne sà di più lo nota e ci illumina sarebbe bello. :P

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..