%% fileunix.tex
%%
-%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2009 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{I file: l'interfaccia standard Unix}
\label{cha:file_unix_interface}
Esamineremo in questo capitolo la prima delle due interfacce di programmazione
-per i file, quella dei \textit{file descriptor}\index{file!descriptor},
+per i file, quella dei \index{file!descriptor} \textit{file descriptor},
nativa di Unix. Questa è l'interfaccia di basso livello provvista direttamente
dalle system call, che non prevede funzionalità evolute come la
bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
\index{file!descriptor|(}
-Per poter accedere al contenuto di un file occorre
-creare un canale di comunicazione con il kernel che renda possibile operare su
-di esso (si ricordi quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si
-fa aprendo il file con la funzione \func{open} che provvederà a localizzare
-l'inode\index{inode} del file e inizializzare i puntatori che rendono
-disponibili le funzioni che il VFS mette a disposizione (riportate in
+Per poter accedere al contenuto di un file occorre creare un canale di
+comunicazione con il kernel che renda possibile operare su di esso (si ricordi
+quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si fa aprendo il file
+con la funzione \func{open} che provvederà a localizzare \index{inode} l'inode
+del file e inizializzare i puntatori che rendono disponibili le funzioni che
+il VFS mette a disposizione (riportate in
tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
impedendo ogni ulteriore operazione.
Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
kernel gestisce l'interazione fra processi e file. Il kernel mantiene sempre
un elenco dei processi attivi nella cosiddetta \itindex{process~table}
-\textit{process table} ed un elenco dei file aperti nella \textit{file table}.
+\textit{process table} ed un elenco dei file aperti nella
+\itindex{file~table} \textit{file table}.
La \itindex{process~table} \textit{process table} è una tabella che contiene
una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
\item i flag relativi ai file descriptor.
\item il numero di file aperti.
\item una tabella che contiene un puntatore alla relativa voce nella
- \textit{file table} per ogni file aperto.
+ \itindex{file~table} \textit{file table} per ogni file aperto.
\end{itemize*}
il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
quest'ultima tabella.
-La \textit{file table} è una tabella che contiene una voce per ciascun file
-che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
-\struct{file}; in ciascuna di esse sono tenute varie informazioni relative al
-file, fra cui:
+La \itindex{file~table} \textit{file table} è una tabella che contiene una
+voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
+strutture di tipo \struct{file}; in ciascuna di esse sono tenute varie
+informazioni relative al file, fra cui:
\begin{itemize*}
\item lo stato del file (nel campo \var{f\_flags}).
\item il valore della posizione corrente (l'\textit{offset}) nel file (nel
campo \var{f\_pos}).
-\item un puntatore all'inode\index{inode}\footnote{nel kernel 2.4.x si è in
- realtà passati ad un puntatore ad una struttura \struct{dentry} che punta a
- sua volta all'inode\index{inode} passando per la nuova struttura del VFS.}
- del file.
+\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
+ realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
+ a sua volta \index{inode} all'inode passando per la nuova struttura del
+ VFS.} del file.
%\item un puntatore alla tabella delle funzioni \footnote{la struttura
% \var{f\_op} descritta in sez.~\ref{sec:file_vfs_work}} che si possono usare
% sul file.
Ritorneremo su questo schema più volte, dato che esso è fondamentale per
capire i dettagli del funzionamento dell'interfaccia dei \textit{file
descriptor}.
+
\index{file!descriptor|)}
\begin{figure}[htb]
In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
-quanto appena detto, avranno come \textit{file
- descriptor}\index{file!descriptor} i valori 0, 1 e 2. Benché questa sia
-soltanto una convenzione, essa è seguita dalla gran parte delle applicazioni,
-e non aderirvi potrebbe portare a gravi problemi di interoperabilità.
+quanto appena detto, avranno come \index{file!descriptor} \textit{file
+ descriptor} i valori 0, 1 e 2. Benché questa sia soltanto una convenzione,
+essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
+portare a gravi problemi di interoperabilità.
Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
facendo riferimento ad un programma in cui lo \textit{standard input} è
associato ad un file mentre lo \textit{standard output} e lo \textit{standard
error} sono entrambi associati ad un altro file (e quindi utilizzano lo
-stesso inode\index{inode}).
+stesso \index{inode} inode).
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
numero di file aperti era anche soggetto ad un limite massimo dato dalle
\label{sec:file_open}
La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
-quella che crea l'associazione fra un \itindex{pathname}\textit{pathname} ed
-un file descriptor, il suo prototipo è:
+quella che crea l'associazione fra un \itindex{pathname} \textit{pathname} ed
+un \index{file!descriptor} file descriptor, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
La funzione apre il file usando il primo file descriptor libero, e crea
-l'opportuna voce, cioè la struttura \struct{file}, nella \textit{file table}
-del processo. Viene sempre restituito come valore di ritorno il file
-descriptor con il valore più basso disponibile.
+l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
+\textit{file table} del processo. Viene sempre restituito come valore di
+ritorno il file descriptor con il valore più basso disponibile.
\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
- \textsl{file di lock}\index{file!di lock} possono incorrere in una
- \textit{race condition}\itindex{race~condition}. Si consiglia come
+ \index{file!di lock} \textsl{file di lock} possono incorrere in una
+ \itindex{race~condition} \textit{race condition}. Si consiglia come
alternativa di usare un file con un nome univoco e la funzione \func{link}
per verificarne l'esistenza (vedi sez.~\ref{sec:ipc_file_lock}).}
-\footnotetext[3]{acronimo di \textit{Denial of
- Service}\itindex{Denial~of~Service~(DoS)}, si chiamano così attacchi
- miranti ad impedire un servizio causando una qualche forma di carico
- eccessivo per il sistema, che resta bloccato nelle risposte all'attacco.}
-
\begin{table}[!htb]
\centering
\footnotesize
- \begin{tabular}[c]{|l|p{12cm}|}
+ \begin{tabular}[c]{|l|p{13cm}|}
\hline
\textbf{Flag} & \textbf{Descrizione} \\
\hline
\hline
\const{O\_CREAT} & Se il file non esiste verrà creato, con le regole di
titolarità del file viste in
- sez.~\ref{sec:file_ownership}. Con questa opzione
- l'argomento \param{mode} deve essere specificato. \\
+ sez.~\ref{sec:file_ownership_management}. Con questa
+ opzione l'argomento \param{mode} deve essere
+ specificato.\\
\const{O\_EXCL} & Usato in congiunzione con \const{O\_CREAT} fa sì che
la precedente esistenza del file diventi un
errore\protect\footnotemark\ che fa fallire
- \func{open} con \errcode{EEXIST}. \\
+ \func{open} con \errcode{EEXIST}.\\
\const{O\_NONBLOCK}& Apre il file in modalità non bloccante, e
comporta che \func{open} ritorni immediatamente anche
quando dovrebbe bloccarsi (l'opzione ha senso solo per
- le fifo, vedi sez.~\ref{sec:ipc_named_pipe}). \\
+ le fifo, vedi sez.~\ref{sec:ipc_named_pipe}).\\
\const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo di
terminale, questo non diventerà il terminale di
controllo, anche se il processo non ne ha ancora uno
- (si veda sez.~\ref{sec:sess_ctrl_term}). \\
+ (si veda sez.~\ref{sec:sess_ctrl_term}).\\
\const{O\_SHLOCK} & Apre il file con uno shared lock (vedi
sez.~\ref{sec:file_locking}). Specifica di BSD,
- assente in Linux. \\
+ assente in Linux.\\
\const{O\_EXLOCK} & Apre il file con un lock esclusivo (vedi
sez.~\ref{sec:file_locking}). Specifica di BSD,
assente in Linux.\\
\const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
ne tronca la lunghezza a zero; con un terminale o una
fifo viene ignorato, negli altri casi il
- comportamento non è specificato. \\
+ comportamento non è specificato.\\
\const{O\_NOFOLLOW}& Se \param{pathname} è un link simbolico la chiamata
fallisce. Questa è un'estensione BSD aggiunta in Linux
dal kernel 2.1.126. Nelle versioni precedenti i link
simbolici sono sempre seguiti, e questa opzione è
- ignorata. \\
+ ignorata.\\
\const{O\_DIRECTORY}&Se \param{pathname} non è una directory la chiamata
fallisce. Questo flag è specifico di Linux ed è stato
introdotto con il kernel 2.1.126 per evitare dei
\itindex{Denial~of~Service~(DoS)}
\textit{DoS}\protect\footnotemark\ quando
\func{opendir} viene chiamata su una fifo o su un
+ dispositivo associato ad una unità a nastri, non deve
dispositivo a nastri; non deve essere utilizzato
- al di fuori dell'implementazione di \func{opendir}. \\
- \const{O\_LARGEFILE}&nel caso di sistemi a 32 bit che supportano file di
+ al di fuori dell'implementazione di \func{opendir}.\\
+ \const{O\_LARGEFILE}&Nel caso di sistemi a 32 bit che supportano file di
grandi dimensioni consente di aprire file le cui
dimensioni non possono essere rappresentate da numeri
- a 31 bit. \\
+ a 31 bit.\\
\hline
\hline % modalità di operazione coi file
- \const{O\_APPEND} & Il file viene aperto in append mode. Prima di ciascuna
+ \const{O\_APPEND} & Il file viene aperto in \itindex{append~mode}
+ \textit{append mode}. Prima di ciascuna
scrittura la posizione corrente viene sempre impostata
alla fine del file. Con NFS si può avere una
corruzione del file se più di un processo scrive allo
leggere e quello di \func{write} in caso di
impossibilità di scrivere immediatamente. Questa
modalità ha senso solo per le fifo e per alcuni file
- di dispositivo. \\
+ di dispositivo.\\
\const{O\_NDELAY} & In Linux\footnotemark\ è sinonimo di
\const{O\_NONBLOCK}.\\
\const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
sez.~\ref{sec:file_asyncronous_io}). Quando è
impostato viene generato il segnale \const{SIGIO}
tutte le volte che sono disponibili dati in input
- sul file. \\
+ sul file.\\
\const{O\_SYNC} & Apre il file per l'input/output sincrono: ogni
\func{write} bloccherà fino al completamento della
scrittura di tutti i dati sull'hardware
sottostante.\\
- \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}, usato da BSD. \\
+ \const{O\_FSYNC} & Sinonimo di \const{O\_SYNC}, usato da BSD.\\
\const{O\_DSYNC} & Variante di I/O sincrono definita da POSIX; presente
dal kernel 2.1.130 come sinonimo di
- \const{O\_SYNC}. \\
+ \const{O\_SYNC}.\\
\const{O\_RSYNC} & Variante analoga alla precedente, trattata allo stesso
- modo. \\
+ modo.\\
\const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
file (vedi sez.~\ref{sec:file_file_times}). Per molti
filesystem questa funzionalità non è disponibile per
alle dimensioni dei blocchi del filesystem; per il
kernel 2.6 basta che siano allineati a multipli di 512
byte.\\
+ \const{O\_CLOEXEC} & Attiva la modalità di \textit{close-on-exec} (vedi
+ sez.~\ref{sec:file_sharing} e
+ \ref{sec:file_fcntl}).\footnotemark\\
\hline
\end{tabular}
\caption{Valori e significato dei vari bit del \textit{file status flag}.}
\label{tab:file_open_flags}
\end{table}
-\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
- il kernel deve simularla, ma questo comporta la possibilità di una race
- condition, vedi sez.~\ref{sec:file_atomic}.}
+\footnotetext[3]{acronimo di \itindex{Denial~of~Service~(DoS)} \textit{Denial
+ of Service}, si chiamano così attacchi miranti ad impedire un servizio
+ causando una qualche forma di carico eccessivo per il sistema, che resta
+ bloccato nelle risposte all'attacco.}
+
+\footnotetext[4]{il problema è che NFS non supporta la scrittura in
+ \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
+ questo comporta la possibilità di una \itindex{race~condition} \textit{race
+ condition}, vedi sez.~\ref{sec:file_atomic}.}
\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
una \func{read} con un valore nullo e non con un errore, questo introduce
un'ambiguità, dato che come vedremo in sez.~\ref{sec:file_read} il ritorno di
- zero da parte di \func{read} ha il significato di una end-of-file.}
+ zero da parte di \func{read} ha il significato di una \textit{end-of-file}.}
\footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
sostanzialmente a permettere ad alcuni programmi (in genere database) la
anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
introdotta con il kernel 2.4.10, le versioni precedenti la ignorano.}
+\footnotetext[7]{introdotto con il kernel 2.6.23, per evitare una
+ \itindex{race~condition} \textit{race condition} che si può verificare con i
+ \itindex{thread} \textit{thread}, fra l'apertura del file e l'impostazione
+ della suddetta modalità con \func{fcntl}.}
Questa caratteristica permette di prevedere qual è il valore del file
descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
all'inizio del file.
L'argomento \param{mode} indica i permessi con cui il file viene creato; i
-valori possibili sono gli stessi già visti in sez.~\ref{sec:file_perm_overview}
-e possono essere specificati come OR binario delle costanti descritte in
-tab.~\ref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
-\var{umask} (vedi sez.~\ref{sec:file_umask}) per il processo.
+valori possibili sono gli stessi già visti in
+sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
+delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
+filtrati dal valore di \itindex{umask} \textit{umask} (vedi
+sez.~\ref{sec:file_perm_management}) per il processo.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
\index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che il
processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
-file table vengono rilasciate. Infine se il file descriptor era l'ultimo
-riferimento ad un file su disco quest'ultimo viene cancellato.
+\itindex{file~table} \textit{file table} vengono rilasciate. Infine se il file
+descriptor era l'ultimo riferimento ad un file su disco quest'ultimo viene
+cancellato.
Si ricordi che quando un processo termina anche tutti i suoi file descriptor
vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
lettura e scrittura avvengono a partire da questa posizione che viene
automaticamente spostata in avanti del numero di byte letti o scritti.
-In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa
-posizione viene impostata a zero all'apertura del file. È possibile impostarla
-ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è:
+In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
+\const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
+file. È possibile impostarla ad un valore qualsiasi con la funzione
+\funcd{lseek}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket\index{socket} o una
- fifo.
+ \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
\item[\errcode{EINVAL}] \param{whence} non è un valore valido.
\end{errlist}
ed inoltre \errval{EBADF}.}
la successiva scrittura avvenga alla fine del file, infatti se questo è stato
aperto anche da un altro processo che vi ha scritto, la fine del file può
essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
-(questa è una potenziale sorgente di \itindex{race~condition}\textit{race
+(questa è una potenziale sorgente di \itindex{race~condition} \textit{race
condition}, vedi sez.~\ref{sec:file_atomic}).
Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
-questo caso la funzione ritorna l'errore \errcode{EPIPE}. Questo, oltre che per
-i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che non
-supportano questa funzione, come ad esempio per i file di
+questo caso la funzione ritorna l'errore \errcode{ESPIPE}. Questo, oltre che
+per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che
+non supportano questa funzione, come ad esempio per i file di
terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
POSIX però non specifica niente in proposito. Infine alcuni file speciali, ad
di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
con un numero di byte inferiore a quelli richiesti.
-Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un
-socket\index{socket}, come vedremo in sez.~\ref{sec:sock_io_behav}), o per la
-lettura da certi file di dispositivo, come le unità a nastro, che
-restituiscono sempre i dati ad un singolo blocco alla volta, o come le linee
-seriali, che restituiscono solo i dati ricevuti fino al momento della lettura.
+Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
+come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
+di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
+singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
+dati ricevuti fino al momento della lettura.
Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
\errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
dati in ingresso: la funzione allora ritorna immediatamente con un errore
-\errcode{EAGAIN}\footnote{BSD usa per questo errore la costante
+\errcode{EAGAIN}\footnote{in BSD si usa per questo errore la costante
\errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
\errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
disponibili occorre provare a ripetere la lettura in un secondo tempo.
l'emulazione per i vecchi kernel che non hanno la system call, è stato
aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
delle librerie la funzione non è disponibile.} (quello che viene chiamato
-normalmente Unix98, vedi sez.~\ref{sec:intro_opengroup}) è stata introdotta la
+normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
\begin{prototype}{unistd.h}
{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
a partire dalla posizione corrente nel file e sposta automaticamente la
posizione in avanti del numero di byte scritti. Se il file è aperto in
-modalità \const{O\_APPEND} i dati vengono sempre scritti alla fine del file.
-Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili
-ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è
-ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem
-supportino questa capacità.
+modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
+alla fine del file. Lo standard POSIX richiede che i dati scritti siano
+immediatamente disponibili ad una \func{read} chiamata dopo che la
+\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
+non è detto che tutti i filesystem supportino questa capacità.
Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
Per i file ordinari il numero di byte scritti è sempre uguale a quello
\label{fig:file_mult_acc}
\end{figure}
-Il primo caso è quello in cui due processi diversi aprono lo stesso file
-su disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
+Il primo caso è quello in cui due processi diversi aprono lo stesso file su
+disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
processo avrà una sua voce nella \textit{file table} referenziata da un
diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
-nella \textit{file table} faranno però riferimento allo stesso
-inode\index{inode} su disco.
+nella \itindex{file~table} \textit{file table} faranno però riferimento allo
+stesso \index{inode} inode su disco.
Questo significa che ciascun processo avrà la sua posizione corrente sul file,
la sua modalità di accesso e versioni proprie di tutte le proprietà che
-vengono mantenute nella sua voce della \textit{file table}. Questo ha
-conseguenze specifiche sugli effetti della possibile azione simultanea sullo
-stesso file, in particolare occorre tenere presente che:
+vengono mantenute nella sua voce della \itindex{file~table} \textit{file
+ table}. Questo ha conseguenze specifiche sugli effetti della possibile
+azione simultanea sullo stesso file, in particolare occorre tenere presente
+che:
\begin{itemize}
\item ciascun processo può scrivere indipendentemente; dopo ciascuna
\func{write} la posizione corrente sarà cambiata solo nel processo. Se la
scrittura eccede la dimensione corrente del file questo verrà esteso
- automaticamente con l'aggiornamento del campo \var{i\_size}
- nell'inode\index{inode}.
-\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
- effettuata una scrittura la posizione corrente viene prima impostata alla
- dimensione corrente del file letta dall'inode\index{inode}. Dopo la
- scrittura il file viene automaticamente esteso.
+ automaticamente con l'aggiornamento del campo \var{i\_size} \index{inode}
+ nell'inode.
+\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
+ le volte che viene effettuata una scrittura la posizione corrente viene
+ prima impostata alla dimensione corrente del file letta \index{inode}
+ dall'inode. Dopo la scrittura il file viene automaticamente esteso.
\item l'effetto di \func{lseek} è solo quello di cambiare il campo
- \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non
- c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
- fine del file la posizione viene impostata leggendo la dimensione corrente
- dall'inode\index{inode}.
+ \var{f\_pos} nella struttura \struct{file} della \itindex{file~table}
+ \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
+ si usa per porsi alla fine del file la posizione viene impostata leggendo la
+ dimensione corrente \index{inode} dall'inode.
\end{itemize}
\begin{figure}[htb]
\end{figure}
Il secondo caso è quello in cui due file descriptor di due processi diversi
-puntino alla stessa voce nella \textit{file table}; questo è ad esempio il
-caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
-di una \func{fork} (si ricordi quanto detto in sez.~\ref{sec:proc_fork}). La
-situazione è illustrata in fig.~\ref{fig:file_acc_child}; dato che il processo
-figlio riceve una copia dello spazio di indirizzi del padre, riceverà anche
-una copia di \struct{file\_struct} e relativa tabella dei file aperti.
+puntino alla stessa voce nella \itindex{file~table} \textit{file table};
+questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
+figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
+sez.~\ref{sec:proc_fork}). La situazione è illustrata in
+fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
+dello spazio di indirizzi del padre, riceverà anche una copia di
+\struct{file\_struct} e relativa tabella dei file aperti.
In questo modo padre e figlio avranno gli stessi file descriptor che faranno
riferimento alla stessa voce nella \textit{file table}, condividendo così la
problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
-utilizzare meccanismi di sincronizzazione più complessi (come il \textit{file
- locking} \index{file!locking}, che esamineremo in
+utilizzare meccanismi di sincronizzazione più complessi (come il
+\index{file!locking} \textit{file locking}, che esamineremo in
sez.~\ref{sec:file_locking}).
Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
vari processi devono scrivere alla fine di un file (ad esempio un file di
log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
-fine del file e poi scrivere può condurre ad una
-\itindex{race~condition}\textit{race condition}: infatti può succedere che un
-secondo processo scriva alla fine del file fra la \func{lseek} e la
-\func{write}; in questo caso, come abbiamo appena visto, il file sarà esteso,
-ma il nostro primo processo avrà ancora la posizione corrente impostata con la
-\func{lseek} che non corrisponde più alla fine del file, e la successiva
-\func{write} sovrascriverà i dati del secondo processo.
+fine del file e poi scrivere può condurre ad una \itindex{race~condition}
+\textit{race condition}: infatti può succedere che un secondo processo scriva
+alla fine del file fra la \func{lseek} e la \func{write}; in questo caso, come
+abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
+ancora la posizione corrente impostata con la \func{lseek} che non corrisponde
+più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
+secondo processo.
Il problema è che usare due system call in successione non è un'operazione
atomica; il problema è stato risolto introducendo la modalità
-\const{O\_APPEND}. In questo caso infatti, come abbiamo descritto in
-precedenza, è il kernel che aggiorna automaticamente la posizione alla fine
-del file prima di effettuare la scrittura, e poi estende il file. Tutto questo
-avviene all'interno di una singola system call (la \func{write}) che non
-essendo interrompibile da un altro processo costituisce un'operazione atomica.
+\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
+descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
+alla fine del file prima di effettuare la scrittura, e poi estende il file.
+Tutto questo avviene all'interno di una singola system call (la \func{write})
+che non essendo interrompibile da un altro processo costituisce un'operazione
+atomica.
Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
-creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file
+creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
esiste. In questo caso la sequenza logica porterebbe a verificare prima
l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
-di nuovo avremmo la possibilità di una \textit{race
- condition}\itindex{race~condition} da parte di un altro processo che crea lo
-stesso file fra il controllo e la creazione.
+di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
+ condition} da parte di un altro processo che crea lo stesso file fra il
+controllo e la creazione.
Per questo motivo sono stati introdotti per \func{open} i due flag
\const{O\_CREAT} e \const{O\_EXCL}. In questo modo l'operazione di controllo
si veda sez.~\ref{sec:ipc_file_lock}).
-\subsection{La funzioni \func{sync} e \func{fsync}}
+\subsection{Le funzioni \func{sync} e \func{fsync}}
\label{sec:file_sync}
Come accennato in sez.~\ref{sec:file_close} tutte le operazioni di scrittura
in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
-può essere controllato attraverso il file \file{/proc/sys/vm/bdflush} (per il
-significato dei valori si può leggere la documentazione allegata al kernel in
-\file{Documentation/sysctl/vm.txt}).
+può essere controllato attraverso il file \procfile{/proc/sys/vm/bdflush} (per
+il significato dei valori si può leggere la documentazione allegata al kernel
+in \file{Documentation/sysctl/vm.txt}).
Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
sicuri che i dati di un database sono stati registrati su disco) si possono
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int fsync(int fd)}
- Sincronizza dati e metadati del file \param{fd}
+ Sincronizza dati e meta-dati del file \param{fd}
\funcdecl{int fdatasync(int fd)}
Sincronizza i dati del file \param{fd}.
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 metadati del file (che
+\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 nell'inode\index{inode} che si leggono con \func{fstat},
+altri dati contenuti \index{inode} nell'inode che si leggono con \func{fstat},
come i tempi del file).
Si tenga presente che questo non comporta la sincronizzazione della
delle directory.}
-\subsection{La funzioni \func{dup} e \func{dup2}}
+\subsection{Le funzioni \func{dup} e \func{dup2}}
\label{sec:file_dup}
Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
file descriptor è \textsl{duplicato}, da cui il nome della funzione.
\begin{figure}[htb]
- \centering \includegraphics[width=15cm]{img/filedup}
+ \centering \includegraphics[width=14cm]{img/filedup}
\caption{Schema dell'accesso ai file duplicati}
\label{fig:file_dup}
\end{figure}
\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
+
+\subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
+\label{sec:file_openat}
+
+Un problema che si pone con l'uso della funzione \func{open}, così come per
+molte altre funzioni che accettano come argomenti dei pathname relativi, è
+che, quando un pathname relativo non fa riferimento alla 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}.
+
+Inoltre come già accennato, la directory di lavoro corrente è una proprietà
+del singolo processo; questo significa che quando si lavora con i
+\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
+molti casi in cui sarebbe invece utile che ogni singolo \itindex{thread}
+\textit{thread} avesse la sua directory di lavoro.
+
+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, contraddistinte dal suffisso \texttt{at}, che permettono che
+permettano l'apertura di un file (o le rispettive altre operazioni) usando un
+pathname relativo ad una directory specificata.\footnote{l'introduzione è
+ avvenuta su proposta dello sviluppatore principale delle \acr{glibc} Urlich
+ Drepper; le corrispondenti 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 pathname del tipo di
+ \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste non siano
+funzioni standard esse sono disponibili anche su altri Unix\footnote{oltre al
+ citato Solaris ne è prevista l'inclusione anche in BSD.} e sono state
+proposte per l'inclusione nello standard POSIX.1, nelle future revisioni dello
+stesso.
+
+L'idea è che si apra prima la directory che si vuole usare come base dei
+pathname relativo, e si passi il file descriptor alla funzione che userà
+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 anche una directory di lavoro diversa per ciascuno di essi.} Con
+queste funzioni si possono anche ottenere grossi aumenti di prestazioni quando
+si devono eseguire operazioni su delle sezioni di albero dei file che
+prevedono gerarchie molto profonde e grandi quantità di file e directory, dato
+che basta eseguire la risoluzione di un pathname una sola volta (nell'apertura
+della directory) e non per ciascun file che essa contiene.
+
+La sintassi generale di queste nuove funzioni è che esse prendano 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:
+\begin{functions}
+ \headdecl{fcntl.h}
+ \funcdecl{int openat(int dirfd, const char *pathname, int flags)}
+ \funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
+ mode))}
+
+ Apre un file usando come directory di lavoro corrente \param{dirfd}.
+
+ \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
+ errore di \func{open}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \param{dirfd} fa riferimento ad un file.
+ \end{errlist}}
+\end{functions}
+
+In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
+con questa nuova interfaccia, con a fianco la corrispondente funzione
+classica. Tranne che nel caso di \func{faccessat} e \func{unlinkat} tutti i
+loro prototipi 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 riportarli uno per
+ uno.}
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Funzione} & \textbf{Corrispondente} \\
+ \hline
+ \hline
+ \func{faccessat} &\func{access} \\
+ \func{fchmodat} &\func{chmod} \\
+ \func{fchownat} &\func{chown} \\
+ \func{fstatat} &\func{stat} \\
+ \func{futimesat} &\func{utimes} \\
+ \func{linkat} &\func{link} \\
+ \func{mkdirat} &\func{mkdir} \\
+ \func{mknodat} &\func{mknod} \\
+ \func{openat} &\func{open} \\
+ \func{readlinkat}&\func{readlink}\\
+ \func{renameat} &\func{rename} \\
+ \func{symlinkat} &\func{symlink} \\
+ \func{unlinkat} &\func{unlink} \\
+ \func{mkfifoat} &\func{mkfifo} \\
+ \hline
+ \end{tabular}
+ \caption{Corrispondenze fra le nuove funzioni ``\textit{at}'' e le
+ corrispettive funzioni classiche.}
+ \label{tab:file_atfunc_corr}
+\end{table}
+
+% TODO documentare utimesat, introdotta in 2.6.22
+% http://kernelnewbies.org/Linux_2_6_22
+
+Il comportamento delle nuove funzioni è del tutto analogo a quello delle
+corrispettive classiche, con la sola eccezione del fatto che se fra i loro
+argomenti si utilizza un pathname relativo questo sarà risolto rispetto alla
+directory indicata da \param{dirfd}; qualora invece si usi un pathname
+assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
+\param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la risoluzione sarà
+effettuata rispetto alla directory di lavoro corrente del processo.
+
+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
+ pathname assoluto, nel qual caso, come detto, il valore di \param{dirfd}
+ sarà completamente ignorato.}
+
+Come accennato ci sono due eccezioni alla precedente regola, \func{faccessat}
+e \func{unlinkat}, che tratteremo esplicitamente. Dette funzioni, oltre a
+prendere \param{dirfd} come primo argomento aggiuntivo, prendono un ulteriore
+argomento finale \param{flags}, utilizzato come maschera binaria. Nel caso di
+\funcd{faccessat} avremo cioè:
+\begin{functions}
+ \headdecl{unistd.h}
+ \funcdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
+
+ Controlla i permessi di accesso.
+
+ \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
+ errore di \func{access}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \param{dirfd} fa riferimento ad un file.
+ \end{errlist}}
+\end{functions}
+
+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}; questo infatti
+può essere specificato come maschera binaria dei seguenti valori:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\const{AT\_EACCESS}] se impostato esegue il controllo dei permessi
+ usando l'\textsl{user-ID effettivo} invece di quello reale (il comportamento
+ di default, che riprende quello di \func{access}).
+\item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato non esegue la
+ dereferenziazione del link simbolico (il comportamento di default, che
+ riprende quello di \func{access}), ma effettua il controllo sui permessi del
+ link simbolico stesso.
+\end{basedescript}
+
+Nel caso di \func{unlinkat} l'ulteriore argomento \param{flags} viene inserito
+perché detta funzione può comportarsi sia come analogo di \func{unlink} che di
+\func{rmdir}; pertanto il suo prototipo è:
+\begin{functions}
+ \headdecl{fcntl.h}
+ \funcdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
+
+ Rimuove una voce da una directory.
+
+ \bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
+ errore di \func{unlink} o di \func{rmdir} a seconda del valore di
+ \param{flags}, ed in più:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \param{dirfd} fa riferimento ad un file.
+ \end{errlist}}
+\end{functions}
+
+Di default il comportamento di \func{unlinkat} è equivalente a quello che
+avrebbe \func{unlink} applicata a \param{pathname}, fallendo se 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, lo si può assegnare direttamente.}
+essa si comporterà come \func{rmdir}.
+
+
\subsection{La funzione \func{fcntl}}
\label{sec:file_fcntl}
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 file locking
- \index{file!locking} (vedi sez.~\ref{sec:file_locking}).}
+ sez.~\ref{sec:file_asyncronous_operation}) e il \index{file!locking}
+ \textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
Per queste operazioni di manipolazione e di controllo delle varie proprietà e
caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
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
- \textit{close-on-exec}\itindex{close-on-exec}, identificato dalla costante
+ \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.
dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file
descriptor \param{fd}. 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
+ all'identificatore del \itindex{process~group} \textit{process group}. In
caso di errore viene restituito $-1$.
\item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
l'identificatore del processo o del \itindex{process~group} \textit{process
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}.
-\item[\const{F\_GETLEASE}] restituisce il tipo di \textit{file lease}
- \index{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\_GETLEASE}] restituisce il tipo di \index{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 \const{SIGIO} (o altro
segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
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 \textit{file
- locking}\index{file!locking} saranno esaminate in
+sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al
+\index{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}.
specifiche di ogni dispositivo particolare, usando come riferimento il solito
file descriptor. Il prototipo di questa funzione è:
\begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
- Manipola il dispositivo sottostante, usando l'argomento \param{request} per
- specificare l'operazione richiesta ed il terzo argomento (usualmente di tipo
- \param{char * argp} o \param{int argp}) per il trasferimento
- dell'informazione necessaria.
+
+ Esegue l'operazione di controllo specificata da \param{request} sul file
+ descriptor \param{fd}.
\bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
operazioni usano però il valore di ritorno per restituire informazioni. In
ed inoltre \errval{EBADF} e \errval{EFAULT}.}
\end{prototype}
-La funzione serve in sostanza per fare tutte quelle operazioni che non si
-adattano al design dell'architettura dei file e che non è possibile effettuare
-con le funzioni esaminate finora. Esse vengono selezionate attraverso il
-valore di \param{request} e gli eventuali risultati possono essere restituiti
-sia attraverso il valore di ritorno che attraverso il terzo argomento
-\param{argp}. Sono esempi delle operazioni gestite con una \func{ioctl}:
+La funzione serve in sostanza come meccanismo generico per fare tutte quelle
+operazioni che non rientrano nell'interfaccia ordinaria della gestione dei
+file e che non è possibile effettuare con le funzioni esaminate finora. La
+funzione richiede che si passi come primo argomento un file descriptor
+regolarmente aperto, e l'operazione da compiere viene selezionata attraverso
+il valore dell'argomento \param{request}. Il terzo argomento dipende
+dall'operazione prescelta; tradizionalmente è specificato come \code{char *
+ argp}, da intendersi come puntatore ad un area di memoria
+generica,\footnote{all'epoca della creazione di questa funzione infatti ancora
+ non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
+essere omesso, e per altre è un semplice intero.
+
+Normalmente la funzione ritorna zero in caso di successo e $-1$ in caso di
+errore, ma per alcune operazione il valore di ritorno, che nel caso viene
+impostato ad un valore positivo, può essere utilizzato come parametro di
+uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
+terzo argomento.
+
+Data la genericità dell'interfaccia non è possibile classificare in maniera
+sistematica le operazioni che si possono gestire con \func{ioctl}, un breve
+elenco di alcuni esempi di esse è il seguente:
\begin{itemize*}
\item il cambiamento dei font di un terminale.
\item l'esecuzione di una traccia audio di un CDROM.
\item l'impostazione della velocità trasmissione di una linea seriale.
\item l'impostazione della frequenza e della durata dei suoni emessi dallo
speaker.
+\item l'impostazione degli attributi dei file su un filesystem
+ ext2.\footnote{i comandi \texttt{lsattr} e \texttt{chattr} fanno questo con
+ delle \func{ioctl} dedicate, usabili solo su questo filesystem e derivati
+ successivi (come ext3).}
\end{itemize*}
-In generale ogni dispositivo ha un suo insieme di possibili diverse operazioni
-effettuabili attraverso \func{ioctl}, che sono definite nell'header file
-\file{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui fanno
+In generale ogni dispositivo ha un suo insieme di operazioni specifiche
+effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
+file \file{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui fanno
riferimento. Infatti anche se in genere i valori di \param{request} sono
opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
Data la assoluta specificità della funzione, il cui comportamento varia da
dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
sommaria delle sue caratteristiche; torneremo ad esaminare in
-seguito\footnote{per l'uso con i socket si veda
- sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici
-(ad esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
-quasi tutte le implementazioni di Unix), qui riportiamo solo i valori di
-alcuni comandi che sono definiti per ogni file:
+seguito\footnote{per l'uso di \func{ioctl} con i socket si veda
+ sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici (ad
+esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
+quasi tutte le implementazioni di Unix), qui riportiamo solo l'elenco delle
+operazioni che sono predefinite per qualunque file,\footnote{in particolare
+ queste operazioni sono definite nel kernel a livello generale, e vengono
+ sempre interpretate per prime, per cui, come illustrato in \cite{LinDevDri},
+ eventuali operazioni specifiche che usino lo stesso valore verrebbero
+ ignorate.} caratterizzate dal prefisso \texttt{FIO}:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{FIOCLEX}] Imposta il flag di
- \textit{close-on-exec}\itindex{close-on-exec}.
-\item[\const{FIONCLEX}] Cancella il flag di
- \textit{close-on-exec}\itindex{close-on-exec}.
-\item[\const{FIOASYNC}] Abilita l'I/O asincrono.
-\item[\const{FIONBIO}] Abilita l'I/O in modalità non bloccante.
+\item[\const{FIOCLEX}] imposta il flag di \itindex{close-on-exec}
+ \textit{close-on-exec} sul file, in questo caso, essendo usata come
+ operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
+ eventuale valore viene ignorato.
+\item[\const{FIONCLEX}] cancella il flag di \itindex{close-on-exec}
+ \textit{close-on-exec} sul file, in questo caso, essendo usata come
+ 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
+ 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).
+\item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
+ bloccante; 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).
+\item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
+ \const{SIGURG} e \const{SIGIO} generati sul file; il terzo argomento deve
+ essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
+ valore specifica il PID del processo.
+\item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
+ \const{SIGURG} e \const{SIGIO} generati sul file; il terzo argomento deve
+ essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
+ scritto il PID del processo.
+\item[\const{FIONREAD}] legge il numero di byte disponibili in lettura sul
+ file descriptor;\footnote{questa operazione è disponibile solo su alcuni
+ file descriptor, in particolare sui socket (vedi
+ sez.~\ref{sec:sock_ioctl_IP}) o sui file descriptor di \textit{epoll}
+ (vedi sez.~\ref{sec:file_epoll}).} il terzo argomento deve essere un
+ puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
+ il valore.
+\item[\const{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
+ directory, mentre se applicata ad un dispositivo fallisce con un errore di
+ \errcode{ENOTTY}; il terzo argomento deve essere un puntatore ad un intero
+ (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
\end{basedescript}
-relativi ad operazioni comunque eseguibili anche attraverso \func{fcntl}.
+% TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
-% TODO estendere la lista delle ioctl
+Si noti però come la gran parte di queste operazioni specifiche dei file (per
+essere precisi le prime sei dell'elenco) siano effettuabili in maniera
+generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
+molto simili e la presenza di questa sovrapposizione è principalmente dovuta
+al fatto che alle origini di Unix i progettisti considerarono che era
+necessario trattare diversamente rispetto alle operazione di controllo delle
+modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
+\func{ioctl} per i secondi;\footnote{all'epoca tra l'altro i dispositivi che
+ usavano \func{ioctl} erano sostanzialmente solo i terminali, il che spiega
+ l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
+ma le due funzioni sono rimaste.
-%%% Local Variables:
-%%% mode: latex
-%%% TeX-master: "gapil"
-%%% End:
-
% LocalWords: descriptor system call cap like kernel sez l'inode inode VFS tab
% LocalWords: process table struct files flags pos all'inode dentry fig shell
% LocalWords: error POSIX STDIN FILENO STDOUT STDERR unistd read write lseek
% LocalWords: fdatasync fstat ext dup oldfd newfd DUPFD cmd long arg flock pid
% LocalWords: SETFD GETFD GETFL SETFL GETLK SETLK SETLKW GETOWN group SIGURG
% LocalWords: SETOWN GETSIG SETSIG sigaction SIGINFO siginfo SETLEASE lease is
-% LocalWords: truncate GETLEASE NOTIFY all'I AND ACCMODE ioctl everything argp
-% LocalWords: framebuffer request ENOTTY CDROM nell'header magic number
-% LocalWords: FIOCLEX FIONCLEX FIOASYNC FIONBIO
+% LocalWords: truncate GETLEASE NOTIFY AND ACCMODE ioctl everything argp all'I
+% LocalWords: framebuffer request ENOTTY CDROM nell'header magic number openat
+% LocalWords: FIOCLEX FIONCLEX FIOASYNC FIONBIO NOATIME redirezione FIOSETOWN
+% LocalWords: FIOGETOWN FIONREAD mkdirat thread Solaris mkdir at Urlich proc
+% LocalWords: Drepper path dirfd faccessat unlinkat access fchmodat chmod Di
+% LocalWords: fchownat chown fstatat futimesat utimes linkat mknodat mknod
+% LocalWords: readlinkat readlink renameat rename symlinkat symlink unlink
+% LocalWords: mkfifoat mkfifo FDCWD EACCESS dereferenziazione rmdir REMOVEDIR
+% LocalWords: epoll lsattr chattr FIOQSIZE
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / blobdiff