Sistemi operativi... come sono fatti?

[nirvana]

Caspita , interessante spetta non sono ancora riuscito a leggermi il terzo post che gia ne haib sparati giu altri tre , intanto bravo credo che questo chiarisca un po piu le idee.

[htsoft]

Finora, probabilmente lo avrete notato, non ho praticamente mai citato l'utente ma solo i processi, parlando di S.O., come mai? Come fa l'utente ad adoperare un S.O.?

In realtà, stiamo parlando di teoria, l'utente non usa mai direttamente il S.O., si limita ad usare i programmi applicativi che, a loro volta, usano il sistema operativo.
Quando avviate un terminale su Linux o su OsX, oppure il prompt dei comandi da Windows, state non solo avviando il terminale, ma contemporaneamente anche un software applicativo denominato Shell.
Questa shell si occupa di ricevere i vostri comandi (sotto forma di parole o sigle) effettuare dei controlli e quindi se si tratta di comandi che è in grado di interpretare direttamente (gli script di shell o i comandi per settare le variabili d'ambiente) li lavora, altrimenti cerca il comando, sotto forma di file eseguibile, e lo avvia.
Il bello è che esistono tanti tipi diversi di shell, ognuno con la sua peculiarità, ma la cosa più interessante è che, essendo programmi applicativi, possono essere tutte presenti contemporaneamente nel sistema e possono essere avviate anche in parallelo tra di loro. Proprio in virtù del fatto che, non essendo integrate nel Kernel, non necessitano la sua ricompilazione per essere cambiate.
Questo, come è facile intuire, permette praticamente a chiunque di crearsi il proprio ambiente di lavoro ritagliato su misura.
Ora però abbandoniamo l'interfaccia a carattere, ci ritroviamo, quasi sempre, su di un ambiente più familiare, ci sono finestre, barre dei menu, mouse, icone. Bene anche tutto ciò per un sistema operativo è un programma (o un insieme di programmi in questo caso) applicativo e ricade anch'esso sotto il termine shell.
Esistono quindi due tipi di shell:
- CLI (Command Line Interface)
- GUI (Graphical User Interface)

Un sistema operativo le vede, entrambe, come come processi ben distinti, e questo è il vero vantaggio di quest'approccio. Vediamo perchè. Supponiamo che vi troviate nel caso in cui la GUI sia bloccata. Il fatto che essa lo sia non significa che lo è anche il S.O., anzi questo probabilmente starà facendo altre belle cose nel frattempo. Vi è però necessario spegnere la macchina in modo corretto (questo dovrebbe essere così sempre). Come procedete?
I S.O. permettono di avviare, in genere, sessioni multiple, sulla stessa macchina o anche remotamente, vi basta avviare tale sessione, entrando con un'altra shell, e quindi, tramite appositi comandi, potete decidere di ammazzare la shell bloccata (o il processo che la blocca) o fare semplicemente lo shutdown di tutto.
Questo è il primo e basilare meccanismo di sicurezza di tutti i Sistemi Operativi, i programmi applicativi possono sempre essere interrotti.
Fu per questo che quando ci furono Windows 95/98/Me la comunità internazionale chiedeva il multitasking non-preempitivo, proprio per garantirsi dalla possibilità di poter sempre interrompere un processo cattivo.
Su Linux le GUI si basano su un processo intermedio tra loro ed il kernel, nella sua attuale incarnazione si chiama XFree86, fornisce una serie di primitive per disegnare e gestire le finestre sullo schermo. il KDE, lo GNOME sono invece le specializzazioni grafiche di tali metodi. Introdurre una funzionalità nell'XFree la rende immediatamente disponibile su tutti gli ambienti che lo sfruttano, sarà poi compito loro adoperarla.
La GUI di OsX è il Finder con la sua personalizzazione Aqua, se chiamate la funzione dal menu mela per l'uscita forzata lo trovate li e se volete potete anche chiuderlo.
Sia su Linux che su OsX potete chiudere i processi relativi alle GUI, questo non significa che avete fermata il S.O. solo non potete più usare mouse e finestre.
Quali sono quindi i vantaggi? Il primo e più evidente è la robustezza e la sicurezza. Una shell non potrà mai bloccare il S.O., mai. Inoltre, su OsX non si potrebbe, insomma, ma su *nix si, se non devo usare mouse e tastiera e se non mi servono le finestre (ad esempio quando allestisco un server), posso decidere di non caricare la GUI ma optare per la CLI e quindi risparmiare un bel pò di risorse, sia in termini di RAM che in termini di impegno del processore.
GLi svantaggi? Beh se uso una GUI sui sistemi di questo tipo ho quello che chiamo effetto ovatta. In pratica il feedback relativo ad una nostra azione è leggermente più lento, quasi come se non fosse messo perfettamente a fuoco. E' come percepire la sensazione che la freccia del mouse che si muove sullo schermo sia ai nostri ordini, non una parte di noi.
Microsoft ha seguito un approccio leggermente differente, d'altronde si chiama Windows mica usix, ed ha preferito integrare la gestione della GUI all'interno del sistema operativo, o meglio ha reso alcuni processi della GUI in grado di girare a livello system (il centro del bersaglio). In effetti quando parliamo di Windows non siamo mai in grado di dire nettamente dove finisce il kernel e dove comincia la GUI, ed infatti la GUI di Windows si chiama Windows, ed il kernel? Windows!
Questo cosa comporta?
Prima i lati positivi: il feedback è, spesso, istantaneo, l'effetto ovatta è non percepibile, il mouse che si muove sullo schermo sembra effettivamente un'estensione del nostro corpo. Inoltre la possibilità di interagire con la grafica così a basso livello permette alle applicazioni performance migliori. Le DirectX sono a tutti gli effetti una parte del S.O. oramai da tempo, ed alcuni dei processi che ne fanno parte girano anch'essi a livello system, ecco quindi che giochi, modellatori ed altro offrono performance di tutto rispetto.
I lati negativi: la sicurezza e la stabilità, purtroppo, sono molto più basse dell'altro approccio. Vediamo il perchè: se eseguo una funzione della GUI a livello system, sapendo che non può essere interrotta, se tale funzione si blocca, allora tutto il sistema si blocca, irreparabilmente. Non posso neanche tentare di effettuare l'operazione di spegnimento o kill che ho descritto sopra, questo perchè il sistema sta eseguendo una funzione a livello system e non gli interessa nient'altro.
Ma anche se il sistema non si blocca posso farne crollare le prestazioni chiamando in modo molto frequente una funzione della GUI eseguita a livello system da un processo ad alta priorità in questo modo interrompo letteralmente il multitasking.
Inoltre se la GUI è parzialmente integrata nel kernel o comunque non è un processo ben definito a se stante, non posso fare a meno di caricarla. In pratica se allestico un server web (dove dell'interfaccia grafica non so che farmene) dovrò comunque rinunciare ad una bella fetta delle mie risorse che quindi non potranno essere sfruttate per servire gli utenti (in genere su un server Windows al boot mi gioco, senza colpo ferire e senza applicativi installati, anche 256 MB di memoria, quasi tutti assorbiti dalla GDI e dai driver precaricati). Da questo si evince che Windows non è nato con il concetto di multiutenza ma di s.o. multitasking monoutente e, anche se qualcuno stenterà a crederlo, è così anche per le versioni server.
Windows Server 2008 potrebbe introdurre una modalità di lavoro solo testo senza GUI. Ma per ora non posso ancora pronunciarmi, ne riparliamo a fine mese quando esce.

[g4dual]

WOW ... spettacolo!

[Bruscolì]

Ciao Roberto complimenti per l'iniziativa, stai praticamente scrivendo un libro online.
Avrei alcune domande relative ai kernel e linux che sono argomenti di cui mi piace leggere.

Ho letto che hai scritto che linux è una personalizzazione di minix ... quello che sapevo per letture varie è che il primo kernel di linux è stato riscritto con le specifiche posix, da Linus Torvald proprio perchè non era soddisfatto di minix ... è sbagliato ??
E inoltre non sono diversi i kernel dei due sistemi ?? Cioè linux utilizza un kernel monolitico mentre minix utilizza un microkernel, che non so cosa sia di preciso ma che sapevo essere due architetture differenti !! Infatti ci fu anche la storida discussione tra i due sviluppatori ...

La distinzione che hai fatto relativa ai tipi di kernel "monolitico" e a "link dinamico" è quella che in linux si fa compilando un kernel senza moduli oppure con moduli caricabili quando necessario ??

Ultima domanda ma Darwin non era un sistema operativo free ?? Il kernel del mc os x non si chiama XNU ??

Spero di non essere andato OT con le mie domande dato che i tuoi post sono molti tecnici e le mie domande più superficiali ... ma mi piace leggere ed essere informato su queste cose

Fulvio

EDIT: ... un'altimissima domanda ... quando parli di windows e del fatto che ha un kernel monilitico ... è questo il motivo per cui ogni vota che si installa un driver bisogna riavviare il sistema operativo ??
Grazie

[Fire]

Dunque Roberto, in linea di massima tutto chiaro escluso un punto sul quale torni spesso e che di fatto, dice esattamente il contrario di quello che ricordo io . Sicuramente sbaglierò io (e ci mancherebbe ) essendo le mie solo riminiscenze, ma come "Amighista", conosco il significato della parola multitasking da molto tempo e quello che ricordo è che uno dei vantaggi del multitasking reso disponibile da Amiga all'epoca, era il fatto che si trattava di un vero e proprio multitasking, ma che sopratutto, si trattava di un multitasking di tipo "preemptive", ...mentre la "concorrenza" d'allora al limite poteva esser dotata di uno di tipo "cooperativo". Amiga disponendo poi anche di Chip Custom dedicati, poteva permettersi allora molti lussi, alcuni dei quali rimasero persino imbattuti, come ad esempio quello di poter aprire schermi multipli contenenti i vari task e poterli poi controllare come fossero delle normali finestre, o di poter eseguire in "parallelo" diverse operazioni, (ricordo che per ridimensionare "l'utenza avversaria", essenzialmente windows, bastava chiedere di formattare un Floppy Disk mentre si compiva un'altra operazione! ). Il multitasking implementato in Amiga, (insieme ad altre caratteristiche pressochè uniche per quel periodo), consentiva alla macchina prestazioni interattive e multimediali impensabili per l'epoca sopperendo in seguito spesso anche a qualche carenza dell' HW quando questo divenne obsoleto permettendogli così una inusitata longevità. Un'ultima curiosità, anche il SO di Amiga discende da Unix e il sistema della memoria protetta causa di tanti Guru Meditation che gli Amighisti ben ricordano, fu poi risolta in ritardo con la versione 4 di AmigaOS.

Da quello che avevo capito io allora quindi, i multitasking, (mi riferisco a quelli implementati nelle macchine dell'epoca), erano essenzialmente di due tipi:

- Quelli "Cooperativi", ossia dove lo scheduler non dispone di prelazione, nel qual caso questo può attuare un cambio di contesto solo nel caso del passaggio di un programma da uno stato all'altro, nello specifico, dallo stato di attesa (standby), a quello di esecuzione (run) e nel caso del termine del programma (end). Nel M.T. di tipo "cooperative", i processi cedono "automaticamente" il controllo al S.O. quando hanno espletato il loro compito. Questo sistema ha il vantaggio di non richiedere uno specifico supporto HW essendo quindi slegato dall'architettura della macchina su cui gira, ma al contempo ha il grave svantaggio che se uno di quei processi si blocca, o per un qualsiasi motivo comunque non ne cede il controllo, il rischio è la paralisi del sistema, in quanto il S.O. da solo non ha la capacità di riprenderne "le redini". Da quanto ne so questo sistema era adottato nelle versioni di Windows sino alla 3.1 e da MacOS sino alla versione 9.

- Quelli "Preemptivi", dove invece lo scheduler dispone delle capacità di prelazione, che sostanzialmente ricordo consistere nella capacità di interrompere un programma indipendentemente dalla disponibilità di quest'ultimo ad eseguire il comando. Questa capacità di prelazione consente sostanzialmente un cambio di contesto molto efficente con un conseguente miglior temporizzazione nelle applicazioni che da un punto di vista dell'utente si traduce anche in una maggior fluidità apparente fra i task. Perchè ciò sia possibile però, è necessario soddisfare determinati requisiti HW, senza i quali non possono attuarsi determinati automatismi che consentano il cambio di applicazione tramite "context switch". Il MT Preempitive ha quindi uno scheduler con delle possibilità in più, non solo quella di poter intervenire dal passaggio dallo stato di esecuzione a quello di attesa (come per il MT Cooperative), ma anche nel passaggio fra altri stati, ossia di quello di un programma dallo stato di esecuzione (run) allo stato di "pronto per essere eseguito" (RTR, Ready To Run) e dallo stato di attesa (standby) allo stato di pronto per essere eseguito (RTR).

Quello che non mi quadra quindi e che da ciò che dici, sembrerebbe essere un vantaggio avere un M.T. non-preempitivo, quando io ricordavo invece fosse giusto il contrario. Di certo ricorderò male io (e su questo non ho dubbi ), ma visto che ci siamo approfitto della tua estrema disponibilità e competenza per togliermi anche questa curiosità.

Continua così!
Fabio.

[htsoft]

Ciao Roberto complimenti per l'iniziativa, stai praticamente scrivendo un libro online.
Avrei alcune domande relative ai kernel e linux che sono argomenti di cui mi piace leggere.

Ho letto che hai scritto che linux è una personalizzazione di minix ... quello che sapevo per letture varie è che il primo kernel di linux è stato riscritto con le specifiche posix, da Linus Torvald proprio perchè non era soddisfatto di minix ... è sbagliato ??
E inoltre non sono diversi i kernel dei due sistemi ?? Cioè linux utilizza un kernel monolitico mentre minix utilizza un microkernel, che non so cosa sia di preciso ma che sapevo essere due architetture differenti !! Infatti ci fu anche la storida discussione tra i due sviluppatori ...

La distinzione che hai fatto relativa ai tipi di kernel "monolitico" e a "link dinamico" è quella che in linux si fa compilando un kernel senza moduli oppure con moduli caricabili quando necessario ??

Ultima domanda ma Darwin non era un sistema operativo free ?? Il kernel del mc os x non si chiama XNU ??

Spero di non essere andato OT con le mie domande dato che i tuoi post sono molti tecnici e le mie domande più superficiali ... ma mi piace leggere ed essere informato su queste cose

Fulvio

Ciao Fulvio,
hai decisamente centrato il problema per quanto riguard Linux. In effetti ho semplificato troppo io dicendo che Linux è una personalizzazione di Minix, in realtà Linus Torwalds lo riscrisse appunto secondo le specifiche Posix, ma la scintilla la lanciò proprio Minix con il suo tentativo di riscrivere un sistema Unix like in qualche modo OpenSource.
In realtà col tempo la visione del kernel monolitico di Torwalds si è sfaldata e vediamo il perchè.
Definizioni:
- Un kernel monolitico è un programma che implementa al suo interno, in un unico blocco la gestione dell'hardware sottostante (in pratica, ad esempio non fa uso di device drivers e pertanto se si cambia l'hardware va ricompilato)
- Un microkernel è invece un insieme di programmi (tipo macchine virtuali) che concorrono tutti insieme ad astrarre dall'hardware secondo determinate specifiche.
Quali sono dunque queste macchine virtuali? Sono tutte quelle che realizzano un'interfaccia tra il nucleo del sistema e l'hardware. Ad esempio i device driver delle schede video.
Uno dei più famosi sistemi operativi a microkernel era quello di Amiga.
Un altro microkernel (anche se non è corretto definirlo così) è XNU che è la base di Darwin che è il sistema operativo di Apple ovvero OsX senza il finder. Oggi si tende spesso a semplificare (lo so è scorretto, ma anche io ho pensato che era inutile scendere fin da subito nei dettagli di ogni singolo sistema operativo) e quando si parla di kernel di OsX lo si chiama Darwin.
Inoltre Darwin è rilasciato sotto licenza OpenSource, infatti ad ogni rilascio del sistema operativo Apple rilascia anche i sorgenti (si avete capito bene ci sono i sorgenti di Leopard disponibili). OpenDarwin è la branca completamente free di Darwin ed è nata dalla collaborazione tra Apple ed un bel gruppo di sviluppatori volenterosi (spesso, anzi, Apple ha beneficiato di questa politica, riducendo enormemente i costi).
In realtà XNU non è un microkernel completo ma un ibrido, esso è il risultato della fusione di due famosi kernel: Mach (microkernel) e FreeBSD (in un altro messaggio avevo scritto BeOS, chiedo scusa, sono un citrullo).
Quest'approccio, seguito da quasi tutti i sistemi operativi moderni (tra cui, anche se in maniera meno sbandierata, gli ultimi kernel linux, ed ecco dove ha fallito Torwald) consiste nel creare un blocco monolitico in cui risiedono tutte quelle funzioni hardware indipendent o che comunque presuppongono di trovare almeno determinati componenti (ad esempio lo schedulatore risiede qui), mentre si lascia decentrato, nella sezione esterna, tutto ciò che è hardware dipendent o comunque non critico (device driver ed altro).
Quindi, e rispondo così al tuo ultimo quesito, un kernel monolitico è quello senza moduli mente un microkernel è un kernel con caricamento di moduli separato (purchè indipendenti ed in qualche modo autosufficienti).

[htsoft]

Ciao Fabio,
Non-Preempitivo e Cooperativo non sono la stessa cosa.
Cooperativo, come hai detto tu, significa che è il programma a scegliere quando cedere il controllo (in genere chiamando una funzione del sistema operativo).
Non-Preempitivo prevede il discorso del bersaglio. Ovvero solo i processi di livello più interno (in genere si tende a limitare il tutto a livello system ovvero di kernel) non possono essere interrotti. Ed il motivo è semplice, se avvio la scrittura di un settore del disco non posso essere interrotto, in nessun modo in quanto la risorsa è singola non condivisibile durante la fase di scrittura.
I processi a livello system (o kernel per semplificare) sono brevi, efficienti e sono quelli che accedono all'hardware ed in genere le risorse fisiche, per questo non sono interrompibili. Tutti i processi che non lavorano a questo livello invece si.
Il concetto di non preempitivo è quindi d'obbligo.
Il fatto di bloccare le interruzioni è fondamentale e vediamo il perchè:
Abbiamo detto che un un multitasking collaborativo prevede che i processi siano così buoni da rendersi conto di non esistere solo loro e quindi di tanto in tanto fanno respirare anche gli altri.
Un multitasking preempitivo invece prevede che sia il sistema operativo a decidere chi deve lavorare in un determinato istante. Ma come fa ad intervenire lo schedulatore in questo caso?
Lo schedulatore usa un hook (uncino) sull'interrupt del timer (Eh?).
In pratica il nostro hardware divide un secondo in 50 tick, ad ogni tick interrompe le normali operazioni ed esegue una routine di aggiornamento dell'orologio, tale operazione prevarica tutte le altre (in realtà in un determinato istante possono accadere più interrupt contemporaneamente tramite un meccanismo denominato livello viene stabilito l'ordine di esecuzione).
Lo schedulatore non fa altro che mettersi in coda alla routine di aggiornamento, così appena le termina inizia a lavorare lui.
In quel momento lui è "PATRONE TI MONTO" e tutti dipendono da ciò che vuole lui, è lui che "CONTROLLA IL PROGRAM COUNTER (BUA BUA BUA)".
Ora immagina che tu stia facendo la free() di una cella di memoria. Ed accade il "Mortal Interrupt" tu cosa fai lasci l'operazione a metà?
Se si tratta di pochi byte va pure bene, ma se stai deallocando 1 Mb allora la cosa diventa seria.
Ecco quindi che finchè non hai finito nessuno può interromperti. Dopo facessero quel che vogliono. Ecco a cosa serve il multitasking non preempitivo (ricordati che questo vale solo se esiste il concetto dei livelli nel S.O. altrimenti il concetto di non preempitivo non esiste).


(Per la cronaca sono un amighista anche io, lo programmavo, usavo il Lattice C originale, anzi forse sono l'unico in Italia ad aver montato su un Amiga 2000 il genlock e la scheda Janus AT, ed ancora oggi me lo piango quel sistema, in linea teorica con i dovuti adeguamenti hardware, darebbe la birra a tutti).

[htsoft]

Piccola aggiunta:
Windows 3.1 - Cooperativo
Windows 95/08 - Preempitivo (senza livelli)
Windows NT/2000/... - Preempitivo per i programmi, non preempitivo per i processi del kernel.

Così forse sono più corretto.

Roberto

[Fire]

Ecco spiegato l'arcano, ...davo per scontato qualcosa che non lo era assolutamente , (però ...me lo sentivo che c'era un "terzo incomodo"), ...altrimenti le cose non "quagliavano"! Grazie per il chiarimento!

(Per la cronaca sono un amighista anche io, lo programmavo, usavo il Lattice C originale, anzi forse sono l'unico in Italia ad aver montato su un Amiga 2000 il genlock e la scheda Janus AT, ed ancora oggi me lo piango quel sistema, in linea teorica con i dovuti adeguamenti hardware, darebbe la birra a tutti).

No scusa, guarda ma qui pecchi di presunzione , ...ricorda che LWITA è una "tana d'Amighisti", ... e poi solo nella mia città ne conoscevo almeno 5 di utenti dotati di Amiga2000 e genlock + Janus+ HD (che lusso!!). Scherzi a parte, per conto mio posso dirti che son partito con un 500 gonfiato all'inverosimile (schede accelleratrici con 68020 e 30 espansioni di memoria etc..), per farmi poi tutto l'escursus sino ad Amiga4000 (anche questa super espansa) con 68040 e scheda grafica PicassoII e genlock esterno, c'havevo collegato di tutto e lavorando per studi professionali che adottavano sistemi analoghi al mio, ho utilizzato persino dei controller BCD (acquistato direttamente negli USA) per la registrazione della animazioni a passo 1 su Betacam, per il quale fummo costretti a editarci da soli tutti gli script di controllo... ...che tempi!

Mi fermo qui per non "inquinare" troppo ( l'ho già fatto abbastanza), ...mi sento quasi un "virus" in questo bel topic.

Fabio.

[Slade]

Grazie un miliardo...ke spettacolo...finalmente si inizia a capire perchè il povero windows sembra apparentemente meno performante

Corregimi se sbaglio...quindi i sistemi UNIX sono piu' stabili perchè dividono la GUI rendendola un applicativo, quindi si può sempre interrompere, mantenedndo il OS attivo...invece windows non ha questa divisione nette, risultando, a meno di blocchi e a parità di hardware, piu' performante...

Ho capito giusto o no...usando parole spicciole?