Il sistema FreeBSD (UNIX) Breve Storia. Storia delle Versioni di UNIX

Transcript

1 Il sistema FreeBSD (UNIX) Breve storia Principi di progettazione Interfaccia del programmatore Interfaccia utente Gestione dei processi Gestione della memoria File System Sistema di Inpput/Output Comunicazione tra processi A.1 Breve Storia Sviluppato per la prima volta nel 1969 da Ken Thompson e Dennis Ritchie ai Bell Laboratories; include caratteristiche di altri sistemi operativi, in particolare MULTICS. La terza versione fu scritta in C, che fu sviluppato appositamente per supportare UNIX. L Università della California a Berkeley (Berkeley Software Distributions) ha sviluppato la propria versione. 4BSD UNIX è stato finanziato da DARPA per sviluppare un sistema UNIX standard per uso governativo. Sviluppato per il VAX, 4.3BSD è una delle versioni più imprtanti, ed è stata portata su molte piattaforme. Diversi progetti di standardizzazione cercano di consolidare le varianti di UNIX allo scopo di fornire una unica interfaccia al programmatore. A.2 Storia delle Versioni di UNIX A.3 1

2 Primi vantaggi di UNIX Scritto in un linguaggio ad alto livello. Distribuito in formato sorgente. Fornisce potenti primitive di sistema operativo su piattoforme poco costose. Progettazione di piccole dimensioni, modulare e pulita. A.4 Principi di progettazione di UNIX Progettato per essere un sistema time-sharing. Possiede una semplice interfaccia utente standard (shell) che può essere sostituita con altre. Il File system ha una struttura di directory ad albero multilivello. I File sono visti dal sistema come sequenze non strutturate di bytes. Supporta la multiprogrammazione (processi multipli); un processo può facilmente generarne altri. L interattività del sistema è stata la principale priorità degli sviluppatori, per fornire gli strumenti adatti allo sviluppo di programmi. A.5 L interfaccia del programmatore Come la maggior parte dei sistemi, UNIX consiste di due parti separate: Kernel: ogni cosa al di sotto delle system-call e al di sopra dell hardware della macchina. Fornisce il file system, la gestione della CPU, la gestione della memoria, e altre funzioni del sistema operativo attraverso le system calls. Programmi di sistema: usano le system call del kernel per fornire funzioni utili, quali la compilazione e la manipolazione di file. A.6 2

3 4.4BSD Struttura a livelli A.7 System Calls Le System calls definiscono l interfaccia del programmatore verso UNIX L insieme dei programmi di sistema definisce l interfaccia utente. Le due interfacce definiscono il contesto che il kernel deve supportare. Tre categorie principali di system calls in UNIX. Gestione di File (le stesse supportano la gestione dei dispositivi) Controllo dei Processi Gestione delle informazioni sul sistema A.8 Gestione dei file Un file è una sequenza di bytes; il kernel non impone alcuna struttura ai files. I Files sono organizzati in una struttura di directory ad albero. Le Directories sono files che contengono informazioni su come trovare altri files. Path name: identifica un file specificando un cammino attraverso la struttura di directory. path names assoluti iniziano alla radice del file system path names relativi iniziano dalla directory corrente System calls per la gestione di base dei files: create, open, read, write, close, unlink, trunc. A.9 3

4 Struttura di directory tipica di UNIX A.10 Controllo dei Processi Un processo è un programma in esecuzione. I Processi sono idetificati da un identificare numerico, un intero. Le system calls per il controllo dei processi sono fork crea un nuovo processo execve è usata dopo una fork per caricare un programma ed eseguirlo exit termina l esecuzione di un processo Un processo può attendere (wait) che un processo figlio termini; wait restituisce l identificatore (process id) del processo terminato cosicchè il padre sa quale figlio termina. wait3 permette al padre di ottenere informazioni di prestazioni del figlio Un processo figlio che termina rimane in uno stato defunct fino a quando il padre non termina o ne richiede lo stato A.11 System call per il controllo dei processi A.12 4

5 Controllo dei processi I Processi comunicano tramite pipes: code di bytes tra due processi alle quali si accede come ad un file. Tutti i processi utenti discendono da un unico processo originale, init. init esegue un processo getty che inizializza il terminale e richiede all utente di autenticarsi (tramite login e password). Un processo login viene attivato e l utente accede al sistema, dal quale è identificato da uno user identifier Inoltre, login genera un processo che esegue la shell, la quale a sua volta genera i sottoprocessi con i comandi dell utente A.13 Controllo dei processi setuid: schema che permette a certi processi di avere più privilegi del normale, pur essendo eseguibili dagli utenti normali. setuid bit associa un effective user identifier del processo all utente proprietario del file, aggiungendone i privilegi e lascia inalterato il real user identifier. A.14 Segnali Meccanismo per gestire eventi simile a interrupt software. Il segnale interrupt, SIGINT, è usato per bloccare un comando prima che termini l esecuzione (in genere, prodotto dai tasti ctrl-c). L uso dei segnali va oltre la semplice gestione di eventi. Sono usati per avviare e interrompere processi su richiesta Il seganle SIGWINCH informa un processo che la finestra nella quale l output di un processo è visualizzato ha cambiato dimensioni. Consegna di dati urgenti derivanti da connessioni di rete. A.15 5

6 Interfaccia utente Programmeri e utenti utilizzano principalmente programmi di sistema già esistenti: le necessarie system calls sono incorporate nel programma e l utente può non esserne a conoscenza. I più comuni programmi di sistema sono orientati alla gestione dei files e delle directory. Directory: mkdir, rmdir, cd, pwd File: ls, cp, mv, rm Altri programmi sono gli editor (e.g., emacs, vi) i formattatori di testo (e.g., troff, LaTEX), programmi per la gestione del sistema (e.g., tar, passwd, netconfig). A.16 Shell e Comandi Shell il proceso utenete che esegue i programmi (anche chiamata interprete dei comandi). Si chiama shell (conchiglia), perché racchiude il kernel. La shell utilizza un prompt per indicare che è pronta ad accettare un comando dall utente. Un tipico comando è la richiesta di eseguire un programma eseguibile. La shell si occupa di ricercare il comando nella gerarchia di directory (attraverso un search path) lo carica e lo esegue. In genere, le directories /bin e /usr/bin sono quasi sempre nel search path. A.17 Shell e Comandi Un search path tipico su un sistema BSD è il seguente: (./home/prof/avi/bin /usr/local/bin /usr/ucb/bin/usr/bin ) In genere, è memorizzato in una variabile PATH che può essere modificata dall utente La shell suspende la propria esecuzione finché il comando non termina (esecuzione in foreground). Un comando può anche eseguire in background: shell e comando eseguono in parallelo A.18 6

7 Standard I/O Ad ogni processo vengono associati tre descrittori di file standard per le operazioni di I/O: standard input il programma legge ciò che lútente scrive standard output il programma invia le risposte allo schermo dell utente standard error per inviare messaggi di errore La maggior parte dei programmi può accettare input da o mandare l utput su un file. La shell usa una semplice sintassi per indicare se l input o l output avvengono da/su file I/O redirection. A.19 Standard I/O Redirection Comandi Significato % ls > filea invia l output di ls sul file filea % pr < filea > fileb prende l input da filea e manda output a fileb % lpr < fileb prende l input da fileb %% make program > & errs manda sia standard output che standard error nel file errs A.20 Pipelines, Filtri, e Shell Scripts Si possono unire singoli comandi tramite una barra verticale ( ) per dire alla shell di passare l output di un comando come input al comando successivo % ls pr lpr Filtro un comando come pr che passa il proprio input in output eseguendo qualche elaborazione su di esso. Scrivere una nuova shell con una diversa sintassi e semantica dei comandi cambierebbe la visione del sistema da parte dell utente, ma non cambia il kernel o l interfaccia per il programmatore. Il sistema X Window è la base delle interfacce grafiche di UNIX. A.21 7

8 Process Management Representation of processes is a major design problem for operating system. UNIX is distinct from other systems in that multiple processes can be created and manipulated with ease. These processes are represented in UNIX by various control blocks. Control blocks associated with a process are stored in the kernel. Information in these control blocks is used by the kernel for process control and CPU scheduling. A.22 8