Rimessi a posto tutti i riferimenti a figure e tabelle cancellando
authorSimone Piccardi <piccardi@gnulinux.it>
Thu, 17 Oct 2002 17:32:52 +0000 (17:32 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Thu, 17 Oct 2002 17:32:52 +0000 (17:32 +0000)
delle vecchie macro che non funzionavano bene.

14 files changed:
elemtcp.tex
fileadv.tex
filedir.tex
fileintro.tex
fileunix.tex
gapil.tex
ipprot.tex
macro.tex
network.tex
process.tex
prochand.tex
simpltcp.tex
socket.tex
system.tex

index 964dd4f..6715770 100644 (file)
@@ -70,9 +70,9 @@ creazione di una connessione 
 \end{enumerate} 
 
 Il procedimento viene chiamato \textit{three way handshake} dato che per
-realizzarlo devono essere scambiati tre segmenti.  In \nfig\ si è
-rappresentata graficamente la sequenza di scambio dei segmenti che stabilisce
-la connessione.
+realizzarlo devono essere scambiati tre segmenti.  In \figref{fig:TCPel_TWH}
+si è rappresentata graficamente la sequenza di scambio dei segmenti che
+stabilisce la connessione.
 
 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
 % sistema del telefono. La funzione \texttt{socket} può essere considerata
@@ -91,11 +91,11 @@ la connessione.
 \end{figure}
 
 Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
-riportati in \curfig); per gestire una connessione affidabile infatti il
-protocollo TCP prevede nell'header la presenza di un numero a 32 bit (chiamato
-appunto \textit{sequence number}) che identifica a quale byte nella sequenza
-del flusso corrisponde il primo byte della sezione dati contenuta nel
-segmento.
+riportati in \figref{fig:TCPel_TWH}); per gestire una connessione affidabile
+infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
+bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
+nella sequenza del flusso corrisponde il primo byte della sezione dati
+contenuta nel segmento.
 
 Il numero di sequenza di ciascun segmento viene calcolato a partire da un
 \textsl{numero di sequenza iniziale} generato in maniera casuale del kernel
@@ -106,7 +106,7 @@ il flag ACK e restituendo nell'apposito campo dell'header un
 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
-varrà anche (vedi \nfig) per l'acknowledgement di un FIN.
+varrà anche (vedi \figref{fig:TCPel_close}) per l'acknowledgement di un FIN.
 
 \subsection{Le opzioni TCP.}
 \label{sec:TCPel_TCP_opt}
@@ -192,8 +192,8 @@ normalmente i segmenti scambiati sono quattro.  Questo non 
 giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
 Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
 effettua la chiusura passiva, siano accorpati in un singolo segmento. In
-\nfig\ si è rappresentato graficamente lo sequenza di scambio dei segmenti che
-stabilisce la connessione.
+\figref{fig:TCPel_close} si è rappresentato graficamente lo sequenza di
+scambio dei segmenti che stabilisce la connessione.
 
 \begin{figure}[htb]
   \centering  
@@ -234,10 +234,11 @@ quali 
 
 Le operazioni del TCP nella creazione e conclusione di una connessione sono
 specificate attraverso il diagramma di transizione degli stati riportato in
-\nfig. TCP prevede l'esistenza di 11 diversi stati per un socket ed un insieme
-di regole per le transizioni da uno stato all'altro basate sullo stato
-corrente e sul tipo di segmento ricevuto; i nomi degli stati sono gli stessi
-che vengono riportati del comando \cmd{netstat} nel campo \textit{State}.
+\figref{fig:TPCel_conn_example}. TCP prevede l'esistenza di 11 diversi stati
+per un socket ed un insieme di regole per le transizioni da uno stato
+all'altro basate sullo stato corrente e sul tipo di segmento ricevuto; i nomi
+degli stati sono gli stessi che vengono riportati del comando \cmd{netstat}
+nel campo \textit{State}.
 
 Una descrizione completa del funzionamento del protocollo va al di là degli
 obiettivi di questo libro; un approfondimento sugli aspetti principali si
@@ -263,9 +264,9 @@ attiva) la transizione 
 l'applicazione riceve un FIN nello stato \texttt{ESTABLISHED} (chiusura
 passiva) la transizione è verso lo stato \texttt{CLOSE\_WAIT}.
 
-In \nfig\ è riportato lo schema dello scambio dei pacchetti che avviene per
-una un esempio di connessione, insieme ai vari stati che il protocollo viene
-ad assumere per i due lati, server e client.
+In \figref{fig:TPCel_conn_example} è riportato lo schema dello scambio dei
+pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
+che il protocollo viene ad assumere per i due lati, server e client.
 
 \begin{figure}[htb]
   \centering
@@ -312,18 +313,18 @@ dati rispondono meglio alle esigenze che devono essere affrontate.
 \subsection{Lo stato \texttt{TIME\_WAIT}}
 \label{sec:TCPel_time_wait}
 
-Come riportato da Stevens (FIXME citare) lo stato \texttt{TIME\_WAIT} è
+Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
 probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
 comune trovare nei newsgroup domande su come sia possibile evitare che
 un'applicazione resti in questo stato lasciando attiva una connessione ormai
 conclusa; la risposta è che non deve essere fatto, ed il motivo cercheremo di
 spiegarlo adesso.
 
-Come si è visto nell'esempio precedente (vedi \curfig) \texttt{TIME\_WAIT} è
-lo stato finale in cui il capo di una connessione che esegue la chiusura
-attiva resta prima di passare alla chiusura definitiva della connessione. Il
-tempo in cui l'applicazione resta in questo stato deve essere due volte la MSL
-(\textit{Maximum Segment Lifetime}). 
+Come si è visto nell'esempio precedente (vedi \figref{fig:TPCel_conn_example})
+\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
+esegue la chiusura attiva resta prima di passare alla chiusura definitiva
+della connessione. Il tempo in cui l'applicazione resta in questo stato deve
+essere due volte la MSL (\textit{Maximum Segment Lifetime}).
 
 La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
@@ -354,13 +355,14 @@ riferimento solo alla prima; ma 
 capisce il perché della scelta di un tempo pari al doppio della MSL come
 durata di questo stato.
 
-Il primo dei due motivi precedenti si può capire tornando a \curfig: assumendo
-che l'ultimo ACK della sequenza (quello del capo che ha eseguito la chiusura
-attiva) vanga perso, chi esegue la chiusura passiva non ricevendo risposta
-rimanderà un ulteriore FIN, per questo motivo chi esegue la chiusura attiva
-deve mantenere lo stato della connessione per essere in grado di reinviare
-l'ACK e chiuderla correttamente. Se non fosse così la risposta sarebbe un RST
-(un altro tipo si segmento) che verrebbe interpretato come un errore.
+Il primo dei due motivi precedenti si può capire tornando a
+\figref{fig:TPCel_conn_example}: assumendo che l'ultimo ACK della sequenza
+(quello del capo che ha eseguito la chiusura attiva) vanga perso, chi esegue
+la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
+questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
+connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
+Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
+verrebbe interpretato come un errore.
 
 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
 connessione allora deve essere in grado di affrontare la perdita di uno
@@ -469,10 +471,11 @@ in tre intervalli:
 \end{enumerate}
 
 In realtà rispetto a quanto indicato nell'RFC~1700 i vari sistemi hanno fatto
-scelte diverse per le porte effimere, in particolare in \nfig\ sono riportate
-quelle di BSD, Solaris e Linux. Nel caso di Linux poi la scelta fra i due
-intervalli possibili viene fatta dinamicamente a seconda della memoria a
-disposizione del kernel per gestire le relative tabelle.
+scelte diverse per le porte effimere, in particolare in
+\figref{fig:TCPel_port_alloc} sono riportate quelle di BSD, Solaris e Linux.
+Nel caso di Linux poi la scelta fra i due intervalli possibili viene fatta
+dinamicamente a seconda della memoria a disposizione del kernel per gestire le
+relative tabelle.
 
 \begin{figure}[!htb]
   \centering
@@ -606,12 +609,12 @@ l'uso dei socket TCP gi
 della funzione \func{socket} che è già stata esaminata in dettaglio in
 \secref{sec:sock_socket}.
 
-In \nfig\ abbiamo un tipico schema di funzionamento di un'applicazione
-client-server che usa i socket TCP: prima il server viene avviato ed in
-seguito il client si connette, in questo caso, a differenza di quanto accadeva
-con gli esempi elementari del \capref{cha:network} si assume che sia il
-client ad effettuare delle richieste a cui il server risponde, il client
-notifica poi di avere concluso inviando un end-of-file a cui il server
+In \figref{fig:TCPel_cliserv_func} abbiamo un tipico schema di funzionamento
+di un'applicazione client-server che usa i socket TCP: prima il server viene
+avviato ed in seguito il client si connette, in questo caso, a differenza di
+quanto accadeva con gli esempi elementari del \capref{cha:network} si assume
+che sia il client ad effettuare delle richieste a cui il server risponde, il
+client notifica poi di avere concluso inviando un end-of-file a cui il server
 risponderà anche lui chiudendo la connessione per aspettarne una nuova.
 
 \begin{figure}[!htb]
@@ -862,16 +865,16 @@ infatti vengono mantenute due code:
   Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
 \end{enumerate}
 
-Lo schema di funzionamento è descritto in \nfig, quando arriva un SYN da un
-client il server crea una nuova entrata nella coda delle connessioni
-incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà nella coda
-delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad
-un timeout. Nel caso di completamento del three way handshake l'entrata viene
-sostata nella coda delle connessioni complete. Quando il processo chiama la
-funzione \func{accept} (vedi \secref{sec:TCPel_func_accept}) la prima
-entrata nella coda delle connessioni complete è passata al programma, o, se la
-coda è vuota, il processo viene posto in attesa e risvegliato all'arrivo della
-prima connessione completa.
+Lo schema di funzionamento è descritto in \figref{fig:TCPel_xxx}, quando
+arriva un SYN da un client il server crea una nuova entrata nella coda delle
+connessioni incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà
+nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
+client o fino ad un timeout. Nel caso di completamento del three way handshake
+l'entrata viene sostata nella coda delle connessioni complete. Quando il
+processo chiama la funzione \func{accept} (vedi
+\secref{sec:TCPel_func_accept}) la prima entrata nella coda delle connessioni
+complete è passata al programma, o, se la coda è vuota, il processo viene
+posto in attesa e risvegliato all'arrivo della prima connessione completa.
 
 Storicamente il valore del parametro \var{backlog} era corrispondente al
 massimo valore della somma del numero di entrate possibili per ciascuna di
@@ -1073,9 +1076,9 @@ concorrente abbiamo riscritto il server \texttt{daytime} dell'esempio
 precedente in forma concorrente, inserendo anche una opzione per la stampa
 degli indirizzi delle connessioni ricevute.
 
-In \nfig\ è mostrato un estratto del codice, in cui si sono tralasciati il
-trattamento delle opzioni e le parti rimaste invariate rispetto al precedente
-esempio. Al solito il sorgente completo del server
+In \figref{fig:TCPel_serv_code} è mostrato un estratto del codice, in cui si
+sono tralasciati il trattamento delle opzioni e le parti rimaste invariate
+rispetto al precedente esempio. Al solito il sorgente completo del server
 \file{ElemDaytimeTCPCuncServ.c} è allegato nella directory dei sorgenti.
 
 \begin{figure}[!htb]
index 0d6e2f0..4543962 100644 (file)
@@ -1315,10 +1315,21 @@ Il comportamento della funzione 
   \label{tab:file_flock_operation}
 \end{table}
 
+
+Con \func{flock} il blocco è associato direttamente al file (cioè rispetto
+allo schema di \secref{sec:file_fd} fa riferimento all'inode e non al file
+descriptor); pertanto sia \func{dup} che \func{fork} non creano altre istanze
+del blocco ma piuttosto degli ulteriori riferimenti allo stesso \textit{file
+  lock}. 
+
 La funzione blocca direttamente il file (cioè rispetto allo schema di
-\secref{fig:file_stat_struct} fa riferimento all'inode, non al file
-descriptor). Pertanto sia \func{dup} che \func{fork} non creano altre istanze
-di un \textit{file lock}.
+\secref{fig:file_stat_struct} fa riferimento alla struttura \var{file}, non al
+file descriptor). Pertanto sia \func{dup} che \func{fork} non creano ulteriori
+istanze di un \textit{file lock} quanto piuttosto degli ulteriori riferimenti
+allo stesso \textit{file lock}. Questo comporta che un lock può essere rimosso
+su uno qualunque dei file descriptor che fanno riferimento allo stesso file,
+ed esso .
+
 
 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
index 30d71ca..2832634 100644 (file)
@@ -305,10 +305,11 @@ che non esiste: in questo caso si ha quello che viene chiamato un
 \textit{dangling link}, letteralmente un \textsl{link ciondolante}.
 
 Come accennato i link simbolici sono risolti automaticamente dal kernel
-all'invocazione delle varie system call; in \ntab\ si è riportato un elenco
-dei comportamenti delle varie funzioni di libreria che operano sui file nei
-confronti della risoluzione dei link simbolici, specificando quali seguono il
-link simbolico e quali invece possono operare direttamente sul suo contenuto.
+all'invocazione delle varie system call; in \tabref{tab:file_symb_effect} si è
+riportato un elenco dei comportamenti delle varie funzioni di libreria che
+operano sui file nei confronti della risoluzione dei link simbolici,
+specificando quali seguono il link simbolico e quali invece possono operare
+direttamente sul suo contenuto.
 \begin{table}[htb]
   \centering
   \footnotesize
@@ -386,15 +387,15 @@ stringa con un carattere nullo e la tronca alla dimensione specificata da
 \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 in grado di leggere direttamente da vari filesystem il file da
-  lanciare come sistema operativo) di vedere i file in questa directory con lo
-  stesso path con cui verrebbero visti dal sistema operativo, anche se essi si
-  trovano, come è solito, su una partizione separata (e che \cmd{grub}
-  vedrebbe come radice).}
+cosiddetti \textit{loop}. La situazione è illustrata in
+\figref{fig:file_link_loop}, 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 in grado di leggere
+  direttamente da vari filesystem il file da lanciare come sistema operativo)
+  di vedere i file in questa directory con lo stesso path con cui verrebbero
+  visti dal sistema operativo, anche se essi si trovano, come è solito, su una
+  partizione separata (e che \cmd{grub} vedrebbe come radice).}
 
 Questo può causare problemi per tutti quei programmi che effettuano la
 scansione di una directory senza tener conto dei link simbolici, ad esempio se
@@ -919,10 +920,10 @@ su un file, su un link simbolico e su un file descriptor.
 
 La struttura \var{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione, la versione
-usata da Linux è mostrata in \nfig, così come riportata dalla pagina di
-manuale di \func{stat} (in realtà la definizione effettivamente usata nel
-kernel dipende dall'architettura e ha altri campi riservati per estensioni
-come tempi più precisi, o per il padding dei campi).
+usata da Linux è mostrata in \figref{fig:file_stat_struct}, così come
+riportata dalla pagina di manuale di \func{stat} (in realtà la definizione
+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
@@ -970,7 +971,7 @@ standard POSIX definisce un insieme di macro per verificare il tipo di files,
 queste vengono usate anche da Linux che supporta pure le estensioni allo
 standard per i link simbolici e i socket definite da BSD; l'elenco completo
 delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
-riportato in \ntab.
+riportato in \tabref{tab:file_type_macro}.
 \begin{table}[htb]
   \centering
   \footnotesize
@@ -995,9 +996,10 @@ riportato in \ntab.
 Oltre alle macro di \tabref{tab:file_type_macro} è possibile usare
 direttamente il valore di \var{st\_mode} per ricavare il tipo di file
 controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in \ntab.
+\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\tabref{tab:file_mode_flags}.
 
-Il primo valore dell'elenco di \secref{tab:file_mode_flags} è la maschera
+Il primo valore dell'elenco di \tabref{tab:file_mode_flags} è la maschera
 binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
 file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
 possono essere usati per effettuare la selezione sul tipo di file voluto, con
@@ -1132,8 +1134,9 @@ Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
 nell'inode insieme agli altri attributi del file e possono essere letti
 tramite la funzione \func{stat}, che li restituisce attraverso tre campi della
 struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti
-tempi e dei relativi campi è riportato nello schema in \ntab, dove si è anche
-riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
+tempi e dei relativi campi è riportato nello schema in
+\tabref{tab:file_file_times}, dove si è anche riportato un esempio delle
+funzioni che effettuano cambiamenti su di essi.
 
 \begin{table}[htb]
   \centering
@@ -1176,14 +1179,14 @@ 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.
+nell'ultima colonna di \tabref{tab:file_file_times}.
 
 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 file (che contengono una lista di nomi) che il sistema tratta
-in maniera del tutto analoga a tutti gli altri.
+illustrato in \tabref{tab:file_times_effects}. 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 file (che contengono una lista di nomi) che
+il sistema tratta in maniera del tutto analoga a tutti gli altri.
 
 Per questo motivo tutte le volte che compiremo un'operazione su un file che
 comporta una modifica del nome contenuto nella directory, andremo anche a
@@ -1389,7 +1392,7 @@ distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,
 si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
 ed \textit{all}, le cui iniziali possono dar luogo a confusione.  Le costanti
 che permettono di accedere al valore numerico di questi bit nel campo
-\var{st\_mode} sono riportate in \ntab.
+\var{st\_mode} sono riportate in \tabref{tab:file_bit_perm}.
 
 \begin{table}[htb]
   \centering
index 359a1e2..794d611 100644 (file)
@@ -471,7 +471,8 @@ metodi che implementano le operazioni disponibili sul file. In questo modo i
 processi in user space possono accedere alle operazioni attraverso detti
 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
 (su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
-operazioni previste dal kernel è riportato in \ntab.
+operazioni previste dal kernel è riportato in
+\tabref{tab:file_file_operations}.
 
 \begin{table}[htb]
   \centering
@@ -533,13 +534,14 @@ alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
 Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
 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 \acr{ext2}, che prevede una separazione dei dati
-in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
-di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem per 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.
+dell'informazione su un disco è riportata in \figref{fig:file_disk_filesys};
+in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
+prevede una separazione dei dati in \textit{blocks group} che replicano il
+superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
+\secref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+filesystem per 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
@@ -553,7 +555,8 @@ 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.
+esemplificare la situazione con uno schema come quello esposto in
+\figref{fig:file_filesys_detail}.
 
 \begin{figure}[htb]
   \centering
@@ -562,11 +565,11 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
   \label{fig:file_filesys_detail}
 \end{figure}
 
-Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
-filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
-per capire il funzionamento delle funzioni che manipolano i file e le
-directory che tratteremo nel prossimo capitolo; in particolare è opportuno
-ricordare sempre che:
+Da \figref{fig:file_filesys_detail} si evidenziano alcune delle
+caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
+visto che sono fondamentali per capire il funzionamento delle funzioni che
+manipolano i file e le directory che tratteremo nel prossimo capitolo; in
+particolare è opportuno ricordare sempre che:
 
 \begin{enumerate}
   
@@ -579,15 +582,15 @@ ricordare sempre che:
   traduzione dell'inglese \textit{directory entry}, che non useremo anche per
   evitare confusione con le \textit{dentry} del kernel di cui si parlava in
   \secref{sec:file_vfs}).
-
-\item Come mostrato in \curfig\ si possono avere più voci che puntano allo
-  stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
-  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 \func{unlink}, ed in realtà non cancella affatto i dati del
-  file, ma si limita ad eliminare la relativa voce da una directory e
-  decrementare il numero di riferimenti nell'\textit{inode}.
+  
+\item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
+  voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
+  contatore che contiene il 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 \func{unlink}, ed in realtà non cancella
+  affatto i dati del file, ma si limita ad 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
@@ -605,9 +608,10 @@ ricordare sempre che:
 
 Infine è bene avere presente che, essendo file pure loro, esiste un numero di
 riferimenti anche per le directory; per cui, se a partire dalla situazione
-mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
-\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza
-abbiamo aggiunto dei numeri di inode.
+mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory
+\file{img} nella directory \file{gapil}, avremo una situazione come quella in
+\figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di
+inode.
 
 \begin{figure}[htb]
   \centering 
@@ -686,9 +690,9 @@ inode.
 
 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.
+lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
+\figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per
+i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.
 
 
 
index cec06e3..bd3ed09 100644 (file)
@@ -138,10 +138,11 @@ posto di questi valori numerici:
   \label{tab:file_std_files}
 \end{table}
 
-In \curfig\ si è utilizzata questa situazione come esempio, facendo
-riferimento ad un programma in cui lo \textit{standard input} è associato ad
-un file mentre lo \textit{standard output} e lo \textit{standard error} sono
-entrambi associati ad un altro file (e quindi utilizzano lo stesso inode).
+In \figref{tab:file_std_files} si è utilizzata questa situazione come esempio,
+facendo riferimento ad un programma in cui lo \textit{standard input} è
+associato ad un file mentre lo \textit{standard output} e lo \textit{standard
+  error} sono entrambi associati ad un altro file (e quindi utilizzano lo
+stesso inode).
 
 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
 numero di file aperti era anche soggetto ad un limite massimo dato dalle
@@ -335,7 +336,8 @@ La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire
 il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
 campo \var{f\_flags} della struttura \var{file} (al solito si veda lo schema
-di \curfig).  Essi sono divisi in tre categorie principali:
+di \figref{fig:file_proc_file}).  Essi sono divisi in tre categorie
+principali:
 \begin{itemize}
 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
   si accederà al file: i valori possibili sono lettura, scrittura o
index 3140c28..c37cd34 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -21,8 +21,8 @@
 \usepackage{listings}
 \lstloadlanguages{C++}
 \usepackage{color} 
-%\usepackage{mdwlist}              % scommentare per la stampa (PS e PDF)
-%\usepackage{boxedminipage}        % scommentare per la stampa (PS e PDF)
+\usepackage{mdwlist}              % scommentare per la stampa (PS e PDF)
+\usepackage{boxedminipage}        % scommentare per la stampa (PS e PDF)
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 
 %
@@ -73,7 +73,7 @@
 \tableofcontents
 \clearemptydoublepage
 
-\include{compatib}    % commentare per la stampa PS e PDF
+%\include{compatib}    % commentare per la stampa PS e PDF
 \include{macro}
 \setcounter{secnumdepth}{-2}
 \include{pref}
index 818abcb..23598b1 100644 (file)
@@ -680,7 +680,7 @@ 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à viste in precedenza.
 Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
-mostrato in \ntab.
+mostrato in \tabref{tab:IP_ipv6_uninaz}.
 
 \begin{table}[htb]
   \centering
@@ -747,14 +747,13 @@ 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
-è 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} è un
-identificatore che deve essere unico nel dominio in cui viene usato, un modo
-immediato per costruirlo è quello di usare il MAC-address delle schede di
-rete.
+è mostrata in \tabref{tab:IP_ipv6_sitelocal}, 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} è un identificatore che deve essere unico nel dominio in
+cui viene usato, un modo immediato per costruirlo è quello di usare il
+MAC-address delle schede di rete.
  
 \begin{table}[!h]
   \centering
@@ -790,12 +789,12 @@ Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi
 di compatibilità.
 
 Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
-\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 supportati
-sull'host di origine).
+\tabref{tab:IP_ipv6_map}), 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 supportati sull'host di origine).
 
 \begin{table}[!htb]
   \centering
@@ -851,11 +850,11 @@ l'accettazione di una connessione da qualunque host.
 \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.
+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ò appartenere ad un numero qualunque numero di gruppi di
 multicast. Il formato degli indirizzi \textit{multicast} è riportato in
-\ntab:
+\tabref{tab:IP_ipv6_multicast}:
 
 \begin{table}[htb]
   \centering
@@ -887,7 +886,7 @@ Il prefisso di formato per tutti gli indirizzi \textit{multicast} 
   transitorio.
 \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.
+  \tabref{tab:IP_ipv6_multiscope}.
 \end{itemize}
 
 
@@ -1040,7 +1039,7 @@ che indica qual'
 opzioni questa sarà l'intestazione 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.
+presente; i valori possibili sono riportati in \tabref{tab:IP_ipv6_nexthead}.
 
 \begin{table}[htb]
   \begin{center}
index afd290c..33640c5 100644 (file)
--- a/macro.tex
+++ b/macro.tex
@@ -8,31 +8,10 @@
 %
 % Figure commands
 %
-\newcommand{\curfig}{fig.~\thefigure}
-
-\newcommand{\nfig}{%
-\setcounter{usercount}{\value{figure}}%
-\addtocounter{usercount}{1}%
-fig.~\thechapter.\theusercount}
-
-\newcommand{\pfig}{%
-\setcounter{usercount}{\value{figure}}%
-\addtocounter{usercount}{-1}%
-fig.~\thechapter.\theusercount}
-
 \newcommand{\figref}[1]{fig.~\ref{#1}}
 %
 % Tables commands
 %
-\newcommand{\curtab}{tab.~\thetable}
-\newcommand{\ntab}{%
-\setcounter{usercount}{\value{table}}%
-\addtocounter{usercount}{1}%
-tab.~\thechapter.\theusercount}
-\newcommand{\ptab}{%
-\setcounter{usercount}{\value{table}}%
-\addtocounter{usercount}{-1}%
-tab.~\thechapter.\theusercount}
 \newcommand{\tabref}[1]{tab.~\ref{#1}}
 %
 % equations commands
index db2cb4d..6f6148e 100644 (file)
@@ -114,11 +114,11 @@ della Difesa Americano.
 \label{sec:net_tcpip_overview}
 
 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
-\ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
-anche la corrispondenza fra i rispettivi livelli (che comunque è
-approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
-operativo rispetto alla divisione fra user space e kernel space spiegata in
-\secref{sec:intro_unix_struct}.
+\tabref{tab:net_layers}); un confronto fra i due è riportato in
+\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
+fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
+ad inserirsi all'interno del sistema operativo rispetto alla divisione fra
+user space e kernel space spiegata in \secref{sec:intro_unix_struct}.
 
 \begin{table}[htb]
   \centering
@@ -165,8 +165,8 @@ 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.
+\figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso dei dati reali
+e i protocolli usati per lo scambio di informazione su ciascuno livello.
 \begin{figure}[!htb]
   \centering
   \includegraphics[width=10cm]{img/tcp_data_flux}  
@@ -247,16 +247,16 @@ infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perch
 di sopra del livello di trasporto i programmi hanno a che fare solo con
 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
 i dettagli relativi alla comunicazione. È pertanto naturale definire una API
-su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
-nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
-user space.
+su questo confine tanto più che è proprio li (come evidenziato in
+\figref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
+inserita la divisione fra kernel space e user space.
 
-In realtà in un sistema unix è possibile accedere anche agli altri livelli
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli
 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
-è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
-usate solo quando si vogliono fare applicazioni di sistema per il controllo
-della rete a basso livello, un uso quindi molto specialistico, e che non
-rientra in quanto trattato qui.
+è indicata in \figref{fig:net_osi_tcpip_comp} lasciando uno spazio fra UDP e
+TCP), ma queste vengono usate solo quando si vogliono fare applicazioni di
+sistema per il controllo della rete a basso livello, un uso quindi molto
+specialistico, e che non rientra in quanto trattato qui.
 
 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
 concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di
@@ -268,9 +268,9 @@ nella maggior parte delle applicazioni.
 \label{sec:net_tcpip_general}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
-altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
-vari protocolli della famiglia, e delle loro relazioni reciproche e con
-alcune dalle principali applicazioni che li usano.
+altri membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
+mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni
+reciproche e con alcune dalle principali applicazioni che li usano.
 
 \begin{figure}[!htbp]
   \centering
@@ -523,7 +523,7 @@ loro origini ed alle eventuali implicazioni che possono avere:
 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
   dipende dal protocollo specifico usato al livello di link. Il più comune è
   quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
-  sono riportati in \ntab.
+  sono riportati in \tabref{tab:net_mtu_values}.
 \end{itemize}
 
 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
index e5e4b50..9a23884 100644 (file)
@@ -222,7 +222,7 @@ volontariamente la sua esecuzione 
 \func{exit} o il ritorno di \func{main}.
 
 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
-normalmente un programma è riportato in \nfig.
+normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.
 
 \begin{figure}[htb]
   \centering
@@ -233,7 +233,8 @@ normalmente un programma 
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-\curfig); torneremo su questo aspetto in \capref{cha:signals}.
+\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+\capref{cha:signals}.
 
 
 
@@ -842,7 +843,7 @@ Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 variabile \var{argc} viene inizializzata al numero di parametri trovati, in
 questo modo il primo parametro è sempre il nome del programma; un esempio di
-questo meccanismo è mostrato in \curfig.
+questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.
 
 
 \subsection{La gestione delle opzioni}
@@ -1015,9 +1016,9 @@ pi
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
-in \curfig, sono definite dal sistema per essere usate da diversi programmi e
-funzioni: per queste c'è l'ulteriore convenzione di usare nomi espressi in
-caratteri maiuscoli.
+in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
+da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
+usare nomi espressi in caratteri maiuscoli.
 
 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
@@ -1034,8 +1035,9 @@ programmi (come \var{EDITOR} che indica l'editor preferito da invocare in caso
 di necessità).
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
-comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce
-anche altre: per una lista più completa si può controllare \cmd{man environ}.
+comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta
+tutte e ne definisce anche altre: per una lista più completa si può
+controllare \cmd{man environ}.
 
 \begin{table}[htb]
   \centering
@@ -1082,7 +1084,7 @@ Oltre a questa funzione di lettura, che 
 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
 delle funzioni previste nei vari standard e disponibili in Linux è riportato
-in \ntab.
+in \tabref{tab:proc_env_func}.
 
 \begin{table}[htb]
   \centering
@@ -1108,9 +1110,9 @@ in \ntab.
   \label{tab:proc_env_func}
 \end{table}
 
-In Linux solo le prime quattro funzioni di \curtab\ sono definite,
-\func{getenv} l'abbiamo già esaminata; delle tre restanti le prime due,
-\func{putenv} e \func{setenv}, servono per assegnare nuove variabili di
+In Linux solo le prime quattro funzioni di \tabref{tab:proc_env_func} sono
+definite, \func{getenv} l'abbiamo già esaminata; delle tre restanti le prime
+due, \func{putenv} e \func{setenv}, servono per assegnare nuove variabili di
 ambiente, i loro prototipi sono i seguenti:
 \begin{functions}
   \headdecl{stdlib.h} 
index af65598..534049e 100644 (file)
@@ -109,9 +109,10 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda
-\secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
-comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
-base c'è \cmd{init} che è progenitore di tutti gli altri processi.
+\secref{sec:file_organization}); in \figref{fig:proc_tree} si è mostrato il
+risultato del comando \cmd{pstree} che permette di visualizzare questa
+struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
+processi.
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
 \textit{process table}; per ciascun processo viene mantenuta una voce nella
@@ -1124,10 +1125,11 @@ linea di comando e l'ambiente ricevuti dal nuovo processo.
 \end{functions}
 
 Per capire meglio le differenze fra le funzioni della famiglia si può fare
-riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
-le modalità di passaggio dei parametri che poi andranno a costituire gli
-argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
-dalla funzione \func{main} del programma chiamato). 
+riferimento allo specchietto riportato in \tabref{tab:proc_exec_scheme}. La
+prima differenza riguarda le modalità di passaggio dei parametri che poi
+andranno a costituire gli argomenti a linea di comando (cioè i valori di
+\var{argv} e \var{argc} visti dalla funzione \func{main} del programma
+chiamato).
 
 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
index b9d99e6..8a6b2ae 100644 (file)
@@ -121,14 +121,15 @@ alla funzione \code{ServEcho}.
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 
-Il codice della funzione \code{ServEcho} è invece mostrata in \nfig, la
-comunicazione viene gestita all'interno del ciclo (linee \texttt{\small
-  6--8}).  I dati inviati dal client vengono letti dal socket con una semplice
-\func{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura
-viene invece gestita dalla funzione \func{SockWrite} (descritta in
-\figref{fig:sock_SockWrite_code}) che si incarica di tenere conto
-automaticamente della possibilità che non tutti i dati di cui è richiesta la
-scrittura vengano trasmessi con una singola \func{write}.
+Il codice della funzione \code{ServEcho} è invece mostrata in
+\figref{fig:TCPsimpl_server_elem_sub}, la comunicazione viene gestita
+all'interno del ciclo (linee \texttt{\small 6--8}).  I dati inviati dal client
+vengono letti dal socket con una semplice \func{read} (che ritorna solo in
+presenza di dati in arrivo), la riscrittura viene invece gestita dalla
+funzione \func{SockWrite} (descritta in \figref{fig:sock_SockWrite_code}) che
+si incarica di tenere conto automaticamente della possibilità che non tutti i
+dati di cui è richiesta la scrittura vengano trasmessi con una singola
+\func{write}.
 
 \begin{figure}[!htb]
   \footnotesize
index 98a79a6..ef729a5 100644 (file)
@@ -785,8 +785,9 @@ ssize_t SockRead(int fd, void *buf, size_t count)
 Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due
 funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un
 socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo
-avere letto o scritto esattamente il numero di byte specificato; il sorgente
-è riportato in \curfig\ e \nfig\ ed è disponibile fra i sorgenti allegati alla
+avere letto o scritto esattamente il numero di byte specificato; il sorgente è
+riportato in \figref{fig:sock_SockRead_code} e
+\figref{fig:sock_SockWrite_code} ed è disponibile fra i sorgenti allegati alla
 guida nei files \file{SockRead.c} e \file{SockWrite.c}.
 
 \begin{figure}[htb]
index 310cd85..c474854 100644 (file)
@@ -755,7 +755,7 @@ significativi sono un \textit{magic number}\footnote{cio
   riservata al \textit{magic number}.} mentre i 16 meno significativi sono
 usati per specificare le opzioni; essi sono usati come maschera binaria e
 vanno impostati con un OR aritmetico della costante \macro{MS\_MGC\_VAL} con i
-valori riportati in \ntab.
+valori riportati in \tabref{tab:sys_mount_flags}.
 
 \begin{table}[htb]
   \footnotesize