Laboratorio di Sistemi Operativi Università degli Studi Milano Bicocca Anno Accademico 2002-2003 Introduzione allarchittetura di Unix Roberto Polillo.

Presentazione sul tema: "Laboratorio di Sistemi Operativi Università degli Studi Milano Bicocca Anno Accademico 2002-2003 Introduzione allarchittetura di Unix Roberto Polillo."— Transcript della presentazione:

1 Laboratorio di Sistemi Operativi Università degli Studi Milano Bicocca Anno Accademico 2002-2003 Introduzione allarchittetura di Unix Roberto Polillo

2 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

3 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 !

4 Esempio: lalbero genealogico di Unix… fino al 1993 (!) AT&T SUN BERKELEY

5 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 nellambito 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 (lintera distribuzione conta circa 10 milioni di linee di codice ha ora una grande diffusione, soprattutto come web server

6 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 spontanea- mente 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

7 From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Free minix-like kernel sources for 386-AT Message-ID: 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. 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

8 "Unix è semplice e coerente, but ci vuole un genio (o, almeno, un programmatore) per comprenderne ed apprezzarne la semplicità" D. Ritchie

9 INTRODUZIONE AL KERNEL UNIX

10 Kernel E il sistema operativo vero e proprio gestisce direttamente lhardware 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 dallhardware

11 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…)

12 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)

13 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

14 Identificazione di un processo Ogni processo è identificato da un Process ID (PID) numerico unico, assegnato dal kernel al momento della creazione del processo

15 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

16 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)

17 Kernel Kernel e processi Residente Processo 2Processo nProcesso 1 Non residente Memoria centralePeriferiche System calls write send interrupt

18 System calls Sono linterfaccia 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, …

19 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)

20 Kernel Portabilità Residente Processo 2Processo nProcesso 1 Non residente Memoria centrale periferiche Periferiche system call POSIX altro kernel, stessa interfaccia

21 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

22 Estensioni a Posix Lapproccio 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

23 Demoni Sono 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) …

24 Kernel Sintesi fin qui Residente Processo 2Processo n Daemon Processo 1 Non residente Memoria centralePeriferiche System calls Processi utente

25 SYSTEM CALLS E INTERRUPTS

26 System call: come funzionano ProcessoKernel (user mode)(kernel mode) --------------- --------------- --------------- syscall (params) ------------------- syscall routine bodies.… dispatch vector switcher altro processo

27 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 fisso del kernel syscall (a, b, c)

28 Richiami sugli interrupts Sono segnali hardware : - generati da device periferici es. fine di unoperazione 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 linterrupt, di trattarlo, e quindi di restituire il controllo al processo interrotto (o a un altro più prioritario) … … con la massima efficienza possibile

29 Gestione degli interrupts ProcessoKernel (user mode)(kernel mode) --------------- --------------- --------------- -------------------- ------------------- Interrupt Interrupt handlers.… interrupt vector Interrupt entry point switcher altro processo

30 Gestione degli interrupts Set kernel mode Disable interrupts Save Registers & PC - tratta linterrupt - scegli il processo con cui proseguire - schedulalo Restore Registers & PC Enable interrupts Set user mode Return al processo prescelto

31 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

32 Sintesi fin qui Residente Processo 2Processo n Daemon Processo 1 Non residente Memoria centralePeriferiche Processi utente Switcher System calls Interrupt Handlers I/O drivers

33 SCHEDULING

34 Stati (principali) di un processo

35 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

36 Schedulazione La schedulazione viene effettuata da una routine del kernel chiamata switcher Lalgoritmo 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

37 Priorità Ogni processo ha un livello di priorità: … -2-1012… 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)

38 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