Upload
loreto-pucci
View
225
Download
1
Embed Size (px)
Citation preview
Laboratorio di Sistemi OperativiUniversità 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 200per 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 sonointeressati 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 spontanea-mente nel tempo
• Le modifiche al codice vengono integrate e rese disponibili a tuttiin 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
ProcessiSono 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)
KernelKernel
Kernel e processi
Res
iden
te
Processo 2 Processo nProcesso 1
Non
res
iden
te
Memoria centrale Periferiche
System calls
writesend
interrupt
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/outputProcess
managementInter-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”)
KernelKernel
Portabilità
Res
iden
te
Processo 2 Processo nProcesso 1
Non
res
iden
te
Memoria centrale
periferiche
Periferiche
system call POSIX
altro kernel,stessa interfaccia
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
DemoniSono processi di sistema, che partono automati-camente 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)• …
KernelKernel
Sintesi fin qui
Res
iden
te
Processo 2 Processo n
DaemonDaemon
Processo 1
Non
res
iden
te
Memoria centrale Periferiche
System calls
Processi utente
SYSTEM CALLS E
INTERRUPTS
System call: come funzionano
Processo Kernel(user mode) (kernel mode)
---------------------------------------------
syscall (params)
-------------------
-------------------
-------------------
syscall routinebodies
.…
dispatch vector
switcherswitcher
altro processo
System call: come funzionano (II)
push a
push b
push c
push syscall#
SVC
push a
push b
push c
push syscall#
SVC
Supervisor call: set kernel mode, save PC e
salta a un indirizzo fissodel kernel
syscall (a, b, c)syscall (a, b, c)
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
Interrupthandlers
.…
interrupt vector
Interrupt entry point
switcherswitcher
altro processo
Gestione degli interrupts
Set kernel modeDisable interrupts
Save Registers & PC- tratta l’interrupt- scegli il processo con cui
proseguire- schedulalo
Restore Registers & PCEnable interrupts
Set user modeReturn 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
Sintesi fin qui
Res
iden
te
Processo 2 Processo n
DaemonDaemon
Processo 1
Non
res
iden
te
Memoria centrale Periferiche
Processi utente
SwitcherSwitcher
System calls Interrupt Handlers I/O drivers
SCHEDULING
Stati (principali) di un processo
Running
AsleepReady
attesa evento
evento occorso
quanto di tempo esaurito
schedulazione
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 invocata, ma ci sono processi ready più prioritari
4. 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