X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileunix.tex;h=6f9334df6dbf7e9fe4610bdb76afa858af1ba646;hp=b4e7b5705a16c2a06b3cfb0001880d285f588150;hb=d25090faca15102552d77c38161a8a34b0bac41e;hpb=ff2d0141751ed62ef56e5bfd226c589311b8b669 diff --git a/fileunix.tex b/fileunix.tex index b4e7b57..6f9334d 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -1,6 +1,6 @@ %% fileunix.tex %% -%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2003 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 "Prefazione", @@ -50,10 +50,10 @@ 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. -Per capire come funziona il meccanismo occorre spiegare a grandi linee come è -che il kernel gestisce l'interazione fra processi e file. Il kernel mantiene -sempre un elenco dei processi attivi nella cosiddetta \textit{process table} -ed un elenco dei file aperti nella \textit{file table}. +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 \textit{process table} ed un +elenco dei file aperti nella \textit{file table}. La \textit{process table} è una tabella che contiene una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è costituita da una @@ -129,7 +129,7 @@ quindi alla lettura della tastiera). Il secondo file inviati i dati in uscita (sempre nel caso della shell, è associato all'uscita del terminale, e quindi alla scrittura sullo schermo). Il terzo è lo \textit{standard error}, su cui viene inviato l'output relativo agli errori, -ed è anch'esso associato all'uscita del termininale. Lo standard POSIX.1 +ed è anch'esso associato all'uscita del terminale. Lo standard POSIX.1 provvede tre costanti simboliche, definite nell'header \file{unistd.h}, al posto di questi valori numerici: \begin{table}[htb] @@ -186,7 +186,7 @@ system call del kernel. \subsection{La funzione \func{open}} \label{sec:file_open} -La funzione \func{open} è la funzione fondamentale per accedere ai file, ed è +La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è quella che crea l'associazione fra un pathname ed un file descriptor, il suo prototipo è: \begin{functions} @@ -253,7 +253,7 @@ usato sempre il file descriptor con il valore pi valore specifica anche una modalità di operazione (vedi sotto), e comporta che \func{open} ritorni immediatamente (l'opzione ha senso solo per le fifo, torneremo questo in \secref{sec:ipc_named_pipe}). \\ - \const{O\_NOCTTY} & se \param{pathname} si riferisce ad un device di + \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 \secref{sec:sess_ctrl_term}). \\ \const{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi @@ -300,7 +300,7 @@ usato sempre il file descriptor con il valore pi \func{write} bloccherà fino al completamento della scrittura di tutti dati sul sull'hardware sottostante.\\ \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\ - \const{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei + \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è disponibile per il singolo file ma come opzione per il filesystem in fase di montaggio.\\ @@ -317,9 +317,10 @@ usato sempre il file descriptor con il valore pi file con un nome univoco e la funzione \func{link} per verificarne l'esistenza (vedi \secref{sec:ipc_file_lock}).} -\footnotetext[3]{\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[3]{\textit{Denial of Service}\index{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.} \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 @@ -335,20 +336,17 @@ descriptor che si otterr alcune applicazioni per sostituire i file corrispondenti ai file standard visti in \secref{sec:file_std_descr}: se ad esempio si chiude lo standard input e si apre subito dopo un nuovo file questo diventerà il nuovo standard -input (avrà cioè il file descriptor 0). - -Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo -sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in -\secref{sec:file_sharing}). Il nuovo file descriptor è impostato per restare -aperto attraverso una \func{exec} (come accennato in \secref{sec:proc_exec}) e -l'offset è impostato all'inizio del file. - -L'argomento \param{mode} specifica i permessi con cui il file viene -eventualmente creato; i valori possibili sono gli stessi già visti in -\secref{sec:file_perm_overview} e possono essere specificati come OR binario -delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi sono -filtrati dal valore di \var{umask} (vedi \secref{sec:file_umask}) per il -processo. +input (avrà cioè il file descriptor 0). Il nuovo file descriptor non è +condiviso con nessun altro processo (torneremo sulla condivisione dei file, in +genere accessibile dopo una \func{fork}, in \secref{sec:file_sharing}) ed è +impostato per restare aperto attraverso una \func{exec} (come accennato in +\secref{sec:proc_exec}); l'offset è impostato 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 \secref{sec:file_perm_overview} +e possono essere specificati come OR binario delle costanti descritte in +\tabref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di +\var{umask} (vedi \secref{sec:file_umask}) 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 @@ -356,38 +354,38 @@ il flag di stato del file (o \textit{file status flag}), che campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema di \figref{fig:file_proc_file}). Essi sono divisi in tre categorie principali: -\begin{itemize} +\begin{itemize*} \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità si accederà al file: i valori possibili sono lettura, scrittura o lettura/scrittura. Uno di questi bit deve essere sempre specificato quando si apre un file. Vengono impostati alla chiamata da \func{open}, e possono - essere riletti con una \func{fcntl} (fanno parte del \textit{file status - flag}), ma non possono essere modificati. + essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}), + ma non possono essere modificati. \item \textsl{i bit delle modalità di apertura}: permettono di specificare alcune delle caratteristiche del comportamento di \func{open} quando viene eseguita. Hanno effetto solo al momento della chiamata della funzione e non sono memorizzati né possono essere riletti. \item \textsl{i bit delle modalità di operazione}: permettono di specificare alcune caratteristiche del comportamento delle future operazioni sul file - (come la \func{read} o la \func{write}). Anch'essi fanno parte del - \textit{file status flag}. Il loro valore è impostato alla chiamata di - \func{open}, ma possono essere riletti e modificati (insieme alle - caratteristiche operative che controllano) con una \func{fcntl}. -\end{itemize} + (come \func{read} o \func{write}). Anch'essi fan parte del \textit{file + status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma + possono essere riletti e modificati (insieme alle caratteristiche operative + che controllano) con una \func{fcntl}. +\end{itemize*} -In \tabref{tab:file_open_flags} si sono riportate, ordinate e divise fra loro +In \tabref{tab:file_open_flags} sono riportate, ordinate e divise fra loro secondo le tre modalità appena elencate, le costanti mnemoniche associate a -ciascuno di questi bit. Dette costanti possono essere combinate fra di loro -con un OR aritmetico per costruire il valore (in forma di maschera binaria) -dell'argomento \param{flags} da passare alla \func{open} per specificarne il -comportamento. I due flag \const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono -estensioni specifiche di Linux, e deve essere definita la macro -\macro{\_GNU\_SOURCE} per poterli usare. +ciascuno di questi bit. Dette costanti possono essere combinate fra loro con +un OR aritmetico per costruire il valore (in forma di maschera binaria) +dell'argomento \param{flags} da passare alla \func{open}. I due flag +\const{O\_NOFOLLOW} e \const{O\_DIRECTORY} sono estensioni specifiche di +Linux, e deve essere definita la macro \macro{\_GNU\_SOURCE} per poterli +usare. Nelle prime versioni di Unix i valori di \param{flag} specificabili per \func{open} erano solo quelli relativi alle modalità di accesso del file. Per questo motivo per creare un nuovo file c'era una system call apposita, -\func{creat}, il cui prototipo è: +\funcd{creat}, il cui prototipo è: \begin{prototype}{fcntl.h} {int creat(const char *pathname, mode\_t mode)} Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del @@ -400,13 +398,13 @@ programmi. \subsection{La funzione \func{close}} \label{sec:file_close} -La funzione \func{close} permette di chiudere un file, in questo modo il file +La funzione \funcd{close} permette di chiudere un file, in questo modo il file descriptor ritorna disponibile; il suo prototipo è: \begin{prototype}{unistd.h}{int close(int fd)} Chiude il descrittore \param{fd}. \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore, - ed in questo caso \var{errno} assumerà uno dei valori: + con \var{errno} che assume i valori: \begin{errlist} \item[\errcode{EBADF}] \param{fd} non è un descrittore valido. \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale. @@ -454,14 +452,14 @@ 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 \func{lseek}, il cui prototipo è: +ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{unistd.h} \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)} Imposta la posizione attuale nel file. - \bodydesc{La funzione ritorna valore della posizione corrente in caso di + \bodydesc{La funzione ritorna il valore della posizione corrente in caso di successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} @@ -491,20 +489,19 @@ seguenti valori\footnote{per compatibilit Come accennato in \secref{sec:file_file_size} con \func{lseek} è possibile impostare la posizione corrente anche oltre la fine del file, e alla -successiva scrittura il file sarà esteso. La chiamata non causa nessuna -attività di input/output, si limita a modificare la posizione corrente nel -kernel (cioè \var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}). - -Dato che la funzione ritorna la nuova posizione, usando il valore zero per -\param{offset} si può riottenere la posizione corrente nel file chiamando la -funzione con \code{lseek(fd, 0, SEEK\_CUR)}. +successiva scrittura il file sarà esteso. La chiamata non causa nessun accesso +al file, si limita a modificare la posizione corrente (cioè il valore +\var{f\_pos} in \param{file}, vedi \figref{fig:file_proc_file}). Dato che la +funzione ritorna la nuova posizione, usando il valore zero per \param{offset} +si può riottenere la posizione corrente nel file chiamando la funzione con +\code{lseek(fd, 0, SEEK\_CUR)}. Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che 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 \textit{race condition} -\index{race condition}, vedi \secref{sec:file_atomic}). +(questa è una potenziale sorgente di +\textit{race condition}\index{race condition}, vedi \secref{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 @@ -521,8 +518,8 @@ indefinito. \label{sec:file_read} -Una volta che un file è stato aperto (con il permesso in lettura) su possono -leggere i dati che contiene utilizzando la funzione \func{read}, il cui +Una volta che un file è stato aperto (con il permesso in lettura) si possono +leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui prototipo è: \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)} @@ -545,24 +542,21 @@ prototipo La funzione tenta di leggere \param{count} byte a partire dalla posizione corrente nel file. Dopo la lettura la posizione sul file è spostata automaticamente in avanti del numero di byte letti. Se \param{count} è zero la -funzione restituisce zero senza nessun altro risultato. - -Si deve sempre tener presente che non è detto che la funzione \func{read} -restituisca sempre il numero di byte richiesto, ci sono infatti varie ragioni -per cui la funzione può restituire un numero di byte inferiore; questo è un -comportamento normale, e non un errore, che bisogna sempre tenere presente. +funzione restituisce zero senza nessun altro risultato. Si deve sempre tener +presente che non è detto che la funzione \func{read} restituisca sempre il +numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione +può restituire un numero di byte inferiore; questo è un comportamento normale, +e non un errore, che bisogna sempre tenere presente. La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte di quanto il file ne contenga. In questo caso il file viene letto fino alla sua fine, e la funzione ritorna regolarmente il numero di byte letti -effettivamente. - -Raggiunta la fine del file, alla ripetizione di un'operazione di lettura, -otterremmo il ritorno immediato di \func{read} con uno zero. La condizione di -raggiungimento della fine del file non è un errore, e viene segnalata appunto -da un valore di ritorno di \func{read} nullo. Ripetere ulteriormente la -lettura non avrebbe nessun effetto se non quello di continuare a ricevere zero -come valore di ritorno. +effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione +di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La +condizione di raggiungimento della fine del file non è un errore, e viene +segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere +ulteriormente la lettura non avrebbe nessun effetto se non quello di +continuare a ricevere zero come valore di ritorno. Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere un numero di byte letti inferiore a quello richiesto, ma questo non è vero @@ -576,20 +570,19 @@ 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 \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. +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} è bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in tal caso l'azione da intraprendere è quella di rieseguire la funzione. -Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}. - -La seconda si verifica quando il file è in modalità non bloccante (vedi +Torneremo in dettaglio sull'argomento in \secref{sec:sig_gen_beha}. La +seconda si verifica quando il file è in modalità non bloccante (vedi \secref{sec:file_noblocking}) e non ci sono dati in ingresso: la funzione -allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{sotto - BSD per questo errore viene usata la costante \errcode{EWOULDBLOCK}, in - Linux, con le glibc, questa è sinonima di \errcode{EAGAIN}.} che indica -soltanto che occorrerà provare a ripetere la lettura. +allora ritorna immediatamente con un errore \errcode{EAGAIN}\footnote{BSD usa + per questo errore la costante \errcode{EWOULDBLOCK}, in Linux, con le + \acr{glibc}, questa è sinonima di \errcode{EAGAIN}.} che indica soltanto che +occorrerà provare a ripetere la lettura. La funzione \func{read} è una delle system call fondamentali, esistenti fin dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix @@ -599,7 +592,7 @@ dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix 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 \secref{sec:intro_opengroup}) è stata introdotta la -definizione di un'altra funzione di lettura, \func{pread}, il cui prototipo è: +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)} @@ -612,7 +605,7 @@ posizione \param{offset}, nel buffer \param{buf}. \end{prototype} \noindent che però diventa accessibile solo con la definizione della macro: \begin{verbatim} - #define _XOPEN_SOURCE 500 +#define _XOPEN_SOURCE 500 \end{verbatim} Questa funzione serve quando si vogliono leggere dati dal file senza @@ -628,7 +621,7 @@ condivisa da processi diversi (vedi \secref{sec:file_sharing}). Il valore di \label{sec:file_write} Una volta che un file è stato aperto (con il permesso in scrittura) su può -scrivere su di esso utilizzando la funzione \func{write}, il cui prototipo è: +scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è: \begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)} Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}. @@ -645,10 +638,10 @@ scrivere su di esso utilizzando la funzione \func{write}, il cui prototipo chiuso in lettura; in questo caso viene anche generato il segnale \const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la funzione ritorna questo errore. - \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di - aver potuto scrivere qualsiasi dato. - \item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si - era aperto il file in modalità \const{O\_NONBLOCK}. + \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver + potuto scrivere qualsiasi dato. + \item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in + modalità \const{O\_NONBLOCK}. \end{errlist} ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF}, \errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori @@ -669,7 +662,7 @@ Per i file ordinari il numero di byte scritti indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo stesso comportamento di \func{read}. -Anche per \func{write} lo standard Unix98 definisce un'analoga \func{pwrite} +Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite} per scrivere alla posizione indicata senza modificare la posizione corrente nel file, il suo prototipo è: \begin{prototype}{unistd.h} @@ -712,7 +705,7 @@ confronti dell'accesso allo stesso file da parte di processi diversi. \label{fig:file_mult_acc} \end{figure} -Il primo caso è quello in cui due processi diversi che aprono lo stesso file +Il primo caso è quello in cui due processi diversi aprono lo stesso file su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun processo avrà una sua voce nella \textit{file table} referenziata da un @@ -840,7 +833,7 @@ scarico dei dati dai buffer del kernel.\footnote{come gi questo dà la garanzia assoluta che i dati siano integri dopo la chiamata, l'hardware dei dischi è in genere dotato di un suo meccanismo interno di ottimizzazione per l'accesso al disco che può ritardare ulteriormente la - scrittura effettiva.} La prima di queste funzioni è \func{sync} il cui + scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui prototipo è: \begin{prototype}{unistd.h}{int sync(void)} @@ -866,7 +859,7 @@ significato dei valori si pu 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 -usare le due funzioni \func{fsync} e \func{fdatasync}, i cui prototipi sono: +usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono: \begin{functions} \headdecl{unistd.h} \funcdecl{int fsync(int fd)} @@ -904,7 +897,7 @@ disco) che deve essere effettuata esplicitamente.\footnote{in realt Abbiamo già visto in \secref{sec:file_sharing} come un processo figlio condivida gli stessi file descriptor del padre; è possibile però ottenere un comportamento analogo all'interno di uno stesso processo \textit{duplicando} -un file descriptor. Per far questo si usa la funzione \func{dup} il cui +un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui prototipo è: \begin{prototype}{unistd.h}{int dup(int oldfd)} Crea una copia del file descriptor \param{oldfd}. @@ -951,13 +944,13 @@ dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec}; diventa così possibile associare un file (o una pipe) allo standard input o allo standard output (torneremo sull'argomento in \secref{sec:ipc_pipe_use}, quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere -il file che si vuole sostituire, cossicché il suo file descriptor possa esser +il file che si vuole sostituire, cosicché il suo file descriptor possa esser restituito alla chiamata di \func{dup}, come primo file descriptor disponibile. Dato che questa è l'operazione più comune, è prevista una diversa versione -della funzione, \func{dup2}, che permette di specificare esplicitamente qual'è -il valore di file descriptor che si vuole avere come duplicato; il suo +della funzione, \funcd{dup2}, che permette di specificare esplicitamente +qual'è il valore di file descriptor che si vuole avere come duplicato; il suo prototipo è: \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)} @@ -983,7 +976,7 @@ funzione di controllo dei file \func{fnctl} (che esamineremo in 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 fra le due funzioni\footnote{a parte la sistassi ed i +La sola differenza fra le due funzioni\footnote{a parte la sintassi 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 @@ -999,12 +992,12 @@ tutta una serie di operazioni ausiliarie che 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 + gestiscono 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 +caratteristiche un file descriptor, viene usata la funzione \funcd{fcntl}, il cui prototipo è: \begin{functions} \headdecl{unistd.h} @@ -1093,9 +1086,9 @@ valori valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro valore (compreso lo stesso \const{SIGIO}) specifica il segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è installato il - manipolatore del segnale come \var{sa\_sigaction} usando + gestore del segnale come \var{sa\_sigaction} usando \const{SA\_SIGINFO}, (vedi \secref{sec:sig_sigaction}), di rendere - disponibili al manipolatore informazioni ulteriori informazioni riguardo il + disponibili al gestore informazioni ulteriori informazioni riguardo il file che ha generato il segnale attraverso i valori restituiti in \struct{siginfo\_t} (come vedremo in \secref{sec:file_asyncronous_io}).\footnote{i due comandi \const{F\_SETSIG} @@ -1112,7 +1105,7 @@ le tematiche relative all'I/O asincrono sono trattate in maniera esaustiva in 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 +comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti 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 @@ -1137,7 +1130,7 @@ interfaccia astratta (un caso tipico 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 +di una funzione apposita, \funcd{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, ...)}