X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=8b979cb3780e0ebae471a271497d36bc3d67db62;hp=8d6277219cf18fc53843330ba217156467d35854;hb=beece18eba2dcc2a9b915dab61277df8685a3da6;hpb=b3593007c4edd76ecbf7386967c1b25d27eed828

diff --git a/fileadv.tex b/fileadv.tex
index 8d62772..8b979cb 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1,6 +1,6 @@
 %% fileadv.tex
 %%
-%% Copyright (C) 2000-2012 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2014 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 "Un preambolo",
@@ -26,12 +26,12 @@ controllo più dettagliato delle modalità di I/O.
 
 \itindbeg{file~locking}
 
-In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
-sistema unix-like gestisce la condivisione dei file da parte di processi
-diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
-in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
-contemporaneamente sullo stesso file non è possibile determinare la sequenza
-in cui essi opereranno.
+In sez.~\ref{sec:file_shared_access} abbiamo preso in esame le modalità in cui
+un sistema unix-like gestisce l'accesso concorrente ai file da parte di
+processi diversi. In quell'occasione si è visto come, con l'eccezione dei file
+aperti in \itindex{append~mode} \textit{append mode}, quando più processi
+scrivono contemporaneamente sullo stesso file non è possibile determinare la
+sequenza in cui essi opereranno.
 
 Questo causa la possibilità di una \itindex{race~condition} \textit{race
   condition}; in generale le situazioni più comuni sono due: l'interazione fra
@@ -244,14 +244,14 @@ possono avere due processi diversi che aprono lo stesso file.
 
 La richiesta di un \textit{file lock} prevede una scansione della lista per
 determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
-un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
+un nuovo elemento.\footnote{cioè una nuova struttura \kstruct{file\_lock}.}
 Nel caso dei blocchi creati con \func{flock} la semantica della funzione
 prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un
 \textit{file lock} quanto piuttosto degli ulteriori riferimenti allo
 stesso. Questo viene realizzato dal kernel secondo lo schema di
 fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock}
 un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
-  \struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
+  \kstruct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
   con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file
   table} da cui si è richiesto il blocco, che così ne identifica il titolare.
 
@@ -260,8 +260,8 @@ Questa struttura prevede che, quando si richiede la rimozione di un
 file descriptor che fa riferimento ad una voce nella \itindex{file~table}
 \textit{file table} corrispondente a quella registrata nel blocco.  Allora se
 ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
-ereditati in un processo figlio puntano sempre alla stessa voce nella
+sez.~\ref{sec:file_shared_access}, e cioè che i file descriptor duplicati e
+quelli ereditati in un processo figlio puntano sempre alla stessa voce nella
 \itindex{file~table} \textit{file table}, si può capire immediatamente quali
 sono le conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
 
@@ -296,8 +296,8 @@ descriptor, il \textit{file lock} non viene rilasciato.
 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
 già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
-sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
-essa viene usata solo secondo il seguente prototipo:
+sez.~\ref{sec:file_fcntl_ioctl}. Quando la si impiega per il \textit{file
+  locking} essa viene usata solo secondo il seguente prototipo:
 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
   
   Applica o rimuove un \textit{file lock} sul file \param{fd}.
@@ -390,8 +390,9 @@ viene usato solo in caso di lettura, quando si chiama \func{fcntl} con
 
 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
 effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
-\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
-l'azione da compiere; i valori relativi al \textit{file locking} sono tre:
+\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl_ioctl},
+specifica l'azione da compiere; i valori relativi al \textit{file locking}
+sono tre:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{F\_GETLK}] verifica se il \textit{file lock} specificato dalla
   struttura puntata da \param{lock} può essere acquisito: in caso negativo
@@ -460,7 +461,7 @@ sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
 kernel. Lo schema delle strutture utilizzate è riportato in
 fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
-  sono evidenziati solo i campi di \struct{file\_lock} significativi per la
+  sono evidenziati solo i campi di \kstruct{file\_lock} significativi per la
   semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
   \ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene
   bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
@@ -481,7 +482,7 @@ voce nella \itindex{file~table} \textit{file table}, ma con il valore del
 Quando si richiede un \textit{file lock} il kernel effettua una scansione di
 tutti i blocchi presenti sul file\footnote{scandisce cioè la
   \itindex{linked~list} \textit{linked list} delle strutture
-  \struct{file\_lock}, scartando automaticamente quelle per cui
+  \kstruct{file\_lock}, scartando automaticamente quelle per cui
   \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
   ben separate.}  per verificare se la regione richiesta non si sovrappone ad
 una già bloccata, in caso affermativo decide in base al tipo di blocco, in
@@ -835,7 +836,7 @@ bloccare completamente un server NFS richiedendo una lettura su un file su cui
 è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
   locking} è di norma disabilitata, e deve essere attivata filesystem per
 filesystem in fase di montaggio (specificando l'apposita opzione di
-\func{mount} riportata in sez.~\ref{sec:sys_file_config}), o con l'opzione
+\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}), o con l'opzione
 \code{-o mand} per il comando omonimo).
 
 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
@@ -901,7 +902,7 @@ possibilità di modificare il file.
 
 Uno dei problemi che si presentano quando si deve operare contemporaneamente
 su molti file usando le funzioni illustrate in
-cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
+sez.~\ref{sec:file_unix_interface} e sez.~\ref{sec:files_std_interface} è che
 si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
 essere disponibile. L'\textit{I/O multiplexing} nasce risposta a questo
 problema. In questa sezione forniremo una introduzione a questa problematica
@@ -913,13 +914,13 @@ I/O.
 \label{sec:file_noblocking}
 
 Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
-\textit{fast} e \textit{slow} system call,\index{system~call~lente} che in
-certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si
-  ricordi però che questo può accadere solo per le pipe, i socket ed alcuni
-  file di dispositivo\index{file!di~dispositivo}; sui file normali le funzioni
-  di lettura e scrittura ritornano sempre subito.}  Ad esempio le operazioni
-di lettura possono bloccarsi quando non ci sono dati disponibili sul
-descrittore su cui si sta operando.
+\textit{fast} e \textit{slow} \textit{system call},\index{system~call~lente}
+che in certi casi le funzioni di I/O possono bloccarsi
+indefinitamente.\footnote{si ricordi però che questo può accadere solo per le
+  pipe, i socket ed alcuni file di dispositivo\index{file!di~dispositivo}; sui
+  file normali le funzioni di lettura e scrittura ritornano sempre subito.}
+Ad esempio le operazioni di lettura possono bloccarsi quando non ci sono dati
+disponibili sul descrittore su cui si sta operando.
 
 Questo comportamento causa uno dei problemi più comuni che ci si trova ad
 affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
@@ -934,18 +935,18 @@ nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
 da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
 potrebbe addirittura arrivare ad un \itindex{deadlock} \textit{deadlock}.
 
-Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
-questo tipo di comportamento delle funzioni di I/O aprendo un file in
-\textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
-nella chiamata di \func{open}. In questo caso le funzioni di input/output
-eseguite sul file che si sarebbero bloccate, ritornano immediatamente,
-restituendo l'errore \errcode{EAGAIN}.  L'utilizzo di questa modalità di I/O
-permette di risolvere il problema controllando a turno i vari file descriptor,
-in un ciclo in cui si ripete l'accesso fintanto che esso non viene garantito.
-Ovviamente questa tecnica, detta \itindex{polling} \textit{polling}, è
-estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
-eseguire in continuazione delle system call che nella gran parte dei casi
-falliranno.
+Abbiamo già accennato in sez.~\ref{sec:file_open_close} che è possibile
+prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file
+in \textsl{modalità non-bloccante}, attraverso l'uso del flag
+\const{O\_NONBLOCK} nella chiamata di \func{open}. In questo caso le funzioni
+di input/output eseguite sul file che si sarebbero bloccate, ritornano
+immediatamente, restituendo l'errore \errcode{EAGAIN}.  L'utilizzo di questa
+modalità di I/O permette di risolvere il problema controllando a turno i vari
+file descriptor, in un ciclo in cui si ripete l'accesso fintanto che esso non
+viene garantito.  Ovviamente questa tecnica, detta \itindex{polling}
+\textit{polling}, è estremamente inefficiente: si tiene costantemente
+impiegata la CPU solo per eseguire in continuazione delle \textit{system call}
+che nella gran parte dei casi falliranno.
 
 Per superare questo problema è stato introdotto il concetto di \textit{I/O
   multiplexing}, una nuova modalità di operazioni che consente di tenere sotto
@@ -1160,12 +1161,13 @@ precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
 La funzione è sostanzialmente identica a \func{select}, solo che usa una
 struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timespec_struct}) per
 indicare con maggiore precisione il timeout e non ne aggiorna il valore in
-caso di interruzione.\footnote{in realtà la system call di Linux aggiorna il
-  valore al tempo rimanente, ma la funzione fornita dalle \acr{glibc} modifica
-  questo comportamento passando alla system call una variabile locale, in modo
-  da mantenere l'aderenza allo standard POSIX che richiede che il valore di
-  \param{timeout} non sia modificato.} Inoltre prende un argomento aggiuntivo
-\param{sigmask} che è il puntatore ad una maschera di segnali (si veda
+caso di interruzione.\footnote{in realtà la \textit{system call} di Linux
+  aggiorna il valore al tempo rimanente, ma la funzione fornita dalle
+  \acr{glibc} modifica questo comportamento passando alla \textit{system call}
+  una variabile locale, in modo da mantenere l'aderenza allo standard POSIX
+  che richiede che il valore di \param{timeout} non sia modificato.} Inoltre
+prende un argomento aggiuntivo \param{sigmask} che è il puntatore ad una
+\index{maschera~dei~segnali} maschera di segnali (si veda
 sez.~\ref{sec:sig_sigmask}).  La maschera corrente viene sostituita da questa
 immediatamente prima di eseguire l'attesa, e ripristinata al ritorno della
 funzione.
@@ -1195,18 +1197,19 @@ interrotta, e la ricezione del segnale non sarà rilevata.
 Per questo è stata introdotta \func{pselect} che attraverso l'argomento
 \param{sigmask} permette di riabilitare la ricezione il segnale
 contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
-  kernel 2.6.16, non era presente la relativa system call, e la funzione era
-  implementata nelle \acr{glibc} attraverso \func{select} (vedi \texttt{man
-    select\_tut}) per cui la possibilità di \itindex{race~condition}
-  \textit{race condition} permaneva; in tale situazione si può ricorrere ad una
-  soluzione alternativa, chiamata \itindex{self-pipe trick} \textit{self-pipe
-    trick}, che consiste nell'aprire una pipe (vedi sez.~\ref{sec:ipc_pipes})
-  ed usare \func{select} sul capo in lettura della stessa; si può indicare
-  l'arrivo di un segnale scrivendo sul capo in scrittura all'interno del
-  gestore dello stesso; in questo modo anche se il segnale va perso prima
-  della chiamata di \func{select} questa lo riconoscerà comunque dalla
-  presenza di dati sulla pipe.} ribloccandolo non appena essa ritorna, così
-che il precedente codice potrebbe essere riscritto nel seguente modo:
+  kernel 2.6.16, non era presente la relativa \textit{system call}, e la
+  funzione era implementata nelle \acr{glibc} attraverso \func{select} (vedi
+  \texttt{man select\_tut}) per cui la possibilità di \itindex{race~condition}
+  \textit{race condition} permaneva; in tale situazione si può ricorrere ad
+  una soluzione alternativa, chiamata \itindex{self-pipe trick}
+  \textit{self-pipe trick}, che consiste nell'aprire una pipe (vedi
+  sez.~\ref{sec:ipc_pipes}) ed usare \func{select} sul capo in lettura della
+  stessa; si può indicare l'arrivo di un segnale scrivendo sul capo in
+  scrittura all'interno del gestore dello stesso; in questo modo anche se il
+  segnale va perso prima della chiamata di \func{select} questa lo riconoscerà
+  comunque dalla presenza di dati sulla pipe.} ribloccandolo non appena essa
+ritorna, così che il precedente codice potrebbe essere riscritto nel seguente
+modo:
 \includecodesnip{listati/pselect_norace.c} 
 in questo caso utilizzando \var{oldmask} durante l'esecuzione di
 \func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
@@ -1401,11 +1404,12 @@ prototipo è:
 \end{prototype}
 
 La funzione ha lo stesso comportamento di \func{poll}, solo che si può
-specificare, con l'argomento \param{sigmask}, il puntatore ad una maschera di
-segnali; questa sarà la maschera utilizzata per tutto il tempo che la funzione
-resterà in attesa, all'uscita viene ripristinata la maschera originale.  L'uso
-di questa funzione è cioè equivalente, come illustrato nella pagina di
-manuale, all'esecuzione atomica del seguente codice:
+specificare, con l'argomento \param{sigmask}, il puntatore ad una
+\index{maschera~dei~segnali} maschera di segnali; questa sarà la maschera
+utilizzata per tutto il tempo che la funzione resterà in attesa, all'uscita
+viene ripristinata la maschera originale.  L'uso di questa funzione è cioè
+equivalente, come illustrato nella pagina di manuale, all'esecuzione atomica
+del seguente codice:
 \includecodesnip{listati/ppoll_means.c} 
 
 Eccetto per \param{timeout}, che come per \func{pselect} deve essere un
@@ -1547,7 +1551,7 @@ maschera binaria in fase di creazione del file descriptor. Al momento l'unico
 valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC},
 che consente di impostare in maniera atomica sul file descriptor il flag di
 \itindex{close-on-exec} \textit{close-on-exec} (si veda il significato di
-\const{O\_CLOEXEC} in tab.~\ref{tab:file_open_flags}), senza che sia
+\const{O\_CLOEXEC} in sez.~\ref{sec:file_open_close}), senza che sia
 necessaria una successiva chiamata a \func{fcntl}.
 
 Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
@@ -1612,6 +1616,9 @@ delle operazioni cui fanno riferimento.
   \label{tab:epoll_ctl_operation}
 \end{table}
 
+% aggiunta EPOLL_CTL_DISABLE con il kernel 3.7, vedi
+% http://lwn.net/Articles/520012/ e http://lwn.net/Articles/520198/
+
 La funzione prende sempre come primo argomento un file descriptor di
 \textit{epoll}, \param{epfd}, che deve essere stato ottenuto in precedenza con
 una chiamata a \func{epoll\_create}. L'argomento \param{fd} indica invece il
@@ -1707,6 +1714,9 @@ identificazione del file descriptor.
 \footnotetext[48]{questa modalità è disponibile solo a partire dal kernel
   2.6.2.}
 
+% TODO aggiunto EPOLLWAKEUP con il 3.5
+
+
 Le modalità di utilizzo di \textit{epoll} prevedono che si definisca qual'è
 l'insieme dei file descriptor da tenere sotto controllo tramite un certo
 \textit{epoll descriptor} \param{epfd} attraverso una serie di chiamate a
@@ -1827,12 +1837,12 @@ Come già per \func{select} e \func{poll} anche per l'interfaccia di
 \textit{epoll} si pone il problema di gestire l'attesa di segnali e di dati
 contemporaneamente per le osservazioni fatte in sez.~\ref{sec:file_select},
 per fare questo di nuovo è necessaria una variante della funzione di attesa
-che consenta di reimpostare all'uscita una maschera di segnali, analoga alle
-estensioni \func{pselect} e \func{ppoll} che abbiamo visto in precedenza per
-\func{select} e \func{poll}; in questo caso la funzione si chiama
-\funcd{epoll\_pwait}\footnote{la funziona è stata introdotta a partire dal
-  kernel 2.6.19, ed è come tutta l'interfaccia di \textit{epoll}, specifica di
-  Linux.} ed il suo prototipo è:
+che consenta di reimpostare all'uscita una \index{maschera~dei~segnali}
+maschera di segnali, analoga alle estensioni \func{pselect} e \func{ppoll} che
+abbiamo visto in precedenza per \func{select} e \func{poll}; in questo caso la
+funzione si chiama \funcd{epoll\_pwait}\footnote{la funziona è stata
+  introdotta a partire dal kernel 2.6.19, ed è come tutta l'interfaccia di
+  \textit{epoll}, specifica di Linux.} ed il suo prototipo è:
 \begin{prototype}{sys/epoll.h} 
   {int epoll\_pwait(int epfd, struct epoll\_event * events, int maxevents, 
     int timeout, const sigset\_t *sigmask)}
@@ -1847,10 +1857,10 @@ estensioni \func{pselect} e \func{ppoll} che abbiamo visto in precedenza per
 \end{prototype}
 
 La funzione è del tutto analoga \funcd{epoll\_wait}, soltanto che alla sua
-uscita viene ripristinata la maschera di segnali originale, sostituita durante
-l'esecuzione da quella impostata con l'argomento \param{sigmask}; in sostanza
-la chiamata a questa funzione è equivalente al seguente codice, eseguito però
-in maniera atomica:
+uscita viene ripristinata la \index{maschera~dei~segnali} maschera di segnali
+originale, sostituita durante l'esecuzione da quella impostata con
+l'argomento \param{sigmask}; in sostanza la chiamata a questa funzione è
+equivalente al seguente codice, eseguito però in maniera atomica:
 \includecodesnip{listati/epoll_pwait_means.c} 
 
 Si tenga presente che come le precedenti funzioni di \textit{I/O multiplexing}
@@ -1895,8 +1905,8 @@ interruzioni delle funzioni di attesa sincrone, ed evitare possibili
 \itindex{race~condition} \textit{race conditions}.\footnote{in sostanza se non
   fossero per i segnali non ci sarebbe da doversi preoccupare, fintanto che si
   effettuano operazioni all'interno di un processo, della non atomicità delle
-  \index{system~call~lente} system call lente che vengono interrotte e devono
-  essere riavviate.}
+  \index{system~call~lente} \textit{system call} lente che vengono interrotte
+  e devono essere riavviate.}
 
 Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
 \textit{real-time} sono state introdotte anche delle interfacce di gestione
@@ -1935,11 +1945,11 @@ descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è
   versioni diverse della \textit{system call}; una prima versione,
   \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
   \acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
-  versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
+  versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
   che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
   argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
-  maschera dei segnali, il cui valore viene impostato automaticamente dalle
-  \acr{glibc}.}  il cui prototipo è:
+  \index{maschera~dei~segnali} maschera dei segnali, il cui valore viene
+  impostato automaticamente dalle \acr{glibc}.}  il cui prototipo è:
 \begin{prototype}{sys/signalfd.h} 
   {int signalfd(int fd, const sigset\_t *mask, int flags)}
 
@@ -1974,13 +1984,13 @@ con \param{fd}, in caso di errore invece verrà restituito $-1$.
 
 L'elenco dei segnali che si vogliono gestire con \func{signalfd} deve essere
 specificato tramite l'argomento \param{mask}. Questo deve essere passato come
-puntatore ad una maschera di segnali creata con l'uso delle apposite macro già
-illustrate in sez.~\ref{sec:sig_sigset}. La maschera deve indicare su quali
-segnali si intende operare con \func{signalfd}; l'elenco può essere modificato
-con una successiva chiamata a \func{signalfd}. Dato che \signal{SIGKILL} e
-\signal{SIGSTOP} non possono essere intercettati (e non prevedono neanche la
-possibilità di un gestore) un loro inserimento nella maschera verrà ignorato
-senza generare errori. 
+puntatore ad una \index{maschera~dei~segnali} maschera di segnali creata con
+l'uso delle apposite macro già illustrate in sez.~\ref{sec:sig_sigset}. La
+maschera deve indicare su quali segnali si intende operare con
+\func{signalfd}; l'elenco può essere modificato con una successiva chiamata a
+\func{signalfd}. Dato che \signal{SIGKILL} e \signal{SIGSTOP} non possono
+essere intercettati (e non prevedono neanche la possibilità di un gestore) un
+loro inserimento nella maschera verrà ignorato senza generare errori.
 
 L'argomento \param{flags} consente di impostare direttamente in fase di
 creazione due flag per il file descriptor analoghi a quelli che si possono
@@ -2138,13 +2148,13 @@ Il primo passo (\texttt{\small 19--20}) è la crezione di un file descriptor
 quello che useremo per il controllo degli altri.  É poi necessario
 disabilitare la ricezione dei segnali (nel caso \signal{SIGINT},
 \signal{SIGQUIT} e \signal{SIGTERM}) per i quali si vuole la notifica tramite
-file descriptor. Per questo prima li si inseriscono (\texttt{\small 22--25}) in
-una maschera di segnali \texttt{sigmask} che useremo con (\texttt{\small 26})
-\func{sigprocmask} per disabilitarli.  Con la stessa maschera si potrà per
-passare all'uso (\texttt{\small 28--29}) di \func{signalfd} per abilitare la
-notifica sul file descriptor \var{sigfd}. Questo poi (\texttt{\small 30--33})
-dovrà essere aggiunto con \func{epoll\_ctl} all'elenco di file descriptor
-controllati con \texttt{epfd}.
+file descriptor. Per questo prima li si inseriscono (\texttt{\small 22--25})
+in una \index{maschera~dei~segnali} maschera di segnali \texttt{sigmask} che
+useremo con (\texttt{\small 26}) \func{sigprocmask} per disabilitarli.  Con la
+stessa maschera si potrà per passare all'uso (\texttt{\small 28--29}) di
+\func{signalfd} per abilitare la notifica sul file descriptor
+\var{sigfd}. Questo poi (\texttt{\small 30--33}) dovrà essere aggiunto con
+\func{epoll\_ctl} all'elenco di file descriptor controllati con \texttt{epfd}.
 
 Occorrerà infine (\texttt{\small 35--38}) creare la \textit{named fifo} se
 questa non esiste ed aprirla per la lettura (\texttt{\small 39--40}); una
@@ -2207,7 +2217,7 @@ ritorno della funzione \func{read} è negativo, uscendo dal programma
 
 In presenza di dati invece il programma proseguirà l'esecuzione stampando
 (\texttt{\small 19--20}) il nome del segnale ottenuto all'interno della
-struttura \const{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
+struttura \struct{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
   stampa si è usato il vettore \var{sig\_names} a ciascun elemento del quale
   corrisponde il nome del segnale avente il numero corrispondente, la cui
   definizione si è omessa dal codice di fig.~\ref{fig:fiforeporter_code_init}
@@ -2458,7 +2468,7 @@ ottenute leggendo in maniera ordinaria il file descriptor con una \func{read},
 
 
 \section{L'accesso \textsl{asincrono} ai file}
-\label{sec:file_asyncronous_access}
+\label{sec:file_asyncronous_operation}
 
 Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
 le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
@@ -2474,23 +2484,23 @@ operazioni di I/O volute.
 
 
 \subsection{Il \textit{Signal driven I/O}}
-\label{sec:file_asyncronous_operation}
+\label{sec:signal_driven_io}
 
 \itindbeg{signal~driven~I/O}
 
-Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
-l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e
-  dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
-  specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è
-possibile attivare in un secondo tempo questa modalità impostando questo flag
-attraverso l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi
-sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità
-asincrona non significa che le operazioni di lettura o scrittura del file
-vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più
-propriamente viene chiamato \textsl{I/O asincrono}, in
+Abbiamo accennato in sez.~\ref{sec:file_open_close} che è definito un flag
+\const{O\_ASYNC}, che consentirebbe di aprire un file in modalità asincrona,
+anche se in realtà è opportuno attivare in un secondo tempo questa modalità
+impostando questo flag attraverso l'uso di \func{fcntl} con il comando
+\const{F\_SETFL} (vedi sez.~\ref{sec:file_fcntl_ioctl}).\footnote{l'uso del
+  flag di \const{O\_ASYNC} e dei comandi \const{F\_SETOWN} e \const{F\_GETOWN}
+  per \func{fcntl} è specifico di Linux e BSD.}  In realtà parlare di apertura
+in modalità asincrona non significa che le operazioni di lettura o scrittura
+del file vengono eseguite in modo asincrono (tratteremo questo, che è ciò che
+più propriamente viene chiamato \textsl{I/O asincrono}, in
 sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione un meccanismo di
 notifica asincrona delle variazione dello stato del file descriptor aperto in
-questo modo.  
+questo modo.
 
 Quello che succede è che per tutti i file posti in questa modalità\footnote{si
   tenga presente però che essa non è utilizzabile con i file ordinari ma solo
@@ -2498,7 +2508,7 @@ Quello che succede è che per tutti i file posti in questa modalità\footnote{si
   kernel 2.6, anche per fifo e pipe.} il sistema genera un apposito segnale,
 \signal{SIGIO}, tutte le volte che diventa possibile leggere o scrivere dal
 file descriptor che si è posto in questa modalità. Inoltre è possibile, come
-illustrato in sez.~\ref{sec:file_fcntl}, selezionare con il comando
+illustrato in sez.~\ref{sec:file_fcntl_ioctl}, selezionare con il comando
 \const{F\_SETOWN} di \func{fcntl} quale processo o quale gruppo di processi
 dovrà ricevere il segnale. In questo modo diventa possibile effettuare le
 operazioni di I/O in risposta alla ricezione del segnale, e non ci sarà più la
@@ -2612,7 +2622,7 @@ standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
 supportano meccanismi simili). Alcune di esse sono realizzate, e solo a
 partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
 \textsl{comandi} aggiuntivi per la funzione \func{fcntl} (vedi
-sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
+sez.~\ref{sec:file_fcntl_ioctl}), che divengono disponibili soltanto se si è
 definita la macro \macro{\_GNU\_SOURCE} prima di includere \headfile{fcntl.h}.
 
 \itindbeg{file~lease} 
@@ -2641,13 +2651,14 @@ un altro processo esegue l'apertura del file in scrittura o usa
 il file viene aperto in lettura; in quest'ultimo caso però il \textit{lease}
 può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
 
-Come accennato in sez.~\ref{sec:file_fcntl} il comando di \func{fcntl} che
-consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
-utilizzato anche per rilasciarlo. In tal caso il file descriptor \param{fd}
-passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
-operare, mentre per indicare il tipo di operazione (acquisizione o rilascio)
-occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
-uno dei tre valori di tab.~\ref{tab:file_lease_fctnl}.
+Come accennato in sez.~\ref{sec:file_fcntl_ioctl} il comando di \func{fcntl}
+che consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che
+viene utilizzato anche per rilasciarlo. In tal caso il file
+descriptor \param{fd} passato a \func{fcntl} servirà come riferimento per il
+file su cui si vuole operare, mentre per indicare il tipo di operazione
+(acquisizione o rilascio) occorrerà specificare come valore
+dell'argomento \param{arg} di \func{fcntl} uno dei tre valori di
+tab.~\ref{tab:file_lease_fctnl}.
 
 \begin{table}[htb]
   \centering
@@ -2873,16 +2884,15 @@ Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
 essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
 con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
   stato introdotto anche il supporto per il \itindex{signal~driven~I/O}
-  \texttt{signal-driven I/O} trattato in
-  sez.~\ref{sec:file_asyncronous_operation}.} siccome gli eventi vengono
-notificati come dati disponibili in lettura, dette funzioni ritorneranno tutte
-le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i
-segnali,\footnote{considerati una pessima scelta dal punto di vista
-  dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
-una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
-sez.~\ref{sec:file_multiplexing}. Qualora si voglia cessare l'osservazione,
-sarà sufficiente chiudere il file descriptor e tutte le risorse allocate
-saranno automaticamente rilasciate.
+  \texttt{signal-driven I/O} trattato in sez.~\ref{sec:signal_driven_io}.}
+siccome gli eventi vengono notificati come dati disponibili in lettura, dette
+funzioni ritorneranno tutte le volte che si avrà un evento di notifica. Così,
+invece di dover utilizzare i segnali,\footnote{considerati una pessima scelta
+  dal punto di vista dell'interfaccia utente.} si potrà gestire l'osservazione
+degli eventi con una qualunque delle modalità di \textit{I/O multiplexing}
+illustrate in sez.~\ref{sec:file_multiplexing}. Qualora si voglia cessare
+l'osservazione, sarà sufficiente chiudere il file descriptor e tutte le
+risorse allocate saranno automaticamente rilasciate.
 
 Infine l'interfaccia di \textit{inotify} consente di mettere sotto
 osservazione, oltre che una directory, anche singoli file.  Una volta creata
@@ -3105,11 +3115,11 @@ permette di ottenere con \func{ioctl}, come per i file descriptor associati ai
 socket (si veda sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in
 lettura sul file descriptor, utilizzando su di esso l'operazione
 \const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file
-  (vedi sez.~\ref{sec:file_ioctl}), che è disponibile solo per i socket e per
-  i file descriptor creati con \func{inotify\_init}.} Si può così utilizzare
-questa operazione, oltre che per predisporre una operazione di lettura con un
-buffer di dimensioni adeguate, anche per ottenere rapidamente il numero di
-file che sono cambiati.
+  (vedi sez.~\ref{sec:file_fcntl_ioctl}), che è disponibile solo per i socket
+  e per i file descriptor creati con \func{inotify\_init}.} Si può così
+utilizzare questa operazione, oltre che per predisporre una operazione di
+lettura con un buffer di dimensioni adeguate, anche per ottenere rapidamente
+il numero di file che sono cambiati.
 
 Una volta effettuata la lettura con \func{read} a ciascun evento sarà
 associata una struttura \struct{inotify\_event} contenente i rispettivi dati.
@@ -3229,8 +3239,8 @@ approssimativamente 512 eventi.\footnote{si ricordi che la quantità di dati
   del nome del file restituito insieme a \struct{inotify\_event}.} In caso di
 errore di lettura (\texttt{\small 35--40}) il programma esce con un messaggio
 di errore (\texttt{\small 37--39}), a meno che non si tratti di una
-interruzione della system call, nel qual caso (\texttt{\small 36}) si ripete la
-lettura.
+interruzione della \textit{system call}, nel qual caso (\texttt{\small 36}) si
+ripete la lettura.
 
 Se la lettura è andata a buon fine invece si esegue un ciclo (\texttt{\small
   43--52}) per leggere tutti gli eventi restituiti, al solito si inizializza
@@ -3314,7 +3324,9 @@ raggruppati in un solo evento.
 \subsection{L'interfaccia POSIX per l'I/O asincrono}
 \label{sec:file_asyncronous_io}
 
-% vedere anche http://davmac.org/davpage/linux/async-io.html
+% vedere anche http://davmac.org/davpage/linux/async-io.html  e
+% http://www.ibm.com/developerworks/linux/library/l-async/ 
+
 
 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
 dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
@@ -3326,12 +3338,12 @@ effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
 
 Benché la modalità di apertura asincrona di un file possa risultare utile in
 varie occasioni (in particolar modo con i socket e gli altri file per i quali
-le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
-comunque limitata alla notifica della disponibilità del file descriptor per le
-operazioni di I/O, e non ad uno svolgimento asincrono delle medesime.  Lo
-standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono vero
-e proprio, che prevede un insieme di funzioni dedicate per la lettura e la
-scrittura dei file, completamente separate rispetto a quelle usate
+le funzioni di I/O sono \index{system~call~lente} \textit{system call} lente),
+essa è comunque limitata alla notifica della disponibilità del file descriptor
+per le operazioni di I/O, e non ad uno svolgimento asincrono delle medesime.
+Lo standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono
+vero e proprio, che prevede un insieme di funzioni dedicate per la lettura e
+la scrittura dei file, completamente separate rispetto a quelle usate
 normalmente.
 
 In generale questa interfaccia è completamente astratta e può essere
@@ -3425,8 +3437,9 @@ richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
 il file non sia stato aperto in \itindex{append~mode} \textit{append mode}
-(vedi sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate
-comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
+(vedi sez.~\ref{sec:file_open_close}), nel qual caso le scritture vengono
+effettuate comunque alla fine de file, nell'ordine delle chiamate a
+\func{aio\_write}.
 
 Si tenga inoltre presente che deallocare la memoria indirizzata da
 \param{aiocbp} o modificarne i valori prima della conclusione di una
@@ -3462,8 +3475,8 @@ verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
 codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
-del caso, i codici di errore delle system call \func{read}, \func{write} e
-\func{fsync}.
+del caso, i codici di errore delle \textit{system call} \func{read},
+\func{write} e \func{fsync}.
 
 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
 che una chiamata ad \func{aio\_error} non ha restituito
@@ -3487,10 +3500,10 @@ l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
 precedente il completamento delle operazioni darebbe risultati indeterminati.
 
 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
-così come ricavato dalla sottostante system call (il numero di byte letti,
-scritti o il valore di ritorno di \func{fsync}).  É importante chiamare sempre
-questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
-asincrono non verrebbero liberate, rischiando di arrivare ad un loro
+così come ricavato dalla sottostante \textit{system call} (il numero di byte
+letti, scritti o il valore di ritorno di \func{fsync}).  É importante chiamare
+sempre questa funzione, altrimenti le risorse disponibili per le operazioni di
+I/O asincrono non verrebbero liberate, rischiando di arrivare ad un loro
 esaurimento.
 
 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
@@ -3653,9 +3666,10 @@ per il campo \var{aio\_sigevent} di \struct{aiocb}.
 Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
   asincrono}, esistono altre funzioni che implementano delle modalità di
 accesso ai file più evolute rispetto alle normali funzioni di lettura e
-scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
-sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
-  memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O avanzato.
+scrittura che abbiamo esaminato in sez.~\ref{sec:file_unix_interface}. In
+questa sezione allora prenderemo in esame le interfacce per l'\textsl{I/O
+  mappato in memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O
+avanzato.
 
 
 \subsection{File mappati in memoria}
@@ -3663,7 +3677,7 @@ sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
 
 \itindbeg{memory~mapping}
 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
-rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
+rispetto a quella classica vista in sez.~\ref{sec:file_unix_interface}, è il
 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
 \textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
@@ -3868,6 +3882,10 @@ tab.~\ref{tab:file_mmap_flag}.
 %     \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area
 %                              mappata con \func{mremap}, proposto ma pare non
 %                              implementato.\\
+%     \const{MAP\_HUGETLB}& da trattare.\\
+% TODO trattare MAP_HUGETLB introdotto con il kernel 2.6.32, e modifiche
+% introdotte con il 3.8 per le dimensioni variabili delle huge pages
+
     \hline
   \end{tabular}
   \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
@@ -3975,12 +3993,12 @@ consentita la scrittura sul file (cioè per un file mappato con
 o in corrispondenza di una eventuale \func{msync}.
 
 Dato per i file mappati in memoria le operazioni di I/O sono gestite
-direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere
+direttamente dalla \index{memoria~virtuale} memoria virtuale, occorre essere
 consapevoli delle interazioni che possono esserci con operazioni effettuate
-con l'interfaccia standard dei file di cap.~\ref{cha:file_unix_interface}. Il
-problema è che una volta che si è mappato un file, le operazioni di lettura e
-scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
-autonoma dal sistema della memoria virtuale.
+con l'interfaccia dei file di sez.~\ref{sec:file_unix_interface}. Il problema
+è che una volta che si è mappato un file, le operazioni di lettura e scrittura
+saranno eseguite sulla memoria, e riportate su disco in maniera autonoma dal
+sistema della memoria virtuale.
 
 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
 potranno essere visibili o meno a seconda del momento in cui la memoria
@@ -4211,7 +4229,7 @@ unix-like.  Diventa così possibile utilizzare una sola mappatura
 iniziale\footnote{e quindi una sola \textit{virtual memory area} nella
   \itindex{page~table} \textit{page table} del processo.} e poi rimappare a
 piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
-nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
+nuova \textit{system call}, \funcd{remap\_file\_pages}, il cui prototipo è:
 \begin{functions}  
   \headdecl{sys/mman.h} 
 
@@ -4426,13 +4444,13 @@ l'operazione sia facilmente eseguibile attraverso una serie multipla di
 chiamate a \func{read} e \func{write}, ci sono casi in cui si vuole poter
 contare sulla atomicità delle operazioni.
 
-Per questo motivo fino da BSD 4.2 vennero introdotte delle nuove system call
-che permettessero di effettuare con una sola chiamata una serie di letture o
-scritture su una serie di buffer, con quello che viene normalmente chiamato
-\textsl{I/O vettorizzato}. Queste funzioni sono \funcd{readv} e
-\funcd{writev},\footnote{in Linux le due funzioni sono riprese da BSD4.4, esse
-  sono previste anche dallo standard POSIX.1-2001.} ed i relativi prototipi
-sono:
+Per questo motivo fino da BSD 4.2 vennero introdotte delle nuove
+\textit{system call} che permettessero di effettuare con una sola chiamata una
+serie di letture o scritture su una serie di buffer, con quello che viene
+normalmente chiamato \textsl{I/O vettorizzato}. Queste funzioni sono
+\funcd{readv} e \funcd{writev},\footnote{in Linux le due funzioni sono riprese
+  da BSD4.4, esse sono previste anche dallo standard POSIX.1-2001.} ed i
+relativi prototipi sono:
 \begin{functions}
   \headdecl{sys/uio.h}
   
@@ -4493,20 +4511,20 @@ indicato dal valore dalla costante \const{IOV\_MAX}, definita come le altre
 costanti analoghe (vedi sez.~\ref{sec:sys_limits}) in \headfile{limits.h}; lo
 stesso valore deve essere ottenibile in esecuzione tramite la funzione
 \func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
-sez.~\ref{sec:sys_sysconf}).
+sez.~\ref{sec:sys_limits}).
 
 Nel caso di Linux il limite di sistema è di 1024, però se si usano le
-\acr{glibc} queste forniscono un \textit{wrapper} per le system call che si
-accorge se una operazione supererà il precedente limite, in tal caso i dati
-verranno letti o scritti con le usuali \func{read} e \func{write} usando un
-buffer di dimensioni sufficienti appositamente allocato e sufficiente a
+\acr{glibc} queste forniscono un \textit{wrapper} per le \textit{system call}
+che si accorge se una operazione supererà il precedente limite, in tal caso i
+dati verranno letti o scritti con le usuali \func{read} e \func{write} usando
+un buffer di dimensioni sufficienti appositamente allocato e sufficiente a
 contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
 ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
 
 Si tenga presente infine che queste funzioni operano sui file con
 l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
 l'interfaccia classica dei \textit{file stream} di
-cap.~\ref{cha:files_std_interface}; a causa delle bufferizzazioni interne di
+sez.~\ref{sec:files_std_interface}; a causa delle bufferizzazioni interne di
 quest'ultima infatti si potrebbero avere risultati indefiniti e non
 corrispondenti a quanto aspettato.
 
@@ -4516,7 +4534,7 @@ maniera atomica a partire da un certa posizione sul file. Per questo motivo a
 partire dal kernel 2.6.30 sono state introdotte anche per l'\textsl{I/O
   vettorizzato} le analoghe delle funzioni \func{pread} e \func{pwrite} (vedi
 sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
-\funcd{preadv} e \func{pwritev} ed i rispettivi prototipi sono:\footnote{le
+\funcd{preadv} e \funcd{pwritev} ed i rispettivi prototipi sono:\footnote{le
   due funzioni sono analoghe alle omonime presenti in BSD; le \textit{system
     call} usate da Linux (introdotte a partire dalla versione 2.6.30)
   utilizzano degli argomenti diversi per problemi collegati al formato a 64
@@ -4679,16 +4697,16 @@ semplicemente un ``\textsl{dimezzamento}'' di \func{sendfile}.\footnote{nel
   senso che un trasferimento di dati fra due file con \func{sendfile} non
   sarebbe altro che la lettura degli stessi su un buffer seguita dalla
   relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
-  chiamate a \func{splice}.} In realtà le due system call sono profondamente
-diverse nel loro meccanismo di funzionamento;\footnote{questo fino al kernel
-  2.6.23, dove \func{sendfile} è stata reimplementata in termini di
-  \func{splice}, pur mantenendo disponibile la stessa interfaccia verso l'user
-  space.} \func{sendfile} infatti, come accennato, non necessita di avere a
-disposizione un buffer interno, perché esegue un trasferimento diretto di
-dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
-applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
-specifici.\footnote{e nel caso di Linux questi sono anche solo quelli in cui
-  essa può essere effettivamente utilizzata.}
+  chiamate a \func{splice}.} In realtà le due \textit{system call} sono
+profondamente diverse nel loro meccanismo di funzionamento;\footnote{questo
+  fino al kernel 2.6.23, dove \func{sendfile} è stata reimplementata in
+  termini di \func{splice}, pur mantenendo disponibile la stessa interfaccia
+  verso l'user space.} \func{sendfile} infatti, come accennato, non necessita
+di avere a disposizione un buffer interno, perché esegue un trasferimento
+diretto di dati; questo la rende in generale più efficiente, ma anche limitata
+nelle sue applicazioni, dato che questo tipo di trasferimento è possibile solo
+in casi specifici.\footnote{e nel caso di Linux questi sono anche solo quelli
+  in cui essa può essere effettivamente utilizzata.}
 
 Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
   realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
@@ -5028,7 +5046,7 @@ La funzione copia \param{len} byte del contenuto di una \textit{pipe} su di
 un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
 sorgente e \param{fd\_out} il capo in scrittura della \textit{pipe}
 destinazione; a differenza di quanto avviene con \func{read} i dati letti con
-\func{tee} da \func{fd\_in} non vengono \textsl{consumati} e restano
+\func{tee} da \param{fd\_in} non vengono \textsl{consumati} e restano
 disponibili sulla \textit{pipe} per una successiva lettura (di nuovo per il
 comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al
 momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio
@@ -5087,16 +5105,16 @@ fig.~\ref{fig:splice_example}).
 
 Infine una nota finale riguardo \func{splice}, \func{vmsplice} e \func{tee}:
 occorre sottolineare che benché finora si sia parlato di trasferimenti o copie
-di dati in realtà nella implementazione di queste system call non è affatto
-detto che i dati vengono effettivamente spostati o copiati, il kernel infatti
-realizza le \textit{pipe} come un insieme di puntatori\footnote{per essere
-  precisi si tratta di un semplice buffer circolare, un buon articolo sul tema
-  si trova su \url{http://lwn.net/Articles/118750/}.}  alle pagine di memoria
-interna che contengono i dati, per questo una volta che i dati sono presenti
-nella memoria del kernel tutto quello che viene fatto è creare i suddetti
-puntatori ed aumentare il numero di referenze; questo significa che anche con
-\func{tee} non viene mai copiato nessun byte, vengono semplicemente copiati i
-puntatori.
+di dati in realtà nella implementazione di queste \textit{system call} non è
+affatto detto che i dati vengono effettivamente spostati o copiati, il kernel
+infatti realizza le \textit{pipe} come un insieme di puntatori\footnote{per
+  essere precisi si tratta di un semplice buffer circolare, un buon articolo
+  sul tema si trova su \url{http://lwn.net/Articles/118750/}.}  alle pagine di
+memoria interna che contengono i dati, per questo una volta che i dati sono
+presenti nella memoria del kernel tutto quello che viene fatto è creare i
+suddetti puntatori ed aumentare il numero di referenze; questo significa che
+anche con \func{tee} non viene mai copiato nessun byte, vengono semplicemente
+copiati i puntatori.
 
 % TODO?? dal 2.6.25 splice ha ottenuto il supporto per la ricezione su rete
 
@@ -5407,15 +5425,11 @@ livello di kernel.
 % vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
 % http://kernelnewbies.org/Linux_2_6_23
 
-
-
-
-
 % TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
 % http://lwn.net/Articles/432757/ 
 
 
-% LocalWords:  dell'I locking multiplexing cap dell' sez system call socket BSD
+% LocalWords:  dell'I locking multiplexing cap sez system call socket BSD
 % LocalWords:  descriptor client deadlock NONBLOCK EAGAIN polling select kernel
 % LocalWords:  pselect like sys unistd int fd readfds writefds exceptfds struct
 % LocalWords:  timeval errno EBADF EINTR EINVAL ENOMEM sleep tab signal void of