X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileio.tex;h=bc3edfbf7c760aad06e36d0de0bad7a732f06d02;hp=e6a904f1cced90f6b42c354db6b11b22f053b0fe;hb=95289c5b54de712ed5b7119cdd7bb8df93a281ef;hpb=aeebfb3d7a3482d1255aeb318d01bbdd92829f4c

diff --git a/fileio.tex b/fileio.tex
index e6a904f..bc3edfb 100644
--- a/fileio.tex
+++ b/fileio.tex
@@ -1740,19 +1740,18 @@ successiva apertura.
 
 Inoltre, come già accennato, la directory di lavoro corrente è una proprietà
 associata al singolo processo; questo significa che quando si lavora con i
-\textit{thread} questa sarà sempre la stessa per tutti \textit{thread}, ed un
-cambiamento di directory di lavoro effettuato all'interno di un \textit{thread}
-verrà applicato a tutti gli altri. Non esiste quindi con le funzioni classiche
-un modo semplice per far si che i singoli \textit{thread} possano aprire file
-usando una propria directory di lavoro per risolvere i \textit{pathname}
-relativi.
+\textit{thread} questa è la stessa per tutti, per cui se la si cambia
+all'interno di un \textit{thread} il cambiamento varrà anche per tutti gli
+altri. Non esiste quindi con le funzioni classiche un modo semplice per far sì
+che i singoli \textit{thread} possano aprire file usando una propria directory
+per risolvere i \textit{pathname} relativi.
 
 Per risolvere questi problemi, riprendendo una interfaccia già presente in
 Solaris, a fianco delle normali funzioni che operano sui file (come
 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
-funzioni di sistema, chiamate in maniera generica ``\textit{at-functions}'' in
-quanto quasi tutte sono contraddistinte dal suffisso \texttt{at}, che
-permettono l'apertura di un file (o le rispettive altre operazioni) usando un
+funzioni di sistema, chiamate genericamente ``\textit{at-functions}'' in
+quanto usualmente contraddistinte dal suffisso \texttt{at}, che permettono
+l'apertura di un file (o le rispettive altre operazioni) usando un
 \textit{pathname} relativo ad una directory
 specificata.\footnote{l'introduzione è avvenuta su proposta dello sviluppatore
   principale della \acr{glibc} Urlich Drepper e le corrispondenti
@@ -1821,15 +1820,14 @@ esame la nuova funzione di sistema \funcd{openat}, il cui prototipo è:
 
 Il comportamento di \func{openat} è del tutto analogo a quello di \func{open},
 con la sola eccezione del fatto che se per l'argomento \param{pathname} si
-utilizza un \textit{pathname} relativo questo, sarà risolto rispetto alla
-directory indicata da \param{dirfd}. Qualora invece si usi un
+utilizza un \textit{pathname} relativo questo sarà risolto rispetto alla
+directory indicata da \param{dirfd}; qualora invece si usi un
 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
-se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD}, la
+se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD} la
 risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
-processo. Si tenga presente però che questa costante, come le altre costanti
-\texttt{AT\_*}, è definita in \headfile{fcntl.h}, pertanto se la si vuole
-usare occorrerà includere comunque questo file, anche per le funzioni che non
-sono definite in esso.
+processo. Questa, come le altre costanti \texttt{AT\_*}, è definita in
+\headfile{fcntl.h}, per cui per usarla occorrerà includere comunque questo
+file, anche per le funzioni che non sono definite in esso.
 
 Così come il comportamento, anche i valori di ritorno e le condizioni di
 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
@@ -1837,8 +1835,8 @@ errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
 particolare si avrà un errore di \errcode{EBADF} se esso non è un file
 descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa
 riferimento ad una directory, tranne il caso in cui si sia specificato un
-\textit{pathname} assoluto, nel qual caso, come detto, il valore
-di \param{dirfd} sarà completamente ignorato.
+\textit{pathname} assoluto, nel qual caso, come detto, il valore di
+\param{dirfd} sarà completamente ignorato.
 
 \begin{table}[htb]
   \centering
@@ -1854,14 +1852,14 @@ di \param{dirfd} sarà completamente ignorato.
      \func{fchownat}  &$\bullet$&\func{chown},\func{lchown}\\
      \funcm{fstatat}  &$\bullet$&\func{stat},\func{lstat}  \\
      \funcm{futimesat}& --      & obsoleta  \\
-     \func{linkat}    &$\bullet$\footnotemark&\func{link}    \\
+     \func{linkat}    &$\bullet$&\func{link}    \\
      \funcm{mkdirat}  & --      &\func{mkdir}   \\
      \funcm{mkfifoat} & --      &\func{mkfifo}  \\
      \funcm{mknodat}  & --      &\func{mknod}   \\
      \func{openat}    & --      &\func{open}    \\
      \funcm{readlinkat}& --     &\func{readlink}\\
      \funcm{renameat} & --      &\func{rename}  \\
-     \funcm{renameat2}& --      &\func{rename}  \\
+     \funcm{renameat2}\footnotemark& -- &\func{rename}  \\
      \funcm{scandirat}& --      &\func{scandir}  \\
      \funcm{statx}    &$\bullet$&\func{stat}  \\
      \funcm{symlinkat}& --      &\func{symlink} \\
@@ -1874,35 +1872,53 @@ di \param{dirfd} sarà completamente ignorato.
   \label{tab:file_atfunc_corr}
 \end{table}
 
-\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
-  utilizzabile solo a partire dal kernel 2.6.18.}
+\footnotetext{anche se la funzione ha un argomento \param{flags} questo
+  attiene a funzionalità specifiche della stessa e non all'uso generico fatto
+  nelle altre \textit{at-functions}, pertanto lo si è indicato come assente.}
 
 In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
 con questa nuova interfaccia, con a fianco la corrispondente funzione
-classica. La gran parte di queste seguono la convenzione appena vista per
-\func{openat}, in cui agli argomenti della corrispondente funzione classica
-viene anteposto l'argomento \param{dirfd}, ed hanno per il resto un
-comportamento identico e non staremo pertanto a trattarle una per una. Per una
-parte di queste, indicate dal contenuto della omonima colonna di
+classica. Tutte seguono la convenzione appena vista per \func{openat}, in cui
+agli argomenti della funzione classica viene anteposto l'argomento
+\param{dirfd}. Per alcune, indicate dal contenuto della omonima colonna di
 tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è prevista
-anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
+anche l'aggiunta di un argomento finale, \param{flags}, che è stato introdotto
+per fornire un meccanismo con cui modificarne il comportamento.
 
-Per le funzioni che lo prevedono l'ulteriore argomento \param{flag} è stato
-introdotto per fornire un meccanismo con cui modificarne il comportamento.  Il
-solo caso generale, valido per tutte, è quello in cui si sta operando su un
+Buona parte di queste funzioni hanno un comportamento identico alla
+corrispondente funzione ordinaria, pertanto non le tratteremo esplicitamente,
+vale per loro quanto detto con \func{openat} per l'uso del nuovo argomento
+\param{dirfd}. 
+
+
+
+Il solo caso generale, valido per tutte, è quello in cui si sta operando su un
 collegamento simbolico, e si vuole poter scegliere se far agire la funzione
 direttamente sullo stesso o sul file da esso referenziato. Ma oltre a questo
 caso generico, l'argomento viene usato per controllare ulteriori
-caratteristiche di funzionamento, dipendenti dalla funzione stessa, per cui
-deve essere comunque passato come maschera binaria ed impostato usando i
-valori delle appropriate costanti \texttt{AT\_*}, definite in
+caratteristiche di funzionamento, dipendenti dalla funzione stessa; per questo
+motivo deve essere comunque passato come maschera binaria ed impostato usando
+i valori delle appropriate costanti \texttt{AT\_*}, definite in
 \headfile{fcntl.h}.
 
 %% Verificare uso generico di AT_EMPTY_XX
 
-Come esempio delle funzioni che lo utilizzano solo nel caso generico possiamo
-considerare \funcd{fchownat}, che può essere usata per sostituire sia
-\func{chown} che \func{lchown}; il suo prototipo è:
+% TODO: trattare i nuovi AT_flags quando e se arriveranno, vedi
+% https://lwn.net/Articles/767547/ 
+
+Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
+\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
+un meccanismo con cui modificarne il comportamento nel caso si stia operando
+su un collegamento simbolico, così da poter scegliere se far agire la funzione
+direttamente sullo stesso o sul file da esso referenziato. Dato che in certi
+casi esso può fornire ulteriori indicazioni per modificare il comportamento
+delle funzioni, \param{flags} deve comunque essere passato come maschera
+binaria, ed impostato usando i valori delle appropriate costanti
+\texttt{AT\_*}, definite in \headfile{fcntl.h}.
+
+Come esempio di questo secondo tipo di funzioni possiamo considerare
+\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
+che \func{lchown}; il suo prototipo è:
 
 \begin{funcproto}{
 \fhead{unistd.h}
@@ -1996,15 +2012,21 @@ se \param{flags} è una maschera binaria, essendo \const{AT\_REMOVEDIR} l'unico
 flag disponibile per questa funzione, lo si può assegnare direttamente.
 
 Infine una terza funzione, \funcm{linkat}, utilizza in maniera diversa dalle
-altre l'argomento \param{flags}, anche se in questo caso l'utilizzo continua
-ad essere attinente al comportamento con i collegamenti simbolici. Si ricordi
-che su Linux il comportamento di \func{link} è quello di non seguire mai i
+altre l'argomento \param{flags},\footnote{si tenga presente che per questa
+  funzione l'argomento \param{flags} è disponibile ed utilizzabile solo a
+  partire dal kernel 2.6.18.} anche se in questo caso l'utilizzo continua ad
+essere attinente al comportamento con i collegamenti simbolici. Si ricordi che
+su Linux il comportamento di \func{link} è quello di non seguire mai i
 collegamenti simbolici, pertanto l'uso ordinario dell'argomento parrebbe in
 questo caso essere inutile.  A partire dal kernel 2.6.18 invece però è stato
 aggiunta per questa funzione la possibilità di usare il valore
 \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i collegamenti
 simbolici.
 
+
+
+
+
 Dato che questo è il comportamento adottato per un valore nullo
 di \param{flags} da tutte le altre funzioni, \func{linkat} è l'unica per cui
 può essere usato esplicitamente questo valore e per la quale non ha senso