Introduzione a Unix ● la storia ● la struttura – il sistema operativo – il file system – directories, files, inodes,... – i programmi

Unix: la storia (1) ● 1965: Bell Labs, MIT, GE si accordano per lo sviluppo congiunto di Multics, un SO multiuser, multiprocess, con un file system gerarchico. ● 1969: AT&T affonda Multics. Ken Thompson e Dennis Ritchie progettano ed implementano su un PDP-7 la prima versione del file system Unix (il nome viene suggerito da Brian Kernighan). ● 1 Gennaio 1970: the epoch (unix start of time). ● 1971: il sistema gira su PDP-11 (16KB RAM, 8KB utente, 512KB disk).

Unix: la storia (2) ● le caratteristiche fondamentali: – orientato alla programmazione – interfaccia utente semplice – utilities semplici ma combinabili a piacere per ottenere funzioni complesse (cp, dd, sort, ls, find, cat,...) – file system gerarchico – multiuser, multiprocess – portabile (H/W architecture independent)

Unix: la storia (3) ● 1973: Unix viene riscritto in C (creato nel frattempo da Kernighan e Ritchie per scrivere Unix...) => la portabilità aumenta a dismisura. ● 1974: Unix viene concesso in licenza alle università – inizia il processo di sviluppo distribuito e collaborativo che ancora oggi è in corso. ● 1980: BSD (Berkeley Software Distribution). ●... ● 1992: Linux!!!

Riassumendo...

... e semplificando (!)

I principi di progetto ● time sharing (semplice scheduling a priorita'), multiprocesso, a memoria virtuale ● modulare (shell intercambiabile...) ● file system ad albero multilivello. Un file e' semplicemente un sequenza di byte ● file ~ I/O devices (dettagli H/W nel kernel) ● da programmatori per programmatori

La struttura (1) NO!! Yes!!

La struttura (2) ● SO stratificato: il nocciolo più interno è l'H/W; il kernel interagisce direttamente (è l'unico che può farlo) con lo H/W e fornisce servizi alle applicazioni utente. ● Le applicazioni non devono avere la minima conoscenza dei dettagli H/W, devono solo sapere come richiedere i servizi necessari al kernel (indipendenza da H/W => portabilità). ● Il colloquio con il kernel avviene mediante system calls standard (open file; read; close file; etc. etc.). ● Entità fondamentali: file (anche i devices lo sono) e processi.

Il kernel ● Implementa tutte le funzionalità tipiche del SO, nascondendo lo H/W e fornendo un'interfaccia astratta di alto livello agli utenti: – Processi (scheduling, priorità, time sharing,...) – Memoria virtuale (swapping, paging,...) – Filesystem (files, dirs,...) – Device drivers (rete, audio, video, dischi,...) ● Caricato al bootstrap, gira in maniera trasparente. ● Monolitico (sicurezza) o modulare (flessibilità).

La shell ● Command Line Interpreter (CLI) - è un programma particolare che fornisce le funzionalità utente di base: – creazione/cancellazione/copia file; – manipolazione permessi su file; – lancio/manipolazione altri processi (job control); – programmazione (interprete); –... ● Sh, ksh, bash, zsh (bourn shell family); csh, tcsh (c-shell family).

Il File system (1) et c binus r de v hom e grou p bi n zsh ttymous e gr1 carbon e / passwd

Il File system (2) ● Struttura gerarchica ad albero; la radice (/ = root) è il nodo principale. ● La struttura H/W (dischi, cd-rom, floppy) è completamente mascherata. ● Ogni nodo è un file o una directory, una collezione di altri file o directory (file speciali: link, socket, pipe,...). ● Ogni elemento è univocamente individuato dal suo pathname: /home/gr5/carbone, /etc/passwd, /dev/tty,... ●. => current working directory;.. => parent directory

file, directory, inode ● file: generici sequenze di byte senza struttura (ASCII, binari, etc. etc.). NON contiene informazioni sulla sua propria struttura (header, trailer,...). ● directory: file che contiene una lista dei file in esso contenuti sotto forma di nomi e inode numbers; ● inode: file speciale nel quale il kernel immagazzina le informazioni fondamentali su un file (permessi, proprietà, date di creazione e modifica, posizione fisica sul supporto). L'utente non ha necessità di accedere direttamente a queste informazioni, ci pensa il kernel a mantenerle e tradurle.

Questo file e' mio! ● utente: username (uid, gid) – uid = user id (< 65535) – gid = group id (< 65535) ● ogni file ha un proprietario ed uno schema di permessi: ugo = user, group, others – rwx—x--- => u tutto, g esecuzione, o nulla – rwxrwxrwx => tutto permesso a tutti ● root (0,0) e' il superuser (gode di tutti i privilegi)

File = I/O devices? ● File, directory, I/O devices: disk, tape, soundcard, ??? – # less /root/.mozilla/bookmarks.html – # tar cf /tmp/archivio /home/luka – # tar cf /dev/tape /home/luka – # dd if=/dev/sda of=/dev/sdb – # sox sample.wav -t ossdsp /dev/dsp – # dd if=/dev/zero of=/dev/null ● Di tutto questo si occupa il kernel tramite i device drivers (pezzi di codice che 'sanno' come parlare con i singoli device)

u**x file systemS ● Linux: – ext2, ext3 – ReiserFS – (hfs, jfs, xfs,...) ● Alcuni di questi implementano funzionalita' evolute di journaling (registrano le transazioni su disco e sono in grado di ricostruirle incaso di crash di sistema).

Processi ● istanze di esecuzione di singoli programmi (i.e.: sequenze di istruzioni) che allocano ed impiegano risorse (CPU, memoria, spazio disco, etc.) e possono comunicare tra di loro ● ogni processo e' univocamente individuato da un intero: pid = process id (< 65535) e dal suo proprietario ● anche i processi sono organizzati gerarchicamente => ogni processo e' figlio (child) di qualche altro processo; init(1) e' il padre (parent) di tutti i processi. Il parent crea i suoi child ed e' (tra le altre cose) responsabile del rilevamento della loro fine 'serena': fork – exec - wait

fork – exec - wait paren t chil d paren t fork() exec( ) exit( ) wait( ) exit value (un processo di cui nessuno raccoglie il valore d'uscita diventa uno zombie) pipe (IPC)

fork() ● unica funzione che ritorna due valori differenti: il pid del child al parent, 0 al child. ● il child e', inizialmente, una copia conforme del parent: stesso spazio di indirizzi del processo originale (stesse variabili con lo stesso valore etc.). La successiva exec() carica in memoria un programma nuovo e lo sostituisce al processo originale. ● parent & child possono comunicare tramite una pipe (la forma piu' primitiva di IPC = interprocess communication)

Uno sguardo d'insieme