X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileunix.tex;h=5508c50c9c882f4ced4136c647ca53d63404a1f9;hp=54b1c190e97add774361d983c55ed8269a9de120;hb=25de957ddf731370bec1eb74b13cf35aa7886d1b;hpb=718a0a24b34dce09e40eafc33c02ae494d100181

diff --git a/fileunix.tex b/fileunix.tex
index 54b1c19..5508c50 100644
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -13,7 +13,7 @@
 
 
 Esamineremo in questo capitolo la prima delle due interfacce di programmazione
-per i file, quella dei \textit{file descriptor}\index{file descriptor},
+per i file, quella dei \textit{file descriptor}\index{file!descriptor},
 nativa di Unix. Questa è l'interfaccia di basso livello provvista direttamente
 dalle system call, che non prevede funzionalità evolute come la
 bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
@@ -34,17 +34,18 @@ tutte le implementazione di un sistema unix-like.
 \subsection{L'architettura dei \textit{file descriptor}}
 \label{sec:file_fd}
 
-Per poter accedere al contenuto di un file occorre creare un canale di
-comunicazione con il kernel che renda possibile operare su di esso (si ricordi
-quanto visto in \secref{sec:file_vfs_work}). Questo si fa aprendo il file con
-la funzione \func{open} che provvederà a localizzare l'inode del file e
-inizializzare i puntatori che rendono disponibili le funzioni che il VFS mette
-a disposizione (riportate in \tabref{tab:file_file_operations}). Una volta
-terminate le operazioni, il file dovrà essere chiuso, e questo chiuderà il
-canale di comunicazione impedendo ogni ulteriore operazione.
+\index{file!descriptor|(} Per poter accedere al contenuto di un file occorre
+creare un canale di comunicazione con il kernel che renda possibile operare su
+di esso (si ricordi quanto visto in \secref{sec:file_vfs_work}). Questo si fa
+aprendo il file con la funzione \func{open} che provvederà a localizzare
+l'inode\index{inode} del file e inizializzare i puntatori che rendono
+disponibili le funzioni che il VFS mette a disposizione (riportate in
+\tabref{tab:file_file_operations}). Una volta terminate le operazioni, il file
+dovrà essere chiuso, e questo chiuderà il canale di comunicazione impedendo
+ogni ulteriore operazione.
 
 All'interno di ogni processo i file aperti sono identificati da un intero non
-negativo, chiamato appunto \textit{file descriptor}\index{file descriptor}.
+negativo, chiamato appunto \textit{file descriptor}.
 Quando un file viene aperto la funzione \func{open} restituisce questo numero,
 tutte le ulteriori operazioni saranno compiute specificando questo stesso
 valore come argomento alle varie funzioni dell'interfaccia.
@@ -67,8 +68,8 @@ particolare:
 \item una tabella che contiene un puntatore alla relativa voce nella
   \textit{file table} per ogni file aperto.
 \end{itemize*}
-il \textit{file descriptor}\index{file descriptor} in sostanza è l'intero
-positivo che indicizza quest'ultima tabella.
+il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
+quest'ultima tabella.
 
 La \textit{file table} è una tabella che contiene una voce per ciascun file
 che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
@@ -78,9 +79,10 @@ file, fra cui:
 \item lo stato del file (nel campo \var{f\_flags}).
 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
   campo \var{f\_pos}).
-\item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
-    ad un puntatore ad una struttura \var{dentry} che punta a sua volta
-    all'inode passando per la nuova struttura del VFS.} del file.
+\item un puntatore all'inode\index{inode}\footnote{nel kernel 2.4.x si è in
+    realtà passati ad un puntatore ad una struttura \var{dentry} che punta a
+    sua volta all'inode\index{inode} passando per la nuova struttura del VFS.}
+  del file.
 %\item un puntatore alla tabella delle funzioni \footnote{la struttura
 %    \var{f\_op} descritta in \secref{sec:file_vfs_work}} che si possono usare
 %  sul file.
@@ -98,20 +100,23 @@ varie strutture di dati sulla quale essa 
 \end{figure}
 Ritorneremo su questo schema più volte, dato che esso è fondamentale per
 capire i dettagli del funzionamento dell'interfaccia dei \textit{file
-  descriptor}\index{file descriptor}.
+  descriptor}.  
+\index{file!descriptor|)}
+
+
 
 
 \subsection{I file standard}
 \label{sec:file_std_descr}
 
-Come accennato i \textit{file descriptor}\index{file descriptor} non sono
-altro che un indice nella tabella dei file aperti di ciascun processo; per
-questo motivo essi vengono assegnati in successione tutte le volte che si apre
-un nuovo file (se non ne è stato chiuso nessuno in precedenza).
+Come accennato i \textit{file descriptor} non sono altro che un indice nella
+tabella dei file aperti di ciascun processo; per questo motivo essi vengono
+assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
+stato chiuso nessuno in precedenza).
 
 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 processo viene lanciato con almeno tre file aperti. Questi, per quanto appena
-detto, avranno come \textit{file descriptor}\index{file descriptor} i valori
+detto, avranno come \textit{file descriptor}\index{file!descriptor} i valori
 0, 1 e 2.  Benché questa sia soltanto una convenzione, essa è seguita dalla
 gran parte delle applicazioni, e non aderirvi potrebbe portare a gravi
 problemi di interoperabilità.
@@ -152,7 +157,7 @@ In \figref{tab:file_std_files} si 
 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).
+stesso inode\index{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
@@ -306,7 +311,7 @@ sempre il file descriptor con il valore pi
 
 \footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
   opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
-  \textsl{file di lock}\index{file di lock} possono incorrere in una race
+  \textsl{file di lock}\index{file!di lock} possono incorrere in una race
   condition\index{race condition}.  Si consiglia come alternativa di usare un
   file con un nome univoco e la funzione \func{link} per verificarne
   l'esistenza (vedi \secref{sec:ipc_file_lock}).}
@@ -408,12 +413,12 @@ descriptor ritorna disponibile; il suo prototipo 
   ed inoltre \errval{EIO}.}
 \end{prototype}
 
-La chiusura di un file rilascia ogni blocco (il \textit{file locking} è
-trattato in \secref{sec:file_locking}) che il processo poteva avere acquisito
-su di esso; se \var{fd} è l'ultimo riferimento (di eventuali copie) ad un file
-aperto, tutte le risorse nella file table vengono rilasciate. Infine se il
-file descriptor era l'ultimo riferimento ad un file su disco quest'ultimo
-viene cancellato.
+La chiusura di un file rilascia ogni blocco (il \textit{file
+  locking}\index{file!locking} è trattato in \secref{sec:file_locking}) che il
+processo poteva avere acquisito su di esso; se \var{fd} è l'ultimo riferimento
+(di eventuali copie) ad un file aperto, tutte le risorse nella file table
+vengono rilasciate. Infine se il file descriptor era l'ultimo riferimento ad
+un file su disco quest'ultimo viene cancellato.
 
 Si ricordi che quando un processo termina anche tutti i suoi file descriptor
 vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
@@ -459,7 +464,8 @@ ad un valore qualsiasi con la funzione \func{lseek}, il cui prototipo 
     successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei
     valori:
   \begin{errlist}
-    \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
+  \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket\index{socket} o una
+    fifo.
     \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
   \end{errlist}
   ed inoltre \errval{EBADF}.}
@@ -565,10 +571,10 @@ non aver selezionato la modalit
 di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
 con un numero di byte inferiore a quelli richiesti.
 
-Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
-come vedremo in \secref{sec:sock_io_behav}), o per la lettura da certi file di
-dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
-singolo blocco alla volta.
+Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un
+socket\index{socket}, come vedremo in \secref{sec:sock_io_behav}), o per la
+lettura da certi file di dispositivo, come le unità a nastro, che
+restituiscono sempre i dati ad un singolo blocco alla volta.
 
 In realtà anche le due condizioni segnalate dagli errori \errcode{EINTR} e
 \errcode{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
@@ -709,7 +715,8 @@ su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
 situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
 processo avrà una sua voce nella \textit{file table} referenziata da un
 diverso file descriptor nella sua \var{file\_struct}. Entrambe le voci nella
-\textit{file table} faranno però riferimento allo stesso inode su disco.
+\textit{file table} faranno però riferimento allo stesso inode\index{inode} su
+disco.
 
 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
 la sua modalità di accesso e versioni proprie di tutte le proprietà che
@@ -720,15 +727,17 @@ stesso file, in particolare occorre tenere presente che:
 \item ciascun processo può scrivere indipendentemente; dopo ciascuna
   \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
   scrittura eccede la dimensione corrente del file questo verrà esteso
-  automaticamente con l'aggiornamento del campo \var{i\_size} nell'inode.
+  automaticamente con l'aggiornamento del campo \var{i\_size}
+  nell'inode\index{inode}.
 \item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
   effettuata una scrittura la posizione corrente viene prima impostata alla
-  dimensione corrente del file letta dall'inode. Dopo la scrittura il file
-  viene automaticamente esteso.
-\item l'effetto di \func{lseek} è solo quello di cambiare il campo \var{f\_pos}
-  nella struttura \var{file} della \textit{file table}, non c'è nessuna
-  operazione sul file su disco. Quando la si usa per porsi alla fine del file
-  la posizione viene impostata leggendo la dimensione corrente dall'inode.
+  dimensione corrente del file letta dall'inode\index{inode}. Dopo la
+  scrittura il file viene automaticamente esteso.
+\item l'effetto di \func{lseek} è solo quello di cambiare il campo
+  \var{f\_pos} nella struttura \var{file} della \textit{file table}, non c'è
+  nessuna operazione sul file su disco. Quando la si usa per porsi alla fine
+  del file la posizione viene impostata leggendo la dimensione corrente
+  dall'inode\index{inode}.
 \end{itemize}
 
 \begin{figure}[htb]
@@ -778,7 +787,7 @@ problema, quando si andr
 maniera imprevedibile.  Il sistema però fornisce in alcuni casi la possibilità
 di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
 utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
-  locking}, che esamineremo in \secref{sec:file_locking}).
+  locking}\index{file!locking}, che esamineremo in \secref{sec:file_locking}).
 
 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
 vari processi devono scrivere alla fine di un file (ad esempio un file di
@@ -800,7 +809,7 @@ avviene all'interno di una singola system call (la \func{write}) che non
 essendo interrompibile da un altro processo costituisce un'operazione atomica.
 
 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
-creare un \textsl{file di lock}\index{file di lock}, bloccandosi se il file
+creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file
 esiste. In questo caso la sequenza logica porterebbe a verificare prima
 l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
 di nuovo avremmo la possibilità di una race condition\index{race condition} da
@@ -876,8 +885,8 @@ Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
 file specificato, ed attendono fino alla conclusione delle operazioni;
 \func{fsync} forza anche la sincronizzazione dei metadati del file (che
 riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
-altri dati contenuti nell'inode che si leggono con \var{fstat} come i tempi
-del file).
+altri dati contenuti nell'inode\index{inode} che si leggono con \var{fstat}
+come i tempi del file).
 
 Si tenga presente che questo non comporta la sincronizzazione della
 directory che contiene il file (e scrittura della relativa voce su
@@ -989,8 +998,8 @@ descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
 gestione sia delle loro proprietà, che di tutta una serie di ulteriori
 funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
   gesticono con questa funzione l'I/O asincrono (vedi
-  \secref{sec:file_asyncronous_io}) e il file locking (vedi
-  \secref{sec:file_locking}).}
+  \secref{sec:file_asyncronous_io}) e il file locking\index{file!locking}
+  (vedi \secref{sec:file_locking}).}
 
 Per queste operazioni di manipolazione e di controllo su proprietà e
 caratteristiche un file descriptor, viene usata la funzione \func{fcntl}, il
@@ -1096,7 +1105,8 @@ poter essere affrontate in dettaglio a questo punto; saranno riprese pi
 avanti quando affronteremo le problematiche ad esse relative (in particolare
 le tematiche relative all'I/O asincrono sono trattate in maniera esaustiva in
 \secref{sec:file_asyncronous_io} mentre quelle relative al \textit{file
-  locking} saranno esaminate in \secref{sec:file_locking}).
+  locking}\index{file!locking} saranno esaminate in
+\secref{sec:file_locking}).
 
 Si tenga presente infine che quando si usa la funzione per determinare le
 modalità di accesso con cui è stato aperto il file (attraverso l'uso del