projects / gapil.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Appunti rimasti indietro
[gapil.git] / prochand.tex
diff --git a/prochand.tex b/prochand.tex
index fa6e1d50969b63087422d86a5b12a7a3865e21e7..a43b44bfb2045c658543fd6f0742220b20dfd277 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -1,6 +1,6 @@
 %% prochand.tex
 %%
 %% prochand.tex
 %%
-%% Copyright (C) 2000-2012 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2014
 %% 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",
@@ -80,10 +80,8 @@ posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize
-\begin{Command}
-[piccardi@gont piccardi]$ pstree -n 
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+[piccardi@gont piccardi]$ \textbf{pstree -n} 
 init-+-keventd
      |-kapm-idled
      |-kreiserfsd
 init-+-keventd
      |-kapm-idled
      |-kreiserfsd
@@ -115,7 +113,7 @@ init-+-keventd
      |-5*[getty]
      |-snort
      `-wwwoffled
      |-5*[getty]
      |-snort
      `-wwwoffled
-\end{Terminal}
+\end{Console}
 %$
   \caption{L'albero dei processi, così come riportato dal comando
     \cmd{pstree}.}
 %$
   \caption{L'albero dei processi, così come riportato dal comando
     \cmd{pstree}.}
@@ -157,19 +155,15 @@ in fig.~\ref{fig:proc_task_struct}.
 
 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
 \textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
 
 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
 \textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni \textit{system call} ed ad ogni interrupt e in una serie di
-altre occasioni, ma può essere anche attivato esplicitamente. Il timer di
-sistema provvede comunque a che esso sia invocato periodicamente; generando un
-interrupt periodico secondo la frequenza specificata dalla costante
-\const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
-  tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
-  portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
-  compilazione del kernel, con un default di 250 e valori possibili di 100,
-  250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
-  refresh della televisione); occorre fare attenzione a non confondere questo
-  valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
-  sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.
+eseguito in occasione di dell'invocazione di ogni \textit{system call} ed per
+ogni interrupt dall'hardware oltre che in una serie di altre occasioni, e può
+essere anche attivato esplicitamente. Il timer di sistema provvede comunque a
+che esso sia invocato periodicamente, generando un interrupt periodico secondo
+una frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
+(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
+che lo \textit{scheduler} scheduler venga comunque eseguito ad intervalli
+regolari e possa prendere le sue decisioni.
+
 
 A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
 completamente diverso, detto \textit{tickless}, in cui non c'è più una
 
 A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
 completamente diverso, detto \textit{tickless}, in cui non c'è più una
@@ -335,9 +329,8 @@ valore nullo, che non è il \ids{PID} di nessun processo.
 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
 sono già troppi processi nel sistema, il che di solito è sintomo che
 qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
 sono già troppi processi nel sistema, il che di solito è sintomo che
 qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
-sul numero totale di processi permessi all'utente argomento su cui torneremo
-in sez.~\ref{sec:sys_resource_limit}, (vedi in particolare
-tab.~\ref{tab:sys_rlimit_values}).
+sul numero totale di processi permessi all'utente, argomento che tratteremo in
+dettaglio in sez.~\ref{sec:sys_resource_limit}.
 
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli cui viene
 
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli cui viene
@@ -390,26 +383,23 @@ distribuito insieme agli altri sorgenti degli esempi su
 \url{http://gapil.truelite.it/gapil_source.tgz}.
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
 \url{http://gapil.truelite.it/gapil_source.tgz}.
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
-(\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
+(\texttt{\small 24-40}) esegue in successione la creazione dei processi figli
 controllando il successo della chiamata a \func{fork} (\texttt{\small
 controllando il successo della chiamata a \func{fork} (\texttt{\small
-  25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
+  25-29}); ciascun figlio (\texttt{\small 31-34}) si limita a stampare il
 suo numero di successione, eventualmente attendere il numero di secondi
 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
 suo numero di successione, eventualmente attendere il numero di secondi
 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
-(\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
+(\texttt{\small 36-38}) stampa un messaggio di creazione, eventualmente
 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
 periodo di attesa.
 
 Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
   LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
 periodo di attesa.
 
 Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
   LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
-specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
+specificare attese (come si può notare in (\texttt{\small 17-19}) i valori
 predefiniti specificano di non attendere), otterremo come risultato sul
 terminale:
 predefiniti specificano di non attendere), otterremo come risultato sul
 terminale:
-\begin{Command}
-[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3}
 Process 1963: forking 3 child
 Spawned 1 child, pid 1964 
 Child 1 successfully executing
 Process 1963: forking 3 child
 Spawned 1 child, pid 1964 
 Child 1 successfully executing
@@ -423,7 +413,8 @@ Child 3 successfully executing
 Child 3, parent 1963, exiting
 Spawned 3 child, pid 1966 
 Go to next child 
 Child 3, parent 1963, exiting
 Spawned 3 child, pid 1966 
 Go to next child 
-\end{Terminal} 
+\end{Console}
+%$
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
@@ -493,11 +484,9 @@ se buona parte dei concetti relativi ai file verranno trattati più avanti
 (principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
 quello che avviene si può redirigere su un file l'output del programma di
 test, quello che otterremo è:
 (principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
 quello che avviene si può redirigere su un file l'output del programma di
 test, quello che otterremo è:
-\begin{Command}
-[piccardi@selidor sources]$ ./forktest 3 > output
-[piccardi@selidor sources]$ cat output
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{./forktest 3 > output}
+[piccardi@selidor sources]$ \textbf{cat output}
 Process 1967: forking 3 child
 Child 1 successfully executing
 Child 1, parent 1967, exiting
 Process 1967: forking 3 child
 Child 1 successfully executing
 Child 1, parent 1967, exiting
@@ -520,31 +509,34 @@ Spawned 2 child, pid 1969
 Go to next child 
 Spawned 3 child, pid 1970 
 Go to next child 
 Go to next child 
 Spawned 3 child, pid 1970 
 Go to next child 
-\end{Terminal}
+\end{Console}
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
 in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
 nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
 adottata nelle librerie del linguaggio C e valida per qualunque sistema
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
 in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
 nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
 adottata nelle librerie del linguaggio C e valida per qualunque sistema
-operativo. Qui basta accennare che si sono usate le funzioni standard della
-libreria del C che prevedono l'output bufferizzato. Il punto è che questa
-bufferizzazione (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering})
-varia a seconda che si tratti di un file su disco, in cui il buffer viene
-scaricato su disco solo quando necessario, o di un terminale, in cui il buffer
-viene scaricato ad ogni carattere di a capo.
+operativo. 
+
+Qui basta accennare che si sono usate le funzioni standard della libreria del
+C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione
+(che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda
+che si tratti di un file su disco, in cui il buffer viene scaricato su disco
+solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad
+ogni carattere di a capo.
 
 Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
 stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
 le singole righe comparivano a video subito dopo l'esecuzione della
 \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
 
 Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
 stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
 le singole righe comparivano a video subito dopo l'esecuzione della
 \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
-fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una
-copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle
-funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando
-il buffer viene scritto su disco all'uscita del figlio, troveremo nel file
-anche tutto quello che il processo padre aveva scritto prima della sua
-creazione. E alla fine del file (dato che in questo caso il padre esce per
-ultimo) troveremo anche l'output completo del padre.
+fine di ogni riga e l'output resta nel buffer. 
+
+Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà
+anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte
+dal padre fino allora. Così quando il buffer viene scritto su disco all'uscita
+del figlio, troveremo nel file anche tutto quello che il processo padre aveva
+scritto prima della sua creazione. E alla fine del file (dato che in questo
+caso il padre esce per ultimo) troveremo anche l'output completo del padre.
 
 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
 
 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
@@ -555,17 +547,17 @@ avviene per le variabili in memoria, la posizione corrente sul file è
 condivisa fra il padre e tutti i processi figli.
 
 Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
 condivisa fra il padre e tutti i processi figli.
 
 Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
-  così il file su cui un programma scrive i suoi dati in uscita, tratteremo
-  l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre viene
-rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
-figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
-processi figli tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd})
-dei file aperti nel processo padre (allo stesso modo in cui lo fa la funzione
-\func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
-figli condividono le stesse voci della \itindex{file~table} \textit{file
-  table} (tratteremo in dettaglio questi termini in
-sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione corrente nel
-file.
+  così il file su cui di default un programma scrive i suoi dati in uscita,
+  tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre
+viene rediretto come si è fatto nell'esempio, lo stesso avviene anche per
+tutti i figli. La funzione \func{fork} infatti ha la caratteristica di
+duplicare nei processi figli tutti i \textit{file descriptor} (vedi
+sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
+in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il
+che comporta che padre e figli condividono le stesse voci della
+\itindex{file~table} \textit{file table} (tratteremo in dettaglio questi
+termini in sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione
+corrente nel file.
 
 In questo modo se un processo scrive su un file aggiornerà la posizione
 corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
 
 In questo modo se un processo scrive su un file aggiornerà la posizione
 corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
@@ -607,10 +599,10 @@ comune dopo l'esecuzione di una \func{fork} è la seguente:
 \begin{itemize*}
 \item i file aperti e gli eventuali flag di \itindex{close-on-exec}
   \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
 \begin{itemize*}
 \item i file aperti e gli eventuali flag di \itindex{close-on-exec}
   \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
-  sez.~\ref{sec:file_fcntl});
+  sez.~\ref{sec:file_fcntl_ioctl});
 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
     reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
     reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
-  \textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
+  \textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
   sez.~\ref{sec:proc_access_id});
 \item gli identificatori per il controllo di sessione: il
   \itindex{process~group} \textit{process group-ID} e il \textit{session id}
   sez.~\ref{sec:proc_access_id});
 \item gli identificatori per il controllo di sessione: il
   \itindex{process~group} \textit{process group-ID} e il \textit{session id}
@@ -619,8 +611,9 @@ comune dopo l'esecuzione di una \func{fork} è la seguente:
   (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
 \item la maschera dei permessi di creazione dei file (vedi
   sez.~\ref{sec:file_perm_management});
   (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
 \item la maschera dei permessi di creazione dei file (vedi
   sez.~\ref{sec:file_perm_management});
-\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
-  azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
+\item la \index{maschera~dei~segnali} maschera dei segnali bloccati (vedi
+  sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
+  sez.~\ref{sec:sig_gen_beha});
 \item i segmenti di memoria condivisa agganciati al processo (vedi
   sez.~\ref{sec:ipc_sysv_shm});
 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
 \item i segmenti di memoria condivisa agganciati al processo (vedi
   sez.~\ref{sec:ipc_sysv_shm});
 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
@@ -786,10 +779,8 @@ stato di terminazione.
 Come verifica di questo comportamento possiamo eseguire il nostro programma
 \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
 di uscire, il risultato è:
 Come verifica di questo comportamento possiamo eseguire il nostro programma
 \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
 di uscire, il risultato è:
-\begin{Command}
-[piccardi@selidor sources]$ ./forktest -c2 3
-\end{Command}
-\begin{Terminal}[commandchars=\\\{\}]
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{./forktest -c2 3}
 Process 1972: forking 3 child
 Spawned 1 child, pid 1973 
 Child 1 successfully executing
 Process 1972: forking 3 child
 Spawned 1 child, pid 1973 
 Child 1 successfully executing
@@ -801,10 +792,10 @@ Child 3 successfully executing
 Spawned 3 child, pid 1975 
 Go to next child 
 
 Spawned 3 child, pid 1975 
 Go to next child 
 
-\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
+[piccardi@selidor sources]$ Child 3, parent 1, exiting
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
-\end{Terminal}
+\end{Console}
 come si può notare in questo caso il processo padre si conclude prima dei
 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
 secondi dopo viene stampato a video anche l'output dei tre figli che
 come si può notare in questo caso il processo padre si conclude prima dei
 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
 secondi dopo viene stampato a video anche l'output dei tre figli che
@@ -835,11 +826,8 @@ condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
 terminale (prima dello scadere dei 10 secondi) otterremo:
 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
 terminale (prima dello scadere dei 10 secondi) otterremo:
-\begin{Command}
-[piccardi@selidor sources]$ ps T
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{ps T}
   PID TTY      STAT   TIME COMMAND
   419 pts/0    S      0:00 bash
   568 pts/0    S      0:00 ./forktest -e10 3
   PID TTY      STAT   TIME COMMAND
   419 pts/0    S      0:00 bash
   568 pts/0    S      0:00 ./forktest -e10 3
@@ -847,7 +835,8 @@ terminale (prima dello scadere dei 10 secondi) otterremo:
   570 pts/0    Z      0:00 [forktest <defunct>]
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
   570 pts/0    Z      0:00 [forktest <defunct>]
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
-\end{Terminal} 
+\end{Console}
+%$
 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
 terminazione, i tre processi figli sono ancora presenti pur essendosi
 conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
 terminazione, i tre processi figli sono ancora presenti pur essendosi
 conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
@@ -855,18 +844,18 @@ sono terminati (la scritta \texttt{defunct}).
 
 La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
 tenuta sempre presente quando si scrive un programma che deve essere mantenuto
 
 La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
 tenuta sempre presente quando si scrive un programma che deve essere mantenuto
-in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
-avere cura di far leggere l'eventuale stato di uscita di tutti i figli. In
-genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
-la funzione \func{wait}, (vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}) di cui vedremo un esempio in
-fig.~\ref{fig:sig_sigchld_handl}.  
-
-Questa operazione è necessaria perché anche se gli \itindex{zombie}
-\textit{zombie} non consumano risorse di memoria o processore, occupano
-comunque una voce nella tabella dei processi e se li si lascia accumulare a
-lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi
-processi. 
+in esecuzione a lungo e creare molti processi figli. In questo caso si deve
+sempre avere cura di far leggere al programma l'eventuale stato di uscita di
+tutti i figli. Una modalità comune di farlo è attraverso l'utilizzo di un
+apposito \textit{signal handler} che chiami la funzione \func{wait}, (vedi
+sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio
+(fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}.
+
+La lettura degli stati di uscita è necessaria perché anche se gli
+\itindex{zombie} \textit{zombie} non consumano risorse di memoria o
+processore, occupano comunque una voce nella tabella dei processi e se li si
+lasciano accumulare a lungo quest'ultima potrebbe esaurirsi, con la
+conseguente impossibilità di lanciare nuovi processi.
 
 Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
 diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
 
 Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
 diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
@@ -882,9 +871,16 @@ provvede a completarne la terminazione.
 Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
 processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
 inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
 Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
 processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
 inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
-sez.~\ref{sec:sig_termination}). L'unica possibilità di cancellarli dalla
-tabella dei processi è quella di terminare il processo che li ha generati, in
-modo che \cmd{init} possa adottarli e concluderne la terminazione.
+sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+terminare il processo che li ha generati e che non sta facendo il suo lavoro,
+in modo che \cmd{init} possa adottarli e concluderne correttamente la
+terminazione. 
+
+Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei
+processi non è sempre indice di un qualche malfunzionamento, in una macchina
+con molto carico infatti può esservi una presenza temporanea dovuta al fatto
+che il processo padre ancora non ha avuto il tempo di gestirli. 
 
 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
 \label{sec:proc_wait}
 
 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
 \label{sec:proc_wait}
@@ -1128,9 +1124,10 @@ tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare
 lo \itindex{exit~status} stato di uscita del processo, e gli altri per
 indicare il segnale che ha causato la terminazione (in caso di conclusione
 anomala), uno per indicare se è stato generato un \itindex{core~dump}
 lo \itindex{exit~status} stato di uscita del processo, e gli altri per
 indicare il segnale che ha causato la terminazione (in caso di conclusione
 anomala), uno per indicare se è stato generato un \itindex{core~dump}
-\textit{core dump}, ecc.\footnote{le definizioni esatte si possono trovare in
-  \file{<bits/waitstatus.h>} ma questo file non deve mai essere usato
-  direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
+\textit{core dump} (vedi sez.~\ref{sec:sig_standard}), ecc.\footnote{le
+  definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
+  questo file non deve mai essere usato direttamente, esso viene incluso
+  attraverso \file{<sys/wait.h>}.}
 
 \begin{table}[!htb]
   \centering
 
 \begin{table}[!htb]
   \centering
@@ -1258,7 +1255,7 @@ primo, quale processo o quale gruppo di processi selezionare.
   \label{tab:proc_waitid_idtype}
 \end{table}
 
   \label{tab:proc_waitid_idtype}
 \end{table}
 
-Come per \func{waitpid} anche il comportamento di \func{waitid} viene
+Come per \func{waitpid} anche il comportamento di \func{waitid} è
 controllato dall'argomento \param{options}, da specificare come maschera
 binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
 alcuni di questi siano identici come significato ed effetto ai precedenti di
 controllato dall'argomento \param{options}, da specificare come maschera
 binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
 alcuni di questi siano identici come significato ed effetto ai precedenti di
@@ -1319,8 +1316,8 @@ campi:
   \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
   \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
   significato è, nell'ordine: uscita normale, terminazione da segnale,
   \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
   \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
   significato è, nell'ordine: uscita normale, terminazione da segnale,
-  processo fermato, processo riavviato, processo terminato in \textit{core
-    dump}.
+  processo fermato, processo riavviato, processo terminato in
+  \itindex{core~dump} \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
 \end{basedescript}
 
 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
 \end{basedescript}
 
 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
@@ -1379,7 +1376,7 @@ Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
 famiglia di funzioni) che possono essere usate per questo compito, in realtà
 (come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
 tutte varianti che consentono di invocare in modi diversi, semplificando il
 famiglia di funzioni) che possono essere usate per questo compito, in realtà
 (come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
 tutte varianti che consentono di invocare in modi diversi, semplificando il
-passaggio degli argomenti, la \textit{system call} \funcd{execve}, il cui
+passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui
 prototipo è:
 
 \begin{funcproto}{ 
 prototipo è:
 
 \begin{funcproto}{ 
@@ -1504,7 +1501,7 @@ convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
 per indicare il nome del file che contiene il programma che verrà eseguito.
 
 \begin{figure}[!htb]
 per indicare il nome del file che contiene il programma che verrà eseguito.
 
 \begin{figure}[!htb]
-  \centering \includegraphics[width=10cm]{img/exec_rel}
+  \centering \includegraphics[width=9cm]{img/exec_rel}
   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
   \label{fig:proc_exec_relat}
 \end{figure}
   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
   \label{fig:proc_exec_relat}
 \end{figure}
@@ -1540,7 +1537,7 @@ seguente:
 \begin{itemize*}
 \item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
   (\ids{PPID});
 \begin{itemize*}
 \item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
   (\ids{PPID});
-\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
+\item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
   \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
 \item la directory radice e la \index{directory~di~lavoro} directory di lavoro
   corrente (vedi sez.~\ref{sec:file_work_dir});
   \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
 \item la directory radice e la \index{directory~di~lavoro} directory di lavoro
   corrente (vedi sez.~\ref{sec:file_work_dir});
@@ -1560,7 +1557,8 @@ seguente:
 % TODO ===========Importante=============
 % TODO questo sotto è incerto, verificare
 % TODO ===========Importante=============
 % TODO ===========Importante=============
 % TODO questo sotto è incerto, verificare
 % TODO ===========Importante=============
-\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
+\item la \index{maschera~dei~segnali} maschera dei segnali (si veda
+  sez.~\ref{sec:sig_sigmask}). 
 \end{itemize*}
 
 Una serie di proprietà del processo originale, che non avrebbe senso mantenere
 \end{itemize*}
 
 Una serie di proprietà del processo originale, che non avrebbe senso mantenere
@@ -1578,7 +1576,8 @@ seguenti proprietà non vengano preservate:
 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
   e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
   e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
-\item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
+\item i \itindex{memory~locking} \textit{memory lock} (vedi
+  sez.~\ref{sec:proc_mem_lock});
 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
 \item i semafori e le code di messaggi POSIX (vedi
   sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
 \item i semafori e le code di messaggi POSIX (vedi
   sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
@@ -1622,7 +1621,7 @@ nell'esecuzione della funzione \func{exec}, queste sono:
 
 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
 \func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
 
 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
 \func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
-\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl}) per ciascun
+\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun
 \textit{file descriptor}. I file per cui è impostato vengono chiusi, tutti gli
 altri file restano aperti. Questo significa che il comportamento predefinito è
 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
 \textit{file descriptor}. I file per cui è impostato vengono chiusi, tutti gli
 altri file restano aperti. Questo significa che il comportamento predefinito è
 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
@@ -1650,13 +1649,13 @@ file appartiene.
 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
 del programma per caricare le librerie necessarie ed effettuare il link
 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
 del programma per caricare le librerie necessarie ed effettuare il link
-dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
-  molto probabile che non il relativo supporto non sia disponibile.} Se il
-programma è in formato ELF per caricare le librerie dinamiche viene usato
-l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
-stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
-collegati con la \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
-collegati con la \acr{glibc}.
+dell'eseguibile; il formato è ormai in completo disuso, per cui è molto
+probabile che non il relativo supporto non sia disponibile. Se il programma è
+in formato ELF per caricare le librerie dinamiche viene usato l'interprete
+indicato nel segmento \const{PT\_INTERP} previsto dal formato stesso, in
+genere questo è \sysfile{/lib/ld-linux.so.1} per programmi collegati con la
+\acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi collegati con la
+\acr{glibc}.
 
 Infine nel caso il programma che si vuole eseguire sia uno script e non un
 binario, questo deve essere un file di testo che deve iniziare con una linea
 
 Infine nel caso il programma che si vuole eseguire sia uno script e non un
 binario, questo deve essere un file di testo che deve iniziare con una linea
@@ -1666,15 +1665,17 @@ nella forma:
 \end{Example}
 dove l'interprete indicato deve essere un eseguibile binario e non un altro
 script, che verrà chiamato come se si fosse eseguito il comando
 \end{Example}
 dove l'interprete indicato deve essere un eseguibile binario e non un altro
 script, che verrà chiamato come se si fosse eseguito il comando
-\cmd{interpreter [argomenti] filename}.\footnote{si tenga presente che con
-  Linux quanto viene scritto come \texttt{argomenti} viene passato
-  all'interprete come un unico argomento con una unica stringa di lunghezza
-  massima di 127 caratteri e se questa dimensione viene ecceduta la stringa
-  viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
-  comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
-  nei vari argomenti e se è troppo lunga restituisce un errore di
-  \const{ENAMETOOLONG}, una comparazione dei vari comportamenti si trova su
-  \url{http://www.in-ulm.de/~mascheck/various/shebang/}.}
+\cmd{interpreter [argomenti] filename}. 
+
+Si tenga presente che con Linux quanto viene scritto come \texttt{argomenti}
+viene passato all'interprete come un unico argomento con una unica stringa di
+lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la
+stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
+comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
+nei vari argomenti e se è troppo lunga restituisce un errore di
+\const{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
+sistemi unix-like si trova su
+\url{http://www.in-ulm.de/~mascheck/various/shebang/}.
 
 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
 basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
 
 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
 basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
@@ -2154,7 +2155,7 @@ Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
   gruppi secondari può essere ottenuto con \func{sysconf} (vedi
 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
   gruppi secondari può essere ottenuto con \func{sysconf} (vedi
-  sez.~\ref{sec:sys_sysconf}), leggendo il parametro
+  sez.~\ref{sec:sys_limits}), leggendo il parametro
   \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
 ereditati dal processo padre e possono essere cambiati con queste funzioni.
 
   \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
 ereditati dal processo padre e possono essere cambiati con queste funzioni.
 
@@ -2574,7 +2575,7 @@ l'utente correnti.
     \hline
     \const{PRIO\_PROCESS} & \type{pid\_t} & processo  \\
     \const{PRIO\_PRGR}    & \type{pid\_t} & \itindex{process~group}
     \hline
     \const{PRIO\_PROCESS} & \type{pid\_t} & processo  \\
     \const{PRIO\_PRGR}    & \type{pid\_t} & \itindex{process~group}
-                                            \textit{process group}  \\ 
+                                            \textit{process group}\\ 
     \const{PRIO\_USER}    & \type{uid\_t} & utente \\
     \hline
   \end{tabular}
     \const{PRIO\_USER}    & \type{uid\_t} & utente \\
     \hline
   \end{tabular}
@@ -2777,9 +2778,9 @@ corrente.
     \const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
     \const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
                           ulteriore di lavoro \textit{CPU
     \const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
     \const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
                           ulteriore di lavoro \textit{CPU
-                            intensive} (dal kernel 2.6.16)\\ 
+                            intensive} (dal kernel 2.6.16).\\ 
     \const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
     \const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
-                          bassa (dal kernel 2.6.23)\\
+                          bassa (dal kernel 2.6.23).\\
     \hline
   \end{tabular}
   \caption{Valori dell'argomento \param{policy} per la funzione
     \hline
   \end{tabular}
   \caption{Valori dell'argomento \param{policy} per la funzione
@@ -2787,6 +2788,10 @@ corrente.
   \label{tab:proc_sched_policy}
 \end{table}
 
   \label{tab:proc_sched_policy}
 \end{table}
 
+% TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta
+% con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e
+% http://lwn.net/Articles/575497/
+
 Con le versioni più recenti del kernel sono state introdotte anche delle
 varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
 di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
 Con le versioni più recenti del kernel sono state introdotte anche delle
 varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
 di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
@@ -2823,7 +2828,7 @@ rispettivamente 1 e 99.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
 
 \begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{\textwidth}
+  \begin{minipage}[c]{0.5\textwidth}
     \includestruct{listati/sched_param.c}
   \end{minipage} 
   \normalsize 
     \includestruct{listati/sched_param.c}
   \end{minipage} 
   \normalsize 
@@ -2837,7 +2842,7 @@ errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con
 la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
 impostato con le funzioni viste in precedenza.
 
 la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
 impostato con le funzioni viste in precedenza.
 
-Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle
+Lo standard POSIX.1b prevede inoltre che l'intervallo dei valori delle
 priorità statiche possa essere ottenuto con le funzioni di sistema
 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
 prototipi sono:
 priorità statiche possa essere ottenuto con le funzioni di sistema
 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
 prototipi sono:
@@ -3466,15 +3471,15 @@ della priorità da impostare con l'argomento \param{ioprio} di
     \hline
     \hline
     \macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
     \hline
     \hline
     \macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
-                                & dato il valore di una priorità come
+                                & Dato il valore di una priorità come
                                   restituito da \func{ioprio\_get} estrae il
                                   valore della classe.\\
     \macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
                                   restituito da \func{ioprio\_get} estrae il
                                   valore della classe.\\
     \macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
-                                & dato il valore di una priorità come
+                                & Dato il valore di una priorità come
                                   restituito da \func{ioprio\_get} estrae il
                                   valore della priorità.\\
     \macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
                                   restituito da \func{ioprio\_get} estrae il
                                   valore della priorità.\\
     \macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
-                                & dato un valore di priorità ed una classe
+                                & Dato un valore di priorità ed una classe
                                   ottiene il valore numerico da passare a
                                   \func{ioprio\_set}.\\
     \hline
                                   ottiene il valore numerico da passare a
                                   \func{ioprio\_set}.\\
     \hline
@@ -3566,6 +3571,7 @@ questo caso non ci sono effetti sugli altri processi questo limite è stato
 rimosso a partire dal kernel 2.6.25.
 
 %TODO verificare http://lwn.net/Articles/355987/
 rimosso a partire dal kernel 2.6.25.
 
 %TODO verificare http://lwn.net/Articles/355987/
+
 \section{Funzioni di gestione avanzata}
 \label{sec:proc_advanced_control}
 
 \section{Funzioni di gestione avanzata}
 \label{sec:proc_advanced_control}
 
@@ -3774,6 +3780,14 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
   Introdotta a partire dal kernel 2.6.23, disponibile solo se si è abilitato
   il supporto nel kernel con \texttt{CONFIG\_SECCOMP}.
 
   Introdotta a partire dal kernel 2.6.23, disponibile solo se si è abilitato
   il supporto nel kernel con \texttt{CONFIG\_SECCOMP}.
 
+% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
+% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
+% Documentation/prctl/seccomp_filter.txt 
+% vedi anche http://lwn.net/Articles/600250/
+
+% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
+% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
+
 \item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
   lo stato corrente del \textit{secure computing mode}, al momento attuale la
   funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
 \item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
   lo stato corrente del \textit{secure computing mode}, al momento attuale la
   funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
@@ -3887,6 +3901,30 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
   memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
   nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
   partire dal kernel 2.6.32.
   memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
   nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
   partire dal kernel 2.6.32.
+% TODO: verificare questa parte
+\item[\const{PR\_SET\_CHILD\_SUBREAPER}] Imposta il processo indicato con il
+  \ids{PID} specificato da \param{arg2} come nuovo ``\textsl{genitore
+    adottivo}'' per tutti i processi discendenti del chiamante che
+  diventeranno orfani, sostituendo in questo ruolo \cmd{init} (si ricordi
+  quanto illustrato in sez.~\ref{sec:proc_termination}). Introdotta a partire
+  dal kernel 3.4.
+\item[\const{PR\_GET\_CHILD\_SUBREAPER}] Ottiene il \ids{PID} del processo a
+  cui vengono assegnati come figli gli orfani del processo
+  corrente. Introdotta a partire dal kernel 3.4.
+  % TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
+  % * Documentation/prctl/seccomp_filter.txt
+  % * http://lwn.net/Articles/475043/
+
+
+% TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi
+% http://lwn.net/Articles/582712/ 
+
+% TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i
+% parametri di base del layout dello spazio di indirizzi di un processo (area
+% codice e dati, stack, brack pointer ecc. vedi
+% http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e 
+
+
 \label{sec:prctl_operation}
 \end{basedescript}
 
 \label{sec:prctl_operation}
 \end{basedescript}
 
@@ -3962,13 +4000,13 @@ 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
 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,\footnote{è
-  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
-\itindex{copy~on~write} \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.
+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 \itindex{copy~on~write}
+\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
 
 Dato che l'uso principale della nuova \textit{system call} è quello relativo
 alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
@@ -4028,7 +4066,7 @@ utilizzati soltanto se si sono specificati rispettivamente i flag
 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
 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.
+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
 
 Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
 nuovo processo da essa creato, è controllato principalmente
@@ -4041,9 +4079,28 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa
 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
 
 \item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
 \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
 
 \item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
-\item[\const{CLONE\_CHILD\_SETTID}]
-\item[\const{CLONE\_FILES}]
-\item[\const{CLONE\_FS}]
+  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}.
+\item[\const{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}.
+\item[\const{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
+  padre la \itindex{file~descriptor~table} \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
+  \itindex{file~descriptor~table} \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[\const{CLONE\_FS}] se questo flag viene impostato il nuovo processo
+  condividerà con il padre le informazioni 
+
 \item[\const{CLONE\_IO}]
 \item[\const{CLONE\_NEWIPC}]
 \item[\const{CLONE\_NEWNET}]
 \item[\const{CLONE\_IO}]
 \item[\const{CLONE\_NEWIPC}]
 \item[\const{CLONE\_NEWNET}]
@@ -4065,8 +4122,11 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa
 \end{basedescript}
 
 
 \end{basedescript}
 
 
-%TODO trattare unshare
+%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
+
 
 
+%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
+% https://lwn.net/Articles/478111/
 
 \subsection{La funzione \func{ptrace}}
 \label{sec:process_ptrace}
 
 \subsection{La funzione \func{ptrace}}
 \label{sec:process_ptrace}
@@ -4074,6 +4134,11 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa
 Da fare
 
 % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
 Da fare
 
 % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
+% TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
+% http://lwn.net/Articles/529060/) 
+% TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
+% kernel 3.11
+
 
 
 \subsection{La gestione delle operazioni in virgola mobile}
 
 
 \subsection{La gestione delle operazioni in virgola mobile}
@@ -4112,6 +4177,15 @@ Da fare
 % le pagine di manuale relative
 % vedere anche dove metterle...
 
 % le pagine di manuale relative
 % vedere anche dove metterle...
 
+% \subsection{La gestione dei moduli}
+% \label{sec:kernel_modules}
+
+% da fare
+
+%TODO trattare init_module e finit_module (quest'ultima introdotta con il
+%kernel 3.8)
+
+
 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
@@ -4307,7 +4381,7 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale.
 % LocalWords:  filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
 % LocalWords:  ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
 % LocalWords:  ENFILE EMFILE argc execl path execv execle execlp execvp vector
 % LocalWords:  filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
 % LocalWords:  ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
 % LocalWords:  ENFILE EMFILE argc execl path execv execle execlp execvp vector
-% LocalWords:  list environ NULL umask pending utime cutime ustime fcntl linker
+% LocalWords:  list environ NULL umask utime cutime ustime fcntl linker
 % LocalWords:  opendir libc interpreter FreeBSD capabilities mandatory access
 % LocalWords:  control MAC SELinux security modules LSM superuser uid gid saved
 % LocalWords:  effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
 % LocalWords:  opendir libc interpreter FreeBSD capabilities mandatory access
 % LocalWords:  control MAC SELinux security modules LSM superuser uid gid saved
 % LocalWords:  effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
GaPiL: Guida alla Programmazione in Linux