Modifiche al sito

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index e309ea954febb4b20c99265896fda52e9001c1b7..0d9de52bd9977d16c014fc8a868231d45b3692e1 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -1,6 +1,6 @@
-% fileintro.tex
+%% fileintro.tex

 %%
 %%

-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2004 Simone Piccardi.  Permission is granted to

 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",


@@ -40,12 +40,12 @@ programmi le opportune interfacce che consentano di leggerne il contenuto; il
 sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
 opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
 Questo viene fatto strutturando l'informazione sul disco attraverso quello che
 sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
 opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
 Questo viene fatto strutturando l'informazione sul disco attraverso quello che

-si chiama un \textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi
-viene resa disponibile ai processi attraverso quello che viene chiamato il
+si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa
+poi viene resa disponibile ai processi attraverso quello che viene chiamato il

 \textsl{montaggio} del \textit{filesystem}.
 \textsl{montaggio} del \textit{filesystem}.

-% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
+% (approfondiremo tutto ciò in sez.~\ref{sec:file_arch_func}).

 
 

-In questa sezione faremo una panormamica generica su come il sistema presenta
+In questa sezione faremo una panoramica generica su come il sistema presenta

 i file ai processi, trattando l'organizzazione di file e directory, i tipi di
 file ed introducendo le interfacce disponibili e le loro caratteristiche.
 
 i file ai processi, trattando l'organizzazione di file e directory, i tipi di
 file ed introducendo le interfacce disponibili e le loro caratteristiche.
 


@@ -69,7 +69,7 @@ accedere al file a partire dalla \textit{root directory}, che 
 una serie di nomi separati da una \file{/}.
 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 una serie di nomi separati da una \file{/}.
 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel

-riceve dal boot loader l'indicazione di quale dispositivo contiene il
+riceve dal bootloader l'indicazione di quale dispositivo contiene il

 filesystem da usare come punto di partenza e questo viene montato come radice
 dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
 che possono essere su altri dispositivi dovranno poi essere inseriti
 filesystem da usare come punto di partenza e questo viene montato come radice
 dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
 che possono essere su altri dispositivi dovranno poi essere inseriti


@@ -81,7 +81,7 @@ alcune strutture interne del kernel) sono generati automaticamente dal kernel
 stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
 
 Una directory, come vedremo in maggior dettaglio in
 stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
 
 Una directory, come vedremo in maggior dettaglio in

-\secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+sez.~\ref{sec:file_vfs_work}, è anch'essa un file, solo che è un file

 particolare che il kernel riconosce come tale. Il suo scopo è quello di
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
 particolare che il kernel riconosce come tale. Il suo scopo è quello di
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque


@@ -107,16 +107,16 @@ precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
   costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
 perché il procedimento funzioni, occorre che i nomi indicati come directory
 esistano e siano effettivamente directory, inoltre i permessi (si veda
   costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
 perché il procedimento funzioni, occorre che i nomi indicati come directory
 esistano e siano effettivamente directory, inoltre i permessi (si veda

-\secref{sec:file_access_control}) devono consentire l'accesso all'intero
+sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero

 \textit{pathname}.
 
 Se il \textit{pathname}\index{pathname} comincia per \file{/} la ricerca parte
 dalla directory radice del processo; questa, a meno di un \func{chroot} (su
 \textit{pathname}.
 
 Se il \textit{pathname}\index{pathname} comincia per \file{/} la ricerca parte
 dalla directory radice del processo; questa, a meno di un \func{chroot} (su

-cui torneremo in \secref{sec:file_chroot}) è la stessa per tutti i processi ed
-equivale alla directory radice dell'albero dei file: in questo caso si parla
-di un \textsl{pathname assoluto}\index{pathname!assoluto}. Altrimenti la
+cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi
+ed equivale alla directory radice dell'albero dei file: in questo caso si
+parla di un \textsl{pathname assoluto}\index{pathname!assoluto}. Altrimenti la

 ricerca parte dalla directory corrente (su cui torneremo in
 ricerca parte dalla directory corrente (su cui torneremo in

-\secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
+sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname

   relativo}\index{pathname!relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
   relativo}\index{pathname!relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti


@@ -132,18 +132,18 @@ se stessa.
 
 Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 
 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:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
+sez.~\ref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like

 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 \textit{Virtual File System}\index{Virtual File System} è riportato in
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 \textit{Virtual File System}\index{Virtual File System} è riportato in

-\tabref{tab:file_file_types}.
+tab.~\ref{tab:file_file_types}.

 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 la classificazione dei file (che in questo caso sono sempre file di dati) in
 base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
 oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
 Alcuni di essi, come le \textit{fifo} (che tratteremo in
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 la classificazione dei file (che in questo caso sono sempre file di dati) in
 base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
 oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
 Alcuni di essi, come le \textit{fifo} (che tratteremo in

-\secref{sec:ipc_named_pipe}) ed i \textit{socket}\index{socket} (che
-tratteremo in \capref{cha:socket_intro}) non sono altro che dei riferimenti
+sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket}\index{socket} (che
+tratteremo in cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti

 per utilizzare delle funzionalità di comunicazione fornite dal kernel. Gli
 altri sono i \textsl{file di dispositivo}\index{file!di dispositivo} (o
 \textit{device file}) che costituiscono una interfaccia diretta per leggere e
 per utilizzare delle funzionalità di comunicazione fornite dal kernel. Gli
 altri sono i \textsl{file di dispositivo}\index{file!di dispositivo} (o
 \textit{device file}) che costituiscono una interfaccia diretta per leggere e


@@ -168,19 +168,19 @@ in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       un file che contiene una lista di nomi associati a degli
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       un file che contiene una lista di nomi associati a degli

-      \textit{inode}\index{inode} (vedi \secref{sec:file_vfs}).  \\
+      \textit{inode}\index{inode} (vedi sez.~\ref{sec:file_vfs}).  \\

       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &
       un file che identifica una periferica ad accesso a caratteri \\
       \textit{block device} & \textsl{dispositivo a blocchi} &
       un file che identifica una periferica ad accesso a blocchi \\
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &
       un file che identifica una periferica ad accesso a caratteri \\
       \textit{block device} & \textsl{dispositivo a blocchi} &
       un file che identifica una periferica ad accesso a blocchi \\

-      \textit{fifo} & \textsl{``coda''} &
+      \textit{fifo} & ``\textsl{coda}'' &

       un file speciale che identifica una linea di comunicazione software
       un file speciale che identifica una linea di comunicazione software

-      unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\
-      \textit{socket}\index{socket} & \textsl{``presa''} &
+      unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
+      \textit{socket}\index{socket} & ``\textsl{presa}''&

       un file speciale che identifica una linea di comunicazione software
       un file speciale che identifica una linea di comunicazione software

-      bidirezionale (vedi \capref{cha:socket_intro}) \\
+      bidirezionale (vedi cap.~\ref{cha:socket_intro}) \\

     \hline
     \end{tabular}
     \caption{Tipologia dei file definiti nel VFS}
     \hline
     \end{tabular}
     \caption{Tipologia dei file definiti nel VFS}


@@ -192,12 +192,12 @@ Windows) 
 flusso continuo di byte. 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
 flusso continuo di byte. 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.\footnote{questo vale
-  anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di
-  dimensione fissa avviene solo all'interno del kernel, ed è completamente
-  trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
-    diretto} riferendosi alla capacità, che non ha niente a che fare con tutto
-  ciò, di effettuare, attraverso degli appositi file di
+il cosiddetto ``\textsl{accesso diretto}'' come nel caso del
+VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
+  dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
+  ed è completamente trasparente all'utente. Inoltre talvolta si parla di
+  \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
+  fare con tutto ciò, di effettuare, attraverso degli appositi file di

   dispositivo\index{file!di dispositivo}, operazioni di I/O direttamente sui
   dischi senza passare attraverso un filesystem (il cosiddetto \textit{raw
     access}, introdotto coi kernel della serie 2.4.x).}
   dispositivo\index{file!di dispositivo}, operazioni di I/O direttamente sui
   dischi senza passare attraverso un filesystem (il cosiddetto \textit{raw
     access}, introdotto coi kernel della serie 2.4.x).}


@@ -236,10 +236,10 @@ 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
 accedere al loro contenuto.
 
 La prima è l'interfaccia standard di Unix, quella che il manuale delle

-\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
-  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce 
+\textsl{glibc} chiama interfaccia dei descrittori di file (o \textit{file
+  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce

 un accesso non bufferizzato; la tratteremo in dettaglio in
 un accesso non bufferizzato; la tratteremo in dettaglio in

-\capref{cha:file_unix_interface}.
+cap.~\ref{cha:file_unix_interface}.

 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando


@@ -252,7 +252,8 @@ L'interfaccia 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 \textit{stream}\index{file!stream}. Essa fornisce funzioni più evolute e un
 accesso bufferizzato (controllato dalla implementazione fatta dalle
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 \textit{stream}\index{file!stream}. Essa fornisce funzioni più evolute e un
 accesso bufferizzato (controllato dalla implementazione fatta dalle

-\acr{glibc}), la tratteremo in dettaglio nel \capref{cha:files_std_interface}.
+\acr{glibc}), la tratteremo in dettaglio nel
+cap.~\ref{cha:files_std_interface}.

 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \textit{stream}\index{file!stream} sono
 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \textit{stream}\index{file!stream} sono


@@ -264,12 +265,12 @@ utilizzando il tipo \ctyp{FILE *}.  L'interfaccia 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 altri oggetti del VFS (fifo, socket\index{socket}, device, sui quali torneremo
 in dettaglio a tempo opportuno), ma per poter accedere alle operazioni di
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 altri oggetti del VFS (fifo, socket\index{socket}, device, sui quali torneremo
 in dettaglio a tempo opportuno), ma per poter accedere alle operazioni di

-controllo (descritte in \secref{sec:file_fcntl} e \secref{sec:file_ioctl}) su
-un qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di
-Unix con i \textit{file descriptor}. Allo stesso modo devono essere usati i
+controllo (descritte in sez.~\ref{sec:file_fcntl} e sez.~\ref{sec:file_ioctl})
+su un qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard
+di Unix con i \textit{file descriptor}. Allo stesso modo devono essere usati i

 \textit{file descriptor}\index{file!descriptor} se si vuole ricorrere a
 modalità speciali di I/O come il \textit{file locking}\index{file!locking} o
 \textit{file descriptor}\index{file!descriptor} se si vuole ricorrere a
 modalità speciali di I/O come il \textit{file locking}\index{file!locking} o

-l'I/O non-bloccante (vedi \capref{cha:file_advanced}).
+l'I/O non-bloccante (vedi cap.~\ref{cha:file_advanced}).

 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 quella dei \textit{file descriptor}, che permette di poter scegliere tra
 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 quella dei \textit{file descriptor}, che permette di poter scegliere tra


@@ -333,12 +334,12 @@ portabilit
 % 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:file_link}) aprire un file provvisorio per
+% in dettaglio in sez.~\ref{sec:file_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.
 

-% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
+% Ritorneremo su questo più avanti in sez.~\ref{sec:file_fd}, quando tratteremo

 % l'input/output sui file, esaminando in dettaglio come tutto ciò viene
 % realizzato.
 
 % l'input/output sui file, esaminando in dettaglio come tutto ciò viene
 % realizzato.
 


@@ -346,12 +347,12 @@ portabilit
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
 
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
 

-Per capire fino in fondo le proprietà di file e directory in un sistema
-unix-like ed il comportamento delle relative funzioni di manipolazione,
-occorre una breve introduzione al funzionamento gestione dei file da parte del
-kernel e sugli oggetti su cui è basato un filesystem. 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}.
+%% Per capire fino in fondo le proprietà di file e directory in un sistema
+%% unix-like ed il comportamento delle relative funzioni di manipolazione,
+%% occorre una breve introduzione al funzionamento della gestione dei file da
+%% parte del kernel e sugli oggetti su cui è basato un filesystem. In particolare
+%% occorre tenere presente dov'è che si situa la divisione fondamentale fra
+%% kernel space e user space che tracciavamo al cap.~\ref{cha:intro_unix}.

 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo


@@ -362,7 +363,7 @@ Linux, l'\acr{ext2}.
 % 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
 % 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:file_vfs}.
+% sez.~\ref{sec:file_vfs}.

 
 
 \subsection{Il \textit{Virtual File System} di Linux}
 
 
 \subsection{Il \textit{Virtual File System} di Linux}


@@ -390,7 +391,7 @@ manipolazioni sulle strutture generiche e utilizzer
 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
 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

-\figref{fig:file_VFS_scheme}.
+fig.~\ref{fig:file_VFS_scheme}.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -409,14 +410,14 @@ 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 è chiamare la funzione
 \code{register\_filesystem} passandole un'apposita struttura
 filesystem supportato: quando si vuole inserire il supporto di un nuovo
 filesystem tutto quello che occorre è chiamare la funzione
 \code{register\_filesystem} passandole un'apposita struttura

-(\var{file\_system\_type}) che contiene i dettagli per il riferimento
+\code{file\_system\_type} che contiene i dettagli per il riferimento

 all'implementazione del 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
 all'implementazione del 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 \secref{sec:file_ext2}), inizializzare tutte le variabili
+il superblock (vedi sez.~\ref{sec:file_ext2}), inizializzare tutte le variabili

 interne e restituire uno speciale descrittore dei filesystem montati al VFS;
 attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
 l'uso di quel filesystem.
 interne e restituire uno speciale descrittore dei filesystem montati al VFS;
 attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
 l'uso di quel filesystem.


@@ -453,8 +454,8 @@ Una singola \textit{dentry} contiene in genere il puntatore ad un
 disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
 una directory, un link simbolico, una FIFO, un file di
 dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa
 disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
 una directory, un link simbolico, una FIFO, un file di
 dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa

-essere rappresentata dal VFS (i tipi di ``file'' riportati in
-\tabref{tab:file_file_types}). A ciascuno di essi è associata pure una
+essere rappresentata dal VFS (i tipi di file riportati in
+tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una

 struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
 file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
 da usare per poterlo manipolare.
 struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
 file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
 da usare per poterlo manipolare.


@@ -484,14 +485,14 @@ la \func{open} per aprire il file o la \func{stat} per leggere i dati
 dell'inode\index{inode} e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 dell'inode\index{inode} e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di

-una struttura di tipo \var{file} in cui viene inserito un puntatore alla
-\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
+una struttura di tipo \struct{file} in cui viene inserito un puntatore alla
+\textit{dentry} e una struttura \struct{f\_ops} che contiene i puntatori ai

 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
 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
+(su questo torneremo in dettaglio in sez.~\ref{sec:file_fd}). Un elenco delle

 operazioni previste dal kernel è riportato in
 operazioni previste dal kernel è riportato in

-\tabref{tab:file_file_operations}.
+tab.~\ref{tab:file_file_operations}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -501,24 +502,25 @@ operazioni previste dal kernel 
     \textbf{Funzione} & \textbf{Operazione} \\
     \hline
     \hline
     \textbf{Funzione} & \textbf{Operazione} \\
     \hline
     \hline

-    \textsl{\code{open}}   & apre il file (vedi \secref{sec:file_open}). \\
-    \textsl{\code{read}}   & legge dal file (vedi \secref{sec:file_read}).\\
-    \textsl{\code{write}}  & scrive sul file (vedi \secref{sec:file_write}).\\ 
+    \textsl{\code{open}}   & apre il file (vedi sez.~\ref{sec:file_open}). \\
+    \textsl{\code{read}}   & legge dal file (vedi sez.~\ref{sec:file_read}).\\
+    \textsl{\code{write}}  & scrive sul file (vedi 
+                             sez.~\ref{sec:file_write}).\\

     \textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi
     \textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi

-                             \secref{sec:file_lseek}). \\
+                             sez.~\ref{sec:file_lseek}). \\

     \textsl{\code{ioctl}}  & accede alle operazioni di controllo 
     \textsl{\code{ioctl}}  & accede alle operazioni di controllo 

-                             (vedi \secref{sec:file_ioctl}).\\
+                             (vedi sez.~\ref{sec:file_ioctl}).\\

     \textsl{\code{readdir}}& legge il contenuto di una directory \\
     \textsl{\code{poll}}   & usata nell'I/O multiplexing (vedi
     \textsl{\code{readdir}}& legge il contenuto di una directory \\
     \textsl{\code{poll}}   & usata nell'I/O multiplexing (vedi

-                             \secref{sec:file_multiplexing}). \\
+                             sez.~\ref{sec:file_multiplexing}). \\

     \textsl{\code{mmap}}   & mappa il file in memoria (vedi 
     \textsl{\code{mmap}}   & mappa il file in memoria (vedi 

-                             \secref{sec:file_memory_map}). \\
+                             sez.~\ref{sec:file_memory_map}). \\

     \textsl{\code{release}}& chiamata quando l'ultimo riferimento a un file 
                              aperto è chiuso. \\
     \textsl{\code{fsync}}  & sincronizza il contenuto del file (vedi
     \textsl{\code{release}}& chiamata quando l'ultimo riferimento a un file 
                              aperto è chiuso. \\
     \textsl{\code{fsync}}  & sincronizza il contenuto del file (vedi

-                             \secref{sec:file_sync}). \\
+                             sez.~\ref{sec:file_sync}). \\

     \textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
     \textsl{\code{fasync}} & abilita l'I/O asincrono (vedi

-                             \secref{sec:file_asyncronous_io}) sul file. \\
+                             sez.~\ref{sec:file_asyncronous_io}) sul file. \\

     \hline
   \end{tabular}
   \caption{Operazioni sui file definite nel VFS.}
     \hline
   \end{tabular}
   \caption{Operazioni sui file definite nel VFS.}


@@ -528,12 +530,12 @@ operazioni previste dal kernel 
 In questo modo per ciascun file diventano possibili una serie di operazioni
 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia
 astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
 In questo modo per ciascun file diventano possibili una serie di operazioni
 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia
 astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad

-utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
-di file in questione.
+utilizzare l'opportuna routine dichiarata in \struct{f\_ops} appropriata al
+tipo di file in questione.

 
 

-Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su
-normale un file di dati; ovviamente certe operazioni (nel caso della seriale
-ad esempio la \code{seek}) non saranno disponibili, però con questo sistema
+Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
+normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
+esempio la \code{seek}) non saranno disponibili, però con questo sistema

 l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 
 l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 


@@ -541,7 +543,7 @@ immediato e (relativamente) trasparente per l'utente ed il programmatore.
 \subsection{Il funzionamento di un filesystem Unix}
 \label{sec:file_filesystem}
 
 \subsection{Il funzionamento di un filesystem Unix}
 \label{sec:file_filesystem}
 

-Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
+Come già accennato in sez.~\ref{sec:file_organization} Linux (ed ogni sistema

 unix-like) 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
 unix-like) 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


@@ -552,11 +554,11 @@ 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
 
 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 \figref{fig:file_disk_filesys};
+dell'informazione su un disco è riportata in fig.~\ref{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
 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
+sez.~\ref{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
 inode\index{inode} e lo spazio a disposizione per i dati e le directory.
 filesystem per Unix, indipendentemente da come poi viene strutturata nei
 dettagli questa informazione, prevedere una divisione fra la lista degli
 inode\index{inode} e lo spazio a disposizione per i dati e le directory.


@@ -574,7 +576,7 @@ 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
 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

-\figref{fig:file_filesys_detail}.
+fig.~\ref{fig:file_filesys_detail}.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -583,7 +585,7 @@ esemplificare la situazione con uno schema come quello esposto in
   \label{fig:file_filesys_detail}
 \end{figure}
 
   \label{fig:file_filesys_detail}
 \end{figure}
 

-Da \figref{fig:file_filesys_detail} si evidenziano alcune delle
+Da fig.~\ref{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
 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


@@ -599,9 +601,9 @@ particolare 
   dell'\textit{inode}\index{inode} ad esso associato, cioè quella che da qui
   in poi chiameremo una \textsl{voce} (come traduzione dell'inglese
   \textit{directory entry}, che non useremo anche per evitare confusione con
   dell'\textit{inode}\index{inode} ad esso associato, cioè quella che da qui
   in poi chiameremo una \textsl{voce} (come 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}).
+  le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}).

   
   

-\item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
+\item Come mostrato in fig.~\ref{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
   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


@@ -627,10 +629,10 @@ particolare 
 
 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
 
 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 \figref{fig:file_filesys_detail} creiamo una nuova directory
+mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory

 \file{img} nella directory \file{gapil}, avremo una situazione come quella in
 \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\index{inode}.
+fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
+di inode\index{inode}.

 
 \begin{figure}[htb]
   \centering 
 
 \begin{figure}[htb]
   \centering 


@@ -654,7 +656,7 @@ adesso sar
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di

-file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di
+file lunghi (256 caratteri, estensibili a 1012) con una dimensione massima di

 4~Tb.
 
 Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
 4~Tb.
 
 Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che


@@ -670,8 +672,8 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
   semantica SVr4 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 \acr{sgid} impostato (per una descrizione dettagliata del significato di
   semantica SVr4 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 \acr{sgid} impostato (per una descrizione dettagliata del significato di

-  questi termini si veda \secref{sec:file_access_control}), nel qual caso file
-  e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
+  questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
+  file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.

 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).


@@ -686,10 +688,16 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
   log).
 \end{itemize}
 
   log).
 \end{itemize}
 

-La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD:
-un filesystem è composto da un insieme di blocchi, la struttura generale è
-quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
-è divisa in gruppi di blocchi.
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
+filesystem è composto da un insieme di blocchi, la struttura generale è quella
+riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
+in gruppi di blocchi.\footnote{non si confonda la questa definizione con
+  quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
+  riferimento alla struttura usata in user space per riportare i dati
+  contenuti in una directory generica, questa fa riferimento alla struttura
+  usata dal kernel per un filesystem \acr{ext2}, definita nel file
+  \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
+  kernel.}

 
 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
 filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
 
 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
 filesystem (superblock e descrittore del filesystem sono quindi ridondati) per


@@ -710,8 +718,9 @@ inode\index{inode}.
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode\index{inode},
 la sua lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode\index{inode},
 la sua 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.
+fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi
+per i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio
+disco.