2.02 Lezione 2 - follen99/ArchitetturaDeiCalcolatori GitHub Wiki
La virtualizzazione consente di gestire un SO come se stesse girando su un hardware dedicato. Questo nella realtà non avviene, perchè abbiamo un'unica CPU, con un set di core sui quali girano più macchine virtuali, che possono essere più sistemi operativi diversi. Questa tecnica è maggiormente usata lato server.
Esiste un ulteriore livello, ovvero quello dei containers. I containers sono una caratteristica di LINUX, che permette di avere degli ambienti di esecuzione che sono separati l'uno dall'altro. Ci permette di avere una soluzione più snella e leggera di una VM, ma al di sotto c'è un unico sistema operativo.
Esistono due distizioni di Real Time, Il soft real time e Hard real time.
- Soft: si cerca di eseguire all'interno dei vincoli di tempo tutto ciò che c'è da eseguire, ma se non si riesce non è un problema. Un esempio di questo tipo potrebbe essere un riproduttore MP3 o riproduttore video, dove si cerca di evitare di perdere frame, per evitare di avere scatti nella visione, ma se succede non è un problema.
- Hard: in questo tipo di aereo il processo DEVE essere effettuato nei limiti di tempo. Un esempio potrebbe essere il pilota automatico di un aereo, il quale riceve un input dai sensori e si regola di conseguenza.
I SO real time non sono assolutamente sistemi come Windows o Linux, ma sono dei SO progettati appositamente. In primo luogo non hanno nulla di virtualizzato, perchè la virtualizzazione aggiunge delle incertezze nei tempi. Solitamente non hanno dischi, ma memoria a stato solido, quindi ci viene garantito con sicurezza che tutto avvenga nei limiti di tempo.
🏁 05-05 0:11
Alcuni dei servizi del SO sono di diretto interesse per l'utente, in particolare tutti i SO devono fornire un'interfaccia utente.
Un' interfaccia storica era quella a linea di comando, dove era presente un cursore con cui si potevano scrivere dei comandi. Questa interfaccia è nota come CLI, inoltre essa è sempre accessibile anche nei sistemi ad interfaccia grafica, proprio perchè permette di lavorare con una velocità superiore (a chi la sa usare).
Sui dispositivi mobili solitamente è presente un'interfaccia di tipo touch screen, dove è possibile toccare su ciò che si vuole fare.
Ovviamente, lo scopo principale del sistema operativo è quello di eseguire i programmi. Il sistema deve quindi essere in grado di caricare un programma in memoria ed eseguirlo, sia in modo normale che anomalo, indicando l'errore.
Le operazioni di I/O sono sotto il controllo del sistema operativo, sottoforma di interfacce astratte come il file system.
Il File System è di particolare interesse, perchè i programmi hanno bisogno di leggere e scrivere files e directories, creare o eliminarle, ricercare degli elementi ecc.
Questo ambito è uno di quelli nati più tardi nell'ambito dei sistemi operativi. Windows 3.1, che è stato in commercio fino all'avvento di windows 95, non aveva un supporto per le comunicazioni. Questo vuol dire che se avessimo voluto connetterci ad internet, avremmo dovuto utilizzare programmi di terze parti. Questo ci fa capire che inizialmente i computers diffusi non si parlavano tra loro. Ai giorni nostri ha una rilevanza fondamentale.
I SO devono sempre essere a conoscenza di errori possibili.
Questi errori possono verificarsi nell'hardware della CPU o memoria, nei dispositivi di I/O, oppure in un programma utente.
Il sistema deve quindi essere in grado di gestire un errore, rilevandolo, e poi comunicandolo all'utente.
Questo tipo di servizio non impatta in modo diretto l'utente, proprio perchè egli non è a conoscenza di queste operazioni. Quando ci sono diversi utenti o jobs in esecuzioni in modo concorrente, le risorse devono essere allocate per ognuno di essi.
Questa caratteristica del SO ci permette di tenere traccia delle operazioni che sono state eseguite, degli errori che si sono verificati, gli accessi da parte degli utenti. Questa è una caratteristica molto importante.
E' una caratteristica che, pur non essendo direttamente connessa all'esecuzione dei programmi, è fondamentale per tutti gli utenti ed il corretto funzionamento del SO.
La CLI, è anche detta interprete di comandi. Questo perché quando scriviamo un comando sulla linea di comando, c'è un programma del SO che prende la nostra stringa, la suddivide nei suoi singoli pezzi, comprende i singoli pezzi ed interpreta il comando eseguendo qualcosa.
Questo interprete è una caratteristica implementata all'interno del kernel, altre volte viene implementata mediante un programma di sistema, principalmente nei sistemi UNIX. Infatti, in ambiente UNIX, non solo possiamo lanciare l'ambiente a linea di comando, ma possiamo anche scegliere tra diversi interpreti per avere delle caratteristiche lievemente diverse.
In windows l'interprete di comandi è il CMD o il PowerShell.
Questi programmi si limitano a prelevare i comandi digitati, decomporli nei vari pezzi e mandarli in esecuzione. A volte i comandi sono integrati all'interno del sistema, mentre altre volte vengono utilizzati dei programmi esterni.
L'interfaccia grafica, nella maggioranza dei casi, usa la metafora del desktop, o scrivania. Ovvero abbiamo uno spazio virtuale in cui sono organizzati tutti i file e programmi. Questo tipo di visualzzazione è un concetto relativamente recente, infatti nel mondo delle GUI l'interfaccia a desktop è stata portata per la prima volta da parte di windows.
Questo tipo di visualizzazione è nata nei laboratori Xerox PARC. La Xerox aveva dei laboratri dove è stata fatta molta attività di ricerca, come alcuni schermi ed addirittura l'attuale mouse.
Le Syscalls forniscono l'interfaccia da programma per i servizi forniti dal sistema operativo.
Per accedere alle Syscalls ci sono delle funzioni scritte in linguaggi ad alto livello, solitamente C o C++, che permettono direttamente di invocare queste funzioni senza scrivere codice macchina. Un esempio di Syscall potrebbe essere la funzione open che si trova all'interno del linguaccio C.
Le Syscall forniscono le API per l'accesso ai servizi del sistema operativo. I servizi del SO sono accessibili attraverso delle API che sono diverse a seconda del SO stesso. Nei sistemi windows l'API si chiama Win32, nei sistemi POSIX, e tutti i sistemi basati su di esso (linux, mac os) abbiamo POSIX API.
Se prendiamo un programma che permettono di visualizzare le Syscalls nel momento in cui lanciamo in esecuzione un programma, scopriamo che ogni programma, durante la sua esecuzione, esegue migliaia di chiamate prima di terminare l'esecuzione.
In realtà i programmi non possono effettuare operazioni I/O, quindi ogni volta che è necessaria un'interazione con il file system, bisogna richiedere dei servizi al sistema operativo. Questo vale per ogni operazione che richiede I/O, come leggere da tastiera, scrivere un file o stampare a video.
Per un esempio di una API standard, consideriamo la funzione read() disponibile nei sistemi UNIX. L'API per questa funzione è ottenuta dalla pagina man invocando il comando:
man read
Il comando man è un comando dei sistemi UNIX che permette di accedere al manuale sia delle syscall che dei programmi di sistema. Quindi sia i programmi di sistema, che tutto cio che riguarda il programmatore è disponibile nel manuale.
Nei sistemi UNIX le API e manuali sono disponibili online, questo che vuol dire che qualsiasi manuale è accessibile facilmente.
Se ad esempio digitiamo man open
in un CLI UNIX otteniamo:
OPEN(1) BSD General Commands Manual OPEN(1)
NAME
open -- open files and directories
SYNOPSIS
open [-e] [-t] [-f] [-F] [-W] [-R] [-n] [-g] [-j] [-h] [-s sdk]
[-b bundle_identifier] [-a application] file ... [--args arg1 ...]
DESCRIPTION
The open command opens a file (or a directory or URL), just as if you had
double-clicked the file's icon. If no application name is specified, the
default application as determined via LaunchServices is used to open the
specified files.
If the file is in the form of a URL, the file will be opened as a URL.
You can specify one or more file names (or pathnames), which are inter-
preted relative to the shell or Terminal window's current working direc-
tory. For example, the following command would open all Word files in the
current working directory:
open *.doc
Opened applications inherit environment variables just as if you had
launched the application directly through its full path. This behavior
was also present in Tiger.
The options are as follows:
-a application
Specifies the application to use for opening the file
-b bundle_indentifier
Specifies the bundle identifier for the application to use when open-
ing the file
-e Causes the file to be opened with /Applications/TextEdit
-t Causes the file to be opened with the default text editor, as deter-
mined via LaunchServices
-f Reads input from standard input and opens the results in the default
text editor. End input by sending EOF character (type Control-D).
Also useful for piping output to open and having it open in the
default text editor.
Per uscire dalla visualizzazione premiamo il tasto q
Il metodo più semplice è quello di passare i parametri all'interno dei registri del processore: basta caricare all'interno di un registro il numero della syscall ed eventuali parametri, ad esempio l'indirizzo dov'è salvata una stringa, e con questo sistema si riesce agevolmente ad utilizzare le syscalls quando abbiamo a disposizione molti registri, e non ci sono molti parametri.
Un altro modo è quello di usare una tabella in memoria, e quindi fornire l'indirizzo di memoria dove sono posizionati tutti i parametri, ed è un metodo abbondantemente usato nei sistemi UNIX.
Un altro modo ancora è quello di salvare i parametri sullo stack, effettuiamo quindi un push sullo stack dei parametri ed il sistema operativo andrà a prelevarli.
In ogni caso il metodo dello stack o della tabella non impone limiti sul numero di parametri da usare.
Nel registro viene caricato solo l'indirizzo della tabella, dopodichè la syscall farà sì che il SO prenda l'indirizzo della tabella dal registro, ed accederà alla tabella per prelevare i parametri.
🏁 lez 2 00:51