-
-
-\footnote{la pagina di
- manuale di \func{open} segnala che questa opzione è difettosa su NFS, e
- che i programmi che la usano per stabilire un \index{file!di lock}
- \textsl{file di lock} possono incorrere in una \itindex{race~condition}
- \textit{race condition}. Si consiglia come alternativa di usare un file
- con un nome univoco e la funzione \func{link} per verificarne
- l'esistenza (vedi sez.~\ref{sec:ipc_file_lock}).}
-
-
-\const{O\_SHLOCK} Apre il file con uno shared lock (vedi
- sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux.
-
-\const{O\_EXLOCK} Apre il file con un lock esclusivo (vedi
- sez.~\ref{sec:file_locking}). Specifica di BSD, assente in Linux.
-
-
-Il terzo gruppo è quello dei flag delle \textsl{modalità di operazione} che
-permettono di specificare alcune caratteristiche del comportamento delle
-future operazioni sul file (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}.
-
-
-\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
-
- \item[\const{O\_APPEND}] Il file viene aperto in \itindex{append~mode}
- \textit{append mode}. Prima di ciascuna scrittura la posizione corrente
- viene sempre impostata alla fine del file. Con NFS si può avere una
- corruzione del file se più di un processo scrive allo stesso
- tempo.\footnote{il problema è che NFS non supporta la scrittura in
- \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
- questo comporta la possibilità di una \itindex{race~condition}
- \textit{race condition}, vedi sez.~\ref{sec:file_atomic}.}
-
- \item[\const{O\_ASYNC}] Apre il file per l'I/O in modalità asincrona (vedi
- sez.~\ref{sec:file_asyncronous_io}). Quando è impostato viene generato il
- segnale \signal{SIGIO} tutte le volte che sono disponibili dati in input
- sul file.
-
- \item[\const{O\_CLOEXEC}] Attiva la modalità di \itindex{close-on-exec}
- \textit{close-on-exec} (vedi sez.~\ref{sec:proc_exec}). Introdotto con il
- kernel 2.6.23, per evitare una \itindex{race~condition} \textit{race
- condition} che si può verificare con i \itindex{thread} \textit{thread},
- fra l'apertura del file e l'impostazione della suddetta modalità con
- \func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
-
- \item[\const{O\_DIRECT}] Esegue l'I/O direttamente dai buffer in user space
- in maniera sincrona, in modo da scavalcare i meccanismi di caching del
- kernel. In genere questo peggiora le prestazioni tranne quando le
- applicazioni ottimizzano il proprio caching.\footnote{l'opzione è stata
- introdotta dalla SGI in IRIX, e serve sostanzialmente a permettere ad
- alcuni programmi (in genere database) la gestione diretta della
- bufferizzazione dell'I/O in quanto essi sono in grado di ottimizzarla al
- meglio per le loro prestazioni; l'opzione è presente anche in FreeBSD,
- senza limiti di allineamento dei buffer. In Linux è stata introdotta con
- il kernel 2.4.10, le versioni precedenti la ignorano.} Per i kernel
- della serie 2.4 si deve garantire che i buffer in user space siano
- allineati alle dimensioni dei blocchi del filesystem; per il kernel 2.6
- basta che siano allineati a multipli di 512 byte.
-
- \item[\const{O\_NOATIME}] Blocca l'aggiornamento dei tempi di accesso dei
- file (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa
- funzionalità non è disponibile per il singolo file ma come opzione
- generale da specificare in fase di montaggio.
-
- \item[\const{O\_NONBLOCK}] Il file viene aperto in modalità non bloccante
- per le operazioni di I/O (che tratteremo in
- sez.~\ref{sec:file_noblocking}): questo significa il fallimento di
- \func{read} in assenza di dati da leggere e quello di \func{write} in caso
- di impossibilità di scrivere immediatamente. Questa modalità ha senso solo
- per le fifo e per alcuni file di dispositivo.
-
- \item[\const{O\_NONBLOCK}] Apre il file in modalità non bloccante, e
- comporta che \func{open} ritorni immediatamente anche quando dovrebbe
- bloccarsi (l'opzione ha senso solo per le fifo, vedi
- sez.~\ref{sec:ipc_named_pipe}).
-
- \item[\const{O\_NDELAY}] In Linux è sinonimo di
- \const{O\_NONBLOCK}.\footnote{l'opzione origina da SVr4, dove però causava
- il ritorno da una \func{read} con un valore nullo e non con un errore,
- questo introduce un'ambiguità, dato che come vedremo in
- sez.~\ref{sec:file_read} il ritorno di zero da parte di \func{read} ha
- il significato di una \textit{end-of-file}.}
-
- \item[\const{O\_SYNC}] Apre il file per l'input/output sincrono: ogni
- \func{write} bloccherà fino al completamento della scrittura di tutti i
- dati sull'hardware sottostante.
-
- \item[\const{O\_FSYNC}] Sinonimo di \const{O\_SYNC}, usato da BSD.
-
- \item[\const{O\_DSYNC}] Variante di I/O sincrono definita da POSIX; presente
- dal kernel 2.1.130 come sinonimo di \const{O\_SYNC}.
-
- \item[\const{O\_RSYNC}] Variante analoga alla precedente, trattata allo
- stesso modo.
-
-\end{basedescript}
-
-
-%TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
-% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
-
-
-In tab.~\ref{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 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.
+Il terzo gruppo è quello dei flag delle \textsl{modalità di operazione},
+riportati in tab.~\ref{tab:open_operation_flag}, che permettono di specificare
+varie caratteristiche del comportamento delle operazioni di I/O che verranno
+eseguite sul file. Tutti questi, tranne \const{O\_CLOEXEC}, che viene
+mantenuto per ogni singolo file descriptor, vengono salvati nel campo
+\var{f\_flags} della struttura \kstruct{file} insieme al valore della
+\textsl{modalità di accesso} andando far parte dei cosiddetti \textit{file
+ status flags}. Il loro valore viene impostato alla chiamata di \func{open},
+ma possono essere riletti ed in alcuni di essi anche modificati, con
+conseguente effetto sulle caratteristiche operative che controllano, con
+\func{fcntl} (vedi sez.~\ref{sec:file_fcntl}).
+
+Il flag \const{O\_DIRECT} non è previsto da nessuno standard, anche se è
+presente in alcuni kernel unix-like.\footnote{il flag è stato introdotto dalla
+ SGI in IRIX, ma è presente senza limiti di allineamento dei buffer anche in
+ FreeBSD.} Per i kernel della serie 2.4 si deve garantire che i buffer in
+\textit{user space} da cui si effettua il trasferimento diretto dei dati siano
+allineati alle dimensioni dei blocchi del filesystem. Con il kernel 2.6 in
+genere basta che siano allineati a multipli di 512 byte, ma le restrizioni
+possono variare a seconda del filesystem, ed inoltre su alcuni filesystem può
+non essere supportato, nel qual caso si avrà un errore di \errval{EINVAL}.
+
+Lo scopo di \const{O\_DIRECT} è consentire un completo controllo sulla
+bufferizzazione dei propri dati per quelle applicazioni (in genere database)
+che hanno esigenze specifiche che non vengono soddisfatte nella maniera più
+efficiente dalla politica generica utilizzata dal kernel. In genere l'uso di
+questo flag peggiora le prestazioni tranne quando le applicazioni sono in
+grado di ottimizzare la propria bufferizzazione in maniera adeguata. Se lo si
+usa si deve avere cura di non mescolare questo tipo di accesso con quello
+ordinario, in quante le esigenze di mantenere coerenti i dati porterebbero ad
+un peggioramento delle prestazioni. Lo stesso dicasi per l'interazione con
+eventuale mappatura in memoria del file (vedi sez.~\ref{sec:file_memory_map}).
+
+Si tenga presente infine che anche se l'uso di \const{O\_DIRECT} comporta
+sostanzialmente solo una scrittura sincrona dei dati dei buffer in
+\textit{user space}, questo non è completamente equivalente all'uso di
+\const{O\_SYNC} che garantisce anche sulla scrittura sincrona dei metadati
+associati alla scrittura dei dati del file. Per questo in genere è opportuno
+se si usa \const{O\_DIRECT} è opportuno richiedere anche \const{O\_SYNC}.
+
+Si tenga presente infine che la implementazione di \const{O\_SYNC} di Linux
+differisce da quanto previsto dallo standard POSIX.1 che prevede, oltre a
+questo flag che dovrebbe indicare la sincronizzazione completa di tutti i dati
+e di tutti i metadati, altri due flag \const{O\_DSYNC} e \const{O\_RSYNC}. Il
+primo dei due richiede la scrittura sincrona di tutti i dati del file e dei
+metadati che ne consentono l'immediata rilettura, ma non di tutti i metadati,
+per evitare la perdita di prestazioni relativa alla sincronizzazione di
+informazioni ausiliarie come i tempi dei file.
+
+Il secondo, da usare in combinazione con \const{O\_SYNC} o \const{O\_DSYNC} ne
+sospende l'effetto, consentendo al kernel di bufferizzare le scritture, ma
+soltanto finché non avviene una lettura, in quel caso i dati ed i metadati
+dovranno essere sincronizzati immediatamente (secondo le modalità indicate da
+\const{O\_SYNC} e \const{O\_DSYNC}) e la lettura verrà bloccata fintanto che
+detta sincronizzazione non sia completata.
+
+Nel caso di Linux, fino al kernel 2.6.33, esisteva solo \const{O\_SYNC}, ma
+con il comportamento previsto dallo standard per \const{O\_DSYNC}, e sia
+questo che \const{O\_RSYNC} erano definiti (fin dal kernel 2.1.130) come
+sinonimi di \const{O\_SYNC}. Con il kernel 2.6.33 il significato di
+\const{O\_SYNC} è diventato quello dello standard, ma gli è stato assegnato un
+valore diverso, mantenendo quello originario, con il comportamento
+corrispondete, per \const{O\_DSYNC}.
+
+% NOTE: per le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
+% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/