Ancora pipe e correzioni per l'uso della macro Console.

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index 987a1d731c92f66d2d3737bd424f4e0a972db888..c7186d530391897d2d8b052d2d90a09ec37d9fd6 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-2013 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",
 %% 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}.}


@@ -400,11 +398,8 @@ Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
 specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
 predefiniti specificano di non attendere), otterremo come risultato sul
 terminale:
 specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
 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


@@ -418,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


@@ -488,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


@@ -515,7 +509,7 @@ 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
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato


@@ -782,10 +776,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


@@ -797,10 +789,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


@@ -831,11 +823,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


@@ -843,7 +832,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


@@ -1255,7 +1245,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


@@ -1376,7 +1366,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}{ 


@@ -1665,14 +1655,16 @@ 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
+\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}.\footnote{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 è
   \url{http://www.in-ulm.de/~mascheck/various/shebang/}.}
 
 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è


@@ -2836,7 +2828,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:


@@ -3773,6 +3765,11 @@ 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 
+
+

 \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


@@ -3896,6 +3893,10 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
 \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.
 \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/
+

 \label{sec:prctl_operation}
 \end{basedescript}
 
 \label{sec:prctl_operation}
 \end{basedescript}
 


@@ -3971,13 +3972,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


@@ -4037,7 +4038,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


@@ -4050,9 +4051,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}]


@@ -4074,8 +4094,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}


@@ -4083,6 +4106,9 @@ 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/) 
+

 
 
 \subsection{La gestione delle operazioni in virgola mobile}
 
 
 \subsection{La gestione delle operazioni in virgola mobile}


@@ -4121,6 +4147,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}