From 5e21fbe6d6ee90209e1ffdf200a0a4b43d01ce77 Mon Sep 17 00:00:00 2001 From: "Christopher R. Gabriel" Date: Mon, 2 Jul 2001 04:43:32 +0000 Subject: [PATCH 01/16] Ho detto solo $Date$, non anche $Id$ --- gapil.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gapil.tex b/gapil.tex index 489bd50..ce44b1f 100644 --- a/gapil.tex +++ b/gapil.tex @@ -60,7 +60,7 @@ Free Documentation License''. \end{quote} -Build: % $Id: gapil.tex,v 1.5 2001/07/02 04:42:53 cgabriel Exp $ $Date: 2001/07/02 04:42:53 $ +Build: % $Date: 2001/07/02 04:43:32 $ \clearemptydoublepage -- 2.30.2 From 09be625ca1ed318adcfd2548ddefe6fa82d41441 Mon Sep 17 00:00:00 2001 From: "Christopher R. Gabriel" Date: Mon, 2 Jul 2001 04:46:29 +0000 Subject: [PATCH 02/16] forse cosi' piace di piu' a latex2html --- gapil.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gapil.tex b/gapil.tex index ce44b1f..71d4867 100644 --- a/gapil.tex +++ b/gapil.tex @@ -60,7 +60,7 @@ Free Documentation License''. \end{quote} -Build: % $Date: 2001/07/02 04:43:32 $ +Build: $Date: 2001/07/02 04:46:29 $ \clearemptydoublepage -- 2.30.2 From 8390493ca67582cbab33e667c0c4445c310b419d Mon Sep 17 00:00:00 2001 From: "Christopher R. Gabriel" Date: Mon, 2 Jul 2001 04:49:05 +0000 Subject: [PATCH 03/16] niente, la mia idea e' svanita nel nulla. LaTeX.. tsk. --- gapil.tex | 2 -- 1 file changed, 2 deletions(-) diff --git a/gapil.tex b/gapil.tex index 71d4867..a8b017b 100644 --- a/gapil.tex +++ b/gapil.tex @@ -60,8 +60,6 @@ Free Documentation License''. \end{quote} -Build: $Date: 2001/07/02 04:46:29 $ - \clearemptydoublepage -- 2.30.2 From de73e63610d4ec307329b26c64467f27b6316688 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 2 Jul 2001 18:12:19 +0000 Subject: [PATCH 04/16] Aggiunte definizioni di un paio di segnali --- signal.tex | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/signal.tex b/signal.tex index 9b2d4cb..3999212 100644 --- a/signal.tex +++ b/signal.tex @@ -423,7 +423,9 @@ Questi segnali sono: \item \texttt{SIGABRT} Il segnale indica che il programma stesso ha rilevato un errore che viene riportato chiamando la funzione \texttt{abort} che genera questo segnale. -\item \texttt{SIGTRAP} +\item \texttt{SIGTRAP} È il segnale generato da un'istruzione di breakpoint o + dall'attivazione del tracciamento per il processo. È usato dai programmi per + il debugging e se un programma normale non dovrebbe ricevere questo segnale. \item \texttt{SIGSYS} Sta ad indicare che si è eseguta una istruzione che richiede l'esecuzione di una system call, ma si è fornito un codice sbagliato per quest'ultima. @@ -447,11 +449,16 @@ periferica). L'azione di default di questi segnali è di terminare il processo, questi segnali sono: \begin{description} -\item \texttt{SIGTERM} -\item \texttt{SIGINT} -\item \texttt{SIGQUIT} -\item \texttt{SIGKILL} -\item \texttt{SIGHUP} +\item \macro{SIGTERM} Questo è un segnale generico usato per causare la + conclusione di un programma. Al contrario di \macro{SIGKILL} può essere + intercettato, ignorato, bloccato. In genere lo si usa per chiedere in + maniera ``educata'' ad un processo di concludersi. +\item \macro{SIGINT} E il segnale di interruzione per il programma. È quello + che viene generato di default dal comando \cmd{kill} o dall'invio sul + terminale del carattere di interrupt (generato dalla sequenza \macro{C-\\}). +\item \macro{SIGQUIT} +\item \macro{SIGKILL} +\item \macro{SIGHUP} \end{description} \subsection{I segnali di allarme} -- 2.30.2 From 056bbc90c8a0710b57fa7b13f5f0dfdad1b3ff3f Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 2 Jul 2001 21:43:55 +0000 Subject: [PATCH 05/16] Risistemati un sacco di riferiementi, e la riorganizzazione della parte sui files --- app_a.tex | 20 +++++----- elemtcp.tex | 17 ++++----- filedir.tex | 4 +- fileintro.tex | 102 +++++++++++++++++++++++++------------------------- filestd.tex | 4 +- intro.tex | 4 +- network.tex | 2 +- process.tex | 18 ++++----- prochand.tex | 2 +- signal.tex | 4 +- simpltcp.tex | 16 ++++---- 11 files changed, 94 insertions(+), 99 deletions(-) diff --git a/app_a.tex b/app_a.tex index 9798904..0332efe 100644 --- a/app_a.tex +++ b/app_a.tex @@ -1175,14 +1175,14 @@ Il primo meccanismo di sicurezza \`e quello della testata di autenticazione (\textit{autentication header}) che fornisce l'autenticazione e il controllo di integrit\`a (ma senza riservatezza) dei pacchetti IP. -La testata di autenticazione ha il formato descritto in Tab.~\ref{tab:authead} -il campo \textit{Next Header} indica la testata successiva, con gli stessi -valori del campo omonimo nella testata principale di IPv6, il campo -\textit{Lengh} indica la lunghezza della testata di autenticazione in numero -di parole a 32 bit, il campo riservato deve essere posto a zero, seguono poi -l'indice di sicurezza, stabilito nella associazione di sicurezza, e un numero -di sequenza che la stazione sorgente deve incrementare di pacchetto in -pacchetto. +La testata di autenticazione ha il formato descritto in +Tab.~\ref{tab:autent_head} il campo \textit{Next Header} indica la testata +successiva, con gli stessi valori del campo omonimo nella testata principale +di IPv6, il campo \textit{Lengh} indica la lunghezza della testata di +autenticazione in numero di parole a 32 bit, il campo riservato deve essere +posto a zero, seguono poi l'indice di sicurezza, stabilito nella associazione +di sicurezza, e un numero di sequenza che la stazione sorgente deve +incrementare di pacchetto in pacchetto. Completano la testata i dati di autenticazione che contengono un valore di controllo di intgrit\`a (ICV, \textit{Integrity Check Value}), che deve essere @@ -1215,7 +1215,7 @@ devono provvedere questa capacit\`a. \hline \end{tabular} \caption{Formato della testata dell'estensione di autenticazione} - \label{tab:authead} + \label{tab:autent_estens} \end{center} \end{table} \renewcommand\arraystretch{1} %default @@ -1245,7 +1245,7 @@ prima che dopo. \hline \end{tabular*} \caption{Formato della testata dell'estensione di autenticazione} - \label{tab:authead} + \label{tab:autent_head} \end{center} \end{table} \begin{center} diff --git a/elemtcp.tex b/elemtcp.tex index 270b9a5..33c005d 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -13,7 +13,7 @@ connessione TCP. \label{sec:TCPel_connession} Prima di entrare nei dettagli delle funzioni usate nelle applicazioni che -utilizzano i socket TCP, è fondamentale spiegare alcune basi del funzionamento +utilizzano i sokcet TCP, è fondamentale spiegare alcune basi del funzionamento del TCP; la conoscenza del funzionamento del protocollo è infatti essenziale per capire il modello di programmazione ed il funzionamento delle API. @@ -188,7 +188,6 @@ seguente: con un ACK. \end{enumerate} - Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione normalmente i segmenti scambiati sono quattro; normalmente giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati. Comunque non è @@ -199,8 +198,8 @@ sequenza di scambio dei segmenti che stabilisce la connessione. \begin{figure}[htb] \centering - \caption{Il \textit{three way handshake} del TCP} - \label{fig:TCPel_TWH} + \caption{La chiusura di una connessione TCP} + \label{fig:TCPel_close} \end{figure} Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui @@ -221,9 +220,9 @@ in \figref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo viene terminato da un segnale tutte le connessioni aperte verranno chiuse. Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo -più avanti in \secref{sec:TCPsimp_echo_example}) sia il client ad eseguire la -chiusura attiva, nella realtà questa può essere eseguita da uno qualunque dei -due capi della comunicazione (come in fatto in precedenza da +più avanti in \secref{sec:TCPsimp_echo}) sia il client ad eseguire la chiusura +attiva, nella realtà questa può essere eseguita da uno qualunque dei due capi +della comunicazione (come in fatto in precedenza da \figref{fig:net_serv_code}), e benché quello del client sia il caso più comune ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali è il server ad effettuare la chiusura attiva. @@ -903,7 +902,7 @@ numero di connessioni per cui un tale valore non comunque una risposta univoca per la scelta del valore, per questo non conviene specificarlo con una costante (il cui cambiamento richiederebbe la ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi -\secref{sec:xxx_env_var}). +\secref{sec:proc_environ}). Lo Stevens tratta accuratamente questo argomento, con esempi presi da casi reali su web server, ed in particolare evidenzia come non sia più vero che il @@ -1138,7 +1137,7 @@ int main(int argc, char *argv[]) \end{lstlisting} \caption{Esempio di codice di un server concorrente elementare per il servizio daytime.} - \label{fig:TCPelem_serv_code} + \label{fig:TCPel_serv_code} \end{figure} Come si può vedere (alle linee \texttt{\small 21--25}) la funzione diff --git a/filedir.tex b/filedir.tex index daf947a..d811bfc 100644 --- a/filedir.tex +++ b/filedir.tex @@ -12,7 +12,7 @@ lasciato ai capitoli successivi. \section{La manipolazione delle caratteristiche dei files} \label{sec:filedir_infos} -Come spiegato in \secref{sec:filedir_file_handling} tutte le informazioni +Come spiegato in \secref{sec:fileintr_filesystem} tutte le informazioni generali relative alle caratteristiche di ciascun file sono mantenute nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per @@ -76,7 +76,7 @@ struct stat { \normalsize \caption{La struttura \texttt{stat} per la lettura delle informazioni dei file} - \label{fig:sock_sa_gen_struct} + \label{fig:filedir_stat_struct} \end{figure} Si noti come i vari membri della struttura siano specificati come tipi nativi diff --git a/fileintro.tex b/fileintro.tex index 4f52826..a7df993 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -6,7 +6,7 @@ Uno dei concetti fondamentali della architettura di unix di input/output del computer viene effettuato attraverso un'interfaccia astratta che tratta le periferiche allo stesso modo degli usuali file di dati. -Questo significa che si può accedere cioè a qualunque periferica del computer, +Questo significa che si può accedere a qualunque periferica del computer, dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i cosiddetti file di dispositivo (i \textit{device files}). Questi sono dei file speciali agendo sui quali i programmi possono leggere, scrivere e compiere @@ -16,25 +16,23 @@ usano per i normali file di dati. In questo capitolo forniremo un'introduzione all'architettura della gestione dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che nelle particolarità che ha la specifica implementazione usata da Linux. Al -comtempo tratteremo l'organizzazione dei file in un sistema unix-like, e le +contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le varie caratteristiche distintive. - - \section{L'organizzazione di files e directories} -\label{sec:filedir_org} +\label{sec:fileintr_organization} -Visto il ruolo fondamentale che i files vengono ad assumere in un sistema -unix-like, è anzitutto opportuno fornire un'introduzione dettagliata su come -essi vengono organizzati all'interno del sistema. +Il primo passo nella trattazione dell'achitettura della gestione dei file in +un sistema unix-like, è quello dell'esame di come essi vengono organizzati e +di quale è la struttura che hanno all'interno del sistema. -\subsection{Una breve introduzione} -\label{sec:fileintr_org_intro} +\subsection{La struttura di files e directory} +\label{sec:fileintr_filedir_struct} Partiamo allora da come viene strutturata nel sistema la disposizione dei file: per potervi accedere il kernel usa una apposita interfaccia che permetta -di strutturare l'informazione tenuta sullo spazio grezzo disponibile sui +di accedere all'informazione tenuta sullo spazio grezzo disponibile sui dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per brevità questo nome al posto della più prolissa traduzione italiana sistema di file}, che descriviremo in dettaglio in \secref{sec:fileintr_vfs}. @@ -70,17 +68,12 @@ oggetti visti attraverso l'interfaccia che manipola i files come le FIFO, i link, i socket e gli stessi i file di dispositivo (questi ultimi, per convenzione, sono inseriti nella directory \texttt{/dev}). - -\subsection{La struttura di file e directories} -\label{sec:fileintr_filedir_struct} - L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei -medesimi nell'albero descritto brevemente in \secref{sec:fileintr_org_intro}; -una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è -solo un particolare tipo di file che contiene le informazioni che associano un -nome al contenuto. Per questo, anche se è usuale parlare di ``file in una -directory'' in realtà una directory contiene solo delle etichette per fare -riferimento ai file stessi. +medesimi nell'albero descritto in precedenza; una directory comunque, come già +specificato in \secref{sec:fileintr_vfs}, è solo un particolare tipo di file +che contiene le informazioni che associano un nome al contenuto. Per questo, +anche se è usuale parlare di ``file in una directory'' in realtà una directory +contiene solo delle etichette per fare riferimento ai file stessi. I manuale delle glibc chiama i nomi contenuti nelle directory \textsl{componenti} (in inglese \textit{file name components}), noi li @@ -112,7 +105,7 @@ Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice del processo; questa, a meno di un \textit{chroot} (su cui torneremo in seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed equivale alla directory radice dell'albero (come descritto in -\secref{sec:fileintr_overview}): in questo caso si parla di un pathname +\secref{sec:fileintr_organization}): in questo caso si parla di un pathname \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è detto \textsl{relativo}. @@ -134,7 +127,12 @@ questa sia la directory radice allora il riferimento Come detto in precedenza in unix esistono vari tipi di file, in Linux questi sono implementati come oggetti del \textit{Virtual File System} e sono presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei -vari tipi di file definiti dal Virtual File System è il seguente: +vari tipi di file definiti dal Virtual File System è riportato in \ntab. + +Si tenga ben presente che questa classificazione non ha nulla a che fare con +la classificazione sui tipi di file (che in questo caso sono sempre file di +dati) in base al loro contenuto, o tipo di accesso. + \begin{table}[htb] \begin{center} @@ -164,10 +162,6 @@ vari tipi di file definiti dal Virtual File System \end{center} \end{table} -Si tenga ben presente che tutto ciò non ha nulla a che fare con la -classificazione sui tipi di file (che in questo caso sono sempre file di dati) -in base al loro contenuto, o tipo di accesso. - Una delle differenze principali con altri sistemi operativi (come il VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono un flusso continuo di bytes; non esiste cioè differenza per come vengono visti @@ -281,7 +275,7 @@ accesso cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo -in dettaglio in \secref{sec:filedir_link}) aprire un file provvisorio per +in dettaglio in \secref{sec:fileintr_link}) aprire un file provvisorio per cancellarlo immediatamente dopo; in questo modo all'uscita del programma il file scomparirà definitivamente dal disco, ma il file ed il suo contenuto saranno disponibili per tutto il tempo in cui il processo è attivo. @@ -298,30 +292,34 @@ una convenzione. \section{L'architettura della gestione dei file} -\label{sec:filedir_file_handling} +\label{sec:fileintro_architecture} Per capire fino in fondo le proprietà di files e directories in un sistema unix ed il funzionamento delle relative funzioni di manipolazione occorre una breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato -un filesystem unix; in particolare si riprenderà, approfondendolo sul piano -dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui -abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione -nel kernel) in \secref{sec:fileintr_vfs}. - -In particolare occorre tenere presente dov'è che si situa la divisione -fondamentale fra kernel space e user space che tracciavamo al +un filesystem unix. In particolare occorre tenere presente dov'è che si situa +la divisione fondamentale fra kernel space e user space che tracciavamo al \capref{cha:intro_unix}. +In questa sezione esamineremo allora come viene implementato l'accesso ai +files in Linux, come il kernel gestisce i vari filesystem, descrivendo poi in +maniera un po' più dettagliata il filesystem standard di Linux, +l'\texttt{ext2}, come esempio di un filesystem unix-like. + + +% in particolare si riprenderà, approfondendolo sul piano +% dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui +% abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione +% nel kernel) in \secref{sec:fileintr_vfs}. \subsection{Il \textit{virtual filesystem} di Linux} \label{sec:fileintr_vfs} -Esamineremo adesso come viene implementato l'accesso ai files in Linux. Questa -sezione riporta informazioni sui dettagli di come il kernel gestisce i files. -L'argomento è abbastanza ``esoterico'' e questa sezione può essere saltata ad -una prima lettura; è bene però tenere presente che vengono introdotti qui -alcuni termini che potranno comparire in seguito, come \textit{inode}, -\textit{dentry}, \textit{dcache}. +% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i +% files. L'argomento è abbastanza ``esoterico'' e questa sezione può essere +% saltata ad una prima lettura; è bene però tenere presente che vengono +% introdotti qui alcuni termini che potranno comparire in seguito, come +% \textit{inode}, \textit{dentry}, \textit{dcache}. In Linux il concetto di \textit{everything is a file} è stato implementato attraverso il \textit{virtual filesystem} (da qui in avanti VFS) che è @@ -433,10 +431,10 @@ diversi filesystem (come quelli usati da Windows o MacOs) \subsection{Il funzionamento di un filesystem unix} -\label{sec:filedir_filesystem} +\label{sec:fileintr_filesystem} -Come già accennato in \secref{sec:fileintr_overview} Linux (ed ogni unix in -generale) organizza i dati che tiene su disco attraverso l'uso di un +Come già accennato in \secref{sec:fileintr_organization} Linux (ed ogni unix +in generale) organizza i dati che tiene su disco attraverso l'uso di un filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è quella di poter supportare grazie al VFS una enorme quantità di filesystem diversi, ognuno dei quali ha una sua particolare struttura e funzionalità @@ -453,7 +451,7 @@ disposizione per i dati e le directory. \centering \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} - \label{fig:filedir_disk_filesys} + \label{fig:fileintr_disk_filesys} \end{figure} Se si va ad esaminare come è strutturata l'informazione all'interno di un @@ -464,7 +462,7 @@ del tipo di quella esposta in \nfig. \centering \caption{Organizzazione di un filesystem} - \label{fig:filedir_filesys_detail} + \label{fig:fileintr_filesys_detail} \end{figure} da questa figura si evidenziano alcune caratteristiche su cui è bene porre attenzione in quanto sono fondamentali per capire il funzionamento delle @@ -522,7 +520,7 @@ adesso sar \subsection{Le funzioni \texttt{link} e \texttt{unlink}} -\label{sec:filedir_link} +\label{sec:fileintr_link} Una delle caratteristiche usate quando si opera con i file è quella di poter creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo @@ -588,7 +586,7 @@ ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può essere così richiamato in diverse directory. -Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del +Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del collegamento diretto è possibile solo se entrambi i pathname sono nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è il caso ad esempio del filesystem \texttt{vfat} di windows). @@ -596,7 +594,7 @@ il caso ad esempio del filesystem \texttt{vfat} di windows). La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, ma solo l'amministratore è in grado di creare un collegamento diretto ad un'altra directory, questo lo si fa perché in questo caso è possibile creare -dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti +dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti programmi non sono in grado di gestire e la cui rimozione diventa estremamente complicata (in genere occorre far girare il programma \texttt{fsck} per riparare il filesystem); data la sua pericolosità in Linux questa @@ -666,7 +664,7 @@ crash dei programmi; la tecnica \texttt{unlink} subito dopo. \subsection{Le funzioni \texttt{remove} e \texttt{rename}} -\label{sec:filedir_cre_canc} +\label{sec:fileintr_remove} Al contrario di quanto avviene con altri unix in Linux non è possibile usare \texttt{unlink} sulle directory, per cancellare una directory si può usare la @@ -740,7 +738,7 @@ nuovo nome dopo che il vecchio \end{prototype} \subsection{I link simbolici} -\label{sec:filedir_sym_link} +\label{sec:fileintr_symlink} Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può funzionare soltanto per file che risiedono sullo stesso filesystem, dato che diff --git a/filestd.tex b/filestd.tex index 174ae98..da1f600 100644 --- a/filestd.tex +++ b/filestd.tex @@ -77,10 +77,10 @@ nell'header \texttt{stdio.h} e sono: \label{sec:filestd_details} \subsection{File temporanei} -\label{sec:filestd_details} +\label{sec:filestd_temp_file} \subsection{Efficienza} -\label{sec:filestd_details} +\label{sec:filestd_efficiency} diff --git a/intro.tex b/intro.tex index 0913f58..6fc0fec 100644 --- a/intro.tex +++ b/intro.tex @@ -217,7 +217,7 @@ In questo modo il sistema dell'utente a cui appartiene ed impedire ad altri utenti di interferire con esso. Inoltre con questo sistema viene anche garantita una forma base di sicurezza interna in quanto anche l'accesso ai file (vedi -\secref{sec:fileintr_access_ctrl}) è regolato da questo meccanismo di +\secref{sec:filedir_access_control}) è regolato da questo meccanismo di identificazione. Un utente speciale del sistema è \textit{root}, il cui uid è zero. Esso @@ -237,7 +237,7 @@ descritti in precedenza sono disattivati. \subsection{Lo standard POSIX} -\label{sec:intro_ansiC} +\label{sec:intro_posix} diff --git a/network.tex b/network.tex index a37ca6d..f6b571b 100644 --- a/network.tex +++ b/network.tex @@ -130,7 +130,7 @@ Il programma anzitutto include gli header necessari (\texttt{\small 1--5}); dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa tutta la parte relativa al trattamento degli argomenti passati dalla linea di comando (effettuata con le apposite routines illustrate in -\capref{cha:parameter_options}). +\capref{sec:proc_opt_handling}). Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale diff --git a/process.tex b/process.tex index 6058959..c19ebe6 100644 --- a/process.tex +++ b/process.tex @@ -59,9 +59,9 @@ linea di comando, in sostanza un prototipo che va sempre bene In realtà nei sistemi unix esiste un'altro modo per definire la funzione \texttt{main}, che prevede la presenza di un terzo parametro, \texttt{char - *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{proc_environ}) del -programma; questa forma però non è prevista dallo standard POSIX.1 per cui se -si vogliono scrivere programmi portabili è meglio evitarla. + *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ}) +del programma; questa forma però non è prevista dallo standard POSIX.1 per cui +se si vogliono scrivere programmi portabili è meglio evitarla. \subsection{Come chiudere un programma} @@ -77,7 +77,7 @@ che passa il controllo direttamente al kernel. Oltre alla conclusione ``normale'' esiste anche la possibilità di una conclusione ``anomala'' del programma a causa di segnali o della chiamata alla funzione \texttt{abort} (che comunque genera un segnale che termina il -programma); torneremo su questo in \secref{sec:sig_abort}. +programma); torneremo su questo in \secref{sec:sig_prog_error}. Il valore di ritorno della funzione main, o quello usato nelle chiamate ad \texttt{exit} e \texttt{\_exit}, viene chiamato \textit{exit status} e passato @@ -116,7 +116,7 @@ Infine occorre distinguere fra lo stato di uscita di un programma possibile un processo possa essere terminato (da un segnale) prima che il programma in esecuzione si sia concluso. In caso di conclusione normale del programma però lo stato di uscita diventa parte dello stato di conclusione del -processo (vedi \secref{sec:prochand_XXX}). +processo (vedi \secref{sec:prochand_xxx}). \subsection{Le funzioni \texttt{exit} e \texttt{\_exit}} @@ -155,7 +155,7 @@ La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga presente che questo non comporta il salvataggio dei dati bufferizzati degli stream), fa si che ogni figlio del processo sia ereditato da \texttt{init} (vedi \secref{cha:process_handling}), manda un segnale \texttt{SIGCHLD} al -processo padre (vedi \ref{sec:sig_sigchild}) ed infine ritorna lo stato di +processo padre (vedi \ref{sec:sig_job_control}) ed infine ritorna lo stato di uscita specificato in \texttt{status} che può essere raccolto usando la funzione \texttt{wait} (vedi \secref{sec:prochand_wait}). @@ -533,7 +533,7 @@ l'errore. Per questo motivo l'implementazione delle routine di allocazione delle glibc mette a disposizione una serie di funzionalità (su cui torneremo in -\secref{sec:proc_mem_advanced}) che permettono di tracciare le allocazioni e +\secref{sec:xxx_advanced}) che permettono di tracciare le allocazioni e le disallocazione, e definisce anche una serie di possibili agganci che permettono di sostituire alle funzioni di libreria una propria versione (che può essere più o meno specializzata per il debugging). @@ -608,7 +608,7 @@ del segmento dati. \subsection{Il controllo della memoria virtuale} -\label{sec:proc_mem_mlock} +\label{sec:proc_mem_lock} Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in maniera trasparente ai processi, decidendo quando rimuovere pagine dalla @@ -818,5 +818,5 @@ versione estesa di \texttt{getopt}. \subsection{Le variabili di ambiente} -\label{sec:proc_env_var} +\label{sec:proc_environ} diff --git a/prochand.tex b/prochand.tex index 721b899..e43caa9 100644 --- a/prochand.tex +++ b/prochand.tex @@ -143,5 +143,5 @@ Linux come il filesystem uid. \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} -\label{sec:prochand_setuid} +\label{sec:prochand_seteuid} diff --git a/signal.tex b/signal.tex index 3999212..ec3bf55 100644 --- a/signal.tex +++ b/signal.tex @@ -1,5 +1,5 @@ \chapter{I segnali} -\label{sec:signals} +\label{cha:signals} I segnali sono il primo e più semplice meccanismo di comunicazione nei confronti dei processi. Non portano con se nessuna informazione che non sia il @@ -161,8 +161,6 @@ determinare quali segnali sono bloccati e quali sono pendenti. - - \subsubsection{Tipi di segnali} \label{sec:sig_types} diff --git a/simpltcp.tex b/simpltcp.tex index b024478..38df63e 100644 --- a/simpltcp.tex +++ b/simpltcp.tex @@ -48,7 +48,7 @@ corpo principale, costituito dalla funzione \texttt{main}. Questa si incarica di creare il socket, metterlo in ascolto di connessioni in arrivo e creare un processo figlio a cui delegare la gestione di ciascuna connessione. Questa parte, riportata in \nfig, è analoga a quella vista nel precedente esempio -esaminato in \secref{sec:TCPelem_serv_code}. +esaminato in \secref{sec:TCPel_cunc_serv}. \begin{figure}[!htb] \footnotesize @@ -114,7 +114,7 @@ int main(int argc, char *argv[]) La struttura di questa prima versione del server è sostanzialmente identica a quella dell'esempio citato, ed ad esso si applicano le considerazioni fatte in \secref{sec:TCPel_cunc_daytime}. Le uniche differenze rispetto all'esempio in -\figref{fig:TCPelem_serv_code} sono che in questo caso per il socket in +\figref{fig:TCPel_serv_code} sono che in questo caso per il socket in ascolto viene usata la porta 7 e tutta la gestione della comunicazione è delegata alla funzione \texttt{ServEcho}. % Per ogni connessione viene creato un @@ -147,7 +147,7 @@ void ServEcho(int sockfd) { \end{lstlisting} \caption{Codice della prima versione della funzione \texttt{ServEcho} per la gestione del servizio \texttt{echo}.} - \label{fig:TCPsimpl_sockecho_code} + \label{fig:TCPsimpl_server_elem_sub} \end{figure} Quando il client chiude la connessione il ricevimento del FIN fa ritornare la @@ -157,7 +157,7 @@ del processo figlio. \subsection{Il client} -\label{sec:TCPsimp_server_main} +\label{sec:TCPsimp_client_main} Il codice del client è riportato in \nfig, anche esso ricalca la struttura del precedente client per il servizio \texttt{daytime} (vedi @@ -201,7 +201,7 @@ int main(int argc, char *argv[]) } \end{lstlisting} \caption{Codice della prima versione del client \texttt{echo}.} - \label{fig:TCPsimpl_sockecho_code} + \label{fig:TCPsimpl_client_elem} \end{figure} La funzione \texttt{main} si occupa della creazione del socket e della @@ -234,7 +234,7 @@ void ClientEcho(FILE * filein, int socket) \end{lstlisting} \caption{Codice della prima versione della funzione \texttt{ClientEcho} per la gestione del servizio \texttt{echo}.} - \label{fig:TCPsimpl_sockecho_code} + \label{fig:TCPsimpl_client_echo_sub} \end{figure} La funzione utilizza due buffer per gestire i dati inviati e letti sul socket @@ -337,7 +337,7 @@ l'immediatamente stampa a video. \subsection{La conclusione normale} -\label{sec:TCPsimpl_startup} +\label{sec:TCPsimpl_conclusion} Tutto quello che scriveremo sul client sarà rimandato indietro dal server e ristampato a video fintanto che non concluderemo l'immissione dei dati; una @@ -394,7 +394,7 @@ casi seguenti: Tutto questo riguarda la connessione, c'è però un'altro effetto del procedimento di chiusura del processo figlio nel server, e cioè l'invio del segnale \texttt{SIGCHILD} al padre. Dato che non si è installato un -manipolatore (vedi \secref{cap:signal} per le problematiche relative) e che +manipolatore (vedi \secref{cha:signals} per le problematiche relative) e che l'azione di default per questo segnale è quella di essere ignorato quello che avremo è che il processo figlio entrerà nello stato di zombie, come risulta una volta che ripetiamo il comando \texttt{ps}: -- 2.30.2 From d0e5573bf74f834c84e9adae6175f388e2f44916 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 3 Jul 2001 17:47:47 +0000 Subject: [PATCH 06/16] Aggiunte descrizioni di vari segnali --- fileintro.tex | 28 +++++---- signal.tex | 155 +++++++++++++++++++++++++++++++++++++------------- 2 files changed, 132 insertions(+), 51 deletions(-) diff --git a/fileintro.tex b/fileintro.tex index a7df993..85098c8 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -125,15 +125,15 @@ questa sia la directory radice allora il riferimento \label{sec:fileintr_file_types} Come detto in precedenza in unix esistono vari tipi di file, in Linux questi -sono implementati come oggetti del \textit{Virtual File System} e sono -presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei -vari tipi di file definiti dal Virtual File System è riportato in \ntab. +sono implementati come oggetti del \textit{Virtual File System} (vedi +\secref{sec:fileintro_vfs}) e sono presenti in tutti i filesystem unix-like +utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual +File System è riportato in \ntab. Si tenga ben presente che questa classificazione non ha nulla a che fare con la classificazione sui tipi di file (che in questo caso sono sempre file di dati) in base al loro contenuto, o tipo di accesso. - \begin{table}[htb] \begin{center} \begin{tabular}[c]{l l p{7cm}} @@ -301,9 +301,9 @@ un filesystem unix. In particolare occorre tenere presente dov' la divisione fondamentale fra kernel space e user space che tracciavamo al \capref{cha:intro_unix}. -In questa sezione esamineremo allora come viene implementato l'accesso ai -files in Linux, come il kernel gestisce i vari filesystem, descrivendo poi in -maniera un po' più dettagliata il filesystem standard di Linux, +In questa sezione esamineremo come viene implementato l'accesso ai files in +Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo +poi in maniera un po' più dettagliata il filesystem standard di Linux, l'\texttt{ext2}, come esempio di un filesystem unix-like. @@ -322,7 +322,7 @@ l'\texttt{ext2}, come esempio di un filesystem unix-like. % \textit{inode}, \textit{dentry}, \textit{dcache}. In Linux il concetto di \textit{everything is a file} è stato implementato -attraverso il \textit{virtual filesystem} (da qui in avanti VFS) che è +attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è l'interfaccia che il kernel rende disponibile ai programmi in user space attraverso la quale vengono manipolati i files; esso provvede un livello di indirezione che permette di collegare le operazioni di manipolazione sui files @@ -333,8 +333,8 @@ di filesystem differenti all'interno dello stesso albero delle directory Quando un processo esegue una system call che opera su un file il kernel chiama sempre una funzione implementata nel VFS; la funzione eseguirà le manipolazioni sulle strutture generiche e ridirigendo la chiamata alla -opportune routine del filesystem specifico a cui si fa riferimento, saranno -queste a chiamare le funzioni di piu basso livello che eseguono le operazioni +opportune routine del filesystem specifico a cui si fa riferimento. Saranno +queste a chiamare le funzioni di più basso livello che eseguono le operazioni di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \begin{figure}[htb] @@ -344,6 +344,14 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \label{fig:fileintro_VFS_scheme} \end{figure} +Il VFS definisce un insieme di funzioni che tutti i filesystem devono +implementare, queste funzioni + + + +\subsection{Il funzionamento del VFS} +\label{sec:fileintr_vfs_work} + La funzione più importante implementata dal VFS è la system call \texttt{open} che permette di aprire un file. Dato un pathname viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve \textit{dcache}), diff --git a/signal.tex b/signal.tex index ec3bf55..beebb00 100644 --- a/signal.tex +++ b/signal.tex @@ -342,7 +342,7 @@ stato dello stack e delle variabili al momento della ricezione del segnale. \begin{table}[htb] \centering - \begin{tabular}[c]{c p{6cm}} + \begin{tabular}[c]{c p{10cm}} A & L'azione di default è terminare il processo. \\ B & L'azione di default è ignorare il segnale. \\ C & L'azione di default è terminare il processo e scrivere un \textit{core @@ -412,19 +412,20 @@ Questi segnali sono: È tipico ottenere questo segnale dereferenziando un puntatore nullo o non inizializzato leggendo al di la della fine di un vettore. -\item \texttt{SIGBUS} In maniera analoga a \texttt{SIGSEGV} questo è un - segnale che viene generato di solito quando si dereferenzia un puntatore non - inzializzato, la differenza con con \texttt{SIGSEGV} è che questo indica un - accesso non valido su un indirizzo esistente (tipo fuori dallo heap o dallo - stack), mentre \texttt{SIGBUS} indica l'accesso ad un indirizzo non valido, - come nel caso di un puntatore non allineato. -\item \texttt{SIGABRT} Il segnale indica che il programma stesso ha rilevato - un errore che viene riportato chiamando la funzione \texttt{abort} che - genera questo segnale. +\item \texttt{SIGBUS} Il nome deriva da \textit{bus error}. Come + \texttt{SIGSEGV} questo è un segnale che viene generato di solito quando si + dereferenzia un puntatore non inzializzato, la differenza è + che\texttt{SIGSEGV} indica un accesso non permesso su un indirizzo esistente + (tipo fuori dallo heap o dallo stack), mentre \texttt{SIGBUS} indica + l'accesso ad un indirizzo non valido, come nel caso di un puntatore non + allineato. +\item \texttt{SIGABRT} Il nome deriva da \textit{abort}. Il segnale indica che + il programma stesso ha rilevato un errore che viene riportato chiamando la + funzione \texttt{abort} che genera questo segnale. \item \texttt{SIGTRAP} È il segnale generato da un'istruzione di breakpoint o dall'attivazione del tracciamento per il processo. È usato dai programmi per il debugging e se un programma normale non dovrebbe ricevere questo segnale. -\item \texttt{SIGSYS} Sta ad indicare che si è eseguta una istruzione che +\item \texttt{SIGSYS} Sta ad indicare che si è eseguita una istruzione che richiede l'esecuzione di una system call, ma si è fornito un codice sbagliato per quest'ultima. \end{description} @@ -447,29 +448,70 @@ periferica). L'azione di default di questi segnali è di terminare il processo, questi segnali sono: \begin{description} -\item \macro{SIGTERM} Questo è un segnale generico usato per causare la - conclusione di un programma. Al contrario di \macro{SIGKILL} può essere - intercettato, ignorato, bloccato. In genere lo si usa per chiedere in - maniera ``educata'' ad un processo di concludersi. -\item \macro{SIGINT} E il segnale di interruzione per il programma. È quello - che viene generato di default dal comando \cmd{kill} o dall'invio sul - terminale del carattere di interrupt (generato dalla sequenza \macro{C-\\}). -\item \macro{SIGQUIT} -\item \macro{SIGKILL} -\item \macro{SIGHUP} +\item \macro{SIGTERM} Il nome sta per \textit{terminate}. È un segnale + generico usato per causare la conclusione di un programma. Al contrario di + \macro{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si + usa per chiedere in maniera ``educata'' ad un processo di concludersi. +\item \macro{SIGINT} Il nome sta per \textit{interrupt}. È il segnale di + interruzione per il programma. È quello che viene generato di default dal + comando \cmd{kill} o dall'invio sul terminale del carattere di controllo + INTR (interrupt, generato dalla sequenza \macro{C-c}). +\item \macro{SIGQUIT} È analogo a \macro{SIGINT} con la differenze che è + controllato da un'altro carattere di controllo, QUIT, corrispondente alla + sequenza \macro{C-\\}. A differenza del precedente l'azione di default, + oltre alla terminazione del processo, comporta anche la creazione di un cor + dump. + + In genere lo si può pensare come corrispondente ad una condizione di + errore del programma rilevata dall'utente. Per questo motivo non è opportuno + fare eseguire al manipolatore di questo segnale le operazioni di pulizia + normalmente previste (tipo la cancellazione di file temporanei), dato che in + certi casi esse possono eliminare informazioni utili nell'esame dei core + dump. +\item \macro{SIGKILL} Il nomeè utilizzato per terminare in maniera immediata + qualunque programma. Questo segnale non può essere né intercettato, né + ignorato, né bloccato, per cui causa comunque la terminazione del processo. + In genere esso viene generato solo per richiesta esplicita dell'utente dal + comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può + intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno + brutali, come \macro{SIGTERM} o \macro{C-c} non funzionano. + + Se un processo non risponde a nessun altro segnale \macro{SIGKILL} ne causa + sempre la terminazione (in effetti il fallimento della terminazione di un + processo da parte di \macro{SIGKILL} costituirebbe un funzionamento del + kernel). Talvolta è il sistema stesso che può generare questo segnale quando + per condizioni particolari il processo non può più essere eseguito neanche + per eseguire il manipolatore. +\item \macro{SIGHUP} Il nome sta per \textit{hang-up}. Segnala che il + terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la + rete). Viene usato anche per riportare la terminazione del processo di + controllo di un terminale a tutti i processi della sessione, in modo che + essi possano disconnettersi dal relativo terminale. + + Viene inoltre usato in genere per segnalare ai demoni (che non hanno un + terminale di controllo) la necessità di reinizializzarsi e rileggere il/i + file di configurazione. \end{description} \subsection{I segnali di allarme} \label{sec:sig_alarm} -Questi segnali sono generati dalla scadenza di un temporizzatore. Il loro -comportamento di default è quello di causare la terminazione del programma, ma -con questi segnali la scelta di default è irrilevante, in quanto il loro uso -presuppone sempre la necessità di un manipolatore. Questi segnali sono: +Questi segnali sono generati dalla scadenza di un timer. Il loro comportamento +di default è quello di causare la terminazione del programma, ma con questi +segnali la scelta di default è irrilevante, in quanto il loro uso presuppone +sempre la necessità di un manipolatore. Questi segnali sono: \begin{description} -\item \texttt{SIGALRM} -\item \texttt{SIGVTALRM} -\item \texttt{SIGPROF} +\item \texttt{SIGALRM} Il nome sta per \textit{alarm}. Segnale la scadenza di + un timer misurato sul tempo reale o sull'orologio di sistema. È normalente + usato dalla funzione \func{alarm}. +\item \texttt{SIGVTALRM} Il nome sta per \textit{virtual alarm}. È analogo al + precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal + processo. +\item \texttt{SIGPROF} Il nome sta per \textit{profiling}. Indica la scadenza + di un timer che misura sia il tempo di CPU speso direttamente dal processo + che quello che il sistema ha speso per conto di quest'utlimo. In genere + viene usato dai tool che servono a fare il profilo d'uso della CPU da parte + del processo. \end{description} @@ -482,24 +524,55 @@ generare questi segnali. L'azione di default è di essere ignorati. Questi segnali sono: \begin{description} -\item \texttt{SIGIO} -\item \texttt{SIGURG} -\item \texttt{SIGPOLL} +\item \texttt{SIGIO} Questo segnale viene inviato quando un file descriptor è + pronto per eseguire dell'input/output. In molti sistemi solo i socket e i + terminali possono generare questo segnale, in Linux questo può essere usato + anche per i file, posto che la \func{fcntl} abbia avuto successo. +\item \texttt{SIGURG} Questo segnale è inviato quando arrivano dei dati + urgenti o \textit{out of band} su di un socket; per maggiori dettagli al + proposito si veda \secref{sec:xxx_urgent_data}. +\item \texttt{SIGPOLL} Questo segnale è equivalente a \macro{SIGIO}, è + definito solo per compatibilità con i sistemi System V. \end{description} \subsection{I segnali per il controllo di sessione} \label{sec:sig_job_control} -Questi sono i segnali usati dal controllo di sessione, il loro uso è specifico -per questo argomento e verrà trattato quando lo affronteremo. -Questi segnali sono: -\begin{description} -\item \texttt{SIGCHLD} -\item \texttt{SIGCONT} -\item \texttt{SIGSTOP} -\item \texttt{SIGTSTP} -\item \texttt{SIGTTIN} -\item \texttt{SIGTTOU} +Questi sono i segnali usati dal controllo delle sessioni e dei processi, il +loro uso è specifico e viene trattato in maniera specifica nelle sezioni in +cui si trattano gli argomenti relativi. Questi segnali sono: +\begin{description} +\item \macro{SIGCHLD} Questo è il segnale mandato al processo padre quando un + figlio termina o viene fermato. L'azione di default è di ignorare il + segnale, la sua gestione è trattata in \secref{sec:prochand_wait}. +\item \macro{SIGCLD} Per Linux questo è solo un segnale identico al + precedente, il nome è obsoleto e andrebbe evitato. +\item \macro{SIGCONT} Il nome sta per \textit{continue}. Il segnale viene + usato per fare ripartire un programma precedentemente fermato da + \macro{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre + ripartire il processo prima della sua consegna. Il comportamento di default + è di fare solo questo; il segnale non può essere bloccato. Si può anche + installare un manipolatore, ma il segnale provoca comunque il riavvio del + processo. + + La maggior pare dei programmi non hanno necessità di intercettare il + segnale, in quanto esso è completamente trasparente rispetto all'esecuzione + che riparte senza che il programma noti niente. Si possono installare dei + manipolatori per far si che un programma produca una qualche azione speciale + se viene fermato e riavviato, come per esempio riscrivere un prompt, o + inviare un avviso. +\item \macro{SIGSTOP} Il segnale ferma un processo (lo porta in uno stato di + sleep); il segnale non può essere né intercettato, né ignorato, né bloccato. +\item \macro{SIGTSTP} Il nome sta per \textit{interactive stop}. Il segnale + ferma il processo interattivamente, ed è generato dal carattere SUSP + (prodotto dalla combinazione \macro{C-z}), ed al contrario di + \macro{SIGSTOP} può essere intercettato e ignorato. In genere un programma + installa un manipolatore per questo segnale quando vuole lasciare il sistema + o il terminale in uno stato definito prima di fermarsi; se per esempio un + programma ha disabilitato l'eco sul terminale può installare un manipolatore + per riabilitarlo prima di fermarsi. +\item \macro{SIGTTIN} +\item \macro{SIGTTOU} \end{description} \subsection{I segnali di operazioni errate} -- 2.30.2 From f226d67a85c76d482da1f06f2c34c6231dfb5312 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 3 Jul 2001 22:56:37 +0000 Subject: [PATCH 07/16] Passata di ispell --- signal.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/signal.tex b/signal.tex index beebb00..d8468d8 100644 --- a/signal.tex +++ b/signal.tex @@ -137,7 +137,7 @@ Nella semantica \textit{reliable} (quella utilizzata da Linux e da ogni Unix moderno) invece il signal handler una volta installato resta attivo e non si hanno tutti i problemi precedenti. In questa semantica i segnali vengono \textsl{generati} dal kernel per un processo all'occorrenza dell'evento che -causa il segnale. In genere questo viene fatto dal kernel settanto un flag +causa il segnale. In genere questo viene fatto dal kernel settando un flag nella process table del processo. Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese @@ -459,7 +459,7 @@ segnali sono: \item \macro{SIGQUIT} È analogo a \macro{SIGINT} con la differenze che è controllato da un'altro carattere di controllo, QUIT, corrispondente alla sequenza \macro{C-\\}. A differenza del precedente l'azione di default, - oltre alla terminazione del processo, comporta anche la creazione di un cor + oltre alla terminazione del processo, comporta anche la creazione di un core dump. In genere lo si può pensare come corrispondente ad una condizione di @@ -468,7 +468,7 @@ segnali sono: normalmente previste (tipo la cancellazione di file temporanei), dato che in certi casi esse possono eliminare informazioni utili nell'esame dei core dump. -\item \macro{SIGKILL} Il nomeè utilizzato per terminare in maniera immediata +\item \macro{SIGKILL} Il nome è utilizzato per terminare in maniera immediata qualunque programma. Questo segnale non può essere né intercettato, né ignorato, né bloccato, per cui causa comunque la terminazione del processo. In genere esso viene generato solo per richiesta esplicita dell'utente dal @@ -502,14 +502,14 @@ segnali la scelta di default sempre la necessità di un manipolatore. Questi segnali sono: \begin{description} \item \texttt{SIGALRM} Il nome sta per \textit{alarm}. Segnale la scadenza di - un timer misurato sul tempo reale o sull'orologio di sistema. È normalente + un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente usato dalla funzione \func{alarm}. \item \texttt{SIGVTALRM} Il nome sta per \textit{virtual alarm}. È analogo al precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal processo. \item \texttt{SIGPROF} Il nome sta per \textit{profiling}. Indica la scadenza di un timer che misura sia il tempo di CPU speso direttamente dal processo - che quello che il sistema ha speso per conto di quest'utlimo. In genere + che quello che il sistema ha speso per conto di quest'ultimo. In genere viene usato dai tool che servono a fare il profilo d'uso della CPU da parte del processo. \end{description} @@ -602,7 +602,7 @@ classificabili in maniera omogenea. Questi segnali sono: \item \texttt{SIGUSR1} e \texttt{SIGUSR2} Sono due segnali a disposizione dell'utente che li può usare per quello che vuole. Possono essere utili per implementare una comunicazione elementare fra processi diversi, o per - eseguire a richiesta una operazione utlizzando un manipolatore. L'azione di + eseguire a richiesta una operazione utilizzando un manipolatore. L'azione di default è terminare il processo. \item \texttt{SIGWINCH} Il nome sta per \textit{window (size) change} ed è generato da molti sistemi (GNU/Linux compreso) quando le dimensioni (in @@ -664,7 +664,7 @@ typedef void (* sighandler_t)(int) cioè un puntatore ad una funzione di tipo \type{void} con un parametro di tipo \type{int}\footnote{si devono usare le parentesi intorno al nome della funzione per via delle precedenze degli operatori del C, senza di esse si - sarebbe definita una funzione che ritorna un puntatarore a \type{void} e non + sarebbe definita una funzione che ritorna un puntatore a \type{void} e non un puntatore ad una funzione \type{void}}. Il numero di segnale passato in \param{signum} segnale può essere indicato -- 2.30.2 From a88d4dd8fdd85cdfe8fd04684d4afb4c24174995 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 8 Jul 2001 21:30:27 +0000 Subject: [PATCH 08/16] Continua la risistemazione. Aggiunta roba su ext2 ed iniziato la parte attinente stat & compny. --- filedir.tex | 682 +++++++++++++++++++++++++++++++++++++++----------- fileintro.tex | 450 ++++++++++----------------------- gapil.tex | 2 +- 3 files changed, 660 insertions(+), 474 deletions(-) diff --git a/filedir.tex b/filedir.tex index d811bfc..361e05a 100644 --- a/filedir.tex +++ b/filedir.tex @@ -5,8 +5,444 @@ In questo capitolo tratteremo in dettaglio le modalit files e directories, ed in particolare esamineremo come è strutturato il sistema base di protezioni e controllo di accesso ai files, e tutta l'interfaccia che permette la manipolazione dei vari attributi di files e -directories. Tutto quello che riguarda invece la manipolazione dei contenuti è -lasciato ai capitoli successivi. +directories. Tutto quello che riguarda invece la manipolazione del contenuto +dei file è lasciato ai capitoli successivi. + + +\section{La gestione di file e directory} + +Le prime funzioni che considereremo sono quelle relative alla gestione di file +e directory, secondo le caratteristiche standard che essi presentano in un +filesystem unix, già esaminate in precedenza (vedi +\secref{sec:fileintr_filesystem}). + +\subsection{Le funzioni \texttt{link} e \texttt{unlink}} +\label{sec:fileintr_link} + +Una delle caratteristiche usate quando si opera con i file è quella di poter +creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo +stesso file accedendovi da directory diverse. Questo è possibile anche in +ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link}, +ma data la struttura del sistema ci sono due metodi sostanzialmente diversi +per fare questa operazione. + +Come si è appena detto l'accesso al contenuto di un file su disco avviene +attraverso il suo inode, e il nome che si trova in una directory è solo una +etichetta associata ad un puntatore a detto inode. Questo significa che la +realizzazione di un link è immediata in quanto uno stesso file può avere tanti +nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo +stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una +particolare preferenza rispetto agli altri. + +Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si +suole chiamare questo tipo di associazione un collegamento diretto (o +\textit{hard link}). Il prototipo della funzione e le sue caratteristiche +principali, come risultano dalla man page, sono le seguenti: +\begin{prototype}{unistd.h} +{int link(const char * oldpath, const char * newpath)} + Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath} + dandogli nome \texttt{newpath}. + + La funzione restituisce zero in caso di successo e -1 per un errore, in caso + di errore. La variabile \texttt{errno} viene settata secondo i seguenti + codici di errore: + \begin{errlist} + \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo + stesso filesystem. + \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e + \texttt{newpath} non supporta i link diretti o è una directory. + \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori + dello spazio di indirizzi del processo. + \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o + per attraversare le directories), vedi \secref{sec:filedir_access_control} + per i dettagli. + \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo. + \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath} + non esiste o è un link simbolico spezzato. + \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath} + non è una directory. + \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a + completare l'operazione. + \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è + su un filesystem montato readonly. + \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di + già. + \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il + numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi + \secref{sec:xxx_limits}). + \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione + di \texttt{oldpath} o \texttt{newpath}. + \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha + spazio per ulteriori voci. + \item \texttt{EIO} c'è stato un errore di input/output. + \end{errlist} +\end{prototype} + +La creazione di un nuovo collegamento diretto non copia il contenuto del file, +ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il +nuovo nome ai precedenti. Si noti che uno stesso file può essere così +richiamato in diverse directory. + +Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del +collegamento diretto è possibile solo se entrambi i pathname sono nello stesso +filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è +il caso ad esempio del filesystem \texttt{vfat} di windows). + +La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, +ma solo l'amministratore è in grado di creare un collegamento diretto ad +un'altra directory, questo lo si fa perché in questo caso è possibile creare +dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti +programmi non sono in grado di gestire e la cui rimozione diventa estremamente +complicata (in genere occorre far girare il programma \texttt{fsck} per +riparare il filesystem); data la sua pericolosità in Linux questa +caratteristica è stata disabilitata, e la funzione restituisce l'errore +\texttt{EPERM}. + +La rimozione di un file (o più precisamente della voce che lo referenzia) si +effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: + +\begin{prototype}{unistd.h}{int unlink(const char * pathname)} + Cancella il nome specificato dal pathname nella relativa directory e + decrementa il numero di riferimenti nel relativo inode. Nel caso di link + simbolico cancella il link simbolico; nel caso di socket, fifo o file di + dispositivo rimuove il nome, ma come per i file i processi che hanno aperto + uno di questi oggetti possono continuare ad utilizzarlo. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. La variabile \texttt{errno} viene + settata secondo i seguenti codici di errore: + \begin{errlist} + \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o + per attraversare le directories), vedi \secref{sec:filedir_access_control} + per i dettagli. + \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory + (valore specifico ritornato da linux che non consente l'uso di + \texttt{unlink} con le directory, e non conforme allo standard POSIX, che + prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia + consnetita o il processo non abbia privilegi sufficienti). + \item \texttt{EFAULT} la stringa + passata come parametro è fuori dello spazio di indirizzi del processo. + \item \texttt{ENAMETOOLONG} il pathname troppo lungo. + \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link + simbolico spezzato. + \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory. + \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory. + \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a + completare l'operazione. + \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola + lettura. + \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del + pathname. + \item \texttt{EIO} errore di input/output. + \end{errlist} +\end{prototype} + +Per cancellare una voce in una directory è necessario avere il permesso di +scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e +il diritto di esecuzione sulla directory che la contiene (torneremo in +dettaglio sui permessi e gli attributi fra poco), se inoltre lo +\textit{sticky} bit è settato occorrerà anche essere proprietari del file o +proprietari della directory (o root, per cui nessuna delle restrizioni è +applicata). + +Una delle caratteristiche di queste funzioni è che la creazione/rimozione +della nome dalla directory e l'incremento/decremento del numero di riferimenti +nell'inode deve essere una operazione atomica (cioè non interrompibile da +altri) processi, per questo entrambe queste funzioni sono realizzate tramite +una singola system call. + +Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti +i riferimenti ad esso sono stati cancellati, solo quando il \textit{link + count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A +questo però si aggiunge una altra condizione, e cioè che non ci siano processi +che abbiano detto file aperto. Come accennato questa proprietà viene spesso +usata per essere sicuri di non lasciare file temporanei su disco in caso di +crash dei programmi; la tecnica è quella di aprire il file e chiamare +\texttt{unlink} subito dopo. + +\subsection{Le funzioni \texttt{remove} e \texttt{rename}} +\label{sec:fileintr_remove} + +Al contrario di quanto avviene con altri unix in Linux non è possibile usare +\texttt{unlink} sulle directory, per cancellare una directory si può usare la +funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la +funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C +per cancellare un file o una directory (e funziona anche per i sistemi che non +supportano i link diretti), che per i file è identica alla \texttt{unlink} e +per le directory è identica alla \texttt{rmdir}: + +\begin{prototype}{stdio.h}{int remove(const char *pathname)} + Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e + \texttt{rmdir} per le directory. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. Per i codici di errori vedi quanto + riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}. +\end{prototype} + +Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il +vantaggio nell'uso di questa funzione al posto della chiamata successiva di +\texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in +questo modo non c'è la possibilità che un processo che cerchi di accedere al +nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante. + +\begin{prototype}{stdio.h} +{int rename(const char *oldpath, const char *newpath)} + Rinomina un file, spostandolo fra directory diverse quando richiesto. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. La variabile \texttt{errno} viene + settata secondo i seguenti codici di errore: + \begin{errlist} + \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre + \texttt{oldpath} non è una directory. + \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo + stesso filesystem. + \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e + non vuota. + \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da + parte di qualche processo (come directory di lavoro o come root) o del + sistema (come mount point). + \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di + \texttt{oldpath} o più in generale si è cercato di creare una directory + come sottodirectory di se stessa. + \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link + consentiti o è una directory e la directory che contiene \texttt{newpath} + ha già il massimo numero di link. + \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory + o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una + directory. + \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello + spazio di indirizzi del processo. + \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in + cui si vuole creare il nuovo link o una delle directory del pathname non + consente la ricerca (permesso di esecuzione). + \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o + \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non + consentono rispettivamente la cancellazione e la creazione del file, o il + filesystem non supporta i link. + \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo. + \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link + simbolico spezzato. + \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a + completare l'operazione. + \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura. + \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del + pathname. + \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la + nuova voce. + \end{errlist} +\end{prototype} + +\subsection{I link simbolici} +\label{sec:fileintr_symlink} + +Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può +funzionare soltanto per file che risiedono sullo stesso filesystem, dato che +in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di +tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una +directory. + +Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di +link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono, +come avviene in altri sistemi operativi, dei file che contengono il +semplicemente il riferimento ad un altro file (o directory). In questo modo è +possibile effettuare link anche attraverso filesystem diversi e a directory, e +pure a file che non esistono ancora. + +Il sistema funziona in quanto i link simbolici sono contrassegnati come tali +al kernel (analogamente a quanto avviene per le directory) per cui la chiamata +ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la +lettura del contenuto del medesimo e l'applicazione della funzione al file +specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare +o rinominare i file operano direttamente sul link simbolico. Inoltre esistono +funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere +alle informazioni del link invece che a quelle del file a cui esso fa +riferimento. + +Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte +dichiarate nell'header file \texttt{unistd.h}. + +\begin{prototype}{unistd.h} +{int symlink(const char * oldname, const char * newname)} + Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli + nome \texttt{newname}. + + La funzione restituisce zero in caso di successo e -1 per un errore, in caso + di errore. La variabile \texttt{errno} viene settata secondo i codici di + errore standard di accesso ai files (trattati in dettaglio in + \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: + \begin{errlist} + \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di + già. + \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è + su un filesystem montato readonly. + \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il + link è piena e non c'è ulteriore spazio disponibile. + \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di + \texttt{oldname} o di \texttt{newname}. + \end{errlist} +\end{prototype} + +Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare +un'altra funzione quando si vuole leggere il contenuto di un link simbolico, +questa funzione è la: + +\begin{prototype}{unistd.h} +{int readlink(const char * path, char * buff, size\_t size)} + Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer + \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un + carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo + piccolo per contenerla. + + La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o + -1 per un errore, in caso di errore. La variabile \texttt{errno} viene + settata secondo i codici di errore: + \begin{errlist} + \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di + già. + \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è + su un filesystem montato readonly. + \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il + link è piena e non c'è ulteriore spazio disponibile. + \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di + \texttt{oldname} o di \texttt{newname}. + \end{errlist} +\end{prototype} + +\section{La manipolazione delle directories} +\label{sec:filedir_dir_handling} + +\subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} +\label{sec:filedir_dir_creat_rem} + +Per creare una nuova directory si può usare la seguente funzione, omonima +dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati +programma deve includere il file \texttt{sys/types.h}. + +\begin{prototype}{sys/stat.h} +{int mkdir (const char * dirname, mode\_t mode)} + Questa funzione crea una nuova directory vuota con il nome indicato da + \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome + può essere indicato con il pathname assoluto o relativo. + + La funzione restituisce zero in caso di successo e -1 per un errore, in caso + di errore \texttt{errno} viene settata secondo i codici di errore standard + di accesso ai files (trattati in dettaglio in + \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: + \begin{errlist} + \item \texttt{EACCESS} + Non c'è il permesso di scrittura per la directory in cui si vuole inserire + la nuova directory. + \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già. + \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory + contiene troppi file. Sotto Linux questo normalmente non avviene perché il + filesystem standard consente la creazione di un numero di file maggiore di + quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che + fare anche con filesystem di altri sistemi questo errore può presentarsi. + \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare + la nuova directory. + \item \texttt{EROFS} La directory su cui si vuole inserire la nuova + directory è su un filesystem montato readonly. + \end{errlist} +\end{prototype} + + +\subsection{Accesso alle directory} +\label{sec:filedir_dir_read} + +Benché le directory siano oggetti del filesystem come tutti gli altri non ha +ovviamente senso aprirle come fossero dei file di dati. Può però essere utile +poterne leggere il contenuto ad esempio per fare la lista dei file che esse +contengono o ricerche sui medesimi. + +Per accedere al contenuto delle directory si usano i cosiddetti +\textit{directory streams} (chiamati così per l'analogia con i file stream); +la funzione \texttt{opendir} apre uno di questi stream e la funzione +\texttt{readdir} legge il contenuto della directory, i cui elementi sono le +\textit{directory entries} (da distinguersi da quelle della cache di cui +parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura +\texttt{struct dirent}. + + +\subsection{La directory di lavoro} +\label{sec:filedir_work_dir} + +A ciascun processo è associato ad una directory nel filesystem che è chiamata +directory corrente o directory di lavoro (\textit{current working directory}) +che è quella a cui si fa riferimento quando un filename è espresso in forma +relativa (relativa appunto a questa directory). + +Quando un utente effettua il login questa directory viene settata alla +cosiddetta \textit{home directory} del suo account, il comando \texttt{cd} +della shell consente di cambiarla a piacere, spostandosi da una directory ad +un'altra. Siccome la directory corrente resta la stessa quando viene creato +un processo figlio, la directory corrente della shell diventa anche la +directory corrente di qualunque comando da essa lanciato. + +Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro +corrente. + +\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)} + Restituisce il filename completo della directory di lavoro corrente nella + stringa puntata da \texttt{buffer}, che deve essere precedentemente + allocata, per una dimensione massima di \texttt{size}. Si può anche + specificare un puntatore nullo come \textit{buffer}, nel qual caso la + stringa sarà allocata automaticamente per una dimensione pari a + \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta + del pathname altrimenti. In questo caso si deve ricordare di disallocare la + stringa una volta cessato il suo utilizzo. + + La funzione restituisce il puntatore \texttt{buffer} se riesce, + \texttt{NULL} se fallisce, in quest'ultimo caso la variabile + \texttt{errno} è settata con i seguenti codici di errore: + \begin{errlist} + \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non + è nullo. + \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della + lunghezza del pathname. + \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei + componenti del pathname (cioè su una delle directory superiori alla + corrente). + \end{errlist} +\end{prototype} + +Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)} +fatta per compatibilità all'indietro con BSD, che non consente di specificare +la dimensione del buffer; esso deve essere allocato in precedenza ed avere una +dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi +\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione +superiore per un pathname, per cui non è detto che il buffer sia sufficiente a +contenere il nome del file, e questa è la ragione principale per cui questa +funzione è deprecata. + +Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)} +che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola +differenza che essa ritorna il valore della variabile di ambiente +\texttt{PWD}, che essendo costruita dalla shell può contenere anche dei +riferimenti simbolici. + +Come già detto in unix anche le directory sono file, è possibile pertanto +riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello, +e non solo tramite il filename; per questo motivo ci sono due diverse funzioni +per cambiare directory di lavoro. + +\begin{prototype}{unistd.h}{int chdir (const char * pathname)} + Come dice il nome (che significa \textit{change directory}) questa funzione + serve a cambiare la directory di lavoro a quella specificata dal pathname + contenuto nella stringa \texttt{pathname}. +\end{prototype} + +\begin{prototype}{unistd.h}{int fchdir (int filedes)} + Analoga alla precedente, ma usa un file descriptor invece del pathname. + + Entrambe le funzioni restituiscono zero in caso di successo e -1 per un + errore, in caso di errore \texttt{errno} viene settata secondo i codici di + errore standard di accesso ai files (trattati in dettaglio in + \secref{sec:filedir_access_control}) ai quali si aggiunge il codice + \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia + una directory. +\end{prototype} \section{La manipolazione delle caratteristiche dei files} @@ -25,14 +461,28 @@ manipolazione sar \label{sec:filedir_stat} La lettura delle informazioni relative ai file è fatta attraverso la famiglia -delle funzioni \texttt{stat}, questa è la funzione che il comando \texttt{ls} -usa per poter stampare tutti i dati dei files; il prototipo della funzione è -il seguente; -\begin{prototype}{unistd.h} -{int stat(const char *file\_name, struct stat *buf)} +delle funzioni \texttt{stat}, che è la funzione che il comando \texttt{ls} usa +per poter stampare tutti i dati dei files. I prototipi di queste funzioni sono +i seguenti: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/stat.h} + \headdecl{unistd.h} + + \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le + informazione del file specificato da \var{file\_name} e le inserisce in + \var{buf}. - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore \texttt{errno} viene settato ai valori: + \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a + \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono + lette le informazioni relativa ad esso e non al file a cui punta. + + \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat} + eccetto che funziona con un file aperto, specificato tramite il suo file + descriptor \var{filedes}. + + Le funzioni restituiscono zero in caso di successo e -1 per un errore, in + caso di errore \texttt{errno} viene settato ai valori: \begin{errlist} \item \texttt{EACCESS} Non c'è il permesso di accedere al file. \item \texttt{ENOTDIR} Una componente del pathname non è una directory. @@ -43,7 +493,7 @@ il seguente; completare l'operazione. \item \texttt{ENAMETOOLONG} Il filename è troppo lungo. \end{errlist} -\end{prototype} +\end{functions} La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in generale dipende dall'implementazione, la versione usata da Linux è mostrata @@ -81,23 +531,88 @@ struct stat { Si noti come i vari membri della struttura siano specificati come tipi nativi del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in -\texttt{sys/types.h}) - - +\texttt{sys/types.h}). \subsection{I tipi di file} \label{sec:filedir_file_types} -Come riportato in \tabref{tab:fileintr_file_types} in linux oltre ai file e +Come riportato in \tabref{tab:fileintr_file_types} in Linux oltre ai file e alle directory esistono vari altri oggetti che possono stare su un filesystem; -il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}, -dato che il valore numerico può variare a seconda delle implementazioni +il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}. +Dato che il valore numerico può variare a seconda delle implementazioni lo +standard POSIX definisce un insieme di macro per verificare il tipo di files, +queste venfono usate anche da Linux che supporta pure le estensioni per link +simbolici e socket definite da BDS, l'elenco è riportato in \ntab: +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + Macro & Tipo del file \\ + \hline + \hline + \macro{S\_ISREG(m)} & file normale \\ + \macro{S\_ISDIR(m)} & directory \\ + \macro{S\_ISCHR(m)} & device a caraetteri \\ + \macro{S\_ISBLK(m)} & device a blocchi\\ + \macro{S\_ISFIFO(m)} & fifo \\ + \macro{S\_ISLNK(m)} & link simbolico \\ + \macro{S\_ISSOCK(m)} & socket \\ + \hline + \end{tabular} + \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})} + \label{tab:filedir_file_type_macro} +\end{table} + +Oltre a queste macro è possibile usare direttamente il valore di +\var{st\_mode} per ricavare il significato dei vari bit del campo attraverso +l'uso dei flag riportati in \ntab: +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|l|} + \hline + Flag & Valore & Significato \\ + \hline + \hline + \macro{S\_IFMT} & 0170000 & bitmask for the file type bitfields \\ + \macro{S\_IFSOCK} & 0140000 & socket \\ + \macro{S\_IFLNK} & 0120000 & symbolic link \\ + \macro{S\_IFREG} & 0100000 & regular file \\ + \macro{S\_IFBLK} & 0060000 & block device \\ + \macro{S\_IFDIR} & 0040000 & directory \\ + \macro{S\_IFCHR} & 0020000 & character device \\ + \macro{S\_IFIFO} & 0010000 & fifo \\ + \macro{S\_ISUID} & 0004000 & set UID bit \\ + \macro{S\_ISGID} & 0002000 & set GID bit (see below) \\ + \macro{S\_ISVTX} & 0001000 & sticky bit (see below) \\ + \macro{S\_IRWXU} & 00700 & mask for file owner permissions \\ + \macro{S\_IRUSR} & 00400 & owner has read permission \\ + \macro{S\_IWUSR} & 00200 & owner has write permission \\ + \macro{S\_IXUSR} & 00100 & owner has execute permission \\ + \macro{S\_IRWXG} & 00070 & mask for group permissions \\ + \macro{S\_IRGRP} & 00040 & group has read permission \\ + \macro{S\_IWGRP} & 00020 & group has write permission \\ + \macro{S\_IXGRP} & 00010 & group has execute permission \\ + \macro{S\_IRWXO} & 00007 & mask for permissions for others (not in + group) \\ + \macro{S\_IROTH} & 00004 & others have read permission \\ + \macro{S\_IWOTH} & 00002 & others have write permisson \\ + \macro{S\_IXOTH} & 00001 & others have execute permission \\ + \hline + \end{tabular} + \caption{Flag per il campo \var{st\_mode} (definite in + \texttt{sys/stat.h})} + \label{tab:filedir_file_mode_flags} +\end{table} \subsection{La dimensione dei file} \label{sec:filedir_file_size} +Il membro \var{st\_size} contiene la dimensione del + \subsection{I tempi dei file} \label{sec:filedir_file_times} @@ -176,141 +691,6 @@ pertanto accesso senza restrizione a qualunque file del sistema. \label{sec:filedir_chown} -\section{La manipolazione delle directories} -\label{sec:filedir_dir_handling} - -\subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} -\label{sec:filedir_dir_creat_rem} - -Per creare una nuova directory si può usare la seguente funzione, omonima -dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati -programma deve includere il file \texttt{sys/types.h}. - -\begin{prototype}{sys/stat.h} -{int mkdir (const char * dirname, mode\_t mode)} - Questa funzione crea una nuova directory vuota con il nome indicato da - \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome - può essere indicato con il pathname assoluto o relativo. - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore \texttt{errno} viene settata secondo i codici di errore standard - di accesso ai files (trattati in dettaglio in - \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: - \begin{errlist} - \item \texttt{EACCESS} - Non c'è il permesso di scrittura per la directory in cui si vuole inserire - la nuova directory. - \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già. - \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory - contiene troppi file. Sotto Linux questo normalmente non avviene perché il - filesystem standard consente la creazione di un numero di file maggiore di - quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che - fare anche con filesystem di altri sistemi questo errore può presentarsi. - \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare - la nuova directory. - \item \texttt{EROFS} La directory su cui si vuole inserire la nuova - directory è su un filesystem montato readonly. - \end{errlist} -\end{prototype} - - -\subsection{Accesso alle directory} -\label{sec:filedir_dir_read} - -Benché le directory siano oggetti del filesystem come tutti gli altri non ha -ovviamente senso aprirle come fossero dei file di dati. Può però essere utile -poterne leggere il contenuto ad esempio per fare la lista dei file che esse -contengono o ricerche sui medesimi. - -Per accedere al contenuto delle directory si usano i cosiddetti -\textit{directory streams} (chiamati così per l'analogia con i file stream); -la funzione \texttt{opendir} apre uno di questi stream e la funzione -\texttt{readdir} legge il contenuto della directory, i cui elementi sono le -\textit{directory entries} (da distinguersi da quelle della cache di cui -parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura -\texttt{struct dirent}. - - -\subsection{La directory di lavoro} -\label{sec:filedir_work_dir} - -A ciascun processo è associato ad una directory nel filesystem che è chiamata -directory corrente o directory di lavoro (\textit{current working directory}) -che è quella a cui si fa riferimento quando un filename è espresso in forma -relativa (relativa appunto a questa directory). - -Quando un utente effettua il login questa directory viene settata alla -cosiddetta \textit{home directory} del suo account, il comando \texttt{cd} -della shell consente di cambiarla a piacere, spostandosi da una directory ad -un'altra. Siccome la directory corrente resta la stessa quando viene creato -un processo figlio, la directory corrente della shell diventa anche la -directory corrente di qualunque comando da essa lanciato. - -Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro -corrente. - -\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)} - Restituisce il filename completo della directory di lavoro corrente nella - stringa puntata da \texttt{buffer}, che deve essere precedentemente - allocata, per una dimensione massima di \texttt{size}. Si può anche - specificare un puntatore nullo come \textit{buffer}, nel qual caso la - stringa sarà allocata automaticamente per una dimensione pari a - \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta - del pathname altrimenti. In questo caso si deve ricordare di disallocare la - stringa una volta cessato il suo utilizzo. - - La funzione restituisce il puntatore \texttt{buffer} se riesce, - \texttt{NULL} se fallisce, in quest'ultimo caso la variabile - \texttt{errno} è settata con i seguenti codici di errore: - \begin{errlist} - \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non - è nullo. - \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della - lunghezza del pathname. - \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei - componenti del pathname (cioè su una delle directory superiori alla - corrente). - \end{errlist} -\end{prototype} - -Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)} -fatta per compatibilità all'indietro con BSD, che non consente di specificare -la dimensione del buffer; esso deve essere allocato in precedenza ed avere una -dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi -\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione -superiore per un pathname, per cui non è detto che il buffer sia sufficiente a -contenere il nome del file, e questa è la ragione principale per cui questa -funzione è deprecata. - -Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)} -che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola -differenza che essa ritorna il valore della variabile di ambiente -\texttt{PWD}, che essendo costruita dalla shell può contenere anche dei -riferimenti simbolici. - -Come già detto in unix anche le directory sono file, è possibile pertanto -riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello, -e non solo tramite il filename; per questo motivo ci sono due diverse funzioni -per cambiare directory di lavoro. - -\begin{prototype}{unistd.h}{int chdir (const char * pathname)} - Come dice il nome (che significa \textit{change directory}) questa funzione - serve a cambiare la directory di lavoro a quella specificata dal pathname - contenuto nella stringa \texttt{pathname}. -\end{prototype} - -\begin{prototype}{unistd.h}{int fchdir (int filedes)} - Analoga alla precedente, ma usa un file descriptor invece del pathname. - - Entrambe le funzioni restituiscono zero in caso di successo e -1 per un - errore, in caso di errore \texttt{errno} viene settata secondo i codici di - errore standard di accesso ai files (trattati in dettaglio in - \secref{sec:filedir_access_control}) ai quali si aggiunge il codice - \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia - una directory. -\end{prototype} - - %La struttura fondamentale che contiene i dati essenziali relativi ai file è il diff --git a/fileintro.tex b/fileintro.tex index 85098c8..d1c8e13 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -1,6 +1,7 @@ + \chapter{I files: l'architettura} \label{cha:files_intro} - + Uno dei concetti fondamentali della architettura di unix è il cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi di input/output del computer viene effettuato attraverso un'interfaccia @@ -71,9 +72,11 @@ convenzione, sono inseriti nella directory \texttt{/dev}). L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei medesimi nell'albero descritto in precedenza; una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è solo un particolare tipo di file -che contiene le informazioni che associano un nome al contenuto. Per questo, -anche se è usuale parlare di ``file in una directory'' in realtà una directory -contiene solo delle etichette per fare riferimento ai file stessi. +che contiene le informazioni che associano un nome al contenuto. + +% Per questo, anche se è usuale parlare di ``file in una directory'' in realtà +% una directory contiene solo delle etichette per fare riferimento ai file +% stessi. I manuale delle glibc chiama i nomi contenuti nelle directory \textsl{componenti} (in inglese \textit{file name components}), noi li @@ -90,7 +93,7 @@ consecutive sono considerate equivalenti ad una sola). Il nome completo di un file viene usualmente chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo nome (poiché genererebbe confusione, dato che con \textit{path} si indica anche un insieme di directory su cui effettuare una -ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune +ricerca, come quello in cui si cercano i comandi); l'uso è ormai così comune che è senz'altro più chiaro dell'alternativa proposta. Il processo con cui si associa ad un pathname uno specifico file è chiamato @@ -117,10 +120,6 @@ la directory che contiene il riferimento alla directory corrente; nel caso questa sia la directory radice allora il riferimento è a se stessa. -% \subsection{Il controllo di accesso} -% \label{sec:fileintr_access_ctrl} - - \subsection{I tipi di files} \label{sec:fileintr_file_types} @@ -162,15 +161,15 @@ dati) in base al loro contenuto, o tipo di accesso. \end{center} \end{table} -Una delle differenze principali con altri sistemi operativi (come il VMS o -Windows) è che per Unix tutti i file di dati sono identici e contengono un -flusso continuo di bytes; non esiste cioè differenza per come vengono visti +Infatti una delle differenze principali con altri sistemi operativi (come il +VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono +un flusso continuo di bytes. Non esiste cioè differenza per come vengono visti dal sistema file di diverso contenuto o formato (come nel caso di quella fra file di testo e binari che c'è in Windows) né c'è una strutturazione a record -per il cosiddetto ``accesso diretto'' come nel caso del VMS. -% (con i kernel -% della serie 2.4 è disponibile una forma di accesso diretto ai dischi il -% \textit{raw access} che però non ha nulla a che fare con questo). +per il cosiddetto ``accesso diretto'' come nel caso del VMS\footnote{con i + kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi + (il \textit{raw access}) attraverso dei device file appositi, che però non + ha nulla a che fare con questo}. Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è codificata in maniera diversa da Windows o MacIntosh, in particolare il fine @@ -188,7 +187,7 @@ programmazione sono due, basate su due diversi meccanismi con cui accedere al loro contenuto. La prima è l'interfaccia standard di unix, quella che il manuale delle glibc -chiama interfaccia dei descrittore di file (o \textit{file descriptor}). È +chiama interfaccia dei descrittori di file (o \textit{file descriptor}). È un'interfaccia specifica di unix e provvede un accesso non bufferizzato. L'interfaccia è primitiva ed essenziale, l'accesso viene detto non @@ -202,11 +201,11 @@ nell'header \texttt{unistd.h}. La seconda interfaccia è quella che il manuale della glibc chiama degli \textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato (controllato dalla implementazione fatta dalle librerie del C). Questa è -l'interfaccia standard usata dal linguaggio C e perciò si trova anche su tutti -i sistemi non Unix. Gli stream sono oggetti complessi e sono rappresentati da -puntatori ad un opportuna struttura definita dalle librerie del C, si accede -ad essi sempre in maniera indiretta utilizzando il tipo \texttt{FILE *}. -L'interfaccia è definita nell'header \texttt{stdio.h}. +l'interfaccia standard specificata dall'ANSI C e perciò si trova anche su +tutti i sistemi non Unix. Gli stream sono oggetti complessi e sono +rappresentati da puntatori ad un opportuna struttura definita dalle librerie +del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo +\texttt{FILE *}. L'interfaccia è definita nell'header \texttt{stdio.h}. Entrambe le interfacce possono essere usate per l'accesso ai file come agli altri oggetti del VFS (pipes, socket, device), ma per poter accedere alle @@ -237,6 +236,7 @@ essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è pertanto di portabilità più limitata. + \subsection{Caratteristiche specifiche dei file in unix} \label{sec:fileint_unix_spec} @@ -332,7 +332,7 @@ di filesystem differenti all'interno dello stesso albero delle directory Quando un processo esegue una system call che opera su un file il kernel chiama sempre una funzione implementata nel VFS; la funzione eseguirà le -manipolazioni sulle strutture generiche e ridirigendo la chiamata alla +manipolazioni sulle strutture generiche e utilizzaerà poi la chiamata alla opportune routine del filesystem specifico a cui si fa riferimento. Saranno queste a chiamare le funzioni di più basso livello che eseguono le operazioni di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. @@ -345,19 +345,53 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \end{figure} Il VFS definisce un insieme di funzioni che tutti i filesystem devono -implementare, queste funzioni - +implementare. L'interfaccia comprende tutte le funzioni che riguardano i +files; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode +e file, corrispondenti a tre apposite strutture definite nel kernel. + +Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun +filesystem supportato, quando si vuole inserire il supporto di un nuovo +filesystem tutto quello che occorre è una chiamata alla funzione +\func{register\_filesystem} passando un'apposita struttura che +(\var{file\_system\_type}) contiene l'implementazione edl medesimo, che sarà +aggiunta alla citata tabella. + + +In questo modo quando viene effettuata la richiesta di montare un nuovo disco +(o qualunque altro \textit{block device} che può contenere un filesystem), il +VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare +nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco +il superblock (vedi \ref{sec:fileintro_ext2}), inizializzare tutte le +variabili interne e restituire uno speciale descrittore dei filesystem montati +al VFS; attraverso quest'ultimo diventa possible accedere alle routine +specifiche per l'uso di quel filesystem. + +Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad +una apposita struttura che contiene vari dati come le informazioni comuni ad +ogni filesystem, i dati privati relativi a quel filesystem specifico, e i +puntatori alle funzioni del kernel relative al filesystem. Il VFS può così +usare le funzioni contenute nel filesystem decriptor per accedere alle routine +specifiche di quel filesystem. + +Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti +su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni +relative al file in uso, insieme ai puntatori alle funzioni dello specifico +filesystem usate per l'accesso dal VFS; in particolare il descrittore +dell'inode contiene i puntatori alle funzioni che possono essere usate su +qualunque file (come \func{link}, \func{stat} e \func{open}), mentre il +descrittore di file contiene i puntatori alle funzioni che vengono usate sui +file già aperti. \subsection{Il funzionamento del VFS} \label{sec:fileintr_vfs_work} -La funzione più importante implementata dal VFS è la system call \texttt{open} -che permette di aprire un file. Dato un pathname viene eseguita una ricerca -dentro la \textit{directory entry cache} (in breve \textit{dcache}), -una tabella di hash che contiene tutte le \textit{directory entry} (in breve -\textit{dentry}) che permette di associare in maniera rapida ed efficiente il -pathname a una specifica dentry. +La funzione più fondamentale implementata dal VFS è la system call +\texttt{open} che permette di aprire un file. Dato un pathname viene eseguita +una ricerca dentro la \textit{directory entry cache} (in breve +\textit{dcache}), una tabella di hash che contiene tutte le \textit{directory + entry} (in breve \textit{dentry}) che permette di associare in maniera +rapida ed efficiente il pathname a una specifica dentry. Una singola dentry contiene in genere il puntatore ad un \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che identifica un singolo @@ -527,298 +561,70 @@ cui si era partiti avr adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}. -\subsection{Le funzioni \texttt{link} e \texttt{unlink}} -\label{sec:fileintr_link} - -Una delle caratteristiche usate quando si opera con i file è quella di poter -creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo -stesso file accedendovi da directory diverse. Questo è possibile anche in -ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link}, -ma data la struttura del sistema ci sono due metodi sostanzialmente diversi -per fare questa operazione. - -Come si è appena detto l'accesso al contenuto di un file su disco avviene -attraverso il suo inode, e il nome che si trova in una directory è solo una -etichetta associata ad un puntatore a detto inode. Questo significa che la -realizzazione di un link è immediata in quanto uno stesso file può avere tanti -nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo -stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una -particolare preferenza rispetto agli altri. - -Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si -suole chiamare questo tipo di associazione un collegamento diretto (o -\textit{hard link}). Il prototipo della funzione e le sue caratteristiche -principali, come risultano dalla man page, sono le seguenti: -\begin{prototype}{unistd.h} -{int link(const char * oldpath, const char * newpath)} - Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath} - dandogli nome \texttt{newpath}. - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore. La variabile \texttt{errno} viene settata secondo i seguenti - codici di errore: - \begin{errlist} - \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo - stesso filesystem. - \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e - \texttt{newpath} non supporta i link diretti o è una directory. - \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori - dello spazio di indirizzi del processo. - \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o - per attraversare le directories), vedi \secref{sec:filedir_access_control} - per i dettagli. - \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo. - \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath} - non esiste o è un link simbolico spezzato. - \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath} - non è una directory. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. - \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di - già. - \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il - numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi - \secref{sec:xxx_limits}). - \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione - di \texttt{oldpath} o \texttt{newpath}. - \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha - spazio per ulteriori voci. - \item \texttt{EIO} c'è stato un errore di input/output. - \end{errlist} -\end{prototype} - -La creazione di un nuovo collegamento diretto non copia il contenuto del file, -ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il -nuovo nome ai precedenti. Si noti che uno stesso file può essere così -richiamato in diverse directory. - -Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del -collegamento diretto è possibile solo se entrambi i pathname sono nello stesso -filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è -il caso ad esempio del filesystem \texttt{vfat} di windows). - -La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, -ma solo l'amministratore è in grado di creare un collegamento diretto ad -un'altra directory, questo lo si fa perché in questo caso è possibile creare -dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti -programmi non sono in grado di gestire e la cui rimozione diventa estremamente -complicata (in genere occorre far girare il programma \texttt{fsck} per -riparare il filesystem); data la sua pericolosità in Linux questa -caratteristica è stata disabilitata, e la funzione restituisce l'errore -\texttt{EPERM}. - -La rimozione di un file (o più precisamente della voce che lo referenzia) si -effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: - -\begin{prototype}{unistd.h}{int unlink(const char * pathname)} - Cancella il nome specificato dal pathname nella relativa directory e - decrementa il numero di riferimenti nel relativo inode. Nel caso di link - simbolico cancella il link simbolico; nel caso di socket, fifo o file di - dispositivo rimuove il nome, ma come per i file i processi che hanno aperto - uno di questi oggetti possono continuare ad utilizzarlo. - - La funzione restituisce zero in caso di successo e -1 per un errore, nel - qual caso il file non viene toccato. La variabile \texttt{errno} viene - settata secondo i seguenti codici di errore: - \begin{errlist} - \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o - per attraversare le directories), vedi \secref{sec:filedir_access_control} - per i dettagli. - \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory - (valore specifico ritornato da linux che non consente l'uso di - \texttt{unlink} con le directory, e non conforme allo standard POSIX, che - prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia - consnetita o il processo non abbia privilegi sufficienti). - \item \texttt{EFAULT} la stringa - passata come parametro è fuori dello spazio di indirizzi del processo. - \item \texttt{ENAMETOOLONG} il pathname troppo lungo. - \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link - simbolico spezzato. - \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory. - \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola - lettura. - \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del - pathname. - \item \texttt{EIO} errore di input/output. - \end{errlist} -\end{prototype} - -Per cancellare una voce in una directory è necessario avere il permesso di -scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e -il diritto di esecuzione sulla directory che la contiene (torneremo in -dettaglio sui permessi e gli attributi fra poco), se inoltre lo -\textit{sticky} bit è settato occorrerà anche essere proprietari del file o -proprietari della directory (o root, per cui nessuna delle restrizioni è -applicata). - -Una delle caratteristiche di queste funzioni è che la creazione/rimozione -della nome dalla directory e l'incremento/decremento del numero di riferimenti -nell'inode deve essere una operazione atomica (cioè non interrompibile da -altri) processi, per questo entrambe queste funzioni sono realizzate tramite -una singola system call. - -Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti -i riferimenti ad esso sono stati cancellati, solo quando il \textit{link - count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A -questo però si aggiunge una altra condizione, e cioè che non ci siano processi -che abbiano detto file aperto. Come accennato questa proprietà viene spesso -usata per essere sicuri di non lasciare file temporanei su disco in caso di -crash dei programmi; la tecnica è quella di aprire il file e chiamare -\texttt{unlink} subito dopo. - -\subsection{Le funzioni \texttt{remove} e \texttt{rename}} -\label{sec:fileintr_remove} - -Al contrario di quanto avviene con altri unix in Linux non è possibile usare -\texttt{unlink} sulle directory, per cancellare una directory si può usare la -funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la -funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C -per cancellare un file o una directory (e funziona anche per i sistemi che non -supportano i link diretti), che per i file è identica alla \texttt{unlink} e -per le directory è identica alla \texttt{rmdir}: - -\begin{prototype}{stdio.h}{int remove(const char *pathname)} - Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e - \texttt{rmdir} per le directory. - - La funzione restituisce zero in caso di successo e -1 per un errore, nel - qual caso il file non viene toccato. Per i codici di errori vedi quanto - riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}. -\end{prototype} - -Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il -vantaggio nell'uso di questa funzione al posto della chiamata successiva di -\texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in -questo modo non c'è la possibilità che un processo che cerchi di accedere al -nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante. - -\begin{prototype}{stdio.h} -{int rename(const char *oldpath, const char *newpath)} - Rinomina un file, spostandolo fra directory diverse quando richiesto. - - La funzione restituisce zero in caso di successo e -1 per un errore, nel - qual caso il file non viene toccato. La variabile \texttt{errno} viene - settata secondo i seguenti codici di errore: - \begin{errlist} - \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre - \texttt{oldpath} non è una directory. - \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo - stesso filesystem. - \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e - non vuota. - \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da - parte di qualche processo (come directory di lavoro o come root) o del - sistema (come mount point). - \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di - \texttt{oldpath} o più in generale si è cercato di creare una directory - come sottodirectory di se stessa. - \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link - consentiti o è una directory e la directory che contiene \texttt{newpath} - ha già il massimo numero di link. - \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory - o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una - directory. - \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello - spazio di indirizzi del processo. - \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in - cui si vuole creare il nuovo link o una delle directory del pathname non - consente la ricerca (permesso di esecuzione). - \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o - \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non - consentono rispettivamente la cancellazione e la creazione del file, o il - filesystem non supporta i link. - \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo. - \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link - simbolico spezzato. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura. - \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del - pathname. - \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la - nuova voce. - \end{errlist} -\end{prototype} - -\subsection{I link simbolici} -\label{sec:fileintr_symlink} - -Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può -funzionare soltanto per file che risiedono sullo stesso filesystem, dato che -in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di -tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una -directory. +\subsection{Il filesystem \texttt{ext2}} +\label{sec:fileintro_ext2} + +Il filesystem standard usato da Linux è il cosidetto \textit{second extended + filesystem}, identificato dalla sigla \texttt{ext2}. Esso supporta tutte le +caratteristiche di un filesystem standard unix, è in grado di gestire +filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a +4~Tb. + +Oltre alle caratteristiche standard ext2 fornisce alcune estensioni che non +sono presenti sugli altri filesystem unix. Caratteristiche particolari di ext2 +sono le seguenti'' + +\begin{itemize} +\item i \textit{file attributes} consentono di modificare il comportamento del + kernel quando agisce su gruppi di file. Possono essere settati su file e + directory e in quest'ultimo caso i nuovi file creati nella directory + ereditano i suoi attributi. +\item sono supportate entrambe le semantiche di BSD e SysV come opzioni di + montaggio. La semantica BSD comporta che i file in una directory sono creati + con lo stesso identificatore di gruppo della directory che li contiene. La + semantica SysV comporta che i file vengono creati con l'identificatore del + gruppo primario del processo, eccetto il caso in cui la directory ha il bit + di setgid settata (per una descrizione dettagliata del sigificato di questi + termini si veda \secref{sec:filedir_access_control}), nel qual caso file e + sottodirectory ereditano sia il group id che il setgid. +\item l'amministratore può scegliere la dimensione dei blocchi del filesystem + in fase di creazione, a seconda delle sue esigenze (blocchi più grandi + peremttono un accesso più veloce, ma sprecano più spazio disco). +\item il filesystem implementa link simbolici veloci, in cui il nome del file + non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando + letture multiple e spreco di spazio), non tutti i nomi però possono essere + gestiti così per limiti di spazio (il limite è 60 caratteri). +\item vengono supportati i file immutabili (che possono solo essere letti) per + la protezione di file di configurazione sensibili, o file + \textit{append-only} che possono essere aperti in scrittura solo per + aggiungere dati (caratteristica utilizzabile per la protezione dei file di + log). +\end{itemize} + +La struttura di ext2 è stata ispirata a quella del filesystem di BSD, un +filesystem è composto da un insieme di blocchi, la struttura generale è +riportata in \nfig; su ciascun gruppo di blocchi contiene una copia delle +informazioni essenziali del filesystem (superblock e descrittore del +filesystem) per una maggiore affidabilità e possibilità di recupero in caso di +corruzione del superblock principale. -Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di -link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono, -come avviene in altri sistemi operativi, dei file che contengono il -semplicemente il riferimento ad un altro file (o directory). In questo modo è -possibile effettuare link anche attraverso filesystem diversi e a directory, e -pure a file che non esistono ancora. - -Il sistema funziona in quanto i link simbolici sono contrassegnati come tali -al kernel (analogamente a quanto avviene per le directory) per cui la chiamata -ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la -lettura del contenuto del medesimo e l'applicazione della funzione al file -specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare -o rinominare i file operano direttamente sul link simbolico. Inoltre esistono -funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere -alle informazioni del link invece che a quelle del file a cui esso fa -riferimento. - -Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte -dichiarate nell'header file \texttt{unistd.h}. - -\begin{prototype}{unistd.h} -{int symlink(const char * oldname, const char * newname)} - Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli - nome \texttt{newname}. - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore. La variabile \texttt{errno} viene settata secondo i codici di - errore standard di accesso ai files (trattati in dettaglio in - \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: - \begin{errlist} - \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di - già. - \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. - \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il - link è piena e non c'è ulteriore spazio disponibile. - \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di - \texttt{oldname} o di \texttt{newname}. - \end{errlist} -\end{prototype} - -Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare -un'altra funzione quando si vuole leggere il contenuto di un link simbolico, -questa funzione è la: - -\begin{prototype}{unistd.h} -{int readlink(const char * path, char * buff, size\_t size)} - Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer - \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un - carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo - piccolo per contenerla. +\begin{figure}[htb] + \centering - La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o - -1 per un errore, in caso di errore. La variabile \texttt{errno} viene - settata secondo i codici di errore: - \begin{errlist} - \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di - già. - \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. - \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il - link è piena e non c'è ulteriore spazio disponibile. - \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di - \texttt{oldname} o di \texttt{newname}. - \end{errlist} -\end{prototype} + \caption{Organizzazione logica del \textit{second extented filesystem}.} + \label{fig:fileintr_ext2_struct} +\end{figure} + +L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle +performance dato che viene ridotta la distanza fra i dati e la tabella degli +inodes. + +Le directory sono implementate come una linked list di entrate di dimensione +variabile. Ciascuna entry contiene il numero di inode, la sua lunghezza, il +nome del file e la sua lunghezza. + + + + diff --git a/gapil.tex b/gapil.tex index a8b017b..2564ee7 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Feb. 2001 -- 2.30.2 From 618bcb85e9e50d96cb4c97b7d61ab2bf4ac89c11 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 9 Jul 2001 20:23:55 +0000 Subject: [PATCH 09/16] Iniziato a sistemare il secondo capitolo sui file --- filedir.tex | 43 ++++++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/filedir.tex b/filedir.tex index 361e05a..1183d06 100644 --- a/filedir.tex +++ b/filedir.tex @@ -475,10 +475,10 @@ i seguenti: \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono - lette le informazioni relativa ad esso e non al file a cui punta. + lette le informazioni relativa ad esso e non al file a cui fa riferimento. \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat} - eccetto che funziona con un file aperto, specificato tramite il suo file + eccetto che si usa con un file aperto, specificato tramite il suo file descriptor \var{filedes}. Le funzioni restituiscono zero in caso di successo e -1 per un errore, in @@ -567,8 +567,9 @@ simbolici e socket definite da BDS, l'elenco \end{table} Oltre a queste macro è possibile usare direttamente il valore di -\var{st\_mode} per ricavare il significato dei vari bit del campo attraverso -l'uso dei flag riportati in \ntab: +\var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati, +per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in +\ntab: \begin{table}[htb] \centering \footnotesize @@ -608,10 +609,37 @@ l'uso dei flag riportati in \ntab: \label{tab:filedir_file_mode_flags} \end{table} +Il primo valore definisce la maschera dei bit usati nei quali viene +memorizzato il tipo di files, mentre gli altri possono essere usati per +effettuare delle selezioni sul tipo di file voluto. + \subsection{La dimensione dei file} \label{sec:filedir_file_size} -Il membro \var{st\_size} contiene la dimensione del +Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file +è un file normale, nel caso di un link simbolico al dimensione è quella del +pathname che contiene, per le directory è in genere un multiplo di 512). + +Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512 +bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per +i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C +per l'interfaccia deglli stream); scrivere in blocchi di dimensione inferiore +sarebbe inefficiente. + +Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto +che corrisponda all'occupazione dello spazio su disco per via della possibile +esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che +si formano tutte le volte che si va a scrivere su un file dopo aver eseguito +una \func{seek} (vedi \secref{sec:fileunix_lseek}) oltre la sua conclusione +corrente. + +In tal caso si avranno differenti risultati a seconda del modi in cui si +calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il +numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si +legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le +parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato +di \cmd{ls}. + \subsection{I tempi dei file} \label{sec:filedir_file_times} @@ -672,6 +700,11 @@ pertanto accesso senza restrizione a qualunque file del sistema. \subsection{I flag \texttt{suid} e \texttt{sgid}} \label{sec:filedir_suid_sgid} + + + + + \subsection{La titolarità di nuovi files e directory} \label{sec:filedir_ownership} -- 2.30.2 From f385263eb52ef0963c1a2f422d194167de83dc3f Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 9 Jul 2001 20:28:42 +0000 Subject: [PATCH 10/16] Aggiunte spiegazioni su sigpipe & c. --- signal.tex | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/signal.tex b/signal.tex index d8468d8..d3d05b8 100644 --- a/signal.tex +++ b/signal.tex @@ -586,10 +586,16 @@ resto del sistema. L'azione di default di questi segnali è di terminare il processo, questi segnali sono: \begin{description} -\item \texttt{SIGPIPE} -\item \texttt{SIGLOST} -\item \texttt{SIGXCPU} -\item \texttt{SIGXFSZ} +\item \texttt{SIGPIPE} Sta per \textit{Broken pipe}. Se si usano delle pipes o + delle FIFO è necessario che, prima che un processo inizi a scrivere su di + essa, un'altro abbia aperto la pipe in lettura (si veda + \secref{sec:ipc_pipes}). Se il processo in lettura non è partito o è + terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo + segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che + lo ha causato fallisce restituendo l'errore \macro{EPIPE} +\item \texttt{SIGLOST} Sta per \textit{Resource lost}. +\item \texttt{SIGXCPU} Sta per \textit{CPU time limit exceeded}. +\item \texttt{SIGXFSZ} Sta per \textit{File size limit exceeded}. \end{description} -- 2.30.2 From ac1d90df40f4ef778400d519610a1ed242db00a8 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 10 Jul 2001 20:50:15 +0000 Subject: [PATCH 11/16] Avanti coi tempi e le dimensioni dei file. --- filedir.tex | 74 ++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 62 insertions(+), 12 deletions(-) diff --git a/filedir.tex b/filedir.tex index 1183d06..4c2f8d1 100644 --- a/filedir.tex +++ b/filedir.tex @@ -310,9 +310,6 @@ questa funzione \end{errlist} \end{prototype} -\section{La manipolazione delle directories} -\label{sec:filedir_dir_handling} - \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} \label{sec:filedir_dir_creat_rem} @@ -435,7 +432,7 @@ per cambiare directory di lavoro. \begin{prototype}{unistd.h}{int fchdir (int filedes)} Analoga alla precedente, ma usa un file descriptor invece del pathname. - + Entrambe le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \texttt{errno} viene settata secondo i codici di errore standard di accesso ai files (trattati in dettaglio in @@ -461,7 +458,7 @@ manipolazione sar \label{sec:filedir_stat} La lettura delle informazioni relative ai file è fatta attraverso la famiglia -delle funzioni \texttt{stat}, che è la funzione che il comando \texttt{ls} usa +delle funzioni \func{stat}, che è la funzione che il comando \cmd{ls} usa per poter stampare tutti i dati dei files. I prototipi di queste funzioni sono i seguenti: \begin{functions} @@ -484,22 +481,22 @@ i seguenti: Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \texttt{errno} viene settato ai valori: \begin{errlist} - \item \texttt{EACCESS} Non c'è il permesso di accedere al file. - \item \texttt{ENOTDIR} Una componente del pathname non è una directory. - \item \texttt{EMLOOP} Ci sono troppi link simbolici nel pathname. - \item \texttt{EFAULT} I puntatori usati sono fuori dallo spazio di indirizzi + \item \texttt{EACCESS} non c'è il permesso di accedere al file. + \item \texttt{ENOTDIR} una componente del pathname non è una directory. + \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname. + \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi del processo. \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a completare l'operazione. - \item \texttt{ENAMETOOLONG} Il filename è troppo lungo. + \item \texttt{ENAMETOOLONG} il filename è troppo lungo. \end{errlist} \end{functions} La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in generale dipende dall'implementazione, la versione usata da Linux è mostrata in \nfig, così come riportata dalla man page (in realtà la definizione -effettivamente usata nel kernel dipende dall'archietettura e ha altri campi -riservati per estensioni come tempo più precisi, o per il padding dei campi). +effettivamente usata nel kernel dipende dall'architettura e ha altri campi +riservati per estensioni come tempi più precisi, o per il padding dei campi). \begin{figure}[!htb] \footnotesize @@ -641,9 +638,62 @@ parti non scritte vengono restituiti degli zeri, si avr di \cmd{ls}. +Se è sempre possibile allargare un file scrivendoci sopra od usando la +funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi +in cui si può avere bisogno di effettuare un troncamento scartando i dati al +di là della dimensione scelta come nuova fine del file. + +Un file può essere troncato a zero aprendolo con il flag \macro{O\_TRUNC}, ma +questo è un caso particolare; per qualunque altra dimensione si possono usare +le due funzioni: +\begin{functions} + \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off_t + length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad + un valore massimo specificato da \var{lenght}. + + \funcdecl{int ftruncate(int fd, off_t length))} Identica a \func{truncate} + eccetto che si usa con un file aperto, specificato tramite il suo file + descriptor \var{fd}, + + Le funzioni restituiscono zero in caso di successo e -1 per un errore, in + caso di errore \texttt{errno} viene settato ai valori: + \begin{errlist} + \item \texttt{EACCESS} non c'è il permesso di accedere al file. + \item \texttt{ENOTDIR} una componente del pathname non è una directory. + \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname. + \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi + del processo. + \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a + completare l'operazione. + \item \texttt{ENOENT} il file non esiste. + \item \texttt{ENAMETOOLONG} il filename è troppo lungo. + \end{errlist} +\end{functions} + +Se il file è più lungo della lunghezza specificata i dati in eccesso saranno +perduti; il comportamento in caso di lunghezza inferiore non è specificato e +dipende dall'implementazione, il file può essere lasciato invariato o esteso +fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con +zeri (e in genere si ha la creazione di un hole nel file). + \subsection{I tempi dei file} \label{sec:filedir_file_times} +Il sistema mantiene tre tempi per ciascun file, corrispondenti a tre campi +della struttura \func{stat}, come riassunto in \ntab: + +\begin{table}[htb] + \centering + \begin{tabular}[c]{|c|l|l|c|} + \var{st\_atime} & & & \\ + \var{st\_mtime} & & & \\ + \var{st\_ctime} & & & \\ + \end{tabular} + \caption{I tre tempi associati a ciascun file} + \label{tab:filedir_file_times} +\end{table} + + \subsection{La funzione \texttt{utime}} \label{sec:filedir_utime} -- 2.30.2 From 34ed932cc43ebd3df23ce3255984bba0301b7231 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 17 Jul 2001 17:49:26 +0000 Subject: [PATCH 12/16] La febbre rompe le scatole, ma almeno uno sa come "perdere tempo" --- filedir.tex | 157 ++++++++++++++++++++++++++++++++++++++-------- fileintro.tex | 2 +- gapil.tex | 3 +- img/link_loop.dia | Bin 0 -> 1655 bytes img/vfs.dia | Bin 0 -> 2798 bytes intro.tex | 67 ++++++++++++++++++-- 6 files changed, 195 insertions(+), 34 deletions(-) create mode 100644 img/link_loop.dia create mode 100644 img/vfs.dia diff --git a/filedir.tex b/filedir.tex index 4c2f8d1..0d6dbdb 100644 --- a/filedir.tex +++ b/filedir.tex @@ -13,7 +13,7 @@ dei file Le prime funzioni che considereremo sono quelle relative alla gestione di file e directory, secondo le caratteristiche standard che essi presentano in un -filesystem unix, già esaminate in precedenza (vedi +filesystem unix, la cui struttura abbiamo esaminato in precedenza (vedi \secref{sec:fileintr_filesystem}). \subsection{Le funzioni \texttt{link} e \texttt{unlink}} @@ -89,14 +89,14 @@ filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non il caso ad esempio del filesystem \texttt{vfat} di windows). La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, -ma solo l'amministratore è in grado di creare un collegamento diretto ad -un'altra directory, questo lo si fa perché in questo caso è possibile creare -dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti -programmi non sono in grado di gestire e la cui rimozione diventa estremamente -complicata (in genere occorre far girare il programma \texttt{fsck} per -riparare il filesystem); data la sua pericolosità in Linux questa -caratteristica è stata disabilitata, e la funzione restituisce l'errore -\texttt{EPERM}. +in alcuni filesystem solo l'amministratore è in grado di creare un +collegamento diretto ad un'altra directory, questo lo si fa perché in questo +caso è possibile creare dei circoli nel filesystem (vedi +\secref{sec:fileintr_symlink}) che molti programmi non sono in grado di +gestire e la cui rimozione diventa estremamente complicata (in genere occorre +far girare il programma \texttt{fsck} per riparare il filesystem); data la sua +pericolosità in generale nei filesystem usati in Linux questa caratteristica è +stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}. La rimozione di un file (o più precisamente della voce che lo referenzia) si effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: @@ -255,10 +255,10 @@ al kernel (analogamente a quanto avviene per le directory) per cui la chiamata ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la lettura del contenuto del medesimo e l'applicazione della funzione al file specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare -o rinominare i file operano direttamente sul link simbolico. Inoltre esistono -funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere -alle informazioni del link invece che a quelle del file a cui esso fa -riferimento. +o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi +\ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la +\texttt{lstat} per accedere alle informazioni del link invece che a quelle del +file a cui esso fa riferimento. Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte dichiarate nell'header file \texttt{unistd.h}. @@ -310,6 +310,87 @@ questa funzione \end{errlist} \end{prototype} +In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che +operano sui file rispetto ai link simbolici; specificando quali seguono il +link simbolico e quali possono operare direttamente sul suo contenuto. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|c|} + \hline + Funzione & Segue il link & Non segue il link \\ + \hline + \hline + \func{access} & $\bullet$ & \\ + \func{chdir} & $\bullet$ & \\ + \func{chmod} & $\bullet$ & \\ + \func{chown} & & $\bullet$ \\ + \func{creat} & $\bullet$ & \\ + \func{exec} & $\bullet$ & \\ + \func{lchown} & $\bullet$ & $\bullet$ \\ + \func{link} & & \\ + \func{lstat} & & $\bullet$ \\ + \func{mkdir} & $\bullet$ & \\ + \func{mkfifo} & $\bullet$ & \\ + \func{mknod} & $\bullet$ & \\ + \func{open} & $\bullet$ & \\ + \func{opendir} & $\bullet$ & \\ + \func{pathconf} & $\bullet$ & \\ + \func{readlink} & & $\bullet$ \\ + \func{remove} & & $\bullet$ \\ + \func{rename} & & $\bullet$ \\ + \func{stat} & $\bullet$ & \\ + \func{truncate} & $\bullet$ & \\ + \func{unlink} & & $\bullet$ \\ + \hline + \end{tabular} + \caption{Uso dei link simbolici da parte di alcune funzioni.} + \label{tab:filedir_symb_effect} +\end{table} +si noti che non si è specificato il comportamento delle funzioni che operano +con i file descriptor, in quanto la gestione del link simbolico viene in +genere effttuata dalla funzione che restituisce il file descriptor +(normalmente la \func{open}). + +\begin{figure}[htb] + \centering + \includegraphics[width=5cm]{img/link_loop.eps} + \caption{Esempio di loop nel filesystem creato con un link simbolico.} + \label{fig:filedir_link_loop} +\end{figure} + +Un caso comune che si può avere con i link simbolici è la creazione dei +cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta +la struttura della directory \file{/boot}. Come si vede si è creato al suo +interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo + tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un + bootloader estremamente avanzato in grado di accedere direttamente + attraverso vari filesystem al file da lanciare come sistema operativo) di + vedere i file in questa directory, che è montata su una partizione separata + (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero + visti dal sistema operativo.}. + +Questo può causare problemi per tutti quei programmi che effettuassero uno +scan di una directory senza tener conto dei link simbolici, in quel caso +infatti il loop nella directory + +Un secondo punto da tenere presente è che un link simbolico può essere fatto +anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo +nella nostra directory con un link del tipo: +\begin{verbatim} +$ln -s /tmp/tmp_file temporaneo +\end{verbatim}%$ +ma anche se \file{/tmp/tmp_file} non esiste. Aprendo in scrittura +\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola +lettura (ad esempio con \cmd{cat}) otterremmo: +\begin{verbatim} +$ cat prova +cat: prova: No such file or directory +\end{verbatim}%$ +con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza +di \file{temporaneo}. + + \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} \label{sec:filedir_dir_creat_rem} @@ -608,20 +689,27 @@ per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in Il primo valore definisce la maschera dei bit usati nei quali viene memorizzato il tipo di files, mentre gli altri possono essere usati per -effettuare delle selezioni sul tipo di file voluto. +effettuare delle selezioni sul tipo di file voluto, combinando opportunamente +i vari flag; ad esempio se si volesse controllare se un file è una directory o +un file ordinario si potrebbe definire la condizione: +\begin{lstlisting} +#define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) ) +\end{lstlisting} +in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e +poi si effettua il confronto con la combinazione di tipi scelta. \subsection{La dimensione dei file} \label{sec:filedir_file_size} Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file è un file normale, nel caso di un link simbolico al dimensione è quella del -pathname che contiene, per le directory è in genere un multiplo di 512). +pathname che contiene). Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512 bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C -per l'interfaccia deglli stream); scrivere in blocchi di dimensione inferiore -sarebbe inefficiente. +per l'interfaccia degli stream); scrivere sul file a blocchi di dati di +dimensione inferiore sarebbe inefficiente. Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto che corrisponda all'occupazione dello spazio su disco per via della possibile @@ -637,7 +725,6 @@ legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato di \cmd{ls}. - Se è sempre possibile allargare un file scrivendoci sopra od usando la funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi in cui si può avere bisogno di effettuare un troncamento scartando i dati al @@ -647,11 +734,11 @@ Un file pu questo è un caso particolare; per qualunque altra dimensione si possono usare le due funzioni: \begin{functions} - \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off_t + \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad un valore massimo specificato da \var{lenght}. - \funcdecl{int ftruncate(int fd, off_t length))} Identica a \func{truncate} + \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate} eccetto che si usa con un file aperto, specificato tramite il suo file descriptor \var{fd}, @@ -672,28 +759,46 @@ le due funzioni: Se il file è più lungo della lunghezza specificata i dati in eccesso saranno perduti; il comportamento in caso di lunghezza inferiore non è specificato e -dipende dall'implementazione, il file può essere lasciato invariato o esteso +dipende dall'implementazione: il file può essere lasciato invariato o esteso fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con zeri (e in genere si ha la creazione di un hole nel file). \subsection{I tempi dei file} \label{sec:filedir_file_times} -Il sistema mantiene tre tempi per ciascun file, corrispondenti a tre campi -della struttura \func{stat}, come riassunto in \ntab: +Il sistema mantiene per ciascun file tre tempi. Questi sono registrati +nell'inode insieme agli altri attibuti del file e possono essere letti tramite +la funzione \func{stat}, che li restituisce attraverso tre campi della +struttura in \figref{fig:filedir_stat_struct} il cui signifato è riportato +nello schema in \ntab: \begin{table}[htb] \centering \begin{tabular}[c]{|c|l|l|c|} - \var{st\_atime} & & & \\ - \var{st\_mtime} & & & \\ - \var{st\_ctime} & & & \\ + \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ + \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ + \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, + \func{utime} & \cmd{-c} \\ \end{tabular} \caption{I tre tempi associati a ciascun file} \label{tab:filedir_file_times} \end{table} +La differenza principale di cui tenere presente è quella fra tempo di modifica +\var{st\_mtime} e tempo di cambiamento di stato \var{st\_ctime}. Il primo +infatti fa riferimento ad una modifica del contenuto di un file, mentre il +secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la +funzione \func{link} e molte altre che vedremo in seguito) che modificano solo +le informazioni contenute nell'inode senza toccare il file, dato che queste +ultime sono separate dal contenuto del file diventa necessario l'utilizzo di +un altro tempo. Si noti inoltre come \var{st\_ctime} non abbia nulla a che +fare con il tempo di creazione usato da molti altri sistemi operativi, che in +unix non esiste. + + + + \subsection{La funzione \texttt{utime}} \label{sec:filedir_utime} diff --git a/fileintro.tex b/fileintro.tex index d1c8e13..d0ca221 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -339,7 +339,7 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \begin{figure}[htb] \centering - + \includegraphics[width=5cm]{img/vfs.eps} \caption{Schema delle operazioni del VFS} \label{fig:fileintro_VFS_scheme} \end{figure} diff --git a/gapil.tex b/gapil.tex index 2564ee7..5e1fc77 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Feb. 2001 @@ -62,7 +62,6 @@ \end{quote} \clearemptydoublepage - \tableofcontents \clearemptydoublepage diff --git a/img/link_loop.dia b/img/link_loop.dia new file mode 100644 index 0000000000000000000000000000000000000000..179491c9d3d4829f46b569be9b9fcb0b45e27bb4 GIT binary patch literal 1655 zcmV--28j6|iwFP!000001MOT}bE7sCe$TJ)u&=Bv35m;Qlbvp-Z=Gppw(lMsD>f|# z56DTJhyM18OV$Pin2WM@7iZ!bgM2=Y^l`p(#7RDXdD;52Cl5%9e|h}ryK*Z1AI7&O=JZ)USo11p!i z$+7&X%X#E2_ngfFcgyayrTg&DItur}O3Oy&;~qjkjAl=+f2VzTOkdhOH#0BTX|TO> zcPuKK-R{EJ6GQl6R~b@cCwV^^laGqUpkRIf;TQ5DyQKWU(U$B&YeD$djn-aJ#fg~f zXA^;ejWK?khwczd^$@;#h)6wz7cX{U#3R?^RhVTM`pgY7Bp&Tqf1LQi^#x^`TtWS< zKYE;pE!Y3(`tdmqWQV`sJzej_b>yv@Z^Xig8Y|DK0~Tkg?3b`9Vo+t8cH#Hs zv;d?KQXK<`9m6coKy_*BV3x}=N+jHIgSF2xBojCkQ>sHiOo!Ye1Wd!AIsph`==1|# zve!lGOfMI!LmeGAokkEqi|R;tVk6Q#QYZafdI+O{MT>+66{lFR-)8n<1zdWr3$V}- zwut$`XZ5hSpXrqwZ+sT4`KHQ|x2On#(a(6y-H0#TC<>oPzwi^=i*^U>;UKAejDYbF z27$Q!M68HQ#*SxZ8xdoYNF;&@4@EF>wAu0OomM5dUHO?*gbr2_sEe?!QbjC4ED=e}TthIRm?W6jAt6s&Q5ElB zKLRkxNKY9lGi;KPQ6fS^Ic$y)6&!^j!AYwTp&?1_D{>4`oD!AgZ_yn&MN#8`q^1Fm zMHSY*<@&W#@rxDLz71rvu59nc#u*Z_v%ME&Dd%6O?H6P<@4pBoRZGMnn=s_Z@zB05 z9@-Yl_5h)i@sM899w2Sz;HA>9ya(Nzf624DUBQ>yhjZbJgp5wxbIB?lC90FJ7?P}5 zr>D9VQr7JEfFyrPp3ga!z!S7YFlUT42wz_DDRfv`0#=gWp#YKuyWBuBpr>OKJ})F) zO@sPJs%-C9b|N?izsdK+Gt1IGXwuTOy*TXyRV`3E5wRbrtXw^_VC@4}SG2a3tz5-lW^5Mz&j;WO!yF!&4=qgFKsrvs;_0tYfCB^`t9+v~Q-l zb4I=R<1uc)bPtFEto$ytfo(&glXU+XCtYVysJ?(sHlXn&`ai4a%Lq8B{l%%hF^<|> z@1yqSQSF^~QhRGs`-?4;$w*2mUP+T6rthGZqDD5TZUGa$$)zde(gp-wnOv@;{c@7a z5#>_K!bvj6mdx&bLx_&ifNCgjKuzD%4pgeT1J#&%hg#Li9HRx5sBJ-|09n`;>zTI? znZU*tPGGO2e+W#CLqqyc$<#RXo{dAux~k40auJ%7Wpw z^`GWQ7-fBbf-o1=e~MvC|EY7q{ih)F0020b BLpuNf literal 0 HcmV?d00001 diff --git a/img/vfs.dia b/img/vfs.dia new file mode 100644 index 0000000000000000000000000000000000000000..14c1f1bdf1fa0428366b7521f4d8f68a38f221a3 GIT binary patch literal 2798 zcmVR2R1O3J93k{$9EOXyF)t!AFCsNBBFwJ$Nt&mAm^a1TBuNzbaVaTJ z?}PDjvb7&clR2ge9N+tGnCHof`@i+0td9ca*U#t~io|UiZjJ--phZV7kKrc2yZ&xy zxXRw24E6pHX5mc~wB3Ce=aY5+q}jdhbG{EZL3ZLvAGYb}>8@&aaZ2%eyS^HfU)4ye z5E1!LL0WbH`GuYq)fiWxe>Dop&3}V+Ua9vr_v4M9ZWf;wpOf#)7jku%i*R$f{Fi$; zJavU+XVUpJ#%G^AKS$T0b#czgWjsji5V z!_!lOvLtD+5?EQSvzOm2?j#gds40<`ClYyhxp?{Q<N!2)A%8P4)lP=bf@75+C2d*u;|JEr4uM&sUftTYfY%v%DN4U!$4??XpnDn#tQ`1 zSl{SmNsYCXre&Y7aK?}lP2}Zx>A4!5 zhV1&Bz0s=cffq}lwU)K@(!1NNW5M+3-FGi@C2`&^QT?WB^d-4ZLy6l9U1=?lITetN z6;-#r-u5?6T(RQbF7WkYyj%R!7w1ReHr@qY&+a8QfCFT;F8&PiCFM7-XmU)POm*XA z287^H!dv=y&dtWkRL01KAcEjZ#;pX4!p+FRdPa@g8@Eizo!=9r{ z&6bw9S_QDq!#a=t&V%SU5B4_BgKIkvqsQI{~ zQ_q&B+|E0!^BCwnsE+dxZ{s|K_N2x5&YqmCNEs^*)b`nEQT=Bpr}y!=-N&<@VSs0- zPb<8czzwyt&fqM2_mY^Y>q3R{Vm={5{5g;g`|a98Y~gO;LM-shxRpkHGAc$NAj#zShd?nDj|!@_*}`e9n$6xrn+33-rA!DXtv0s+K{ z$>@~;>=kQJ9(D0b<>c`~ERmPv#MUzG`eotu&%ry$!228}>u-xq@DQ$p#m)WgZICY3 z{`xNH%*#8La@8{@uUAIiP&uvHc&Bplh6-us;q|qQ)Q-eo0e`oEnS;1*(Bv$^VM^`D(Hf9R&?2tuJ^&4d=h(}uc%8J z77^5YCQnF!=MwTB*)t8oEJ!VXPQ{S;% z`Ev&TMD8TET!j8;4nuyKdP2pXujZcceX-}mt)E-&oQykLEYLEidFDL$W)zzuczT1Q z%?GvA79Z^Ck69pZ@j{&|V3OZpv2#g)t8yKxPrV!HB3Kj3cJONh!%|m1iC%rSZr}vM zjuCDj%00Q|aY(x(57t7HnSEzTy+Hs-q2z~9%!@+=ic19o?d`CRWS^nRn;oip9#AtE zhzt|ZnwO$k^WHN*1sy3~>C91?7!P08vRr1Qu2G#kD%>QTHweLE@Cn_aCe491bY+ zydtfMK}w`xtgg?$nBePEmIu4V7e9&?f5dr^-ui1>NT63p(6BmNNMQ7}7GjbjTBI^| z#@4I#E1Gu;Aub~;^*#$aQweQDv95OZkStq7+rMNUYZTF9_f3juvGy@K<5AMHFi{oJ zk|N+O(ykCQ9Po};s8_@bZN%Fv;>B>P;#m(MiiFWq+z`WD(U%7~Rm+}?c}NK+^7{NE z-rvi@+27Of;Yh->jdXjJ%+{^VM!E)HkBE`}`w?e&J!1LspI@gMYZnRQ*Dg9*F=wBBHzz?@qQA^#}O?GEWk&g!%{yKrQZznK2vq1gE0q4+g}nWnJu3iaYJ zWI3!Khw%yCwMmpm!3dbm^FdG%7=~3|D*_&u1SZ8E=Cz*fwnvzKTYQnMk|t4PH$KJ^ zSi8Ad_L}viP(00{Ey$VWh$ywC|D(8^I^H~owrJ_r@3a zWSX;DYAeEKOjx>ACa^=R@C+iCIUKmmWf~{y?d8y1x0E-XQn954J=p>~{OnE1%=uOX zPI9QSb2wKsVrR7QlvHL9ZZbhhp#LzBmXH#uRfF)@@Jd+yQ>fX2b!>GcqE?y04;iz AkN^Mx literal 0 HcmV?d00001 diff --git a/intro.tex b/intro.tex index 6fc0fec..cc6dcfa 100644 --- a/intro.tex +++ b/intro.tex @@ -229,18 +229,75 @@ descritti in precedenza sono disattivati. \section{Gli standard di unix e GNU/Linux} \label{sec:intro_standard} - +In questa sezione prenderemo in esame alcune caratteristiche generali del +sistema e gli standard adottati per le funzioni, i prototipi, gli errori, i +tipi di dati. + +\subsection{Prototipi e puntatori} +\label{sec:intro_function} + +\subsection{La misura del tempo in unix} +\label{sec:intro_unix_time} + +Storicamente i sistemi unix-like hanno sempre mantenuto due distinti valori +per i tempi all'interno del sistema, chiamati rispettivamente \textit{calendar + time} e \textit{process time}, secondo le definizioni: +\begin{itemize} +\item \textit{calendar time}: è il numero di secondi dalla mezzanotte del + primo gennaio 1970, in tempo universale coordinato (o UTC, data che viene + usualmente indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata \textit{the + Epoch}). Viene chiamato anche GMT (Greenwich Mean Time) dato che l'UTC + corrisponde all'ora locale di Greenwich. E' il tempo su cui viene mantenuto + l'orologio del calcolatore, e viene usato ad esempio per indicare le date di + modifica dei file o quelle di avvio dei processi. Per memorizzare questo + tempo è stato riservato il tipo primitivo \func{time\_t}. +\item \textit{process time}: talvolta anche detto tempo di CPU. Viene misurato + in \textit{clock tick}, corripondenti al numero di interruzioni effettuate + dal timer di sistema, e che per Linux sono ogni centesimo di secondo + (eccetto per la piattaforma alpha). Il dato primitivo usato per questo tempo + è \func{clock\_t}, inoltre la costante \macro{HZ} restituisce la frequenza + di operazione del timer, e corrisponde dunque al numero di tick al secondo + (Posix definisce allo stesso modo la costante \macro{CLK_TCK}); questo + valore può comunque essere ottenuto con \func{sysconf} (vedi + \secref{sec:intro_limits}). +\end{itemize} + +In genere si usa il \textit{calendar time} per tenere le date dei file e le +informazioni analoghe che riguardano i tempi di ``orologio'' (usati ad esempio +per i demoni che compiono lavori amministrativi ad ore definite, come +\cmd{cron}). Di solito questo vene convertito automaticamente dal valore in +UTC al tempo locale, utilizzando le opportune informazioni di localizzazione +(specificate in \file{/etc/timezone}). E da tenere presente che questo tempo è +mantenuto dal sistema e non corrisponde all'orologio hardware del calcolatore. + +Il \textit{process time} di solito si esprime in secondi e viene usato appunto +per tenere conto dei tempi di esecuzione dei processi. Per ciascun processo il +kernel tiene tre di questi tempi: +\begin{itemize} +\item \textit{clock time} +\item \textit{user time} +\item \textit{system time} +\end{itemize} +il primo è il tempo ``reale'' (viene anche chiamato \textit{wall clock time}) +dall'avvio del processo, e misura il tempo trascorso fino alla sua +conclusione; chiaramente un tale tempo dipede anche dal carico del sistema e +da quanti altri processi stavano girando nello stesso periodo. Il secondo +tempo è quello che la CPU ha speso nell'esecuzione delle istruzioni del +processo in user space. Il terzo è il tempo impiegato dal kernel per eseguire +delle system call per conto del processo medesimo (tipo quello usato per +eseguire una \func{write} su un file). In genere la somma di user e system +time viene chiamato \textit{CPU time}. \subsection{Lo standard ANSI C} \label{sec:intro_ansiC} - - \subsection{Lo standard POSIX} \label{sec:intro_posix} +\subsection{Valori e limiti del sistema} +\label{sec:intro_limits} - - +\subsection{Tipi di dati primitivi} +\label{sec:intro_data_types} -- 2.30.2 From 40b7e9c1b5e028582e15046f1b1982d3c8a22eeb Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Wed, 18 Jul 2001 12:44:46 +0000 Subject: [PATCH 13/16] Si prosegue con i file, tempi e altro. --- filedir.tex | 150 +++++++++++++++++++++++++++++++++++++++++++++++----- gapil.tex | 6 +-- intro.tex | 2 +- 3 files changed, 140 insertions(+), 18 deletions(-) diff --git a/filedir.tex b/filedir.tex index 0d6dbdb..592440e 100644 --- a/filedir.tex +++ b/filedir.tex @@ -380,7 +380,7 @@ nella nostra directory con un link del tipo: \begin{verbatim} $ln -s /tmp/tmp_file temporaneo \end{verbatim}%$ -ma anche se \file{/tmp/tmp_file} non esiste. Aprendo in scrittura +ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura \file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola lettura (ad esempio con \cmd{cat}) otterremmo: \begin{verbatim} @@ -692,7 +692,7 @@ memorizzato il tipo di files, mentre gli altri possono essere usati per effettuare delle selezioni sul tipo di file voluto, combinando opportunamente i vari flag; ad esempio se si volesse controllare se un file è una directory o un file ordinario si potrebbe definire la condizione: -\begin{lstlisting} +\begin{lstlisting}{} #define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) ) \end{lstlisting} in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e @@ -769,8 +769,8 @@ zeri (e in genere si ha la creazione di un hole nel file). Il sistema mantiene per ciascun file tre tempi. Questi sono registrati nell'inode insieme agli altri attibuti del file e possono essere letti tramite la funzione \func{stat}, che li restituisce attraverso tre campi della -struttura in \figref{fig:filedir_stat_struct} il cui signifato è riportato -nello schema in \ntab: +struttura in \figref{fig:filedir_stat_struct}. Il significato di detti tempi e +dei relativi campi è riportato nello schema in \ntab: \begin{table}[htb] \centering @@ -784,31 +784,155 @@ nello schema in \ntab: \label{tab:filedir_file_times} \end{table} - -La differenza principale di cui tenere presente è quella fra tempo di modifica -\var{st\_mtime} e tempo di cambiamento di stato \var{st\_ctime}. Il primo +Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di +modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di +cambiamento di stato (il \textit{chage time} \var{st\_ctime}). Il primo infatti fa riferimento ad una modifica del contenuto di un file, mentre il secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la funzione \func{link} e molte altre che vedremo in seguito) che modificano solo -le informazioni contenute nell'inode senza toccare il file, dato che queste -ultime sono separate dal contenuto del file diventa necessario l'utilizzo di -un altro tempo. Si noti inoltre come \var{st\_ctime} non abbia nulla a che -fare con il tempo di creazione usato da molti altri sistemi operativi, che in -unix non esiste. +le informazioni contenute nell'inode senza toccare il file, diventa necessario +l'utilizzo di un altro tempo. + +Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni +come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il +tempo di ultimo accesso viene di solito usato per cancellare i file che non +servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} cancella i +vecchi articoli sulla base di questo tempo). + +Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere +quali file necessitano di essere ricompilati o (talvolta insieme anche al +tempo di cambiamento di stato) per decidere quali file devono essere +archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni +\cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato +nell'ultima colonna di \curtab. + +L'effetto delle varie funzioni di manipolazione dei file sui tempi è +illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa +riferimento, sia per la directory che lo contiene; questi ultimi possono +essere capiti se si tiene conto di quanto già detto, e cioè che anche le +directory sono files, che il sistema tratta in maniera del tutto analoga agli +altri. + +Per questo motivo tutte le volte che compiremo una operazione su un file che +comporta una modifica della sua directory entry, andremo anche a scrivere +sulla directory che lo contiene cambiandone il tempo di modifica. Un esempio +di questo può essere la cancellazione di un file, mentre leggere o scrivere o +cambiarne i permessi ha effetti solo sui tempi del file. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|c|c|c|c|c|l|} + \hline + Funzione & \multicolumn{3}{c}{File o directory} + &\multicolumn{3}{c}{Directory genitrice} &Note \\ + Funzione & \multicolumn{3}{c}{di riferimento} & + \multicolumn{3}{c}{del riferimento} \\ + \hline + \hline + \func{chmod}, \func{fchmod} + & & &$\bullet$& & & & \\ + \func{chown}, \func{fchown} + & & &$\bullet$& & & & \\ + \func{creat} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con + \macro{O\_CREATE} \\ \func{creat} + & &$\bullet$&$\bullet$& &$\bullet$&$\bullet$& + con \macro{O\_TRUNC} \\ \func{exec} + &$\bullet$& & & & & & \\ + \func{lchown} + & & &$\bullet$& & & & \\ + \func{link} + & & &$\bullet$& &$\bullet$&$\bullet$& \\ + \func{mkdir} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\ + \func{mkfifo} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\ + \func{open} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con + \macro{O\_CREATE} \\ \func{open} + & &$\bullet$&$\bullet$& & & & con + \macro{O\_TRUNC} \\ \func{pipe} + &$\bullet$&$\bullet$&$\bullet$& & & & \\ + \func{read} + &$\bullet$& & & & & & \\ + \func{remove} + & & &$\bullet$& &$\bullet$&$\bullet$& using + \func{unlink}\\ \func{remove} + & & & & &$\bullet$&$\bullet$& using + \func{rmdir}\\ \func{rename} + & & &$\bullet$& &$\bullet$&$\bullet$& per entrambi + gli argomenti\\ \func{rmdir} + & & & & &$\bullet$&$\bullet$& \\ + \func{truncate}, \func{ftruncate} + & &$\bullet$&$\bullet$& & & & \\ + \func{unlink} + & & &$\bullet$& &$\bullet$&$\bullet$& \\ + \func{utime} + &$\bullet$&$\bullet$&$\bullet$& & & & \\ + \func{write} + & &$\bullet$&$\bullet$& & & & \\ + \hline + \end{tabular} + \caption{Effetti delle varie funzioni su tempi di ultimo accesso + \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento + \textsl{(c)}} + \label{tab:filedir_times_effects} +\end{table} +Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di +creazione del file usato da molti altri sistemi operativi, che in unix non +esiste. \subsection{La funzione \texttt{utime}} \label{sec:filedir_utime} +I tempi di ultimo accesso e modifica possono essere cambiati usando la +funzione \func{utime}, il cui prototipo è: + +\begin{prototype}{utime.h} +{int utime(const char * filename, struct utimbuf *times)} + +Cambia i tempi di ultimo accesso e modifica dell'inode specificato da +\var{filename} secondo i campi \var{actime} e \var{modtime} di \var{times}. Se +questa è \macro{NULL} allora viene usato il tempo corrente. + +La funzione restituisce zero in caso di successo e -1 in caso di errore, nel +qual caso \var{errno} è settata opportunamente. +\begin{errlist} +\item \texttt{EACCESS} non si ha il permesso di scrittura sul file. +\item \texttt{ENOENT} \var{filename} non esiste. +\end{errlist} +\end{prototype} + +La struttura \var{utimebuf} usata da \func{utime} è definita come: +\begin{lstlisting}{} +struct utimbuf { + time_t actime; /* access time */ + time_t modtime; /* modification time */ +}; +\end{lstlisting} + +L'effetto della funzione e i privilegi necessari per eseguirla dipendono da +cosa è l'argomento \var{times}; se è \textit{NULL} la funzione setta il tempo +corrente e basta l'accesso in scrittura al file; se invece si è specificato un +valore la funzione avrà successo solo se si è proprietari del file (o si hanno +i privilegi di amministratore). + +Si tenga presente che non è comunque possibile specificare il tempo di +cambiamento di stato del file, che viene comunque cambiato dal kernel anche +alla chiamata di \func{utime}; questo serve acnhe come misura di sicurezza per +evitare che si possa modificare un file nascondendo completamente le proprie +tracce. In realtà la cosa resta possibile, se si è in grado di accedere al +device, scrivendo direttamente sul disco senza passare attraverso il +filesystem, ma ovviamente è molto più complicato da realizzare. \section{Il controllo di accesso ai file} \label{sec:filedir_access_control} - In unix è implementata da qualunque filesystem standard una forma elementare (ma adatta alla maggior parte delle esigenze) di controllo di accesso ai files. Torneremo sull'argomento in dettaglio più avanti (vedi diff --git a/gapil.tex b/gapil.tex index 5e1fc77..dedffaa 100644 --- a/gapil.tex +++ b/gapil.tex @@ -105,16 +105,14 @@ \include{socket} \include{elemtcp} \include{simpltcp} +\appendix \include{app_a} \include{app_b} \include{fdl} - - % at the end put the bibliography %\bibliographystyle{phaip} %\bibliography{biblio} -\end{document} - +\end{document} \ No newline at end of file diff --git a/intro.tex b/intro.tex index cc6dcfa..ebbc5e2 100644 --- a/intro.tex +++ b/intro.tex @@ -257,7 +257,7 @@ per i tempi all'interno del sistema, chiamati rispettivamente \textit{calendar (eccetto per la piattaforma alpha). Il dato primitivo usato per questo tempo è \func{clock\_t}, inoltre la costante \macro{HZ} restituisce la frequenza di operazione del timer, e corrisponde dunque al numero di tick al secondo - (Posix definisce allo stesso modo la costante \macro{CLK_TCK}); questo + (Posix definisce allo stesso modo la costante \macro{CLK\_TCK}); questo valore può comunque essere ottenuto con \func{sysconf} (vedi \secref{sec:intro_limits}). \end{itemize} -- 2.30.2 From daacafbdd3ae5d8fa4b68ecdcc2a5c97fd5128b7 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Wed, 18 Jul 2001 23:08:12 +0000 Subject: [PATCH 14/16] Rimesse a posto un sacco di referenze, figure, etc. --- app_a.tex | 569 ++++++++++++++++++++--------------------- filedir.tex | 44 ++-- fileintro.tex | 14 +- gapil.tex | 5 +- img/environ_var.dia | Bin 0 -> 1712 bytes img/iso_tcp_comp.dia | Bin 0 -> 1945 bytes img/proc_exit.dia | Bin 0 -> 2724 bytes img/tcp_data_flux.dia | Bin 0 -> 2395 bytes img/tcpip_overview.dia | Bin 0 -> 378 bytes network.tex | 81 +++--- process.tex | 63 ++++- signal.tex | 1 + socket.tex | 63 +++-- 13 files changed, 451 insertions(+), 389 deletions(-) create mode 100644 img/environ_var.dia create mode 100644 img/iso_tcp_comp.dia create mode 100644 img/proc_exit.dia create mode 100644 img/tcp_data_flux.dia create mode 100644 img/tcpip_overview.dia diff --git a/app_a.tex b/app_a.tex index 0332efe..5c85730 100644 --- a/app_a.tex +++ b/app_a.tex @@ -1,43 +1,42 @@ \chapter{Il protocollo IP} \label{cha:ip_protocol} - L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981 dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura hardware delle reti di trasmissione, e creare una interfaccia di trasmissione -dei dati indipendente dal sottostante substrato di rete, che pu\`o essere -realizzato con le tecnologie pi\`u disparate (Ethernet, Token Ring, FDDI, +dei dati indipendente dal sottostante substrato di rete, che può essere +realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.). \section{Introduzione} -\label{sec:appA_intro} +\label{sec:IP_intro} -Il compito di IP \`e pertanto quello di trasmettere i pacchetti da un computer +Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer all'altro della rete; le caratteristiche essenziali con cui questo viene realizzato in IPv4 sono due: \begin{itemize} \item \textit{Universal addressing} la comunicazione avviene fra due host - identificati univocamente con un indirizzo a 32 bit che pu\`o appartenere ad + identificati univocamente con un indirizzo a 32 bit che può appartenere ad una sola interfaccia di rete. \item \textit{Best effort} viene assicurato il massimo impegno nella - trasmissione, ma non c'\`e nessuna garanzia per i livelli superiori n\'e - sulla percentuale di successo n\'e sul tempo di consegna dei pacchetti di + trasmissione, ma non c'è nessuna garanzia per i livelli superiori né + sulla percentuale di successo né sul tempo di consegna dei pacchetti di dati. \end{itemize} Per effettuare la comunicazione e l'instradamento dei pacchetti fra le varie -reti di cui \`e composta Internet IPv4 organizza gli indirizzi in una +reti di cui è composta Internet IPv4 organizza gli indirizzi in una gerarchia a due livelli, in cui una parte dei 32 bit dell'indirizzo indica il numero di rete, e un'altra l'host al suo interno. Il numero di rete serve ai router per stabilire a quale rete il pacchetto deve essere inviato, il numero di host indica la macchina di destinazione finale all'interno di detta rete. -Per garantire l'unicit\`a dell'indirizzo Internet esiste un'autorit\`a +Per garantire l'unicità dell'indirizzo Internet esiste un'autorità centrale (la IANA, \textit{Internet Assigned Number Authority}) che assegna i -numeri di rete alle organizzazioni che ne fanno richiesta; \`e poi compito di +numeri di rete alle organizzazioni che ne fanno richiesta; è poi compito di quest'ultime assegnare i numeri dei singoli host. Per venire incontro alle diverse esigenze gli indirizzi di rete sono stati @@ -113,17 +112,17 @@ diverse. \end{tabular} \caption{Le classi di indirizzi secondo IPv4.} -\label{tab:ipv4class} +\label{tab:IP_ipv4class} \end{table} Le classi usate per il dispiegamento delle reti sono le prime tre; la classe D -\`e destinata al (non molto usato) \textit{multicast} mentre la classe E \`e +è destinata al (non molto usato) \textit{multicast} mentre la classe E è riservata per usi sperimentali e non viene impiegata. -Come si pu\`o notare per\`o la suddivisione riportata in -Tab.~\ref{tab:ipv4class} \`e largamente inefficiente in quanto se ad un utente -necessita anche solo un indirizzo in pi\`u dei 256 disponibili con una classe -A occorre passare a una classe B, con un conseguente spreco di numeri. +Come si può notare però la suddivisione riportata in \tabref{tab:IP_ipv4class} +è largamente inefficiente in quanto se ad un utente necessita anche solo un +indirizzo in più dei 256 disponibili con una classe A occorre passare a una +classe B, con un conseguente spreco di numeri. Inoltre, in particolare per le reti di classe C, la presenza di tanti indirizzi di rete diversi comporta una crescita enorme delle tabelle di @@ -154,32 +153,32 @@ di questi ultimi ed inefficienza nel trasporto. \cline{2-33} \end{tabular} \caption{Uno esempio di indirizzamento CIDR.} -\label{tab:ipv4cidr} +\label{tab:IP_ipv4cidr} \end{table} -Per questo nel 1992 \`e stato introdotto un indirizzamento senza classi (il +Per questo nel 1992 è stato introdotto un indirizzamento senza classi (il CIDR) in cui il limite fra i bit destinati a indicare il numero di rete e -quello destinati a indicare l'host finale pu\`o essere piazzato in qualunque -punto (vedi Tab.~\ref{tab:ipv4cidr}), permettendo di accorpare pi\`u classi A -su un'unica rete o suddividere una classe B e diminuendo al contempo il -numero di indirizzi di rete da inserire nelle tabelle di instradamento dei +quello destinati a indicare l'host finale può essere piazzato in qualunque +punto (vedi Tab.~\tabref{tab:IP_ipv4cidr}), permettendo di accorpare più +classi A su un'unica rete o suddividere una classe B e diminuendo al contempo +il numero di indirizzi di rete da inserire nelle tabelle di instradamento dei router. \section{I motivi della transizione} -\label{sec:whyipv6} +\label{sec:IP_whyipv6} Negli ultimi anni la crescita vertiginosa del numero di macchine connesse a internet ha iniziato a far emergere i vari limiti di IPv4; in particolare si -\`e iniziata a delineare la possibilit\`a di arrivare a una carenza di +è iniziata a delineare la possibilità di arrivare a una carenza di indirizzi disponibili. -In realt\`a il problema non \`e propriamente legato al numero di indirizzi -disponibili; infatti con 32 bit si hanno $2^{32}$, cio\`e circa 4 miliardi, -numeri diversi possibili, che sono molti di pi\`u dei computer attualemente +In realtà il problema non è propriamente legato al numero di indirizzi +disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi, +numeri diversi possibili, che sono molti di più dei computer attualemente esistenti. -Il punto \`e che la suddivisione di questi numeri nei due livelli rete/host e +Il punto è che la suddivisione di questi numeri nei due livelli rete/host e l'utilizzo delle classi di indirizzamento mostrate in precedenza, ha comportato che, nella sua evoluzione storica, il dispiegamento delle reti e l'allocazione degli indirizzi siano stati inefficienti; neanche l'uso del CIDR @@ -188,16 +187,16 @@ ridispiegamento degli indirizzi comporta cambiamenti complessi a tutti i livelli e la riassegnazione di tutti gli indirizzi dei computer di ogni sottorete. -Diventava perci\`o necessario progettare un nuovo protocollo che permettesse -di risolvere questi problemi, e garantisse flessibilit\`a sufficiente per +Diventava perciò necessario progettare un nuovo protocollo che permettesse +di risolvere questi problemi, e garantisse flessibilità sufficiente per poter continuare a funzionare a lungo termine; in particolare necessitava un nuovo schema di indirizzamento che potesse rispondere alle seguenti -necessit\`a: +necessità: \begin{itemize} \item un maggior numero di numeri disponibili che consentisse di non restare - pi\`u a corto di indirizzi -\item un'organizzazione gerarchica pi\`u flessibile dell'attuale + più a corto di indirizzi +\item un'organizzazione gerarchica più flessibile dell'attuale \item uno schema di assegnazione degli indirizzi in grado di minimizzare le dimensioni delle tabelle di instradamento \item uno spazio di indirizzi che consentisse un passaggio automatico dalle @@ -206,46 +205,46 @@ necessit\`a: \section{Principali caratteristiche di IPv6} -\label{sec:ipv6over} +\label{sec:IP_ipv6over} -Per rispondere alle esigenze descritte in Sez.~\ref{sec:whyipv6} IPv6 nasce +Per rispondere alle esigenze descritte in \secref{sec:IP_whyipv6} IPv6 nasce come evoluzione di IPv4, mantendone inalterate le funzioni che si sono dimostrate valide, eliminando quelle inutili e aggiungendone poche altre -ponendo al contempo una grande attenzione a mantenere il protocollo il pi\`u +ponendo al contempo una grande attenzione a mantenere il protocollo il più snello e veloce possibile. I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a grandi linee nei seguenti punti: \begin{itemize} -\item l'espansione delle capacit\`a di indirizzamento e instradamento, per - supportare una gerarchia con pi\`u livelli di indirizzamento, un numero di +\item l'espansione delle capacità di indirizzamento e instradamento, per + supportare una gerarchia con più livelli di indirizzamento, un numero di nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che si aggiungono agli usuali \textit{unycast} e \textit{multicast} \item la semplificazione del formato della testata, eliminando o rendendo - opzionali alcuni dei campi di IPv4, per eliminare la necessit\`a di + opzionali alcuni dei campi di IPv4, per eliminare la necessità di riprocessamento della stessa da parte dei router e contenere l'aumento di dimensione dovuto ai nuovi indirizzi \item un supporto per le opzioni migliorato, per garantire una trasmissione - pi\`u efficiente del traffico normale, limiti meno stringenti sulle - dimensioni delle opzioni, e la flessibilit\`a necessaria per introdurne di + più efficiente del traffico normale, limiti meno stringenti sulle + dimensioni delle opzioni, e la flessibilità necessaria per introdurne di nuove in futuro -\item il supporto per delle capacit\`a di qualit\`a di servizio (QoS) che - permetta di identificare gruppi di dati per i quali si pu\`o provvedere un +\item il supporto per delle capacità di qualità di servizio (QoS) che + permetta di identificare gruppi di dati per i quali si può provvedere un trattamento speciale (in vista dell'uso di internet per applicazioni multimediali e/o ``real-time'') \end{itemize} \section{La testata di IPv6} -\label{sec:ipv6haed} +\label{sec:IP_ipv6head} Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal protocollo per gestire la trasmissione dei pacchetti; in -Tab.~\ref{tab:ipv6head} \`e riportato il formato della testata di IPv6 da -confrontare con quella di IPv4 in Tab.~\ref{tab:ipv4head}. la spiegazione del -significato dei vari campi delle due testate \`e riportato rispettivamente in -Tab.~\ref{tab:ipv6field} e Tab.~\ref{tab:ipv4field}) +\tabref{tab:IP_ipv6head} è riportato il formato della testata di IPv6 da +confrontare con quella di IPv4 in \tabref{tab:IP_ipv4head}. La spiegazione del +significato dei vari campi delle due testate è riportato rispettivamente in +\tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field}) \begin{table}[htb] \footnotesize @@ -278,11 +277,11 @@ Tab.~\ref{tab:ipv6field} e Tab.~\ref{tab:ipv4field}) \hline \end{tabular} \caption{La testata o \textit{header} di IPv6} - \label{tab:ipv6head} + \label{tab:IP_ipv6head} \end{center} \end{table} -Come si pu\`o notare la testata di IPv6 diventa di dimensione fissa, pari a 40 +Come si può notare la testata di IPv6 diventa di dimensione fissa, pari a 40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per IPv4; un semplice raddoppio nonostante lo spazio destinato agli indirizzi sia quadruplicato, questo grazie a una notevole semplificazione che ha ridotto il @@ -297,65 +296,65 @@ numero dei campi da 12 a 8. \textit{version} & 4 bit & \textsl{versione}, nel caso specifico vale sempre 6\\ \textit{priority} & 4 bit & - \textsl{priorit\`a}, vedi Sez.~\ref{sec:prio} \\ + \textsl{priorità}, vedi Sez.~\ref{sec:prio} \\ \textit{flow label} & 24 bit & - \textsl{etichetta di flusso}, vedi Sez.~\ref{sec:flow}\\ + \textsl{etichetta di flusso}, vedi Sez.~\ref{sec:IP_ipv6_flow}\\ \textit{payload leght} & 16 bit & - \textsl{lunghezza del carico}, cio\`e del corpo dei dati che segue + \textsl{lunghezza del carico}, cioè del corpo dei dati che segue l'intestazione, in bytes. \\ \textit{next header} & 8 bit & \textsl{testata successiva}, identifica il tipo di pacchetto che segue la testata di IPv6, usa gli stessi valori del campo protocollo nella testata di IPv4\\ \textit{hop limit} & 8 bit & \textsl{limite di salti}, stesso significato del \textit{time to live} nella testata di IPv4, - \`e decrementato di uno ogni volta che un nodo ritrasmette il + è decrementato di uno ogni volta che un nodo ritrasmette il pacchetto, se arriva a zero il pacchetto viene scartato \\ \textit{source IP} & 128 bit & \textsl{indirizzo di origine} \\ \textit{destination IP}& 128 bit & \textsl{indirizzo di destinazione}\\ \bottomrule \end{tabular} \caption{Legenda per il significato dei campi dell'intestazione di IPv6} - \label{tab:ipv6field} + \label{tab:IP_ipv6field} \end{center} \end{table} -Abbiamo gi\`a anticipato in Sez.~\ref{sec:ipv6over} uno dei criteri principali -nella progettazione di IPv6 \`e stato quello di ridurre al massimo il tempo di +Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali +nella progettazione di IPv6 è stato quello di ridurre al massimo il tempo di processamento dei pacchetti da parte dei router, un confronto con la testata -di IPv4 (vedi Tab.~\ref{tab:ipv4head}) mostra le seguenti differenze: +di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze: \begin{itemize} -\item \`e stato eliminato il campo \textit{header lenght} in quanto le opzioni - sono state tolte dalla testata che ha cos\`\i\ dimensione fissa; ci possono - essere pi\`u testate opzionali (\textsl{testate di estensione}, vedi - Sez.~\ref{sec:extens}), ciascuna dell quali avr\`a un suo campo di lunghezza - all'interno. -\item la testata e gli indirizzi sono allineati a 64 bit, questo rende pi\`u +\item è stato eliminato il campo \textit{header lenght} in quanto le opzioni + sono state tolte dalla testata che ha così dimensione fissa; ci possono + essere più testate opzionali (\textsl{testate di estensione}, vedi + \secref{sec:_IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di + lunghezza all'interno. +\item la testata e gli indirizzi sono allineati a 64 bit, questo rende più veloce il processo da parte di computer con processori a 64 bit. \item i campi per gestire la frammentazione (\textit{identification}, \textit{flag} e \textit{fragment offset}) sono stati eliminati; questo - perch\'e la frammentazione \'e un'eccezione che non deve rallentare il + perché la frammentazione è un'eccezione che non deve rallentare il processo dei pacchetti nel caso normale. -\item \`e stato eliminato il campo \textit{checksum} in quanto tutti i +\item è stato eliminato il campo \textit{checksum} in quanto tutti i protocolli di livello superiore (TCP, UDP e ICMPv6) hanno un campo di checksum che include, oltre alla loro testata e ai dati, pure i campi \textit{payload lenght}, \textit{next header}, e gli indirizzi di origine e di destinazione; una checksum esiste anche per la gran parte protocolli di livello inferiore (anche se quelli che non lo hanno, come SLIP, non possono - essere usati con grande affidabilit\`a); con questa scelta si \`e ridotto di - molti tempo di riprocessamento dato che i router non hanno pi\'u la - necessit\`a di ricalcolare la checksum ad ogni passaggio di un pacchetto per + essere usati con grande affidabilità); con questa scelta si è ridotto di + molti tempo di riprocessamento dato che i router non hanno più la + necessità di ricalcolare la checksum ad ogni passaggio di un pacchetto per il cambiamento del campo \textit{hop limit}. -\item \`e stato eliminato il campo \textit{type of service}, che praticamente - non \`e mai stato utilizzato; una parte delle funzionali\`a ad esso delegate +\item è stato eliminato il campo \textit{type of service}, che praticamente + non è mai stato utilizzato; una parte delle funzionalià ad esso delegate sono state reimplementate (vedi il campo \textit{priority} al prossimo punto) con altri metodi. -\item \`e stato introdotto un nuovo campo \textit{flow label}, che viene - usato, insieme al campo \textit{priority} (che recupera i bit di - precedenza del campo \textit{type of service}) per implementare la gestione - di una ``qualit\`a di servizio'' (vedi Sez.~\ref{sec:qos}) che permette di +\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato, + insieme al campo \textit{priority} (che recupera i bit di precedenza del + campo \textit{type of service}) per implementare la gestione di una + ``qualità di servizio'' (vedi Sez.~\ref{sec:IP_ipv6_qos}) che permette di identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si - pu\`o provvedere un trattamento speciale. + può provvedere un trattamento speciale. \end{itemize} \begin{table}[htb] @@ -392,7 +391,7 @@ di IPv4 (vedi Tab.~\ref{tab:ipv4head}) mostra le seguenti differenze: \hline \end{tabular} \caption{L'intestazione o \textit{header} di IPv4} -\label{tab:ipv4head} +\label{tab:IP_ipv4head} \end{table} \begin{table}[htb] @@ -408,17 +407,17 @@ di IPv4 (vedi Tab.~\ref{tab:ipv4head}) mostra le seguenti differenze: \textit{type of service} & 8 bit & \textsl{tipo di servizio}, consiste in: 3 bit di precedenza, correntemente ignorati; un bit non usato a 0; 4 bit che identificano - il tipo di servizio richiesto, uno solo dei quali pu\`o essere 1\\ + il tipo di servizio richiesto, uno solo dei quali può essere 1\\ \textit{total lenght} & 16 bit & \textsl{lunghezza totale}, indica la dimensione del pacchetto IP in byte\\ \textit{identification} & 16 bit & \textsl{identificazione}, - assegnato alla creazione, \`e aumentato di uno all'origine alla + assegnato alla creazione, è aumentato di uno all'origine alla trasmissione di ciascun pacchetto, ma resta lo stesso per i pacchetti frammentati\\ \textit{flag} & 3 bit & \textsl{flag} bit di frammentazione, uno indica se un - pacchetto \`e frammentato, un'altro se ci sono ulteriori frammenti, e - un'altro se il pacchetto non pu\`o essere frammentato. \\ + pacchetto è frammentato, un'altro se ci sono ulteriori frammenti, e + un'altro se il pacchetto non può essere frammentato. \\ \textit{fragmentation offset} & 13 bit& \textsl{offset di frammento}, indica la posizione del frammento rispetto al pacchetto originale\\ \textit{time to live} & 16 bit & \textsl{tempo di vita}, @@ -434,7 +433,7 @@ di IPv4 (vedi Tab.~\ref{tab:ipv4head}) mostra le seguenti differenze: \bottomrule \end{tabular} \caption{Legenda per il significato dei campi dell'intestazione di IPv4} - \label{tab:ipv4field} + \label{tab:IP_ipv4field} \end{center} \end{table} @@ -443,58 +442,58 @@ ulteriori caratteristiche che diversificano il comportamento di IPv4 da quello di IPv6 sono le seguenti: \begin{itemize} -\item il broadcasting non \`e previsto in IPv6, le applicazioni che lo usano +\item il broadcasting non è previsto in IPv6, le applicazioni che lo usano dovono essere reimplementate usando il multicasting (vedi - Sez.~\ref{sec:multicast}), che da opzionale diventa obbligatorio. -\item \`e stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}. -\item i router non possono pi\`u frammentare i pacchetti lungo il cammino, la - frammentazione di pacchetti troppo grandi potr\`a essere gestita solo ai + \secref{sec:IP_multicast}), che da opzionale diventa obbligatorio. +\item è stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}. +\item i router non possono più frammentare i pacchetti lungo il cammino, la + frammentazione di pacchetti troppo grandi potrà essere gestita solo ai capi della comunicazione (usando un'apposita estensione vedi - Sez.~\ref{sec:extens}). -\item IPv6 richiede il supporto per il \textit{path MTU discovery} (cio\`e il + \secref{sec:IP_ipv6_extens}). +\item IPv6 richiede il supporto per il \textit{path MTU discovery} (cioè il protocollo per la selezione della massima lunghezza del pacchetto); seppure - questo sia in teoria opzionale, senza di esso non sar\`a possibile inviare - pacchetti pi\`u larghi della dimensione minima (576 bytes). + questo sia in teoria opzionale, senza di esso non sarà possibile inviare + pacchetti più larghi della dimensione minima (576 bytes). \end{itemize} \section{Gli indirizzi di IPv6} -\label{sec:addr} +\label{sec:IP_ipv6_addr} -Come gi\`a abbondantemente anticipato la principale novit\`a di IPv6 \`e +Come già abbondantemente anticipato la principale novità di IPv6 è costituita dall'ampliamento dello spazio degli indirizzi, che consente di avere indirizzi disponibili in un numero dell'ordine di quello degli atomi che costituiscono la terra. -In realt\`a l'allocazione di questi indirizzi deve tenere conto della -necessit\`a di costruire delle gerarchie che consentano un instradamento -rapido ed efficiente dei pacchetti, e flessibilit\`a nel dispiegamento delle +In realtà l'allocazione di questi indirizzi deve tenere conto della +necessità di costruire delle gerarchie che consentano un instradamento +rapido ed efficiente dei pacchetti, e flessibilità nel dispiegamento delle reti, il che comporta una riduzione drastica dei numeri utilizzabili; uno studio sull'efficienza dei vari sistemi di allocazione usati in altre -architetture (come i sistemi telefonici) \`e comunque giunto alla conclusione +architetture (come i sistemi telefonici) è comunque giunto alla conclusione che anche nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di -fornire pi\`u di un migliaio di indirizzi per ogni metro quadro della +fornire più di un migliaio di indirizzi per ogni metro quadro della superficie terrestre. \subsection{La notazione} -\label{sec:notazione} -Con un numero di bit quadruplicato non \`e pi\`u possibile usare la notazione +\label{sec:IP_ipv6_notation} +Con un numero di bit quadruplicato non è più possibile usare la notazione coi numeri decimali di IPv4 per rappresentare un numero IP. Per questo gli indirizzi di IPv6 sono in genere scritti come sequenze di otto numeri -esadecimali di 4 cifre (cio\`e a gruppi di 16 bit) usando i due punti come -separatore; cio\`e qualcosa del tipo +esadecimali di 4 cifre (cioè a gruppi di 16 bit) usando i due punti come +separatore; cioè qualcosa del tipo \texttt{5f1b:df00:ce3e:e200:0020:0800:2078:e3e3}. Visto che la notazione resta comunque piuttosto pesante esistono alcune -abbreviazioni; si pu\`o evitare di scrivere gli zeri iniziali per cui si -pu\`o scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero \`e -zero si pu\`o omettere del tutto, cos\`\i\ come un insieme di zeri (ma questo -solo una volta per non generare ambiguit\`a) per cui il precedente indirizzo -si pu\`o scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}. +abbreviazioni; si può evitare di scrivere gli zeri iniziali per cui si +può scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero è +zero si può omettere del tutto, così come un insieme di zeri (ma questo +solo una volta per non generare ambiguità) per cui il precedente indirizzo +si può scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}. Infine per scrivere un indirizzo IPv4 all'interno di un indirizzo IPv6 si -pu\`o usare la vecchia notazione con i punti, per esempio +può usare la vecchia notazione con i punti, per esempio \texttt{::192.84.145.138}. \begin{table}[htb] @@ -536,66 +535,66 @@ pu\`o usare la vecchia notazione con i punti, per esempio multicast & \texttt{1111 1111} & 1/256 \\ \hline \end{tabular} - \caption{Classificazione degli indirizzi IPv6 a seconda dei bit pi\`u + \caption{Classificazione degli indirizzi IPv6 a seconda dei bit più significativi} - \label{tab:ipv6addr} + \label{tab:IP_ipv6addr} \end{table} \subsection{La architettura degli indirizzi di IPv6} -\label{sec:arch} +\label{sec:IP_ipv6_addr_arch} Come per IPv4 gli indirizzi sono identificatori per una singola (indirizzi \textit{unicast}) o per un insieme (indirizzi \textit{multicast} e \textit{anycast}) di interfacce di rete. Gli indirizzi sono sempre assegnati all'interfaccia, non al nodo che la -ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo pu\`o +ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo può essere identificato attraverso uno qualunque degli indirizzi unicast delle sue -interfacce. A una interfaccia possono essere associati anche pi\`u indirizzi. +interfacce. A una interfaccia possono essere associati anche più indirizzi. IPv6 presenta tre tipi diversi di indirizzi: due di questi, gli indirizzi \textit{unicast} e \textit{multicast} hanno le stesse caratteristiche che in -IPv4, un terzo tipo, gli indirizzi \textit{anycast} \`e completamente nuovo. -In IPv6 non esistono pi\`u gli indirizzi \textit{broadcast}, la funzione di +IPv4, un terzo tipo, gli indirizzi \textit{anycast} è completamente nuovo. +In IPv6 non esistono più gli indirizzi \textit{broadcast}, la funzione di questi ultimi deve essere reimplementata con gli indirizzi \textit{multicast}. Gli indirizzi \textit{unicast} identificano una singola interfaccia i pacchetti mandati ad un tale indirizzo verranno inviati a quella interfaccia, gli indirizzi \textit{anycast} identificano un gruppo di interfacce tale che -un pacchetto mandato a uno di questi indirizzi viene inviato alla pi\`u vicina +un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina (nel senso di distanza di routing) delle interfacce del gruppo, gli indirizzi \textit{multicast} identificano un gruppo di interfacce tale che un pacchetto mandato a uno di questi indirizzi viene inviato a tutte le interfacce del gruppo. -In IPv6 non ci sono pi\`u le classi ma i bit pi\`u significativi indicano il -tipo di indirizzo; in Tab.~\ref{tab:ipv6addr} sono riportati i valori di detti -bit e il tipo di indirizzo che loro corrispondente. I bit pi\`u significativi -costituiscono quello che viene chiamato il \textit{format prefix} ed \`e sulla -base di questo che i vari tipi di indirizzi vengono identificati. -Come si vede questa architettura di allocazione supporta l'allocazione di -indirizzi per i provider, per uso locale e per il multicast; inoltre \`e stato -riservato lo spazio per indirizzi NSAP, IPX e per le connessioni; gran parte -dello spazio (pi\`u del 70\%) \`e riservato per usi futuri. +In IPv6 non ci sono più le classi ma i bit più significativi indicano il tipo +di indirizzo; in \tabref{tab:IP_ipv6addr} sono riportati i valori di detti +bit e il tipo di indirizzo che loro corrispondente. I bit più significativi +costituiscono quello che viene chiamato il \textit{format prefix} ed è sulla +base di questo che i vari tipi di indirizzi vengono identificati. Come si +vede questa architettura di allocazione supporta l'allocazione di indirizzi +per i provider, per uso locale e per il multicast; inoltre è stato riservato +lo spazio per indirizzi NSAP, IPX e per le connessioni; gran parte dello +spazio (più del 70\%) è riservato per usi futuri. Si noti infine che gli indirizzi \textit{anycast} non sono riportati in -Tab.~\ref{tab:ipv6addr} in quanto allocati al di fuori dello spazio di +\tabref{tab:IP_ipv6addr} in quanto allocati al di fuori dello spazio di allocazione degli indirizzi unicast. \subsection{Indirizzi unicast \textit{provider-based}} -\label{sec:unicast} +\label{sec:IP_ipv6_unicast} Gli indirizzi \textit{provider-based} sono gli indirizzi usati per le comunicazioni globali, questi sono definiti nell'RFC 2073 e sono gli equivalenti degli attuali indirizzi delle classi da A a C. -L'autorit\`a che presiede all'allocazione di questi indirizzi \`e la IANA; per +L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per evitare i problemi di crescita delle tabelle di instradamento e una procedura -efficiente di allocazione la struttura di questi indirizzi \`e organizzata fin -dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi \`e +efficiente di allocazione la struttura di questi indirizzi è organizzata fin +dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi è stato suddiviso in una serie di campi secondo lo schema riportato in -Tab.~\ref{tab:unicast}. +\tabref{tab:IP_ipv6_unicast}. \begin{table}[htb] \centering @@ -617,15 +616,15 @@ Tab.~\ref{tab:unicast}. \hline \end{tabular} \caption{Formato di un indirizzo unicast \textit{provider-based}.} -\label{tab:unicast} +\label{tab:IP_ipv6_unicast} \end{table} -Al livello pi\`u alto la IANA pu\`o delegare l'allocazione a delle autorit\`a +Al livello più alto la IANA può delegare l'allocazione a delle autorità regionali (i Regional Register) assegnando ad esse dei blocchi di indirizzi; a -queste autorit\`a regionali \`e assegnato un Registry Id che deve seguire +queste autorità regionali è assegnato un Registry Id che deve seguire immediatamente il prefisso di formato. Al momento sono definite tre registri -regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si \`e riservata la -possibilit\`a di allocare indirizzi su base regionale; pertanto sono previsti +regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si è riservata la +possibilità di allocare indirizzi su base regionale; pertanto sono previsti i seguenti possibili valori per il \textsl{Registry Id}; gli altri valori restano riservati per la IANA. \begin{table}[htb] @@ -641,7 +640,7 @@ gli altri valori restano riservati per la IANA. \end{tabular} \caption{Valori dell'identificativo dei Regional Register allocati ad oggi.} - \label{tab:regid} + \label{tab:IP_ipv6_regid} \end{center} \end{table} @@ -651,17 +650,17 @@ servizi, e \textit{Subscriber Id}, che identifica i fruitori, sia gestita dai singoli registri regionali. Questi ultimi dovranno definire come dividere lo spazio di indirizzi assegnato a questi due campi (che ammonta a un totale di 58~bit), definendo lo spazio da assegnare al \textit{Provider Id} e -al \textit{Subscriber Id}, ad essi spetter\`a inoltre anche l'allocazione dei -numeri di \textit{Provider Id} ai singoli fornitori, ai quali sar\`a delegata -l'autorit\`a di allocare i \textit{Subscriber Id} al loro interno. +al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei +numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata +l'autorità di allocare i \textit{Subscriber Id} al loro interno. -L'ultimo livello \`e quello \textit{Intra-subscriber} che \`e lasciato alla +L'ultimo livello è quello \textit{Intra-subscriber} che è lasciato alla gestione dei singoli fruitori finali, gli indirizzi \textit{provider-based} lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la -modalit\`a pi\`u immediata \`e quella di usare uno schema del tipo mostrato in -Tab.~\ref{tab:uninterf} dove l'\textit{Interface Id} \`e dato dal MAC-address -a 48~bit dello standard ethernet, scritto in genere nell'hardware delle scheda -di rete, e si usano i restanti 16~bit per indicare la sottorete. +modalità più immediata è quella di usare uno schema del tipo mostrato in +\tabref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal +MAC-address a 48~bit dello standard ethernet, scritto in genere nell'hardware +delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete. \begin{table}[htb] \centering @@ -679,23 +678,23 @@ di rete, e si usano i restanti 16~bit per indicare la sottorete. \end{tabular} \caption{Formato del campo \textit{Intra-subscriber} per un indirizzo unicast \textit{provider-based}.} -\label{tab:uninterf} +\label{tab:IP_ipv6_uninterf} \end{table} -Qualora si dovesse avere a che fare con una necessit\`a di un numero pi\`u +Qualora si dovesse avere a che fare con una necessità di un numero più elevato di sottoreti, il precedente schema andrebbe modificato, per evitare l'enorme spreco dovuto all'uso dei MAC-address, a questo scopo si possono -usare le capacit\`a di autoconfigurazione di IPv6 per assegnare indirizzi +usare le capacità di autoconfigurazione di IPv6 per assegnare indirizzi generici con ulteriori gerarchie per sfruttare efficacemente tutto lo spazio di indirizzi. -Un registro regionale pu\`o introdurre un ulteriore livello nella gerarchia -degli indirizzi, allocando dei blocchi per i quali delegare l'autorit\`a a dei +Un registro regionale può introdurre un ulteriore livello nella gerarchia +degli indirizzi, allocando dei blocchi per i quali delegare l'autorità a dei registri nazionali, quest'ultimi poi avranno il compito di gestire la attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i -paese coperto dal registro nazionale con le modalit\`a viste in precedenza. -Una tale ripartizione andr\`a effettuata all'interno dei soliti 58~bit come -mostrato in Tab.~\ref{tab:uninaz}. +paese coperto dal registro nazionale con le modalità viste in precedenza. +Una tale ripartizione andrà effettuata all'interno dei soliti 58~bit come +mostrato in \ntab. \begin{table}[htb] \centering @@ -719,15 +718,16 @@ mostrato in Tab.~\ref{tab:uninaz}. \end{tabular} \caption{Formato di un indirizzo unicast \textit{provider-based} che prevede un registro nazionale.} -\label{tab:uninaz} +\label{tab:IP_ipv6_uninaz} \end{table} + \subsection{Indirizzi ad uso locale} -\label{sec:linksite} +\label{sec:IP_ipv6_linksite} Gli indirizzi ad uso locale sono indirizzi unicast che sono instradabili solo localmente (all'interno di un sito o di una sottorete), e possono avere una -unicit\`a locale o globale. +unicità locale o globale. Questi indirizzi sono pensati per l'uso all'interno di un sito per mettere su una comunicazione locale immediata, o durante le fasi di autoconfigurazione @@ -748,26 +748,25 @@ prima di avere un indirizzo globale. \hline \end{tabular} \caption{Formato di un indirizzo \textit{link-local}.} -\label{tab:linklocal} +\label{tab:IP_ipv6_linklocal} \end{table} Ci sono due tipi di indirizzi, \textit{link-local} e \textit{site-local}. Il -primo \`e usato per un singolo link; la struttura \`e mostrata in -Tab.~\ref{tab:linklocal}, questi indirizzi iniziano sempre per \texttt{FE80} e -vengono in genere usati per la configurazione automatica dell'indirizzo al -bootstrap e per la ricerca dei vicini (vedi Sez.~\ref{sec:autoconf}); un -pacchetto che abbia tale indirizzo come sorgente o destinazione non deve -venire ritrasmesso dai router. - -Un indirizzo \textit{site-local} invece \`e usato per l'indirizzamento +primo è usato per un singolo link; la struttura è mostrata in \curtab, questi +indirizzi iniziano sempre per \texttt{FE80} e vengono in genere usati per la +configurazione automatica dell'indirizzo al bootstrap e per la ricerca dei +vicini (vedi \ref{sec:IP_ipv6_autoconf}); un pacchetto che abbia tale +indirizzo come sorgente o destinazione non deve venire ritrasmesso dai router. + +Un indirizzo \textit{site-local} invece è usato per l'indirizzamento all'interno di un sito che non necessita di un prefisso globale; la struttura -\`e mostrata in Tab.~\ref{tab:sitelocal}, questi indirizzi iniziano sempre per +è mostrata in \ntab, questi indirizzi iniziano sempre per \texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del sito stesso; sono in sostanza gli equivalenti degli indirizzi riservati per reti private definiti su IPv4. -Per entrambi gli indirizzi il campo \textit{Interface Id} \`e un +Per entrambi gli indirizzi il campo \textit{Interface Id} è un identificatore che deve essere unico nel dominio in cui viene usato, un modo -immediato per costruirlo \`e quello di usare il MAC-address delle schede di +immediato per costruirlo è quello di usare il MAC-address delle schede di rete. \begin{table}[!h] @@ -787,10 +786,10 @@ rete. \hline \end{tabular} \caption{Formato di un indirizzo \textit{site-local}.} -\label{tab:sitelocal} +\label{tab:IP_ipv6_sitelocal} \end{table} -Gli indirizzi di uso locale consentono ad una organizzazione che non \`e +Gli indirizzi di uso locale consentono ad una organizzazione che non è (ancora) connessa ad Internet di operare senza richiedere un prefisso globale, una volta che in seguito l'organizzazione venisse connessa a Internet potrebbe continuare a usare la stessa suddivisione effettuata con gli @@ -798,18 +797,18 @@ indirizzi \textit{site-local} utilizzando un prefisso globale e la rinumerazione degli indirizzi delle singole macchine sarebbe automatica. \subsection{Indirizzi riservati} -\label{sec:reserved} +\label{sec:IP_ipv6_reserved} Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi -di compatibilit\`a. +di compatibilità. Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in -Tab.~\ref{tab:ipv6map}), questo sono indirizzi unicast che vengono usati per -consentire ad applicazioni IPv6 di comunicare con host capaci solo di IPv4; -questi sono ad esempio gli indirizzi generati da un DNS quando l'host -richiesto supporta solo IPv4; l'uso di un tale indirizzo in un socket IPv6 -comporta la generazione di un pacchetto IPv4 (ovviamente occorre che sia IPv4 -che IPv6 siano supportate sull'host di origine). +\ntab), questo sono indirizzi unicast che vengono usati per consentire ad +applicazioni IPv6 di comunicare con host capaci solo di IPv4; questi sono ad +esempio gli indirizzi generati da un DNS quando l'host richiesto supporta solo +IPv4; l'uso di un tale indirizzo in un socket IPv6 comporta la generazione di +un pacchetto IPv4 (ovviamente occorre che sia IPv4 che IPv6 siano supportate +sull'host di origine). \begin{table}[!htb] \centering @@ -827,14 +826,14 @@ che IPv6 siano supportate sull'host di origine). \hline \end{tabular} \caption{Formato di un indirizzo IPV4 mappato su IPv6.} -\label{tab:ipv6map} +\label{tab:IP_ipv6_map} \end{table} -Un secondo tipo di indirizzi di compatibilit\`a sono gli \textit{IPv4 - compatibili IPv6} (vedi Tab.~\ref{tab:ipv6comp} usati nella transizione da -IPv4 a IPv6, quando un host che supporta sia IPv6 che IPv4 non ha un router -IPv6 deve usare nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6 -inviato a un tale indirizzo verr\`a automaticamente incapsulato in IPv4. +Un secondo tipo di indirizzi di compatibilità sono gli \textit{IPv4 + compatibili IPv6} (vedi \ntab) usati nella transizione da IPv4 a IPv6, +quando un host che supporta sia IPv6 che IPv4 non ha un router IPv6 deve usare +nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6 inviato a un tale +indirizzo verrà automaticamente incapsulato in IPv4. \begin{table}[htb] \centering @@ -852,24 +851,24 @@ inviato a un tale indirizzo verr\`a automaticamente incapsulato in IPv4. \hline \end{tabular} \caption{Formato di un indirizzo IPV4 mappato su IPv6.} -\label{tab:ipv6comp} +\label{tab:IP_ipv6_comp} \end{table} Altri indirizzi speciali sono il \textit{loopback address}, costituito da 127 -zeri ed un uno (cio\`e \texttt{::1}) e l'\textsl{indirizzo generico} -costituito da tutti zeri (scritto come \texttt{0::0} o ancora pi\`u +zeri ed un uno (cioè \texttt{::1}) e l'\textsl{indirizzo generico} +costituito da tutti zeri (scritto come \texttt{0::0} o ancora più semplicemente come \texttt{:}) usato in genere quando si vuole indicare l'accettazione di una connessione da qualunque host. \subsection{Multicasting} -\label{sec:multicast} +\label{sec:IP_ipv6_multicast} Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di multicast e il pacchetto viene inviato a tutte le interfacce di detto gruppo. -Un'interfaccia pu\`o appartenere ad un numero qualunque numero di gruppi di -multicast. Il formato degli indirizzi \textit{multicast} \`e riportato in -Tab.~\ref{tab:multicast} +Un'interfaccia può appartenere ad un numero qualunque numero di gruppi di +multicast. Il formato degli indirizzi \textit{multicast} è riportato in +\ntab: \begin{table}[htb] \centering @@ -888,24 +887,24 @@ Tab.~\ref{tab:multicast} \hline \end{tabular} \caption{Formato di un indirizzo \textit{multicast}.} -\label{tab:multicast} +\label{tab:IP_ipv6_multicast} \end{table} -Il prefisso di formato per tutti gli indirizzi \textit{multicast} \`e -\texttt{FF}, ad esso seguono i due campi il cui significato \`e il seguente: +Il prefisso di formato per tutti gli indirizzi \textit{multicast} è +\texttt{FF}, ad esso seguono i due campi il cui significato è il seguente: \begin{itemize} \item \textsl{flag}: un insieme di 4 bit, di cui i primi tre sono riservati e - posti a zero, l'ultimo \`e zero se l'indirizzo \`e permanente (cio\`e un - indirizzo noto, assegnato dalla IANA), ed \`e uno se invece l'indirizzo \`e + posti a zero, l'ultimo è zero se l'indirizzo è permanente (cioè un + indirizzo noto, assegnato dalla IANA), ed è uno se invece l'indirizzo è transitorio. -\item \textsl{scop} \`e un numero di quattro bit che indica il raggio di - validit\`a dell'indirizzo, i valori assegnati per ora sono riportati in - Tab.~\ref{tab:multiscope}. +\item \textsl{scop} è un numero di quattro bit che indica il raggio di + validità dell'indirizzo, i valori assegnati per ora sono riportati in + \ntab. \end{itemize} Infine l'ultimo campo identifica il gruppo di multicast, sia permanente che -transitorio, all'interno del raggio di validit\`a del medesimo. +transitorio, all'interno del raggio di validità del medesimo. \begin{table}[!htb] \centering @@ -924,26 +923,26 @@ transitorio, all'interno del raggio di validit\`a del medesimo. \bottomrule \end{tabular} \caption{Possibili valori del campo \textsl{scop} di un indirizzo multicast.} -\label{tab:multiscope} +\label{tab:IP_ipv6_multiscope} \end{table} \subsection{Indirizzi \textit{anycast}} -\label{sec:anycast} +\label{sec:IP_anycast} Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un gruppo di interfacce per quali un pacchetto indirizzato a questo tipo di -indirizzo viene inviato al componente del gruppo pi\`u ``vicino'' secondo la +indirizzo viene inviato al componente del gruppo più ``vicino'' secondo la distanza di instradamento calcolata dai router. Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast, -usando uno dei formati disponibili, e per questo, sono da essi assolutamente -indistinguibili. Quando un indirizzo unicast viene assegnato a pi\`u -interfacce (trasformandolo in un anycast) il computer su cui \`e l'interfaccia -deve essere configurato per tener conto del fatto. +usando uno dei formati disponibili, e per questo, sono da essi assolutamente +indistinguibili. Quando un indirizzo unicast viene assegnato a più interfacce +(trasformandolo in un anycast) il computer su cui è l'interfaccia deve essere +configurato per tener conto del fatto. Gli indirizzi anycast consentono a un nodo sorgente di inviare pacchetti a una destinazione su un gruppo di possibili interfacce selezionate. La sorgente non -deve curarsi di come scegliere l'interfaccia pi\`u vicina, compito che tocca +deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca al sistema di instradamento, (in sostanza la sorgente non ha nessun controllo sulla selezione). @@ -956,26 +955,26 @@ Questi indirizzi pertanto possono essere usati come indirizzi intermedi in una testata di instradamento o per identificare insiemi di router connessi a una particolare sottorete, o che forniscono l'accesso a un certo sotto dominio. -L'idea alla base degli indirizzi anycast \`e perci\`o quella di utilizzarli -per poter raggiungere il fornitore di servizio pi\`u vicino; ma restano aperte -tutta una serie di problematiche, visto che una connessione con uno di questi -indirizzi non \`e possibile, dato che per una variazione delle distanze di -routing non \`e detto che due pacchetti successivi finiscano alla stessa +L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per +poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta +una serie di problematiche, visto che una connessione con uno di questi +indirizzi non è possibile, dato che per una variazione delle distanze di +routing non è detto che due pacchetti successivi finiscano alla stessa interfaccia. -La materia \`e pertanto ancora controversa e in via di definizione. +La materia è pertanto ancora controversa e in via di definizione. \section{Le estensioni} -\label{sec:extens} +\label{sec:IP_ipv6_extens} -Come gi\`a detto in precedenza IPv6 ha completamente cambiato il trattamento +Come già detto in precedenza IPv6 ha completamente cambiato il trattamento delle opzioni; queste ultime infatti sono state tolte dalla testata del pacchetto, e poste in apposite \textsl{testate di estensione} (o \textit{extension header}) poste fra la testata di IPv6 e la testata del protocollo di trasporto. -Per aumentare la velocit\`a di processo, sia dei dati del livello seguente che +Per aumentare la velocità di processo, sia dei dati del livello seguente che di ulteriori opzioni, ciascuna estensione deve avere una lunghezza multipla di 8 bytes per mantenere l'allineamento a 64~bit di tutti le testate seguenti. @@ -985,7 +984,7 @@ alla destinazione finale, questa scelta ha consentito un miglioramento delle prestazioni rispetto a IPv4 dove la presenza di un'opzione comportava l'esame di tutte quante. -Un secondo miglioramento \`e che rispetto a IPv4 le opzioni possono essere di +Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di lunghezza arbitraria e non limitate a 40 bytes; questo, insieme al modo in cui vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la sicurezza, improponibili con IPv4. @@ -994,28 +993,28 @@ Le estensioni definite al momento sono le seguenti: \begin{itemize} \item \textbf{Hop by hop} devono seguire immediatamente la testata principale; indicano le opzioni che devono venire processate ad ogni passaggio da un - router, fra di esse \`e da menzionare la \textit{jumbo payload} che segnala + router, fra di esse è da menzionare la \textit{jumbo payload} che segnala la presenza di un pacchetto di dati di dimensione superiore a 64Kb. \item \textbf{Destination options} opzioni che devono venire esaminate al nodo - di ricevimento, nessuna di esse \`e tuttora definita. + di ricevimento, nessuna di esse è tuttora definita. \item \textbf{Routing} definisce una \textit{source route} (come la analoga - opzione di IPv4) cio\`e una lista di indirizzi IP di nodi per i quali il + opzione di IPv4) cioè una lista di indirizzi IP di nodi per i quali il pacchetto deve passare. \item \textbf{Fragmentation} viene generato automaticamente quando un host - vuole frammentare un pacchetto, ed \`e riprocessato automaticamente alla + vuole frammentare un pacchetto, ed è riprocessato automaticamente alla destinazione che riassembla i frammenti. \item \textbf{Authentication} gestisce l'autenticazione e il controllo di - integrit\`a dei pacchetti; \`e documentato dall'RFC 162. + integrità dei pacchetti; è documentato dall'RFC 162. \item \textbf{Encapsulation} serve a gestire la segretezza del contenuto - trasmesso; \`e documentato dall'RFC 1827. + trasmesso; è documentato dall'RFC 1827. \end{itemize} -La presenza di opzioni \`e rilevata dal valore del campo \textit{next header} -che indica qual'\`e la testata successiva a quella di IPv6; in assenza di -opzioni questa sar\`a la testata di un protocollo di trasporto del livello -superiore, per cui il campo assumer\`a lo stesso valore del campo -\textit{protocol} di IPv4, altrimenti assumer\`a il valore dell'opzione -presente; i valori possibili sono riportati in Tab.~\ref{tab:nexthead}. +La presenza di opzioni è rilevata dal valore del campo \textit{next header} +che indica qual'è la testata successiva a quella di IPv6; in assenza di +opzioni questa sarà la testata di un protocollo di trasporto del livello +superiore, per cui il campo assumerà lo stesso valore del campo +\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione +presente; i valori possibili sono riportati in \ntab. \begin{table}[htb] \begin{center} @@ -1044,71 +1043,71 @@ presente; i valori possibili sono riportati in Tab.~\ref{tab:nexthead}. 255& & riservato \\ \end{tabular} \caption{Tipi di protocolli e testate di estensione} - \label{tab:nexthead} + \label{tab:IP_ipv6_nexthead} \end{center} \end{table} -Questo meccanismo permette la presenza di pi\`u opzioni in successione prima +Questo meccanismo permette la presenza di più opzioni in successione prima del pacchetto del protocollo di trasporto; l'ordine raccomandato per le -estensioni \`e quello riportato nell'elenco precedente con la sola differenza +estensioni è quello riportato nell'elenco precedente con la sola differenza che le opzioni di destinazione sono inserite nella posizione ivi indicata solo se, come per il tunnelling, devono essere esaminate dai router, quelle che devono essere esaminate solo alla destinazione finale vanno in coda. -\section{Qualit\`a di servizio} -\label{sec:qos} +\section{Qualità di servizio} +\label{sec:IP_ipv6_qos} -Una delle caratteristiche innovative di IPv6 \`e quella di avere introdotto un -supporto per la qualit\`a di servizio che \`e importante per applicazioni come +Una delle caratteristiche innovative di IPv6 è quella di avere introdotto un +supporto per la qualità di servizio che è importante per applicazioni come quelle multimediali o ``real-time'' che richiedono un qualche grado di -controllo sulla stabilit\`a della banda di trasmissione, sui ritardi o la +controllo sulla stabilità della banda di trasmissione, sui ritardi o la dispersione dei temporale del flusso dei pacchetti. \subsection{Etichette di flusso} -\label{sec:flow} -L'introduzione del campo \textit{flow label} pu\`o essere usata dall'origine +\label{sec:IP_ipv6_flow} +L'introduzione del campo \textit{flow label} può essere usata dall'origine della comunicazione per etichettare quei pacchetti per i quali si vuole un trattamento speciale da parte dei router come un una garanzia di banda minima assicurata o un tempo minimo di instradamento/trasmissione garantito. -Questo aspetto di IPv6 \`e ancora sperimentale per cui i router che non +Questo aspetto di IPv6 è ancora sperimentale per cui i router che non supportino queste funzioni devono porre a zero il \textit{flow label} per i pacchetti da loro originanti e lasciare invariato il campo per quelli in transito. -Un flusso \`e una sequenza di pacchetti da una particolare origine a una +Un flusso è una sequenza di pacchetti da una particolare origine a una particolare destinazione per il quale l'origine desidera un trattamento speciale da parte dei router che lo manipolano; la natura di questo -trattamento pu\`o essere comunicata ai router in vari modi (come un protocollo +trattamento può essere comunicata ai router in vari modi (come un protocollo di controllo o con opzioni del tipo \textit{hop-by-hop}). -Ci possono essere pi\`u flussi attivi fra un'origine e una destinazione, come +Ci possono essere più flussi attivi fra un'origine e una destinazione, come del traffico non assegnato a nessun flusso, un flusso viene identificato univocamente dagli indirizzi di origine e destinazione e da una etichetta di flusso diversa da zero, il traffico normale deve avere l'etichetta di flusso posta a zero. -L'etichetta di flusso \`e assegnata dal nodo di origine, i valori devono +L'etichetta di flusso è assegnata dal nodo di origine, i valori devono essere scelti in maniera (pseudo)casuale nel range fra 1 e FFFFFF in modo da rendere utilizzabile un qualunque sottoinsieme dei bit come chiavi di hash per i router. -\subsection{Priorit\`a} +\subsection{Priorità} \label{sec:prio} -Il campo di priorit\`a consente di indicare il livello di priorit\`a dei +Il campo di priorità consente di indicare il livello di priorità dei pacchetti relativamente agli altri pacchetti provenienti dalla stessa sorgente. I valori sono divisi in due intervalli, i valori da 0 a 7 sono usati -per specificare la priorit\`a del traffico per il quale la sorgente provvede -un controllo di congestione cio\`e per il traffico che pu\`o essere ``tirato +per specificare la priorità del traffico per il quale la sorgente provvede +un controllo di congestione cioè per il traffico che può essere ``tirato indietro'' in caso di congestione come quello di TCP, i valori da 8 a 15 sono usati per i pacchetti che non hanno questa caratteristica, come i pacchetti ``real-time'' inviati a ritmo costante. Per il traffico con controllo di congestione sono raccomandati i seguenti -valori di priorit\`a a seconda del tipo di applicazione: +valori di priorità a seconda del tipo di applicazione: \begin{table}[htb] \centering @@ -1130,9 +1129,9 @@ valori di priorit\`a a seconda del tipo di applicazione: \label{tab:priority} \end{table} -Per il traffico senza controllo di congestione la priorit\`a pi\`u bassa +Per il traffico senza controllo di congestione la priorità più bassa dovrebbe essere usata per quei pacchetti che si preferisce siano scartati -pi\`u facilmente in caso di congestione. +più facilmente in caso di congestione. \section{Sicurezza a livello IP} @@ -1140,40 +1139,40 @@ pi\`u facilmente in caso di congestione. La attuale implementazione di Internet presenta numerosi problemi di sicurezza, in particolare i dati presenti nelle testate dei vari protocolli -sono assunti essere corretti, il che da adito alla possibilit\`a di varie +sono assunti essere corretti, il che da adito alla possibilità di varie tipologie di attacco forgiando pacchetti false, inoltre tutti questi dati passano in chiaro sulla rete e sono esposti all'osservazione di chiunque si trovi in mezzo. -Con IPv4 non \`e possibile realizzare un meccanismo di autenticazione e +Con IPv4 non è possibile realizzare un meccanismo di autenticazione e riservatezza a un livello inferiore al primo (quello di applicazione), con -IPv6 \`e stato progettata la possibilit\`a di intervenire al livello del +IPv6 è stato progettata la possibilità di intervenire al livello del collegamento (il terzo) prevendo due apposite estensioni che possono essere usate per fornire livelli di sicurezza a seconda degli utenti. La codifica -generale di questa architettura \`e riportata nell'RFC 2401. +generale di questa architettura è riportata nell'RFC 2401. Il meccanismo in sostanza si basa su due estensioni: \begin{itemize} \item una testata di sicurezza (\textit{autentication header}) che garantisce - al destinatario l'autenticit\`a del pacchetto + al destinatario l'autenticità del pacchetto \item un carico di sicurezza (\textit{Encrypted Security Payload}) che - assicura che solo il legittimo ricevente pu\`o leggere il pacchetto. + assicura che solo il legittimo ricevente può leggere il pacchetto. \end{itemize} -Perch\'e tutto questo funzioni le stazioni sorgente e destinazione devono +Perché tutto questo funzioni le stazioni sorgente e destinazione devono usare una stessa chiave crittografica e gli stessi algoritmi, l'insieme degli accordi fra le due stazioni per concordare chiavi e algoritmi usati va sotto il nome di associazione di sicurezza. I pacchetti autenticati e crittografati portano un indice dei parametri di sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima -di ogni comunicazione ed \`e definito dalla stazione sorgente. Nel caso di -multicast dov\`a essere lo stesso per tutte le stazioni del gruppo. +di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di +multicast dovà essere lo stesso per tutte le stazioni del gruppo. \subsection{Autenticazione} -Il primo meccanismo di sicurezza \`e quello della testata di autenticazione +Il primo meccanismo di sicurezza è quello della testata di autenticazione (\textit{autentication header}) che fornisce l'autenticazione e il controllo -di integrit\`a (ma senza riservatezza) dei pacchetti IP. +di integrità (ma senza riservatezza) dei pacchetti IP. La testata di autenticazione ha il formato descritto in Tab.~\ref{tab:autent_head} il campo \textit{Next Header} indica la testata @@ -1185,10 +1184,10 @@ di sicurezza, e un numero di sequenza che la stazione sorgente deve incrementare di pacchetto in pacchetto. Completano la testata i dati di autenticazione che contengono un valore di -controllo di intgrit\`a (ICV, \textit{Integrity Check Value}), che deve essere -di dimensione pari a un multiplo intero di 32 bit e pu\`o contenere un padding +controllo di intgrità (ICV, \textit{Integrity Check Value}), che deve essere +di dimensione pari a un multiplo intero di 32 bit e può contenere un padding per allineare la testata a 64 bit. Tutti gli algoritmi di autenticazione -devono provvedere questa capacit\`a. +devono provvedere questa capacità. \renewcommand\arraystretch{1.2} \begin{table}[htb] @@ -1222,13 +1221,13 @@ devono provvedere questa capacit\`a. -La testata di autenticazione pu\`o essere impiegata in due modi diverse -modalit\`a: modalit\`a trasporto e modalit\`a tunnel. +La testata di autenticazione può essere impiegata in due modi diverse +modalità: modalità trasporto e modalità tunnel. -La modalit\`a trasporto \`e utilizzabile solo per comunicazioni fra stazioni +La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni singole che supportino l'autenticazione. In questo caso la testata di -autenticazione \`e inserita dopo tutte le altre testate di estensione -eccezion fatta per la \textit{Destination Option} che pu\`o comparire sia +autenticazione è inserita dopo tutte le altre testate di estensione +eccezion fatta per la \textit{Destination Option} che può comparire sia prima che dopo. \begin{table}[htb] @@ -1256,47 +1255,47 @@ prima che dopo. \end{pspicture} \end{center} -La modalit`\a tunnel pu\`o essere utilizzata sia per comunicazioni fra stazioni -singole che con un gateway di sicurezza; in questa modalit\`a +La modalit`\a tunnel può essere utilizzata sia per comunicazioni fra stazioni +singole che con un gateway di sicurezza; in questa modalità -La testata di autenticazione \`e una testata di estensione inserita dopo la +La testata di autenticazione è una testata di estensione inserita dopo la testata principale e prima del carico dei dati. La sua presenza non ha -perci\`o alcuna influenza sui livelli superiori dei protocolli di trasmissione +perciò alcuna influenza sui livelli superiori dei protocolli di trasmissione come il TCP. -La procedura di autenticazione cerca di garantire l'autenticit\`a del +La procedura di autenticazione cerca di garantire l'autenticità del pacchetto nella massima estensione possibile, ma dato che alcuni campi della testata di IP possono variare in maniera impredicibile alla sorgente, il loro -valore non pu\`o essere protetto dall'autenticazione. +valore non può essere protetto dall'autenticazione. Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una versione speciale del pacchetto in cui il numero di salti nella testata -principale \`e settato a zero, cos\`\i\ come le opzioni che possono essere -modificate nella trasmissione, e la testata di routing (se usata) \`e posta ai +principale è settato a zero, così come le opzioni che possono essere +modificate nella trasmissione, e la testata di routing (se usata) è posta ai valori che deve avere all'arrivo. -L'estensione \`e indipendente dall'algoritmo particolare, e il protocollo \`e -ancora in fase di definizione; attualmente \`e stato suggerito l'uso di una +L'estensione è indipendente dall'algoritmo particolare, e il protocollo è +ancora in fase di definizione; attualmente è stato suggerito l'uso di una modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche una chiave che viene inserita all'inizio e alla fine degli altri campi. \subsection{Riservatezza} \label{sec:ecry} -Per garantire una trasmissione riservata dei dati, \`e stata previsto la -possibilit\`a di trasmettere pacchetti con i dati criptati: il cosiddetto ESP, +Per garantire una trasmissione riservata dei dati, è stata previsto la +possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP, \textit{Encripted Security Payload}. Questo viene realizzato usando con una apposita opzione che deve essere sempre l'ultima delle testate di estensione; ad essa segue il carico del pacchetto che viene criptato. Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di quella mostrata in Tab~.\ref{tab:criptopack}, tutti i campi sono in chiaro -fino al vettore di inizializzazione, il resto \`e crittografato. +fino al vettore di inizializzazione, il resto è crittografato. \renewcommand\arraystretch{1.2} \begin{table}[htb] diff --git a/filedir.tex b/filedir.tex index 592440e..c071eca 100644 --- a/filedir.tex +++ b/filedir.tex @@ -583,7 +583,7 @@ riservati per estensioni come tempi pi \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[]{} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} struct stat { dev_t st_dev; /* device */ ino_t st_ino; /* inode */ @@ -692,7 +692,7 @@ memorizzato il tipo di files, mentre gli altri possono essere usati per effettuare delle selezioni sul tipo di file voluto, combinando opportunamente i vari flag; ad esempio se si volesse controllare se un file è una directory o un file ordinario si potrebbe definire la condizione: -\begin{lstlisting}{} +\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} #define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) ) \end{lstlisting} in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e @@ -775,10 +775,15 @@ dei relativi campi \begin{table}[htb] \centering \begin{tabular}[c]{|c|l|l|c|} + \hline + Membro & Significato & Funzione&opzione \\ + \hline + \hline \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, \func{utime} & \cmd{-c} \\ + \hline \end{tabular} \caption{I tre tempi associati a ciascun file} \label{tab:filedir_file_times} @@ -824,10 +829,13 @@ cambiarne i permessi ha effetti solo sui tempi del file. \footnotesize \begin{tabular}[c]{|l|c|c|c|c|c|c|l|} \hline - Funzione & \multicolumn{3}{c}{File o directory} - &\multicolumn{3}{c}{Directory genitrice} &Note \\ - Funzione & \multicolumn{3}{c}{di riferimento} & - \multicolumn{3}{c}{del riferimento} \\ + \multicolumn{1}{|c|}{Funzione} + &\multicolumn{3}{p{2cm}}{File o directory di riferimento} + &\multicolumn{3}{p{2cm}}{Directory genitrice del riferimento} + &\multicolumn{1}{|c|}{Note} \\ + \cline{2-7} + & \textsl{(a)} & \textsl{(m)}& \textsl{(c)} + & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}& \\ \hline \hline \func{chmod}, \func{fchmod} @@ -907,7 +915,7 @@ qual caso \var{errno} \end{prototype} La struttura \var{utimebuf} usata da \func{utime} è definita come: -\begin{lstlisting}{} +\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} struct utimbuf { time_t actime; /* access time */ time_t modtime; /* modification time */ @@ -916,18 +924,18 @@ struct utimbuf { L'effetto della funzione e i privilegi necessari per eseguirla dipendono da cosa è l'argomento \var{times}; se è \textit{NULL} la funzione setta il tempo -corrente e basta l'accesso in scrittura al file; se invece si è specificato un -valore la funzione avrà successo solo se si è proprietari del file (o si hanno -i privilegi di amministratore). +corrente ed è sufficiente avere accesso in scrittura al file; se invece si è +specificato un valore la funzione avrà successo solo se si è proprietari del +file (o si hanno i privilegi di amministratore). Si tenga presente che non è comunque possibile specificare il tempo di -cambiamento di stato del file, che viene comunque cambiato dal kernel anche -alla chiamata di \func{utime}; questo serve acnhe come misura di sicurezza per -evitare che si possa modificare un file nascondendo completamente le proprie -tracce. In realtà la cosa resta possibile, se si è in grado di accedere al -device, scrivendo direttamente sul disco senza passare attraverso il -filesystem, ma ovviamente è molto più complicato da realizzare. - +cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le +volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}). +Questo serve anche come misura di sicurezza per evitare che si possa +modificare un file nascondendo completamente le proprie tracce. In realtà la +cosa resta possibile, se si è in grado di accedere al device, scrivendo +direttamente sul disco senza passare attraverso il filesystem, ma ovviamente è +molto più complicato da realizzare. \section{Il controllo di accesso ai file} @@ -974,8 +982,6 @@ pertanto accesso senza restrizione a qualunque file del sistema. % elementare qui; inoltre ad un processo sono associati diversi identificatori, % torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}. - - \subsection{I flag \texttt{suid} e \texttt{sgid}} \label{sec:filedir_suid_sgid} diff --git a/fileintro.tex b/fileintro.tex index d0ca221..c9be147 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -125,7 +125,7 @@ questa sia la directory radice allora il riferimento Come detto in precedenza in unix esistono vari tipi di file, in Linux questi sono implementati come oggetti del \textit{Virtual File System} (vedi -\secref{sec:fileintro_vfs}) e sono presenti in tutti i filesystem unix-like +\secref{sec:fileintr_vfs}) e sono presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual File System è riportato in \ntab. @@ -292,7 +292,7 @@ una convenzione. \section{L'architettura della gestione dei file} -\label{sec:fileintro_architecture} +\label{sec:fileintr_architecture} Per capire fino in fondo le proprietà di files e directories in un sistema unix ed il funzionamento delle relative funzioni di manipolazione occorre una @@ -341,7 +341,7 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \centering \includegraphics[width=5cm]{img/vfs.eps} \caption{Schema delle operazioni del VFS} - \label{fig:fileintro_VFS_scheme} + \label{fig:fileintr_VFS_scheme} \end{figure} Il VFS definisce un insieme di funzioni che tutti i filesystem devono @@ -361,7 +361,7 @@ In questo modo quando viene effettuata la richiesta di montare un nuovo disco (o qualunque altro \textit{block device} che può contenere un filesystem), il VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco -il superblock (vedi \ref{sec:fileintro_ext2}), inizializzare tutte le +il superblock (vedi \ref{sec:fileintr_ext2}), inizializzare tutte le variabili interne e restituire uno speciale descrittore dei filesystem montati al VFS; attraverso quest'ultimo diventa possible accedere alle routine specifiche per l'uso di quel filesystem. @@ -435,9 +435,11 @@ previste dal kernel \begin{table}[htb] \centering - \begin{tabular}[c]{c p{7cm}} + \begin{tabular}[c]{|c|p{7cm}} + \hline \textbf{funzione} & \textbf{operazione} \\ \hline + \hline \textit{open} & apre il file \\ \textit{read} & legge dal file \\ \textit{write} & scrive sul file \\ @@ -562,7 +564,7 @@ adesso sar \subsection{Il filesystem \texttt{ext2}} -\label{sec:fileintro_ext2} +\label{sec:fileintr_ext2} Il filesystem standard usato da Linux è il cosidetto \textit{second extended filesystem}, identificato dalla sigla \texttt{ext2}. Esso supporta tutte le diff --git a/gapil.tex b/gapil.tex index dedffaa..91f93a0 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Feb. 2001 @@ -79,9 +79,10 @@ \lstset{basicstyle=\small, labelstyle=\tiny, labelstep=1, - labelsep=2pt, + labelsep=2pt, frame=TB, frametextsep=5pt, + indent=0.3cm, basicstyle=\ttfamily, keywordstyle=\color{blue}\ttfamily, ndkeywordstyle=\color{yellow}\ttfamily, diff --git a/img/environ_var.dia b/img/environ_var.dia new file mode 100644 index 0000000000000000000000000000000000000000..bd352e85b0bec7de9cb9dde1db996fb3d5cef228 GIT binary patch literal 1712 zcmV;h22c4PiwFP!000001MOT}Z`(E$e$THE+}D&6DN3T#Iz_t$=zw%7+U#K%21B-4 zTbnEylAO!Se)~vCiLIMsi=rAQ3{ay|j?dxc`#v5WGJ5~vZs}_`G>W}27!4pW1|QB( z-p@SujQyKO?owk0LCmj4gGG|8&UF3u_7?c}v73Yu@VzyNss5kq`>xK6^uhUwrfoZz zxrxi~<#*jAiM+`=p<3WB>1Z%cojxTIPY)BwEw2w+WVcESRT{!~?`f2~ z|Fl`6w0w+n;%|*YIQfT8le~N16E~Q-(M)@*eG2aen+4VwXx?lzxH5{vQ|=IR#ssJ` zKCAF?9?er!?rwD+n_N#OWzP|7yBo}X`k6#5w0431bL{7qn6kOwgca_n~&urR?qCckVKH{pX(idq)Ml1pdl;Wv8puX5n+(j#pCyLlV8Ghq@IF7yDlmEb*>Lt;RiuqcQi zlP`%TCMM!h`StTxgo{iOI83y3} zHCJ}Fa%BknNtTI9mS0%1Tn~NR0raJ=j2ZY5ur}Z~`KM&?x9yXH|53r;5{G~5**pOL zCV<=UC$ix$hEN6nV}ZZj1^h`5@OL)w#{kQRKT+_11@L#o;g6-32{ZU(U~b@VwVr`} z(cijD&jS5zwc$15pNQk1!LjX#AHaYu^xKlrFVG>S{>QaXG!%vZ5ZDYaG8cd$FrbAv zDARo+XaGns2kDV)6#f3k<)zvsYF7iUpi9+&rS2LVUC4plZ6X4ogNXgOO~h7313Bh+28Ma8`^ecnB@yi^x0(=Z6eG?=BWKd4XjJ8msI&0sNI zm7~|4Mn1%;&*pcJr{R`OW`j0%qbR&BJKta&33?v;G??#hy>N&p$7jz797qhKj7f22 zm3jD$wqV@jr=l6vk}y5rtZjZf8sG}LYQ78e@0!K$n$=_7r3Q7BL6}`UVaPq0N?77R z9?zvh0}LTLx^t<28GoyyL;Hscbu_iVhYH+|lIkmOI%V_WDQ#$3UZ{ZWCCG#E zeC5IJL>^4J;(#{ULaq%*lP-Myc>Q^Frcb=!Okc+l|BuoJ0c|jqGW1k<6h6wv57CvzeQwQ`=e`J?fat*TDy*kKp3#0WBGF6Fum6b@du@c!$HL;2Eq$A1?`=GpI zK!P*MV~77e1HbNv^TVB-hhR7yI^3*%ixlx+CGqi3BL1)w;+w#dPkfWDr$ypBeG$LV zzh>eyGevww{DX*Z{T$*WqZ8s|0Q(?5TTc;rBtGUsfJh(2FZ8dO_?YJ)ZCj*>|0;=Z z|0LqWj)?C-)Wf2Wfdx$`<357ya>y_Hp?JF|Ap9@P(Qzol#jn3zUws?Vr8|w4EC|Q~F22-S$$~^#z#Yi~ku3{2J2J%c z1>_LSLmr1LTz$X(^XtWkrR?jwxAS1Fq(Mj;h?0gwr6IdcUm<^fQh3Mw`N{vAugw~A GWdHy!Dqao% literal 0 HcmV?d00001 diff --git a/img/iso_tcp_comp.dia b/img/iso_tcp_comp.dia new file mode 100644 index 0000000000000000000000000000000000000000..feeb0dd1bdcba97665ed2726c55294f980ce7d2e GIT binary patch literal 1945 zcmV;K2WI#miwFP!000001MQt(bDKC2z~A#JJnpM2BZ)tvY0|k~UpjYl?Oghvk!{uH ziopX)lib67_LG3r#>PpCSQ1iYCY}MyyOvn(PrIz}+jlqXc=TOld6Xt+V~m{fyYrK` zi-^Bb|I3W8N2)=R>!Y*rO3KZf>Gb;g8pXFcmuZIL=nCax`X7&DK2?pT7U8_)Rs+cHb9lEt`eRkfR^ahi?3^Z0E1>TB^go>pR}H97al z-tdjc_QkF@X&$L2@^*93Qj!0Tn&881^e81gedr+R*gH)j+=C>lN#J}I- zX;h7IHR*RoA)Wmr=CbPEh2+VCXN%G6(fjmfyoIYX9z~0@@h7J~Jo_C|!j$tl7@tkL zy^drO?)UfbLLQSno9&Cv)R*VUG8UD1j6!e1)XOPxkmF6%3CC-vP{d+=IZw0X5VDGfs9%I9IiG*89p)(TsjB{nrnI-!78NwiVw zm(#)=Cmyg(w(gBJ$rdL0Mcl{+no3_w-4F-s~yQibNE!WbG=${x0?qTsA*+aU|9?qG$TZfHgN2&$B2YFym~ zRZ8hFX!Vzn*J<|6vdV;2#ImXUKs!0;s%*w$1$J*>JZs=zKVtQ_nx zy?`oU6(Wa)L@ONztUhq5D|;=ijA&(RDte<;2SpVays854lvQB(x(aLyE1sTK-Bea! zzZY70bz1oYq1ETrZ63{eY-wdeD_d648?C$!wop*;Efi$Cg(8ICK{3$K%700)GOn#q zPQ>v-23!fKqAC(ncUua`5F1C+g?C~t@XVk=m!6tg?hu*v zXOxJh&A|hBkOB*I?W%g!wuy;O1gO_`I_GJUT#95-bl~ybI((lvZM&@;)_k+Cx#{^L zKO;0&m-nGL;h@KknjR%}8I+~u2TZ?vXS7nbr61&>Oi89?LTR*p`)uqT3}3^C@sSS) zhtDF}`$`?zKYs3o+gs~bQ=u>Gr}rB_#@6`j#&2T#(58Rvxe%nIaK(Ynv(*a3F|!ro zzhuB-OT@bmSdO^{+Eor7dx&_j$&4^`ilQbTm&puFLRaf`@esVjpSHlsIQ_n7WY#x; z`Udl2k_l`XiRbvrA*j`X8{kuh+>o*fL0BI?e}C}l;^Xw=#iu@9!k1_*^4EW-Yo5G} zN|K3PDD>qF%!^2TP;a2nfQd_gxC4a@6-o!g@dqE$57rl$ED@|T=-e3`%cU7t?hp){ zOmlW~$zgBVw0gH1-Va}5I;|tZ7#DmH;O9SKN;$q@2acgAv_W; zor^qAPt=DJDPAyb0%+RQP0i8<)G@FQ90Tl=3@{2^ugFwu*PuOvpRfZQwqeV12 zQEH+jn)83vb+8Ku6F*TmJnJVQ{RDM7@Drf>bUlQffKA-HkU~YQA<<8r9!^NH>n3=) z)5LlSb1z|UbM=(WqPPPm;X^tJAL$?P33VzfKt=Vg1E0yN^{JU-WN@jhww2Dg4Lh<-?h8=$QU*9L&R~h z(mIe$`*}M5CTt~f%K)m;$ZQ-1x?nLb7o@No%t)vgE7~KR(jtV?I}M<>*F3Pfj1F;g fnPW-ZDT&MD;&-&qPijB3eSY#k5ut5nbAkW>q|eE? literal 0 HcmV?d00001 diff --git a/img/proc_exit.dia b/img/proc_exit.dia new file mode 100644 index 0000000000000000000000000000000000000000..b2f2e820e546f7c00f208b3e9278f3871e3845d3 GIT binary patch literal 2724 zcmV;V3S0FbiwFP!000001MOXHZ=*;O{yx6~dA>3o`n_3iW_2^GlU8@qtu%Z0HNrM= zxWQlnNhV+Jw_i7Sl9(48)7`|eh?H26b{EyuQ%})d)%^O~k4@}6gjpV?$@L5ZZ}!{g z55KOW;1~J3&Vr328zi|px}Mz?#rBu0tH;Mj5I^NXk!B!{?m-@2{V#~);7T^SntlG@ zIIlZc1x29F?al^8kwuI9B6N~q6JF02!See$OYf7_tZKDuw@l+Sa~^{DdiL?Q{Fzj!jZa3RBk7SeLY1?Sh(U1E3s?DxdE*mB5&maFrK312sJMq$2+l6)t zDK5+5wU#{nSBvaezQ%pA`7CTDQ1zTaTp|(q$0Zy zhs(*AK`c$?kScI^@3&D=q(`p*Hi+{+3RI_`(Q_&i*IBeW48*+_9lbn8tK#nFho#}F zdVjLi`$LpRi#Tk%`Y0)kb^oNFDWh*X-(;;`MfYHK;B6NJvqBE-huwrD5Q)3hRb57-nSx1RzbFMJ~>~~AF~&7^=3}Ax}N>Z+aI2~ zLb5aId>Z4kO`q?h=hC{m&HLEZ^^SSPr-g#o%G@1u`kb6UZ;+cmmHUAdo}oO1L3T`OrI&BsXEQDwR1^#bzt% z0|ufdx!)|eb@^>E-bqkQRyRSGrH}QFLn&^Da?PG^;xJhs1|!uKaTM-7C8(P%ZA#jH zUhC}TKhB**i;4y%IEqw)1J9h7|6b2nGbF8b+JQ;sQMP-Ra~cQYW1)2urcL{V0J@L? zjVF=@RNKJ{OSmxkSK_onj)u^7I<%o)D={`K4g+6PM1voj52e7T8dDIRM5Zy_(X{L% zmi$-vqi8W@V#1Uwhs*)CZp#Qjj)XES#weX*AUH=#G?9nHr59>&8nWw;)s0qNH@uvs zthKC7Y2MxD9dnuoufBUGDou)ZiRwSQMqktWERwjr(v{W%nPV~2P*HW;>urC-#Fdlc z?E+uVmwV-pzPKQc*2yO9x_2+J0X#ug>-@|~zN9+yiYAAIvQ#&e<-qp^l<<~5UI@G4 zER|twDTp9Am!T!We(7f9d1g7B?NYPN&e4v^r@;220$YUkBU^81WP2h+nJz?yvRzu) zE+^0;MmeB_lM16qh`FyY%1ex5h-_oDQ_q&BwXk;r=p_KO_UMTl7SQr#xcf4s`(K75 zp_}WX8_EYC->;0G*_=;Of+(rrg(08IPa-+71UG`hGPt|cY-x#i&(agVFAU#A2jBc{ z@GZ3QjTDhvCPUeZ;ivb7|nM$Iome{6XzJA~?!wtfV*Uc~Akd44h>w zI|dkGzjauMCq!NxBKaF3Qak%d#dkKRk|70D5VaWL%TE>OdIYj6F@h7@h}>7Mr2(6; zcyUu#HL#M*s<8GXx|6!*V)=Q4h~ms*)(h5_vdGY%TGqUvg6a)TF({ zq%U#0{O+v6hiDl(i~HN#Fmsl{@-FO5S2~o5(lb@5SEACXa$1v=j-@D_Dx{g7)YtBY zNNdYZ>Xn;xs-UjCq{CTB-AQ-t8A+%33*DSuNKIrqvgZ1qrA$Y*OWB3qNC~?JRGTt( zN66TP%!DC}aq@K;5W*wR`MN&vn9ts0zOL*FO$ocE5_ZLut!q77SDP@okt&z*%3NO6 zxxg_CU8YKx_raUOh&_*2>mm({5Xzp(6B58YLf#{LW?__v*~Fiw_!CYQFYkjxeIq`H zJu{nqr=$GM9CvnPCC?D=pT6ccwE z^m!sEdpR)=-lKrbmrrn zs=VEys;BBS({;#c0$TG@H0z9e=BJKMxda&pr9r}(Rk<{IHzYMmqewqQ+31buZj79mixb<-I7>YR#QeK z?`=u!KY#x=&FLAN(`&WBX;yEn9pF0V>$EqZA+FtR-+b!wa%PT~t5Cx?tL|4(Fj$>l z1qIk=U+_l?I|z9jq^2# zW9N^g2(#N@ITaG<6%sV8ZYm_Ox*@-Bq|6nmjGdwNYW*tDy;6wB$z1KkPe-b9Z79~& zZrW1m!s^bkMx876-lWbIYwzeX+>m?L4yrm=QpTiZW)$LK|`g;~V9LPzYg3(@8t#xagf>Dd_ zUc*TLuCFN1hpc3Euey*=A@c?A7EXIyC8BY34p z@Yq~FGJN+#;~{5k8-EM10qo;vbNNii*D z4&&Icjz>5fp@+cSqy9qgvDFVZA zmw<`@6OzEB*!=|5vt9g%^6$=9$tqbI$J6r1Py%Z=w~4(*-O>}A*qwM9R7WRKu zfm4@_v%89xZvD1ZLDn}_!S8)Xl|R$?X`Lo5CQQt1s#2R2wqwH5t#Ti`bQhjM$|NSnwyq7q+=?!w4g^@U{{>IDcRYGia;Z~AG`a{YF6xwmYz~=n=!9;`u9h1 zm3q3Ji>pKz>?)B76IS+Q-Gqtql*o6HP*&`ht`e$e2IVa6`^vhGE%Pr&TkyRH;elcu#KI5H)LC# zXh)U|N$zy^VZVJy+wt92B3|6?RDc+eO&3K;y zZ`;5mX%h9`>fNMis%$iGQm;s+>0NJ>jQ@P7%6T#AEnBVHjmx~Oyl+W<*Zc5w@z=Xu znYrDubH?^8nWfdf+3BpTGufnho*gtfVMo1gwOO^QWuxNZ{=?sb56e?py|J-%>_ks? z(oB=;AuA61snR50P6Q=_Qu;CvZ|`Dczl+>{7nS`kvU)fxtENh_=CGSlS>|a{EPHCI zdD^|7dYt6)mN_>R=x+UM)-+|y`F~CF`ZWVszP(;OZ(WHGRW>=l5O-Rfu=12mn#bXH zOVhQq{%pzmx2(=ad3x;Zv!XF({#nz!?scALleBKR(z|U=SbAJFyKNize!JI>VENXb zlUj6`FrsHNcyg!^Nhkf-j5X2Arp?vAq zTbifS;kc}dLkDYOFbngGHG4Rqm-WguOh2aC!((&WHtS}4R92I;YCCbCKsWRCWBD{Z z5>vJNuDA5EysE=0nPl_&+$h>6Y5C@I{k&p9{VOZdBP$AYSCqWXEv~45uzo<|K}e#0 z)b+xS%c2;j#bj~TuO7>>kE3oUP|T;}*?zyre9K#m%IGI;Uke=(qHdC^875U#KJ8mi zzw{BtiH>3zYB+f%-#vT5i-A|-G2D+ zK~i{SFGo3ynGotYCt>=WB(lv(_?nY|Z=IAxNJ@~DXpxdY-@}4$nU%yVRsz%kEdl>L zF9C|g1c?a}6NAKrX%G{B8DbLZ!=|uHOacNC6|$ElF$syF5tWBmLQKAV`izvMDTPuMVu>@SGCD0<50O}=3OOTeBq$ON~ zmc*B#CBgu1GTXc)fRL(g6fuzi8j3)uLq$w}d|vWTq$Qnc37}NsjF-d)c!_nb1U6y` zwJ(+cswK!vG*h^IeFsZz%O&ulmrxga32o6!DC#9hOputEBqs4mVq%qCfPMlifj$Vr z1P6;4$cWEz+$RUk;%g!pJDvHc}%6#Yi=f0Ca(d~jgEBV*u937!y@GX z?QBhIw`PQHibklLsu3(3LC&GgIrOt0?G}#Em&y_9rgVh1)Q(Ur9zo85oWm^Vkj}lk z8Uo>Et(l?tZ)>cvDWxUhY0K9lf0b=1?D)g#%y~FTfmI z2WHU<%mRTKff<4MYJi#P0CRXDVCMS33@$=uSjWs@KWK*bs2MP9Ms!AWz8-YuI_NAe zgwBxxbaoLp!#Z#V`;jxWht7bpGomx1^Yx%}tbxw^k`!|#Nol9%L)d3FpRDSWD4?QG z3FAQo1BeL?BemlT>iEZ(qGnaul;bkbOK*~S$!wNqrjz0qDY;>h}Zx|2)h_TDX51vtuZ2s1XGoL*MSjVs-&J~wVHPClU%e_nR}mC zxPd64g%Sc$!VO9=-vCO0)lh;G${1JAN>Dg4P}wb<2aB|Nd3*(F^hLACYC&u;gAITo zge!0W6X0MqhF~NNgGGJf5*#=Qf{>|QnCk$Cmy|ce1U*c^fWb5-d@l3n6Pv?KyC@*) znt%2xRNzEC%`T3kFc?sY5Pg*yOQVia%1lnguyu2IXGF(7rtJLAF^PT77ia3XG-X{U z@A8|$S6^dr-J8MeJ!}RWihY=Y*oOvoiBTv*P>}ILi~KPJEkL_2Ul4X zX;GPt?R#Tk-5U!x-Z(Vyqq0_i?n(F&7kz)>ihVxd1Om!vAFf5r_>^Z7lHL2@k7Yjj zS$dFy*MlcFo*)) zj|hb;*aE7{@t~0l!w<9&c!a0C4_@yiMQ$x%i}zGPOJNy<$?THKOTC2 N^B1u0#l_>d003*Jdy)VE literal 0 HcmV?d00001 diff --git a/img/tcpip_overview.dia b/img/tcpip_overview.dia new file mode 100644 index 0000000000000000000000000000000000000000..a65f4170a747ab664d92e0e33e7eb92eedf1c6d5 GIT binary patch literal 378 zcmV-=0fqh_iwFP!000001GSaij)E`{h3|a|Qtzpfz1TH^*?kc+NX5yPmb8P&%|830 z)Kyf_mDmIlCMVySA10kIcA50H!dTQQWK(~_7SU*)Ak69~HIR9=K-v9Q$TmdzjPtTA zeOXx`ZG4G^Zw3DWDS_7_&Z3d$odXge*vDKHhz!OB2~R;LLKeg7J2kpc32RhNx6)D@ zZwoSH0#%P3v-Fha&57eP?cXvIyn3HnZ~JXEmCPT{(KuZDY?Ljbt}n+eOb8W}~(zQ*jwG^NlCo+Y2-p8&$ z*1t?&DbwfaYb4Tl@?V3rj}*{^|F-A9o0u9*`WLaK=%AFC&}O;oYuCgd(6EMI_46km zhx5G47A?k7+^Pc=4W9ZDUk$_$op^zXuy Date: Thu, 19 Jul 2001 17:47:12 +0000 Subject: [PATCH 15/16] Aggiunte altre figure, e materiale vario a spasso. --- filedir.tex | 263 ++++++++++++++++++++--------------------- fileintro.tex | 97 +++++++++------ gapil.tex | 2 +- img/dir_links.dia | Bin 0 -> 2847 bytes img/dir_struct.dia | Bin 0 -> 3191 bytes img/disk_struct.dia | Bin 0 -> 2135 bytes img/filesys_struct.dia | Bin 0 -> 4893 bytes img/memory_layout.dia | Bin 0 -> 1231 bytes process.tex | 26 ++-- 9 files changed, 207 insertions(+), 181 deletions(-) create mode 100644 img/dir_links.dia create mode 100644 img/dir_struct.dia create mode 100644 img/disk_struct.dia create mode 100644 img/filesys_struct.dia create mode 100644 img/memory_layout.dia diff --git a/filedir.tex b/filedir.tex index c071eca..b7a2bb9 100644 --- a/filedir.tex +++ b/filedir.tex @@ -2,14 +2,118 @@ \label{cha:files_and_dirs} In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono -files e directories, ed in particolare esamineremo come è strutturato il -sistema base di protezioni e controllo di accesso ai files, e tutta -l'interfaccia che permette la manipolazione dei vari attributi di files e -directories. Tutto quello che riguarda invece la manipolazione del contenuto -dei file è lasciato ai capitoli successivi. +file e directory, ed in particolare esamineremo come è strutturato il sistema +base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che +permette la manipolazione dei vari attributi di file e directory. Tutto quello +che riguarda invece la manipolazione del contenuto dei file è lasciato ai +capitoli successivi. -\section{La gestione di file e directory} + +\section{Il controllo di accesso ai file} +\label{sec:filedir_access_control} + +Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella +del controllo di accesso ai file, che viene implementato per qualunque +filesystem standard. In questa sezione ne esamineremo i concetti essenziali e +le funzioni usate per gestirne i vari aspetti. + + +\subsection{I permessi per l'accesso ai file} +\label{sec:filedir_perm_overview} + +Il controllo di accesso ai file in unix segue un modello abbastanza semplice, +ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre +livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di +tipo unix, e non è detto che sia applicabile a un filesystem +qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows, + per il quale vengono assegnati in maniera fissa con un opzione in fase di + montaggio}. Esistono inoltre estensioni che permettono di implementare le +ACL (\textit{Access Control List}) che sono un meccanismo di controllo di +accesso molto più sofisticato. + +Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto +\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli +identificatoti di utenti e gruppi (uid e gig) già accennato in +\secref{sec:intro_multiuser}, e un insieme di permessi che sono divisi in tre +classi, e cioè attribuiti rispettivamente al proprietario, a qualunque utente +faccia parte del gruppo cui appartiene il file, e a tutti gli altri utenti. + +I permessi sono espressi da un insieme di 12 bit: di questi i nove meno +significativi sono usati a gruppi di tre per indicare i permessi base di +lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere +\textit{w}, \textit{r} \textit{x} nell'output di \cmd{ls}) applicabili +rispettivamente al proprietario, al gruppo, a tutti (una descrizione più +dettagliata dei vari permessi associati ai file è riportata in +\secref{sec:filedir_suid_sgid}). I restanti tre bit sono usati per indicare +alcune caratteristiche più complesse (\textit{suid}, \textit{sgid}, e +\textit{sticky}) su cui pure torneremo in seguito (vedi +\secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}). + +Tutte queste informazioni sono tenute per ciascun file nell'inode, in +opportuni bit del campo \var{st\_mode} della struttura letta da \func{stat} +(vedi \figref{fig:filedir_stat_struct}) che possono essere controllati con i +valori riportati in \ntab. + +\begin{table}[htb] + \centering + + \caption{I bit deipermessi di accesso ai file, come definiti in + \texttt{}} + \label{tab:file_bit_perm} +\end{table} + + +% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid +% confrontandoli con quelli del file e se l'operazione richiesta è compatibile +% con i permessi associati al file essa viene eseguita, altrimenti viene +% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non +% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale +% a +% pertanto accesso senza restrizione a qualunque file del sistema. + +% In realtà il procedimento è più complesso di quanto descritto in maniera +% elementare qui; inoltre ad un processo sono associati diversi identificatori, +% torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}. + + +\subsection{I flag \texttt{suid} e \texttt{sgid}} +\label{sec:filedir_suid_sgid} + +\subsection{La titolarità di nuovi files e directory} +\label{sec:filedir_ownership} + + +\subsection{La funzione \texttt{access}} +\label{sec:filedir_access} + + +\subsection{La funzione \texttt{umask}} +\label{sec:filedir_umask} + + +\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} +\label{sec:filedir_chmod} + +\subsection{Il flag \texttt{sticky}} +\label{sec:filedir_sticky} + +\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} +\label{sec:filedir_chown} + + + + +%La struttura fondamentale che contiene i dati essenziali relativi ai file è il +%cosiddetto \textit{inode}; questo conterrà informazioni come il +%tipo di file (file di dispositivo, directory, file di dati, per un elenco +%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi +%\secref{sec:file_times}). + + + + +\section{La manipolazione di file e directory} Le prime funzioni che considereremo sono quelle relative alla gestione di file e directory, secondo le caratteristiche standard che essi presentano in un @@ -26,13 +130,13 @@ ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link}, ma data la struttura del sistema ci sono due metodi sostanzialmente diversi per fare questa operazione. -Come si è appena detto l'accesso al contenuto di un file su disco avviene -attraverso il suo inode, e il nome che si trova in una directory è solo una -etichetta associata ad un puntatore a detto inode. Questo significa che la -realizzazione di un link è immediata in quanto uno stesso file può avere tanti -nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo -stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una -particolare preferenza rispetto agli altri. +Come spiegato in \secref{sec:fileintr_architecture} l'accesso al contenuto di +un file su disco avviene attraverso il suo inode, e il nome che si trova in +una directory è solo una etichetta associata ad un puntatore a detto inode. +Questo significa che la realizzazione di un link è immediata in quanto uno +stesso file può avere tanti nomi diversi allo stesso tempo, dati da +altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di +questi nomi viene ad assumere una particolare preferenza rispetto agli altri. Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si suole chiamare questo tipo di associazione un collegamento diretto (o @@ -43,39 +147,21 @@ principali, come risultano dalla man page, sono le seguenti: Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath} dandogli nome \texttt{newpath}. - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore. La variabile \texttt{errno} viene settata secondo i seguenti - codici di errore: + La funzione restituisce zero in caso di successo e -1 in caso di errore. La + variabile \texttt{errno} viene settata opportunamente, i principali codici + di errore sono: \begin{errlist} \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo stesso filesystem. \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e \texttt{newpath} non supporta i link diretti o è una directory. - \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori - dello spazio di indirizzi del processo. - \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o - per attraversare le directories), vedi \secref{sec:filedir_access_control} - per i dettagli. - \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo. - \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath} - non esiste o è un link simbolico spezzato. - \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath} - non è una directory. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di già. \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi \secref{sec:xxx_limits}). - \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione - di \texttt{oldpath} o \texttt{newpath}. - \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha - spazio per ulteriori voci. - \item \texttt{EIO} c'è stato un errore di input/output. \end{errlist} + \end{prototype} La creazione di un nuovo collegamento diretto non copia il contenuto del file, @@ -112,28 +198,14 @@ effettua con la funzione \texttt{unlink}; il suo prototipo qual caso il file non viene toccato. La variabile \texttt{errno} viene settata secondo i seguenti codici di errore: \begin{errlist} - \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o - per attraversare le directories), vedi \secref{sec:filedir_access_control} - per i dettagli. - \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory + \item \texttt{EISDIR} \var{pathname} si riferisce ad una directory (valore specifico ritornato da linux che non consente l'uso di \texttt{unlink} con le directory, e non conforme allo standard POSIX, che prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia consnetita o il processo non abbia privilegi sufficienti). - \item \texttt{EFAULT} la stringa - passata come parametro è fuori dello spazio di indirizzi del processo. - \item \texttt{ENAMETOOLONG} il pathname troppo lungo. - \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link - simbolico spezzato. - \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory. - \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola - lettura. - \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del - pathname. - \item \texttt{EIO} errore di input/output. + \item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola + lettura. + \item \texttt{EISDIR} \var{pathname} fa riferimento a una directory. \end{errlist} \end{prototype} @@ -523,6 +595,7 @@ per cambiare directory di lavoro. \end{prototype} + \section{La manipolazione delle caratteristiche dei files} \label{sec:filedir_infos} @@ -693,7 +766,7 @@ effettuare delle selezioni sul tipo di file voluto, combinando opportunamente i vari flag; ad esempio se si volesse controllare se un file è una directory o un file ordinario si potrebbe definire la condizione: \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} -#define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) ) +#define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG)) \end{lstlisting} in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e poi si effettua il confronto con la combinazione di tipi scelta. @@ -763,6 +836,7 @@ dipende dall'implementazione: il file pu fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con zeri (e in genere si ha la creazione di un hole nel file). + \subsection{I tempi dei file} \label{sec:filedir_file_times} @@ -889,7 +963,7 @@ cambiarne i permessi ha effetti solo sui tempi del file. \end{table} Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di -creazione del file usato da molti altri sistemi operativi, che in unix non +creazione del file, usato da molti altri sistemi operativi, che in unix non esiste. @@ -938,82 +1012,3 @@ direttamente sul disco senza passare attraverso il filesystem, ma ovviamente molto più complicato da realizzare. -\section{Il controllo di accesso ai file} -\label{sec:filedir_access_control} - -In unix è implementata da qualunque filesystem standard una forma elementare -(ma adatta alla maggior parte delle esigenze) di controllo di accesso ai -files. Torneremo sull'argomento in dettaglio più avanti (vedi -\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei -concetti essenziali. - -Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix, -e non è detto che sia applicabile (ed infatti non è vero per il filesystem di -Windows) a un filesystem qualunque. Esistono inoltre estensioni che permettono -di implementare le ACL (\textit{Access Control List}) che sono un meccanismo -di controllo di accesso molto più sofisticato. - -Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto -\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e -gid accennato in \secref{sec:intro_multiuser}, e un insieme di permessi che -sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario, -a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti -gli altri utenti. - -I permessi sono espressi da un insieme di 12 bit: di questi i nove meno -significativi sono usati a gruppi di tre per indicare i permessi base di -lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere -\textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al -proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari -permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}). I -restanti tre bit sono usati per indicare alcune caratteristiche più complesse -(\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in -seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}). - -Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un -processo cerca l'accesso al file esso controlla i propri uid e gid -confrontandoli con quelli del file e se l'operazione richiesta è compatibile -con i permessi associati al file essa viene eseguita, altrimenti viene -bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non -viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale ha -pertanto accesso senza restrizione a qualunque file del sistema. - -% In realtà il procedimento è più complesso di quanto descritto in maniera -% elementare qui; inoltre ad un processo sono associati diversi identificatori, -% torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}. - -\subsection{I flag \texttt{suid} e \texttt{sgid}} -\label{sec:filedir_suid_sgid} - - - - - - -\subsection{La titolarità di nuovi files e directory} -\label{sec:filedir_ownership} - -\subsection{La funzione \texttt{access}} -\label{sec:filedir_access} - -\subsection{La funzione \texttt{umask}} -\label{sec:filedir_umask} - -\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} -\label{sec:filedir_chmod} - -\subsection{Il flag \texttt{sticky}} -\label{sec:filedir_sticky} - -\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} -\label{sec:filedir_chown} - - - - -%La struttura fondamentale che contiene i dati essenziali relativi ai file è il -%cosiddetto \textit{inode}; questo conterrà informazioni come il -%tipo di file (file di dispositivo, directory, file di dati, per un elenco -%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi -%\secref{sec:file_times}). - diff --git a/fileintro.tex b/fileintro.tex index c9be147..2bcfe81 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -339,7 +339,7 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \begin{figure}[htb] \centering - \includegraphics[width=5cm]{img/vfs.eps} + \includegraphics[width=7cm]{img/vfs.eps} \caption{Schema delle operazioni del VFS} \label{fig:fileintr_VFS_scheme} \end{figure} @@ -435,7 +435,7 @@ previste dal kernel \begin{table}[htb] \centering - \begin{tabular}[c]{|c|p{7cm}} + \begin{tabular}[c]{|c|p{7cm}|} \hline \textbf{funzione} & \textbf{operazione} \\ \hline @@ -487,31 +487,39 @@ daremo una descrizione a grandi linee che si adatta alle caratteristiche comuni di un qualunque filesystem standard unix. Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni -partizione può contenere un filesystem; quest'ultimo è in genere strutturato -secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a -disposizione per i dati e le directory. +partizione può contenere un filesystem; la strutturazione tipica +dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento +alla struttura del filesystem ext2, che prevede una separazione dei dati in +\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di +ext2 torneremo in \secref{sec:fileintr_ext2}). È comunque caratteristica +comune di tutti i filesystem unix, indipendentemente da come poi viene +strutturata nei dettagli questa informazione, prevedere una divisione fra la +lista degli inodes e lo spazio a disposizione per i dati e le directory. \begin{figure}[htb] \centering - + \includegraphics[width=9cm]{img/disk_struct.eps} \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} \label{fig:fileintr_disk_filesys} \end{figure} -Se si va ad esaminare come è strutturata l'informazione all'interno di un -singolo filesystem (tralasciando le parti connesse alla strutturazione e al -funzionamento del filesystem stesso come il super-block) avremo una situazione -del tipo di quella esposta in \nfig. +Se si va ad esaminare con maggiore dettaglio la strutturazione +dell'informazione all'interno del singolo filesystem (tralasciando i dettagli +relativi al funzionamento del filesystem stesso come la strutturazione in +gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo +esemplificare la situazione con uno schema come quello esposto in \nfig. + \begin{figure}[htb] \centering - - \caption{Organizzazione di un filesystem} + \includegraphics[width=11cm]{img/filesys_struct.eps} + \caption{Strutturazionne dei dati all'interno di un filesystem} \label{fig:fileintr_filesys_detail} \end{figure} -da questa figura si evidenziano alcune caratteristiche su cui è bene porre -attenzione in quanto sono fondamentali per capire il funzionamento delle -funzioni che manipolano i file e le directory su cui torneremo fra poco; in -particolare è opportuno ricordare sempre che: + +Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su +cui è bene porre attenzione in quanto sono fondamentali per capire il +funzionamento delle funzioni che manipolano i file e le directory su cui +torneremo in seguitp; in particolare è opportuno ricordare sempre che: \begin{enumerate} @@ -530,38 +538,44 @@ particolare numero di riferimenti (\textit{link count}) che sono stati fatti ad esso; solo quando questo contatore si annulla i dati del file vengono effettivamente rimossi dal disco. Per questo la funzione per cancellare un - file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del + file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del file, ma si limita a eliminare la relativa voce da una directory e decrementare il numero di riferimenti nell'\textit{inode}. \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode} nello stesso filesystem e non ci può essere una directory che contiene riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita - l'uso del comando \texttt{ln} (che crea una nuova voce per un file - esistente, con la funzione \texttt{link}) al filesystem corrente. + l'uso del comando \cmd{ln} (che crea una nuova voce per un file + esistente, con la funzione \func{link}) al filesystem corrente. \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto del file non deve essere spostato, viene semplicemente creata una nuova voce per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità - in cui opera normalmente il comando \texttt{mv} attraverso la funzione - \texttt{rename}). + in cui opera normalmente il comando \cmd{mv} attraverso la funzione + \func{rename}). \end{enumerate} Infine è bene avere presente che essendo file pure loro, esiste un numero di riferimenti anche per le directories; per cui se ad esempio a partire dalla -situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir} -nella directory corrente avremo una situazione come quella in \nfig, dove per +situazione mostrata in \curfig\ creiamo una nuova directory \texttt{img} nella +directory \file{gapil}: avremo una situazione come quella in \nfig, dove per chiarezza abbiamo aggiunto dei numeri di inode. +\begin{figure}[htb] + \centering + \includegraphics[width=11cm]{img/dir_links.eps} + \caption{Organizzazione dei link per le directory} + \label{fig:fileintr_dirs_link} +\end{figure} + La nuova directory avrà allora un numero di riferimenti pari a due, in quanto è referenziata dalla directory da cui si era partiti (in cui è inserita la -nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.} +nuova voce che fa riferimento a \file{img}) e dalla voce \file{.} che è sempre inserita in ogni directory; questo vale sempre per ogni directory che non contenga a sua volta altre directories. Al contempo la directory da cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto -adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}. - +adesso sarà referenziata anche dalla voce \file{..} di \file{img}. \subsection{Il filesystem \texttt{ext2}} \label{sec:fileintr_ext2} @@ -591,7 +605,7 @@ sono le seguenti'' sottodirectory ereditano sia il group id che il setgid. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione, a seconda delle sue esigenze (blocchi più grandi - peremttono un accesso più veloce, ma sprecano più spazio disco). + permettono un accesso più veloce, ma sprecano più spazio disco). \item il filesystem implementa link simbolici veloci, in cui il nome del file non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando letture multiple e spreco di spazio), non tutti i nomi però possono essere @@ -604,27 +618,32 @@ sono le seguenti'' \end{itemize} La struttura di ext2 è stata ispirata a quella del filesystem di BSD, un -filesystem è composto da un insieme di blocchi, la struttura generale è -riportata in \nfig; su ciascun gruppo di blocchi contiene una copia delle -informazioni essenziali del filesystem (superblock e descrittore del -filesystem) per una maggiore affidabilità e possibilità di recupero in caso di -corruzione del superblock principale. +filesystem è composto da un insieme di blocchi, la struttura generale è quella +riportata in \figref{fig:fileintr_filesys_detail}, in cui la partizione è +divisa in gruppi di blocchi. + +Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del +filesystem (superblock e descrittore del filesystem sono quindi ridondati) per +una maggiore affidabilità e possibilità di recupero in caso di corruzione del +superblock principale. + \begin{figure}[htb] \centering - - \caption{Organizzazione logica del \textit{second extented filesystem}.} - \label{fig:fileintr_ext2_struct} + \includegraphics[width=9cm]{img/dir_struct.eps} + \caption{Struttura delle directory nel \textit{second extented filesystem}.} + \label{fig:fileintr_ext2_dirs} \end{figure} L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle performance dato che viene ridotta la distanza fra i dati e la tabella degli inodes. -Le directory sono implementate come una linked list di entrate di dimensione -variabile. Ciascuna entry contiene il numero di inode, la sua lunghezza, il -nome del file e la sua lunghezza. - +Le directory sono implementate come una linked list con voci di dimensione +variabile. Ciascuna voce della lista contiene il numero di inode, la sua +lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig; +in questo modo è possibile implementare nomi per i file anche molto lunghi +(fino a 1024 caratteri) senza sprecare spazio disco. diff --git a/gapil.tex b/gapil.tex index 91f93a0..18f10c4 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Feb. 2001 diff --git a/img/dir_links.dia b/img/dir_links.dia new file mode 100644 index 0000000000000000000000000000000000000000..7eaf5a31c11c88863615d70214612bddecb509c7 GIT binary patch literal 2847 zcmV+)3*hu0iwFP!000001MOW)bK|%XzWZ0GG*=IWH^BAIY-MsyRZ`i#yC{nzGoeHk zMUTgO*xw!ilC1~zumv#|i5H_Vwo1 zQIY+kf5vq->FEa3xjFjMe{7oBFN4AJ^K(+Z%(JGdld^b9=K0{StSqyEZZznBz3KJV zI~Zk6X5L%An>9^c44<03H_aybm;Nw&`0u!`o~EPzqSdn9LseFF??+aC>3{lezxsn^ zH-n9S4)i_CW_i8c?PONX3*Dr7nYEhi>BszDYqM-M*Nvv*ub=+LJ}pjZ`NpcRT_?I% zNHfXmaWQSnsq?H{TnLgVLdffN__&B6yoeHBL=7*ZnBUK;x~a3GX^Rd48+}HVVxZQWH&pw-u%Y4!QXOtkq zwGb-#ok*Deo0#9HiOkDB-o8Iu)Y;oBb9D|CfZ=Z|?Yer)#lj!)}*Sk2ZFWgC?=PGDy?Uw(4fcVHoEG4A zqJp{!*;KNRDB3B~Y;JFty!E6XvR`h3va%RYC;9Fhl~120JA&eeqVBuG%Aoc^da@5P zL80t}TDK3{ckG6Jm}C!i743tweP}6Kv=5N>L3y(e4BS2-%I(~4X&;E<%y`z_un)7k zddTPVXdygU2o^0wI17<_un?)zcTGvbVW-+k2x_LjR0(4sm`tTUOwHl>8;I{knd@s7 zod`!0u}jyYg@DY)BOmE__+&gazgNk42A_+)0lCujzw++H4em|aS#EF1ESJ$)>3)q^CN!9Jr28aV)eDq=*!EDv?YvBhwt7zfJgSU^90YY8V)_VQA@BGzgGW zX)iThDnLC;x>nD^;OkjpMdNi$rMahclmeegYr}|%vejJ1S5^tkRDenz6 zNUfS16G*cVZUosPV31LXZ^s zBS;>IAhl|45hU*jK_Y}BLAnwoj|3TvASw1kkRkv$SB$P+12=jr&rtyixEGU0 z^;W>Wm^`Yk6mS#DcqB(Ra#XQ`J0v;sPVE7X?1BJY-vb<7WA%11)z|!f8<;In4pZ}e zNd)X%{-Yfp#HBD8kO+Y?umu}tlBEU#f(T_GM=3%Eb;7*Sfn}+t)hNHYK{p|(_>W?e z&p-dWnq0`ai{+d3a>z;%+3O{hBZu>&9PRk_H=pti!tMrq`hf<7>VwNeP7v=qC+ z$sK0KYqwH6wc*L&a#wg~0d_;$QnP3n03CJazDF8{-9QwrZy-u+QVV_qQG6SpF~5Q; z4@TX!KjBE2efyxRJhUXlC^p-N+A0sbvo10_1jZ_li?8z7t7efLA<2>XAjc#CJ+j3* zeXsPW;OQ|g!g3V^$^8+e3`US_iy&oOrR;hLGOofBkRXNo9=gzJ9+^;O(>#jbsYGC# z=E0!+D529l7<6kS=rj)nP4lqSd|%E|xy-$^iGYJli&&uy(=ae|8&|~Hwc_kwRr&Id zVw&#)oANT_gUzH0ED6)_qF703++2jsq>r46wwb;j_jU*$8CbgoOT@7zG*QMboOYh2 zzGrZ1pHD~kSzTAp+nulcFxQ^%%X~UMeD=gu#L?^XP6-c{HUkfhM#sEm1YZBsd(@aJ za|@rQT4WP?tAB4?u>Bt<%Ma6Z^TVxtU+a`S;@-<@NeUYHh*@5xJZ0*RTb5POxNi+? zN0Va>BJ3|3_LO!M_8j@yh61uEf+PrWN-XRdPM5IPGT~v*H`DMfR3B?V5)xs5xv(cr zu$TWw*kdnVzJNtNmMOJfzV`N4UcLz6<%`2yPL4H+xW8;KpPe)A_hFv+2vrm44KpT%35~ zqip`@%}|^MW3h=u{vH_PJ=~8%!I-*lxh#NTtTc>yDlClk>s_jSb%vOQv3>=Hacg|- zCi;XTj4u_&@*^#ENb4C%zmx<$#u`vQ> z<8S$&MPBbiv+%II2XLJUNpOm9k$ITdmUAI&CE^nUD#QHG;~}xusCG3`x9D&zoatWB zvDx*}CgOM#X`3887l%cG7DYMtMziMo;fq?*Km5N=g$xON$dH1E3@K!WaLX*>_n1Yo zXNH5rnnmehl?CvnOr+u(_1Kz4?Q$N88pg1OF?BJF($z37j?3&NufN_b4)o8s&L&@P{s)=e!(w0D0020_ajyUX literal 0 HcmV?d00001 diff --git a/img/dir_struct.dia b/img/dir_struct.dia new file mode 100644 index 0000000000000000000000000000000000000000..0c5b0ff87cf38ad7261bf6f4c0c29783a56ef4ff GIT binary patch literal 3191 zcmaKsdpwi-q0@|M9(Fuj_MtuKRsoe|*8o5`fJ|@Q^?i*({2X_$ z)a3PaCIijESA5&K?<5@;#Tf$`U|Sf2RbmypI~MX9A~bpUt}FXNftVnY#yk?T@8x`Mu$P() z7buU7x413qz&_P!F$pQXLEz-e4*9&#HTUZBGJU4-BmH^dojr4Yk-7FoYTUjjWn9;_ zRNb8|d&k#~ncQt)i=|tPA$!BrFP;0!$Pl?Smn8cnybG0_@P1C$Oy{Vw`|k?Dq~~{H z_ayJ5Mqph`cvW!Z_{`T_m3xGUp%Xl*TmcE$$#xgXU<=C;!CGk7r8Hc?ce2Ky{J_FF zqWRNFYrz@didkAmOrZVCG1%OPIu69zmyb+Z5%#v%lxxAW1~CHefF@DrerLVpLSRND zCHjdWG}d+ZZ;@HInAvPj)*(CBgu2@*qx{P=1)cD=O8>#t{ECtOXPOEjd*0)ih2TrL zHg&>)n00C~Er}kW?OqOF9UvFNl%|tp6?Rg9)eAcfB%7mJhjDnYptTW?d50U%@OG>5k|R3)UxG1;|dO|S;1o$>C%HvL3Yzf&BKpJVYW!KMLAgE7OQ~b znU}nkzuDVfXN0F>dZlb*8OUd3LoH+@#@I%n&D4}h|Mc#>f=);drQgm=p%i<~Tu(zv_eXgEOM_eqo-KZ;Tv-B0gEh}0x`RK6hsx1 z?_<)N>GfNWEZ=1~SRJhWP>};%2E`B`$+w zlzErRe!G{Nf#=)r>T3E8a%4P}u!`F_ktOkuQl4@Azej!K?qaKNa}vCCfaW%8iam{<=CmtFhop*P)GI+e`{@JIEWd=`=~E9 zx6<1Zw5Mti=00{P*(iz{6(j`Kji)w)!Pg#kU=0nHVARDX=*LWiViJ>`EmSDf9zsfs z1o%S%jzItg{#CWd_k!n9E^1oKetboof+xze(vQoP04n;%hr=H5$sP%s&64wG4~+2?Ub zuhV%;r*l{nYKBTR>Jz>EJC{(ho2IhIgKY%|^vTf*Jjmkc!=L6z4UAsW4yje(vgyPe z0PMIs`ZuES>jhR+nD$yb>tEGW_>{{zX~ z7^9x@3O0b&zYC~Pp^0sbZ)`(t+sL0MkjNMCPCGWVl{cuCO^!c4jdUiKlC1KuKJn7{;dh}UZ`WU zrt08-YZ@NzwE0uh*MDo;i2J7|%l}i;1Xc-b_@^eW!+}3^j3pA{5vXVJP*NhASE+Gc zmw5V)J%q?fKx8ZX(h}%DA^eV*?K+?vx)CQATebTVUQLPgC1kEZQp_O{mMefzT!whu zg3!7s{*Adc0!{l*CjXIVIn{F&?joXqZcSY&z_788sDq> zL>Ccnk#$riORLgs{pEkH?*XIGGv~68Ixs(}!{$gtSqjQi{e79R_aY-ao#BU;`F1F1rvGI(WUdd9iPDmPsZ3f#o=`dy>*H$uV+wXSv=->7Amg@RCasi} zkI2bTR3$GVW4mq2D@U}NgN!8cM!!TURmXg1j~QR=8XgLs?L5x_C_A)_sTiM~7NOXR z8ec4S@?C~wqTmCOjjRezrtx5L(P#S6=LcZGG8rI6=TLpgl|2*9^=zvdzI3Z!o^omZQi9gSqdA}y6GbRn2x=%jvJ2U4s4AP%41(H; zBB!@QW0cy~aT8}1p=Rk*Ww=Cxu*BJ01m(o5Py3<>2pIHb+Ek)M9nITsm*eZbm2jT% z!g+b~)h>FSVrwB;W4^w}LznmEp67yBF~|Ey*5Z)LQU(%7&UnoS|NLuvy%5uI$h4D= zUc5`NRb16~P3w*E;I5sQ786e}i&e|tZ=9hs)!0mvhTlnb^?LgnzUMY@E7OB(d)i~$ zh2VE$+b<**Y=2W*)Fmx@Mn%dib=0RAn2z=>oTZys%J=MwXGDql&qKEpd;MIB4a&Ma zaAmCq+^r6R3)5^AyoTj`OTwRhH>`811%Lfsw@o*>{_kIBbs)dOmrfcYIbcxOxIuSM z;8n+$GY3l^Cm$e)oM*g$rkxy=Kn`j%CE$5geXJi{<72hS&bhrxVFlujhMvU*Szxd8 z0^OJdIB>U%z)Czh4`_No8NXJ`wgx|+-ur>a)&*;|KF2k?xeVYNFn6QQWzmg6%AD!v z!5K*P4>FuNNkZ{jLGZ4OS6XxlzrJ?Z2icBpa%r<$K|Civ3nU682+r2*g-UZImI!fm z4~R}RU0u18fz9%m4*iKcDF-nb$I7|^fKezv|91;)8jmGzKgtwv-D_(vT#y#()y-g5mW%hp;lslNN>)WwW;sgYB`U=5zbHwfpszNSGr?>BZW$&tww0>hltL=mCWm3+gd>W@s zKDmgJ>Ov3{5JH}=!|^Oe@GKH|7CAhNxVT$nd6`FX*<>@yvP48_#i`7fqC1~r93@g^ zUJ?a&r+y!oW%kPFzmJmQ5CN*UpRMOuOPuEM>cyU`wH`9$QeeRLPO9WQ<{%O37p zLao;!t=;a28

D1K89CTohcp$OAM17x~fxT*Q?HXamrXkOp8R)FJvW8Cd*6h2ly4<$2 zu2z|wkMcdGxffFFeZ`b4E!%jh_t#6l#&c2p@^?0m((RP>cwP-dYqbYv#$;E$4pOl$ zY;+yBjnQ_2*VR8}jG`o-rgPDLmqfapw-i8Ls<5<`5I|i5H+2aF1;8!=qky|^uyF|# zd0`lm{xtY-l64DBhj zZ|WFA@DftERYJlcBIn4WL+Bb(X!Ga`$)f|~JenZ}9W_(LxQn+EX^w~lM~jU=Sw7uR zH4BcAz9BqCLhXX?u@mGnRr7TN;`6|h`80PGb}{ujynM$nlwQ9)r%(7TTjsF@|F@Dw z8?&+Q;81sf-BYB|u>Qb9oCLv^L-3JHFzJ&=u->41=4`#e`Md!>N#+3S4rJ!w?ZgK% zbHM!y5N6q2SeIasFj${(u4)=4r$`tmaKhj}_vBU`S>P?XMnWA@O~bY$_d+^yPtcMD ztNv9>R;B*FE+&JkzimfXZ>*hdQ+9lCk+6uW+|V#aUExAdMDC}mf|Sc z+AIZk-4~I;!FW;U-gao|7@~>1&u}`dsTbuc5q0XVq0TX+Cs8p=L^^%>gCFQO)E$;e zBvrj=#QaZxac0su)Tt(E3uRV?LeA#T>iyyC|BToFT>D?Yc`mE=iB4p{#tl^JkQ1;0 z>+Mh$Y73Un)wwFhwGA_lfsME+VEg8&wc|Hp$L_8vl4H!60-N!^!i;gZ6PFqcX~Qz) zbSYMGp{KTQKX}Lwy+HC*Wtu*0=Z=zW{LN9Z*TTVeN4I-{rlx7OIs;m0q+(=YsK{enT^*0*lqY;M801&r#E0|98-9uQ1)=&e12Dq{sclb)d` z4PdIxpok%$o3QGQ_6 zx4pI(Q<^!!yeCg8iwAo=mHVDn$@RVkW`qXP3VKqUDV7V7U+EH!EzOvmRIO>6EzUsV zqGw*TWx&W7=(MgvMvTt`jYd)(HX7KD#=a16H173bI*EWC4@_M(^6Uv5Idb*Hv)+K? z?_aJaq8R7#!fxvu!DB<$EIdNOV_@DO44pXgt*VKKf^(oFN8qWW9eQ>l=xE&70-ZQ= zL>XZlY?R!%&wGT8I%T{X#pOI&SZFkuYGQ%$Y`{oQGT;an7(G3|paRA~?*@VcqmfV+ z82bc_6q|Q^LPMj6!X0P~5a|~*#%VSY78;GA(YHm_bDk5S#C%w`vf2Q&su~cVDz&K2 ziD2~wghag#dgL3NG8!dzQm}z*XlR;s4UloOaT|`>0fBBsz*{9H?CH^8;GwgbT!+NY z%x<|{O6+X@m2^}`G>`y^i9Rl}0Z4{;=!N|ONcAP-jxH`079b4{ST|J7A|&K-5z2ee zsuy5JRHwOmR^-pn{n}Qa%)i*{Hb(Y)r zbomOav7u^wy?6P+xg6fbFXZnukLI^m N{{w_i%ao{*005z6J$e8D literal 0 HcmV?d00001 diff --git a/img/filesys_struct.dia b/img/filesys_struct.dia new file mode 100644 index 0000000000000000000000000000000000000000..49ac7738f3a3af7931e7b6fd09e482a00eff3548 GIT binary patch literal 4893 zcmV+&6XNV2iwFP!000001MQt#b0Rsi$KU5uI6SZJvQl@gw|nEvdEJP!adzGvWkcJX z!IT5&>G8{c_9F>wic1-TlrooW$MiI~C?U}ApO?x?{rw+*Jq<7Z?2jjdX7u$EDt7sg zZ@>J#H>m&S|9cqMPZ$1x(Ih#z{pFc1Xv0!r!f9=0{EZL8FIn zzy6o}b@rC#Pb|*0>5X;{GJUGY4};PAIOBdjoP7|yvYhkR&tdl=?(l~g;tw&#A7U`M zeQw6naXpx>4|CTv!+t%QjWiwq=KD{UH=&L`jai+_VO_uXL_6;cD-%ltH*tG2D7JD3{@OrSikhg^V9#fFi{ut&v*`g z>r-g%{;z*Oolo!I(|Xja$GwX$7r!-sT`mkPySy0mzFz(hTmE=fC*)7&1!(Q_d2Zgm zM|K76mDu%7cAfn0ZuQ(_|L*J2!>~U){})y*JUmXj&kp;Y`>q-H`r~bH-G3Q-e)5yY=I8AOA8WfU z+YJ2mVy%B*@&DfcYr0|eL+a}1elcpq)z2ztjL>1pTQ1ZM_m8=jVbt(=zmccm!&n)2 zRTo!|>H1Qmqq%h4icdNiH9ddM+Dlc3bNY^P>2fEU(R9<8;raO?zYm`JlP~|p5(*mslWL<>W_XrZEyhI^Ds7< z&^)TJ*(CB*QSkbXY!pSM%&Sf0GXsfk6q9E45wi%o%@Ntf5_WMj0V3HctRyl4tP(a7 zVATz)G(-RZ*DFk!)JFhdNhkm8^)L22|6t@l_1jhBv}Ty@T=+R1#AG^R_Db$6m>)#U zcq1b#;f;)pHbzwvIq*uE)W zwg3UdLX;l@rp2w2Yo#fwZ82dncV8 z%N5A)4PAOnxb(QZ!06Ir7CrdqVAS8F2as+LW3>RPMN|y92$!V6DyDCsV$K>9GPm5o zo_^bXGaB9YN4+?eohFz$jqF#+{qySho66R9IqA@U-FVkf{Ks}%kH^i=)srulJWo9H z?XW+3c>mp}zWME+&j&{cOUW-;57uPO#=QRK;?biR%I7?J(!n#+UmIQv z^ViDd*Ru8czm+$X$$8*8oCk?27U10lq3xBZ>}vs&&|W*_tf1*g3Yf@$Nb?`$vR;!1 zffi3ga_xphuicQX+6^B@l&Ia1__Z6FYBxH#v@ZM{W7OW|r6*T!_>c-UYbz>em4M)) z3l|bs&Iua_1*sjfhrTkoO*ESQV-)hw&(c3v%RaW;#XpA?=U(S_(7SX(rRxN`O4z6p zj9cf8v9iH5Yj2b#;LF6jBB3flB0(atlSt?kk+7d65;}uOpccXfnb0E8$c*+ed?<$y z{;?m`$MyzaCMx;9P&g6_5{jLK!lVd=Ll%mzbe~BN?R6;V22`yOLd%fvGcn)i;RK;V zz7LKg-{&9q24PYccf;oXj|rvz_D}t-uQ$s5<<~M$$d?~FGL6Z_YYIKj=vsNkBKL?X z$}&=xF%w_OrEv=VKID)vcqL2+wh9o2eH$_{c0P>poXA(9@YIhH%CBuGJPpY? z-15_eDSd=5j(V3rm7ngi{2_h$mstF+wfH6W;-{s57E7OJSo)}0*V*FN@%H1_#c$CU zKjzKHwEPdJgn=j53HddNeDkHPgf%u)`!X&Z+yGQcau-Gg4ifpg!`l4T5Akn^u2IsZ zhuzY3-s#%^+JpS0N(L@-$OUe&{x=EXI7GCMIQEX1(-Sq1GWGG zu1$c%C&1GBKZo^ivaEm96w8bN8&fQA1lR%uP?qI9+B@*%8VM6!2Hb17)-uUMb}?3L z`NgT7vSHL?xkHl*wlWoLt*thy*Fu$t zJ3kjviEJvdzUW9MFuU<57pZ`#LIpNvFzJVY*eyKtiUk#YX@%V^Hf>(yOdr>#6p#f2 zh1>3AhJlI=W8W~)1u#&UHIanD;b6csVW3N3pcWXQ*Da>ai!eAY3`7S+!oZfmpcNaKBC&y{*x)=cP+2fAC1L~9jtxwa*uYS1a2^=wEEw1l z5V!>d=v4mw(#-W7E=1Pij{jF zM4`K!B+H@}7B`I$)WU^(6T{t+CdvhH2%`eiP(m*3mfIp{sW(l6L4xsd!AR-dD#RxV z24oTpjV%~ThMWttF8UYTa2rMisZ<%k&|3w=(v6WM7`q5YN)K0|kp*LOST1>nf?tl@ z)Xfh8Z(ZH|16!i4TiU#+uN(DsTjDIeIt1`3TXZK4MzRQHK#UP%nHZB9d|!)A8B}IL z8TXNL5z12LMV!%YW6PkaJgvGka_=3h!j`~{X~zReEQ{mDtJC4?f-v@p!{+pQX zczr)@#xEDWdRkMD#PlACE31z>BqHVrRdTr(L$5?(?Lw3?iFk%zhQcX7*umwU3qPlm zhga$4UifMFb{4)+trva{o)|kl#{Sg|U%DdY^G+|Nr?&KeQQsX$3#ZcHUzNXz?C z*`DJ*`_JQcYlyruu?-uTuIAr2x47TCNhEHt8_zzOz6|@_(e9qW_Ug&w_BfYQkp5Xg zx=o1D0lI_q?pO1U4dx(sg#Vt_>2$5bZQ2&K&V@^kU_gp+Ka|#1_)(3JpmEjCY?Csx zP3>Z35&Ai$OoPz4Ym08SqOnF9dih=46c1aAlcJ_4u_0YOk4f{wyxontF2 zWmVK^C6q&Tig=~L$S{;KA~d6xm106ipCvqT_%+ZE_48m@`LmU*cK+|?$9Uk0FHq?$ z&?}ugmmAeQV_M7fK0o+ve%f7r3N=N*@9{(Rn5S2d*=3APMq>=+jImfX#_TwZ@l$<2 zZpavCF~&f~7{M5K35Crj6i^v_p^!r9S@v=+6gun>5n{~a5Q^ts(%D^Dyf2MpZ?* z_)0D+;^-TP@z%a!yv*Lz9Dmm^V(e@fv+0akbjB7Pfkl~)z??b)6JztOfM`7RF zoi;Hl;W?_f)aEMT(IrZF^rCtJ9Rr1q0aY&?3IrlkJ*O;D&na8RKw!6fN}CuNgX7{r zW-4WqB}&=k!Wf`qpwKZOV{j-Cs657?gehQ4ra+Z21!M@$fdQSz5R@>{112xh0h6~nVB%u{$QY0G|;A9KP7Mwc- zB9ATLMQj0I+CkTpumzMOItvVB9$UbR*aE(^VVo&p3n)i)1`wzmwtyAcO`R?6rp`+2 zrp~A#+<9Q2bJzk_Wb;tAw0S5iv3V$?URdV6aX>>WC@Bh@ULe0^3TDjzX=4FXD?~gTxkVhWZbDqgC_xE_XnuB1-)l? zvuFQ_+{Q`lG`00Z#MUFA68kri82WDwuMdDvH11U2iE;!K7X;2%P(Hj#xamSZ#{-rj@Un8_C*5w#(pOJJP-U5w`D0PI~!&he&Yl_{PJCw ze+IvNAATVCPZ)lg0>A!D`19-sqHukFCb=@9zlEp%M#ZhrJxvmr#AJVUW}9O9ZAXyD zf70NaqxJZ6HBZ1z^eGmbP0E<)TYxVNKKOELqEBv1^ch0`gwaoN_%*i8-+Y-1SaRhL ztMrvc_4QfUSo`QmT@%?|=?(lkD4z;HJOA=J82>)G&gLfe7>OE1Byq<8IbGc!V6naXLU_|0rM z6aIbp-TzOt+rLHM2V`|kQNw>!6#$k;1uV7-*h(_)fSgzqc#1zjxB4K9VcTr-38E=wAjF;JlZWDXhVaIFlVvXog7WakQ5S0OX# zbW>)~O&KtzY;3g(*1(M)5~Pd6hX3z3bSM$M?T>m}%bC|ExY_dU-w4)wJonG5Z(zau zkyb!+{0eA+UI8r-E1-iL*;U2d{c4!M+N$Lj>)a*Kor;m(@k*!k@c5Wz7L_zMcA(-$ zf)v3#3lKBS5C)JnV||Jnj`4zV#Yi$pGIo#*l^_}3QsPQRmnU!2H`&B?<@K!iEqd}M zxbXOneA1-IlRwwGw=T$%%iaunPRg`$QnpM^%1};5sqtGJD|vdl=VG P-+uXjpJxNx4y*wHsWxww literal 0 HcmV?d00001 diff --git a/img/memory_layout.dia b/img/memory_layout.dia new file mode 100644 index 0000000000000000000000000000000000000000..3608964870209c27c2b460ef522d34cf63787866 GIT binary patch literal 1231 zcmV;=1Tgy_iwFP!000001MOQ|Z{j!Xyf{h$g zN+0I8k8`1fT(~4LGpIo-Rl?Et`Pk<>K0bjjUtgDz_JVm#7#-^-F!ZlacV9w+KFhy3 zM@vl_&^Wmo>kA=PpGTw3W&@&aj0EE#B5M%i(N7dbXe5nB`qQ1J6#+sdP;xK7i-h20 zx)xZYXo<)A6wQ9jIa||E&#ZF08H*U#UQjgF@1N6`KFVQ62RKKtS7?QK8Fsm1F_9)> zyQ-Kp;3V$_o7^gvMs)sk|CfEA4Jp5|$Eq7>BZ*idJ}0!w!!e4oiGaX|5boyTa*C;X ziby>LS5HCW$%=8o5fN3IDPs{vG-DEcjob6YGZe{?Ip&Jl9{rgJ!A^|-8Ab6q4rI6A z)pMy5=bVJcg?M1mfU+T>SWI4zO_u>WEPIB(RfhjUVls_zod<-9&g;E{-*$xWy4GtF z;`qdBAKEk^EpoHbDaXrp=X#LcDs5CLMTEAP=kVY5Ta=d1aW4GAEU@YScqVf9{u79X zh=ux|B`m(`gx;%i$wB zk8nm{fxvST63cTQ6D}yPEC8X?juc0DIhip|tJ`f)Zlw&VgsZOYI(Z@Ay^JXu#>J0S~|=Bvn>IE^uup zm4OE>=g|Y6W2ZW>*Qjz9g&mWUQRH8Ffs>2OUQG>PCbjGN(&izf72} zmo<&RW1YsjR+`e3;P#RdETy%f156(pWjzvrU6k#e&5jJo=7UF7dX(fEXiWZiqU%XfbT)qdkE4-l=bJAkPD1fL&4asU<|s_ z4E5sKIl=5BCs>M`(Y9~;{sYW%fXoSj>6;0wbsIS$7HIZkNDAGOf;F_GuXTttVIN7s zR+=-oW`l=SMkd6T~^&G}p{lN94)r%GvHpadLjnWJm%@#;DX$ zT-jB2pJ)rIyyTnIQfPvuhf{6;X>z;rb?y>qPx`j{(6^^p-|oA<{VVC)JEiZB)E|;X t3m1wMUcgqT@gm7@QMs9`-0!OL>^l8@#?#%w4>+FgegRsDFKy2_008~1U`YS~ literal 0 HcmV?d00001 diff --git a/process.tex b/process.tex index 750db60..834190d 100644 --- a/process.tex +++ b/process.tex @@ -388,7 +388,7 @@ programma C viene suddiviso nei seguenti segmenti: \begin{figure}[htb] \centering - + \includegraphics[width=8cm]{img/memory_layout.eps} \caption{Disposizione tipica dei segmenti di memoria di un processo} \label{fig:proc_mem_layout} \end{figure} @@ -496,8 +496,8 @@ la funzione lo utilzza, altrimenti rialloca altrove un blocco della dimensione voluta copiandoci automaticamente il contenuto, lo spazio in più non viene inizializzato. -Il fatto che il blocco di memoria restituito da \texttt{realloc} possa -camabiare comporta che si deve sempre riassegnare al puntatore passato per il +Il fatto che il blocco di memoria restituito da \func{realloc} possa +cambiare comporta che si deve sempre riassegnare al puntatore passato per il ridimensionamento il valore di ritorno della funzione, e che non ci devono essere altri puntatori che puntino all'interno di un'area che si vuole ridimensionare. @@ -537,6 +537,7 @@ le disallocazione, e definisce anche una serie di possibili agganci che permettono di sostituire alle funzioni di libreria una propria versione (che può essere più o meno specializzata per il debugging). + \subsection{La funzione \texttt{alloca}} \label{sec:proc_mem_alloca} @@ -558,8 +559,8 @@ viene rilasciata automaticamente al ritorno della funzione. Come è evidente questa funzione ha molti vantaggi, e permette di evitare i problemi di memory leak non essendo più necessaria la deallocazione esplicita; una delle ragioni principali per usarla è però che funziona anche quando si -usa \texttt{longjump} per uscire con un salto non locale da una funzione (vedi -\secref{sec:proc_longjmp}), +usa \func{longjump} per uscire con un salto non locale da una funzione (vedi +\secref{sec:proc_longjmp}), Un altro vantaggio e che in Linux la funzione è molto veloce e non viene sprecato spazio, infatti non è necessario gestire un pool di memoria da @@ -572,6 +573,17 @@ cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un segnale di \textit{segmentation violation} analogo a quello che si avrebbe da una ricorsione infinita. +Inoltre non è chiaramente possibile usare questa funzione per allocare memoria +che deve poi essere usata anche al di fuori della funzione in cui questa viene +chiamata, in quanto all'uscita dalla funzione lo spazio allocato diventerebbe +libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni con +conseguenze imprevedibili. + +Questo è lo stesso problema potenziale che si può avere con le variabili +automatiche; un errore comune infatti è quello di restituire al chiamante un +puntatore ad una di queste variabili, che sarà automaticamente distrutta +all'uscita della funzione, con gli stessi problemi appena citati per +\func{alloca}. \subsection{Le funzioni \texttt{brk} e \texttt{sbrk}} \label{sec:proc_mem_sbrk} @@ -672,7 +684,7 @@ che pu Il controllo del flusso di un programma in genere viene effettuato con le varie istruzioni del linguaggio C, la più bistrattata delle quali è il -\texttt{goto} ampiamente deprecato in favore di costrutti più puliti; esiste +\texttt{goto}, ampiamente deprecato in favore di costrutti più puliti; esiste però un caso in l'uso di questa istruzione porta all'implementazione più efficiente, quello dell'uscita in caso di errore. @@ -820,7 +832,7 @@ versione estesa di \texttt{getopt}. Oltre ai parametri passati da linea di comando ogni processo riceve dal sistema un \textsl{ambiente}, nella forma di una lista di variabili (\textit{environment list}) messa a disposizione dal processo costruita nella -chiamata ad \finc{exec} che lo ha lanciato. +chiamata ad \func{exec} che lo ha lanciato. Come per la lista dei parametri anche questa lista è un array di puntatori a caratteri, ciascuno dei quali punta ad una stringa (terminata da un null). A -- 2.30.2 From 51808855fbeb095f8a1917fdf4b67fba041306a4 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 20 Jul 2001 18:22:43 +0000 Subject: [PATCH 16/16] Corrette alcune dimensioni --- network.tex | 2 +- process.tex | 4 ++-- socket.tex | 8 ++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/network.tex b/network.tex index bfc9f74..4da3c73 100644 --- a/network.tex +++ b/network.tex @@ -414,7 +414,7 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP La comunicazione fra due stazioni avviene secondo le modalità illustrate in \nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per lo scambio di informazione su ciascuno livello. -\begin{figure}[!htbp] +\begin{figure}[!htb] \centering \includegraphics[width=6cm]{img/tcp_data_flux.eps} \caption{Strutturazione del flusso dei dati nella comunicazione fra due diff --git a/process.tex b/process.tex index 834190d..36e4295 100644 --- a/process.tex +++ b/process.tex @@ -388,7 +388,7 @@ programma C viene suddiviso nei seguenti segmenti: \begin{figure}[htb] \centering - \includegraphics[width=8cm]{img/memory_layout.eps} + \includegraphics[width=5cm]{img/memory_layout.eps} \caption{Disposizione tipica dei segmenti di memoria di un processo} \label{fig:proc_mem_layout} \end{figure} @@ -850,7 +850,7 @@ un esempio del contenuto dell'ambiente, in si variabili che normalmente sono definite dal sistema, è riportato in \nfig. \begin{figure}[htb] \centering - \includegraphics[width=7cm]{img/environ_var.eps} + \includegraphics[width=11cm]{img/environ_var.eps} \caption{Esempio di lista delle variabili di ambiente.} \label{fig:proc_envirno_list} \end{figure} diff --git a/socket.tex b/socket.tex index e72d210..e20c388 100644 --- a/socket.tex +++ b/socket.tex @@ -268,7 +268,7 @@ in \nfig: \begin{figure}[!htbp] \footnotesize - \begin{lstlisting}{} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} struct sockaddr { sa_family_t sa_family; /* address family: AF_xxx */ char sa_data[14]; /* address (protocol-specific) */ @@ -345,7 +345,7 @@ conforme allo standard POSIX.1g. \begin{figure}[!htbp] \footnotesize - \begin{lstlisting}{} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} struct sockaddr_in { sa_family_t sin_family; /* address family: AF_INET */ u_int16_t sin_port; /* port in network byte order */ @@ -397,7 +397,7 @@ struttura degli indirizzi \begin{figure}[!htbp] \footnotesize - \begin{lstlisting}{} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} struct sockaddr_in6 { u_int16_t sin6_family; /* AF_INET6 */ u_int16_t sin6_port; /* port number */ @@ -444,7 +444,7 @@ definita nel file di header \texttt{sys/un.h}. \begin{figure}[!htbp] \footnotesize - \begin{lstlisting}{} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} #define UNIX_PATH_MAX 108 struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX */ -- 2.30.2