Aggiornamento anno note di copyright, dimenticato da gennaio...

[gapil.git] / fileadv.tex

diff --git a/fileadv.tex b/fileadv.tex
index e881d60111e12615ad2844a78a38e18491f94d1b..38b74dcade0c89e6480ea1b223277610a79cf1d2 100644 (file)
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1,6 +1,6 @@
 %% fileadv.tex
 %%
 %% fileadv.tex
 %%

-%% Copyright (C) 2000-2007 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2008 Simone Piccardi.  Permission is granted to

 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",


@@ -913,6 +913,8 @@ operazioni di I/O volute.
 \subsection{Il \textit{Signal driven I/O}}
 \label{sec:file_asyncronous_operation}
 
 \subsection{Il \textit{Signal driven I/O}}
 \label{sec:file_asyncronous_operation}
 

+\itindbeg{signal~driven~I/O}
+

 Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
 l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e
   dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
 Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
 l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e
   dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è


@@ -1001,6 +1003,9 @@ utilizzabili.\footnote{vale a dire impostare il contenuto di
 
 % TODO fare esempio che usa O_ASYNC
 
 
 % TODO fare esempio che usa O_ASYNC
 

+\itindend{signal~driven~I/O}
+
+

 
 \subsection{I meccanismi di notifica asincrona.}
 \label{sec:file_asyncronous_lease}
 
 \subsection{I meccanismi di notifica asincrona.}
 \label{sec:file_asyncronous_lease}


@@ -1054,7 +1059,6 @@ questo 
 \textit{lease breaker}, cerca di eseguire una \func{open} o una
 \func{truncate} sul file del quale l'\textit{holder} detiene il
 \textit{lease}.
 \textit{lease breaker}, cerca di eseguire una \func{open} o una
 \func{truncate} sul file del quale l'\textit{holder} detiene il
 \textit{lease}.

-

 La notifica avviene in maniera analoga a come illustrato in precedenza per
 l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
 il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
 La notifica avviene in maniera analoga a come illustrato in precedenza per
 l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
 il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il


@@ -1300,9 +1304,12 @@ eliminato.\footnote{anzi, una delle capacit
 
 Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
 essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
 
 Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
 essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e

-con l'interfaccia di \textit{epoll}; siccome gli eventi vengono notificati
-come dati disponibili in lettura, dette funzioni ritorneranno tutte le volte
-che si avrà un evento di notifica. Così, invece di dover utilizzare i
+con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
+  stato introdotto anche il supporto per il \itindex{signal~driven~I/O}
+  \texttt{signal-driven I/O} trattato in
+  sez.~\ref{sec:file_asyncronous_operation}.} siccome gli eventi vengono
+notificati come dati disponibili in lettura, dette funzioni ritorneranno tutte
+le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i

 segnali,\footnote{considerati una pessima scelta dal punto di vista
   dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
 una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
 segnali,\footnote{considerati una pessima scelta dal punto di vista
   dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
 una qualunque delle modalità di \textit{I/O multiplexing} illustrate in


@@ -1757,11 +1764,12 @@ normalmente.
 
 In generale questa interfaccia è completamente astratta e può essere
 implementata sia direttamente nel kernel, che in user space attraverso l'uso
 
 In generale questa interfaccia è completamente astratta e può essere
 implementata sia direttamente nel kernel, che in user space attraverso l'uso

-di thread. Per le versioni del kernel meno recenti esiste una implementazione
-di questa interfaccia fornita delle \acr{glibc}, che è realizzata
-completamente in user space, ed è accessibile linkando i programmi con la
-libreria \file{librt}. Nelle versioni più recenti (a partire dalla 2.5.32) è
-stato introdotto direttamente nel kernel un nuovo layer per l'I/O asincrono.
+di \itindex{thread} \textit{thread}. Per le versioni del kernel meno recenti
+esiste una implementazione di questa interfaccia fornita delle \acr{glibc},
+che è realizzata completamente in user space, ed è accessibile linkando i
+programmi con la libreria \file{librt}. Nelle versioni più recenti (a partire
+dalla 2.5.32) è stato introdotto direttamente nel kernel un nuovo layer per
+l'I/O asincrono.

 
 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
 attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
 
 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
 attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per


@@ -1832,9 +1840,9 @@ quello che indica le modalit
   fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di
   \struct{siginfo\_t}.
 \item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
   fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di
   \struct{siginfo\_t}.
 \item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo

-  thread che esegue la funzione specificata da \var{sigev\_notify\_function}
-  con argomento \var{sigev\_value}, e con gli attributi specificati da
-  \var{sigev\_notify\_attribute}.
+  \itindex{thread} \textit{thread} che esegue la funzione specificata da
+  \var{sigev\_notify\_function} con argomento \var{sigev\_value}, e con gli
+  attributi specificati da \var{sigev\_notify\_attribute}.

 \end{basedescript}
 
 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
 \end{basedescript}
 
 Le due funzioni base dell'interfaccia per l'I/O asincrono sono


@@ -2225,14 +2233,15 @@ multiplo della dimensione di una pagina di memoria.
   \label{tab:file_mmap_prot}
 \end{table}
 
   \label{tab:file_mmap_prot}
 \end{table}
 

-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 \itindex{page~table} \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 \const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
+Il valore dell'argomento \param{prot} indica la protezione\footnote{come
+  accennato in sez.~\ref{sec:proc_memory} 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 \itindex{page~table} \textit{page table} la mappatura sulle
+  pagine di memoria reale, ed le modalità di accesso (lettura, esecuzione,
+  scrittura); una loro violazione causa quella una \itindex{segment~violation}
+  \textit{segment violation}, e la relativa emissione del segnale
+  \const{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 tab.~\ref{tab:file_mmap_prot}; il valore specificato deve essere
 compatibile con la modalità di accesso con cui si è aperto il file.
 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
 riportati in tab.~\ref{tab:file_mmap_prot}; il valore specificato deve essere
 compatibile con la modalità di accesso con cui si è aperto il file.


@@ -2291,9 +2300,9 @@ tab.~\ref{tab:file_mmap_flag}.
                              un \const{SIGSEGV}.\\
     \const{MAP\_LOCKED}    & Se impostato impedisce lo swapping delle pagine
                              mappate.\\
                              un \const{SIGSEGV}.\\
     \const{MAP\_LOCKED}    & Se impostato impedisce lo swapping delle pagine
                              mappate.\\

-    \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} stack. Indica 
-                             che la mappatura deve essere effettuata con gli
-                             indirizzi crescenti verso il basso.\\
+    \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} \textit{stack}. 
+                             Indica che la mappatura deve essere effettuata 
+                             con gli indirizzi crescenti verso il basso.\\

     \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
                              argomenti \param{fd} e \param{offset} sono
                              ignorati.\footnotemark\\
     \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
                              argomenti \param{fd} e \param{offset} sono
                              ignorati.\footnotemark\\


@@ -2910,7 +2919,7 @@ che anzi in certi casi si potevano avere anche dei peggioramenti.  Questo ha
 portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
   questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
   in \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
 portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
   questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
   in \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}

-  {\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
+  {\textsf{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}

 alla decisione di consentire l'uso della funzione soltanto quando il file da
 cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
 non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
 alla decisione di consentire l'uso della funzione soltanto quando il file da
 cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
 non è un socket) e quello su cui si scrive è un socket; in tutti gli altri


@@ -2937,13 +2946,15 @@ semplicemente un ``\textsl{dimezzamento}'' di \func{sendfile}.\footnote{nel
   sarebbe altro che la lettura degli stessi su un buffer seguita dalla
   relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
   chiamate a \func{splice}.} In realtà le due system call sono profondamente
   sarebbe altro che la lettura degli stessi su un buffer seguita dalla
   relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
   chiamate a \func{splice}.} In realtà le due system call sono profondamente

-diverse nel loro meccanismo di funzionamento; \func{sendfile} infatti, come
-accennato, non necessita affatto di avere a disposizione un buffer interno,
-perché esegue un trasferimento diretto di dati; questo la rende in generale
-molto più efficiente, ma anche limitata nelle sue applicazioni, dato che
-questo tipo di trasferimento è possibile solo in casi specifici.\footnote{e
-  nel caso di Linux questi sono anche solo quelli in cui essa può essere
-  effettivamente utilizzata.}
+diverse nel loro meccanismo di funzionamento;\footnote{questo fino al kernel
+  2.6.23, dove \func{sendfile} è stata reimplementata in termini di
+  \func{splice}, pur mantenendo disponibile la stessa interfaccia verso l'user
+  space.} \func{sendfile} infatti, come accennato, non necessita di avere a
+disposizione un buffer interno, perché esegue un trasferimento diretto di
+dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
+applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
+specifici.\footnote{e nel caso di Linux questi sono anche solo quelli in cui
+  essa può essere effettivamente utilizzata.}

 
 Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
   realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
 
 Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
   realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli


@@ -2951,7 +2962,7 @@ Il concetto che sta dietro a \func{splice} invece 
   stata la reinterpretazione che ne è stata fatta nell'implementazione su
   Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
   dallo stesso Linus Torvalds in \href{http://kerneltrap.org/node/6505}
   stata la reinterpretazione che ne è stata fatta nell'implementazione su
   Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
   dallo stesso Linus Torvalds in \href{http://kerneltrap.org/node/6505}

-  {\texttt{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
+  {\textsf{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una

 funzione che consente di fare in maniera del tutto generica delle operazioni
 di trasferimento di dati fra un file e un buffer gestito interamente in kernel
 space. In questo caso il cuore della funzione (e delle affini \func{vmsplice}
 funzione che consente di fare in maniera del tutto generica delle operazioni
 di trasferimento di dati fra un file e un buffer gestito interamente in kernel
 space. In questo caso il cuore della funzione (e delle affini \func{vmsplice}


@@ -3335,12 +3346,13 @@ detto che i dati vengono effettivamente spostati o copiati, il kernel infatti
 realizza le \textit{pipe} come un insieme di puntatori\footnote{per essere
   precisi si tratta di un semplice buffer circolare, un buon articolo sul tema
   si trova su \href{http://lwn.net/Articles/118750/}
 realizza le \textit{pipe} come un insieme di puntatori\footnote{per essere
   precisi si tratta di un semplice buffer circolare, un buon articolo sul tema
   si trova su \href{http://lwn.net/Articles/118750/}

-  {\texttt{http://lwn.net/Articles/118750/}}.}  alle pagine di memoria interna
+  {\textsf{http://lwn.net/Articles/118750/}}.}  alle pagine di memoria interna

 che contengono i dati, per questo una volta che i dati sono presenti nella
 memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
 ed aumentare il numero di referenze; questo significa che anche con \func{tee}
 non viene mai copiato nessun byte, vengono semplicemente copiati i puntatori.
 
 che contengono i dati, per questo una volta che i dati sono presenti nella
 memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
 ed aumentare il numero di referenze; questo significa che anche con \func{tee}
 non viene mai copiato nessun byte, vengono semplicemente copiati i puntatori.
 

+% TODO?? dal 2.6.25 splice ha ottenuto il supporto per la ricezione su rete

 
 
 \subsection{Gestione avanzata dell'accesso ai dati dei file}
 
 
 \subsection{Gestione avanzata dell'accesso ai dati dei file}


@@ -3559,6 +3571,8 @@ mancanza di spazio disco.
 
 % TODO documentare \func{fallocate}, introdotta con il 2.6.23
 % vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
 
 % TODO documentare \func{fallocate}, introdotta con il 2.6.23
 % vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/

+% http://kernelnewbies.org/Linux_2_6_23
+% \func{fallocate} con il 2.6.25 supporta pure XFS

 
 
 %\subsection{L'utilizzo delle porte di I/O}
 
 
 %\subsection{L'utilizzo delle porte di I/O}