driver, in cui si richiede la verifica della capacità di accesso in lettura
e scrittura ma viene restituito un file descriptor che non può essere letto
o scritto, ma solo usato con una \func{ioctl} (vedi
- sez.~\ref{sec:file_ioctl}).}
+ sez.~\ref{sec:file_fcntl_ioctl}).}
La modalità di accesso deve sempre essere specificata quando si apre un file,
il valore indicato in \param{flags} viene salvato nei
\itindex{file~status~flag} \textit{file status flags}, e può essere riletto
-con \func{fcntl} (vedi sez.~\ref{sec:file_fcntl}), il relativo valore può
-essere poi ottenuto un AND aritmetico della maschera binaria
+con \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}), il relativo valore
+può essere poi ottenuto un AND aritmetico della maschera binaria
\const{O\_ACCMODE}, ma non può essere modificato. Nella \acr{glibc} sono
definite inoltre \const{O\_READ} come sinonimo di \const{O\_RDONLY} e
\const{O\_WRITE} come sinonimo di \const{O\_WRONLY}.\footnote{si tratta di
\func{open} nel momento in viene eseguita per aprire un file. Questi flag
hanno effetto solo nella chiamata della funzione, non sono memorizzati fra i
\itindex{file~status~flag} \textit{file status flags} e non possono essere
-riletti da \func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
+riletti da \func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).
\begin{table}[htb]
\centering
condition} con una sovrapposizione dei dati se
più di un processo scrive allo stesso tempo. \\
\const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
- sez.~\ref{sec:file_asyncronous_io}). Quando è
+ sez.~\ref{sec:signal_driven_io}). Quando è
impostato viene generato il segnale \signal{SIGIO}
tutte le volte che il file è pronto per le
operazioni di lettura o scrittura. Questo flag si
che si potrebbe verificare con i \textit{thread}
fra l'apertura del file e l'impostazione della
suddetta modalità con \func{fcntl} (vedi
- sez.~\ref{sec:file_fcntl}).\\
+ sez.~\ref{sec:file_fcntl_ioctl}).\\
\const{O\_DIRECT} & Esegue l'I/O direttamente dalla memoria in
\textit{user space} in maniera sincrona, in modo da
scavalcare i meccanismi di bufferizzazione del
fifo, vedi sez.~\ref{sec:ipc_named_pipe}), o quando
si vuole aprire un file di dispositivo per eseguire
una \func{ioctl} (vedi
- sez.~\ref{sec:file_ioctl}).\\
+ sez.~\ref{sec:file_fcntl_ioctl}).\\
\const{O\_NDELAY} & In Linux è un sinonimo di \const{O\_NONBLOCK}, ma
origina da SVr4, dove però causava il ritorno da
una \func{read} con un valore nullo e non con un
ma possono venire riletti in un secondo tempo con \func{fcntl}, inoltre alcuni
di essi possono anche essere modificati tramite questa funzione, con
conseguente effetto sulle caratteristiche operative che controllano (torneremo
-sull'argomento in sez.~\ref{sec:file_fcntl}).
+sull'argomento in sez.~\ref{sec:file_fcntl_ioctl}).
Il flag \const{O\_ASYNC} (che, per per compatibilità con BSD, si può indicare
anche con la costante \const{FASYNC}) è definito come possibile valore per
l'uso di \func{fcntl}. Per questo motivo, non essendovi nessuna necessità
specifica di definirlo in fase di apertura del file, è sempre opportuno
attivarlo in un secondo tempo con \func{fcntl} (vedi
-sez.~\ref{sec:file_fcntl}).
+sez.~\ref{sec:file_fcntl_ioctl}).
Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
quelle classiche appena esposte. Questo significa che l'uso di questi nuovi
valori non garantisce la mappatura della effettiva allocazione dello spazio
disco di un file, per il quale esiste una specifica operazione di controllo
-(vedi sez.~\ref{sec:file_ioctl}).
+(vedi sez.~\ref{sec:file_fcntl_ioctl}).
Si noti inoltre che in questo caso anche i \itindex{file~status~flag} flag di
stato del file, essendo mantenuti nella struttura \kstruct{file} della
\textit{file table}, vengono condivisi, per cui una modifica degli stessi con
-\func{fcntl} (vedi sez.~\ref{sec:file_fcntl}) si applicherebbe a tutti
+\func{fcntl} (vedi sez.~\ref{sec:file_fcntl_ioctl}) si applicherebbe a tutti
processi che condividono la voce nella \itindex{file~table} \textit{file
table}. Ai file però sono associati anche altri flag, dei quali l'unico
usato al momento è \const{FD\_CLOEXEC}, detti \itindex{file~descriptor~flags}
tenuto presente che nel caso in cui si usi \func{dup} per duplicare un file
descriptor, se questo ha il flag di \textit{close-on-exec}
\itindex{close-on-exec} attivo (vedi sez.~\ref{sec:proc_exec} e
-sez.~\ref{sec:file_fcntl}), questo verrà cancellato nel file descriptor
+sez.~\ref{sec:file_fcntl_ioctl}), questo verrà cancellato nel file descriptor
restituito come copia.
L'uso principale di questa funzione è nella shell per la redirezione dei file
La duplicazione dei file descriptor può essere effettuata anche usando la
funzione di controllo dei file \func{fcntl} (che esamineremo in
-sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
+sez.~\ref{sec:file_fcntl_ioctl}) con il parametro \const{F\_DUPFD}. L'operazione ha
la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
\param{newfd} diventa equivalente a \func{dup}. La sola differenza fra le due
funzioni (a parte la sintassi ed i diversi codici di errore) è che \func{dup2}
\end{funcproto}
I vari standard prevedono che la funzione si limiti a far partire le
-operazioni, ritornando immediatamente; con Linux fin dal kernel 1.3.20 invece
+operazioni, ritornando immediatamente, con Linux fin dal kernel 1.3.20 invece
la funzione aspetta la conclusione delle operazioni di sincronizzazione. Si
tenga presente comunque che questo non dà la garanzia assoluta che i dati
siano integri dopo la chiamata, l'hardware dei dischi è in genere dotato di un
La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
esplicitamente lo scarico dei dati su disco, un tempo era invocata da un
apposito demone di sistema (in genere chiamato \cmd{update}) che eseguiva lo
-scarico dei dati ad intervalli di tempo fissi, ad esempio il valore
-tradizionale usato da BSD era di 30 secondi, mentre su Linux il valore
-utilizzato è di 5 secondi.
-
-Con le nuove versioni del kernel le operazioni di scarico periodico dei dati
-su disco vengono gestite direttamente dal sistema della memoria virtuale,
-attraverso opportuni \textit{task} interni al kernel il cui comportamento può
-essere controllato attraverso il file \sysctlfile{vm/bdflush}. Per il
-significato dei valori si può leggere la documentazione allegata ai sorgenti
-del kernel nel file \file{Documentation/sysctl/vm.txt}. Si tenga presente che
-la funzione di sistema \funcm{bdflush} che un tempo veniva usata per queste
-impostazioni è deprecata e causa semplicemente la stampa di un messaggio nei
-log del kernel, pertanto non la prenderemo in esame.
-
-Quando si vogliono scaricare soltanto i dati di un singolo file (ad esempio
-essere sicuri che i dati di un database sono stati registrati su disco) si
-possono usare le due funzioni di sistema \funcd{fsync} e \funcd{fdatasync}, i
-cui prototipi sono:
+scarico dei dati ad intervalli di tempo fissi. Con le nuove versioni del
+kernel queste operazioni vengono gestite direttamente dal sistema della
+memoria virtuale, attraverso opportuni \textit{task} interni al kernel il cui
+comportamento può essere controllato attraverso il file
+\sysctlfile{vm/bdflush}.\footnote{per il significato dei valori che si possono
+ scrivere in questo file si consulti la documentazione allegata ai sorgenti
+ del kernel nel file \file{Documentation/sysctl/vm.txt}, trattandosi di
+ argomenti di natura sistemistica non li prenderemo in esame.} Si tenga
+presente che la funzione di sistema \funcm{bdflush}, che un tempo veniva usata
+per queste impostazioni, è deprecata e causa semplicemente la stampa di un
+messaggio nei log del kernel, pertanto non la prenderemo in esame.
+
+Quando si vogliano scaricare i dati di un singolo file, ad esempio essere
+sicuri che i dati di un database siano stati registrati su disco, si possono
+usare le due funzioni di sistema \funcd{fsync} e \funcd{fdatasync}, i cui
+prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\end{funcproto}
Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
-file specificato, ed attendono fino alla conclusione delle operazioni;
-\func{fsync} forza anche la sincronizzazione dei meta-dati del file (che
-riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
-altri dati contenuti \itindex{inode} nell'\textit{inode} che si leggono con
-\func{fstat}, come i tempi del file).
-
-Si tenga presente che questo non comporta la sincronizzazione della
-directory che contiene il file (e scrittura della relativa voce su
-disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
- il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
- il kernel provvede anche alla sincronizzazione automatica delle voci
- delle directory.}
+file specificato, ed attendono fino alla conclusione delle operazioni. La
+prima, \func{fsync} forza anche la sincronizzazione dei meta-dati del file,
+che riguardano sia le modifiche alle tabelle di allocazione dei settori, che
+gli altri dati contenuti \itindex{inode} nell'\textit{inode} che si leggono
+con \func{fstat}, come i tempi del file. Se lo scopo dell'operazione, come
+avviene spesso per i database, è assicurarsi che i dati raggiungano il disco e
+siano rileggibili immediatamente in maniera corretta, è sufficiente l'uso di
+\func{fdatasync} che non comporta anche l'esecuzione di operazioni non
+necessarie all'integrità dei dati, come l'aggiornamento dei temi di ultima
+modifica ed ultimo accesso.
+
+Si tenga presente che l'uso di queste funzioni non comporta la
+sincronizzazione della directory che contiene il file e la scrittura della
+relativa voce su disco, che se necessaria deve essere effettuata
+esplicitamente con \func{fsync} sul file descriptor della
+directory.\footnote{in realtà per il filesystem \acr{ext2}, quando lo si monta
+ con l'opzione \cmd{sync}, il kernel provvede anche alla sincronizzazione
+ automatica delle voci delle directory.}
+
+L'uso di \func{sync} presenta in certi casi, quando ci sono più filesystem
+montati, problemi di prestazioni dovute al fatto che la funzione provoca la
+sincronizzazione dei dati su tutti quanti i filesystem, anche quando
+interesserebbe che questo avvenga soltanto su quello dei file su cui si sta
+lavorando, se i dati in attesa sono molti questo può causare seri problemi di
+prestazioni.
+
+Per questo motivo è stata introdotta una nuova funzione di sistema,
+\funcd{syncfs},\footnote{la funzione è stata introdotta a partire dal kernel
+ 2.6.39 ed è accessibile solo se è definita la macro \macro{\_GNU\_SOURCE}, è
+ specifica di Linux e non prevista da nessuno standard.} che effettua lo
+scarico dei dati soltanto per il filesystem su cui si sta operando, il suo
+prototipo è:
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int syncfs(int fd)}
+\fdesc{Sincronizza il buffer della cache dei file del singolo filesystem col
+ disco.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
+ \end{errlist}
+}
+\end{funcproto}
-% TODO, aggiungere syncfs, introdotta con il 2.6.39
+La funzione richiede che si specifichi nell'argomento \param{fd} un file
+descriptor su cui si sta operando, e lo scarico dei dati sarà limitato al
+filesystem su cui il file ad esso corrispondente si trova.
-\subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
+\subsection{Le \textit{at-functions}: \func{openat} e affini}
\label{sec:file_openat}
\itindbeg{at-functions}
-Un problema che si pone con l'uso della funzione \func{open}, così come per
-molte altre funzioni che accettano come argomenti dei
-\itindsub{pathname}{relativo} \textit{pathname} relativi, è che, quando un
-\textit{pathname} relativo non fa riferimento alla \index{directory~di~lavoro}
-directory di lavoro corrente, è possibile che alcuni dei suoi componenti
-vengano modificati in parallelo alla chiamata a \func{open}, e questo lascia
-aperta la possibilità di una \itindex{race~condition} \textit{race condition}.
+Un problema generale che si pone con l'uso della funzione \func{open}, così
+come per le altre funzioni che prendono come argomenti dei
+\itindsub{pathname}{relativo} \textit{pathname} relativi, è la possibilità,
+quando un \textit{pathname} relativo non fa riferimento ad un file posto
+direttamente nella \index{directory~di~lavoro} directory di lavoro corrente,
+che alcuni dei componenti del \textit{pathname} vengano modificati in
+parallelo alla chiamata a \func{open}, cosa che lascia aperta la possibilità
+di una \itindex{race~condition} \textit{race condition} in cui c'è spazio per
+un \itindex{symlink~attack} \textit{symlink attack} (si ricordi quanto visto
+per \func{access} in sez.~\ref{sec:file_perm_management}).
Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
corrente è una proprietà del singolo processo; questo significa che quando si
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, dette anche funzioni ``\textit{at}'' in quanto contraddistinte dal
+funzioni, dette anche ``\textit{at-functions}'' in quanto contraddistinte dal
suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
altre operazioni) usando un \itindsub{pathname}{relativo} \textit{pathname}
relativo ad una directory specificata.\footnote{l'introduzione è avvenuta su
- proposta dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
- corrispondenti \textit{system call} sono state inserite nel kernel ufficiale
- a partire dalla versione 2.6.16, in precedenza era disponibile una
- emulazione che, sia pure con prestazioni inferiori, funzionava facendo
- ricorso all'uso del filesystem \textit{proc} con l'apertura del file
- attraverso il riferimento a \textit{pathname} del tipo di
- \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
-siano presenti negli standard tradizionali esse sono state adottate da vari
-Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
-essere incluse nella recente revisione (la POSIX.1-2008) dello standard
-POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
+ proposta dello sviluppatore principale della \acr{glibc} Urlich Drepper e le
+ corrispondenti \textit{system call} sono state inserite nel kernel a partire
+ dalla versione 2.6.16, in precedenza era disponibile una emulazione che, sia
+ pure con prestazioni inferiori, funzionava facendo ricorso all'uso del
+ filesystem \textit{proc} con l'apertura del file attraverso il riferimento a
+ \textit{pathname} del tipo di \texttt{/proc/self/fd/dirfd/relative\_path}.}
+Benché queste funzioni non siano presenti negli standard tradizionali esse
+sono state adottate da altri sistemi unix-like com Solaris i vari BSD, fino ad
+essere incluse in una recente revisione (la POSIX.1-2008) dello standard
+POSIX.1. Con la \acr{glibc} per l'accesso a queste funzioni è necessario
definire la macro \macro{\_ATFILE\_SOURCE}.
L'uso di queste funzioni prevede una apertura iniziale della directory che
sarà la base della risoluzione dei \itindsub{pathname}{relativo}
\textit{pathname} relativi che verranno usati in seguito, dopo di che si dovrà
passare il relativo file descriptor alle varie funzioni che useranno quella
-directory come punto di partenza per la risoluzione.\footnote{in questo modo,
- anche quando si lavora con i \itindex{thread} \textit{thread}, si può
- mantenere una \index{directory~di~lavoro} directory di lavoro diversa per
- ciascuno di essi.}
+directory come punto di partenza per la risoluzione. In questo modo, anche
+quando si lavora con i \itindex{thread} \textit{thread}, si può mantenere una
+\index{directory~di~lavoro} directory di lavoro diversa per ciascuno di essi.
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
\textit{race condition}, consente anche di ottenere aumenti di prestazioni
significativi quando si devono eseguire molte operazioni su sezioni
dell'albero dei file che prevedono delle gerarchie di sottodirectory molto
-profonde; infatti in questo caso basta eseguire la risoluzione del
+profonde. Infatti in questo caso basta eseguire la risoluzione del
\textit{pathname} della directory di partenza una sola volta (nell'apertura
iniziale) e non tutte le volte che si deve accedere a ciascun file che essa
contiene.
La sintassi generale di queste nuove funzioni è che esse prevedono come primo
-argomento il file descriptor della directory da usare come base, mentre gli
-argomenti successivi restano identici a quelli della corrispondente funzione
-ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
-come:
+argomento il file descriptor della directory da usare come base per la
+risoluzione dei nomi, mentre gli argomenti successivi restano identici a
+quelli della corrispondente funzione ordinaria. Se ad esempio prendiamo in
+esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
\begin{funcproto}{
\fhead{fcntl.h}
\fdecl{int openat(int dirfd, const char *pathname, int flags)}
-\fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
- mode))}
+\fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t mode)}
\fdesc{Apre un file a partire da una directory di \index{directory~di~lavoro}
lavoro.}
}
corrispettive classiche, con la sola eccezione del fatto che se fra i loro
argomenti si utilizza un \itindsub{pathname}{relativo} \textit{pathname}
relativo questo sarà risolto rispetto alla directory indicata
-da \param{dirfd}; qualora invece si usi un \itindsub{pathname}{assoluto}
+da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
\textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
-se per
-\param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
- 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.} la risoluzione sarà
-effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
-corrente del processo.
+se per \param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la
+risoluzione sarà effettuata rispetto alla directory di
+\index{directory~di~lavoro} lavoro corrente del processo. Si tenga presente
+però che questa, 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.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
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.\footnote{tranne il caso in cui si sia
- specificato un \itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel
- qual caso, come detto, il valore di \param{dirfd} sarà completamente
- ignorato.}
-
-In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
-con questa nuova interfaccia, con a fianco la corrispondente funzione
-classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
- funzioni \func{utimes} e \func{lutimes} non sono propriamente le
- corrispondenti di \func{utimensat}, dato che questa ha una maggiore
- precisione nella indicazione dei tempi dei file.} 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}.\footnote{non staremo pertanto a riportarle una per
- una.} Per una parte di queste, 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}.
+riferimento ad una directory, tranne il caso in cui si sia specificato un
+\itindsub{pathname}{assoluto} \textit{pathname} assoluto, nel qual caso, come
+detto, il valore di \param{dirfd} sarà completamente ignorato.
\begin{table}[htb]
\centering
\hline
\hline
\func{faccessat} &$\bullet$&\func{access} \\
- \func{fchmodat} &$\bullet$&\func{chmod} \\
+ \funcm{fchmodat} &$\bullet$&\func{chmod} \\
\func{fchownat} &$\bullet$&\func{chown},\func{lchown}\\
- \func{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
+ \funcm{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
\func{utimensat} &$\bullet$&\func{utimes},\func{lutimes}\\
\func{linkat} &$\bullet$\footnotemark&\func{link} \\
\funcm{mkdirat} & -- &\func{mkdir} \\
\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
utilizzabile solo a partire dal kernel 2.6.18.}
-% TODO manca prototipo di fchmodat, verificare se metterlo o metter menzione
-% TODO manca prototipo di fstatat, verificare se metterlo o metter menzione
+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
+tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è prevista
+anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
+
+
% TODO manca prototipo di linkat, verificare se metterlo o metter menzione
% TODO manca prototipo di utimensat, verificare se metterlo o metter menzione
In questo caso il valore di \param{flags} stabilisce il comportamento della
funzione quando la si applica ad un collegamento simbolico, e l'unico valore
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \headfile{fcntl.h} è
- definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
- collegamenti simbolici, essendo questo però il comportamento adottato per un
- valore nullo di \param{flags} questo valore non viene mai usato.} che se
-impostato indica alla funzione di non eseguire la dereferenziazione di un
-eventuale collegamento simbolico, facendo comportare \func{fchownat} come
-\func{lchown} invece che come \func{chown}.
+utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}, che se impostato indica alla
+funzione di non eseguire la dereferenziazione di un eventuale collegamento
+simbolico, facendo comportare \func{fchownat} come \func{lchown} invece che
+come \func{chown}.
Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr}
-solo due funzioni possono usare l'argomento \param{flags} con valori diversi
-da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
-il suo prototipo è:
+solo due funzioni possono usare l'argomento \param{flags} per indicare altro
+rispetto alla possibilità di seguire o meno un collegamento simbolico, la
+prima di queste è \funcd{faccessat}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
}
\end{funcproto}
-La funzione esegue lo stesso controllo di accesso effettuabile con
-\func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
-il comportamento rispetto a quello ordinario di \func{access}. In questo caso
-esso può essere specificato come maschera binaria di due valori:
-\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{AT\_EACCES}] se impostato \funcd{faccessat} esegue il controllo
- dei permessi usando l'\ids{UID} effettivo invece di quello reale (il
- comportamento di default, che riprende quello di \func{access}).
-\item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue
- la dereferenziazione dei collegamenti simbolici, effettuando il controllo
- dei permessi direttamente sugli stessi.
-\end{basedescript}
+La funzione esegue il controllo di accesso ad un file, ma
+l'argomento \param{flags} consente di modificarne il comportamento rispetto a
+quello ordinario di \func{access}. In questo caso esso può essere specificato
+come maschera binaria di due valori: il solito \const{AT\_SYMLINK\_NOFOLLOW},
+con il significato già spiegato, e \const{AT\_EACCES} per indicare alla
+funzione di eseguire il controllo dei permessi usando l'\ids{UID} effettivo
+invece di quello reale (il comportamento di default, che riprende quello di
+\func{access}).
-La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
-argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
-comportarsi sia come analogo di \func{unlink} che di \func{rmdir}; il suo
-prototipo è:
+
+La seconda eccezione è \funcd{unlinkat}, in questo caso
+l'argomento \param{flags} viene utilizzato perché tramite esso si può indicare
+alla fuzione di comportarsi sia come analogo di \func{unlink} che di
+\func{rmdir}; il suo prototipo è:
\begin{funcproto}{
\fhead{fcntl.h}
Di default il comportamento di \func{unlinkat} è equivalente a quello che
avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
in cui questo è una directory, se però si imposta \param{flags} al valore di
-\const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
- essendo questo l'unico flag disponibile per questa funzione, lo si può
- assegnare direttamente.} essa si comporterà come \func{rmdir}, in tal
+\const{AT\_REMOVEDIR}, essa si comporterà come \func{rmdir}, in tal
caso \param{pathname} deve essere una directory, che sarà rimossa qualora
-risulti vuota.
+risulti vuota. Non essendo in questo caso prevista la possibilità di usare
+altri valori (la funzione non segue comunque i collegamenti simbolici) anche
+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
+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
+usare \const{AT\_SYMLINK\_NOFOLLOW}. Per avere un quadro d'insieme si è
+riassunto in tab.~\ref{tab:at-functions_constant_values} l'elenco delle
+costanti utilizzabili per i valori di \param{flags}.
-\itindend{at-functions}
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{AT\_SYMLINK\_NOFOLLOW}& se impostato la funzione non esegue la
+ dereferenziazione dei collegamenti simbolici.\\
+ \const{AT\_SYMLINK\_FOLLOW}& se impostato la funzione esegue la
+ dereferenziazione dei collegamenti simbolici
+ (usato esplicitamente solo da \func{linkat}).\\
+ \const{AT\_EACCES} & usato solo da \func{faccessat}, richiede che
+ il controllo dei permessi sia fatto usando
+ l'\ids{UID} effettivo invece di quello
+ reale.\\
+ \const{AT\_REMOVEDIR} & usato solo da \func{unlinkat}, richiede che
+ la funzione si comporti come \func{rmdir}
+ invece che come \func{unlink}.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti utilizzate per i bit dell'argomento
+ aggiuntivo \param{flags} delle \textit{at-functions}.}
+ \label{tab:at-functions_constant_values}
+\end{table}
-% TODO manca prototipo e motivazione di fexecve, da trattare qui in quanto
-% inserita nello stesso standard e da usare con openat, vedi
-% http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
+Un'ultima differenza fra le \textit{at-functions} e le funzioni tradizionali
+di cui sono estensione è, come accennato in sez.~\ref{sec:file_temp_file},
+quella relativa a \funcm{utimensat} che non è propriamente una corrispondente
+esatta di \func{utimes} e \func{lutimes}, dato che questa funzione ha una
+maggiore precisione nella indicazione dei tempi dei file, per i quali come per
+\func{futimes}, si devono usare strutture \struct{timespec} che consentono una
+precisione fino al nanosecondo.
+% NOTA: manca prototipo di utimensat, per ora si lascia una menzione
+\itindend{at-functions}
+% TODO: manca prototipo e motivazione di fexecve, da trattare qui in quanto
+% inserita nello stesso standard e da usare con openat, vedi
+% http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
-\subsection{La funzione \func{fcntl}}
-\label{sec:file_fcntl}
+
+\subsection{Le operazioni di controllo}
+\label{sec:file_fcntl_ioctl}
Oltre alle operazioni base esaminate in sez.~\ref{sec:file_unix_interface}
esistono tutta una serie di operazioni ausiliarie che è possibile eseguire su
un file descriptor, che non riguardano la normale lettura e scrittura di dati,
ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori
-funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
- gestiscono con questa funzione varie modalità di I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_operation}) e il \itindex{file~locking}
- \textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
+funzionalità che il kernel può mettere a disposizione.
-Per queste operazioni di manipolazione e di controllo delle varie proprietà e
-caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
-il cui prototipo è:
+Per le operazioni di manipolazione e di controllo delle varie proprietà e
+caratteristiche di un file descriptor, viene usata la funzione di sistema
+\funcd{fcntl},\footnote{ad esempio si gestiscono con questa funzione varie
+ modalità di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_operation}) e
+ il \itindex{file~locking} \textit{file locking} (vedi
+ sez.~\ref{sec:file_locking}).} il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int fcntl(int fd, int cmd)}
\fdecl{int fcntl(int fd, int cmd, long arg)}
\fdecl{int fcntl(int fd, int cmd, struct flock * lock)}
+\fdecl{int fcntl(int fd, int cmd, struct f\_owner\_ex * owner)}
\fdesc{Esegue una operazione di controllo sul file.}
}
Il primo argomento della funzione è sempre il numero di file descriptor
\var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
-sono determinati dal valore dell'argomento \param{cmd} che in sostanza
-corrisponde all'esecuzione di un determinato \textsl{comando}; in
-sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
-per la duplicazione dei file descriptor, una lista di tutti i possibili valori
-per \var{cmd} è riportata di seguito:
+aggiuntivi, sono determinati dal valore dell'argomento \param{cmd} che in
+sostanza corrisponde all'esecuzione di un determinato \textsl{comando}. A
+seconda del comando specificato il terzo argomento può essere assente (ma se
+specificato verrà ignorato), può assumere un valore intero di tipo
+\ctyp{long}, o essere un puntatore ad una struttura \struct{flock}.
+
+In sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di
+\func{fcntl} per la duplicazione dei file descriptor, una lista di tutti i
+possibili valori per \var{cmd}, e del relativo significato, dei codici di
+errore restituiti e del tipo del terzo argomento (cui faremo riferimento con
+il nome indicato nel precedente prototipo), è riportata di seguito:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
- maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
- nuovo file descriptor in caso di successo e $-1$ in caso di errore. Gli
- errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
- del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
- massimo numero di descrittori consentito.
-\item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
- valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
+ maggiore o uguale ad \param{arg}, e ne fa un duplicato
+ di \param{fd}, ritorna il nuovo file descriptor in caso di successo e $-1$
+ in caso di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ \errcode{EINVAL} se \param{arg} è negativo o maggiore del massimo consentito
+ o \errcode{EMFILE} se il processo ha già raggiunto il massimo numero di
+ descrittori consentito.
+
+\item[\const{F\_DUPFD\_CLOEXEC}] ha lo stesso effetto di \const{F\_DUPFD}, ma
+ in più attiva il flag di \itindex{close-on-exec} \textit{close-on-exec} sul
+ file descriptor duplicato, in modo da evitare una successiva chiamata con
+ \const{F\_SETFD}. La funzionalità è stata introdotta con il kernel 2.6.24 ed
+ è prevista nello standard POSIX.1-2008 (si deve perciò definire
+ \macro{\_POSIX\_C\_SOURCE} ad un valore adeguato secondo quanto visto in
+ sez.~\ref{sec:intro_gcc_glibc_std}).
+
+\item[\const{F\_GETFD}] ritorna il valore dei \textit{file descriptor flags} di
+ \param{fd} in caso di successo o $-1$ in caso di errore, il terzo argomento
+ viene ignorato. Non sono previsti errori diversi da \errval{EBADF}. Al
+ momento l'unico flag usato è quello di \itindex{close-on-exec}
+ \textit{close-on-exec}, identificato dalla costante \const{FD\_CLOEXEC}, che
+ serve a richiedere che il file venga chiuso nella esecuzione di una
+ \func{exec} (vedi sez.~\ref{sec:proc_exec}). Un valore nullo significa
+ pertanto che il flag non è impostato.
+
+\item[\const{F\_SETFD}] imposta il valore dei \textit{file descriptor flags}
+ al valore specificato con \param{arg}, ritorna un valore nullo in caso di
+ successo e $-1$ in caso di errore. Non sono previsti errori diversi da
+ \errval{EBADF}. Dato che l'unico flag attualmente usato è quello di
\itindex{close-on-exec} \textit{close-on-exec}, identificato dalla costante
- \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
- esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Ritorna un
- valore nullo in caso di successo e $-1$ in caso di errore.
-\item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
- \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
- file descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti
- (il comportamento predefinito) restano aperti.
-\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
- caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
- bit impostati da \func{open} all'apertura del file che vengono memorizzati,
+ \const{FD\_CLOEXEC}, tutti gli altri bit di \param{arg}, anche se impostati,
+ vengono ignorati.\footnote{questo almeno è quanto avviene fino al kernel
+ 3.2, come si può evincere dal codice della funzione \texttt{do\_fcntl} nel
+ file \texttt{fs/fcntl.c} dei sorgenti del kernel.}
+
+\item[\const{F\_GETFL}] ritorna il valore dei \textit{file status flags} di
+ \param{fd} in caso di successo o $-1$ in caso di errore, il terzo argomento
+ viene ignorato. Non sono previsti errori diversi da \errval{EBADF}. Il
+ comando permette di rileggere il valore di quei bit
+ dell'argomento \param{flags} di \func{open} che vengono memorizzati nella
+ relativa voce della \textit{file table} all'apertura del file, vale a dire
quelli riportati in tab.~\ref{tab:open_access_mode_flag} e
tab.~\ref{tab:open_operation_flag}).
-\item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore
- specificato da \param{arg}, ritorna un valore nullo in caso di successo o
- $-1$ in caso di errore. Possono essere impostati solo i bit riportati in
- tab.~\ref{tab:open_operation_flag}.\footnote{la pagina di manuale riporta
- come impostabili solo \const{O\_APPEND}, \const{O\_NONBLOCK} e
- \const{O\_ASYNC}.}
+
+\item[\const{F\_SETFL}] imposta il valore dei \textit{file status flags} al
+ valore specificato da \param{arg}, ritorna un valore nullo in caso di
+ successo o $-1$ in caso di errore. In generale possono essere impostati solo
+ i flag riportati in tab.~\ref{tab:open_operation_flag}, su Linux si possono
+ modificare soltanto \const{O\_APPEND}, \const{O\_ASYNC}, \const{O\_DIRECT},
+ \const{O\_NOATIME} e \const{O\_NONBLOCK}. Oltre a \errval{EBADF} si otterrà
+ \errcode{EPERM} se si cerca di rimuovere \const{O\_APPEND} da un file
+ marcato come \textit{append-only} o se di cerca di impostare
+ \const{O\_NOATIME} su un file di cui non si è proprietari (e non si hanno i
+ permessi di amministatore) ed \errcode{EINVAL} se si cerca di impostare
+ \const{O\_DIRECT} su un file che non supporta questo tipo di operazioni.
+
\item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
- \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
- ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Questa
+ \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato,
+ ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Come
+ per i due successivi comandi oltre a \errval{EBADF} se \param{lock} non è un
+ puntatore valido restituisce l'errore generico \errcode{EFAULT}. Questa
funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+
\item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
- specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
- qualcun altro ritorna immediatamente restituendo $-1$ e imposta \var{errno} a
- \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
- nullo. Questa funzionalità è trattata in dettaglio in
- sez.~\ref{sec:file_posix_lock}.
+ specificato nella struttura puntata da \param{lock}, ritorna un valore nullo
+ in caso di successo e $-1$ se il file lock è tenuto da qualcun altro, nel
+ qual caso si ha un errore di \errcode{EACCES} o \errcode{EAGAIN}. Questa
+ funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+
\item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
- la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
+ la funzione non ritorna subito ma attende che il blocco sia rilasciato, se
l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
- imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
- nullo. Questa funzionalità è trattata in dettaglio in
- sez.~\ref{sec:file_posix_lock}.
-\item[\const{F\_GETOWN}] restituisce il \ids{PID} del processo o
- l'identificatore del \itindex{process~group} \textit{process
- group}\footnote{i \itindex{process~group} \textit{process group} sono
- (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
- controllo di sessione; a ciascuno di essi è associato un identificatore
- (un numero positivo analogo al \ids{PID}).} che è preposto alla ricezione
- dei segnali \signal{SIGIO}\footnote{o qualunque altro segnale alternativo
- impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
- descriptor \param{fd}\footnote{il segnale viene usato sia per il
- \textit{Signal Drive I/O}, che tratteremo in
- sez.~\ref{sec:file_asyncronous_operation}, e dai vari meccanismi di
- notifica asincrona, che tratteremo in
- sez.~\ref{sec:file_asyncronous_lease}.} e \signal{SIGURG} per la notifica
- dei dati urgenti di un socket.\footnote{vedi
- sez.~\ref{sec:TCP_urgent_data}.} Nel caso di un \textit{process group}
- viene restituito un valore negativo il cui valore assoluto corrisponde
- all'identificatore del \itindex{process~group} \textit{process group}. In
- caso di errore viene restituito $-1$.
+ imposta \var{errno} a \errcode{EINTR}. Questa funzionalità è trattata in
+ dettaglio in sez.~\ref{sec:file_posix_lock}.
+
+\item[\const{F\_GETOWN}] restituisce in caso di successo l'identificatore del
+ processo o del \itindex{process~group} \textit{process group} (vedi
+ sez.~\ref{sec:sess_proc_group}) che è preposto alla ricezione del segnale
+ \signal{SIGIO} (o l'eventuale segnale alternativo impostato con
+ \const{F\_SETSIG}) per gli eventi asincroni associati al file
+ descriptor \param{fd} e del segnale \signal{SIGURG} per la notifica dei dati
+ urgenti di un socket (vedi sez.~\ref{sec:TCP_urgent_data}). Restituisce $-1$
+ in caso di errore ed il terzo argomento viene ignorato. Non sono previsti
+ errori diversi da \errval{EBADF}.
+
+ Per distinguerlo dal caso in cui il segnale viene inviato a un singolo
+ processo, nel caso di un \textit{process group} viene restituito un valore
+ negativo il cui valore assoluto corrisponde all'identificatore del
+ \itindex{process~group} \textit{process group}. Con Linux questo comporta un
+ problema perché se il valore restitituito dalla \textit{system call} è
+ compreso nell'intervallo fra $-1$ e $-4095$ in alcune architetture questo
+ viene trattato dalla \acr{glibc} come un errore,\footnote{il problema deriva
+ dalle limitazioni presenti in architetture come quella dei normali PC
+ (i386) per via delle modalità in cui viene effettuata l'invocazione delle
+ \textit{system call} che non consentono di restituire un adeguato codice
+ di ritorno.} per cui in tal caso \func{fcntl} ritornerà comunque $-1$
+ mentre il valore restituito dalla \textit{system call} verrà assegnato ad
+ \var{errno}, cambiato di segno.
+
+ Per questo motivo con il kernel 2.6.32 è stato introdotto il comando
+ alternativo \const{F\_GETOWN\_EX}, che vedremo a breve, che consente di
+ evitare il problema. A partire dalla versione 2.11 la \acr{glibc}, se
+ disponibile, usa questa versione alternativa per mascherare il problema
+ precedente e restituire un valore corretto in tutti i casi.\footnote{in cui
+ cioè viene restituito un valore negativo corretto qualunque sia
+ l'identificatore del \itindex{process~group} \textit{process group}, che
+ non potendo avere valore unitario (non esiste infatti un
+ \itindex{process~group} \textit{process group} per \cmd{init}) non può
+ generare ambiguità con il codice di errore.} Questo però comporta che il
+ comportamento del comando può risultare diverso a seconda delle versioni
+ della \acr{glibc} e del kernel.
+
\item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
l'identificatore del processo o del \itindex{process~group} \textit{process
- group} che riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli
- eventi associati al file descriptor \param{fd}, ritorna un valore nullo in
- caso di successo o $-1$ in caso di errore. Come per \const{F\_GETOWN}, per
- impostare un \itindex{process~group} \textit{process group} si deve usare
- per \param{arg} un valore negativo, il cui valore assoluto corrisponde
+ group} che riceverà i segnali \signal{SIGIO} e \signal{SIGURG} per gli
+ eventi associati al file descriptor \param{fd}. Ritorna un valore nullo in
+ caso di successo o $-1$ in caso di errore. Oltre a \errval{EBADF} gli errori
+ possibili sono \errcode{ESRCH} se \param{arg} indica un processo o un
+ \itindex{process~group} \textit{process group} inesistente.
+
+ L'impostazione è soggetta alle stesse restrizioni presenti sulla funzione
+ \func{kill} (vedi sez.~\ref{sec:sig_kill_raise}), per cui un utente non
+ privilegiato può inviare i segnali solo ad un processo che gli appartiene,
+ in genere comunque si usa il processo corrente. Come per \const{F\_GETOWN},
+ per indicare un \itindex{process~group} \textit{process group} si deve usare
+ per \param{arg} un valore negativo, il cui valore assoluto corrisponda
all'identificatore del \itindex{process~group} \textit{process group}.
-\item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
- sono dati disponibili in ingresso su un file descriptor aperto ed impostato
- per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
- indica il valore predefinito (che è \signal{SIGIO}), un valore diverso da
- zero indica il segnale richiesto, (che può essere anche lo stesso
- \signal{SIGIO}). In caso di errore ritorna $-1$.
-\item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
- possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
- ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
- valore zero indica di usare il segnale predefinito, \signal{SIGIO}. Un altro
- valore diverso da zero (compreso lo stesso \signal{SIGIO}) specifica il
- segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
+
+ A partire dal kernel 2.6.12 se si sta operando con i \textit{thread} della
+ implementazione nativa di Linux (quella della NTPL, vedi
+ sez.~\ref{sec:linux_ntpl}) e se si è impostato un segnale specifico con
+ \const{F\_SETSIG}, un valore positivo di \param{arg} viene interpretato come
+ indicante un \textit{Thread ID} e non un \textit{Process ID}. Questo
+ consente di inviare il segnale impostato con \const{F\_SETSIG} ad uno
+ specifico \textit{thread}. In genere questo non comporta differenze
+ significative per il processi ordinari, in cui non esistono altri
+ \textit{thread}, dato che su Linux il \textit{thread} principale, che in tal
+ caso è anche l'unico, mantiene un valore del \textit{Thread ID} uguale al
+ \ids{PID} del processo. Il problema è però che questo comportamento non si
+ applica a \signal{SIGURG}, per il quale \param{arg} viene sempre
+ interpretato come l'identificatore di un processo o di un
+ \itindex{process~group} \textit{process group}.
+
+\item[\const{F\_GETOWN\_EX}] legge nella struttura puntata
+ dal'argomento \param{owner} l'identificatore del processo, \textit{thread} o
+ \itindex{process~group} \textit{process group} (vedi
+ sez.~\ref{sec:sess_proc_group}) che è preposto alla ricezione dei segnali
+ \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$
+ in caso di errore. Oltre a \errval{EBADF} e da
+ \errval{EFAULT} se \param{owner} non è un puntatore valido.
+
+ Il comando, che è disponibile solo a partire dal kernel 2.6.32, effettua lo
+ stesso compito di \const{F\_GETOWN} di cui costituisce una evoluzione che
+ consente di superare i limiti e le ambiguità relative ai valori restituiti
+ come identificativo. A partire dalla versione 2.11 della \acr{glibc} esso
+ viene usato dalla libreria per realizzare una versione di \func{fcntl} che
+ non presenti i problemi illustrati in precedenza per la versione precedente
+ di \const{F\_GETOWN}. Il comando è specifico di Linux ed utilizzabile solo
+ se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+\item[\const{F\_SETOWN\_EX}] imposta con il valore della struttura
+ \struct{f\_owner\_ex} puntata \param{owner}, l'identificatore del processo o
+ del \itindex{process~group} \textit{process group} che riceverà i segnali
+ \signal{SIGIO} e \signal{SIGURG} per gli eventi associati al file
+ descriptor \param{fd}. Ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore, con gli stessi errori di \const{F\_SETOWN} più
+ \errcode{EINVAL} se il campo \var{type} di \struct{f\_owner\_ex} non indica
+ un tipo di identificatore valido.
+
+ \begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{varwidth}[c]{0.5\textwidth}
+ \includestruct{listati/f_owner_ex.h}
+ \end{varwidth}
+ \normalsize
+ \caption{La struttura \structd{f\_owner\_ex}.}
+ \label{fig:f_owner_ex}
+ \end{figure}
+
+ Come \const{F\_GETOWN\_EX} il comando richiede come terzo argomento il
+ puntatore ad una struttura \struct{f\_owner\_ex} la cui definizione è
+ riportata in fig.~\ref{fig:f_owner_ex}, in cui il primo campo indica il tipo
+ di indentificatore il cui valore è specificato nel secondo campo, che assume
+ lo stesso significato di \param{arg} per \const{F\_SETOWN}. Per il campo
+ \var{type} i soli valori validi sono \const{F\_OWNER\_TID},
+ \const{F\_OWNER\_PID} e \const{F\_OWNER\_PGRP}, che indicano rispettivamente
+ che si intedende specificare con \var{pid} un \textit{Tread ID}, un
+ \textit{Process ID} o un \textit{Process Group ID}. A differenza di
+ \const{F\_SETOWN} se si specifica un \textit{Tread ID} questo riceverà sia
+ \signal{SIGIO} (o il segnale impostato con \const{F\_SETSIG}) che
+ \signal{SIGURG}. Il comando è specifico di Linux, è disponibile solo a
+ partire dal kernel 2.6.32, ed è utilizzabile solo se si è definita la macro
+ \macro{\_GNU\_SOURCE}.
+
+\item[\const{F\_GETSIG}] restituisce il valore del segnale inviato dai vari
+ meccanismi di I/O asincrono associati al file descriptor \param{fd} (quelli
+ trattati in sez.~\ref{sec:file_asyncronous_operation}) in caso di successo o
+ $-1$ in caso di errore, il terzo argomento viene ignorato. Non sono previsti
+ errori diversi da \errval{EBADF}. Un valore nullo indica che si sta usando
+ il segnale predefinito, che è \signal{SIGIO}. Un valore diverso da zero
+ indica il segnale che è stato impostato con \const{F\_SETSIG}, che può
+ essere anche lo stesso \signal{SIGIO}. Il comando è specifico di Linux ed
+ utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+\item[\const{F\_SETSIG}] imposta il segnale inviato dai vari meccanismi di I/O
+ asincrono associati al file descriptor \param{fd} (quelli trattati in
+ sez.~\ref{sec:file_asyncronous_operation}) al valore indicato
+ da \param{arg}, ritorna un valore nullo in caso di successo o $-1$ in caso
+ di errore. Oltre a \errval{EBADF} gli errori possibili sono
+ \errcode{EINVAL} se \param{arg} indica un numero di segnale non valido. Un
+ valore nullo di \param{arg} indica di usare il segnale predefinito, cioè
+ \signal{SIGIO}. Un valore diverso da zero, compreso lo stesso
+ \signal{SIGIO}, specifica il segnale voluto. Il comando è specifico di
+ Linux ed utilizzabile solo se si è definita la macro \macro{\_GNU\_SOURCE}.
+
+ L'impostazione di un valore diverso da zero permette inoltre, se si è
installato il gestore del segnale come \var{sa\_sigaction} usando
\const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
disponibili al gestore informazioni ulteriori riguardo il file che ha
- generato il segnale attraverso i valori restituiti in \struct{siginfo\_t}
- (come vedremo in sez.~\ref{sec:file_asyncronous_io}).\footnote{i due comandi
- \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
- Linux.}
-\item[\const{F\_SETLEASE}] imposta o rimuove un \itindex{file~lease}
- \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
- Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui il
- processo che detiene un \textit{lease} su un file riceve una notifica
- qualora un altro processo cerca di eseguire una \func{open} o una
- \func{truncate} su di esso.} sul file descriptor \var{fd} a seconda del
- valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
- valore nullo in caso di successo o $-1$ in caso di errore. Questa
- funzionalità avanzata è trattata in dettaglio in
- sez.~\ref{sec:file_asyncronous_lease}.
+ generato il segnale attraverso i valori restituiti in
+ \struct{siginfo\_t}. Se inoltre si imposta un segnale \textit{real-time} si
+ potranno sfruttare le caratteristiche di avanzate di questi ultimi (vedi
+ sez.~\ref{sec:sig_real_time}), ed in particolare la capacità di essere
+ accumulati in una coda prima della notifica.
+
\item[\const{F\_GETLEASE}] restituisce il tipo di \itindex{file~lease}
\textit{file lease} che il processo detiene nei confronti del file
- descriptor \var{fd} o $-1$ in caso di errore. Con questo comando il terzo
- argomento può essere omesso. Questa funzionalità avanzata è trattata in
- dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
-\item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
- riportata al processo chiamante, tramite il segnale \signal{SIGIO} (o altro
- segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
+ descriptor \var{fd} o $-1$ in caso di errore, il terzo argomento viene
+ ignorato. Non sono previsti errori diversi da \errval{EBADF}. Il comando è
+ specifico di Linux ed utilizzabile solo se si è definita la macro
+ \macro{\_GNU\_SOURCE}. Questa funzionalità è trattata in dettaglio in
+ sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\const{F\_SETLEASE}] imposta o rimuove a seconda del valore
+ di \param{arg} un \itindex{file~lease} \textit{file lease} sul file
+ descriptor \var{fd} a seconda del valore indicato da \param{arg}. Ritorna un
+ valore nullo in caso di successo o $-1$ in caso di errore. Oltre a
+ \errval{EBADF} si otterrà \errcode{EINVAL} se si è specificato un valore non
+ valido per \param{arg} (deve essere usato uno dei valori di
+ tab.~\ref{tab:file_lease_fctnl}), \errcode{ENOMEM} se non c'è memoria
+ sufficiente per creare il \textit{file lease}, \errcode{EACCESS} se non si è
+ il proprietario del file e non si hanno i privilegi di
+ amministratore.\footnote{per la precisione occorre la capacità
+ \itindex{capabilities} \const{CAP\_LEASE}.}
+
+ Il comando è specifico di Linux ed utilizzabile solo se si è definita la
+ macro \macro{\_GNU\_SOURCE}. Il comando è presente a partire dai kernel
+ della serie 2.4.x, quando è stato introdotto il supporto \textit{file
+ lease}, per cui un processo che detiene un \textit{lease} su un file
+ riceve una notifica qualora un altro processo cerchi di eseguire una
+ \func{open} o una \func{truncate} su di esso. Questa funzionalità è trattata
+ in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\const{F\_NOTIFY}] attiva il meccanismo di notifica asincrona per cui
+ viene riportato al processo chiamante, tramite il segnale \signal{SIGIO} (o
+ altro segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
- in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in caso
- di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
- 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+ in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in
+ caso di errore. Il comando è specifico di Linux ed utilizzabile solo se si è
+ definita la macro \macro{\_GNU\_SOURCE}. Questa funzionalità, disponibile
+ dai kernel della serie 2.4.x, è trattata in dettaglio in
+ sez.~\ref{sec:file_asyncronous_lease}.
+
+\item[\const{F\_GETPIPE\_SZ}]
+
+\item[\const{F\_SETPIPE\_SZ}]
+
\end{basedescript}
-La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
-poter essere affrontate in tutti i loro aspetti a questo punto; saranno
-pertanto riprese più avanti quando affronteremo le problematiche ad esse
-relative. In particolare le tematiche relative all'I/O asincrono e ai vari
-meccanismi di notifica saranno trattate in maniera esaustiva in
-sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al
-\itindex{file~locking} \textit{file locking} saranno esaminate in
-sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
-trattato in sez.~\ref{sec:sock_ctrl_func}.
+La maggior parte delle funzionalità controllate dai comandi di \func{fcntl}
+sono molto avanzate e richiedono degli approfondimenti ulteriori rispetto a
+quanto illustrato adesso; saranno pertanto riprese più avanti quando
+affronteremo le problematiche ad esse relative. In particolare le tematiche
+relative all'I/O asincrono e ai vari meccanismi di notifica saranno trattate
+in maniera esaustiva in sez.~\ref{sec:file_asyncronous_operation} mentre
+quelle relative al \itindex{file~locking} \textit{file locking} saranno
+esaminate in sez.~\ref{sec:file_locking}). L'uso di questa funzione con i
+socket verrà trattato in sez.~\ref{sec:sock_ctrl_func}.
+
+La gran parte dei comandi di \func{fcntl} (\const{F\_DUPFD}, \const{F\_GETFD},
+\const{F\_SETFD}, \const{F\_GETFL}, \const{F\_SETFL}, \const{F\_GETLK},
+\const{F\_SETLK} e \const{F\_SETLKW}) sono presenti da molto tempo, sono
+previsti da SVr4 e 4.3BSD e standardizzati in POSIX.1-2001 che inoltre prevede
+gli ulteriori \const{F\_GETOWN} e \const{F\_SETOWN}. Pertanto nell'elenco si
+sono indicate esplicitamente soltanto le ulteriori richieste in termini delle
+macro di funzionalità di sez.~\ref{sec:intro_gcc_glibc_std} soltanto per le
+funzionalità inserite in standard successivi o specifiche di Linux.
Si tenga presente infine che quando si usa la funzione per determinare le
modalità di accesso con cui è stato aperto il file (attraverso l'uso del
-\subsection{La funzione \func{ioctl}}
-\label{sec:file_ioctl}
+% \subsection{La funzione \func{ioctl}}
+% \label{sec:file_ioctl}
Benché il concetto di \textit{everything is a file} si sia dimostrato molto
valido anche per l'interazione con i dispositivi più vari, fornendo una
usate per i normali file di dati, esisteranno sempre caratteristiche
peculiari, specifiche dell'hardware e della funzionalità che ciascun
dispositivo può provvedere, che non possono venire comprese in questa
-interfaccia astratta (un caso tipico è l'impostazione della velocità di una
-porta seriale, o le dimensioni di un framebuffer).
+interfaccia astratta come ad esempio l'impostazione della velocità di una
+porta seriale, o le dimensioni di un framebuffer.
Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
eventuale valore viene ignorato.
\item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
- file (vedi sez.~\ref{sec:file_asyncronous_operation}); il terzo argomento
+ file (vedi sez.~\ref{sec:signal_driven_io}); il terzo argomento
deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
che contiene un valore logico (un valore nullo disabilita, un valore non
nullo abilita).
% LocalWords: fwritable ext freading fwriting buffering setvbuf BUFSIZ setbuf
% LocalWords: IONBF IOLBF IOFBF setbuffer setlinebuf flbf fbufsize flushlbf hh
% LocalWords: fsync fpurge flockfile ftrylockfile funlockfile files fig flags
-% LocalWords: locking fsetlocking type Virtual operation dentry unistd sys AT
-% LocalWords: modification hole functions FSETSIG pathname EEXIST CREAT EINTR
+% LocalWords: locking fsetlocking type virtual operation dentry unistd sys AT
+% LocalWords: modification hole functions pathname EEXIST CREAT EINTR
% LocalWords: EISDIR EFBIG EOVERFLOW ELOOP NOFOLLOW ENODEV ENOENT ENOTDIR fork
% LocalWords: EMFILE ENAMETOOLONG ENFILE ENOMEM ENOSPC EROFS exec access RDWR
% LocalWords: RDONLY ioctl AND ACCMODE creation Denial Service DoS opendir NFS
% LocalWords: everything framebuffer ENOTTY argp CDROM lsattr chattr magic
% LocalWords: number FIOCLEX FIONCLEX FIOASYNC FIONBIO FIOSETOWN FIOGETOWN
% LocalWords: FIONREAD epoll FIOQSIZE side effects SAFE BYCALLER QUERY EACCES
-% LocalWords: EBUSY OpenBSD
+% LocalWords: EBUSY OpenBSD syncfs
% LocalWords: ENXIO NONBLOCK WRONLY EPERM NOATIME ETXTBSY EWOULDBLOCK
% LocalWords: EFAULT
projects / gapil.git / blobdiff