Il software di base. pappalar

Transcript

1 Il software di base Fonte Introduzione ai sistemi informatici Sciuto D., Buonanno G., Fornaciari W., Mari L. Edizioni McGraw-Hill (1997) (Capitolo 4) Copia dei lucidi on line pappalar ( ) 1:1/28 (p.1)

2 Architettura dei sistemi Architettura (essenziale) di un sistema (informatico): hardware (hw) software applicativo o applicazioni, usato da/implementato per l utente finale P.es. programmi gestionali, di office automation, di calcolo,... sw di base o di sistema, caratterizzato da: non è direttamente utile all utente finale necessario alle applicazioni (per funzionamento/uso o sviluppo) Esempi di software di sistema: compilatori/interpreti consentono sviluppo/esecuzione di programmi in linguaggi ad alto livello interfaccia d utente gestisce l interazione tra utente e sistema; può essere grafica (GUI) o testuale (p. es. command.com di MS-DOS) sistema operativo (SO) strato di sw interposto tra applicazioni e hw I maggiori esempi, oggi, sono Unix e Windows. Architettura dei sistemi ( ) 1:2/28 (p.2)

3 Nozione di sistema operativo [Pagina intenzionalmente vuota] Nozione di sistema operativo ( ) 1:3/28 (p.3)

4 Il S.O. come macchina virtuale Modalità di interazione tra SO e il resto del sistema: Software Hardware Istruzioni l. macchina Applicazione CPU+memoria system calls SO Applicazione Interfaccia/Servizi SO Computer I/O (Periferiche) Le frecce simboleggiano interazioni; in particolare ho usato: frecce singole per l esecuzione di istruzioni (da parte della CPU) frecce doppie per indicare che un componente software ne chiama un altro (quello puntato), ottenendone dei servizi; concettualmente, chiamata e servizi connessi sono una singola interazione sw, detta system call se va da applicazione a SO (materialmente, un interazione sw è iniziata da un apposita istruzione e dà luogo a più istruzioni eseguite dalla CPU.) La figura suggerisce che le applicazioni interagiscono con le periferiche: non direttamente, con istruzioni CPU ma indirettamente, via system call (per una motivazione, v. pag. 8) La CPU è una macchina elettronica che esegue istruzioni CPU. Per analogia, anche il complesso CPU+SO si può vedere come una macchina che esegue istruzioni CPU+system call; si tratta di una: macchina virtuale = non (interamente) materiale macchina estesa: ha istruzioni estese (system call) ed estende (v. pag. 6) i servizi forniti dalla CPU Nozione di sistema operativo ( ) 1:4/28 (p.4)

5 Il SO come gestore di risorse Il SO si può vedere in realtà sotto una duplice veste: macchina virtuale (insieme con l hw), gestore delle risorse del sistema. Le nozioni (1) e (2) sono complementari. Esempi di risorse: processori memorie timer dischi terminali interfacce di rete stampanti file Nozione di sistema operativo ( ) 1:5/28 (p.5)

6 Servizi dei SO I servizi forniti dal SO si possono ricondurre a uno dei suoi due ruoli. Il SO/macchina virtuale fornisce al sw utente un astrazione semplice di realtà più complesse: funzionamento dell hw (interrupt, temporizzazioni etc.) organizzazione della memoria di massa organizzazione della memoria centrale presenza di altro sw utente Il SO/gestore di risorse presiede a 1. accesso disciplinato ad esse e 2. per certi SO e risorse, replicazione virtuale di queste in questo caso (2) il SO si può vedere, oltre che come gestore di risorse, come macchina virtuale estesa (v. p. 7). Per (1) SO alloca risorse ai programmi, arbitrando richieste incompatibili Le risorse possono essere condivisibili (es. file in lettura) o no (es. stampante) Alcuni gruppi di servizi di supporto all allocazione: attribuire un proprietario alle risorse registrare a chi è in uso ogni risorsa in ogni istante rispondere alle richieste di accesso arbitrare in modo equo ed efficace in caso di conflitti tra richieste registrare l uso passato delle risorse (p.es. per l addebito) ( ) 1:6/28 (p.6) Nozione di sistema operativo

7 Virtualizzazione di risorse fisiche e multiprogramming Multiprogramming e time-sharing sono la regola per i SO di oggi. SO multiprogrammato: più programmi oltre al SO risiedono in memoria. Job 3 Job 2 Job 1 Memory partitions Operating system SO (multiprogrammato e) time-sharing: più programmi procedono in parallelo usando la/le CPU a turni di ms (a ogni istante, ogni CPU esegue un istruzione di un solo programma). Un programma in corso di esecuzione si dice processo: un processo è caratterizzato da programma + stato(=valori dei dati) un SO multiprogrammato permette più processi concorrenti Nel fornire i servizi per la multiprogrammazione, il SO funge insieme da: macchina virtuale/estesa: ogni (utente di) programma si illude di avere un sistema (CPU+memoria+I/O) privato gestore di risorse: la multiprogrammazione presuppone una turnazione nell uso delle risorse (specie CPU) N.B.: nell accesso alle risorse (v. p. 6), conflitti e opportunità di condivisioni scaturiscono proprio dal multiprogramming. ( ) 1:7/28 (p.7) Nozione di sistema operativo

8 SO: Motivazioni Perché non incorporare direttamente nelle applicazioni (alcune o tutte) le funzionalità del SO? Per una certa funzionalità F (p.es. accesso al disco), quest alternativa è rappresentata dallo schema di destra (a sin., la soluzione standard) Applicazione Applicazione Applicazione F Applicazione F F SO SO Ma la 2a soluzione è da scartare per varie ragioni (v. oltre), che giustificano l esistenza dei SO. efficienza (spazio di memoria): il codice relativo verrebbe replicato più e più volte, per ogni applicazione qualità: il SO (sviluppato ad hoc, da esperti) può implementare meglio di ciascuna applicazione le funzionalità richieste costi: ciascuna applicazione sarebbe di sviluppo più oneroso (dovendo reinventare la ruota ) compatibilità condivisione e cooperazione: probabili conflitti tra applicazioni se esse gestissero direttamente le risorse impossibilità di comunicare senza un substrato SW comune sicurezza e protezione: l accesso all hw via SO è protetto (soggetto a controllo delle autorizzazioni); l accesso diretto da parte delle applicazioni sarebbe indiscriminato Nozione di sistema operativo ( ) 1:8/28 (p.8)

9 SO: Motivazioni L architettura Software Hardware Istruzioni l. macchina Applicazione CPU+memoria system calls SO Applicazione Interfaccia/Servizi SO Computer I/O (Periferiche) ovvero, più astrattamente Applicazione interfaccia Sistema Operativo (SO) Hardware (Hw) comporta ulteriori vantaggi. standardizzazione e stabilità: ci sono molti meno SO che varietà di hw l interfaccia/servizi (insieme di system call) di un SO è più stabile dell interfaccia dell hw; da ciò portabilità e modularità (v. sotto) portabilità un applicazione gira su hw diversi purché questi supportino lo stesso SO convertire un applicazione per un nuovo hw+so prescinde comunque dai dettagli hw (importa solo l interfaccia del nuovo SO) modularità: applicazione e utenti sono schermati da modifiche/innovazioni di hw e parti interne di SO, a patto che l interfaccia del SO non muti. Nozione di sistema operativo ( ) 1:9/28 (p.9)

10 [Pagina intenzionalmente vuota] ( ) 1:10/28 (p.10)

11 Livelli e macchine virtuali Un sistema sw si dice organizzato a livelli se: si possono raggruppare i suoi componenti in insiemi L 1, L 2,..., L n, L n+1,... detti livelli se, per ogni n, L n+1 usa solo i servizi dei livelli inferiori L n, L n 1,..., ma non superiori L n+1 L n L 2 L 1 servizio macchina virtuale Come al solito i livelli dal più basso L 1 al generico L n si possono vedere come una macchina virtuale che offre servizi ai livelli superiori. Il presupposto è che ogni livello, p.es. L n, aggiunga funzionalità ai livelli inferiori, astragga da complicazioni eccessive dei livelli inferiori fornisca un interfaccia semplice, potente, intuitiva ai livelli superiori Tipica organizzazione a livelli di un SO: ( ) 1:11/28 (p.11)

12 Il nucleo Livello più interno: scambia dati direttamente con l hw riceve segnali elettrici (interrupt) dall hw virtualizza la CPU per ogni programma in esecuzione (processo), mascherando la competizione con gli altri per la CPU regola i conflitti tra processi per le risorse consente la comunicazione e la sincronizzazione tra processi La virtualizzazione della CPU per sw sopra il livello 0 si può raffigurare così: ( ) 1:12/28 (p.12)

13 Il gestore della memoria Problemi: memoria limitata (costo) numero di processi elevato (in rapporto alla memoria) protezione della memoria allocata per ciascun processo Soluzione (in questo livello): virtualizzazione memoria per ciascun processo. Risultati: per ciascun processo, spazi di memoria virtuali indipendenti, mappati ognuno su un area di RAM: aree per lo più disgiunte protezione dei dati (rispetto ad altri processi) aree talora coincidenti in modo controllato condivisione dati spazi di memoria virtuale molto più grandi della RAM disponibile: p.es. 4GB di memoria virtuale (per processo) contro 32MB di RAM la parte di memoria virtuale che non entra nell area di memoria fisica assegnata al processo risiede su disco il SO trasferisce automaticamente informazione tra disco e RAM (paginazione, swapping) in modo che il processo abbia l illusione di disporre davvero di tutta la memoria virtuale ( ) 1:13/28 (p.13)

14 Il gestore della memoria: memoria virtuale Insieme, kernel (livello 1) e gestore della memoria (livello 2) virtualizzano, per ogni processo, una macchina quasi completa: CPU+Memoria: ( ) 1:14/28 (p.14)

15 Gestione delle periferiche I gestori delle periferiche (driver) offrono ai livelli superiori delle periferiche virtuali: di accesso facile, indipendente da hardware, temporizzazioni etc. ma che non sono, diversamente da CPU e memoria, repliche virtuali fedeli: p.es. il disco visto attraverso il driver è lo stesso per tutti i processi: il settore 300 è lo stesso per tutti i processi. viceversa, il byte all indirizzo 300 di memoria per il processo P è distinto dai byte 300 dei processi Q, R,... ( ) 1:15/28 (p.15)

16 Gestione dei file Molti SO (p.es. Windows e Unix) organizzano l informazione da scambiare in Input/Output in file (=documenti), ovvero sequenze di byte; la natura dell informazione associata alla sequenza di byte è varia (programmi, caratteri, numeri), ma non ha rilevanza per il sistema operativo (semmai ad applicazioni/utenti) Il gestore dei file (file system) fornisce ai livelli superiori l astrazione costituita dall oggetto file: come al solito, un file non esiste in senso materiale l oggetto file ha natura virtuale o astratta Su oggetti di tipo file, il sw che si appoggia al file system può compiere varie operazioni, p.es.: leggerne l informazione scrivervi informazione crearlo/cancellarlo/copiarlo spostarlo tra contenitori virtuali (directory) definire diritti di accesso ai file ( ) 1:16/28 (p.16)

17 Supporto di rete È integrato nel SO. Dovrebbe godere di alcune caratteristiche chiave: condivisione delle risorse p.es. computer di una grande organizzazione (banca etc.) openness (=apertura) cioè soprattutto interoperabilità per programmi e sistemi diversi, ma aderenti a standard comuni concorrenza (=parallelismo) scalabilità (=capacità di cambiare scala senza problemi) tolleranza ai guasti trasparenza cioè astrazione da separazione/distribuzione (per programmatore di applicazioni/utente Tra le (categorie di) requisiti più importanti, per un SO di rete: prestazioni affidabilità scalabilità coerenza (tra eventuali repliche di dati) sicurezza ( ) 1:17/28 (p.17)

18 Programmi di utilità I programmi di utilità non sono in genere parte del SO, ma ne costituiscono un corredo : ampliano le funzionalità del SO, sono di interesse generale e di supporto ad altre attività (Le applicazioni propriamente dette sono finalizzate ad attività specifiche dell utente finale.) Esempi: editor (crea/modifica file testo) compilatori (generano programmi eseguibili da programmi in linguaggi ad alto livello) debugger (aiutano a trovare gli errori in un programma) backup, controllo e ottimizzazione di dischi programmi di test (del sistema) ricerca e sostituzione di testo ( ) 1:18/28 (p.18)

19 Interfaccia d utente L interfaccia d utente può o no (p.es. Unix) far parte del SO in senso stretto. In ogni caso, architetturalmente si appoggia al resto del SO (v. grafico a p. 11). Compiti dell interfaccia d utente: rilevare e interpretare gli input dell utente (tipicamente via tastiera e mouse) reagire a questi come previsto dalle specifiche. Le interfacce d utente grafiche (GUI), p.es. MS-Windows, sono: user-friendly (amichevoli) e intuitive potenti molto ricche di funzionalità e modalità di interazione ( ) 1:19/28 (p.19)

20 Interprete dei comandi È il nome di un interfaccia d utente testuale; più specificamente, si chiama shell in ambito Unix, command.com in ambito Windows. Sotto command.com (menù Avvio, Programmi, Prompt di MS-DOS) lo schermo di un PC si presenta all incirca così: C:\USER> C:\USER> si dice prompt dell interprete dei comandi: è il segnale con cui il sistema si mostra pronto a ricevere input Il prompt non proviene dal SO direttamente, ma dall interprete dei comandi, programma che gira sul SO (fig. p. 11) I caratteri battuti sulla tastiera dall utente sono riprodotti sullo schermo, accanto al prompt, sulla riga di comando: la riga viene presa in considerazione come comando dalla shell solo quando si preme il tasto Enter (o Return o Invio) fino ad allora, il contenuto della riga di comando: è in un area di memoria provvisoria detta buffer di input lo si può ancora correggere con il tasto di cancellazione (etichettato ) Esc Num Lock / * - Tab Caps Enter Pag Shift 1 End 2 3 Pag Ctrl Alt barra spaziatrice 0. Ins Del ( ) 1:20/28 (p.20)

21 Comandi interni ed esterni per la shell Dato un comando di nome task: 1. se è un comando interno, sarà eseguito direttamente dalla shell; p. es. (Windows): dir, cd, md, rd, del, ren, copy, date, time, path, prompt, type 2. se no, la shell cerca un file - task sotto Unix - task.com o task.exe o task.bat (nell ordine) sotto Windows e, se lo trova, lo manda in esecuzione e attende che termini; quindi invia di nuovo il prompt ed è pronta a eseguirne un altro Nel caso (2) task si dice comando esterno, p.es. in Windows: xcopy.exe, print.exe, more.com, tree.com, diskcopy.com, format.com, sys.com I file-comandi esterni vengono cercati: nella directory corrente prima e, poi, in una lista di directory detta path (percorso) Sotto Windows il path si definisce con il comando path: C:\USER> path path senza argomenti mostra il path corrente PATH=C:\DOS C:\USER> path c:\dos;c:\user C:\USER> path PATH=C:\DOS;C:\USER ( ) 1:21/28 (p.21)

22 Bootstrap (DOS-Windows) All accensione, un PC si porta nello stato di attesa dei comandi attraverso un procedimento noto come bootstrap. Per default, il bootstrap passa per queste fasi: il programma di boot su ROM sceglie come unità di boot il floppy, se c è, o, se no, il disco rigido si esegue un secondo programma di boot posto in una locazione fissa sull unità di boot questo cerca nell unità di boot il resto (il grosso) del sistema operativo e lo carica in memoria; p.es. per MS-DOS, i file msdos.sys e io.sys nella \ dell unità di boot, si cerca il file command.com contenente il programma che fa da interprete dei comandi e si passa a eseguirlo nella \ dell unità di boot, command.com cerca il file autoexec.bat ed esegue i comandi in esso contenuti Un tipico file autoexec.bat: C:\USER> type \autoexec.bat prompt $p$g rende il prompt unità e dir corrente ($p) e segno di > ($g) path c:\dos Il file CONFIG.SYS (in genere nella \ dell unità di boot) è usato durante il bootstrap per determinare la configurazione del sistema. Infine, se il sistema è configurato per questo, si ha l avvio automatico della GUI (interfaccia grafica) ( ) 1:22/28 (p.22)

23 File e nomi di file Molti SO, tra cui MS-DOS, Unix, Windows organizzano l informazione di IO in file (documenti), cioè sequenze di byte. I byte in un file possono avere diverse interpretazioni: rappresentazione di caratteri (es =ci) rappresentazione di interi (es =26979) istruzioni e dati per il computer Ma l interpretazione dipende dall uso che si fa del file: per Windows tutti i file sono comunque solo sequenze di byte. Inoltre questo vale qualunque sia il supporto fisico per i byte: per file su disco, dischetto, nastro magnetico, CD, stampante etc. Ogni file Windows ha un nome (detto nome semplice in seguito) fatto da: vari caratteri scelti (per prudenza) tra A...Z a...z _ un punto (.) vari caratteri (tipicamente 3) detti estensione del file. Windows non distingue tra maiuscole e minuscole: nome=nome. Esempi: lezione.doc lezione.old file_mio ( ) 1:23/28 (p.23)

24 Directory e subdirectory La directory si può immaginare come un contenitore di: file altre directory Ad esempio la directory user potrebbe raffigurarsi: user agenda telefoni affari lettere domande prevent fiat ibm rai comune usl compiti storia geometr roma grecia sfera cono La directory user contiene la sub-directory affari, che contiene le subdirectory lettere e domande, la subdirectory compiti, che contiene le subdirectory storia e geometr Inoltre, queste directory contengono i file mostrati in grigio. ( ) 1:24/28 (p.24)

25 L albero delle directory I contenuti delle directory si possono rappresentare, anzichè con delle scatole, come in: user agenda telefoni affari lettere domande prevent fiat ibm rai comune usl compiti storia geometr roma grecia sfera cono con degli alberi di cui file e directory sono i nodi: user agenda telefoni affari compiti prevent lettere domande storia geometria fiat ibm rai comune usl roma grecia sfera cono Ogni directory mostrata qui (tranne user) ha un solo genitore: la directory in cui è contenuta e di cui si dice figlia. La struttura delle directory si dice gerarchica perché la relazione genitore-figlio determina una gerarchia. ( ) 1:25/28 (p.25)

26 L albero delle directory: Explorer Il programma Explorer (=Gestione Risorse) di Windows fornisce una rappresentazione grafica dell albero delle directory: user agenda telefoni affari lettere domande prevent fiat ibm rai comune usl compiti storia geometr roma grecia sfera cono user agenda telefoni affari compiti prevent lettere domande storia geometria fiat ibm rai comune usl roma grecia sfera cono ( ) 1:26/28 (p.26)

27 Root, dir corrente, pathname Di norma una directory come user si trova dentro altre. Esiste però una directory che non è contenuta in nessun altra: si chiama root (radice dell albero) e si indica con il backslash \ L albero completo in cui si trova quello di user a pag. 3 è: \ bin tmp command.com user user affari ibm affari ibm Ad ogni istante è definita una directory corrente o di lavoro. File e directory, intesi come nodi di un albero, non possono essere individuati univocamente con un nome semplice, come p.es. ibm. Per questo ogni file o directory con nome semplice f ha un nome completo o pathname che può avere due forme: assoluta: localizza f sull albero rispetto alla root; è data dai nodi da \ fino a f compreso, separati da \ p.es. \user\affari\ibm relativa: localizza f rispetto alla directory corrente; è data dai nodi dalla directory corrente esclusa fino a f compreso, separati da \, p.es affari\ibm se la dir corrente è \user NB un n. completo è assoluto se inizia per \, relativo altrimenti nei nomi il carattere \ ha due usi: (1) root e (2) separatore di directory ( ) 1:27/28 (p.27)

28 Root, dir corrente, pathname I caratteri. e.. sono nomi speciali di directory:. rappresenta la directory corrente.. rappresenta la directory genitore di quella corrente P.es., dato l albero (supposto immediatamente sotto \) user agenda telefoni affari compiti prevent lettere domande storia geometria fiat ibm rai comune usl roma grecia sfera cono se domande è la directory corrente, i nomi: \user\affari\lettere\rai..\affari\lettere\rai si riferiscono allo stesso file; e così anche: \user\affari\domande\comune comune e.\comune DOS - 06/03/ /8 ( ) 1:28/28 (p.28)