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

diff --git a/fileadv.tex b/fileadv.tex
index b35d14c..4c063d3 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
@@ -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
@@ -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
@@ -4514,7 +4516,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 +4739,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 +5028,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