+La \textit{system call} richiede soltanto due argomenti: il
+primo, \param{flags}, consente di controllare le modalità di creazione del
+nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
+dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
+si intende creare un \textit{thread}. L'esecuzione del programma creato da
+\func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
+stessa.
+
+La necessità di avere uno \textit{stack} alternativo c'è solo quando si
+intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
+vede esattamente la stessa memoria del \textit{task}
+``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
+ il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
+ da essa creato, senza nessuna delle implicazioni che il concetto ha per i
+ processi.} e nella sua esecuzione alla prima chiamata di una funzione
+andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
+quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
+\textit{stack}).
+
+Per evitare di doversi garantire contro la evidente possibilità di
+\textit{race condition} che questa situazione comporta (vedi
+sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
+necessario che il chiamante allochi preventivamente un'area di memoria. In
+genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
+imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
+non utilizzarlo direttamente nel processo chiamante.
+
+In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
+non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
+presente inoltre che in molte architetture di processore lo \textit{stack}
+cresce verso il basso, pertanto in tal caso non si dovrà specificare
+per \param{child\_stack} il puntatore restituito da \func{malloc}, ma un
+puntatore alla fine del buffer da essa allocato.
+
+Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
+memoria, la \textit{system call}, a differenza della funzione di libreria che
+vedremo a breve, consente anche di passare per \param{child\_stack} il valore
+\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
+processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
+cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
+in questo caso si applica la semantica del \textit{copy on write} illustrata
+in sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
+automaticamente copiate come le altre e il nuovo processo avrà un suo
+\textit{stack} totalmente indipendente da quello del padre.
+
+Dato che l'uso principale della nuova \textit{system call} è quello relativo
+alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
+libreria con una sintassi diversa, orientata a questo scopo, e la
+\textit{system call} resta accessibile solo se invocata esplicitamente come
+visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
+ \textit{system call} non è disponibile la chiamata veloce con
+ \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
+\funcd{clone} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
+ ... \\
+\phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
+\fdesc{Crea un nuovo processo o \textit{thread}.}
+}
+{La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
+ di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
+ valori:
+\begin{errlist}
+ \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
+ \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
+ un valore nullo per \param{child\_stack}.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
+ \texttt{task\_struct} o per copiare le parti del contesto del chiamante
+ necessarie al nuovo \textit{task}.
+ \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
+ richiesti dai flag indicati.
+\end{errlist}}
+\end{funcproto}
+
+% NOTE: una pagina con la descrizione degli argomenti:
+% * http://www.lindevdoc.org/wiki/Clone
+
+La funzione prende come primo argomento \param{fn} il puntatore alla funzione
+che verrà messa in esecuzione nel nuovo processo, che può avere un unico
+argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
+terzo argomento \param{arg}. Per quanto il precedente prototipo possa
+intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
+definire una qualunque funzione \param{fn} che restituisce un intero ed ha
+come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
+un nuovo processo.
+
+Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
+non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
+di ritorno della funzione (o quello specificato con \func{exit}) verrà
+utilizzato come stato di uscita della funzione. I tre
+argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
+presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
+le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
+ Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
+utilizzati soltanto se si sono specificati rispettivamente i flag
+\const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
+\const{CLONE\_CHILD\_SETTID}.
+
+La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
+\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
+al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
+un processo ordinario e non un \textit{thread}.
+
+Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
+nuovo processo da essa creato, è controllato principalmente
+dall'argomento \param{flags}, che deve essere specificato come maschera
+binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
+elenco, che illustra quelle attualmente disponibili:\footnote{si fa
+ riferimento al momento della stesura di questa sezione, cioè con il kernel
+ 3.2.}
+
+\begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
+ ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un
+ riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a
+ quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei
+ \textit{thread} ed è presente dal kernel 2.5.49.
+
+\item[\constd{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
+ figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
+ utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
+ kernel 2.5.49.
+
+\item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
+ padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
+ questo significa che ogni \textit{file descriptor} aperto da un processo
+ verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
+ \textit{file descriptor flag} di un \textit{file descriptor} verrà per
+ entrambi.
+
+ Se non viene impostato il processo figlio eredita una copia della
+ \textit{file descriptor table} del padre e vale la semantica classica della
+ gestione dei \textit{file descriptor}, che costituisce il comportamento
+ ordinario di un sistema unix-like e che illustreremo in dettaglio in
+ sez.~\ref{sec:file_shared_access}.
+
+\item[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre le informazioni relative all'albero dei file, ed in
+ particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
+ stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
+ \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
+ qualunque di queste caratteristiche in un processo, avrà effetto anche
+ sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
+ informazioni, che saranno così indipendenti per i due processi, come avviene
+ nel comportamento ordinario di un sistema unix-like.
+
+\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo
+ processo condividerà con il padre il contesto dell'I/O, altrimenti, come
+ come avviene nel comportamento ordinario con una \func{fork} otterrà un suo
+ contesto dell'I/O.
+
+ Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
+ sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
+ questi vengono trattati come se fossero lo stesso, condividendo il tempo per
+ l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
+ questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
+ dello stesso processo (ad esempio con le funzioni di I/O asincrono di
+ sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
+
+%TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
+%relativa sezione da creare a parte
+
+% \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
+% introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
+% processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
+% di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
+% di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
+% tutti quegli oggetti che non vegono identificati con un \textit{pathname}
+% sull'albero dei file.
+
+% L'uso di questo flag richiede privilegi di amministratore (più precisamente
+% la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
+% con \const{CLONE\_SYSVSEM}.
+
+% \item[\constd{CLONE\_NEWNET}]
+% \item[\constd{CLONE\_NEWNS}]
+% \item[\constd{CLONE\_NEWPID}]
+% \item[\constd{CLONE\_NEWUTS}]
+
+
+% TODO trattare CLONE_NEWCGROUP introdotto con il kernel 4.6, vedi
+% http://lwn.net/Articles/680566/
+
+\item[\constd{CLONE\_PARENT}]
+\item[\constd{CLONE\_PARENT\_SETTID}]
+\item[\constd{CLONE\_PID}]
+
+\item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
+ chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
+ figlio viene tracciato.
+
+\item[\constd{CLONE\_SETTLS}]
+\item[\constd{CLONE\_SIGHAND}]
+\item[\constd{CLONE\_STOPPED}]
+\item[\constd{CLONE\_SYSVSEM}]
+\item[\constd{CLONE\_THREAD}]
+
+\item[\constd{CLONE\_UNTRACED}] se questo flag viene impostato un processo non
+ può più forzare \const{CLONE\_PTRACE} su questo processo.
+
+\item[\constd{CLONE\_VFORK}] se questo flag viene impostato il chiamante viene
+ fermato fintato che il figlio appena creato non rilascia la sua memoria
+ virtuale con una chiamata a \func{exec} o \func{exit}, viene quindi
+ replicato il comportamento di \func{vfork}.
+
+\item[\constd{CLONE\_VM}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre la stessa memoria virtuale, e le scritture in
+ memoria fatte da uno qualunque dei processi saranno visibili dall'altro,
+ così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}).
+
+ Se non viene impostato il processo figlio otterrà una copia dello spazio
+ degli indirizzi e si otterrà il comportamento ordinario di un processo di un
+ sistema unix-like creato con la funzione \func{fork}.
+\end{basedescript}
+
+
+%TODO sezione separata sui namespace
+
+%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
+
+%TODO: trattare la funzione setns e i namespace file descriptors (vedi
+% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
+% informazioni su setns qui: http://lwn.net/Articles/532748/
+% http://lwn.net/Articles/531498/
+
+
+% TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
+% pkey_mprotect, introdotte con il kernel 4.8, vedi
+% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
+
+%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
+% https://lwn.net/Articles/478111/
+
+%\subsection{La funzione \func{ptrace}}
+%\label{sec:process_ptrace}
+
+%Da fare