X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=ade65bcbb9ded2a06945e7553e8111aca86b54e1;hp=e69c9d7dad9448559e67af400d7d6803eb2597bc;hb=4aa6c51696d2b11c572eccd37238db1691785573;hpb=4a64ffb309155737e851268a29e4217987a9c15e

diff --git a/fileadv.tex b/fileadv.tex
index e69c9d7..ade65bc 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1,6 +1,6 @@
 %% fileadv.tex
 %%
-%% Copyright (C) 2000-2011 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2012 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",
@@ -24,7 +24,7 @@ controllo più dettagliato delle modalità di I/O.
 \section{Il \textit{file locking}}
 \label{sec:file_locking}
 
-\index{file!locking|(}
+\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
@@ -223,7 +223,7 @@ fondamentale da capire è che un \textit{file lock}, qualunque sia
 l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
 agisce sempre su di un file; perciò le informazioni relative agli eventuali
 \textit{file lock} sono mantenute dal kernel a livello di
-inode\index{inode},\footnote{in particolare, come accennato in
+inode\itindex{inode},\footnote{in particolare, come accennato in
   fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti in una
   \itindex{linked~list} \textit{linked list} di strutture
   \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
@@ -234,7 +234,7 @@ inode\index{inode},\footnote{in particolare, come accennato in
 dato che questo è l'unico riferimento in comune che possono avere due processi
 diversi che aprono lo stesso file.
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering
   \includegraphics[width=15.5cm]{img/file_flock}
   \caption{Schema dell'architettura del \textit{file locking}, nel caso
@@ -333,9 +333,9 @@ che un \textit{file lock} fa sempre riferimento ad una regione, per cui si
 potrà avere un conflitto anche se c'è soltanto una sovrapposizione parziale
 con un'altra regione bloccata.
 
-\begin{figure}[!bht]
+\begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/flock.h}
   \end{minipage} 
   \normalsize 
@@ -385,7 +385,7 @@ riportate in tab.~\ref{tab:file_flock_type}, che permettono di richiedere
 rispettivamente uno \textit{shared lock}, un \textit{esclusive lock}, e la
 rimozione di un blocco precedentemente acquisito. Infine il campo \var{l\_pid}
 viene usato solo in caso di lettura, quando si chiama \func{fcntl} con
-\const{F\_GETLK}, e riporta il \acr{pid} del processo che detiene il
+\const{F\_GETLK}, e riporta il \ids{PID} del processo che detiene il
 \textit{file lock}.
 
 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
@@ -433,7 +433,7 @@ chiamate) per cui si deve sempre verificare il codice di ritorno di
 quando la si invoca con \const{F\_SETLK}, per controllare che il blocco sia
 stato effettivamente acquisito.
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering \includegraphics[width=9cm]{img/file_lock_dead}
   \caption{Schema di una situazione di \itindex{deadlock} \textit{deadlock}.}
   \label{fig:file_flock_dead}
@@ -462,16 +462,16 @@ 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
   semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
-  \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
+  \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 è
   comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
   impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
-  usato.} il blocco è sempre associato \index{inode} all'inode, solo che in
+  usato.} il blocco è sempre associato \itindex{inode} all'inode, solo che in
 questo caso la titolarità non viene identificata con il riferimento ad una
 voce nella \itindex{file~table} \textit{file table}, ma con il valore del
-\acr{pid} del processo.
+\ids{PID} del processo.
 
-\begin{figure}[!bht]
+\begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/file_posix_lock}
   \caption{Schema dell'architettura del \textit{file locking}, nel caso
     particolare del suo utilizzo secondo l'interfaccia standard POSIX.}
@@ -488,19 +488,19 @@ una già bloccata, in caso affermativo decide in base al tipo di blocco, in
 caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
 
 Nel caso di rimozione invece questa viene effettuata controllando che il
-\acr{pid} del processo richiedente corrisponda a quello contenuto nel blocco.
+\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco.
 Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
 dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
 POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
-figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
-\func{exec} in quanto il \acr{pid} resta lo stesso.  Questo comporta che, al
+figlio avrà un \ids{PID} diverso, mentre passa indenne attraverso una
+\func{exec} in quanto il \ids{PID} resta lo stesso.  Questo comporta che, al
 contrario di quanto avveniva con la semantica BSD, quando un processo termina
 tutti i \textit{file lock} da esso detenuti vengono immediatamente rilasciati.
 
 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
 \func{open} in questo caso non fa differenza) può essere usato per rimuovere
-un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
+un blocco, dato che quello che conta è solo il \ids{PID} del processo. Da
 questo deriva una ulteriore sottile differenza di comportamento: dato che alla
 chiusura di un file i blocchi ad esso associati vengono rimossi, nella
 semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
@@ -508,11 +508,11 @@ tutti i blocchi relativi al file cui esso faceva riferimento, anche se questi
 fossero stati creati usando altri file descriptor che restano aperti.
 
 Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del
-\acr{pid} del processo, possiamo anche prendere in considerazione un altro
+\ids{PID} del processo, possiamo anche prendere in considerazione un altro
 degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
 richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno
 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
-solo sul \acr{pid} del processo che chiama la funzione, queste richieste
+solo sul \ids{PID} del processo che chiama la funzione, queste richieste
 avranno sempre successo.
 
 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
@@ -535,9 +535,9 @@ preoccuparsi di accorpare o dividere le voci nella lista dei \textit{file
   lock} per far si che le regioni bloccate da essa risultanti siano coerenti
 con quanto necessario a soddisfare l'operazione richiesta.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/Flock.c}
   \end{minipage} 
   \normalsize 
@@ -799,7 +799,7 @@ affatto equivalente a \func{flock}).
 \subsection{Il \textit{mandatory locking}}
 \label{sec:file_mand_locking}
 
-\itindbeg{mandatory~locking|(}
+\itindbeg{mandatory~locking}
 
 Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
 per introdurre un \textit{file locking} che, come dice il nome, fosse
@@ -811,7 +811,7 @@ opportune verifiche nei processi, questo verrebbe comunque rispettato.
 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
 utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
 quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
-utilizzato per cambiare il group-ID effettivo con cui viene eseguito un
+utilizzato per cambiare il \ids{GID} effettivo con cui viene eseguito un
 programma, ed è pertanto sempre associato alla presenza del permesso di
 esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
 esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
@@ -835,7 +835,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 tab.~\ref{tab:sys_mount_flags}, o con l'opzione
+\func{mount} riportata in sez.~\ref{sec:sys_file_config}), o con l'opzione
 \code{-o mand} per il comando omonimo).
 
 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
@@ -890,9 +890,9 @@ soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
 qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
 possibilità di modificare il file.
 
-\index{file!locking|)}
+\itindend{file~locking}
 
-\itindend{mandatory~locking|(}
+\itindend{mandatory~locking}
 
 
 \section{L'\textit{I/O multiplexing}}
@@ -1173,13 +1173,14 @@ funzione.
 L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
 \textit{race condition} \itindex{race~condition} quando ci si deve porre in
 attesa sia di un segnale che di dati. La tecnica classica è quella di
-utilizzare il gestore per impostare una variabile globale e controllare questa
-nel corpo principale del programma; abbiamo visto in
-sez.~\ref{sec:sig_example} come questo lasci spazio a possibili race
-condition, per cui diventa essenziale utilizzare \func{sigprocmask} per
-disabilitare la ricezione del segnale prima di eseguire il controllo e
-riabilitarlo dopo l'esecuzione delle relative operazioni, onde evitare
-l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe perso.
+utilizzare il gestore per impostare una \index{variabili!globali} variabile
+globale e controllare questa nel corpo principale del programma; abbiamo visto
+in sez.~\ref{sec:sig_example} come questo lasci spazio a possibili
+\itindex{race~condition} \textit{race condition}, per cui diventa essenziale
+utilizzare \func{sigprocmask} per disabilitare la ricezione del segnale prima
+di eseguire il controllo e riabilitarlo dopo l'esecuzione delle relative
+operazioni, onde evitare l'arrivo di un segnale immediatamente dopo il
+controllo, che andrebbe perso.
 
 Nel nostro caso il problema si pone quando oltre al segnale si devono tenere
 sotto controllo anche dei file descriptor con \func{select}, in questo caso si
@@ -1235,7 +1236,7 @@ cui prototipo è:
     degli insiemi.
   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
-    \macro{RLIMIT\_NOFILE}.
+    \const{RLIMIT\_NOFILE}.
   \end{errlist}
   ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
 \end{prototype}
@@ -1264,7 +1265,7 @@ strutture \struct{pollfd} a meno di non voler cambiare qualche condizione.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/pollfd.h}
   \end{minipage} 
   \normalsize 
@@ -1394,7 +1395,7 @@ prototipo è:
     degli insiemi.
   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
-    \macro{RLIMIT\_NOFILE}.
+    \const{RLIMIT\_NOFILE}.
   \end{errlist}
   ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
 \end{prototype}
@@ -1520,7 +1521,7 @@ sono:
     nel sistema.
   \item[\errcode{EMFILE}] si è raggiunto il limite sul numero massimo di
     istanze di \textit{epoll} per utente stabilito da
-    \procfile{/proc/sys/fs/epoll/max\_user\_instances}.
+    \sysctlfile{fs/epoll/max\_user\_instances}.
   \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
     l'istanza.
   \end{errlist}
@@ -1575,7 +1576,7 @@ controllare, per questo si deve usare la seconda funzione dell'interfaccia,
   \item[\errcode{EPERM}] il file \param{fd} non supporta \textit{epoll}.
   \item[\errcode{ENOSPC}] si è raggiunto il limite massimo di registrazioni
     per utente di file descriptor da osservare imposto da
-    \procfile{/proc/sys/fs/epoll/max\_user\_watches}.
+    \sysctlfile{fs/epoll/max\_user\_watches}.
   \end{errlist}
 }
 \end{prototype}
@@ -1631,7 +1632,7 @@ sotto controllo.  L'argomento viene ignorato con l'operazione
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/epoll_event.h}
   \end{minipage} 
   \normalsize 
@@ -1650,7 +1651,7 @@ definizione è riportata in fig.~\ref{fig:epoll_event}.
 Il primo campo, \var{events}, è una maschera binaria in cui ciascun bit
 corrisponde o ad un tipo di evento, o una modalità di notifica; detto campo
 deve essere specificato come OR aritmetico delle costanti riportate in
-tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, è una \ctyp{union}
+tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, è una \direct{union}
 che serve a identificare il file descriptor a cui si intende fare riferimento,
 ed in astratto può contenere un valore qualsiasi (specificabile in diverse
 forme) che ne permetta una indicazione univoca. Il modo più comune di usarlo
@@ -1974,8 +1975,8 @@ 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 \const{SIGKILL} e
-\const{SIGSTOP} non possono essere intercettati (e non prevedono neanche la
+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. 
 
@@ -2076,7 +2077,7 @@ successivo con \func{fcntl}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/signalfd_siginfo.h}
   \end{minipage} 
   \normalsize 
@@ -2119,9 +2120,9 @@ necessarie. Al solito si è tralasciata la parte dedicata alla decodifica delle
 opzioni che consentono ad esempio di cambiare il nome del file associato alla
 fifo.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/FifoReporter-init.c}
   \end{minipage} 
   \normalsize 
@@ -2133,8 +2134,8 @@ fifo.
 Il primo passo (\texttt{\small 19--20}) è la crezione di un file descriptor
 \texttt{epfd} di \itindex{epoll} \textit{epoll} con \func{epoll\_create} che è
 quello che useremo per il controllo degli altri.  É poi necessario
-disabilitare la ricezione dei segnali (nel caso \const{SIGINT},
-\const{SIGQUIT} e \const{SIGTERM}) per i quali si vuole la notifica tramite
+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
@@ -2150,9 +2151,9 @@ volta fatto questo sarà necessario aggiungere il relativo file descriptor
 del tutto analoga a quanto fatto con quello relativo alla notifica dei
 segnali.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/FifoReporter-main.c}
   \end{minipage} 
   \normalsize 
@@ -2493,7 +2494,7 @@ 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
   con socket, file di terminale o pseudo terminale, ed anche, a partire dal
   kernel 2.6, anche per fifo e pipe.} il sistema genera un apposito segnale,
-\const{SIGIO}, tutte le volte che diventa possibile leggere o scrivere dal
+\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
 \const{F\_SETOWN} di \func{fcntl} quale processo o quale gruppo di processi
@@ -2535,7 +2536,7 @@ sez.~\ref{sec:sig_sigaction}).
 Per far questo però occorre utilizzare le funzionalità dei segnali real-time
 (vedi sez.~\ref{sec:sig_real_time}) impostando esplicitamente con il comando
 \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
-I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
+I/O asincrono (il segnale predefinito è \signal{SIGIO}). In questo caso il
 gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo
 \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia il
   segnale che si è associato all'I/O, ed indica appunto che il segnale è stato
@@ -2553,14 +2554,14 @@ la coda.
 
 Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo
 più assicurare il comportamento corretto per un segnale real-time, invierà al
-suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali
+suo posto un solo \signal{SIGIO}, su cui si saranno accumulati tutti i segnali
 in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
 diventati attivi. L'unico modo per essere sicuri che questo non avvenga è di
 impostare la lunghezza della coda dei segnali real-time ad una dimensione
 identica al valore massimo del numero di file descriptor
 utilizzabili.\footnote{vale a dire impostare il contenuto di
-  \procfile{/proc/sys/kernel/rtsig-max} allo stesso valore del contenuto di
-  \procfile{/proc/sys/fs/file-max}.}
+  \sysctlfile{kernel/rtsig-max} allo stesso valore del contenuto di
+  \sysctlfile{fs/file-max}.}
 
 % TODO fare esempio che usa O_ASYNC
 
@@ -2581,7 +2582,7 @@ classico non prevedeva alcun meccanismo per cui un processo possa essere
 \textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
 motivo per cui i demoni devono essere \textsl{avvisati} in qualche
 modo\footnote{in genere questo vien fatto inviandogli un segnale di
-  \const{SIGHUP} che, per una convenzione adottata dalla gran parte di detti
+  \signal{SIGHUP} che, per una convenzione adottata dalla gran parte di detti
   programmi, causa la rilettura della configurazione.} se il loro file di
 configurazione è stato modificato, perché possano rileggerlo e riconoscere le
 modifiche.
@@ -2612,7 +2613,7 @@ partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
 sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
 definita la macro \macro{\_GNU\_SOURCE} prima di includere \file{fcntl.h}.
 
-\index{file!lease|(} 
+\itindbeg{file~lease} 
 
 La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
 questo è un meccanismo che consente ad un processo, detto \textit{lease
@@ -2622,9 +2623,9 @@ questo è un meccanismo che consente ad un processo, detto \textit{lease
 \textit{lease}.
 La notifica avviene in maniera analoga a come illustrato in precedenza per
 l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
-il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
+il segnale \signal{SIGIO}, ma questo segnale può essere modificato usando il
 comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
-  può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
+  può rispecificare lo stesso \signal{SIGIO}.} Se si è fatto questo\footnote{è
   in genere è opportuno farlo, come in precedenza, per utilizzare segnali
   real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
 si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
@@ -2676,7 +2677,7 @@ Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
 su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
 (pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
 può ottenere un \textit{lease} soltanto per un file appartenente ad un
-\acr{uid} corrispondente a quello del processo. Soltanto un processo con
+\ids{UID} corrispondente a quello del processo. Soltanto un processo con
 privilegi di amministratore (cioè con la \itindex{capabilities} capability
 \const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
 \textit{lease} su qualunque file.
@@ -2710,7 +2711,7 @@ operazione di lettura, declassando il \textit{lease} a lettura con
 
 Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
 il numero di secondi specificato dal parametro di sistema mantenuto in
-\procfile{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
+\sysctlfile{fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
 declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
   evitare che un processo blocchi indefinitamente l'accesso ad un file
   acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
@@ -2737,14 +2738,14 @@ un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
   stata definita la macro \macro{\_GNU\_SOURCE}.} chiamata \textit{dnotify},
 che consente di richiedere una notifica quando una directory, o uno qualunque
 dei file in essa contenuti, viene modificato.  Come per i \textit{file lease}
-la notifica avviene di default attraverso il segnale \const{SIGIO}, ma se ne
+la notifica avviene di default attraverso il segnale \signal{SIGIO}, ma se ne
 può utilizzare un altro.\footnote{e di nuovo, per le ragioni già esposte in
   precedenza, è opportuno che si utilizzino dei segnali real-time.} Inoltre,
 come in precedenza, si potrà ottenere nel gestore del segnale il file
 descriptor che è stato modificato tramite il contenuto della struttura
 \struct{siginfo\_t}.
 
-\index{file!lease|)}
+\itindend{file~lease}
 
 \begin{table}[htb]
   \centering
@@ -2856,7 +2857,7 @@ effettuate le operazioni di notifica;\footnote{per evitare abusi delle risorse
   di sistema è previsto che un utente possa utilizzare un numero limitato di
   istanze di \textit{inotify}; il valore di default del limite è di 128, ma
   questo valore può essere cambiato con \func{sysctl} o usando il file
-  \procfile{/proc/sys/fs/inotify/max\_user\_instances}.} si tratta di un file
+  \sysctlfile{fs/inotify/max\_user\_instances}.} si tratta di un file
 descriptor speciale che non è associato a nessun file su disco, e che viene
 utilizzato solo per notificare gli eventi che sono stati posti in
 osservazione. Dato che questo file descriptor non è associato a nessun file o
@@ -2917,7 +2918,7 @@ modalità della stessa.  L'operazione può essere ripetuta per tutti i file e le
 directory che si vogliono tenere sotto osservazione,\footnote{anche in questo
   caso c'è un limite massimo che di default è pari a 8192, ed anche questo
   valore può essere cambiato con \func{sysctl} o usando il file
-  \procfile{/proc/sys/fs/inotify/max\_user\_watches}.} e si utilizzerà sempre
+  \sysctlfile{fs/inotify/max\_user\_watches}.} e si utilizzerà sempre
 un solo file descriptor.
 
 Il tipo di evento che si vuole osservare deve essere specificato
@@ -3088,7 +3089,7 @@ modalità non bloccante) fino all'arrivo di almeno un evento.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/inotify_event.h}
   \end{minipage} 
   \normalsize 
@@ -3151,7 +3152,7 @@ aggiuntivi\footnote{questi compaiono solo nel campo \var{mask} di
 \end{table}
 
 \footnotetext{la coda di notifica ha una dimensione massima specificata dal
-  parametro di sistema \procfile{/proc/sys/fs/inotify/max\_queued\_events} che
+  parametro di sistema \sysctlfile{fs/inotify/max\_queued\_events} che
   indica il numero massimo di eventi che possono essere mantenuti sulla
   stessa; quando detto valore viene ecceduto gli ulteriori eventi vengono
   scartati, ma viene comunque generato un evento di tipo
@@ -3185,7 +3186,7 @@ funzioni di ausilio è riportato in fig.~\ref{fig:inotify_monitor_example}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/inotify_monitor.c}
   \end{minipage}
   \normalsize
@@ -3350,7 +3351,7 @@ disponibilità dell'interfaccia per l'I/O asincrono.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/aiocb.h}
   \end{minipage} 
   \normalsize 
@@ -3430,10 +3431,10 @@ Si tenga inoltre presente che deallocare la memoria indirizzata da
 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
 richiesta.  Questo comporta che non si devono usare per \param{aiocbp}
-variabili automatiche e che non si deve riutilizzare la stessa struttura per
-un'altra operazione fintanto che la precedente non sia stata ultimata. In
-generale per ogni operazione si deve utilizzare una diversa struttura
-\struct{aiocb}.
+\index{variabili!automatiche} variabili automatiche e che non si deve
+riutilizzare la stessa struttura per un'altra operazione fintanto che la
+precedente non sia stata ultimata. In generale per ogni operazione si deve
+utilizzare una diversa struttura \struct{aiocb}.
 
 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
 \func{aio\_write} non implica che le operazioni siano state effettivamente
@@ -3785,7 +3786,7 @@ Il valore dell'argomento \param{prot} indica la protezione\footnote{come
   pagine di memoria reale, ed le modalità di accesso (lettura, esecuzione,
   scrittura); una loro violazione causa quella una \itindex{segment~violation}
   \textit{segment violation}, e la relativa emissione del segnale
-  \const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
+  \signal{SIGSEGV}.} da applicare al segmento di memoria e deve essere
 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
 riportati in tab.~\ref{tab:file_mmap_prot}; il valore specificato deve essere
 compatibile con la modalità di accesso con cui si è aperto il file.
@@ -3841,7 +3842,7 @@ tab.~\ref{tab:file_mmap_flag}.
                              modifiche fatte alla regione mappata, in
                              questo caso dopo una scrittura, se non c'è più
                              memoria disponibile, si ha l'emissione di
-                             un \const{SIGSEGV}.\\
+                             un \signal{SIGSEGV}.\\
     \const{MAP\_LOCKED}    & Se impostato impedisce lo swapping delle pagine
                              mappate.\\
     \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} \textit{stack}. 
@@ -3888,7 +3889,7 @@ piuttosto complessi, essi si possono comprendere solo tenendo presente che
 tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
 memoria virtuale. Questo comporta allora una serie di conseguenze. La più
 ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
-avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
+avrà l'emissione di un segnale di violazione di accesso (\signal{SIGSEGV}),
 dato che i permessi sul segmento di memoria relativo non consentono questo
 tipo di accesso.
 
@@ -3915,7 +3916,7 @@ verrà il file sarà mappato su un segmento di memoria che si estende fino al
 bordo della pagina successiva.
 
 In questo caso è possibile accedere a quella zona di memoria che eccede le
-dimensioni specificate da \param{length}, senza ottenere un \const{SIGSEGV}
+dimensioni specificate da \param{length}, senza ottenere un \signal{SIGSEGV}
 poiché essa è presente nello spazio di indirizzi del processo, anche se non è
 mappata sul file. Il comportamento del sistema è quello di restituire un
 valore nullo per quanto viene letto, e di non riportare su file quanto viene
@@ -3929,8 +3930,8 @@ quella della mappatura in memoria.
 In questa situazione, per la sezione di pagina parzialmente coperta dal
 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
-sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
-\const{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
+sarà più possibile, ma il segnale emesso non sarà \signal{SIGSEGV}, ma
+\signal{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
 
 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
 in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
@@ -4464,7 +4465,7 @@ essere letti o scritti ed in che quantità. Il primo campo della struttura,
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/iovec.h}
   \end{minipage} 
   \normalsize 
@@ -4537,7 +4538,7 @@ sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
     per \var{errno} anche i valori:
   \begin{errlist}
   \item[\errcode{EOVERFLOW}] \param{offset} ha un valore che non può essere
-    usato come \ctyp{off\_t}.
+    usato come \type{off\_t}.
   \item[\errcode{ESPIPE}] \param{fd} è associato ad un socket o una pipe.
   \end{errlist}
 }
@@ -4653,8 +4654,7 @@ significativi delle prestazioni rispetto all'uso in sequenza di \func{read} e
 che anzi in certi casi si potevano avere anche dei peggioramenti.  Questo ha
 portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
   questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
-  in \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
-  {\textsf{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
+  in \url{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}.}
 alla decisione di consentire l'uso della funzione soltanto quando il file da
 cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
 non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
@@ -4693,18 +4693,18 @@ Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
   scopi da \func{sendfile}, quello che rende \func{splice} davvero diversa è
   stata la reinterpretazione che ne è stata fatta nell'implementazione su
   Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
-  dallo stesso Linus Torvalds in \href{http://kerneltrap.org/node/6505}
-  {\textsf{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
-funzione che consente di fare in maniera del tutto generica delle operazioni
-di trasferimento di dati fra un file e un buffer gestito interamente in kernel
-space. In questo caso il cuore della funzione (e delle affini \func{vmsplice}
-e \func{tee}, che tratteremo più avanti) è appunto l'uso di un buffer in
-kernel space, e questo è anche quello che ne ha semplificato l'adozione,
-perché l'infrastruttura per la gestione di un tale buffer è presente fin dagli
-albori di Unix per la realizzazione delle \textit{pipe} (vedi
-sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale allora \func{splice}
-non è altro che una diversa interfaccia (rispetto alle \textit{pipe}) con cui
-utilizzare in user space l'oggetto ``\textsl{buffer in kernel space}''.
+  dallo stesso Linus Torvalds in \url{http://kerneltrap.org/node/6505}.} si
+tratta semplicemente di una funzione che consente di fare in maniera del tutto
+generica delle operazioni di trasferimento di dati fra un file e un buffer
+gestito interamente in kernel space. In questo caso il cuore della funzione (e
+delle affini \func{vmsplice} e \func{tee}, che tratteremo più avanti) è
+appunto l'uso di un buffer in kernel space, e questo è anche quello che ne ha
+semplificato l'adozione, perché l'infrastruttura per la gestione di un tale
+buffer è presente fin dagli albori di Unix per la realizzazione delle
+\textit{pipe} (vedi sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale
+allora \func{splice} non è altro che una diversa interfaccia (rispetto alle
+\textit{pipe}) con cui utilizzare in user space l'oggetto ``\textsl{buffer in
+  kernel space}''.
 
 Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
 come area di memoria (vedi fig.~\ref{fig:ipc_pipe_singular}) dove appoggiare i
@@ -4875,9 +4875,9 @@ file destinazione. Il passo successivo è aprire il file sorgente
 (\texttt{\small 18--22}), quello di destinazione (\texttt{\small 23--27}) ed
 infine (\texttt{\small 28--31}) la \textit{pipe} che verrà usata come buffer.
 
-\begin{figure}[!phtb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/splicecp.c}
   \end{minipage}
   \normalsize
@@ -5050,7 +5050,7 @@ allegati alla guida.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/tee.c}
   \end{minipage}
   \normalsize
@@ -5089,12 +5089,12 @@ 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 \href{http://lwn.net/Articles/118750/}
-  {\textsf{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.
+  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
 
@@ -5174,7 +5174,7 @@ nelle operazioni successive.
 
 Il concetto di \func{readahead} viene generalizzato nello standard
 POSIX.1-2001 dalla funzione \func{posix\_fadvise},\footnote{anche se
-  l'argomento \param{len} è stato modificato da \ctyp{size\_t} a \ctyp{off\_t}
+  l'argomento \param{len} è stato modificato da \type{size\_t} a \type{off\_t}
   nella revisione POSIX.1-2003 TC5.} che consente di ``\textsl{avvisare}'' il
 kernel sulle modalità con cui si intende accedere nel futuro ad una certa
 porzione di un file,\footnote{la funzione però è stata introdotta su Linux
@@ -5356,7 +5356,7 @@ Trattandosi di una funzione di servizio, ed ovviamente disponibile
 esclusivamente su Linux, inizialmente \funcd{fallocate} non era stata definita
 come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
   in maniera indiretta con l'ausilio di \func{syscall}, vedi
-  sez.~\ref{sec:intro_syscall}, come \code{long fallocate(int fd, int mode,
+  sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
       loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
   stato fornito un supporto esplicito; il suo prototipo è:
 \begin{functions}