X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=55ccf9ac8760b2c114aaa87906b55b9d6ef8ed38;hp=4e7ead42692035936712a5559138060161d775ee;hb=c56e6721f8ea10764f29995600f1506e72209423;hpb=04a547df13e4c672d95e1060e1ada9ae2e1fcb2f

diff --git a/filedir.tex b/filedir.tex
index 4e7ead4..55ccf9a 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -107,7 +107,7 @@ restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
   entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
 la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
 \textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
-vedremo a breve è l'oggetto usato dal kernel per identificare un un
+vedremo a breve è l'oggetto usato dal kernel per identificare un
 file.\footnote{in questo caso si parla di file come di un qualunque oggetto
   generico che sta sul filesystem e non dell'oggetto file del VFS cui
   accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
@@ -232,7 +232,7 @@ tab.~\ref{tab:file_inode_operations} le più rilevanti.
     \hline
   \end{tabular}
   \caption{Le principali operazioni sugli \textit{inode} definite tramite
-    \kstruct{inode\_operation}.} 
+    \kstructd{inode\_operation}.} 
   \label{tab:file_inode_operations}
 \end{table}
 
@@ -328,7 +328,7 @@ tab.~\ref{tab:file_file_operations} le più significative.
                              sez.~\ref{sec:file_asyncronous_io}) sul file.\\
     \hline
   \end{tabular}
-  \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.}
+  \caption{Operazioni sui file definite tramite \kstructd{file\_operation}.}
   \label{tab:file_file_operations}
 \end{table}
 
@@ -698,7 +698,7 @@ indietro al kernel ad ogni scrittura.\footnote{costituiscono quindi un
 
 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
+riportate nel file \procfilem{/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.
@@ -1248,7 +1248,8 @@ del filesystem stesso.
   \label{fig:sys_statfs}
 \end{figure}
 
-\conffilebeg{/etc/mtab}
+\conffilebeg{/etc/mtab} 
+
 La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
 file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
   \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
@@ -1257,9 +1258,9 @@ ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
   \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.
+leggere il contenuto di questi file in opportune strutture \structd{fstab} e
+\structd{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
@@ -1276,6 +1277,7 @@ 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 della \acr{glibc}
 \cite{GlibcMan} per la documentazione completa.
+
 \conffileend{/etc/mtab}
 
 % TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
@@ -2003,7 +2005,7 @@ sez.~\ref{sec:files_std_interface}. La prima funzione di questa interfaccia è
 \end{funcproto}
 
 La funzione apre un \textit{directory stream} per la directory
-\param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
+\param{dirname}, ritornando il puntatore ad un oggetto di tipo \typed{DIR} (che
 è il tipo opaco usato dalle librerie per gestire i \textit{directory stream})
 da usare per tutte le operazioni successive, la funzione inoltre posiziona lo
 \textit{stream} sulla prima voce contenuta nella directory.
@@ -2747,8 +2749,8 @@ comportato il fatto che \type{dev\_t} è diventato un 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 \headfile{sys/sysmacros.h},\footnote{se si usa
-  la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
+Le macro sono definite nel file \headfiled{sys/sysmacros.h},\footnote{se si
+  usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
   versioni specifiche di questa libreria, \macrod{gnu\_dev\_major},
   \macrod{gnu\_dev\_minor} e \macrod{gnu\_dev\_makedev} che si possono usare
   direttamente, al costo di una minore portabilità.} che viene automaticamente
@@ -3100,7 +3102,7 @@ informazioni relative ad esso e non al file a cui fa riferimento. Infine
 tramite il suo file descriptor \param{filedes}.
 
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfiled{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
@@ -3122,7 +3124,7 @@ sez.~\ref{sec:file_file_times}).
 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 \headfile{sys/types.h},
-con l'eccezione di \type{blksize\_t} e \type{blkcnt\_t} che sono nuovi tipi
+con l'eccezione di \typed{blksize\_t} e \typed{blkcnt\_t} che sono nuovi tipi
 introdotti per rendersi indipendenti dalla piattaforma. 
 
 Benché la descrizione dei commenti di fig.~\ref{fig:file_stat_struct} sia
@@ -4345,8 +4347,8 @@ filename e su un file descriptor, i loro prototipi sono:
 
 Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
 variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
-tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi sui
-file.
+tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi
+sui file.
 
 \begin{table}[!htb]
   \centering
@@ -5332,11 +5334,11 @@ queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
 
 La funzione alloca ed inizializza un'area di memoria che verrà usata per
 mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
-voci. La funzione ritorna un valore di tipo \type{acl\_t} da usare in tutte le
+voci. La funzione ritorna un valore di tipo \typed{acl\_t} da usare in tutte le
 altre funzioni che operano sulla ACL. La funzione si limita alla allocazione
 iniziale e non inserisce nessun valore nella ACL che resta vuota. 
 
-Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
+Si tenga presente che pur essendo \typed{acl\_t} un tipo opaco che identifica
 ``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
 che un puntatore all'area di memoria allocata per i dati richiesti. Pertanto
 in caso di fallimento verrà restituito un puntatore nullo di tipo
@@ -5471,7 +5473,7 @@ tramite un file descriptor usando \func{acl\_get\_fd} o con un
 funzione, che può richiedere anche la ACL relativa ad una directory, il
 secondo argomento \param{type} consente di specificare se si vuole ottenere la
 ACL di default o quella di accesso. Questo argomento deve essere di tipo
-\type{acl\_type\_t} e può assumere solo i due valori riportati in
+\typed{acl\_type\_t} e può assumere solo i due valori riportati in
 tab.~\ref{tab:acl_type}.
 
 \begin{table}[htb]
@@ -5849,7 +5851,7 @@ manuale.
 
 Se si vuole operare direttamente sui contenuti di un oggetto di tipo
 \type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
-opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+opportuni puntatori di tipo \typed{acl\_entry\_t}, che possono essere ottenuti
 dalla funzione \funcm{acl\_get\_entry} (per una voce esistente) o dalla
 funzione \funcm{acl\_create\_entry} per una voce da aggiungere. Nel caso della
 prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
@@ -6433,7 +6435,7 @@ cui a ciascun processo sono stati associati tre distinti insiemi di
 \textit{inheritable} ed \textit{effective}. Questi insiemi vengono mantenuti
 in forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come
   i vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
-  \struct{task\_struct} di ciascun processo (vedi
+  \texttt{task\_struct} di ciascun processo (vedi
   fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
   \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
   \texttt{kernel\_cap\_t}; questo era, fino al kernel 2.6.25 definito come
@@ -6532,7 +6534,7 @@ tutti, compreso l'amministratore.\footnote{la qual cosa, visto il default
 Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
 è diventato una proprietà di ciascun processo, che viene propagata invariata
 sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
-\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+\sysctlfilem{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
 ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
 presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}). 
 
@@ -7048,7 +7050,7 @@ 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
-\headfile{sys/capability.h}) requisito che non risulta più
+\headfiled{sys/capability.h}) requisito che non risulta più
 presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
   necessario.}
 
@@ -7057,7 +7059,7 @@ presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
   \centering
   \begin{minipage}[c]{0.8\textwidth}
     \includestruct{listati/cap_user_header_t.h}
-  \end{minipage} 
+  \end{minipage}
   \normalsize 
   \caption{Definizione delle strutture a cui fanno riferimento i puntatori
     \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
@@ -7118,7 +7120,7 @@ della suddetta libreria attraverso l'opzione \texttt{-lcap}.
 
 Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
 dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
-\type{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
+\typed{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
 \textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
   una struttura interna utilizzata dalle librerie, i cui campi non devono mai
   essere acceduti direttamente.} in sono memorizzati tutti i dati delle
@@ -7261,7 +7263,7 @@ tab.~\ref{tab:cap_set_identifier}.
     \constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
     \hline
   \end{tabular}
-  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+  \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
     identifica gli insiemi delle \textit{capabilities}.}
   \label{tab:cap_set_identifier}
 \end{table}
@@ -7333,7 +7335,7 @@ In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
 indica su quale dei tre insiemi si intende operare, sempre con i valori di
 tab.~\ref{tab:cap_set_identifier}.  La capacità che si intende controllare o
 impostare invece deve essere specificata attraverso una variabile di tipo
-\type{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
+\typed{cap\_value\_t}, che può 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
@@ -7358,7 +7360,7 @@ tab.~\ref{tab:cap_value_type}.
     \constd{CAP\_SET}  & La capacità è impostata.\\
     \hline
   \end{tabular}
-  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+  \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
     indica lo stato di una capacità.}
   \label{tab:cap_value_type}
 \end{table}