X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileio.tex;h=ba66a3539e174655c0c7d8df39f2687f41d1307e;hp=9e7e960569f0ebc65beb52717d5c8601a10daade;hb=7208522fd60468969d96dba5d8dd2cbd24b75b89;hpb=7b43a7843d483c826a6ed13224208c615a23c4d6

diff --git a/fileio.tex b/fileio.tex
index 9e7e960..ba66a35 100644
--- a/fileio.tex
+++ b/fileio.tex
@@ -51,10 +51,10 @@ chiamata l'interfaccia dei \textit{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. Questo si
 fa aprendo il file con la funzione \func{open} (vedi
-sez.~\ref{sec:file_open_close}) che provvederà a localizzare \itindex{inode}
-l'\textit{inode} del file e inizializzare i puntatori che rendono disponibili
-le funzioni che il VFS mette a disposizione (quelle di
-tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
+sez.~\ref{sec:file_open_close}) che provvederà a localizzare l'\textit{inode}
+del file e inizializzare i puntatori che rendono disponibili le funzioni che
+il VFS mette a disposizione (quelle di
+tab.~\ref{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.
 
@@ -98,10 +98,9 @@ particolare:
 \item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo
   \var{f\_pos}.
 \item un puntatore alla struttura \kstruct{inode} che identifica
-  \itindex{inode} l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in
-    realtà passati ad un puntatore ad una struttura \kstruct{dentry} che punta
-    a sua volta \itindex{inode} all'\textit{inode} passando per la nuova
-    struttura del VFS.}
+  l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in realtà passati
+    ad un puntatore ad una struttura \kstruct{dentry} che punta a sua volta
+    all'\textit{inode} passando per la nuova struttura del VFS.}
 \item un puntatore \var{f\_op} alla tabella delle funzioni che si possono
   usare sul file.\footnote{quelle della struttura \kstruct{file\_operation},
     descritte sommariamente in tab.~\ref{tab:file_file_operations}.}
@@ -120,6 +119,7 @@ In fig.~\ref{fig:file_proc_file} si è riportato uno schema semplificato in cui
 interrelazioni fra la \textit{file table}, la \textit{process table} e le
 varie strutture di dati che il kernel mantiene per ciascun file e ciascun
 processo.
+\itindend{process~table}
 
 Come si può notare alla fine il collegamento che consente di porre in
 relazione i file ed i processi è effettuato attraverso i dati mantenuti nella
@@ -130,7 +130,7 @@ essenziali come:
 \item il numero di file aperti dal processo.
 \item la \itindex{file~descriptor~table} \textit{file descriptor table}, una
   tabella con i puntatori, per ciascun file aperto, alla relativa voce nella
-  \itindex{file~table} \textit{file table}.
+  \textit{file table}.
 \end{itemize*}
 
 In questa infrastruttura un \textit{file descriptor} non è altro che l'intero
@@ -141,25 +141,24 @@ processo a cui era stato assegnato questo indice. Una volta ottenuta grazie al
 voluto nella \textit{file table}, il kernel potrà usare le funzioni messe
 disposizione dal VFS per eseguire sul file tutte le operazioni necessarie.
 
-\itindend{process~table}
-\itindend{file~table}
-
-
 Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo
 \textit{file descriptor} libero nella tabella, e per questo motivo essi
 vengono assegnati in successione tutte le volte che si apre un nuovo file,
 posto che non ne sia stato chiuso nessuno in precedenza.
 
+\itindbeg{standard~input} 
+\itindbeg{standard~output}
+\itindbeg{standard~error}
+
 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 processo si aspetta di avere sempre tre file aperti che, per quanto appena
 detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i
 valori 0, 1 e 2.  Il primo file è sempre associato al cosiddetto
-\itindex{standard~input} \textit{standard input}, è cioè il file da cui un
-processo si aspetta di dover leggere i dati in ingresso. Il secondo file è il
-cosiddetto \itindex{standard~output} \textit{standard output}, cioè quello su
-cui ci si aspetta di dover scrivere i dati in uscita. Il terzo è lo
-\itindex{standard~error} \textit{standard error}, su cui vengono scritti i
-dati relativi agli errori.
+\textit{standard input}, è cioè il file da cui un processo si aspetta di dover
+leggere i dati in ingresso. Il secondo file è il cosiddetto \textit{standard
+  output}, cioè quello su cui ci si aspetta di dover scrivere i dati in
+uscita. Il terzo è lo  \textit{standard error}, su cui
+vengono scritti i dati relativi agli errori.
 
 Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
 delle applicazioni, e non aderirvi potrebbe portare a problemi di
@@ -191,27 +190,28 @@ tab.~\ref{tab:file_std_files}.
   \label{tab:file_std_files}
 \end{table}
 
+\itindend{standard~input} 
+\itindend{standard~output}
+\itindend{standard~error}
+
 In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa
 rispetto a quella usuale della shell, in cui tutti e tre questi file fanno
 riferimento al terminale su cui si opera. Nell'esempio invece viene illustrata
-la situazione di un programma in cui lo \itindex{standard~input}
-\textit{standard input} è associato ad un file mentre lo
-\itindex{standard~output} \textit{standard output} e lo
-\itindex{standard~error} \textit{standard error} sono associati ad un altro
-file.  Si noti poi come per questi ultimi le strutture \kstruct{file} nella
-\itindex{file~table} \textit{file table}, pur essendo distinte, fanno
-riferimento allo stesso \itindex{inode} \textit{inode}, dato che il file che è
-stato aperto lo stesso. Questo è quello che avviene normalmente quando si apre
-più volte lo stesso file.
-
-Si ritrova quindi anche con le voci della \itindex{file~table} \textit{file
-  table} una situazione analoga di quella delle voci di una directory, con la
-possibilità di avere più voci che fanno riferimento allo stesso
-\itindex{inode} \textit{inode}. L'analogia è in realtà molto stretta perché
-quando si cancella un file, il kernel verifica anche che non resti nessun
-riferimento in una una qualunque voce della \itindex{file~table} \textit{file
+la situazione di un programma in cui lo \textit{standard input} è associato ad
+un file mentre lo \textit{standard output} e lo \textit{standard error} sono
+associati ad un altro file.  Si noti poi come per questi ultimi le strutture
+\kstruct{file} nella \textit{file table}, pur essendo distinte, fanno
+riferimento allo stesso \textit{inode}, dato che il file che è stato aperto lo
+stesso. Questo è quello che avviene normalmente quando si apre più volte lo
+stesso file.
+
+Si ritrova quindi anche con le voci della \textit{file table} una situazione
+analoga di quella delle voci di una directory, con la possibilità di avere più
+voci che fanno riferimento allo stesso \textit{inode}. L'analogia è in realtà
+molto stretta perché quando si cancella un file, il kernel verifica anche che
+non resti nessun riferimento in una una qualunque voce della \textit{file
   table} prima di liberare le risorse ad esso associate e disallocare il
-relativo \itindex{inode} \textit{inode}.
+relativo \textit{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
@@ -221,6 +221,7 @@ più recenti non sussiste più, dato che si è passati da un vettore ad una
 lista, ma restano i limiti imposti dall'amministratore (vedi
 sez.~\ref{sec:sys_limits}).
 
+\itindend{file~table}
 
 
 \subsection{Apertura, creazione e chiusura di un file}
@@ -1566,8 +1567,8 @@ quando un \textit{pathname} relativo non fa riferimento ad un file posto
 direttamente nella directory di lavoro corrente, che alcuni dei componenti del
 \textit{pathname} vengano modificati in parallelo alla chiamata a \func{open},
 cosa che lascia aperta la possibilità di una \textit{race condition} in cui
-c'è spazio per un \itindex{symlink~attack} \textit{symlink attack} (si ricordi
-quanto visto per \func{access} in sez.~\ref{sec:file_perm_management}).
+c'è spazio per un \textit{symlink attack} (si ricordi quanto visto per
+\func{access} in sez.~\ref{sec:file_perm_management}).
 
 Inoltre come già accennato, la directory di lavoro corrente è una proprietà
 del singolo processo; questo significa che quando si lavora con i