X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=fileadv.tex;h=240c0582524d1d7eab149b336df1cde0276a4106;hb=8fb2646cc3cba04b2a7c581056feb9bf1fff0f8b;hp=b35d14c1e4a5be77613082b59797b32fe8793ee4;hpb=ffb12837c5ed8ccc095bc9c88349cd19b5e6b472;p=gapil.git

diff --git a/fileadv.tex b/fileadv.tex
index b35d14c..240c058 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -244,14 +244,14 @@ possono avere due processi diversi che aprono lo stesso file.
 
 La richiesta di un \textit{file lock} prevede una scansione della lista per
 determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
-un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
+un nuovo elemento.\footnote{cioè una nuova struttura \kstruct{file\_lock}.}
 Nel caso dei blocchi creati con \func{flock} la semantica della funzione
 prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un
 \textit{file lock} quanto piuttosto degli ulteriori riferimenti allo
 stesso. Questo viene realizzato dal kernel secondo lo schema di
 fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock}
 un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
-  \struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
+  \kstruct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
   con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file
   table} da cui si è richiesto il blocco, che così ne identifica il titolare.
 
@@ -460,7 +460,7 @@ sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
 kernel. Lo schema delle strutture utilizzate è riportato in
 fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
-  sono evidenziati solo i campi di \struct{file\_lock} significativi per la
+  sono evidenziati solo i campi di \kstruct{file\_lock} significativi per la
   semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
   \ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene
   bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
@@ -481,7 +481,7 @@ voce nella \itindex{file~table} \textit{file table}, ma con il valore del
 Quando si richiede un \textit{file lock} il kernel effettua una scansione di
 tutti i blocchi presenti sul file\footnote{scandisce cioè la
   \itindex{linked~list} \textit{linked list} delle strutture
-  \struct{file\_lock}, scartando automaticamente quelle per cui
+  \kstruct{file\_lock}, scartando automaticamente quelle per cui
   \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
   ben separate.}  per verificare se la regione richiesta non si sovrappone ad
 una già bloccata, in caso affermativo decide in base al tipo di blocco, in
@@ -835,7 +835,7 @@ bloccare completamente un server NFS richiedendo una lettura su un file su cui
 è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
   locking} è di norma disabilitata, e deve essere attivata filesystem per
 filesystem in fase di montaggio (specificando l'apposita opzione di
-\func{mount} riportata in sez.~\ref{sec:sys_file_config}), o con l'opzione
+\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}), o con l'opzione
 \code{-o mand} per il comando omonimo).
 
 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
@@ -901,7 +901,7 @@ possibilità di modificare il file.
 
 Uno dei problemi che si presentano quando si deve operare contemporaneamente
 su molti file usando le funzioni illustrate in
-cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
+sez.~\ref{sec:file_unix_interface} e sez.~\ref{sec:files_std_interface} è che
 si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
 essere disponibile. L'\textit{I/O multiplexing} nasce risposta a questo
 problema. In questa sezione forniremo una introduzione a questa problematica
@@ -1547,7 +1547,7 @@ maschera binaria in fase di creazione del file descriptor. Al momento l'unico
 valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC},
 che consente di impostare in maniera atomica sul file descriptor il flag di
 \itindex{close-on-exec} \textit{close-on-exec} (si veda il significato di
-\const{O\_CLOEXEC} in tab.~\ref{tab:file_open_flags}), senza che sia
+\const{O\_CLOEXEC} in sez.~\ref{sec:file_open}), senza che sia
 necessaria una successiva chiamata a \func{fcntl}.
 
 Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
@@ -1714,12 +1714,14 @@ l'insieme dei file descriptor da tenere sotto controllo tramite un certo
   chiamate devono essere ripetute per ciascun file descriptor, incorrendo in
   una perdita di prestazioni qualora il numero di file descriptor sia molto
   grande; per questo è stato proposto di introdurre come estensione una
-  funzione \func{epoll\_ctlv} che consenta di effettuare con una sola chiamata
+  funzione \code{epoll\_ctlv} che consenta di effettuare con una sola chiamata
   le impostazioni per un blocco di file descriptor.} L'uso di
 \const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di
 osservazione di un file descriptor che sia già stato aggiunto alla lista di
 osservazione.
 
+% TODO verificare se prima o poi epoll_ctlv verrà introdotta
+
 Le impostazioni di default prevedono che la notifica degli eventi richiesti
 sia effettuata in modalità \textit{level triggered}, a meno che sul file
 descriptor non si sia impostata la modalità \textit{edge triggered},
@@ -1933,7 +1935,7 @@ descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è
   versioni diverse della \textit{system call}; una prima versione,
   \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
   \acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
-  versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
+  versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
   che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
   argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
   maschera dei segnali, il cui valore viene impostato automaticamente dalle
@@ -2205,7 +2207,7 @@ ritorno della funzione \func{read} è negativo, uscendo dal programma
 
 In presenza di dati invece il programma proseguirà l'esecuzione stampando
 (\texttt{\small 19--20}) il nome del segnale ottenuto all'interno della
-struttura \const{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
+struttura \struct{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
   stampa si è usato il vettore \var{sig\_names} a ciascun elemento del quale
   corrisponde il nome del segnale avente il numero corrispondente, la cui
   definizione si è omessa dal codice di fig.~\ref{fig:fiforeporter_code_init}
@@ -3167,15 +3169,15 @@ così all'applicazione di collegare la corrispondente coppia di eventi
 Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
 l'evento è relativo ad un file presente in una directory posta sotto
 osservazione, in tal caso essi contengono rispettivamente il nome del file
-(come pathname relativo alla directory osservata) e la relativa dimensione in
-byte. Il campo \var{name} viene sempre restituito come stringa terminata da
-NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di
-allineamento del risultato, ed il valore di \var{len} corrisponde al totale
-della dimensione di \var{name}, zeri aggiuntivi compresi. La stringa con il
-nome del file viene restituita nella lettura subito dopo la struttura
-\struct{inotify\_event}; questo significa che le dimensioni di ciascun evento
-di \textit{inotify} saranno pari a \code{sizeof(\struct{inotify\_event}) +
-  len}.
+(come \itindsub{pathname}{relativo} \textit{pathname} relativo alla directory
+osservata) e la relativa dimensione in byte. Il campo \var{name} viene sempre
+restituito come stringa terminata da NUL, con uno o più zeri di terminazione,
+a seconda di eventuali necessità di allineamento del risultato, ed il valore
+di \var{len} corrisponde al totale della dimensione di \var{name}, zeri
+aggiuntivi compresi. La stringa con il nome del file viene restituita nella
+lettura subito dopo la struttura \struct{inotify\_event}; questo significa che
+le dimensioni di ciascun evento di \textit{inotify} saranno pari a
+\code{sizeof(\struct{inotify\_event}) + len}.
 
 Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
 semplice programma che permette di mettere sotto osservazione uno o più file e
@@ -3651,9 +3653,10 @@ per il campo \var{aio\_sigevent} di \struct{aiocb}.
 Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
   asincrono}, esistono altre funzioni che implementano delle modalità di
 accesso ai file più evolute rispetto alle normali funzioni di lettura e
-scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
-sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
-  memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O avanzato.
+scrittura che abbiamo esaminato in sez.~\ref{sec:file_unix_interface}. In
+questa sezione allora prenderemo in esame le interfacce per l'\textsl{I/O
+  mappato in memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O
+avanzato.
 
 
 \subsection{File mappati in memoria}
@@ -3661,7 +3664,7 @@ sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
 
 \itindbeg{memory~mapping}
 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
-rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
+rispetto a quella classica vista in sez.~\ref{sec:file_unix_interface}, è il
 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
 \textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
@@ -3973,12 +3976,12 @@ consentita la scrittura sul file (cioè per un file mappato con
 o in corrispondenza di una eventuale \func{msync}.
 
 Dato per i file mappati in memoria le operazioni di I/O sono gestite
-direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere
+direttamente dalla \index{memoria~virtuale} memoria virtuale, occorre essere
 consapevoli delle interazioni che possono esserci con operazioni effettuate
-con l'interfaccia standard dei file di cap.~\ref{cha:file_unix_interface}. Il
-problema è che una volta che si è mappato un file, le operazioni di lettura e
-scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
-autonoma dal sistema della memoria virtuale.
+con l'interfaccia dei file di sez.~\ref{sec:file_unix_interface}. Il problema
+è che una volta che si è mappato un file, le operazioni di lettura e scrittura
+saranno eseguite sulla memoria, e riportate su disco in maniera autonoma dal
+sistema della memoria virtuale.
 
 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
 potranno essere visibili o meno a seconda del momento in cui la memoria
@@ -4504,7 +4507,7 @@ ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
 Si tenga presente infine che queste funzioni operano sui file con
 l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
 l'interfaccia classica dei \textit{file stream} di
-cap.~\ref{cha:files_std_interface}; a causa delle bufferizzazioni interne di
+sez.~\ref{sec:files_std_interface}; a causa delle bufferizzazioni interne di
 quest'ultima infatti si potrebbero avere risultati indefiniti e non
 corrispondenti a quanto aspettato.
 
@@ -4514,7 +4517,7 @@ maniera atomica a partire da un certa posizione sul file. Per questo motivo a
 partire dal kernel 2.6.30 sono state introdotte anche per l'\textsl{I/O
   vettorizzato} le analoghe delle funzioni \func{pread} e \func{pwrite} (vedi
 sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
-\funcd{preadv} e \func{pwritev} ed i rispettivi prototipi sono:\footnote{le
+\funcd{preadv} e \funcd{pwritev} ed i rispettivi prototipi sono:\footnote{le
   due funzioni sono analoghe alle omonime presenti in BSD; le \textit{system
     call} usate da Linux (introdotte a partire dalla versione 2.6.30)
   utilizzano degli argomenti diversi per problemi collegati al formato a 64
@@ -4737,7 +4740,7 @@ definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
       \func{splice}, oppure nessuno dei file descriptor è una pipe, oppure si
       è dato un valore a \param{off\_in} o \param{off\_out} ma il
       corrispondente file è un dispositivo che non supporta la funzione
-      \func{seek}.
+      \func{lseek}.
     \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
       richiesta.
     \item[\errcode{ESPIPE}] o \param{off\_in} o \param{off\_out} non sono
@@ -5026,7 +5029,7 @@ La funzione copia \param{len} byte del contenuto di una \textit{pipe} su di
 un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
 sorgente e \param{fd\_out} il capo in scrittura della \textit{pipe}
 destinazione; a differenza di quanto avviene con \func{read} i dati letti con
-\func{tee} da \func{fd\_in} non vengono \textsl{consumati} e restano
+\func{tee} da \param{fd\_in} non vengono \textsl{consumati} e restano
 disponibili sulla \textit{pipe} per una successiva lettura (di nuovo per il
 comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al
 momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio