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
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
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
\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} \\
\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}
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
projects / gapil.git / blobdiff