X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=ac07597e75951f2433f9dab94a48da0fc4f68c5c;hb=70885537614fe3332312bc9e9fcd900e04f22451;hp=9cd3f899b0918211007e63bb589573863ebd8c10;hpb=9ae76fdeacb0ff52559c8bf310b20d485ccc9328;p=gapil.git

diff --git a/filedir.tex b/filedir.tex
index 9cd3f89..ac07597 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -1,6 +1,6 @@
 %% filedir.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",
@@ -287,12 +287,12 @@ di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
 \end{figure}
 
 Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
-contiene, oltre ad alcune informazioni usate dall'interfaccia dei file
-descriptor il cui significato emergerà più avanti, il puntatore \struct{f\_op}
-ad una struttura \kstruct{file\_operation}. Questa è l'analoga per i file di
-\kstruct{inode\_operation}, e definisce le operazioni generiche fornite dal
-VFS per i file. Si sono riportate in tab.~\ref{tab:file_file_operations} le
-più significative.
+\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
+dei file descriptor il cui significato emergerà più avanti, il puntatore
+\struct{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga
+per i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
+fornite dal VFS per i file. Si sono riportate in
+tab.~\ref{tab:file_file_operations} le più significative.
 
 \begin{table}[htb]
   \centering
@@ -332,7 +332,7 @@ Anche in questo caso tutte le volte che deve essere eseguita una
 \textit{system call} o una qualunque altra operazione sul file il VFS andrà ad
 utilizzare la funzione corrispondente attraverso il puntatore
 \var{f\_op}. Dato che è cura del VFS quando crea la struttura all'apertura del
-file, assegnare a \var{f\_op} il puntatore alla versione di
+file assegnare a \var{f\_op} il puntatore alla versione di
 \kstruct{file\_operation} corretta per quel file, sarà possibile scrivere allo
 stesso modo sulla porta seriale come su un normale file di dati, e lavorare
 sui file allo stesso modo indipendentemente dal filesystem.
@@ -340,12 +340,12 @@ sui file allo stesso modo indipendentemente dal filesystem.
 Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
 alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
 \kstruct{file\_operation}.  Ovviamente non è detto che tutte le operazioni
-possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek}
-non è realizzabile per un dispositivo come la porta seriale o per una fifo,
-mentre sui file del filesystem \texttt{vfat} non sono disponibili i permessi,
-ma resta il fatto che grazie al VFS le \textit{system call} per le operazioni
-sui file restano sempre le stesse nonostante le enormi differenze che possono
-esserci negli oggetti a cui si applicano.
+possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
+sarà presente per un dispositivo come la porta seriale o per una fifo, mentre
+sui file del filesystem \texttt{vfat} non saranno disponibili i permessi, ma
+resta il fatto che grazie al VFS le \textit{system call} per le operazioni sui
+file possono restare sempre le stesse nonostante le enormi differenze che
+possono esserci negli oggetti a cui si applicano.
  
 
 \itindend{Virtual~File~System}
@@ -355,6 +355,8 @@ esserci negli oggetti a cui si applicano.
 %       * http://thecoffeedesk.com/geocities/rkfs.html
 %       * http://www.linux.it/~rubini/docs/vfs/vfs.html
 
+
+
 \subsection{Il funzionamento di un filesystem Unix}
 \label{sec:file_filesystem}
 
@@ -372,11 +374,11 @@ fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
 partizioni. In essa per semplicità si è fatto riferimento alla struttura del
 filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
   group}.  All'interno di ciascun \textit{block group} viene anzitutto
-replicato il cosiddetto \textit{superblock}, (la struttura che contiene
-l'indice iniziale del filesystem e che consente di accedere a tutti i dati
-sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
-per accedere agli stessi.  Sulle caratteristiche di \acr{ext2} e derivati
-torneremo in sez.~\ref{sec:file_ext2}.
+replicato il cosiddetto \itindex{superblock} \textit{superblock}, (la
+struttura che contiene l'indice iniziale del filesystem e che consente di
+accedere a tutti i dati sottostanti) e creata una opportuna suddivisione dei
+dati e delle informazioni per accedere agli stessi.  Sulle caratteristiche di
+\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}.
 
 \itindbeg{inode}
 
@@ -399,9 +401,10 @@ per i dati in essi contenuti.
 Se si va ad esaminare con maggiore dettaglio la strutturazione
 dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
 dettagli relativi al funzionamento del filesystem stesso come la
-strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
-gestione possiamo esemplificare la situazione con uno schema come quello
-esposto in fig.~\ref{fig:file_filesys_detail}.
+strutturazione in gruppi dei blocchi, il \itindex{superblock}
+\textit{superblock} e tutti i dati di gestione possiamo esemplificare la
+situazione con uno schema come quello esposto in
+fig.~\ref{fig:file_filesys_detail}.
 
 \begin{figure}[!htb]
   \centering
@@ -461,17 +464,17 @@ opportuno tenere sempre presente che:
   è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
   funzione \func{rename} (vedi sez.~\ref{sec:file_remove}). Questa operazione
   non modifica minimamente neanche l'\textit{inode} del file, dato che non si
-  opera su questo ma sulla directory che lo contiene.
+  opera sul file ma sulla directory che lo contiene.
 
-\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
+\item Gli \textit{inode} dei file, che contengono i \textsl{metadati}, ed i
   blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
   in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
   possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio
   per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore
   spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
   creare nuovi file, ma si potranno estendere quelli che ci
-  sono.\footnote{questo comportamento non è generale, alcuni filesystem evoluti
-    possono evitare il problema dell'esaurimento degli \textit{inode}
+  sono.\footnote{questo comportamento non è generale, alcuni filesystem
+    evoluti possono evitare il problema dell'esaurimento degli \textit{inode}
     riallocando lo spazio disco libero per i blocchi.}
 
 \end{enumerate}
@@ -506,19 +509,18 @@ tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di
 \label{sec:file_ext2}
 
 
-Benché non esista il filesystem di Linux, dato che esiste un supporto nativo
-di diversi filesystem che sono in uso da anni, quello che gli avvicina di più
-è la famiglia di filesystem evolutasi a partire dal \textit{second extended
-  filesystem}, o \acr{ext2}, che nonostante il nome è stato il primo ad essere
-usato in maniera estensiva. Il filesystem \acr{ext2} ha subito un grande
-sviluppo e diverse evoluzioni, fra cui l'aggiunta del \textit{journaling} con
-\acr{ext3}, probabilmente ancora il filesystem più diffuso, ed una serie di
-ulteriori miglioramento con il successivo \acr{ext4}, che sta iniziando a
-sostituirlo gradualmente. In futuro è previsto che questo debba essere
-sostituito da un filesystem completamente diverso, \acr{btrfs}, che dovrebbe
-diventare il filesystem standard di Linux, ma questo al momento è ancora in
-fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione
-  di di questo paragrafo, l'inizio del 2012.}
+Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto
+nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina
+di più è la famiglia di filesystem evolutasi a partire dal \textit{second
+  extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un
+grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
+\textit{journaling} con \acr{ext3}, probabilmente ancora il filesystem più
+diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4},
+che sta iniziando a sostituirlo gradualmente. In futuro è previsto che questo
+debba essere sostituito da un filesystem completamente diverso, \acr{btrfs},
+che dovrebbe diventare il filesystem standard di Linux, ma questo al momento è
+ancora in fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima
+  revisione di di questo paragrafo, l'inizio del 2012.}
 
 Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
 dalle prime versioni del kernel e supporta tutte le caratteristiche di un
@@ -543,7 +545,7 @@ le seguenti:
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
   di \acr{sgid} impostato (per una descrizione dettagliata del significato di
   questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
-  file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
+  file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   in fase di creazione, a seconda delle sue esigenze: blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco.
@@ -565,11 +567,12 @@ riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
 in gruppi di blocchi.
 
 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
-affidabilità e possibilità di recupero in caso di corruzione del
-\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
-inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
-distanza fra i dati e la tabella degli \itindex{inode} inode.
+filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati)
+per una maggiore affidabilità e possibilità di recupero in caso di corruzione
+del \itindex{superblock} \textit{superblock} principale. L'utilizzo di
+raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni
+dato che viene ridotta la distanza fra i dati e la tabella degli
+\itindex{inode} inode.
 
 \begin{figure}[!htb]
   \centering
@@ -610,15 +613,15 @@ contenenti un gran numero di file.
 % in caso di crash del sistema)
 
 
-\subsection{La gestione dei filesystem}
+\subsection{La gestione dell'uso dei filesystem}
 \label{sec:sys_file_config}
 
 Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
 occorre prima rendere disponibile al sistema il filesystem su cui essi sono
 memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount}
-il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e
-  non è portabile.}
+\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount},
+il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che
+  usa la omonima \textit{system call} e non è portabile.}
 
 \begin{funcproto}{ 
 \fhead{sys/mount.h} 
@@ -641,12 +644,17 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e
     o non può essere montato su \param{target} perché la directory è ancora in
     uso.
   \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
-    \textit{superblock} non valido, o si è cercato di rimontare un filesystem
-    non ancora montato, o di montarlo senza che \param{target} sia un
-    \itindex{mount~point} \textit{mount point} o di spostarlo
-    quando \param{target} non è un \itindex{mount~point} \textit{mount point}
-    o è la radice.
-  \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+    \itindex{superblock} \textit{superblock} non valido, o si è cercato di
+    rimontare un filesystem non ancora montato, o di montarlo senza
+    che \param{target} sia un \itindex{mount~point} \textit{mount point} o di
+    spostarlo quando \param{target} non è un \itindex{mount~point}
+    \textit{mount point} o è la radice.
+  \item[\errcode{ELOOP}] si è cercato di spostare un \itindex{mount~point}
+    \textit{mount point} su una sottodirectory di \param{source} o si sono
+    incontrati troppi link simolici nella risoluzione di un nome.
+  \item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
+    dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
+    è piena.
   \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è
     configurato nel kernel.
   \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
@@ -655,122 +663,407 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e
     dispositivo \param{source} è sbagliato.
   \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
   \end{errlist} 
-  ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM},
-  \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro
-  significato generico.}
+  ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG},
+  \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
 \end{funcproto}
 
-La funzione monta sulla directory indicata \param{target}, detta
+La funzione monta sulla directory indicata da \param{target}, detta
 \itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
-di dispositivo indicato \param{source}. In entrambi i casi, come daremo per
+di dispositivo indicato da \param{source}. In entrambi i casi, come daremo per
 assunto da qui in avanti tutte le volte che si parla di directory o file nel
 passaggio di un argomento di una funzione, si intende che questi devono essere
 indicati con la stringa contenente il loro \itindex{pathname}
 \textit{pathname}.
 
-In generale un filesystem è contenuto su un disco, e come illustrato in
-sez.~\ref{sec:file_vfs_work} l'operazione di montaggio corrisponde a rendere
-visibile il contenuto del suddetto disco, identificato attraverso il file di
-dispositivo ad esso associato, all'interno di una directory dell'albero dei
-file. 
-
-Ma la struttura del \textit{Virtual File System} vista in
-sez.~\ref{sec:file_vfs_work} è estremamente flessibile e può essere usata
-anche per oggetti diversi da un disco. Ad esempio usando il \textit{loop
-  device} si può montare un file qualunque (come l'immagine di un CD-ROM o di
-un floppy) che contiene un filesystem, inoltre alcuni filesystem, come
-\file{proc} o \file{devfs} sono del tutto virtuali, i loro dati sono generati
-al volo ad ogni lettura, e passati al kernel ad ogni scrittura.
-
-Il tipo di filesystem è specificato dall'argomento \param{filesystemtype}, che
-deve essere una delle stringhe riportate nel file
-\procfile{/proc/filesystems}, che come accennato in
-sez.~\ref{sec:file_vfs_work} contiene l'elenco dei filesystem supportati dal
-kernel. Nel caso si sia indicato uno dei filesystem virtuali, che non è
-associato a nessun file di dispositivo, il contenuto di \param{source} viene
-ignorato.
+Normalmente un filesystem è contenuto su un disco o una partizione, ma come
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
+\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente
+flessibile e può essere usata anche per oggetti diversi da un disco. Ad
+esempio usando il \textit{loop device} si può montare un file qualunque (come
+l'immagine di un CD-ROM o di un floppy) che contiene l'immagine di un
+filesystem, inoltre alcuni tipi di filesystem, come \texttt{proc} o
+\texttt{sysfs} sono virtuali e non hanno un supporto che ne contenga i dati,
+che invece sono generati al volo ad ogni lettura, e passati indietro al kernel
+ad ogni scrittura.\footnote{costituiscono quindi un meccanismo di
+  comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel.}
+
+Il tipo di filesystem che si vuole montare è specificato
+dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
+riportate nel file \procfile{/proc/filesystems} che, come accennato in
+sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
+kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
+nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
 
 L'argomento \param{data} viene usato per passare le impostazioni relative alle
 caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di
-parole chiave (separate da virgole e senza spazi) che indicano le opzioni del
-filesytem che devono essere impostate, in sostanza viene usato il contenuto
-del parametro dell'opzione \texttt{-o} del comando \texttt{mount}. I valori
-utilizzabili dipendono dal tipo di filesystem e ciascuno ha i suoi, pertanto
-si rimanda alla documentazione della pagina di manuale di questo comando. 
+parole chiave (separate da virgole e senza spazi) che indicano le cosiddette
+``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere
+viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o}
+del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
+filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
+pagina di manuale di questo comando e dei singoli filesystem.
 
 Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
 disponibile nella directory specificata come \itindex{mount~point}
 \textit{mount point}, il precedente contenuto di detta directory viene
-mascherato dal contenuto della directory radice del filesystem montato.
-
-Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
-\itindex{mount~point} \textit{mount point} da una directory ad un'altra, sia
-montare in diversi \itindex{mount~point} \textit{mount point} lo stesso
-filesystem, sia montare più filesystem sullo stesso \itindex{mount~point}
-\textit{mount point}, nel qual caso vale quanto appena detto, e solo il
+mascherato dal contenuto della directory radice del filesystem montato. Fino
+ai kernel della serie 2.2.x non era possibile montare un filesytem se un
+\textit{mount point} era già in uso. 
+
+A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
+atomicamente un \itindex{mount~point} \textit{mount point} da una directory ad
+un'altra, sia montare lo stesso filesystem in diversi \itindex{mount~point}
+\textit{mount point}, sia montare più filesystem sullo stesso
+\itindex{mount~point} \textit{mount point} impilandoli l'uno sull'altro, nel
+qual caso vale comunque quanto detto in precedenza, e cioè che solo il
 contenuto dell'ultimo filesystem montato sarà visibile.
 
-Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
-attivate o meno, alcune di queste sono generali (anche se non è detto siano
-disponibili in ogni filesystem), e vengono specificate come opzioni di
-montaggio con l'argomento \param{mountflags}.  
+Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
+forma della lista di parole chiave indicata con l'argomento \param{data},
+esistono pure alcune opzioni che si possono applicare in generale, anche se
+non è detto che tutti i filesystem le supportino, che si specificano tramite
+l'argomento \param{mountflags}.  L'argomento inoltre può essere utilizzato per
+modificare il comportamento della funzione, facendole compiere una operazione
+diversa (ad esempio un rimontaggio, invece che un montaggio).
+
+In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
+della serie 2.2.x i 16 più significativi avevano un valore riservato che
+doveva essere specificato obbligatoriamente,\footnote{il valore era il
+  \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
+  costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
+  riservata al \textit{magic number}, mentre per specificarlo si può dare un
+  OR aritmetico con la costante \const{MS\_MGC\_VAL}.} e si potevano usare
+solo i 16 meno significativi. Oggi invece, con un numero di opzioni superiore,
+sono utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia
+presente detto valore, che non esprime una combinazione valida, esso viene
+ignorato. Il valore dell'argomento deve essere espresso come maschera binaria
+e i vari bit devono essere impostati con un OR aritmetico dei rispettivi flag,
+identificati dalle costanti riportate nell'elenco seguente:
+
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\itindbeg{bind~mount}
+\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
+  possibile montare una directory di un filesystem in un'altra directory,
+  l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
+  verranno presi in considerazione solo gli argomenti \param{source}, che
+  stavolta indicherà la directory che si vuole montare (e non un file di
+  dispositivo) e \param{target} che indicherà la directory su cui verrà
+  effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype}
+  e \param{data} vengono ignorati.
+
+  In sostanza quello che avviene è che in corrispondenza del \index{pathname}
+  \textit{pathname} indicato da \param{target} viene montato l'\textit{inode}
+  di \param{source}, così che la porzione di albero dei file presente sotto
+  \param{source} diventi visibile allo stesso modo sotto
+  \param{target}. Trattandosi esattamente dei dati dello stesso filesystem,
+  ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile
+  nell'altro, visto che entrambi faranno riferimento agli stessi
+  \textit{inode}.
+
+  Dal punto di vista del \itindex{Virtual~File~System} VFS l'operazione è
+  analoga al montaggio di un filesystem proprio nel fatto che anche in questo
+  caso si inserisce in corripondenza della \textit{dentry} di \texttt{target}
+  un diverso \textit{inode}, che stavolta, invece di essere quello della
+  radice del filesystem indicato da un file di dispositivo, è quello di una
+  directory già montata.
+
+  Si tenga presente che proprio per questo sotto \param{target} comparirà il
+  contenuto che è presente sotto \param{source} all'interno del filesystem in
+  cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
+  porzione di albero che sta sotto \param{source} qualora in una
+  sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
+  tal caso infatti nella porzione di albero sotto \param{source} si troverebbe
+  il contenuto del nuovo filesystem (o di un altro \textit{bind mount}) mentre
+  sotto \param{target} ci sarebbe il contenuto presente nel filesystem
+  originale.\footnote{questo evita anche il problema dei \textit{loop} di
+    fig.~\ref{fig:file_link_loop}, dato che se anche si montasse su
+    \param{target} una directory in cui essa è contenuta, il cerchio non
+    potrebbe chiudersi perché ritornati a \param{target} dentro il
+    \textit{bind mount} vi si troverebbe solo il contenuto originale e non si
+    potrebbe tornare indietro.}
+
+  Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
+  \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
+  originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
+  \textit{read-only bind mount} e viene onorata la presenza del flag
+  \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file sotto
+  \param{target} sia effettuabile esclusivamente in sola lettura.
+
+  Il supporto per il \textit{bind mount} consente di superare i limiti
+  presenti per gli \textit{hard link} (di cui parleremo in
+  sez.~\ref{sec:file_link}) ottenendo un qualcosa di analogo in cui si può
+  fare riferimento alla porzione dell'albero dei file di un filesystem
+  presente a partire da una certa directory utilizzando una qualunque altra
+  directory, anche se questa sta su un filesystem diverso. Si può così fornire
+  una alternativa all'uso dei link simbolici (di cui parleremo in
+  sez.~\ref{sec:file_symlink}) che funziona correttamente anche all'intero di
+  un \textit{chroot} (argomento su cui torneremo in
+  sez.~\ref{sec:file_chroot}.  
+\itindend{bind~mount}
+
+\item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
+  directory venga immediatamente registrata su disco in maniera sincrona
+  (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
+  tutte le directory del filesystem, ma su alcuni filesystem è possibile
+  impostarla a livello di singole directory o per i sottorami di una directory
+  con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune
+    \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
+
+  Questo consente di ridurre al minimo il rischio di perdita dei dati delle
+  directory in caso di crollo improvviso del sistema, al costo di una certa
+  perdita di prestazioni dato che le funzioni di scrittura relative ad
+  operazioni sulle directory non saranno più bufferizzate e si bloccheranno
+  fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
+
+\item[\const{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
+  \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}) sui file
+  del filesystem. Per poterlo utilizzare effettivamente però esso dovrà essere
+  comunque attivato esplicitamente per i singoli file impostando i permessi
+  come illustrato in sez.~\ref{sec:file_mand_locking}.
+
+\item[\const{MS\_MOVE}] Effettua uno del spostamento del \itindex{mount~point}
+  \textit{mount point} di un filesystem. La directory del
+  \itindex{mount~point} \textit{mount point} originale deve essere indicata
+  nell'argomento \param{source}, e la sua nuova posizione
+  nell'argomento \param{target}. Tutti gli altri argomenti della funzione
+  vengono ignorati.
+
+  Lo spostamento avviene atomicamente, ed il ramo di albero presente
+  sotto \param{source} sarà immediatamante visibile sotto \param{target}. Non
+  esiste cioè nessun momento in cui il filesystem non risulti montato in una o
+  nell'altra directory e pertanto è garantito che la risoluzione di
+  \textit{pathname} relativi all'interno del filesystem non possa fallire.
+
+\item[\const{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
+  degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
+  qualunque tipo di file. Dato che l'aggiornamento degli \textit{access time}
+  è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+  elevato visto che una qualunque lettura comporta comunque una scrittura su
+  disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
+    della batteria sui portatili.} questa opzione consente di disabilitarla
+  completamente. La soluzione può risultare troppo drastica dato che
+  l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
+  sviluppo del kernel sono state introdotte altre opzioni che forniscono
+  soluzioni più appropriate e meno radicali.
+
+\item[\const{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
+  di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
+  misura di precauzione per rendere inutile la presenza di eventuali file di
+  dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
+    che le convenzioni del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
+    \textit{Linux Filesystem Hierarchy Standard} richiedono che questi siano
+    mantenuti esclusivamente sotto \texttt{/dev}.}
+
+  Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
+  fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
+  il controllo dei contenuti, in particolar modo quelli posti su dispositivi
+  rimuovibili. In questo modo si evitano alla radice possibili situazioni in
+  cui un utente malizioso inserisce su uno di questi filesystem dei file di
+  dispositivo con permessi ``opportunamente'' ampliati che gli consentano di
+  accedere anche a risorse cui non dovrebbe.
+
+\item[\const{MS\_NODIRATIME}] Viene disabilitato sul filesystem
+  l'aggiornamento degli \textit{access time} (vedi
+  sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
+  una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
+  directory, che in pratica che non viene mai utilizzata, mantenendola per i
+  file in cui invece ha un impiego, sia pur limitato.
+
+\item[\const{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
+  qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
+  usata come misura di precauzione per rendere impossibile l'uso di programmi
+  posti su filesystem che non dovrebbero contenerne.
+
+  Anche in questo caso viene utilizzata per fornire un accesso più controllato
+  a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da
+  questo punto di vista l'opzione è meno importante delle analoghe
+  \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un
+  programma creato dall'utente pone un livello di rischio nettamente
+  inferiore, ed è in genere consentita per i file contenuti nella sua home
+  directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa
+    opzione, il cui uso ha senso solo per ambienti molto controllati in cui si
+    vuole che gli utenti eseguano solo i programmi forniti
+    dall'amministratore.}
+
+\item[\const{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
+  dei permessi \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid}
+  (vedi sez.~\ref{sec:file_special_perm}) eventualmente presenti sui file in
+  esso contenuti. L'opzione viene usata come misura di precauzione per rendere
+  inefficace l'effetto di questi bit per filesystem in cui non ci dovrebbero
+  essere file dotati di questi permessi.
+
+  Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
+  \const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
+  di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
+  che un utente malizioso possa inserire su uno di questi filesystem un
+  eseguibile con il bit \itindex{suid~bit} \acr{suid} attivo e di proprietà
+  dell'amministratore o di un altro utente, che gli consentirebbe di eseguirlo
+  per conto di quest'ultimo.
+
+\item[\const{MS\_PRIVATE}] Marca un \itindex{mount~point} \textit{mount point}
+  come privato. Si tratta di una delle nuove opzioni (insieme a
+  \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+  parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+    subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+  funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+  \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+  marcare, e tutti gli altri argomenti verranno ignorati.
+
+  Di default, finché non lo si marca altrimenti con una delle altre opzioni
+  dell'interfaccia \itindex{shared~subtree} \textit{shared subtree}, ogni
+  \textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un
+  \itindex{mount~point} \textit{mount point} di tipo \textit{private} si
+  comporta come descritto nella trattazione di \const{MS\_BIND}. Si usa questo
+  flag principalmente per revocare gli effetti delle altre opzioni e riportare
+  il comportamento a quello ordinario.
+
+\item[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
+  non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
+  volte che si deve accedere ai contenuti di un filesystem con la certezza che
+  questo non venga modificato (ad esempio per ispezionare un filesystem
+  corrotto). All'avvio di default il kernel monta la radice in questa
+  modalità.
+
+\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \itindex{mount~point}
+  \textit{mount point} presenti al di sotto del \textit{mount point} indicato
+  gli effetti della opzione degli \itindex{shared~subtree} \textit{shared
+    subtree} associata. Anche questo caso l'argomento \param{target} deve fare
+  riferimento ad un \itindex{mount~point} \textit{mount point} e tutti gli
+  altri argomenti sono ignorati, ed il flag deve essere indicato assieme ad
+  una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+  \const{MS\_UNBINDABLE}.
+
+\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
+  \textit{access time} sul filesystem soltanto quando questo risulti
+  antecendente il valore corrente del \textit{modification time} o del
+  \textit{change time} (per i tempi dei file si veda
+  sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
+  kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
+  default del sistema, che può essere riportato a quello tradizionale con
+  l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato
+  anche modificato e l'\textit{access time} viene comunque aggiornato se è più
+  vecchio di un giorno.
+
+  L'opzione consente di evitare i problemi di prestazioni relativi
+  all'aggiornamento dell'\textit{access time} senza avere impatti negativi
+  riguardo le funzionalità, il comportamento adottato infatti consente di
+  rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al
+  contempo ulteriori operazioni su disco negli accessi successivi. In questo
+  modo l'informazione relativa al fatto che un file sia stato letto resta
+  disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con
+  l'introduzione di questo comportamento l'uso delle alternative
+  \const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
+
+\item[\const{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
+  cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
+  possono modificare le opzioni del filesystem anche se questo è in uso. Gli
+  argomenti \param{source} e \param{target} devono essere gli stessi usati per
+  il montaggio originale, mentre \param{data} che \param{mountflags}
+  conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
+
+  Qualunque opzione specifica del filesystem indicata con \param{data} può
+  essere modificata, mentre con \param{mountflags} possono essere modificate
+  solo alcune opzioni generiche. Con i kernel più recenti queste sono soltanto
+  \const{MS\_MANDLOCK}, \const{MS\_RDONLY} e \const{MS\_SYNCHRONOUS}, prima
+  del kernel 2.6.16 potevano essere modificate anche le ulteriori
+  \const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
+  2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
+
+\item[\const{MS\_SHARED}] Marca un \itindex{mount~point} \textit{mount point}
+  come \textit{shared mount}.  Si tratta di una delle nuove opzioni (insieme a
+  \const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+  parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+    subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+  funzionalità dei \itindex{bind~mount} \textit{bind mount}.  In questo caso
+  \param{target} dovrà fare riferimento al \itindex{mount~point} \textit{mount
+    point} che si intende marcare, e tutti gli altri argomenti verranno
+  ignorati.
+
+  Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+  effettuati da un \textit{mount point} marcato da essa siano di tipo
+  \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
+  ogni ulteriore operazione di montaggio o smontaggio che avviene su una
+  directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
+  smontaggio cioè vengono ``\textsl{propagate}'' a tutti i \textit{mount
+    point} della stessa condivisione, e la sezione di albero di file vista al
+  di sotto di ciascuno di essi sarà sempre identica.
+
+\item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
+  avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
+  è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
+  non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
+  2.6.12, che aveva lo stesso effetto.
+
+\item[\const{MS\_SLAVE}] Marca un \itindex{mount~point} \textit{mount point}
+  come \textit{slave mount}. Si tratta di una delle nuove opzioni (insieme a
+  \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
+  parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+    subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+  funzionalità dei \itindex{bind~mount} \textit{bind mount}.  In questo caso
+  \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+  marcare, e tutti gli altri argomenti verranno ignorati.
+
+  Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+  effettuati da un \textit{mount point} marcato da essa siano di tipo
+  \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
+  montaggio o smontaggio che avviene su una directory al di sotto del
+  \textit{mount point} originale.  Le operazioni di montaggio e smontaggio in
+  questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
+  originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
+  essi potranno eseguire al loro interno ulteriori montaggi che non saranno
+  propagati né negli altri né nel \itindex{mount~point} \textit{mount point}
+  originale.
+
+\item[\const{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
+  cui l'\textit{access time} viene aggiornato ad ogni accesso al
+  file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
+  comportamento di default del kernel è diventato quello fornito da
+  \const{MS\_RELATIME}.
+
+\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
+  ogni modifica al contenuto del filesystem venga immediatamente registrata su
+  disco. Lo stesso comportamento può essere ottenuto con il flag
+  \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open}).
+
+  Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
+  in caso di crollo improvviso del sistema, al costo di una pesante perdita di
+  prestazioni dato che tutte le funzioni di scrittura non saranno più
+  bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un
+  compromesso in cui questo comportamento avviene solo per le directory, ed ha
+  quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
+
+\item[\const{MS\_UNBINDABLE}] Marca un \itindex{mount~point} \textit{mount
+    point} come \textit{unbindable mount}. Si tratta di una delle nuove
+  opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e
+  \const{MS\_SLAVE}) facenti parte dell'infrastruttura degli
+  \itindex{shared~subtree} \textit{shared subtree} introdotta a partire dal
+  kernel 2.6.15, che estendono le funzionalità dei \itindex{bind~mount}
+  \textit{bind mount}.  In questo caso
+  \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+  marcare, e tutti gli altri argomenti verranno ignorati.
+
+  Un \textit{mount point} marcato in questo modo disabilità la capacità di
+  eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
+  allo stesso modo di un \itindex{mount~point} \textit{mount point} ordinario
+  di tipo \textit{private} con in più la restrizione che nessuna sua
+  sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+  utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind
+    mount}.
 
-In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \itindex{magic~number} \textit{magic
-  number}\footnote{che nel caso è \code{0xC0ED}, si può usare la costante
-  \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
-  al \textit{magic number}.} mentre i 16 meno significativi sono usati per
-specificare le opzioni; essi sono usati come maschera binaria e vanno
-impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i
-valori riportati in tab.~\ref{tab:sys_mount_flags}.
+\end{basedescript}
 
-\begin{table}[htb]
-  \footnotesize
-  \centering
-  \begin{tabular}[c]{|l|r|p{8cm}|}
-    \hline
-    \textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\
-    \hline
-    \hline
-    \const{MS\_RDONLY}     &  1 & Monta in sola lettura.\\
-    \const{MS\_NOSUID}     &  2 & Ignora i bit \itindex{suid~bit} \acr{suid} e
-                                  \itindex{sgid~bit} \acr{sgid}.\\ 
-    \const{MS\_NODEV}      &  4 & Impedisce l'accesso ai file di dispositivo.\\
-    \const{MS\_NOEXEC}     &  8 & Impedisce di eseguire programmi.\\
-    \const{MS\_SYNCHRONOUS}& 16 & Abilita la scrittura sincrona.\\
-    \const{MS\_REMOUNT}    & 32 & Rimonta il filesystem cambiando le opzioni.\\
-    \const{MS\_MANDLOCK}   & 64 & Consente il \textit{mandatory locking} 
-                                  \itindex{mandatory~locking} (vedi
-                                  sez.~\ref{sec:file_mand_locking}).\\
-    \const{S\_WRITE}      & 128 & Scrive normalmente.\\
-    \const{S\_APPEND}     & 256 & Consente la scrittura solo in
-                                  \itindex{append~mode} \textit{append mode} 
-                                  (vedi sez.~\ref{sec:file_sharing}).\\
-    \const{S\_IMMUTABLE}  & 512 & Impedisce che si possano modificare i file.\\
-    \const{MS\_NOATIME}   &1024 & Non aggiorna gli \textit{access time} (vedi
-                                  sez.~\ref{sec:file_file_times}).\\
-    \const{MS\_NODIRATIME}&2048 & Non aggiorna gli \textit{access time} delle
-                                  directory.\\
-    \const{MS\_BIND}      &4096 & Monta il filesystem altrove.\\
-    \const{MS\_MOVE}      &8192 & Sposta atomicamente il punto di montaggio.\\
-    \hline
-  \end{tabular}
-  \caption{Tabella dei codici dei flag di montaggio di un filesystem.}
-  \label{tab:sys_mount_flags}
-\end{table}
+% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
+% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
+%  * http://lwn.net/Articles/159077/ e
+%  * Documentation/filesystems/sharedsubtree.txt
 
-% TODO aggiornare con i nuovi flag di man mount
-% gli S_* non esistono più come segnalato da Alessio...
-% verificare i readonly mount bind del 2.6.26
+% TODO: (bassa priorità) non documentati ma presenti in sys/mount.h:
+%       * MS_POSIXACL
+%       * MS_KERNMOUNT
+%       * MS_I_VERSION
+%       * MS_ACTIVE
+%       * MS_NOUSER
 
-La funzione \func{mount} può essere utilizzata anche per effettuare il
-\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
-alcune delle caratteristiche di funzionamento (ad esempio passare da sola
-lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
-bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che
-deve essere effettuato il rimontaggio del filesystem (con le opzioni
-specificate dagli altri bit), anche in questo caso il valore di \param{source}
-viene ignorato.
 
 Una volta che non si voglia più utilizzare un certo filesystem è possibile
 \textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
@@ -780,54 +1073,79 @@ Una volta che non si voglia più utilizzare un certo filesystem è possibile
 \fdecl{umount(const char *target)}
 \fdesc{Smonta un filesystem.} 
 }
-{La funzione ritorna  $0$ in caso 
-  di successo e $-1$  per un errore,
+{La funzione ritorna  $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
+  \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
+    directory di lavoro di qualche processo, o contiene dei file aperti, o un
+    altro mount point.
+  \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point}.
   \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
-  \item[\errcode{EBUSY}]  \param{target} è la directory di lavoro di qualche
-  processo, o contiene dei file aperti, o un altro mount point.
-\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
-\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
-  significato generico.}
+  \end{errlist}
+  ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
+  \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico.  }
 \end{funcproto}
 
 La funzione prende il nome della directory su cui il filesystem è montato e
 non il file o il dispositivo che è stato montato,\footnote{questo è vero a
   partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
   funzione poteva essere usata anche specificando il file di dispositivo.} in
-quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
-punti. Nel caso più di un filesystem sia stato montato sullo stesso
-\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
-montato per ultimo.
-
-Si tenga presente che la funzione fallisce quando il filesystem è
-\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
-filesystem, se questo contiene la directory di lavoro corrente di un qualunque
-processo o il \itindex{mount~point} \textit{mount point} di un altro
-filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
-
-Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
-casi permette di forzare lo smontaggio di un filesystem, anche quando questo
-risulti occupato; il suo prototipo è:
+quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
+che è stato montato per ultimo. Si tenga presente che la funzione fallisce se
+il filesystem è \textsl{occupato}, cioè quando se ci sono ancora dei file
+aperti sul filesystem, se questo contiene la \index{directory~di~lavoro}
+directory di lavoro corrente di un qualunque processo o il
+\itindex{mount~point} \textit{mount point} di un altro filesystem.
+
+Linux provvede inoltre una seconda funzione, \funcd{umount2}, che consente un
+maggior controllo delle operazioni, come forzare lo smontaggio di un
+filesystem anche quando questo risulti occupato; il suo prototipo è:
+
 \begin{funcproto}{ 
 \fhead{sys/mount.h}
 \fdecl{umount2(const char *target, int flags)}
 \fdesc{Smonta un filesystem.} 
 }
-{La funzione è identica a \func{umount} per valori di ritorno e codici di
-  errore. }
+{La funzione ritorna  $0$ in caso di successo e $-1$ per un errore,
+  nel qual caso \var{errno} assumerà uno dei valori: 
+  \begin{errlist}
+     \item[\errcode{EAGAIN}] 
+     \item[\errcode{EINVAL}]
+  \end{errlist}
+  e gli altri valori visti per \func{umount} con lo stesso signigicato.
+}
 \end{funcproto}
 
-Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
-definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
+Il valore di \param{flags} è una maschera binaria, che deve essere specificato
+con un OR aritmetico dei valori illustrate in tab.~\ref{tab:umount2_flags}.
 Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
 anche se è occupato per via di una delle condizioni descritte in precedenza. A
 seconda del tipo di filesystem alcune (o tutte) possono essere superate,
 evitando l'errore di \errcode{EBUSY}.  In tutti i casi prima dello smontaggio
-viene eseguita una sincronizzazione dei dati. 
+viene eseguita una sincronizzazione dei dati.
+
+\begin{table}[!htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|p{8cm}|}
+    \hline
+    \textbf{Costante} & \textbf{Descrizione}\\
+    \hline
+    \hline
+    \const{MNT\_FORCE}  & (dal kernel 2.2).\\
+    \const{MNT\_DETACH} & (dal kernel 2.4.11 e dalla \acr{glibc} 2.11).\\
+    \const{MNT\_EXPIRE} & (dal kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
+    \const{UMOUNT\_NOFOLLOW}& (dal kernel 2.6.34).\\
+    \hline
+  \end{tabular}
+  \caption{Costanti che identificano i bit dell'argomento \param{flags}
+    della funzione \func{umount2}.} 
+  \label{tab:umount2_flags}
+\end{table}
+
 
-% TODO documentare MNT_DETACH e MNT_EXPIRE ...
 
 Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
   ma con una struttura diversa.} utili per ottenere in maniera diretta
@@ -843,14 +1161,14 @@ informazioni riguardo al filesystem su cui si trova un certo file, sono
 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
-  \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non
+  \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato
+    non supporta la funzione.
   \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe,
   \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
   \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro
   significato generico.}
 \end{funcproto}
 
-
 Queste funzioni permettono di ottenere una serie di informazioni generali
 riguardo al filesystem su cui si trova il file specificato; queste vengono
 restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita
@@ -870,7 +1188,6 @@ genere è il nome del filesystem stesso.
   \label{fig:sys_statfs}
 \end{figure}
 
-
 Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
 file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono
 usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le
@@ -891,8 +1208,6 @@ tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
 
 
 
-
-
 \section{La gestione di file e directory}
 \label{sec:file_dir}
 
@@ -940,12 +1255,14 @@ Per aggiungere ad una directory una voce che faccia riferimento ad un
 \itindex{inode} \textit{inode} già esistente si utilizza la funzione
 \func{link}; si suole chiamare questo tipo di associazione un collegamento
 diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
-\begin{prototype}{unistd.h}
-{int link(const char *oldpath, const char *newpath)}
-  Crea un nuovo collegamento diretto.
-  
-  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
-    errore nel qual caso \var{errno} viene impostata ai valori:
+
+\begin{funcproto}{ 
+\fhead{unistd.h}
+\fdecl{int link(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+  nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
   \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
     riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
@@ -957,11 +1274,12 @@ diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
   \item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
     numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
     sez.~\ref{sec:sys_limits}).
-  \end{errlist}
-  ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOTDIR},
-  \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
-  \errval{ENOSPC}, \errval{EIO}.}
-\end{prototype}
+  \end{errlist} ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG},
+  \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS},
+  \errval{ELOOP}, \errval{ENOSPC}, \errval{EIO} nel loro significato
+  generico.}
+\end{funcproto}
+
 
 La funzione crea sul \itindex{pathname} \textit{pathname} \param{newpath} un
 collegamento diretto al file indicato da \param{oldpath}.  Per quanto detto la
@@ -994,10 +1312,12 @@ complicata (in genere per questo tipo di errori occorre far girare il
 programma \cmd{fsck} per riparare il filesystem).
 
 Data la pericolosità di questa operazione e la disponibilità dei link
-simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nel caso di Linux questa capacità è stata completamente disabilitata, e al
-tentativo di creare un link diretto ad una directory la funzione \func{link}
-restituisce l'errore \errcode{EPERM}.
+simbolici (che vedremo in sez.~\ref{sec:file_symlink}) e dei
+\itindex{bind~mount} \textit{bind mount} (già visti in
+sez.~\ref{sec:sys_file_config}) che possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un link diretto ad una directory la
+funzione \func{link} restituisce l'errore \errcode{EPERM}.
 
 Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
 \textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
@@ -1009,10 +1329,9 @@ iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
   kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
   durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
   attuale fino ad oggi (per riferimento si veda
-  \href{http://lwn.net/Articles/293902}
-  {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
-comportamento che non segue più lo standard per cui l'\textit{hard link} viene
-creato rispetto al link simbolico, e non al file cui questo punta.
+  \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
+che non segue più lo standard per cui l'\textit{hard link} viene creato
+rispetto al link simbolico, e non al file cui questo punta.
 
 La ragione di questa differenza rispetto allo standard, presente anche in
 altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
@@ -1034,24 +1353,24 @@ farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
 La rimozione di un file (o più precisamente della voce che lo referenzia
 all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
 suo prototipo è il seguente:
-\begin{prototype}{unistd.h}{int unlink(const char *pathname)}
 
-  Cancella un file.
-  
-  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso il file non viene toccato. La variabile
-    \var{errno} viene impostata secondo i seguenti codici di errore:
+\begin{funcproto}{ 
+\fhead{unistd.h}
+\fdecl{int unlink(const char *pathname)}
+\fdesc{Cancella un file.} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+  nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
-  \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory.
-    \footnotemark
+  \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
+    directory.\footnotemark 
   \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
   lettura.
   \item[\errcode{EISDIR}] \param{pathname} fa riferimento a una directory.
-  \end{errlist}
-  ed inoltre: \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
+  \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
   \errval{ENOTDIR}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
-  \errval{EIO}.}
-\end{prototype}
+  \errval{EIO} nel loro significato generico.}
+\end{funcproto}
 
 \footnotetext{questo è un valore specifico ritornato da Linux che non consente
   l'uso di \func{unlink} con le directory (vedi sez.~\ref{sec:file_remove}).
@@ -1117,16 +1436,17 @@ Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
 una directory (e funziona anche per i sistemi che non supportano i link
 diretti). Per i file è identica a \func{unlink} e per le directory è identica
 a \func{rmdir}; il suo prototipo è:
-\begin{prototype}{stdio.h}{int remove(const char *pathname)}
-  Cancella un nome dal filesystem. 
-  
-  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso il file non viene toccato.
-    
-    I codici di errore riportati in \var{errno} sono quelli della chiamata
-    utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
-    descrizioni di \func{unlink} e \func{rmdir}.}
-\end{prototype}
+
+\begin{funcproto}{ 
+\fhead{stdio.h}
+\fdecl{int remove(const char *pathname)}
+\fdesc{Cancella un nome dal filesystem.} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+  caso \var{errno} assumerà uno dei valori relativi alla chimata utilizzata,
+  pertanto si può fare riferimento a quanto illustrato nelle descrizioni di
+  \func{unlink} e \func{rmdir}.}
+\end{funcproto}
 
 La funzione utilizza la funzione \func{unlink}\footnote{questo vale usando le
   \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
@@ -1141,15 +1461,15 @@ nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
   funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
   standard POSIX estende la funzione anche alle directory.} il cui prototipo
 è:
-\begin{prototype}{stdio.h}
-  {int rename(const char *oldpath, const char *newpath)} 
-  
-  Rinomina un file.
-  
-  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso il file non viene toccato. La variabile
-    \var{errno} viene impostata secondo i seguenti codici di errore:
-  \begin{errlist} 
+
+\begin{funcproto}{ 
+\fhead{stdio.h}
+\fdecl{int rename(const char *oldpath, const char *newpath)}
+\fdesc{Rinomina un file.} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+  nel qual caso \var{errno} assumerà uno dei valori: 
+  \begin{errlist}
   \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
     \param{oldpath} non è una directory.
   \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
@@ -1157,19 +1477,19 @@ nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
   \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
     non vuota.
   \item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
-    parte di qualche processo (come directory di lavoro o come radice) o del
-    sistema (come \itindex{mount~point} \textit{mount point}).
+    parte di qualche processo (come \index{directory~di~lavoro} directory di
+    lavoro o come radice) o del sistema (come \itindex{mount~point}
+    \textit{mount point}).
   \item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
     \param{oldpath} o più in generale si è cercato di creare una directory come
     sotto-directory di se stessa.
   \item[\errcode{ENOTDIR}] uno dei componenti dei \itindex{pathname}
     \textit{pathname} non è una directory o \param{oldpath} è una directory e
     \param{newpath} esiste e non è una directory.
-  \end{errlist} 
-  ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
+  \end{errlist} ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
   \errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
-  \errval{ENOSPC}.}
-\end{prototype}
+  \errval{ENOSPC} nel loro significato generico.}
+\end{funcproto}
 
 La funzione rinomina il file \param{oldpath} in \param{newpath}, eseguendo se
 necessario lo spostamento di un file fra directory diverse. Eventuali altri
@@ -1235,13 +1555,15 @@ alcune funzioni di libreria (come \func{open} o \func{stat}) quando ricevono
 come argomento un link simbolico vengono automaticamente applicate al file da
 esso specificato.  La funzione che permette di creare un nuovo link simbolico
 è \funcd{symlink}, ed il suo prototipo è:
-\begin{prototype}{unistd.h}
-  {int symlink(const char *oldpath, const char *newpath)} 
-  Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
-  \param{oldpath}.
-  
-  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
-    errore, nel qual caso la variabile \var{errno} assumerà i valori:
+
+
+\begin{funcproto}{ 
+\fhead{unistd.h}
+\fdecl{int symlink(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo link simbolico.} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+  nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
   \item[\errcode{EPERM}] il filesystem che contiene \param{newpath} non
     supporta i link simbolici.
@@ -1250,17 +1572,19 @@ esso specificato.  La funzione che permette di creare un nuovo link simbolico
   \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
   \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
     lettura.
-  \end{errlist}
-  ed inoltre \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
-  \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP}, \errval{ENOSPC} e
-  \errval{EIO}.}
-\end{prototype}
+  \end{errlist} ed inoltre \errval{EFAULT}, \errval{EACCES},
+  \errval{ENAMETOOLONG}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
+  \errval{ENOSPC} e \errval{EIO} nel loro significato generico.}
+\end{funcproto}
 
-Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
-di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
-nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
-che non esiste: in questo caso si ha quello che viene chiamato un
-\textit{dangling link}, letteralmente un \textsl{link ciondolante}.
+La funzione crea un nuovo link simbolico con \itindex{pathname}
+\textit{pathname} \param{newpath} che fa riferimento ad \param{oldpath}.  Si
+tenga presente che la funzione non effettua nessun controllo sull'esistenza di
+un file di nome \param{oldpath}, ma si limita ad inserire il
+\itindex{pathname} \textit{pathname} nel link simbolico. Pertanto un link
+simbolico può anche riferirsi ad un file che non esiste: in questo caso si ha
+quello che viene chiamato un \textit{dangling link}, letteralmente un
+\textsl{link ciondolante}.
 
 Come accennato i link simbolici sono risolti automaticamente dal kernel
 all'invocazione delle varie system call; in tab.~\ref{tab:file_symb_effect} si
@@ -1453,14 +1777,15 @@ La funzione che permette la cancellazione di una directory è invece
   \begin{errlist}
   \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
     directory, oppure la directory che contiene \param{dirname} ha lo
-    \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo
+    \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo
     del processo non corrisponde al proprietario della directory.
   \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
     che contiene la directory che si vuole cancellare, o non c'è il permesso
     di attraversare (esecuzione) una delle directory specificate in
     \param{dirname}.
-  \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
-    radice di qualche processo.
+  \item[\errcode{EBUSY}] la directory specificata è la
+    \index{directory~di~lavoro} directory di lavoro o la radice di qualche
+    processo.
   \item[\errcode{ENOTEMPTY}] la directory non è vuota.
   \end{errlist}
   ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
@@ -1595,8 +1920,8 @@ comportato il passaggio di \type{dev\_t} a \index{tipo!opaco} tipo opaco, e la
 necessità di specificare il numero tramite delle opportune macro, così da non
 avere problemi di compatibilità con eventuali ulteriori estensioni.
 
-Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
-automaticamente incluso quando si include \file{sys/types.h}; si possono
+Le macro sono definite nel file \headfile{sys/sysmacros.h}, che viene
+automaticamente incluso quando si include \headfile{sys/types.h}; si possono
 pertanto ottenere i valori del \itindex{major~number} \textit{major number} e
 \itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente
 con le macro \macro{major} e \macro{minor}:
@@ -1724,7 +2049,7 @@ La funzione restituisce il file descriptor associato al \textit{directory
   stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
 funzioni che operano sui file descriptor, ad esempio si potrà usare
 \func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la directory di lavoro (vedi
+spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
 sez.~\ref{sec:file_work_dir}).
 
 Viceversa se si è aperto un file descriptor corrispondente ad una directory è
@@ -2081,17 +2406,18 @@ una directory.  La funzione inizia con l'aprire (\texttt{\small 18--22}) uno
 stream sulla directory passata come primo argomento, stampando un messaggio in
 caso di errore.
 
-Il passo successivo (\texttt{\small 23--24}) è cambiare directory di lavoro
-(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
-\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
-(\texttt{\small 26--30}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
-  della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
-  \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
-  struttura \struct{dirent} sono sempre relativi alla directory in questione,
-  e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
-  ottenere le dimensioni.}
+Il passo successivo (\texttt{\small 23--24}) è cambiare
+\index{directory~di~lavoro} directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
+\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
+\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
+  26--30}) sulle singole voci dello stream ci si trovi all'interno della
+directory.\footnote{questo è essenziale al funzionamento della funzione
+  \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
+  quanto i nomi dei file memorizzati all'interno di una struttura
+  \struct{dirent} sono sempre relativi alla directory in questione, e senza
+  questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
+  le dimensioni.}
 
 Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
 alla funzione passata come secondo argomento, il ciclo di scansione della
@@ -2115,7 +2441,7 @@ chiusura (\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo
 \label{sec:file_work_dir}
 
 \itindbeg{pathname}
-
+\index{directory~di~lavoro|(} 
 Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
 directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
   della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
@@ -2193,11 +2519,11 @@ la directory corrente (vale a dire ``\texttt{.}'') e tornarvi in seguito con
 Una seconda usata per ottenere la directory di lavoro è \code{char
   *get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
 \code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
-contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
-\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
-all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
-attraverso eventuali link simbolici.
+della variabile di ambiente \envvar{PWD}, che essendo costruita dalla shell
+può contenere un \textit{pathname} comprendente anche dei link
+simbolici. Usando \func{getcwd} infatti, essendo il \textit{pathname} ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
 
 Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
 (equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
@@ -2236,7 +2562,7 @@ quello in cui il processo non ha il permesso di accesso alla directory
 specificata da \param{fd}.
 
 \itindend{pathname}
-
+\index{directory~di~lavoro|)} 
 
 
 \subsection{I file temporanei}
@@ -2273,7 +2599,7 @@ massimo di \const{TMP\_MAX} volte, limite oltre il quale il comportamento è
 indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
 specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
   \const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
-  \file{stdio.h}.}
+  \headfile{stdio.h}.}
 
 Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
 \func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
@@ -2294,7 +2620,7 @@ L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
 nome provvisorio. La funzione assegna come directory per il file temporaneo,
 verificando che esista e sia accessibile, la prima valida fra le seguenti:
 \begin{itemize*}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+\item La variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
   definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
   \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
 \item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
@@ -2358,7 +2684,7 @@ La funzionane genera un nome univoco sostituendo le \code{XXXXXX} finali di
 funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
 alle possibili \itindex{race~condition} \textit{race condition} date per
 \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
-il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
+il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID}
 del processo più una lettera, il che mette a disposizione solo 26 possibilità
 diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
 Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
@@ -2392,7 +2718,7 @@ sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
 questa funzione esiste una variante \funcd{mkostemp}, introdotta
 specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
   nella versione 2.7 delle librerie e richiede che sia definita la macro
-  \const{\_GNU\_SOURCE}.} il cui prototipo è:
+  \macro{\_GNU\_SOURCE}.} il cui prototipo è:
 \begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
   Genera un file temporaneo.
   
@@ -2475,7 +2801,7 @@ riferimento. Infine \func{fstat} esegue la stessa operazione su un file già
 aperto, specificato tramite il suo file descriptor \param{filedes}.
 
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
 usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
 riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
@@ -2496,7 +2822,7 @@ sez.~\ref{sec:file_file_times}), o per il padding dei campi.
 
 Si noti come i vari membri della struttura siano specificati come tipi
 primitivi del sistema (di quelli definiti in
-tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h}).
 
 \subsection{I tipi di file}
 \label{sec:file_types}
@@ -2530,14 +2856,14 @@ riportato in tab.~\ref{tab:file_type_macro}.
     \macro{S\_ISSOCK}\texttt{(m)} & socket.\\
     \hline    
   \end{tabular}
-  \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
+  \caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
   \label{tab:file_type_macro}
 \end{table}
 
 Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
 direttamente il valore di \var{st\_mode} per ricavare il tipo di file
 controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\headfile{sys/stat.h} sono definite le costanti numeriche riportate in
 tab.~\ref{tab:file_mode_flags}.
 
 Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
@@ -2584,7 +2910,7 @@ un'opportuna combinazione.
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit che compongono il campo
-    \var{st\_mode} (definite in \file{sys/stat.h}).}
+    \var{st\_mode} (definite in \headfile{sys/stat.h}).}
   \label{tab:file_mode_flags}
 \end{table}
 
@@ -2743,6 +3069,8 @@ accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia
 in termini di prestazioni, che di consumo di risorse come la batteria per i
 portatili, o cicli di riscrittura per i dischi su memorie riscrivibili.
 
+% TODO aggiustare per il contenuto duplicato con le analoghe MS_*
+
 Per questo motivo, onde evitare di mantenere una informazione che nella
 maggior parte dei casi non interessa, è sempre stato possibile disabilitare
 l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio
@@ -3077,7 +3405,7 @@ concetti essenziali e le funzioni usate per gestirne i vari aspetti.
 
 Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
 cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
-degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
+degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori
 sono accessibili da programma tramite la funzione \func{stat}, e sono
 mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
 \struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
@@ -3224,8 +3552,8 @@ veda sez.~\ref{sec:file_special_perm}).
 La procedura con cui il kernel stabilisce se un processo possiede un certo
 permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid}
-effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in
+\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID}
+effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in
   realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
   identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
   sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
@@ -3234,19 +3562,19 @@ effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in
 
 Per una spiegazione dettagliata degli identificatori associati ai processi si
 veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo
-corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
-lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi
+sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo
+corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha
+lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi
 cui l'utente appartiene.
 
 I passi attraverso i quali viene stabilito se il processo possiede il diritto
 di accesso sono i seguenti:
 \begin{enumerate}
-\item Se l'\acr{uid} effettivo del processo è zero (corrispondente
+\item Se l'\ids{UID} effettivo del processo è zero (corrispondente
   all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
   controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
   tutti i file.
-\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del
+\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del
   proprietario del file (nel qual caso si dice che il processo è proprietario
   del file) allora:
   \begin{itemize*}
@@ -3256,8 +3584,8 @@ di accesso sono i seguenti:
     impostato, l'accesso è consentito
   \item altrimenti l'accesso è negato
   \end{itemize*}
-\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari
-  dei processi corrispondono al \acr{gid} del file allora:
+\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari
+  dei processi corrispondono al \ids{GID} del file allora:
   \begin{itemize*}
   \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
     consentito, 
@@ -3298,9 +3626,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema.
 Se però il file del programma (che ovviamente deve essere
 eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
   e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del
-proprietario del file al posto dell'\acr{uid} del processo originario.  Avere
-il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del
+kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del
+proprietario del file al posto dell'\ids{UID} del processo originario.  Avere
+il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del
 processo.
 
 I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
@@ -3397,10 +3725,10 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti.
 \label{sec:file_perm_management}
 
 Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid}
-reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e
-\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
+file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo;
+ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID}
+reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e
+\ids{GID} relativi all'utente che ha lanciato il programma, e che, come
 accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
 sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
 
@@ -3490,7 +3818,7 @@ filename e su un file descriptor, i loro prototipi sono:
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del
+  \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
     proprietario del file o non è zero.
     \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
   \end{errlist}
@@ -3554,7 +3882,7 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$.
 
 Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
 comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo
+funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
 corrisponde a quello del proprietario del file o dell'amministratore,
 altrimenti esse falliranno con un errore di \errcode{EPERM}.
 
@@ -3564,7 +3892,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
 in particolare accade che:
 \begin{enumerate}
 \item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
-  \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso
+  \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso
   viene automaticamente cancellato (senza notifica di errore) qualora sia
   stato indicato in \param{mode}.
 \item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
@@ -3574,7 +3902,7 @@ in particolare accade che:
   un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
   automaticamente cancellato da \param{mode} (senza notifica di errore)
   qualora il gruppo del file non corrisponda a quelli associati al processo
-  (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero).
+  (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero).
 \end{enumerate}
 
 Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
@@ -3647,21 +3975,21 @@ quale utente e gruppo esso deve appartenere.  Lo stesso problema si presenta
 per la creazione di nuove directory (procedimento descritto in
 sez.~\ref{sec:file_dir_creat_rem}).
 
-Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
+Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda
+all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece
+prevede due diverse possibilità:
 \begin{itemize*}
-\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo.
-\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
+\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo.
+\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui
   esso è creato.
 \end{itemize*}
 in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
 semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
 norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+\ids{GID} del processo, se però la directory in cui viene creato il file ha il
 bit \acr{sgid} impostato allora viene usata la seconda opzione.
 
-Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre
 automaticamente propagato, restando coerente a quello della directory di
 partenza, in tutte le sotto-directory. 
 
@@ -3670,7 +3998,7 @@ risultato di coerenza che si ha con BSD necessita che quando si creano nuove
 directory venga anche propagato anche il bit \acr{sgid}. Questo è il
 comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
 esempio che le varie distribuzioni assicurano che le sotto-directory create
-nella home di un utente restino sempre con il \acr{gid} del gruppo primario
+nella home di un utente restino sempre con il \ids{GID} del gruppo primario
 dello stesso.
 
 La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
@@ -3702,7 +4030,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono:
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
     errore, nel qual caso caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del
+  \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
     proprietario del file o non è zero, o utente e gruppo non sono validi
   \end{errlist}
   Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
@@ -4413,15 +4741,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di
 ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
 sono i seguenti:
 \begin{enumerate*}
-\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza
+\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza
   nessun controllo.
-\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora:
+\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora:
   \begin{itemize*}
   \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
     l'accesso è consentito;
   \item altrimenti l'accesso è negato.
   \end{itemize*}
-\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore
+\item Se l'\ids{UID} del processo corrisponde ad un qualunque qualificatore
   presente in una voce \const{ACL\_USER} allora:
   \begin{itemize*}
   \item se la voce \const{ACL\_USER} corrispondente e la voce
@@ -4429,7 +4757,7 @@ sono i seguenti:
     consentito;
   \item altrimenti l'accesso è negato.
   \end{itemize*}
-\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
   corrisponde al gruppo proprietario del file allora: 
   \begin{itemize*}
   \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
@@ -4438,7 +4766,7 @@ sono i seguenti:
     l'accesso è consentito;
   \item altrimenti l'accesso è negato.
   \end{itemize*}
-\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
   corrisponde ad un qualunque qualificatore presente in una voce
   \const{ACL\_GROUP} allora:
   \begin{itemize*}
@@ -4782,7 +5110,7 @@ tab.~\ref{tab:acl_to_text_options}.
     \hline
     \const{TEXT\_ABBREVIATE}     & stampa le voci in forma abbreviata.\\
     \const{TEXT\_NUMERIC\_IDS}   & non effettua la risoluzione numerica di
-                                   \acr{uid} e \acr{gid}.\\
+                                   \ids{UID} e \ids{GID}.\\
     \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
                                    vengono eliminati dalla \const{ACL\_MASK}
                                    viene generato un commento con i permessi 
@@ -5108,7 +5436,7 @@ La funzione richiede che il filesystem sul quale si vuole operare sia montato
 con il supporto delle quote abilitato; esso deve essere specificato con il
 nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che
 lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o
-il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si
+il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si
 vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare
 un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
 stessa.
@@ -5217,10 +5545,10 @@ l'amministratore può ottenere i dati di tutti.
     \hline
     \const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\
     \const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta
-                            \acr{uid} e \acr{gid} a 32 bit e limiti fino a
+                            \ids{UID} e \ids{GID} a 32 bit e limiti fino a
                             $2^{42}$ byte e $2^{32}$ file.\\
     \const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta
-                            \acr{uid} e \acr{GID} a 32 bit e limiti fino a
+                            \ids{UID} e \ids{GID} a 32 bit e limiti fino a
                             $2^{64}$ byte e $2^{64}$ file.\\
     \hline
   \end{tabular}
@@ -5688,7 +6016,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
 privilegi originali dal processo.
 
 Per questo motivo se un programma senza \textit{capabilities} assegnate viene
-eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come
+eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come
 se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
 tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
 col risultato di fornire comunque al processo tutte le capacità presenti nel
@@ -5697,19 +6025,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
 riesce così a riottenere il comportamento classico di un sistema unix-like.
 
 Una seconda circostanza è quella relativa a cosa succede alle
-\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid}
-nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a
+\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
+nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
 cedere o riottenere i i privilegi di amministratore) che si possono effettuare
 con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
 casistica è di nuovo alquanto complessa, considerata anche la presenza dei
 diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
 avrà allora che:
 \begin{enumerate*}
-\item se si passa da \acr{uid} effettivo nullo a non nullo
+\item se si passa da \ids{UID} effettivo nullo a non nullo
   l'\textit{effective set} del processo viene totalmente azzerato, se
-  viceversa si passa da \acr{uid} effettivo non nullo a nullo il
+  viceversa si passa da \ids{UID} effettivo non nullo a nullo il
   \textit{permitted set} viene copiato nell'\textit{effective set};
-\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno
+\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno
   cancellate dall'\textit{effective set} del processo tutte le capacità
   attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
   \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
@@ -5744,7 +6072,7 @@ Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
 ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
 mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
 valore consente di modificare queste regole speciali che si applicano ai
-processi con \acr{uid} nullo. La maschera viene sempre mantenuta
+processi con \ids{UID} nullo. La maschera viene sempre mantenuta
 attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
 cancellato il flag \const{SECURE\_KEEP\_CAPS}.
 
@@ -5758,22 +6086,22 @@ cancellato il flag \const{SECURE\_KEEP\_CAPS}.
     \hline
     \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
                                 sue \textit{capabilities} quando tutti i suoi
-                                \acr{uid} passano ad un valore non
+                                \ids{UID} passano ad un valore non
                                 nullo (regola di compatibilità per il cambio
-                                di \acr{uid} n.~3 del precedente
+                                di \ids{UID} n.~3 del precedente
                                 elenco), sostituisce il precedente uso
                                 dell'operazione \const{PR\_SET\_KEEPCAPS} di
                                 \func{prctl}.\\
     \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
                                 delle sue \textit{capabilities} nel passaggio
-                                da nullo a non nullo degli \acr{uid}
+                                da nullo a non nullo degli \ids{UID}
                                 dei gruppi \textit{effective} e
                                 \textit{file system} (regole di compatibilità
-                                per il cambio di \acr{uid} nn.~1 e 2 del
+                                per il cambio di \ids{UID} nn.~1 e 2 del
                                 precedente elenco).\\
     \const{SECURE\_NOROOT}    & Il processo non assume nessuna capacità
                                 aggiuntiva quando esegue un programma, anche
-                                se ha \acr{uid} nullo o il programma ha
+                                se ha \ids{UID} nullo o il programma ha
                                 il \acr{suid} bit attivo ed appartiene
                                 all'amministratore (regola di compatibilità
                                 per l'esecuzione di programmi senza
@@ -5830,13 +6158,14 @@ Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
 breve descrizione ed il nome delle costanti che le identificano, è riportato
 in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
   tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
-    capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
-  aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
-riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux.  Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
-molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+    capabilities}) e dalle definizioni in
+  \texttt{include/linux/capabilities.h}, è aggiornato al kernel 2.6.26.} la
+tabella è divisa in due parti, la prima riporta le \textit{capabilities}
+previste anche nella bozza dello standard POSIX1.e, la seconda quelle
+specifiche di Linux.  Come si può notare dalla tabella alcune
+\textit{capabilities} attengono a singole funzionalità e sono molto
+specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
+opportuno dettagliare maggiormente.
 
 \begin{table}[!h!btp]
   \centering
@@ -6009,8 +6338,8 @@ capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
 La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
 maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
 processo che non ha la proprietà di un file in un vasto campo di
-operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del
-  processo (o meglio l'\acr{uid} di filesystem, vedi
+operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del
+  processo (o meglio l'\ids{UID} di filesystem, vedi
   sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}  queste
 comprendono i cambiamenti dei permessi e dei tempi del file (vedi
 sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
@@ -6035,7 +6364,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi
 sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su
 qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
 sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
-(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario
+(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario
 nella trasmissione delle credenziali dei socket (vedi
 sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
 (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
@@ -6104,8 +6433,9 @@ fig.~\ref{fig:cap_kernel_struct}.  Per un certo periodo di tempo era anche
 indicato che per poterle utilizzare fosse necessario che la macro
 \macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
 una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\texttt{sys/capability.h}) requisito che non risulta più presente.\footnote{e
-  non è chiaro neanche quanto sia mai stato davvero necessario.}
+\headfile{sys/capability.h}) requisito che non risulta più
+presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
+  necessario.}
 
 Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
 prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
@@ -6300,8 +6630,8 @@ La funzione richiede che si indichi quale degli insiemi si intente cancellare
 con l'argomento \param{flag}. Questo deve essere specificato con una variabile
 di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta
   in effetti di un tipo enumerato, come si può verificare dalla sua
-  definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
-valori illustrati in tab.~\ref{tab:cap_set_identifier}.
+  definizione che si trova in \headfile{sys/capability.h}.} uno dei valori
+illustrati in tab.~\ref{tab:cap_set_identifier}.
 
 Si possono inoltre confrontare in maniera diretta due diversi
 \textit{capability state} con la funzione \funcd{cap\_compare}; il suo
@@ -6365,7 +6695,7 @@ prendere come valore uno qualunque di quelli riportati in
 tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
 combinare diversi valori in una maschera binaria, una variabile di tipo
 \type{cap\_value\_t} può indicare una sola capacità.\footnote{in
-  \texttt{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
+  \headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
   \ctyp{int}, ma i valori validi sono soltanto quelli di
   tab.~\ref{tab:proc_capabilities}.}
 
@@ -6558,7 +6888,7 @@ specifico occorre usare la funzione \funcd{capgetp}, il cui
 prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
   prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
   ma il valore di ritorno è intero, come si può verificare anche dalla
-  dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+  dichiarazione della stessa in \headfile{sys/capability.h}.} è:
 \begin{functions}
   \headdecl{sys/capability.h}
 
@@ -6658,7 +6988,7 @@ funzione.
 
 
 
-\subsection{La funzione \func{chroot}}
+\subsection{La gestione dei {chroot}}
 \label{sec:file_chroot}
 
 % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
@@ -6672,20 +7002,23 @@ Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
 programma ad una sezione limitata del filesystem, per cui ne parleremo in
 questa sezione.
 
+% TODO riferimenti ai bind mount, link simbolici ecc.
+
 Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
-  sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
-  \struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
-di norma corrispondente alla radice dell'albero di file e directory come visto
-dal kernel (ed illustrato in sez.~\ref{sec:file_pathname}), ha per il processo
-il significato specifico di directory rispetto alla quale vengono risolti i
+\index{directory~di~lavoro} directory di lavoro, ha anche una directory
+\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
+  \var{pwd} e \var{root}) di \struct{fs\_struct}; vedi
+  fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
+alla radice dell'albero di file e directory come visto dal kernel (ed
+illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
+specifico di directory rispetto alla quale vengono risolti i
 \itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
   un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
   sempre questa directory come punto di partenza.} Il fatto che questo valore
 sia specificato per ogni processo apre allora la possibilità di modificare le
 modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
 cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la directory
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la \index{directory~di~lavoro} directory
 di lavoro.
 
 Normalmente la directory radice di un processo coincide anche con la radice
@@ -6704,7 +7037,7 @@ con la funzione \funcd{chroot}, il cui prototipo è:
 \bodydesc{La funzione restituisce zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero.
+  \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero.
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
@@ -6727,19 +7060,20 @@ cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
 
 Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
 si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
-comunque accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
-(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
-filesystem.
+resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
+\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
+usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
+partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
+potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
+del filesystem.
 
 Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
-portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
-trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
-\func{chroot} su una qualunque directory contenuta nell'attuale directory di
-lavoro.  Per questo motivo l'uso di questa funzione non ha molto senso quando
-un processo necessita dei privilegi di root per le sue normali operazioni.
+portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
+\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
+\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
+contenuta nell'attuale directory di lavoro.  Per questo motivo l'uso di questa
+funzione non ha molto senso quando un processo necessita dei privilegi di root
+per le sue normali operazioni.
 
 Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
 questo caso infatti si vuole che il server veda solo i file che deve
@@ -6823,7 +7157,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  second linked journaled source filesystemtype unsigned device
 % LocalWords:  mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE
 % LocalWords:  NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs
-% LocalWords:  fstatfs fstab mntent ino bound orig new setpcap
+% LocalWords:  fstatfs fstab mntent ino bound orig new setpcap metadati sysfs
 
 %%% Local Variables: 
 %%% mode: latex