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 \textit{file descriptor}\index{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 è
\subsection{L'architettura dei \textit{file descriptor}}
\label{sec:file_fd}
-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 \secref{sec:file_vfs_work}). Questo si fa aprendo il file con
-la funzione \func{open} che provvederà a localizzare l'inode del file e
-inizializzare i puntatori che rendono disponibili le funzioni che il VFS mette
-a disposizione (riportate in \tabref{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.
+\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 \secref{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
+\tabref{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.
All'interno di ogni processo i file aperti sono identificati da un intero non
-negativo, chiamato appunto \textit{file descriptor}\index{file descriptor}.
+negativo, chiamato appunto \textit{file descriptor}.
Quando un file viene aperto la funzione \func{open} restituisce questo numero,
tutte le ulteriori operazioni saranno compiute specificando questo stesso
valore come argomento alle varie funzioni dell'interfaccia.
\item una tabella che contiene un puntatore alla relativa voce nella
\textit{file table} per ogni file aperto.
\end{itemize*}
-il \textit{file descriptor}\index{file descriptor} in sostanza è l'intero
-positivo che indicizza quest'ultima tabella.
+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
\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\footnote{nel kernel 2.4.x si è in realtà passati
- ad un puntatore ad una struttura \var{dentry} che punta a sua volta
- all'inode passando per la nuova struttura del VFS.} del file.
+\item un puntatore all'inode\index{inode}\footnote{nel kernel 2.4.x si è in
+ realtà passati ad un puntatore ad una struttura \var{dentry} che punta a
+ sua volta all'inode\index{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 \secref{sec:file_vfs_work}} che si possono usare
% sul file.
\end{figure}
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}.
+ descriptor}.
+\index{file!descriptor|)}
+
+
\subsection{I file standard}
\label{sec:file_std_descr}
-Come accennato i \textit{file descriptor}\index{file descriptor} non sono
-altro che un indice nella tabella dei file aperti di ciascun processo; per
-questo motivo essi vengono assegnati in successione tutte le volte che si apre
-un nuovo file (se non ne è stato chiuso nessuno in precedenza).
+Come accennato i \textit{file descriptor} non sono altro che un indice nella
+tabella dei file aperti di ciascun processo; per questo motivo essi vengono
+assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
+stato chiuso nessuno in precedenza).
In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
processo viene lanciato con almeno tre file aperti. Questi, per quanto appena
-detto, avranno come \textit{file descriptor}\index{file descriptor} i valori
+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à.
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).
+stesso inode\index{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
\const{O\_CREAT} e \const{O\_EXCL}.
\item[\errcode{EISDIR}] \var{pathname} indica una directory e si è tentato
l'accesso in scrittura.
- \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e \var{pathname}
- non è una directory.
- \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o \const{O\_WRONLY}
- ed il file è una fifo che non viene letta da nessun processo o
- \var{pathname} è un file di dispositivo ma il dispositivo è assente.
+ \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
+ \var{pathname} non è una directory.
+ \item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o
+ \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
+ processo o \var{pathname} è un file di dispositivo ma il dispositivo è
+ assente.
\item[\errcode{ENODEV}] \var{pathname} si riferisce a un file di dispositivo
che non esiste.
\item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
pathname o si è indicato \const{O\_NOFOLLOW} e \var{pathname} è un link
simbolico.
\end{errlist}
- ed inoltre \const{EACCES}, \const{ENAMETOOLONG}, \const{ENOENT},
- \const{EROFS}, \const{EFAULT}, \const{ENOSPC}, \const{ENOMEM},
- \const{EMFILE} e \const{ENFILE}.}
+ ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM},
+ \errval{EMFILE} e \errval{ENFILE}.}
\end{functions}
La funzione apre il file, usando il primo file descriptor libero, e crea
\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 race
+ \textsl{file di lock}\index{file!di lock} possono incorrere in una race
condition\index{race condition}. Si consiglia come alternativa di usare un
file con un nome univoco e la funzione \func{link} per verificarne
l'esistenza (vedi \secref{sec:ipc_file_lock}).}
\item[\errcode{EBADF}] \var{fd} non è un descrittore valido.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
- ed inoltre \const{EIO}.}
+ ed inoltre \errval{EIO}.}
\end{prototype}
-La chiusura di un file rilascia ogni blocco (il \textit{file locking} è
-trattato in \secref{sec:file_locking}) che il processo poteva avere acquisito
-su di esso; se \var{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.
+La chiusura di un file rilascia ogni blocco (il \textit{file
+ locking}\index{file!locking} è trattato in \secref{sec:file_locking}) che il
+processo poteva avere acquisito su di esso; se \var{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.
Si ricordi che quando un processo termina anche tutti i suoi file descriptor
vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
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 o una fifo.
+ \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket\index{socket} o una
+ fifo.
\item[\errcode{EINVAL}] \param{whence} non è un valore valido.
\end{errlist}
- ed inoltre \const{EBADF}.}
+ ed inoltre \errval{EBADF}.}
\end{functions}
La nuova posizione è impostata usando il valore specificato da \param{offset},
\item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
era aperto il file in modalità \const{O\_NONBLOCK}.
\end{errlist}
- ed inoltre \const{EBADF}, \const{EIO}, \const{EISDIR}, \const{EBADF},
- \const{EINVAL} e \const{EFAULT} ed eventuali altri errori dipendenti dalla
+ ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
+ \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
natura dell'oggetto connesso a \var{fd}.}
\end{prototype}
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,
-come vedremo in \secref{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.
+Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un
+socket\index{socket}, come vedremo in \secref{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.
In realtà anche le due condizioni segnalate dagli errori \errcode{EINTR} e
\errcode{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è
\item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
era aperto il file in modalità \const{O\_NONBLOCK}.
\end{errlist}
- ed inoltre \const{EBADF}, \const{EIO}, \const{EISDIR}, \const{EBADF},
- \const{ENOSPC}, \const{EINVAL} e \const{EFAULT} ed eventuali altri errori
+ ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
+ \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
dipendenti dalla natura dell'oggetto connesso a \var{fd}.}
\end{prototype}
\begin{figure}[htb]
\centering
- \includegraphics[width=13cm]{img/filemultacc}
+ \includegraphics[width=15cm]{img/filemultacc}
\caption{Schema dell'accesso allo stesso file da parte di due processi
diversi}
\label{fig:file_mult_acc}
situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
processo avrà una sua voce nella \textit{file table} referenziata da un
diverso file descriptor nella sua \var{file\_struct}. Entrambe le voci nella
-\textit{file table} faranno però riferimento allo stesso inode su disco.
+\textit{file table} faranno però riferimento allo stesso inode\index{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
\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.
+ 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. 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 \var{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.
+ dimensione corrente del file letta dall'inode\index{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 \var{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}.
\end{itemize}
\begin{figure}[htb]
\centering
- \includegraphics[width=13cm]{img/fileshar}
+ \includegraphics[width=15cm]{img/fileshar}
\caption{Schema dell'accesso ai file da parte di un processo figlio}
\label{fig:file_acc_child}
\end{figure}
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}, che esamineremo in \secref{sec:file_locking}).
+ locking}\index{file!locking}, che esamineremo in \secref{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
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 race condition\index{race condition} da
\item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
sincronizzazione.
\end{errlist}
- ed inoltre \const{EBADF}, \const{EROFS} e \const{EIO}.}
+ ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
\end{functions}
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
riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
-altri dati contenuti nell'inode che si leggono con \var{fstat} come i tempi
-del file).
+altri dati contenuti nell'inode\index{inode} che si leggono con \var{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
\textsl{duplicato}, da cui il nome della funzione.
\begin{figure}[htb]
- \centering \includegraphics[width=13cm]{img/filedup}
+ \centering \includegraphics[width=15cm]{img/filedup}
\caption{Schema dell'accesso ai file duplicati}
\label{fig:file_dup}
\end{figure}
\end{prototype}
\noindent e qualora il file descriptor \param{newfd} sia già aperto (come
avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
-sarà prima chiuso e poi duplicato.
+sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
+allo stesso valore per il file descriptor).
La duplicazione dei file descriptor può essere effettuata anche usando la
funzione di controllo dei file \func{fnctl} (che esamineremo in
-\secref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}.
+\secref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
+la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
+\param{newfd} diventa equivalente a \func{dup}.
-L'operazione ha la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0
-come valore per \param{newfd} diventa equivalente a \func{dup}. La sola
-differenza, a parte i codici di errore, è che \func{dup2} chiude il nuovo file
-se è già aperto mentre \func{fcntl} apre il primo disponibile con un valore
-superiore, per cui per poterla usare come \func{dup2} occorrerebbe prima
-effettuare una \func{close}, perdendo l'atomicità dell'operazione.
+La sola differenza fra le due funzioni\footnote{a parte la sistassi ed i
+ diversi codici di errore.} è che \func{dup2} chiude il file descriptor
+\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
+effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
+file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
+\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
\subsection{La funzione \func{fcntl}}
Oltre alle operazioni base esaminate in \secref{sec:file_base_func} esistono
tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
-descriptor. Per queste operazioni di manipolazione delle varie proprietà di un
-file descriptor viene usata la funzione \func{fcntl} il cui prototipo è:
+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
+ gesticono con questa funzione l'I/O asincrono (vedi
+ \secref{sec:file_asyncronous_io}) e il file locking\index{file!locking}
+ (vedi \secref{sec:file_locking}).}
+
+Per queste operazioni di manipolazione e di controllo su proprietà e
+caratteristiche un file descriptor, viene usata la funzione \func{fcntl}, il
+cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{fcntl.h}
l'attesa viene interrotta da un segnale la funzione restituisce -1 e imposta
\var{errno} a \errcode{EINTR} (questa funzionalità è trattata in dettaglio in
\secref{sec:file_posix_lock}).
-\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o il process
- group che è preposto alla ricezione dei segnali \const{SIGIO} e
- \const{SIGURG} per gli eventi associati al file descriptor \var{fd}. Il
- process group è restituito come valore negativo.
-\item[\const{F\_SETOWN}] imposta il processo o process group che riceverà i
+\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
+ l'identificatore del process group\footnote{i \texttt{process group} sono
+ (vedi \secref{sec:sess_proc_group}) sono raggruppamenti di processi usati
+ nel controllo di sessione; a ciascuno di essi è associato un
+ identificatore (un numero positivo analogo al \acr{pid}).} che è preposto
+ alla ricezione dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi
+ associati al file descriptor \var{fd}. Nel caso di un process group viene
+ restituito un valore negativo il cui valore assoluto corrisponde
+ all'identificatore del process group.
+\item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
+ l'identificatore del processo o del \textit{process group} che riceverà i
segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file
- descriptor \var{fd}. I process group sono impostati usando valori negativi.
-\item[\const{F\_GETSIG}] restituisce il valore del segnale mandato quando ci
- sono dati disponibili in input su un file descriptor aperto o impostato in
- I/O asincrono. Il valore 0 indica il valore predefinito (che è
- \const{SIGIO}), un valore diverso da zero indica il segnale richiesto, (che
- può essere lo stesso \const{SIGIO}).
+ descriptor \var{fd}. Come per \const{F\_GETOWN}, per impostare un process
+ group si deve usare per \param{arg} un valore negativo, il cui valore
+ assoluto corrisponde all'identificatore del 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 \secref{sec:file_asyncronous_io}). Il valore 0
+ indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
+ zero indica il segnale richiesto, (che può essere anche lo stesso
+ \const{SIGIO}).
\item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
possibile effettuare I/O sul file descriptor in caso di I/O asincrono. Il
valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
poter essere affrontate in dettaglio a questo punto; saranno riprese più
avanti quando affronteremo le problematiche ad esse relative (in particolare
-riprenderemo le tematiche relative all'I/O asincrono in
-\secref{sec:file_asyncronous_io} e quelle relative al \textit{file locking} in
+le tematiche relative all'I/O asincrono sono trattate in maniera esaustiva in
+\secref{sec:file_asyncronous_io} mentre quelle relative al \textit{file
+ locking}\index{file!locking} saranno esaminate in
\secref{sec:file_locking}).
-Per determinare le modalità di accesso inoltre è necessario estrarre i bit di
-accesso (ottenuti con il comando \const{F\_GETFL}); infatti la definizione
-corrente non assegna bit separati a \const{O\_RDONLY}, \const{O\_WRONLY} e
-\const{O\_RDWR},\footnote{posti rispettivamente ai valori 0, 1 e 2.} per cui il
-valore si ottiene eseguendo un AND binario del valore di ritorno di
-\func{fcntl} con la maschera \const{O\_ACCMODE} anch'essa definita in
-\file{fcntl.h}.
+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
+comando \const{F\_GETFL}) è necessario estrarre i bit corripondenti nel
+\textit{file status flag} che si è ottenuto. Infatti la definizione corrente
+di quest'ultimo non assegna bit separati alle tre diverse modalità
+\const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
+ queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
+motivo il valore della modalità di accesso corrente si ottiene eseguendo un
+AND binario del valore di ritorno di \func{fcntl} con la maschera
+\const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
+accesso dal \textit{file status flag}.
\label{sec:file_ioctl}
Benché il concetto di \textit{everything is a file} si sia dimostratato molto
-valido anche per l'interazione con i più vari dispositivi, con cui si può
-interagire con le stesse funzioni usate per i normali file di dati,
-esisteranno sempre caratteristiche peculiari, specifiche dell'hardware e della
-funzionalità che ciascuno di essi provvede, 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).
-
-Per questo motivo l'architettura del sistema ha previsto l'esistenza di una
-funzione speciale, \func{ioctl}, con cui poter compiere operazioni specifiche
-per ogni singolo dispositivo. Il prototipo di questa funzione è:
+valido anche per l'interazione con i dispositivi più vari, fornendo una
+interfaccia che permette di interagire con essi tramite le stesse funzioni
+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).
+
+Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
+di una funzione apposita, \func{ioctl}, con cui poter compiere le operazioni
+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 il parametro \param{request} per
- specificare l'operazione richiesta e il terzo parametro (usualmente di tipo
+ specificare l'operazione richiesta ed il terzo parametro (usualmente di tipo
\param{char * argp} o \param{int argp}) per il trasferimento
dell'informazione necessaria.
\item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
validi.
\end{errlist}
- ed inoltre \const{EBADF} e \const{EFAULT}.}
+ ed inoltre \errval{EBADF} e \errval{EFAULT}.}
\end{prototype}
La funzione serve in sostanza per fare tutte quelle operazioni che non si
opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
definizione delle macro da usare per \param{request}, in modo da essere
- sicuri che essi siano sempre diversi, ed il loro uso causi al più un errore.
- Si veda il capitolo quinto di \cite{LinDevDri} per una trattazione
- dettagliata dell'argomento.} in alcuni casi, relativi a valori assegnati
-prima che questa differenziazione diventasse pratica corrente si potrebbe
-avere
-
-Per questo motivo non è possibile fare altro che darne una descrizione
-generica; torneremo ad esaminare in seguito 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 che sono definiti per ogni file:
+ sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi
+ causi al più un errore. Si veda il capitolo quinto di \cite{LinDevDri} per
+ una trattazione dettagliata dell'argomento.} così che la richiesta di
+operazioni relative ad altri dispositivi usualmente provoca il ritorno della
+funzione con una condizione di errore, in alcuni casi, relativi a valori
+assegnati prima che questa differenziazione diventasse pratica corrente, si
+potrebbero usare valori validi anche per il dispositivo corrente, con effetti
+imprevedibili o indesiderati.
+
+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 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:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{FIOCLEX}] Imposta il bit di \textit{close on exec}.
\item[\const{FIONCLEX}] Cancella il bit di \textit{close on exec}.
projects / gapil.git / blobdiff