Risistemati un sacco di riferiementi, e la riorganizzazione della parte

sui files

diff --git a/app_a.tex b/app_a.tex
index 9798904de193d3598a8d070028efa7a787e58e6e..0332efe535f695265824e13562641ff4e73cbb37 100644 (file)
--- 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.
 
 (\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
 
 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}
     \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
   \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}
     \hline
     \end{tabular*}
     \caption{Formato della testata dell'estensione di autenticazione}

-    \label{tab:authead}
+    \label{tab:autent_head}

   \end{center}
 \end{table}
 \begin{center}
   \end{center}
 \end{table}
 \begin{center}

diff --git a/elemtcp.tex b/elemtcp.tex
index 270b9a585b2860879aa999d66bb2ec38c324663c..33c005ded79e282d72ceb9f3e866de9f41fbef2b 100644 (file)
--- 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
 \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.
 
 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}
 
   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 è
 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
   
 \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
 \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
 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.
 \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
 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
 
 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.}
   \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
 \end{figure}
 
 Come si può vedere (alle linee \texttt{\small 21--25}) la funzione

diff --git a/filedir.tex b/filedir.tex
index daf947a8ced46053c5df9ae3c25effc427526c86..d811bfccee48f6f716d831bd1cb07487bb5be0b9 100644 (file)
--- 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}
 
 \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
 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}
   \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
 \end{figure}
 
 Si noti come i vari membri della struttura siano specificati come tipi nativi

diff --git a/fileintro.tex b/fileintro.tex
index 4f5282680fa349d7f88ecc1aa43656036e5eb740..a7df9939b1089dcc33a5f2889978a390bfd5252f 100644 (file)
--- 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.
 
 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
 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
 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.
 
 varie caratteristiche distintive.
 

-
-

 \section{L'organizzazione di files e directories}
 \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
 
 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}.
 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}).
 
 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
 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
 
 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
 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}.
 \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
 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}
  
 \begin{table}[htb]
   \begin{center}


@@ -164,10 +162,6 @@ vari tipi di file definiti dal Virtual File System 
   \end{center}
 \end{table}
 
   \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
 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
 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.
 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}
 
 
 \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
 
 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}.
 
 \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}
 
 
 \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 è
 
 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}
 
 
 \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à
 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}
   \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
 \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}
   \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
 \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}}
 
 
 \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
 
 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.
  
 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).
 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
 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
 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}}
 \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
 
 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}
 \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
 
 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 174ae98e633cabe66e64adac441491c48738d97f..da1f600a03304454da3745f70f386afaf9706830 100644 (file)
--- 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}
 
 \subsection{File temporanei}

-\label{sec:filestd_details}
+\label{sec:filestd_temp_file}

 
 \subsection{Efficienza}
 
 \subsection{Efficienza}

-\label{sec:filestd_details}
+\label{sec:filestd_efficiency}

 
 
 
 
 
 

diff --git a/intro.tex b/intro.tex
index 0913f58fd9a0499786ff22adf9b14504d0c63ef9..6fc0fecac814ceb9b4196b500c9dcb81408232a4 100644 (file)
--- 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
 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
 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}
 
 
 \subsection{Lo standard POSIX}

-\label{sec:intro_ansiC}
+\label{sec:intro_posix}

 
 
 
 
 
 

diff --git a/network.tex b/network.tex
index a37ca6dd90922ae7718f159a367127f66c5f105c..f6b571ba196abee09037536fcb40247c489c758f 100644 (file)
--- 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
 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
 
 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 6058959bdd6986fb0e9f711ef396db1019148dde..c19ebe615c73a90b628571ae55c79f4fe18161ba 100644 (file)
--- 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
 
 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}
 
 
 \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
 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
 
 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
 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}}
 
 
 \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
 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}).
 
 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
 
 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).
 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}  
 
 
 \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
 
 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}
 
 
 \subsection{Le variabili di ambiente}

-\label{sec:proc_env_var}
+\label{sec:proc_environ}

 
 

diff --git a/prochand.tex b/prochand.tex
index 721b899fe852690493596a0bb8aefeffb5675262..e43caa970b166af4e26da74b68bc55e3dcfe2c9f 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -143,5 +143,5 @@ Linux come il filesystem uid.
 
 
 \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
 
 
 \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 399921243b9477c15e4b6dd06436ad280dcf316c..ec3bf5547afcab767eddadcd7d14a91cb477bb67 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -1,5 +1,5 @@
 \chapter{I segnali}
 \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
 
 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}
 
 \subsubsection{Tipi di segnali}
 \label{sec:sig_types}
 

diff --git a/simpltcp.tex b/simpltcp.tex
index b024478486cfa3f02ea0f0df82b41adaaf1ee4a1..38df63e18b241f3dc0f99d3cabba23a58346f41f 100644 (file)
--- 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
 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
 
 \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
 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
 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}.}
   \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
 \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}
 
 
 \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
 
 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}.}
 }
   \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
 \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}.}
   \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
 \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}
 
 
 \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
 
 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
 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}:
 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}: