%% fileadv.tex
%%
-%% Copyright (C) 2000-2016 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 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",
La prima modalità di \textit{file locking} che è stata implementata nei
sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
- come al \textit{record locking}, dizione utilizzata anche dal manuale delle
+ come al \textit{record locking}, dizione utilizzata anche dal manuale della
\acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
mentre questo nome viene usato da Stevens per riferirsi al \textit{file
Il comportamento seguito in questo caso è che la funzione ha successo ed
esegue l'operazione richiesta sulla regione indicata; è compito del kernel
preoccuparsi di accorpare o dividere le voci nella lista dei \textit{file
- lock} per far si che le regioni bloccate da essa risultanti siano coerenti
+ lock} per far sì che le regioni bloccate da essa risultanti siano coerenti
con quanto necessario a soddisfare l'operazione richiesta.
\begin{figure}[!htbp]
\func{exec}. Per questo stesso motivo la funzione non è equivalente a
\func{flock} e può essere usata senza interferenze insieme a quest'ultima.
+
+\subsection{Gli \textit{open file descriptor locks}}
+\label{sec:open_file_descriptor_locks}
+
+Come illustrato in dettaglio nella precedente sez.~\ref{sec:file_posix_lock},
+la chiusura di un file su cui sono presenti dei \textit{file lock} comporta
+l'immediato rilascio degli stessi, anche se questi sono stati acquisiti da un
+processo diverso.
+
+da finire.
+
% TODO trattare i POSIX file-private lock introdotti con il 3.15,
% vedi http://lwn.net/Articles/586904/ correlato:
% http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html
attuale delle cose è sconsigliabile fare affidamento sul \textit{mandatory
locking}.
+% TODO il supporto è stato reso opzionale nel 4.5, verrà eliminato nel futuro
+% (vedi http://lwn.net/Articles/667210/)
+
\itindend{file~locking}
\itindend{mandatory~locking}
tutti i sistemi che supportano i socket, compreso le varianti di System V ed
inserita in POSIX.1-2001; il suo prototipo è:\footnote{l'header
\texttt{sys/select.h} è stato introdotto con POSIX.1-2001, è ed presente con
- le \acr{glibc} a partire dalla versione 2.0, in precedenza, con le
- \acr{libc4} e le \acr{libc5}, occorreva includere \texttt{sys/time.h},
+ la \acr{glibc} a partire dalla versione 2.0, in precedenza, con le
+ \acr{libc4} e \acr{libc5}, occorreva includere \texttt{sys/time.h},
\texttt{sys/types.h} e \texttt{unistd.h}.}
\begin{funcproto}{
ricalcolano \param{timeout} tutte le volte. In genere questa caratteristica è
disponibile nei sistemi che derivano da System V e non è disponibile per
quelli che derivano da BSD; lo standard POSIX.1-2001 non permette questo
-comportamento e per questo motivo le \acr{glibc} nascondono il comportamento
+comportamento e per questo motivo la \acr{glibc} nasconde il comportamento
passando alla \textit{system call} una copia dell'argomento \param{timeout}.
Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
vengano dichiarate nell'header \headfiled{sys/select.h}, che sostituisce i
precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
\funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
- l'header \headfile{sys/select.h}, compaiono in Linux a partire dalle
+ l'header \headfile{sys/select.h}, compaiono in Linux a partire dalla
\acr{glibc} 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header,
- le \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
+ la \acr{glibc} 2.0 contiene una definizione sbagliata di \func{psignal},
senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
\acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
\acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timespec_struct}) per
indicare con maggiore precisione il timeout e non ne aggiorna il valore in
caso di interruzione. In realtà anche in questo caso la \textit{system call}
-di Linux aggiorna il valore al tempo rimanente, ma la funzione fornita dalle
+di Linux aggiorna il valore al tempo rimanente, ma la funzione fornita dalla
\acr{glibc} modifica questo comportamento passando alla \textit{system call}
una variabile locale, in modo da mantenere l'aderenza allo standard POSIX che
richiede che il valore di \param{timeout} non sia modificato.
\param{sigmask} permette di riabilitare la ricezione il segnale
contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
kernel 2.6.16, non era presente la relativa \textit{system call}, e la
- funzione era implementata nelle \acr{glibc} attraverso \func{select} (vedi
+ funzione era implementata nella \acr{glibc} attraverso \func{select} (vedi
\texttt{man select\_tut}) per cui la possibilità di \textit{race condition}
permaneva; in tale situazione si può ricorrere ad una soluzione alternativa,
chiamata \itindex{self-pipe~trick} \textit{self-pipe trick}, che consiste
risultati illustrati in precedenza. Come nel caso di \func{pselect} la
\textit{system call} che implementa \func{ppoll} restituisce, se la funzione
viene interrotta da un segnale, il tempo mancante in \param{timeout}, e come
-per \func{pselect} la funzione di libreria fornita dalle \acr{glibc} maschera
+per \func{pselect} la funzione di libreria fornita dalla \acr{glibc} maschera
questo comportamento non modificando mai il valore di \param{timeout} anche se
in questo caso non esiste nessuno standard che richieda questo comportamento.
servizio è chiamata \textit{epoll},\footnote{l'interfaccia è stata creata da
Davide Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44,
ma la sua forma definitiva è stata raggiunta nel kernel 2.5.66, il supporto
- è stato aggiunto nelle \acr{glibc} a partire dalla versione 2.3.2.} anche se
+ è stato aggiunto nella \acr{glibc} a partire dalla versione 2.3.2.} anche se
sono state in discussione altre interfacce con le quali effettuare lo stesso
tipo di operazioni; \textit{epoll} è in grado di operare sia in modalità
\textit{level triggered} che \textit{edge triggered}.
-La prima versione di \textit{epoll} prevedeva l'apertura di uno speciale file
-di dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
+La prima versione di \textit{epoll} prevedeva l'uso di uno speciale file di
+dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
utilizzare con le funzioni dell'interfaccia ma poi si è passati all'uso di
apposite \textit{system call}. Il primo passo per usare l'interfaccia di
\textit{epoll} è pertanto quello ottenere detto file descriptor chiamando una
La seconda versione della funzione, \func{epoll\_create1} è stata introdotta
come estensione della precedente (è disponibile solo a partire dal kernel
2.6.27) per poter passare dei flag di controllo come maschera binaria in fase
-di creazione del file descriptor. Al momento l'unico valore legale
-per \param{flags} (a parte lo zero) è \constd{EPOLL\_CLOEXEC}, che consente di
+di creazione del file descriptor. Al momento l'unico valore legale per
+\param{flags} (a parte lo zero) è \constd{EPOLL\_CLOEXEC}, che consente di
impostare in maniera atomica sul file descriptor il flag di
-\textit{close-on-exec} (si è trattato il significato di \const{O\_CLOEXEC} in
-sez.~\ref{sec:file_open_close}), senza che sia necessaria una successiva
+\textit{close-on-exec} (vedi sez.~\ref{sec:proc_exec} e
+sez.~\ref{sec:file_shared_access}) senza che sia necessaria una successiva
chiamata a \func{fcntl}.
Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
ed è utile per riconoscere la chiusura di una connessione dall'altro capo di
un socket quando si lavora in modalità \textit{edge triggered}.}
+% TODO aggiunto con il kernel 4.5 EPOLLEXCLUSIVE, vedi
+% http://lwn.net/Articles/633422/#excl
+
Il secondo campo, \var{data}, è una \dirct{union} che serve a identificare il
file descriptor a cui si intende fare riferimento, ed in astratto può
contenere un valore qualsiasi (specificabile in diverse forme) che ne permetta
La funzione di sistema che permette di abilitare la ricezione dei segnali
tramite file descriptor è \funcd{signalfd},\footnote{in realtà quella
- riportata è l'interfaccia alla funzione fornita dalle \acr{glibc}, esistono
+ riportata è l'interfaccia alla funzione fornita dalla \acr{glibc}, esistono
infatti due versioni diverse della \textit{system call}; una prima versione,
- \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
+ \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con la
\acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
- che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
+ che viene sempre usata a partire dalla \acr{glibc} 2.9, che prende un
argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
- maschera dei segnali, il cui valore viene impostato automaticamente dalle
+ maschera dei segnali, il cui valore viene impostato automaticamente dalla
\acr{glibc}.} il cui prototipo è:
\begin{funcproto}{
potranno essere ricevuti normalmente una volta che si rimuova il blocco
imposto con \func{sigprocmask}.
-Oltre che con le funzioni dell'\textit{I/O multiplexing} l'uso del file
-descriptor restituito da \func{signalfd} cerca di seguire la semantica di un
-sistema unix-like anche con altre \textit{system call}; in particolare esso
+Oltre a poter essere usato con le funzioni dell'\textit{I/O multiplexing}, il
+file descriptor restituito da \func{signalfd} cerca di seguire la semantica di
+un sistema unix-like anche con altre \textit{system call}; in particolare esso
resta aperto (come ogni altro file descriptor) attraverso una chiamata ad
\func{exec}, a meno che non lo si sia creato con il flag di
-\const{SFD\_CLOEXEC} o si sia successivamente impostato il
+\const{SFD\_CLOEXEC} o si sia successivamente impostato il
\textit{close-on-exec} con \func{fcntl}. Questo comportamento corrisponde
anche alla ordinaria semantica relativa ai segnali bloccati, che restano
pendenti attraverso una \func{exec}.
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{0.90\textwidth}
+ \begin{minipage}[c]{0.95\textwidth}
\includestruct{listati/signalfd_siginfo.h}
\end{minipage}
\normalsize
\label{fig:fiforeporter_code_init}
\end{figure}
-Il contenuto di \struct{signalfd\_siginfo} ricalca da vicino quella della
-analoga struttura \struct{siginfo\_t} (illustrata in
+Il contenuto di \struct{signalfd\_siginfo} ricalca da vicino quella
+dell'analoga struttura \struct{siginfo\_t} (illustrata in
fig.~\ref{fig:sig_siginfo_t}) usata dall'interfaccia ordinaria dei segnali, e
restituisce dati simili. Come per \struct{siginfo\_t} i campi che vengono
avvalorati dipendono dal tipo di segnale e ricalcano i valori che abbiamo già
interfaccia è stata introdotta in forma considerata difettosa con il kernel
2.6.22, per cui è stata immediatamente tolta nel successivo 2.6.23 e
reintrodotta in una forma considerata adeguata nel kernel 2.6.25, il
- supporto nelle \acr{glibc} è stato introdotto a partire dalla versione
+ supporto nella \acr{glibc} è stato introdotto a partire dalla versione
2.8.6, la versione del kernel 2.6.22, presente solo su questo kernel, non è
supportata e non deve essere usata.} La prima funzione di sistema prevista,
quella che consente di creare un timer, è \funcd{timerfd\_create}, il cui
% TODO trattare fanotify, vedi http://lwn.net/Articles/339399/ e
% http://lwn.net/Articles/343346/ (incluso nel 2.6.36)
+% fanotify_mark() ha FAN_MARK_FILESYSTEM dal 4.20
+% fanotify() ha FAN_OPEN_EXEC dal 4.21/5.0
\subsection{L'interfaccia POSIX per l'I/O asincrono}
In generale questa interfaccia è completamente astratta e può essere
implementata sia direttamente nel kernel che in \textit{user space} attraverso
l'uso di \textit{thread}. Per le versioni del kernel meno recenti esiste una
-implementazione di questa interfaccia fornita completamente delle \acr{glibc}
+implementazione di questa interfaccia fornita completamente dalla \acr{glibc}
a partire dalla versione 2.1, che è realizzata completamente in \textit{user
space}, ed è accessibile linkando i programmi con la libreria
\file{librt}. A partire dalla versione 2.5.32 è stato introdotto nel kernel
esse.
Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
-(illustrata in in fig.~\ref{fig:struct_sigevent}) che serve a specificare il
-modo in cui si vuole che venga effettuata la notifica del completamento delle
+(illustrata in fig.~\ref{fig:struct_sigevent}) che serve a specificare il modo
+in cui si vuole che venga effettuata la notifica del completamento delle
operazioni richieste; per la trattazione delle modalità di utilizzo della
stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
% http://webfiveoh.com/content/guides/2012/aug/mon-13th/linux-asynchronous-io-and-libaio.html,
% https://code.google.com/p/kernel/wiki/AIOUserGuide,
% http://bert-hubert.blogspot.de/2012/05/on-linux-asynchronous-file-io.html
+% https://www.fsl.cs.sunysb.edu/~vass/linux-aio.txt
+
+% TODO trattare la poll API basata sull'I/O asicrono, introdotta con il kernel
+% 4.18, vedi https://lwn.net/Articles/743714/,
+% https://lwn.net/Articles/742978/, https://lwn.net/Articles/758324/
+% http://git.infradead.org/users/hch/vfs.git/commit/d2d9e26c7cb6d95d521153897910080cf56c7fad
+% Reverted
+% TODO trattare la nuova API per l'I/O asincrono (io_uring), introdotta con il
+% kernel 5.1, vedi https://lwn.net/Articles/776703/,
+% https://lwn.net/ml/linux-fsdevel/20190112213011.1439-1-axboe@kernel.dk/
\section{Altre modalità di I/O avanzato}
\label{sec:file_advanced_io}
con \const{MAP\_PRIVATE}.\\
\const{MAP\_STACK} & Al momento è ignorato, è stato fornito (dal kernel
2.6.27) a supporto della implementazione dei
- thread nelle \acr{glibc}, per allocare memoria in
- uno spazio utilizzabile come \textit{stack} per le
- architetture hardware che richiedono un
- trattamento speciale di quest'ultimo.\\
+ \textit{thread} nella \acr{glibc}, per allocare
+ memoria in uno spazio utilizzabile come
+ \textit{stack} per le architetture hardware che
+ richiedono un trattamento speciale di
+ quest'ultimo.\\
\constd{MAP\_UNINITIALIZED}& Specifico per i sistemi embedded ed
utilizzabile dal kernel 2.6.33 solo se è stata
abilitata in fase di compilazione dello stesso
% TODO trattare MAP_HUGETLB introdotto con il kernel 2.6.32, e modifiche
% introdotte con il 3.8 per le dimensioni variabili delle huge pages
+% TODO trattare MAP_FIXED_NOREPLACE vedi https://lwn.net/Articles/751651/ e
+% https://lwn.net/Articles/741369/
+
+% TODO: verificare MAP_SYNC e MAP_SHARED_VALIDATE, vedi
+% https://lwn.net/Articles/731706/, https://lwn.net/Articles/758594/ incluse
+% con il 4.15
+
+
L'argomento \param{flags} specifica infine 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
\label{tab:madvise_advice_values}
\end{table}
+% TODO aggiunta MADV_FREE dal kernel 4.5 (vedi http://lwn.net/Articles/590991/)
+% TODO aggiunta MADV_WIPEONFORK dal kernel 4.14 that causes the affected memory
+% region to appear to be full of zeros in the child process after a fork. It
+% differs from the existing MADV_DONTFORK in that the address range will
+% remain valid in the child (dalla notizia in https://lwn.net/Articles/733256/).
+
\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
identifica pagine di memoria identiche e le accorpa in una unica pagina
(soggetta al \textit{copy-on-write} per successive modifiche); per evitare
L'argomento \param{advice} invece può assumere solo i valori indicati in
tab.~\ref{tab:posix_madvise_advice_values}, che riflettono gli analoghi di
\func{madvise}, con lo stesso effetto per tutti tranne
-\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalle \acr{glibc} 2.6
+\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalla \acr{glibc} 2.6
\const{POSIX\_MADV\_DONTNEED} viene ignorato, in quanto l'uso del
corrispondente \const{MADV\_DONTNEED} di \func{madvise} ha, per la semantica
imperativa, l'effetto immediato di far liberare le pagine da parte del kernel,
\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
sez.~\ref{sec:sys_limits}).
-Nel caso di Linux il limite di sistema è di 1024, però se si usano le
-\acr{glibc} queste forniscono un \textit{wrapper} per le \textit{system call}
+Nel caso di Linux il limite di sistema è di 1024, però se si usa la
+\acr{glibc} essa fornisce un \textit{wrapper} per le \textit{system call}
che si accorge se una operazione supererà il precedente limite, in tal caso i
dati verranno letti o scritti con le usuali \func{read} e \func{write} usando
-un buffer di dimensioni sufficienti appositamente allocato e sufficiente a
+un buffer di dimensioni sufficienti appositamente allocato in grado di
contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
descriptor (si ricordi quanto visto in sez.~\ref{sec:file_adv_func}) con delle
chiamate a \func{lseek}.
+% TODO trattare preadv2() e pwritev2(), introdotte con il kernel 4.6, vedi
+% http://lwn.net/Articles/670231/ ed il flag RWF_HIPRI, anche l'aggiunta del
+% flag RWF_APPEND a pwritev2 con il kernel 4.16, vedi
+% https://lwn.net/Articles/746129/
\subsection{L'I/O diretto fra file descriptor: \func{sendfile} e
La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
fra due file descriptor è \func{sendfile}.\footnote{la funzione è stata
- introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
+ introdotta con i kernel della serie 2.2, e disponibile dalla \acr{glibc}
2.1.} La funzione è presente in diverse versioni di Unix (la si ritrova ad
esempio in FreeBSD, HPUX ed altri Unix) ma non è presente né in POSIX.1-2001
né in altri standard (pertanto si eviti di utilizzarla se si devono scrivere
% TODO?? dal 2.6.25 splice ha ottenuto il supporto per la ricezione su rete
+% TODO trattare qui copy_file_range (vedi http://lwn.net/Articles/659523/),
+% introdotta nel kernel 4.5
+
\subsection{Gestione avanzata dell'accesso ai dati dei file}
\label{sec:file_fadvise}
che l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
\textit{sparse file} (vedi sez.~\ref{sec:file_lseek}) senza una effettiva
allocazione dello spazio disco.} In realtà questa è la modalità con cui la
-funzione veniva realizzata nella prima versione fornita dalle \acr{glibc}, per
+funzione veniva realizzata nella prima versione fornita dalla \acr{glibc}, per
cui la funzione costituiva in sostanza soltanto una standardizzazione delle
modalità di esecuzione di questo tipo di allocazioni.
stato introdotto solo a partire dal kernel 2.6.25.} che consente di
realizzare direttamente all'interno del kernel l'allocazione dello spazio
disco così da poter realizzare una versione di \func{posix\_fallocate} con
-prestazioni molto più elevate; nelle \acr{glibc} la nuova \textit{system call}
+prestazioni molto più elevate; nella \acr{glibc} la nuova \textit{system call}
viene sfruttata per la realizzazione di \func{posix\_fallocate} a partire
dalla versione 2.10.
come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
in maniera indiretta con l'ausilio di \func{syscall}, vedi
sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
- loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
+ loff\_t offset, loff\_t len)}.} ma a partire dalla \acr{glibc} 2.10 è
stato fornito un supporto esplicito; il suo prototipo è:
\begin{funcproto}{
% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
% http://kernelnewbies.org/Linux_2_6_23
+
% TODO aggiungere FALLOC_FL_ZERO_RANGE e FALLOC_FL_COLLAPSE_RANGE, inseriti
% nel kernel 3.15 (sul secondo vedi http://lwn.net/Articles/589260/), vedi
% anche http://lwn.net/Articles/629965/
% TODO aggiungere FALLOC_FL_INSERT vedi http://lwn.net/Articles/629965/
+% TODO aggiungere i file hints di fcntl (F_GET_RW_HINT e compagnia)
+% con RWH_WRITE_LIFE_EXTREME e RWH_WRITE_LIFE_SHORT aggiunte con
+% il kernel 4.13 (vedi https://lwn.net/Articles/727385/)
+
+\subsection{Altre funzionalità avanzate}
+\label{sec:file_seal_et_al}
+
+da fare
% TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
-% http://lwn.net/Articles/432757/
+% http://lwn.net/Articles/432757/ (probabilmente da associare alle
+% at-functions)
+
+% TODO: trattare i file seal, vedi fcntl / F_ADD_SEAL e memfd_create
+
+% TODO trattare qui ioctl_ficlonerange ?
+
+
% LocalWords: dell'I locking multiplexing cap sez system call socket BSD GID