Avanti sul memory mapping
[gapil.git] / fileadv.tex
index 531aaa0b7af806ecc604a6e7a88b15791426c5c7..790ccdbb74debdcda926406a285fb64caa8b3d2a 100644 (file)
@@ -373,8 +373,6 @@ invier
 in eccesso, e si dovrà determinare al solito modo quali sono i file diventati
 attivi.
 
-
-
 Benché la modalità di apertura asincrona di un file possa risultare utile in
 varie occasioni (in particolar modo con i socket e gli altri file per i quali
 le funzioni di I/O sono system call lente), essa è comunque limitata alla
@@ -392,18 +390,439 @@ di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie
   asincrono.} esiste una sola versione stabile di questa interfaccia, quella
 delle \acr{glibc}, che è realizzata completamente in user space.  Esistono
 comunque vari progetti sperimentali (come il KAIO della SGI, o i patch di
-Benjamin La Haise) che prevedono una interfaccia che utilizza un supporto
-diretto da parte del kernel.
+Benjamin La Haise) che prevedono un supporto diretto da parte del kernel.
+
+Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
+attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per
+\textit{asyncronous I/O control block}), che viene passata come argomento a
+tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
+\file{aio.h}, è riportata in \figref{fig:file_aiocb}. Nello steso file è
+definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
+disponibilità dell'interfaccia per l'I/O asincrono.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct aiocb
+{
+    int aio_fildes;               /* File descriptor.  */
+    off_t aio_offset;             /* File offset */
+    int aio_lio_opcode;           /* Operation to be performed.  */
+    int aio_reqprio;              /* Request priority offset.  */
+    volatile void *aio_buf;       /* Location of buffer.  */
+    size_t aio_nbytes;            /* Length of transfer.  */
+    struct sigevent aio_sigevent; /* Signal number and value.  */
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \type{aiocb}, usata per il controllo dell'I/O
+    asincrono.}
+  \label{fig:file_aiocb}
+\end{figure}
+
+Le operazioni di I/O asincrono possono essere effettuate solo su un file già
+aperto; il file deve inoltre supportare la funzione \func{lseek},
+pertanto terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
+contemporanee effettuabili su un singolo file.
+
+Ogni operazione deve inizializzare opportunamente un \textit{control block}.
+Il file descriptor su cui operare deve essere specificato tramite il campo
+\var{aio\_fildes}; dato che più operazioni possono essere eseguita in maniera
+asincrona, il concetto di posizione corrente sul file viene a mancare;
+pertanto si deve sempre specificare nel campo \var{aio\_offset} la posizione
+sul file da cui i dati saranno letti o scritti.  Nel campo \var{aio\_buf} deve
+essere specificato l'indirizzo del buffer usato per l'I/O, ed in
+\var{aio\_nbytes} la lunghezza del blocco di dati da trasferire.
+
+Il campo \var{aio\_reqprio} permette di settare la priorità delle operazioni
+di I/O.\footnote{in generale perché ciò sia possibile occorre che la
+  piattaforma supporti questa caratteristica, questo viene indicato definendo
+  le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
+  \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene settata a partire
+da quella del processo chiamante (vedi \secref{sec:proc_priority}), cui viene
+sottratto il valore di questo campo.
+
+Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione
+\func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una
+sola chiamanta una serie di operazioni, usando un vettore di \textit{control
+  block}. Tramite questo campo si specifica quale è la natura di ciascuna di
+esse.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct sigevent
+{
+    sigval_t sigev_value;
+    int sigev_signo;
+    int sigev_notify;
+    sigev_notify_function;
+    sigev_notify_attributes;
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \type{sigevent}, usata per specificare le modailtà di
+    notifica degli eventi relativi alle operazioni di I/O asincrono.}
+  \label{fig:file_sigevent}
+\end{figure}
+
+Infine il campo \var{aio\_sigevent} è una struttura di tipo \type{sigevent}
+che serve a specificare il modo in cui si vuole che venga effettuata la
+notifica del completamento delle operazioni richieste. La struttura è
+riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello
+che indica le modalità della notifica, esso può assumere i tre valori:
+\begin{basedescript}{\desclabelwidth{3.0cm}}
+\item[\macro{SIGEV\_NONE}]   Non viene inviata nessuna notifica.
+\item[\macro{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
+  chiamante il segnale specificato nel campo \var{sigev\_signo}, se il
+  manipolatore è installato con \macro{SA\_SIGINFO}, il gli verrà restituito
+  il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per
+  \type{siginfo\_t}.
+\item[\macro{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
+  thread che esegue la funzione specificata da \var{sigev\_notify\_function},
+  con gli attributi specificati da \var{sigev\_notify\_attribute}.
+\end{basedescript}
+
+Le due funzioni base dell'interfaccia per l'I/O asincrono sono
+\func{aio\_read} ed \func{aio\_write}.  Esse permettono di richiedere una
+lettura od una scrittura asincrona di dati, usando la struttura \type{aiocb}
+appena descritta; i rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{aio.h}
+
+  \funcdecl{int aio\_read(struct aiocb *aiocbp)}
+  Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.
+
+  \funcdecl{int aio\_write(struct aiocb *aiocbp)}
+  Richiede una scrittura asincrona secondo quanto specificato con
+  \param{aiocbp}.
+  
+  \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
+    errore, nel qual caso \var{errno} viene settata ai valori:
+  \begin{errlist}
+  \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato.
+  \item[\macro{ENOSYS}] La funzione non è implementata.
+  \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi
+    \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
+  \item[\macro{EAGAIN}] La coda delle richieste è momentaneamente piena.
+  \end{errlist}
+}
+\end{functions}
+
+Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
+richiesta, o in caso di errore. Non è detto che gli errori \macro{EBADF} ed
+\macro{EINVAL} siano rilevati immediatamente al momento della chiamata,
+potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
+scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
+il file non sia stato aperto in \textit{append mode} (vedi
+\secref{sec:file_open}), nel qual caso le scritture vengono effettuate
+comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
+
+Si tenga inoltre presente che deallocare la memoria indirizzata da
+\param{aiocbp} o modificarne i valori prima della conclusione di una
+operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
+campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
+richiesta.  Questo comporta che occorre evitare di usare per \param{aiocbp}
+variabili automatiche e che non si deve riutilizzare la stessa struttura per
+un'ulteriore operazione fintanto che la precedente non sia stata ultimata. In
+generale per ogni operazione di I/O asincrono si deve utilizzare una diversa
+struttura \type{aiocb}.
+
+Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
+\func{aio\_write} non implica che le operazioni siano state effettivamente
+eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
+altre due funzioni, che permettono di controllare lo stato di esecuzione. La
+prima è \func{aio\_error}, che serve a determinare un eventuale stato di
+errore; il suo prototipo è:
+\begin{prototype}{aio.h}
+  {int aio\_error(const struct aiocb *aiocbp)}  
+
+  Determina lo stato di errore delle operazioni di I/O associate a
+  \param{aiocbp}.
+  
+  \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
+    successo, altrimenti restituisce il codice di errore.}
+% }, che viene salvato  
+%     anche in \var{errno}, i valori possibili sono:
+%   \begin{errlist}
+%   \item[\macro{ENOSYS}] La funzione non è implementata.
+%   \item[\macro{EINPROGRESS}] L'operazione è ancora in corso.
+%   \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi
+%     \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
+%   \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato.
+%   \end{errlist}
+%   più tutti quelli possibili per le sottostanti operazioni, .}
+\end{prototype}
 
+Se l'operazione non si è ancora completata viene restituito l'errore di
+\macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
+conclusa con successo, altrimenti restituisce il codice dell'errore
+verificatosi, ed esegue il corrispondente settaggio di \var{errno}. Il codice
+può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore errato per
+\param{aiocbp}, che uno degli errori possibili durante l'esecuzione
+dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
+del caso, i codici di errore delle system call \func{read}, \func{write} e
+\func{fsync}.
+
+Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
+che una chiamata ad \func{aio\_error} non ha restituito \macro{EINPROGRESS},
+si potrà usare la seconda funzione dell'interfaccia, \func{aio\_return}, che
+permette di verificare il completamento delle operazioni di I/O asincrono; il
+suo prototipo è:
+\begin{prototype}{aio.h}
+{ssize\_t aio\_return(const struct aiocb *aiocbp)} 
+
+Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
+\param{aiocbp}.
+  
+\bodydesc{La funzione restituisce lo stato di uscita dell'operazione
+  eseguita.}
+\end{prototype}
 
+La funzione deve essere chiamata una sola volte per ciascuna operazione
+asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
+associate. É per questo motivo che occorre chiamare la funzione solo dopo che
+l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
+precedente il completamento delle operazioni darebbe risultati indeterminati.
+
+La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
+così come ricavato dalla sottostante system call (il numero di byte letti,
+scritti o il valore di ritorno di \func{fsync}).  É importante chiamare sempre
+questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
+asincrono non verrebbero liberate, rischiando di arrivare ad un loro
+esaurimento.
+
+Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
+disposizione un'altra operazione, quella di sincronizzazione delll'I/O, essa è
+compiuta dalla funzione \func{aio\_fsync}, che ha lo stesso effetto della
+analoga \func{fsync}, ma viene esguita in maniera asincrona; il suo prototipo
+è:
+\begin{prototype}{aio.h}
+{ssize\_t aio\_return(int op, struct aiocb *aiocbp)} 
+
+Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
+  
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+  errore, che può essere, con le stesse modalità di \func{aio\_read},
+  \macro{EAGAIN}, \macro{EBADF} o \macro{EINVAL}.}
+\end{prototype}
 
+La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
+immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
+verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
+di lettura e scrittura. L'argomento \param{op} permette di indicare la
+modalità di esecuzione, se si specifica il valore \macro{O\_DSYNC} le
+operazioni saranno completate con una chiamata a \func{fdatasync}, se si
+specifica \macro{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
+\secref{sec:file_sync}).
+
+Il successo della chiamata assicura la sincronizzazione delle operazioni fino
+allora richieste, niente è garantito riguardo la sincronizzazione dei dati
+relativi ad eventuali operazioni richieste successivamente. Se si è
+specificato un meccanismo di notifica questo sarà innescato una volta che le
+operazioni di sincronizzazione dei dati saranno completate.
+
+In alcuni casi può essere necessario interrompere le operazioni (in genere
+quando viene richiesta un'uscita immediata dal programam), per questo lo
+standard POSIX.1b prevede una funzioni apposita, \func{aio\_cancel}, che
+permette di cancellare una operazione richiesta in precedenza; il suo
+prototipo è:
+\begin{prototype}{aio.h}
+{int aio\_cancel(int fildes, struct aiocb *aiocbp)} 
+
+Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
+da \param{aiocbp}.
+  
+\bodydesc{La funzione restituisce il risultato dell'operazione con un codice
+  di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
+  un valore non valido di \param{fildes}, setta \var{errno} al valore
+  \macro{EBADF}.}
+\end{prototype}
 
-\subsection{I/O multiplo}
+La funzione permette di cancellare una operazione specifica sul file
+\param{fildes}, o tutte le operazioni pendenti, specificando \macro{NULL} come
+valore di \param{aiocbp}.  Quando una operazione viene cancellata una
+successiva chiamata ad \func{aio\_error} riporterà \macro{ECANCELED} come
+codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
+di notifica non verrà invocato. Se si specifica una operazione relativa ad un
+altro file descriptor il risultato è indeterminato.
+
+In caso di successo, i possibili valori di ritorno per \func{aio\_cancel} sono
+tre (anch'essi definiti in \file{aio.h}):
+\begin{basedescript}{\desclabelwidth{3.0cm}}
+\item[\macro{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
+  cancellazione sono state già completate,
+  
+\item[\macro{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
+  state cancellate,  
+  
+\item[\macro{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
+  corso e non sono state cancellate.
+\end{basedescript}
+
+Nel caso si abbia \macro{AIO\_NOTCANCELED} occorrerà chiamare
+\func{aio\_error} per determinare quali sono le operazioni effettivamente
+cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
+corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
+del loro avvenuto completamento.
+
+Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
+fornisce anche una apposita funzione, \func{aio\_suspend}, che permette di
+sospendere l'esecuzione del processo chiamante fino al completamento di una
+specifica operazione; il suo prototipo è:
+\begin{prototype}{aio.h}
+{int aio\_suspend(const struct aiocb * const list[], int nent, const struct
+    timespec *timeout)}
+  
+  Attende, per un massimo di \param{timeout}, il completamento di una delle
+  operazioni specificate da \param{list}.
+  
+  \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
+    completate, e -1 in caso di errorem nel qual caso \var{errno} viene
+    settata ai valori:
+    \begin{errlist}
+    \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
+      \param{timeout}.
+    \item[\macro{ENOSYS}] La funzione non è implementata.
+    \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
+    \end{errlist}
+  }
+\end{prototype}
+
+La funzione permette di bloccare il processo fintanto che almeno una delle
+\param{nent} operazioni specificate nella lista \param{list} è completata, per
+un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
+segnale.\footnote{si tenga conto che questo segnale può anche essere quello
+  utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
+con delle strutture \var{aiocb} relative ad operazioni effettivamente
+richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
+siano specificati valori non validi l'effetto è indefinito.  Un valore
+\macro{NULL} per \param{timout} comporta l'assenza di timeout.
+
+Lo standard POSIX.1b infine ha previsto pure una funzione, \func{lio\_listio},
+che permette di effettuare la richiesta di una intera lista di operazioni di
+lettura o scrittura; il suo prototipo è:
+\begin{prototype}{aio.h}
+  {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
+    sigevent *sig)}
+  
+  Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
+  secondo la modalità \param{mode}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+    errore, nel qual caso \var{errno} viene settata ai valori:
+    \begin{errlist}
+    \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro
+      \param{timeout}.
+    \item[\macro{ENOSYS}] La funzione non è implementata.
+    \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
+    \end{errlist}
+  }
+\end{prototype}
+
+La funzione esegue la richiesta delle \param{nent} operazioni indicate dalla
+lista \param{list}; questa deve contenere gli indirizzi di altrettanti
+\textit{control block}, opportunamente inizializzati; in particolare nel caso
+dovrà essere specificato il tipo di operazione tramite il campo
+\var{aio\_lio\_opcode}, che può prendere i tre valori:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\macro{LIO\_READ}]  si richiede una operazione di lettura.
+\item[\macro{LIO\_WRITE}] si richiede una operazione di scrittura.
+\item[\macro{LIO\_NOP}] non si effettua nessuna operazione.
+\end{basedescript}
+l'ultimo valore viene usato quando si ha a che fare con un vettore di
+dimensione fissa, per poter specificare solo alcune operazioni, o quando si è
+dovuto cancellare delle operazioni e si deve ripetere la richiesta per quelle
+non completate.
+
+L'argomento \param{mode} permette di stabilire il comportamento della
+funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si
+blocca fino al completamento di tutte le operazioni richieste; se invece si
+spercifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver
+messo in coda tutte le richieste. In questo caso il chiamante può richiedere
+la notifica del completamento di tutte le richieste, settando l'argomento
+\param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent}
+di \type{aiocb}.
+
+
+
+\subsection{I/O vettorizzato}
 \label{sec:file_multiple_io}
 
-Un caso abbastanza comune è quello in cui ci si trova a dover affrontare una
+Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
 serie multipla di operazioni di I/O, come una serie di letture o scritture di
-vari buffer. In questo caso 
+vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
+una struttura ed essi devono essere caricati o salvati su un file.  Benché
+l'operazione sia facilmente eseguibile attraverso una serie multipla di
+chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
+operazioni.
+
+Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
+  integrate anche dallo standard Unix 98; fino alle libc5 Linux usava
+  \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
+  che è stata dismessa per restare aderenti allo standard.} ha introdotto due
+nuove system call, \func{readv} e \func{writev}, che permettono di effettare
+con una sola chiamata una lettura o una scrittura su una serie di buffer
+(quello che viene chiamato \textsl{I/O vettorizzato}. I relativi prototipi
+sono:
+\begin{functions}
+  \headdecl{sys/uio.h}
+  
+  \funcdecl{int readv(int fd, const struct iovec *vector, int count)} Esegue
+  una lettura vettorizzata da \param{fd} nei \param{count} buffer specificati
+  da \param{vector}.
+  
+  \funcdecl{int writev(int fd, const struct iovec *vector, int count)} Esegue
+  una scrittura vettorizzata da \param{fd} nei \param{count} buffer
+  specificati da \param{vector}.
+  
+  \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
+    caso di successo, e -1 in caso di errore, nel qual caso \var{errno} viene
+    settata ai valori:
+  \begin{errlist}
+  \item[\macro{EBADF}] si è specificato un file descriptor sbagliato.
+  \item[\macro{EINVAL}] si è specificato un valore non valido per uno degli
+    argomenti (ad esempio \param{count} è maggiore di \macro{MAX\_IOVEC}).
+  \item[\macro{EINTR}] la funzione è stata interrotta da un segnale prima di
+    di avere eseguito una qualunque lettura o scrittura.
+  \item[\macro{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
+  non ci sono dati in lettura.
+  \item[\macro{EOPNOTSUPP}] La coda delle richieste è momentaneamente piena.
+  \end{errlist}
+  ed inoltre \macro{EISDIR}, \macro{ENOMEM}, \macro{EFAULT} (se non sono stato
+  allocati correttamente i buffer specificati nei campi \func{iov\_base}), più
+  tutti gli ulteriori errori che potrebbero avere le usuali funzioni di
+  lettura e scrittura eseguite su \param{fd}.}
+\end{functions}
+
+Entrambe le funzioni usano una struttura \type{iovec}, definita in
+\figref{fig:file_iovec}, che definisce dove i dati devono essere letti o
+scritti. Il primo campo, \var{iov\_base}, contiene l'indirizzo del buffer ed
+il secondo, \var{iov\_len}, la dimensione dello stesso. 
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct iovec {
+    __ptr_t iov_base;    /* Starting address */
+    size_t iov_len;      /* Length in bytes  */
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \type{iovec}, usata dalle operazioni di I/O
+    vettorizzato.} 
+  \label{fig:file_iovec}
+\end{figure}
+
+I buffer da utlizzare sono specificati attraverso l'argomento \var{vector} che
+è un array di tale strutture, la cui lunghezza è specificata da \param{count}.
+Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati.
 
 
 
@@ -411,14 +830,289 @@ vari buffer. In questo caso
 \label{sec:file_memory_map}
 
 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
-rispetto a quella classica, è quella dei file \textsl{mappati in memoria}. In
-sostanza quello che si fa è usare il meccanismo della
-\textsl{paginazione}\index{paginazione} usato per la memoria virtuale (vedi
-\secref{sec:proc_mem_gen}) per trasformare vedere il file in una sezione dello
-spazio di indirizzi del processo, in modo che l'accesso a quest'ultimo con le
-normali operazioni di lettura e scrittura delle variabili in memoria, si
-trasformi in I/O sul file stesso.
+rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il
+cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della
+\textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi
+\secref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un
+file in una sezione dello spazio di indirizzi del processo.
+
+Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in
+quanto non sarà più necessario utilizzare dei buffer intermedi su cui
+appoggiare i dati da traferire, ma questi potranno essere acceduti
+direttamente dalla sezione di memoria; inoltre questa interfaccia
+è più efficiente delle usuali funzioni di I/O, in quanto permette di caricare
+in memoria solo le parti del file che sono effettivamente usate ad un dato
+istante.
+
+Infatti, dato che l'accesso è fatto direttamente attraverso la memoria
+virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta
+o scritta sul file una pagina alla volta e solo per le parti effettivamente
+usate, il tutto in maniera completamente trasparente al processo; l'acceso
+alle pagine non ancora caricate avverrà allo stesso modo con cui vengono
+caricate in memoria le pagine che sono state salvate sullo swap.
+
+Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un
+file vengono salvate automaticamente, così come le pagine dei programmi
+vengono scritte sulla swap; questo consente di accedere ai file su dimensioni
+il cui solo limite è quello dello spazio di indirizzi disponibile, e non della
+memoria su cui possono esserne lette delle porzioni.
+
+L'interfaccia prevede varie funzioni per la gestione del \textit{memory
+  mapping}, la prima di queste è \func{mmap}, che esegue la mappatura in
+memoria un file; il suo prototipo è:
+\begin{functions}
+  
+  \headdecl{unistd.h}
+  \headdecl{sys/mman.h} 
+
+  \funcdecl{void * mmap(void *start, size\_t length, int prot, int flags, int
+    fd, off\_t offset)}
+  
+  Esegue la mappatura in memoria del file \param{fd}.
+  
+  \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
+    in caso di successo, e \macro{MAP\_FAILED} (-1) in caso di errore, nel
+    qual caso \var{errno} viene settata ai valori:
+    \begin{errlist}
+    \item[\macro{EBADF}] Il file descriptor non è valido, e non si è usato
+      \macro{MAP\_ANONYMOUS}.
+    \item[\macro{EACCES}] Il file descriptor non si riferisce ad un file
+      normale, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è
+      aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e settato
+      \macro{PROT\_WRITE} ed \param{fd} non è aperto in lettura/scrittura, o
+      si è settato \macro{PROT\_WRITE} ed \param{fd} è in
+      \textit{append-only}.
+    \item[\macro{EINVAL}] I valori di \param{start}, \param{length} o
+      \param{offset} non sono validi (o troppo grandi o non allineati sulla
+      dimensione delle pagine).
+    \item[\macro{ETXTBSY}] Si è settato \macro{MAP\_DENYWRITE} ma \param{fd} è
+      aperto in scrittura.
+    \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria.
+    \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero
+      di mappature possibili.
+    \item[\macro{ENODEV}] Il filesystem di \param{fd} no supporta il memory
+      mapping.
+    \end{errlist}
+  }
+\end{functions}
+
+La funzione richiede di mappare in memoria la sezione del file \param{fd} a
+partire da \param{offset} per \param{lenght} byte, preferibilmente
+all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
+multiplo della dimensione di una pagina di memoria. Il valore dell'argomento
+\param{prot} indica la protezione\footnote{in Linux la memoria reale è divisa
+  in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti
+  lineari di memoria virtuale.  Per ciascuno di questi segmenti il kernel
+  mantiene nella \textit{page table} la mappatura sulle pagine di memoria
+  reale, ed le modalità di accesso (lettura, esecuzione, scrittura); una loro
+  violazione causa quella che si chiama una \textit{segment violation}, e la
+  relativa emissione del segnale \macro{SIGSEGV}.} da applicare al segmento di
+memoria e deve essere specificato come maschera binaria ottenuta dall'OR di
+uno o più dei valori riportati in \tabref{tab:file_mmap_flag}; il valore
+specificato deve essere compatibile con la modalità con cui si è aperto il
+file.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \macro{PROT\_EXEC}  & Le pagine possono essere eseguite.\\
+    \macro{PROT\_READ}  & Le pagine possono essere lette.\\
+    \macro{PROT\_WRITE} & Le pagine possono essere scritte.\\
+    \macro{PROT\_NONE}  & L'accesso alle pagine è vietato.\\
+    \hline    
+  \end{tabular}
+  \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
+    protezione applicate alle pagine del file mappate in memoria.}
+  \label{tab:file_mmap_prot}
+\end{table}
+
+L'argomento \param{flags} specifica qual'è il tipo di oggetto mappato, le
+opzioni relative alle modalità con cui è effettuata la mappatura e alle
+modalità con cui le modifiche alla memoria mappata vengono condivise o
+mantenute private al processo che le ha effettuate. Deve essere specificato
+come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
+\tabref{tab:file_mmap_flag}.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|p{10cm}|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \macro{MAP\_FIXED}     & Non permette di restituire un indirizzo diverso
+                             da \param{start}, se questo non può essere usato
+                             \func{mmap} fallisce. Se si setta questo flag il
+                             valore di \param{start} deve essere allineato
+                             alle dimensioni di una pagina. \\
+    \macro{MAP\_SHARED}    & I cambiamenti sulla memoria mappata vengono
+                             riportati sul file e saranno immediatamente
+                             visibili agli altri processi che mappano lo stesso
+                             file.\footnotemark Il file su disco però non sarà
+                             aggiornato fino alla chiamata di \func{rsync} o
+                             \func{unmap}), e solo allora le modifiche saranno
+                             visibili per l'I/O convenzionale. Incompatibile
+                             con \macro{MAP\_PRIVATE}. \\ 
+    \macro{MAP\_PRIVATE}   & I cambiamenti sulla memoria mappata non vengono
+                             riportati sul file. Ne viene fatta una copia
+                             privata cui solo il processo chiamante ha
+                             accesso.  Le modifiche sono mantenute attraverso
+                             il meccanismo del \textit{copy on write} e
+                             salvate su swap in caso di necessità. Non è
+                             specificato se i cambiamenti sul file originale
+                             vengano riportati sulla regione
+                             mappata. Incompatibile con \macro{MAP\_SHARED}. \\
+    \macro{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
+                             \textit{DoS}\index{DoS} (veniva usato per
+                             segnalare che tentativi di scrittura sul file
+                             dovevano fallire con \macro{ETXTBUSY}).\\
+    \macro{MAP\_EXECUTABLE}& Ignorato. \\
+    \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva
+                             delle pagine di swap ad uso del meccanismo di
+                             \textit{copy on  write} per mantere le modifiche 
+                             fatte alla regione mappata, in
+                             questo caso dopo una scrittura, se non c'è più
+                             memoria disponibile, si ha l'emissione di
+                             un \macro{SIGSEGV}. \\
+    \macro{MAP\_LOCKED}    & Se settato impedisce lo swapping delle pagine
+                             mappate. \\
+    \macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica alla virtual memory
+                             che la mappatura deve essere effettuata .\\
+    \macro{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
+                             argomenti \param{fd} e \param{offset} sono
+                             ignorati.\footnotemark\\
+    \macro{MAP\_ANON}      & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\
+    \macro{MAP\_FILE}      & Valore di compatibiità, deprecato.\\
+    \hline
+  \end{tabular}
+  \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
+  \label{tab:file_mmap_flag}
+\end{table}
 
+\footnotetext{Dato che tutti faranno riferimento alle stesse pagine di
+  memoria.}  
+\footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è
+  stato implementato in Linux a partire dai kernel della serie 2.4.x.}
+
+Un file viene sempre mappato su multipli delle dimensioni di una pagina,
+qualora esso sia più corto la parte restante è riempita con zeri; eventuali
+scritture in quella zona di memoria non vengono riportate sul file. Se le
+dimensioni del file cambiano (esso viene esteso o troncato), non è specificato
+quale effetto viene a aversi sulle pagine di memoria che corrispondono alle
+regioni aggiunte o tolte.
+
+Si tenga presente che non tutti i file possono venire mappati in memoria; ad
+esempio non è possibile mappare in memoria pipe, socket e fifo; lo stesso vale
+anche per alcuni file di dispositivo, che non dispongono dell'operazione
+relativa \var{mmap} (si ricordi quanto esposto in \secref{sec:file_vfs_work}).
+
+La memoria mappata viene mantenuta attraverso una \func{fork}; con gli stessi
+attributi. In particolare se la memoria è condivisa lo sarà anche fra padre e
+figlio, se è privata ognuno di essi manterrà una sua versione privata. Non c'è
+invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
+sostituisce tutto lo spazio degli indirizzo con quello del nuovo programma.
+
+Quando si effettua una mappatura di un file, i relativi tempi (vedi
+\secref{sec:file_file_times}) vengono pure modificati. Il valore di
+\var{st\_atime} può venir cambiato in un qualunque momento in cui la mappatura
+sia attiva: il primo riferimento ad una pagina mappata aggiorna questo tempo.
+I valori di \var{st\_ctime} e \var{st\_mtime} vengono cambiati solo quando è
+possibile una scrittura (cioè per un file mappato con \macro{PROT\_WRITE} e
+\macro{MAP\_SHARED}) e sono aggiornati dopo la scrittura e prima di una
+eventuale \func{msync}.
+
+Dato per i file mappati in memoria le operazioni di I/O sono gestite
+direttamente dalla memoria virtuale, occorre essere consapevoli delle
+interazioni che possono esserci con operazioni effettuate con l'interfaccia
+standard di \capref{sec:file_unix_interface}. Il problema è che una volta che
+si è mappato un file, le operazioni di lettura e scrittura saranno eseguite
+sulla memoria, e riportate su disco in maniera autonoma dal sistema della
+memoria virtuale.  
+
+Pertanto se si modifica un file con l'interfaccia standard queste modifiche
+potranno essere visibili o meno a seconda del momento in cui la memoria
+virtuale leggerà dal disco in memoria quella sezione del file, ed è del tutto
+indefinito quale può essere il contenuto della memoria mappata.  È però
+possibile usare la funzione \func{msync} per sincronizzare il contenuto della
+memoria con il file su disco; il suo prototipo è:
+\begin{functions}  
+  \headdecl{unistd.h}
+  \headdecl{sys/mman.h} 
+
+  \funcdecl{int msync(const void *start, size\_t length, int flags)}
+  
+  Sincronizza i contenuti di una sezione di un file mappato in memoria.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+    errore nel qual caso \var{errno} viene settata ai valori:
+    \begin{errlist}
+    \item[\macro{EINVAL}] O \param{start} non è multiplo di \macro{PAGESIZE},
+    o si è specificato un valore non valido per \param{flags}.
+    \item[\macro{EFAULT}] Il range specificato non ricade in una zona
+      precedentemente mappata.
+    \end{errlist}
+  }
+\end{functions}
+
+La funzione esegue la sincronizzazione su file di quanto scritto nella sezione
+di memoria indicata da \param{start} e \param{offset}.  Provvede anche ad
+aggiornare i relativi tempi di modifica; in questo modo le funzioni
+dell'interfaccia standard potranno accedere al contenuto aggiornato.
+
+L'argomento \param{flag} è specificato come maschera binaria composta da un OR
+dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però
+\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore
+infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
+meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
+attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
+flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
+le mappature dello stesso file, così che esse possano essere immediatamente
+aggiornate ai nuovi valori.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \macro{MS\_ASYNC}     & Richiede la sincronizzazione.\\
+    \macro{MS\_SYNC}      & Attende che la sincronizzazione si eseguita.\\
+    \macro{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
+                            siano invalidate.\\
+    \hline    
+  \end{tabular}
+  \caption{Valori dell'argomento \param{flag} di \func{msync}.}
+  \label{tab:file_mmap_rsync}
+\end{table}
+
+Una volta completate le operazioni di I/O si può eliminare la mappatura della
+memoria usando la funzione \func{munmap}, il cui prototipo è:
+\begin{functions}  
+  \headdecl{unistd.h}
+  \headdecl{sys/mman.h} 
+
+  \funcdecl{int munmap(void *start, size\_t length)}
+  
+  Rilascia la mappatura sulla sezione di memoria specificata.
+
+  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+    errore nel qual caso \var{errno} viene settata ai valori:
+    \begin{errlist}
+    \item[\macro{EINVAL}] Il range specificato non ricade in una zona
+      precedentemente mappata.
+    \end{errlist}
+  }
+\end{functions}
+
+La funzione 
 
 
 \section{Il file locking}
@@ -463,7 +1157,6 @@ Il \textit{mandatory locking} 
 
 
 
-
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"