X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=prochand.tex;h=76b801cf579002a154d005149b8a08a0ed2d7dce;hb=1e4d83a2fbb6ea0d957d96ebde4ebb486f69cd37;hp=abe6f477066509608cc93081249bdbf63879eaf3;hpb=ffb12837c5ed8ccc095bc9c88349cd19b5e6b472;p=gapil.git

diff --git a/prochand.tex b/prochand.tex
index abe6f47..76b801c 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -238,12 +238,12 @@ Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un
 candidato per generare ulteriori indicatori associati al processo di cui
 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
-\ids{PID} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa
-funzione. Questo utilizzo però può risultare pericoloso, un \ids{PID} infatti
-è univoco solo fintanto che un processo è attivo, una volta terminato esso
-potrà essere riutilizzato da un processo completamente diverso, e di questo
-bisogna essere ben consapevoli.
+\ids{PID} per generare un \textit{pathname} univoco, che non potrà essere
+replicato da un altro processo che usi la stessa funzione. Questo utilizzo
+però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto
+che un processo è attivo, una volta terminato esso potrà essere riutilizzato
+da un processo completamente diverso, e di questo bisogna essere ben
+consapevoli.
 
 Tutti i processi figli dello stesso processo padre sono detti
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
@@ -668,7 +668,7 @@ una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
 \end{itemize*}
 
 Una seconda funzione storica usata per la creazione di un nuovo processo è
-\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
+\funcm{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
 semantica e gli stessi errori; la sola differenza è che non viene creata la
 tabella delle pagine né la struttura dei task per il nuovo processo. Il
 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
@@ -700,7 +700,7 @@ di vista di come il sistema gestisce la conclusione dei processi.
 Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
 programma viene terminato in maniera normale: la chiamata di \func{exit}, che
 esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
-esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente alla
+esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
 chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
 direttamente alle operazioni di terminazione del processo da parte del kernel.
 
@@ -746,7 +746,7 @@ Nel caso di conclusione normale, abbiamo visto in
 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
 valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
-valore di ritorno per \func{main}.  Ma se il processo viene concluso in
+valore di ritorno per \code{main}.  Ma se il processo viene concluso in
 maniera anomala il programma non può specificare nessun \textit{exit status},
 ed è il kernel che deve generare autonomamente il \textit{termination status}
 per indicare le ragioni della conclusione anomala.
@@ -1146,7 +1146,7 @@ anomala), uno per indicare se è stato generato un \itindex{core~dump}
                                       significativi dello stato di uscita del
                                       processo (passato attraverso
                                       \func{\_exit}, \func{exit} o come valore
-                                      di ritorno di \func{main}); può essere
+                                      di ritorno di \code{main}); può essere
                                       valutata solo se \val{WIFEXITED} ha
                                       restituito un valore non nullo.\\ 
     \macro{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
@@ -1392,7 +1392,7 @@ prototipo è:
   \item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono
     eseguibili, o il file è su un filesystem montato con l'opzione
     \cmd{noexec}, o manca  il permesso di attraversamento di una delle
-    directory del pathname.
+    directory del \textit{pathname}.
   \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
     \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
     interprete.
@@ -1415,11 +1415,11 @@ prototipo è:
 \end{funcproto}
 
 La funzione \func{execve} esegue il programma o lo script indicato dal
-pathname \param{filename}, passandogli la lista di argomenti indicata
+\textit{pathname} \param{filename}, passandogli la lista di argomenti indicata
 da \param{argv} e come ambiente la lista di stringhe indicata
 da \param{envp}. Entrambe le liste devono essere terminate da un puntatore
 nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal
-nuovo programma quando la sua funzione \func{main} è dichiarata nella forma
+nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
 \code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
 passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
 torneremo in sez.~\ref{sec:sys_res_limits}).
@@ -1487,7 +1487,7 @@ illustrata in fig.~\ref{fig:proc_exec_relat}.
 
 La prima differenza fra le funzioni riguarda le modalità di passaggio dei
 valori che poi andranno a costituire gli argomenti a linea di comando (cioè i
-valori di \param{argv} e \param{argc} visti dalla funzione \func{main} del
+valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
 programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
 ``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
 e \textit{list}.
@@ -1522,7 +1522,7 @@ proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
 se non viene trovato nessun altro file viene finalmente restituito
 \errcode{EACCES}.  Le altre quattro funzioni si limitano invece a cercare di
 eseguire il file indicato dall'argomento \param{path}, che viene interpretato
-come il \itindex{pathname} \textit{pathname} del programma.
+come il \textit{pathname} del programma.
 
 La terza differenza è come viene passata la lista delle variabili di ambiente.
 Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
@@ -2211,7 +2211,7 @@ chiamata con un vettore di dimensioni adeguate.
 
 Infine per impostare i gruppi supplementari di un processo ci sono due
 funzioni, che possono essere usate solo se si hanno i privilegi di
-amministratore.\footnote{e più precisamente se si ha la \itindex{capability}
+amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
   \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è
 \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
   differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
@@ -3216,7 +3216,7 @@ Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
 valutato più volte. Questo significa ad esempio che non si può usare al suo
 posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
 volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
-\itindex{side!effects} \textit{side effects}).\footnote{nel linguaggio C si
+\itindex{side~effects} \textit{side effects}).\footnote{nel linguaggio C si
   parla appunto di \textit{side effects} quando si usano istruzioni la cui
   valutazione comporta effetti al di fuori dell'istruzione stessa, come il
   caso indicato in cui si passa una funzione ad una macro che usa l'argomento
@@ -3758,7 +3758,7 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
   impostato ad 1. Una volta abilitato il \itindex{secure~computing~mode}
   \textit{secure computing mode} il processo potrà utilizzare soltanto un
   insieme estremamente limitato di \textit{system call}: \func{read},
-  \func{write}, \func{\_exit} e \func{sigreturn}. Ogni altra \textit{system
+  \func{write}, \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system
     call} porterà all'emissione di un \signal{SIGKILL} (vedi
   sez.~\ref{sec:sig_termination}).  Il \textit{secure computing mode} è stato
   ideato per fornire un supporto per l'esecuzione di codice esterno non fidato
@@ -3901,9 +3901,9 @@ processi, che poi è stata utilizzata anche per fornire supporto per le
 tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
 
 Per questo l'interfaccia per la creazione di un nuovo processo è stata
-delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di
-reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più
-che di nuovi processi si può parlare della creazioni di nuovi
+delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
+di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
+più che di nuovi processi si può parlare della creazioni di nuovi
 ``\textit{task}'' del kernel che possono assumere la veste sia di un processo
 classico isolato dagli altri come quelli trattati finora, che di un
 \textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
@@ -4062,6 +4062,9 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa
 \end{basedescript}
 
 
+%TODO trattare unshare
+
+
 \subsection{La funzione \func{ptrace}}
 \label{sec:process_ptrace}