%% fileadv.tex
%%
-%% Copyright (C) 2000-2018 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 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 è
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}.
% 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}
% 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/,
-% http://git.infradead.org/users/hch/vfs.git/commit/d2d9e26c7cb6d95d521153897910080cf56c7fad
+% 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}
% 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
% 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)
% LocalWords: dell'I locking multiplexing cap sez system call socket BSD GID