Aggiunte i listati per poter usare le modifiche di Mirko, con la generazione
[gapil.git] / fileunix.tex
index b4e7b5705a16c2a06b3cfb0001880d285f588150..5decd4994f91e0aa80b9e216dee0864c46d77e8f 100644 (file)
@@ -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.
 
 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
 
 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,
 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]
 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}
 
 \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}
 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}). \\
     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
     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}. \\
     \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.\\
     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}).}
 
   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
 
 \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
@@ -387,7 +388,7 @@ estensioni specifiche di Linux, e deve essere definita la macro
 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,
 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
 \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,7 +401,7 @@ programmi.
 \subsection{La funzione \func{close}}
 \label{sec:file_close}
 
 \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}. 
 descriptor ritorna disponibile; il suo prototipo è:
 \begin{prototype}{unistd.h}{int close(int fd)}
   Chiude il descrittore \param{fd}. 
@@ -454,14 +455,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
 
 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. 
   
 \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}
     successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei
     valori:
   \begin{errlist}
@@ -521,8 +522,8 @@ indefinito.
 \label{sec:file_read}
 
 
 \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)}
   
 prototipo è:
 \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
   
@@ -599,7 +600,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
   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)}
 
 \begin{prototype}{unistd.h}
 {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
 
@@ -628,7 +629,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ò
 \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}.
 \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}.
@@ -669,7 +670,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}.
 
 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}
 per scrivere alla posizione indicata senza modificare la posizione corrente
 nel file, il suo prototipo è:
 \begin{prototype}{unistd.h}
@@ -712,7 +713,7 @@ confronti dell'accesso allo stesso file da parte di processi diversi.
   \label{fig:file_mult_acc}
 \end{figure}
 
   \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
 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 +841,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
   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)}
   
 prototipo è:
 \begin{prototype}{unistd.h}{int sync(void)}
   
@@ -866,7 +867,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
 
 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)}
 \begin{functions}
   \headdecl{unistd.h}
   \funcdecl{int fsync(int fd)}
@@ -904,7 +905,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}
 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}.
 prototipo è:
 \begin{prototype}{unistd.h}{int dup(int oldfd)}
   Crea una copia del file descriptor \param{oldfd}.
@@ -951,13 +952,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
 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
 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)}
   
 prototipo è:
 \begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
   
@@ -983,7 +984,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 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
   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 +1000,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
 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
   \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}
 cui prototipo è:
 \begin{functions}
   \headdecl{unistd.h}
@@ -1093,9 +1094,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
   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
   \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}
   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 +1113,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
 
 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
 \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 +1138,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
 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, ...)}  
 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, ...)}