Altre correzioni ed indici

[gapil.git] / filedir.tex

diff --git a/filedir.tex b/filedir.tex
index 2fbda9fa35ea0bdd0c9987a51d832f8c025e2e94..3aae3d7986a96f74f1ccebec0a020b31d092cb81 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -100,7 +100,7 @@ relativi campi con i dati specifici di quel filesystem, ed in particolare si
 dovrà creare anche la relativa versione della funzione \code{mount}.
 
 \itindbeg{pathname}
 dovrà creare anche la relativa versione della funzione \code{mount}.
 
 \itindbeg{pathname}

-\itindbeg{pathname!resolution}
+\itindbeg{pathname~resolution}

 
 Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
 restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
 
 Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
 restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory


@@ -138,7 +138,7 @@ questo punto verrà inserita nella cache.
 
 Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
 della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
 
 Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
 della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}

-iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà
+iniziale nel \itindex{mount~point} \textit{mount point} dello stesso, si avrà

 comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
 a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
 filesystem, e come vedremo questo farà sì che venga eseguita una
 comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
 a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
 filesystem, e come vedremo questo farà sì che venga eseguita una


@@ -146,7 +146,7 @@ filesystem, e come vedremo questo farà sì che venga eseguita una
 filesystem.
 
 \itindend{pathname}
 filesystem.
 
 \itindend{pathname}

-\itindend{pathname!resolution}
+\itindend{pathname~resolution}

 
 % Un secondo effetto della chiamata funzione \texttt{mount} di
 % \kstruct{file\_system\_type} è quello di allocare una struttura
 
 % Un secondo effetto della chiamata funzione \texttt{mount} di
 % \kstruct{file\_system\_type} è quello di allocare una struttura


@@ -256,11 +256,11 @@ Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
 funzione \texttt{open} che invece è citata in
 tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
   invocata dato che nella struttura \kstruct{inode} è presente anche il
 funzione \texttt{open} che invece è citata in
 tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
   invocata dato che nella struttura \kstruct{inode} è presente anche il

-  puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
-  fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
-file richiede comunque un'altra operazione che mette in gioco l'omonimo
-oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
-viene associata ad ogni file aperto nel sistema.
+  puntatore \var{i\_fop} alla struttura \kstruct{file\_operation} che fornisce
+  detta funzione.} Questo avviene perché su Linux l'apertura di un file
+richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
+VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
+ad ogni file aperto nel sistema.

 
 I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
 come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
 
 I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
 come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le


@@ -291,8 +291,8 @@ di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
 Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
 \kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
 dei file descriptor il cui significato emergerà più avanti, il puntatore
 Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
 \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
+\var{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.
 
 fornite dal VFS per i file. Si sono riportate in
 tab.~\ref{tab:file_file_operations} le più significative.
 


@@ -458,7 +458,7 @@ opportuno tenere sempre presente che:
   che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
   Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
   nuova voce per un file esistente con la funzione \func{link} (vedi
   che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
   Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
   nuova voce per un file esistente con la funzione \func{link} (vedi

-  sez.~\ref{sec:file_link}) a file nel filesystem corrente.
+  sez.~\ref{sec:file_link}), a operare su file nel filesystem corrente.

   
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
   
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una


@@ -516,13 +516,13 @@ 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
 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.}
+\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
+il filesystem più diffuso, ed una serie di ulteriori miglioramenti 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
 
 Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
 dalle prime versioni del kernel e supporta tutte le caratteristiche di un


@@ -620,9 +620,9 @@ contenenti un gran numero di file.
 \label{sec:sys_file_config}
 
 Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
 \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},
+occorre rendere disponibile al sistema il filesystem su cui essi sono
+memorizzati. L'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio} e 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.}
 
 il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che
   usa la omonima \textit{system call} e non è portabile.}
 


@@ -725,8 +725,8 @@ 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
 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).
+modificare il comportamento della funzione \func{mount}, 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
 
 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


@@ -748,8 +748,8 @@ identificati dalle costanti riportate nell'elenco seguente:
   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
   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à
+  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.
 
   effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype}
   e \param{data} vengono ignorati.
 


@@ -787,20 +787,19 @@ identificati dalle costanti riportate nell'elenco seguente:
   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
   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.
+  \textit{read-only bind mount} e viene onorata la presenza aggiuntiva 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
 
   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}.  
+  sez.~\ref{sec:file_link}) con la possibilità di 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
 \itindend{bind~mount}
 
 \item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una


@@ -808,7 +807,7 @@ identificati dalle costanti riportate nell'elenco seguente:
   (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
   (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
+  con il comando \cmd{chattr}.\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
     \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
 
   Questo consente di ridurre al minimo il rischio di perdita dei dati delle


@@ -961,7 +960,7 @@ identificati dalle costanti riportate nell'elenco seguente:
   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
   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}
+  il montaggio originale, mentre sia \param{data} che \param{mountflags}

   conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
 
   Qualunque opzione specifica del filesystem indicata con \param{data} può
   conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
 
   Qualunque opzione specifica del filesystem indicata con \param{data} può


@@ -982,14 +981,16 @@ identificati dalle costanti riportate nell'elenco seguente:
     point} che si intende marcare, e tutti gli altri argomenti verranno
   ignorati.
 
     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.
+  Lo scopo dell'opzione è ottenere che tutti i successivi \itindex{bind~mount}
+  \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 effettuate al di sotto di un qualunque
+  \textit{mount point} così marcato verranno ``\textsl{propagate}'' a tutti i
+  \itindex{mount~point} \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
 
 \item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
   avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione


@@ -1010,7 +1011,7 @@ identificati dalle costanti riportate nell'elenco seguente:
   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
   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
+  \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
   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


@@ -1045,13 +1046,13 @@ identificati dalle costanti riportate nell'elenco seguente:
   \param{target} dovrà fare riferimento al \textit{mount point} che si intende
   marcare, e tutti gli altri argomenti verranno ignorati.
 
   \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}.
+  Un \textit{mount point} marcato in questo modo disabilita la capacità di
+  eseguire dei \itindex{bind~mount} \textit{bind mount} del suo contenuto. 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}.

 
 \end{basedescript}
 
 
 \end{basedescript}
 


@@ -1116,7 +1117,7 @@ filesystem anche quando questo risulti occupato; il suo prototipo è:
 {La funzione ritorna  $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
 {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{BUSY}] \param{target} è la \index{directory~di~lavoro}
+     \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{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
        directory di lavoro di qualche processo, o contiene dei file aperti, o un
        altro mount point.
      \item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}


@@ -1178,16 +1179,28 @@ Con \const{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
 due, si marca il \itindex{mount~point} \textit{mount point} di un filesystem
 non occupato come ``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna
 con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si
 due, si marca il \itindex{mount~point} \textit{mount point} di un filesystem
 non occupato come ``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna
 con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si

-sarebbe ricevuto \errcode{BUSY}.  Una volta marcato, se nel frattempo non
+sarebbe ricevuto \errcode{EBUSY}.  Una volta marcato, se nel frattempo non

 viene fatto nessun uso del filesystem, ad una successiva chiamata con
 \const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare
 viene fatto nessun uso del filesystem, ad una successiva chiamata con
 \const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare

-un meccanismo che smonti automaticamente i filesystem che restano inutilizzato
+un meccanismo che smonti automaticamente i filesystem che restano inutilizzati

 per un certo periodo di tempo.
 
 per un certo periodo di tempo.
 

-% Infine il flag \const{UMOUNT\_NOFOLLOW} impedisce l'uso di un link simbolico
-% per \param{target} evitando così che si possano passare ai programmi che
-% effettuano lo smontaggio dei filesystem per i quali è previsto la possibilità
-% di gestione da parte degli utenti con uno programma \acr{sgid} 
+Infine il flag \const{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
+questo è un link simbolico (vedi sez.~\ref{sec:file_symlink}). Questa è una
+misura di sicurezza introdotta per evitare, per quei filesystem per il quale è
+prevista una gestione diretta da parte degli utenti, come quelli basati su
+FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
+  interessanti applicazioni del \itindex{Virtual~File~System} VFS che
+  consente, tramite un opportuno modulo, di implementarne le funzioni in
+  \textit{user space}, così da rendere possibile l'implementazione di un
+  qualunque filesytem (con applicazioni di grande interesse come il filesystem
+  cifrato \textit{encfs} o il filesystem di rete \textit{sshfs}) che possa
+  essere usato direttamente per conto degli utenti.}  che si possano passare
+ai programmi che effettuano lo smontaggio dei filesystem, che in genere sono
+privilegiati ma consentono di agire solo sui propri \textit{mount point}, dei
+link simbolici che puntano ad altri \textit{mount point}, ottenendo così la
+possibilità di smontare qualunque filesystem.
+

 
 Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
   ma con una struttura diversa.} utili per ottenere in maniera diretta
 
 Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
   ma con una struttura diversa.} utili per ottenere in maniera diretta


@@ -1212,13 +1225,15 @@ informazioni riguardo al filesystem su cui si trova un certo file, sono
 \end{funcproto}
 
 Queste funzioni permettono di ottenere una serie di informazioni generali
 \end{funcproto}
 
 Queste funzioni permettono di ottenere una serie di informazioni generali

-riguardo al filesystem su cui si trova il file specificato con un ; queste vengono
-restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita
-come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il
-filesystem in esame sono impostati a zero.  I valori del campo \var{f\_type}
-sono definiti per i vari filesystem nei relativi file di header dei sorgenti
-del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in
-genere è il nome del filesystem stesso.
+riguardo al filesystem su cui si trova il file specificato con un
+\textit{pathname} per \func{statfs} e con un file descriptor (vedi
+sez.~\ref{sec:file_fd}) per \func{statfs}.  Le informazioni vengono restituite
+all'indirizzo \param{buf} di una struttura \struct{statfs} definita come in
+fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in
+esame sono impostati a zero.  I valori del campo \var{f\_type} sono definiti
+per i vari filesystem nei relativi file di header dei sorgenti del kernel da
+costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in genere è il nome
+del filesystem stesso.

 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -1231,23 +1246,37 @@ genere è il nome del filesystem stesso.
 \end{figure}
 
 Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
 \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
-informazioni riguardo ai filesystem da montare e a quelli correntemente
-montati. Le funzioni servono a leggere il contenuto di questi file in
-opportune strutture \struct{fstab} e \struct{mntent}, e, per
-\conffile{/etc/mtab} per inserire e rimuovere le voci presenti nel file.
-
-In generale si dovrebbero usare queste funzioni (in particolare quelle
-relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che
-effettua il montaggio di un filesystem; in realtà in questi casi è molto più
-semplice invocare direttamente il programma \cmd{mount}, per cui ne
-tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
-\cite{glibc} per la documentazione completa.
+file \conffile{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
+  \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
+ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
+  \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
+  \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
+sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
+filesystem da montare e a quelli correntemente montati. Le funzioni servono a
+leggere il contenuto di questi file in opportune strutture \struct{fstab} e
+\struct{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e rimuovere
+le voci presenti nel file.
+
+In generale si dovrebbero usare queste funzioni, in particolare quelle
+relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
+effettua il montaggio di un filesystem. In realtà in questi casi è molto più
+semplice invocare direttamente il programma \cmd{mount}. Inoltre l'uso stesso
+di \conffile{/etc/mtab} è considerato una pratica obsoleta, in quanto se non
+aggiornato correttamente (cosa che è impossibile se la radice è montata in
+sola lettura) il suo contenuto diventa fuorviante.
+
+Per questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
+oggi sostituito da un link simbolico a \procfile{/proc/mounts}, che contiene
+una versione degli stessi contenuti (vale a dire l'elenco dei filesystem
+montati) generata direttamente dal kernel, e quindi sempre disponibile e
+sempre aggiornata. Per questo motivo tralasceremo la trattazione, di queste
+funzioni, rimandando al manuale delle \acr{glibc} \cite{GlibcMan} per la
+documentazione completa.

 
 % TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
 % TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...) 
 
 
 % TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
 % TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...) 
 

+

 \section{La gestione di file e directory}
 \label{sec:file_dir}
 
 \section{La gestione di file e directory}
 \label{sec:file_dir}
 


@@ -1255,11 +1284,11 @@ Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
 la gestione dei file ha delle caratteristiche specifiche che derivano
 direttamente dall'architettura del sistema.  In questa sezione esamineremo le
 funzioni usate per la manipolazione di file e directory, per la creazione di
 la gestione dei file ha delle caratteristiche specifiche che derivano
 direttamente dall'architettura del sistema.  In questa sezione esamineremo le
 funzioni usate per la manipolazione di file e directory, per la creazione di

-link simbolici e diretti, per la gestione e la lettura delle directory.
-
-In particolare ci soffermeremo sulle conseguenze che derivano
-dall'architettura dei filesystem illustrata nel capitolo precedente per quanto
-riguarda il comportamento e gli effetti delle varie funzioni.
+link simbolici e diretti, per la gestione e la lettura delle directory.  In
+particolare ci soffermeremo sulle conseguenze che derivano dalla struttura
+generica di un qualunque filesystem illustrata in
+sez.~\ref{sec:file_filesystem} per quanto attiene il comportamento e gli
+effetti delle varie funzioni.

 
 
 \subsection{Le funzioni \func{link} e \func{unlink}}
 
 
 \subsection{Le funzioni \func{link} e \func{unlink}}


@@ -1271,9 +1300,9 @@ o i nomi logici del VMS) che permettono di fare riferimento allo stesso file
 chiamandolo con nomi diversi o accedendovi da directory diverse.
 
 Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
 chiamandolo con nomi diversi o accedendovi da directory diverse.
 
 Questo è possibile anche in ambiente Unix, dove tali collegamenti sono

-usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo
-la gestione dei file ci sono due metodi sostanzialmente diversi per fare
-questa operazione.
+usualmente chiamati ``\textit{link}''; ma data l'architettura del sistema
+riguardo la gestione dei file ci sono due metodi sostanzialmente diversi per
+fare questa operazione.

 
 Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene passando attraverso il suo \itindex{inode}
 
 Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
 file su disco avviene passando attraverso il suo \itindex{inode}


@@ -1283,18 +1312,19 @@ trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
 della directory, che viene associata ad un puntatore che fa riferimento al
 suddetto \textit{inode}.
 
 della directory, che viene associata ad un puntatore che fa riferimento al
 suddetto \textit{inode}.
 

-Questo significa che, fintanto che si resta sullo stesso filesystem, la
-realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
+Questo significa che fintanto che si resta sullo stesso filesystem la
+realizzazione di un link è immediata ed uno stesso file può avere tanti nomi

 diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}
 diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}

-\textit{inode} effettuate tramite ``etichette'' diverse in directory
-diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
-particolare preferenza o originalità rispetto agli altri, in quanto tutti
-fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
+\textit{inode} effettuate tramite ``etichette'' diverse (voci, nella
+nomenclatura di sez.~\ref{sec:file_filesystem}) in directory diverse. Si noti
+anche che nessuno di questi nomi viene ad assumere una particolare preferenza
+o originalità rispetto agli altri, in quanto tutti fanno comunque riferimento
+allo stesso \itindex{inode} \textit{inode}.

 
 Per aggiungere ad una directory una voce che faccia riferimento ad un
 \itindex{inode} \textit{inode} già esistente si utilizza la funzione
 
 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:
+\funcd{link}, e si suole chiamare questo tipo di associazione un collegamento
+diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:

 
 \begin{funcproto}{ 
 \fhead{unistd.h}
 
 \begin{funcproto}{ 
 \fhead{unistd.h}


@@ -1304,19 +1334,19 @@ diretto, o \textit{hard link}.  Il prototipo della funzione è il seguente:
 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
 {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}
-    \textit{mount point}.
-  \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
-    \param{newpath} non supporta i link diretti o è una directory.

   \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
     esiste già.
   \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}).
   \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
     esiste già.
   \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} nel loro significato
+  \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
+    \param{newpath} non supporta i link diretti o è una directory.
+  \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
+    riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
+    \textit{mount point}.
+  \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
+  \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
+  \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato

   generico.}
 \end{funcproto}
 
   generico.}
 \end{funcproto}
 


@@ -1327,12 +1357,12 @@ nuovo collegamento diretto non copia il contenuto del file, ma si limita a
 creare una voce nella directory specificata da \param{newpath} e ad aumentare
 di uno il numero di riferimenti al file (riportato nel campo \var{st\_nlink}
 della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat}) aggiungendo il
 creare una voce nella directory specificata da \param{newpath} e ad aumentare
 di uno il numero di riferimenti al file (riportato nel campo \var{st\_nlink}
 della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat}) aggiungendo il

-nuovo nome ai precedenti. Si noti che uno stesso file può essere così chiamato
+nuovo nome ai precedenti. In questo modo lo stesso file può essere chiamato

 con vari nomi in diverse directory.
 
 Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
 collegamento diretto è possibile solo se entrambi i \textit{pathname} sono
 con vari nomi in diverse directory.
 
 Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
 collegamento diretto è possibile solo se entrambi i \textit{pathname} sono

-nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti
+nello stesso filesystem. Inoltre il filesystem deve supportare i collegamenti

 diretti (il meccanismo non è disponibile ad esempio con il filesystem
 \acr{vfat} di Windows). In realtà la funzione ha un ulteriore requisito, e
 cioè che non solo che i due file siano sullo stesso filesystem, ma anche che
 diretti (il meccanismo non è disponibile ad esempio con il filesystem
 \acr{vfat} di Windows). In realtà la funzione ha un ulteriore requisito, e
 cioè che non solo che i due file siano sullo stesso filesystem, ma anche che


@@ -1346,9 +1376,9 @@ filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
 l'amministratore è in grado di creare un collegamento diretto ad un'altra
 directory: questo viene fatto perché con una tale operazione è possibile
 creare dei \textit{loop} nel filesystem (vedi l'esempio mostrato in
 l'amministratore è in grado di creare un collegamento diretto ad un'altra
 directory: questo viene fatto perché con una tale operazione è possibile
 creare dei \textit{loop} nel filesystem (vedi l'esempio mostrato in

-sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
-non sono in grado di gestire e la cui rimozione diventerebbe estremamente
-complicata (in genere per questo tipo di errori occorre far girare il
+sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti
+programmi non sono in grado di gestire e la cui rimozione diventerebbe
+piuttosto complicata (in genere per questo tipo di errori occorre eseguire il

 programma \cmd{fsck} per riparare il filesystem).
 
 Data la pericolosità di questa operazione e la disponibilità dei link
 programma \cmd{fsck} per riparare il filesystem).
 
 Data la pericolosità di questa operazione e la disponibilità dei link


@@ -1360,22 +1390,24 @@ 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
 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
-prevederebbe che quest'ultimo venga risolto e che il collegamento sia
-effettuato rispetto al file cui esso punta, e che venga riportato un errore
-qualora questo non esista o non sia un file. Questo era anche il comportamento
-iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
-  precisione il comportamento era quello previsto dallo standard POSIX fino al
-  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
+\textit{hard link} ad un link simbolico. In questo caso lo standard
+POSIX.1-2001 prevederebbe che quest'ultimo venga risolto e che il collegamento
+sia effettuato rispetto al file cui esso punta, e che venga riportato un
+errore qualora questo non esista o non sia un file. Questo era anche il
+comportamento iniziale di Linux ma a partire dai kernel della serie
+2.0.x\footnote{per la precisione il comportamento era quello previsto dallo
+  standard POSIX fino al 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

   \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
 che non segue più lo standard per cui l'\textit{hard link} viene creato
   \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.
+rispetto al link simbolico, e non al file cui questo punta. La revisione
+POSIX.1-2008 lascia invece il comportamento dipendente dall'implementazione,
+cosa che rende Linux aderente allo standard.

 
 

-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
-riferimento anche ad un file non esistente o a una directory, per i quali
+La ragione di questa differenza rispetto al vecchio standard, presente anche
+in altri sistemi unix-like, sono dovute al fatto che un link simbolico può
+fare riferimento anche ad un file non esistente o a una directory, per i quali

 l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
 link simbolico è stata ritenuta una scelta scorretta nella progettazione
 dell'interfaccia.  Infatti se non ci fosse il comportamento adottato da Linux
 l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
 link simbolico è stata ritenuta una scelta scorretta nella progettazione
 dell'interfaccia.  Infatti se non ci fosse il comportamento adottato da Linux


@@ -1385,10 +1417,10 @@ destinazione. Invece evitando di seguire lo standard l'operazione diventa
 possibile, ed anche il comportamento della funzione risulta molto più
 comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
   link} rispetto alla destinazione di un link simbolico è sempre possibile
 possibile, ed anche il comportamento della funzione risulta molto più
 comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
   link} rispetto alla destinazione di un link simbolico è sempre possibile

-farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
-  standard possa causare problemi, come nell'esempio descritto nell'articolo
-  citato nella nota precedente, a programmi che non si aspettano questa
-  differenza rispetto allo standard POSIX.}
+farlo direttamente.\footnote{ciò non toglie che questo comportamento possa
+  causare problemi, come nell'esempio descritto nell'articolo citato nella
+  nota precedente, a programmi che non si aspettano questa differenza rispetto
+  allo standard POSIX.}

 
 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
 
 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


@@ -2171,7 +2203,7 @@ volte che si ripete la lettura di una voce sullo stesso \textit{directory
   stream}.
 
 Di questa funzione esiste anche una versione \index{funzioni!rientranti}
   stream}.
 
 Di questa funzione esiste anche una versione \index{funzioni!rientranti}

-rientrante, \func{readdir\_r},\footnote{per usarla è necessario definire una
+rientrante, \funcd{readdir\_r},\footnote{per usarla è necessario definire una

   qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
   \macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
   \macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
   qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
   \macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
   \macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e


@@ -2343,12 +2375,12 @@ La funzione legge tutte le voci della directory indicata dall'argomento
 \struct{dirent}) come argomento della funzione di selezione specificata da
 \param{filter}; se questa ritorna un valore diverso da zero il puntatore viene
 inserito in un vettore che viene allocato dinamicamente con \func{malloc}.
 \struct{dirent}) come argomento della funzione di selezione specificata da
 \param{filter}; se questa ritorna un valore diverso da zero il puntatore viene
 inserito in un vettore che viene allocato dinamicamente con \func{malloc}.

-Qualora si specifichi un valore \val{NULL} per l'argomento \func{filter} non
+Qualora si specifichi un valore \val{NULL} per l'argomento \param{filter} non

 viene fatta nessuna selezione e si ottengono tutte le voci presenti.
 
 viene fatta nessuna selezione e si ottengono tutte le voci presenti.
 

-Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
-del riordinamento possono essere personalizzate usando la funzione
-\param{compar} come criterio di ordinamento di \func{qsort}, la funzione
+Le voci selezionate possono essere riordinate tramite \funcm{qsort}, le
+modalità del riordinamento possono essere personalizzate usando la funzione
+\param{compar} come criterio di ordinamento di \funcm{qsort}, la funzione

 prende come argomenti le due strutture \struct{dirent} da confrontare
 restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
 alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
 prende come argomenti le due strutture \struct{dirent} da confrontare
 restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
 alla fine l'indirizzo della lista ordinata dei puntatori alle strutture


@@ -2385,7 +2417,7 @@ La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
 campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
 estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
   l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
 campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
 estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
   l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando

-  \func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
+  \funcm{strcoll} al posto di \funcm{strcmp}.} anche \func{versionsort}, che

 ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
 \texttt{file10} viene comunque dopo \texttt{file4}.)
 
 ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
 \texttt{file10} viene comunque dopo \texttt{file4}.)
 


@@ -2483,9 +2515,9 @@ chiusura (\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo
 
 Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
 directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
 
 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ù
+  della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più

   precisamente nel campo \texttt{pwd} della sotto-struttura
   precisamente nel campo \texttt{pwd} della sotto-struttura

-  \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
+  \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o

 \textsl{directory di lavoro} (in inglese \textit{current working directory}).
 La directory di lavoro è quella da cui si parte quando un
 \itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
 \textsl{directory di lavoro} (in inglese \textit{current working directory}).
 La directory di lavoro è quella da cui si parte quando un
 \itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,


@@ -2640,7 +2672,7 @@ specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
   \headfile{stdio.h}.}
 
 Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
   \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.
+\funcm{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.

 Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
 il file esplicitamente, il suo prototipo è:
 \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
 Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
 il file esplicitamente, il suo prototipo è:
 \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}


@@ -3409,7 +3441,7 @@ Queste due funzioni sono una estensione definita in una recente revisione
 dello standard POSIX (la POSIX.1-2008); sono state introdotte a partire dal
 kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
 2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta
 dello standard POSIX (la POSIX.1-2008); sono state introdotte a partire dal
 kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
 2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta

-  la funzione \func{futimesat} seguendo una bozza della revisione dello
+  la funzione \funcm{futimesat} seguendo una bozza della revisione dello

   standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
   stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
   essere più utilizzata: pertanto non la tratteremo.} La prima è
   standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
   stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
   essere più utilizzata: pertanto non la tratteremo.} La prima è


@@ -3971,8 +4003,8 @@ lettura), che però può fornire un valore che è lo stesso per tutti e tre i
 permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
 $222$ nel secondo). Per questo motivo il sistema associa ad ogni
 processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
 permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
 $222$ nel secondo). Per questo motivo il sistema associa ad ogni
 processo\footnote{è infatti contenuta nel campo \var{umask} della struttura

-  \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.}  una maschera di
-bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+  \kstruct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.}  una maschera
+di bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che

 alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
 bit indicati nella maschera vengono infatti cancellati dai permessi quando un
 nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
 alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
 bit indicati nella maschera vengono infatti cancellati dai permessi quando un
 nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche


@@ -5317,7 +5349,7 @@ essere solo impostate qualora \param{path} indichi una directory. Inoltre
 perché la funzione abbia successo la ACL dovrà essere valida, e contenere
 tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL
 vuota per cancellare la ACL di default associata a
 perché la funzione abbia successo la ACL dovrà essere valida, e contenere
 tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL
 vuota per cancellare la ACL di default associata a

-\func{path}.\footnote{questo però è una estensione della implementazione delle
+\param{path}.\footnote{questo però è una estensione della implementazione delle

   ACL di Linux, la bozza di standard POSIX.1e prevedeva l'uso della apposita
   funzione \funcd{acl\_delete\_def\_file}, che prende come unico argomento il
   \textit{pathname} della directory di cui si vuole cancellare l'ACL di
   ACL di Linux, la bozza di standard POSIX.1e prevedeva l'uso della apposita
   funzione \funcd{acl\_delete\_def\_file}, che prende come unico argomento il
   \textit{pathname} della directory di cui si vuole cancellare l'ACL di


@@ -7047,7 +7079,7 @@ questa sezione.
 Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
 \index{directory~di~lavoro} directory di lavoro, ha anche una directory
 \textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
 Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
 \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
+  \var{pwd} e \var{root}) di \kstruct{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
   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