Laboratorio di Sistemi Operativi
Università degli Studi Milano Bicocca
Anno Accademico 2002-2003
Introduzione all’archittetura
di Unix
Roberto Polillo
Indice della prima parte del corso
•
•
•
•
•
•
•
Introduzione al kernel Unix
System calls e interrupts
Process management
Comunicazione fra processi
File system
Sockets
(Cenni su) architettura web
Premessa importante
Unix non è un sistema operativo…
… ma una famiglia di sistemi operativi
Quindi non ha senso parlare di una
architettura … ma bisogna parlare di una
famiglia di architetture
Ciò complica notevolmente le cose !
Esempio:
l’albero genealogico
di Unix…
fino al 1993 (!)
AT&T
SUN
BERKELEY
Linux
• Linux è una versione di UNIX, realizzata “spontaneamente”
dallo studente finlandese Linus Torvalds a partire dal 1991,
e da un grande numero di programmatori su Internet (più di 200
per il kernel, più di 2000 per il resto del sistema)
• il codice sorgente è “liberamente” disponibile nell’ambito della
“GNU General Public License”
• il progetto non ha avuto nessun finanziamento, nè alcuna
pianificazione, nè alcun coordinamento centrale
• e tuttavia il sistema è robusto e sofisticato (l’intera distribuzione
conta circa 10 milioni di linee di codice
• ha ora una grande diffusione, soprattutto come web server
Linux: come è nato
• Linus Torvalds, studente di sistemi operativi, realizza una prima
•
•
•
•
•
versione elementare, per studio personale
Poi mette i sorgenti in rete e chiede aiuto a tutti coloro che sono
interessati al progetto, via Internet
Ciò crea una ampia comunità di programmatori, che comunicano
attraverso la rete e producono un enorme numero di miglioramenti
a partire dal codice iniziale
Linus Torvalds mantiene nel processo un controllo lasco, consultivo
e non prescrittivo, assieme a numerosi “guru” emersi spontaneamente nel tempo
Le modifiche al codice vengono integrate e rese disponibili a tutti
in rete con estrema frequenza (anche più di una volta al giorno)
Il nuovo codice viene immediatamente testato da un gran numero
di programmatori, che identificano e rimuovono gli errori
From: [email protected] (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Free minix-like kernel sources for 386-AT
Message-ID: <[email protected]>
Date: 5 Oct 91 05:41:06 GMT
Organization: University of Helsinki
Do you pine for the nice days of minix-1.1, when men were men and wrote their own device
drivers? Are you without a nice project and just dying to cut your teeth on a OS you can
try to modify for your needs? Are you finding it frustrating when everything works on minix?
No more all- nighters to get a nifty program working? Then this post might be just for you :-)
As I mentioned a month(?) ago, I'm working on a free version of a minix-lookalike for AT-386
computers. It has finally reached the stage where it's even usable (though may not be
depending on what you want), and I am willing to put out the sources for wider distribution.
<omissis>
I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two,
or next month, who knows), and I've already got minix. This is a program for hackers by a
hacker. I've enjouyed doing it, and somebody might enjoy looking at it and even modifying it
for their own needs. It is still small enough to understand, use and modify, and I'm looking
forward to any comments you might have.
I'm also interested in hearing from anybody who has written any of the utilities/library
functions for minix. If your efforts are freely distributable (under copyright or even public
domain), I'd like to hear from you, so I can add them to the system. I'm using Earl Chews
estdio right now thanks for a nice and working system Earl), and similar works will be very
wellcome. Your (C)'s will of course be left intact. Drop me a line if you are willing to let
me use your code.
Linus
"Unix è semplice e coerente, but ci vuole un
genio (o, almeno, un programmatore) per
comprenderne ed apprezzarne la semplicità"
D. Ritchie
INTRODUZIONE
AL KERNEL UNIX
Kernel
E’ il sistema operativo vero e proprio
• gestisce direttamente l’hardware della macchina e le
sue periferiche
• è sempre (quasi tutto) residente in memoria: viene
caricato alla accensione del sistema, e ci resta fino al
suo spegnimento (o a un crash)
• fornisce i servizi necessari ai processi in esecuzione
attraverso un insieme di system call
• gestisce gli interrupts generati dall’hardware
Processi
Sono i programmi in esecuzione
• Nei sistemi Unix tradizionali, ogni processo esegue una singola
sequenza di istruzioni in un proprio spazio di indirizzi: un unico
program counter specifica la prossima istruzione da eseguire
• I sistemi più moderni possono eseguire più thread in uno stesso
spazio di indirizzi (in Linux: lightweight process)
• Ogni processo è indipendente dagli altri, e può interagire con
essi solo attraverso il kernel, mediante opportune system call
• Il codice di un processo non necessariamente deve risiedere
tutto in memoria centrale (varie tecniche di memory
management…)
Time sharing
Unix è un sistema time-sharing: un processo
esegue per un quanto di tempo (o finchè non
si sospende in attesa di un evento, es.: fine
I/O)
Protezioni hardware
• Il kernel viene eseguito in kernel mode:
può eseguire qualunque istruzione di macchina e
accedere a qualunque area di menoria
• I processi utente vengono eseguiti in user
mode:
non possono eseguire alcune istruzioni “pericolose” e
non possono accedere allo spazio di indirizzi del
kernel e di altri processi
Identificazione di un processo
• Ogni processo è identificato da un Process ID
(PID) numerico unico, assegnato dal kernel al
momento della creazione del processo
Proprietari di un processo
• Ogni processo appartiene a:
- un utente, identificato dal suo User Id (UID)
- un gruppo di utenti, identificato dal suo Group ID
(GID)
• Ciò permette di realizzare dei meccanismi di
protezione (ad esempio, un processo potrà essere
terminato o sospeso soltanto dal suo proprietario)
• A un certo istante, più processi possono avere lo
stesso UID
Gruppi di processi
• Ogni processo può appartenere a un gruppo
di processi
• Un gruppo è identificato dal PID di un
processo detto leader del gruppo (process
group ID)
• Ciò permette di effettuare azioni su una
collettività di processi (ad esempio,
terminazione)
Residente
Kernel e processi
Kernel
interrupt
Non residente
System calls
send
write
Processo 1
Processo 2
Memoria centrale
Processo n
Periferiche
System calls
• Sono l’interfaccia programmativa verso il kernel, per
richiedere i servizi del kernel
• Il loro numero dipende dalla versione di Unix (da una
settantina a oltre 200)
• Le categorie principali di system call sono tre:
Input/output
Process
management
Inter-process
communications
open, close, read,
write, …
fork, exec, exit,
kill, …
send, pipe,
socket, …
Standardizzazione
POSIX.1 standardizza un nucleo base di system call
(circa 120), a livello di interfaccia sorgente C (ma anche
Fortran e Ada)
POSIX: IEEE Portable Operating System Interface for Computing Environment
Es.:
int open (const char *path, int oflag, …);
Un sorgente C Standard conforme a POSIX può essere
eseguito, una volta compilato, su qualunque sistema
POSIX dotato di un ambiente di programmazione C
Standard (“portabilità a livello sorgente”)
Residente
Portabilità
altro kernel,
Kernel
stessa interfaccia
system call POSIX
Non residente
periferiche
Processo 1
Processo 2
Memoria centrale
Processo n
Periferiche
Linux
• Linux 2.4 è conforme a Posix
NB: Le versioni Linux sono identificate da tre numeri:
2.4.18
Versione
Versione:
numeri pari
identificano
versioni
stabili
Release
Estensioni a Posix
• L’approccio Posix è minimalista: standardizza un
nucleo base di funzioni
(ad es., nessuna funzione di system administration)
• Normalmente, i sistemi POSIX forniscono anche una
serie di estensioni non POSIX (system call e/o
opzioni addizionali)
• Queste estensioni compromettono la portabilità dei
programmi, quindi vanno usate con estrema cautela
Demoni
Sono processi di sistema, che partono automaticamente in background quando il sistema è attivato
Esempi:
• Gestione del tempo (cron): si attiva ogni minuto per
•
•
•
•
controllare se c’è qualcosa da fare, nel qual caso lo fa,
e si sospende fino al prossimo controllo (es.: backup
periodici)
Gestione delle code di stampa
Gestione della posta in partenza e in arrivo
Gestione della memoria (pagedaemon, swapper)
…
Residente
Sintesi fin qui
Kernel
Non residente
System calls
Processi
utente
Processo 1
Daemon
Processo 2
Memoria centrale
Processo n
Periferiche
SYSTEM CALLS
E
INTERRUPTS
System call: come funzionano
Processo
Kernel
(user mode)
(kernel mode)
dispatch vector
-------------------------------------------
.…
syscall (params)
syscall routine
bodies
-------------------
-------------------------------------
altro processo
switcher
System call: come funzionano (II)
push a
push b
syscall (a, b, c)
push c
push syscall#
SVC
Supervisor call:
set kernel mode, save PC e
salta a un indirizzo fisso
del kernel
Richiami sugli interrupts
• Sono segnali hardware :
- generati da device periferici
• es. fine di un’operazione di I/O
- oppure generati dalla CPU, a fronte di eccezioni es.
•
•
•
•
•
divisione per zero,
stack overflow,
indirizzamenti invalidi (indirizzi inesistenti o protetti),
tentativo di eseguire istruzioni privilegiate in user mode,
caduta di tensione, ecc.
Una interruzione fa sì che il controllo venga trasferito al kernel…
… che ha il compito di identificare l’interrupt, di trattarlo, e quindi
di restituire il controllo al processo interrotto (o a un altro più
prioritario) …
… con la massima efficienza possibile
Gestione degli interrupts
Processo
Kernel
(user mode)
(kernel mode)
Interrupt
interrupt vector
-------------------------------------------
Interrupt
entry point
.…
--------------------------------------
Interrupt
handlers
-------------------------------------
altro processo
switcher
Gestione degli interrupts
Set kernel mode
Disable interrupts
Save Registers & PC
- tratta l’interrupt
- scegli il processo con cui
proseguire
- schedulalo
Restore Registers & PC
Enable interrupts
Set user mode
Return al processo prescelto
Livelli di interrupt
• Gli interrupt sono organizzati su diversi livelli
di priorità
• Il trattamento di un interrupt può essere a sua
volta interrotto da un interrupt di priorità
maggiore
• Mentre sto trattando un interrupt, interrupt di
priorità uguale o minore vengono ignorati e
scartati
Non residente
Residente
Sintesi fin qui
Switcher
System calls
Interrupt Handlers
Processi
utente
Processo 1
I/O drivers
Daemon
Processo 2
Memoria centrale
Processo n
Periferiche
SCHEDULING
Stati (principali) di un processo
Running
attesa
evento
schedulazione
quanto di tempo
esaurito
Ready
Asleep
evento occorso
Process switching
Uno switch di processo può avvenire in 4
casi:
1. quando un processo si pone in stato di sleep
2. quando esegue una exit
3. quando si ritorna da una system call da esso
4.
invocata, ma ci sono processi ready più prioritari
quando si ritorna dalla gestione di un interrupt ma
ci sono processi ready più prioritari
Schedulazione
• La schedulazione viene effettuata da una
routine del kernel chiamata switcher
• L’algoritmo di schedulazione dei processi
pronti è stato progettato per fornire buoni
tempi di risposta ai processi interattivi
• In pratica: i processi CPU-bound sono serviti
solo quando tutti i processi I/O-bound e quelli
interattivi sono bloccati
Priorità
• Ogni processo ha un livello di priorità:
… -2
-1
0
1
2
…
 priorità maggiori 
• Le priorità vengono attribuite dinamicamente
• Processi che eseguono in modo kernel hanno
priorità maggiore di quelli in modo user (così
restano il meno possibile in modo kernel)
• Processi di pari priorità sono schedulati a turno
(“round-robin”)
Calcolo delle priorità
• La priorità di un processo ha una componente statica (base) e
una dinamica che dipende dal tempo di CPU ricevuto:
• ad ogni tic del clock viene incrementato il contatore di utilizzo
della CPU del processo in esecuzione
• Ogni secondo, le priorità di tutti i processi vengono ricalcolate
secondo la formula:
nuova priorità = base + utilizzo CPU/2
• La base è di solito 0, ma può essere incrementata con il
comando nice, che peggiora la priorità
• In tal modo, vengono “premiati” i processi pronti che non hanno
avuto molta CPU, e “penalizzato” quello running