Risistemata introduzione e login

diff --git a/prochand.tex b/prochand.tex
index 5186e4155337a7da038ea9aa40879f7bb497469f..ef75e52dd8c52b2235666884701029c885a738a7 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -767,15 +767,15 @@ informazioni riguardo ai processi che sta terminando.
 
 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
 
 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati

-dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di
-terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria
-in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono
-terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal
-padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei
-processi ed in genere possono essere identificati dall'output di \cmd{ps} per
-la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il
-padre effettuerà la lettura dello stato di uscita anche questa informazione,
-non più necessaria, verrà scartata e la terminazione potrà dirsi completamente
+dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di terminazione,
+mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
+processi che sono terminati, ma il cui stato di terminazione non è stato
+ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
+nella tabella dei processi ed in genere possono essere identificati
+dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
+indica lo stato (vedi \tabref{tab:proc_proc_states}). Quando il padre
+effettuerà la lettura dello stato di uscita anche questa informazione, non più
+necessaria, verrà scartata e la terminazione potrà dirsi completamente

 conclusa.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
 conclusa.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa


@@ -925,14 +925,16 @@ specchietto riportato in \tabref{tab:proc_waidpid_pid}:
 Il comportamento di \func{waitpid} può inoltre essere modificato passando
 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
 Il comportamento di \func{waitpid} può inoltre essere modificato passando
 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione

-quando il processo figlio non è terminato, e \macro{WUNTRACED} (usata per il
-controllo di sessione, trattato in \secref{sec:sess_job_control}) che fa
-ritornare la funzione anche per i processi figli che sono bloccati ed il cui
-stato non è stato ancora riportato al padre. Il valore dell'opzione deve
-essere specificato come maschera binaria ottenuta con l'OR delle suddette
-costanti con zero. In Linux sono previste altre opzioni non standard relative
-al comportamento con i thread, che saranno trattate in
-\secref{sec:thread_xxx}.
+quando il processo figlio non è terminato, e \macro{WUNTRACED}. Quest'ultimo
+viene generalmente usato per il controllo di sessione, (trattato in
+\secref{sec:sess_job_control}) in quanto permette di identificare i processi
+bloccati. La funzione infatti in tal caso ritorna, restituendone il \acr{pid},
+se c'è un processo figlio che è entrato in stato di sleep (vedi
+\tabref{tab:proc_proc_states}) di cui non si è ancora letto lo stato (con
+questa stessa opzione). Il valore dell'opzione deve essere specificato come
+maschera binaria ottenuta con l'OR delle suddette costanti con zero. In Linux
+sono previste altre opzioni non standard relative al comportamento con i
+thread, che saranno trattate in \secref{sec:thread_xxx}.

 
 La terminazione di un processo figlio è chiaramente un evento asincrono
 rispetto all'esecuzione di un programma e può avvenire in un qualunque
 
 La terminazione di un processo figlio è chiaramente un evento asincrono
 rispetto all'esecuzione di un programma e può avvenire in un qualunque


@@ -1186,7 +1188,7 @@ indicato dal parametro \var{path}, che viene interpretato come il
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=13cm]{img/exec_rel}
+  \includegraphics[width=15cm]{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}


@@ -1289,8 +1291,12 @@ problematiche connesse ad una gestione accorta dei privilegi.
 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
   realtà già esistono estensioni di questo modello base, che lo rendono più
   flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
   realtà già esistono estensioni di questo modello base, che lo rendono più
   flessibile e controllabile, come le \textit{capabilities}, le ACL per i file

-  o il \textit{Mandatory Access Control} di SELinux.} di sicurezza di un
-sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
+  o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul
+  lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
+  sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
+    Modules}, ol LSM, in grado di fornire diversi agganci a livello del kernel
+  per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
+un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla

 separazione fra l'amministratore (\textsl{root}, detto spesso anche
 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
 separazione fra l'amministratore (\textsl{root}, detto spesso anche
 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
 utenti, per i quali invece vengono effettuati i vari controlli di accesso.

diff --git a/session.tex b/session.tex
index 2f73d61b53bd790d8a3f0303dcf86eb926c7ac63..67e5129ad880b8598639bf6be5ac9be6a4a4fdfa 100644 (file)
--- a/session.tex
+++ b/session.tex
@@ -62,12 +62,12 @@ nella gestione del job control non si pu
 Per questo il kernel prevede la possibilità di raggruppare più processi in un
 \textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
 Per questo il kernel prevede la possibilità di raggruppare più processi in un
 \textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che

-originano da una riga di comando appartengano allo stesso \textit{process
-  group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
-terminale, possano fare riferimento ad esso.
+originano da una riga di comando appartengano allo stesso raggruppamento, in
+modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
+possano fare riferimento ad esso.

 
 

-In generale allora all'interno di una sessione avremo un eventuale (possono
-non esserci) \textit{process group} in \textit{foreground}, che riunisce i
+In generale allora all'interno di una sessione avremo un eventuale (può non
+esserci) \textit{process group} in \textit{foreground}, che riunisce i

 processi che possono accedere al terminale, e più \textit{process group} in
 \textit{background}, che non possono accedervi. Il job control prevede che
 quando un processo appartenente ad un raggruppamento in \textit{background}
 processi che possono accedere al terminale, e più \textit{process group} in
 \textit{background}, che non possono accedervi. Il job control prevede che
 quando un processo appartenente ad un raggruppamento in \textit{background}


@@ -78,15 +78,18 @@ Un comportamento analogo si ha anche per i segnali generati dai comandi di
 tastiera inviati dal terminale che vengono inviati a tutti i processi del
 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
 l'esecuzione del comando, che può poi essere mandato in \textit{background}
 tastiera inviati dal terminale che vengono inviati a tutti i processi del
 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
 l'esecuzione del comando, che può poi essere mandato in \textit{background}

-con il comando \cmd{bg}. Il comando \cmd{fg} consente invece di mettere in
-\textit{foreground} un comando precedentemente lanciato in
-\textit{background}.
+con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
+  sono parole chiave che indicano comandi interni alla shell, e nel caso non
+  comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
+consente invece di mettere in \textit{foreground} un comando precedentemente
+lanciato in \textit{background}.

 
 Di norma la shell si cura anche di notificare all'utente (di solito prima
 
 Di norma la shell si cura anche di notificare all'utente (di solito prima

-della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
-le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
-\secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
-e quali sono terminati. 
+della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
+in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
+sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
+l'opzione \macro{WUNTRACED}, secondo quanto illustrato in
+\secref{sec:proc_wait}).

 
 
 \subsection{I \textit{process group} e le \textsl{sessioni}}
 
 
 \subsection{I \textit{process group} e le \textsl{sessioni}}


@@ -158,16 +161,16 @@ stessa sessione del padre. Vedremo poi come sia possibile creare pi
 \textit{process group} all'interno della stessa sessione, e spostare i
 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
 
 \textit{process group} all'interno della stessa sessione, e spostare i
 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
 

-Ciascun gruppo di processi ha sempre un processo principale, il cosiddetto
-\textit{process group leader}, che è identificato dall'avere un \acr{pgid}
-uguale al suo \acr{pid}, in genere questo è il primo processo del gruppo, che
-si incarica di lanciare tutti gli altri. Un nuovo gruppo si crea con la
-funzione \func{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD
-  definisce una funzione con lo stesso nome, che però è identica a
-  \func{setpgid}; nelle \acr{glibc} viene sempre usata sempre questa
-  definizione, a meno di non richiedere esplicitamente la compatibilità
-  all'indietro con BSD, definendo la macro \macro{\_BSD\_SOURCE}.} il cui
-prototipo è:
+Ciascun raggruppamento di processi ha sempre un processo principale, il
+cosiddetto \textit{process group leader}, che è identificato dall'avere un
+\acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
+raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
+raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la
+  definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
+  però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
+  sempre questa definizione, a meno di non richiedere esplicitamente la
+  compatibilità all'indietro con BSD, definendo la macro
+  \macro{\_BSD\_SOURCE}.} il cui prototipo è:

 \begin{prototype}{unistd.h}{int setpgrp(void)}
   Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
   
 \begin{prototype}{unistd.h}{int setpgrp(void)}
   Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
   


@@ -176,10 +179,11 @@ prototipo 
 \end{prototype}
 
 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
 \end{prototype}
 
 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo

-corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i
-successivi processi da esso creati apparterranno (a meno di non cambiare di
-nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo
-da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è:
+corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
+i successivi processi da esso creati apparterranno (a meno di non cambiare di
+nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
+processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il
+cui prototipo è:

 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
   Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
   
 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
   Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
   


@@ -199,11 +203,12 @@ cambiamento pu
 \textit{process group} che è nella stessa sessione del processo chiamante.
 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
 \textit{process group} che è nella stessa sessione del processo chiamante.
 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha

-ancora eseguito una \func{exec}. Specificando un valore nullo per \param{pid}
-si indica il processo corrente, mentre specificando un valore nullo per
-\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
-processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
-  0)}.
+ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
+  dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
+  \var{task\_struct}.}  Specificando un valore nullo per \param{pid} si indica
+il processo corrente, mentre specificando un valore nullo per \param{pgid} si
+imposta il \textit{process group} al valore del \acr{pid} del processo
+selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}.

 
 Di norma questa funzione viene usata dalla shell quando si usano delle
 pipeline, per mettere nello stesso process group tutti i programmi lanciati su
 
 Di norma questa funzione viene usata dalla shell quando si usano delle
 pipeline, per mettere nello stesso process group tutti i programmi lanciati su


@@ -281,7 +286,7 @@ Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
 il precedente terminale di controllo viene cancellata, ed il processo che è
 divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
   è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è
 il precedente terminale di controllo viene cancellata, ed il processo che è
 divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
   è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è

-  sempre vera}, un terminale di controllo. In generale questo viene fatto
+  sempre vera.}, un terminale di controllo. In generale questo viene fatto

 automaticamente dal sistema\footnote{a meno di non avere richiesto
   esplicitamente che questo non diventi un terminale di controllo con il flag
   \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la
 automaticamente dal sistema\footnote{a meno di non avere richiesto
   esplicitamente che questo non diventi un terminale di controllo con il flag
   \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la


@@ -294,10 +299,10 @@ sessione.
 
 In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
 associato ai file standard (di input, output ed error) dei processi nella
 
 In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
 associato ai file standard (di input, output ed error) dei processi nella

-sessione, ma solo quelli che fanno parte del cosiddetto gruppo di
+sessione, ma solo quelli che fanno parte del cosiddetto ragruppamento di

 \textit{foreground}, possono leggere e scrivere in certo istante. Per
 \textit{foreground}, possono leggere e scrivere in certo istante. Per

-impostare il gruppo di \textit{foreground} di un terminale si usa la funzione
-\func{tcsetpgrp}, il cui prototipo è:
+impostare il raggruppamento di \textit{foreground} di un terminale si usa la
+funzione \func{tcsetpgrp}, il cui prototipo è:

 \begin{functions}
   \headdecl{unistd.h}
   \headdecl{termios.h}
 \begin{functions}
   \headdecl{unistd.h}
   \headdecl{termios.h}


@@ -322,13 +327,13 @@ impostare il gruppo di \textit{foreground} di un terminale si usa la funzione
 un processo nella stessa sessione e con lo stesso terminale di controllo. 
 
 Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e
 un processo nella stessa sessione e con lo stesso terminale di controllo. 
 
 Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e

-relativi gruppi) che non fanno parte del gruppo di \textit{foreground} sono
-detti in \textit{background}; se uno si essi cerca di accedere al terminale di
-controllo provocherà l'invio da parte del kernel di uno dei due segnali
-\macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato in
-lettura o scrittura) a tutto il suo \textit{process group}; dato che il
+relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
+sono detti in \textit{background}; se uno si essi cerca di accedere al
+terminale di controllo provocherà l'invio da parte del kernel di uno dei due
+segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato
+in lettura o scrittura) a tutto il suo \textit{process group}; dato che il

 comportamento di default di questi segnali (si riveda quanto esposto in
 comportamento di default di questi segnali (si riveda quanto esposto in

-\secref{sec:sig_job_control}) è di bloccare il processo, di norma questo
+\secref{sec:sig_job_control}) è di fermare il processo, di norma questo

 comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
 condizioni di errore.\footnote{la shell in genere notifica comunque un
   avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
 comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
 condizioni di errore.\footnote{la shell in genere notifica comunque un
   avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di


@@ -359,18 +364,18 @@ ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
 processo di accedere direttamente al suo terminale di controllo attraverso il
 file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
 proprio terminale di controllo.  Questo consente anche a processi che possono
 processo di accedere direttamente al suo terminale di controllo attraverso il
 file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
 proprio terminale di controllo.  Questo consente anche a processi che possono

-aver rediretto l'output di accedere al terminale, pur non disponendo più del
-file descriptor originario; un caso tipico è il programma \cmd{crypt} che
-accetta la redirezione sullo standard input di un file da decrittare, ma deve
-poi leggere la password dal terminale.
+aver rediretto l'output di accedere al terminale di controllo, pur non
+disponendo più del file descriptor originario; un caso tipico è il programma
+\cmd{crypt} che accetta la redirezione sullo standard input di un file da
+decrittare, ma deve poi leggere la password dal terminale.

 
 Un'altra caratteristica del terminale di controllo usata nel job control è che
 utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
 
 Un'altra caratteristica del terminale di controllo usata nel job control è che
 utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},

-\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà si che il kernel invii i
+\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i

 corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
 \macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a
 corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
 \macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a

-tutti i processi del gruppo di \textit{foreground}; in questo modo la shell
-può gestire il blocco e l'interruzione dei vari comandi.
+tutti i processi del raggruppamento di \textit{foreground}; in questo modo la
+shell può gestire il blocco e l'interruzione dei vari comandi.

  
 Per completare la trattazione delle caratteristiche del job control legate al
 terminale di controllo, occorre prendere in considerazione i vari casi legati
  
 Per completare la trattazione delle caratteristiche del job control legate al
 terminale di controllo, occorre prendere in considerazione i vari casi legati


@@ -391,10 +396,10 @@ riutilizzato per qualche altra sessione.
 Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
 ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
 potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
 Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
 ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
 potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un

-segnale di \macro{SIGHUP} ai processi del gruppo di foreground. In questo modo
-essi potranno essere avvisati che non esiste più un processo in grado di
-gestire il terminale (di norma tutto ciò comporta la terminazione anche di
-questi ultimi).
+segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In
+questo modo essi potranno essere avvisati che non esiste più un processo in
+grado di gestire il terminale (di norma tutto ciò comporta la terminazione
+anche di questi ultimi).

 
 Restano però gli eventuali processi in background, che non ricevono il
 segnale; in effetti se il terminale non dovesse più servire essi potrebbero
 
 Restano però gli eventuali processi in background, che non ricevono il
 segnale; in effetti se il terminale non dovesse più servire essi potrebbero


@@ -406,10 +411,11 @@ controllo dello stesso.
 Questa è la situazione in cui si ha quello che viene chiamato un
 \textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
 \textit{process group} i cui processi hanno come padri esclusivamente o altri
 Questa è la situazione in cui si ha quello che viene chiamato un
 \textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
 \textit{process group} i cui processi hanno come padri esclusivamente o altri

-processi nel gruppo, o processi fuori della sessione.  Lo standard prevede
-inoltre che se la terminazione di un processo fa sì che un raggruppamento di
-processi diventi orfano e se i suoi membri sono bloccati, ad essi vengano
-inviati in sequenza i segnali di \macro{SIGHUP} e \macro{SIGCONT}.
+processi nel raggruppamento, o processi fuori della sessione.  Lo standard
+prevede inoltre che se la terminazione di un processo fa sì che un
+raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
+essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e
+\macro{SIGCONT}.

 
 La definizione può sembrare complicata, e a prima vista non è chiaro cosa
 tutto ciò abbia a che fare con il problema della terminazione del processo di
 
 La definizione può sembrare complicata, e a prima vista non è chiaro cosa
 tutto ciò abbia a che fare con il problema della terminazione del processo di


@@ -422,21 +428,20 @@ non viene emesso nessun segnale perch
 solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
 processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
   uscita del processo, come una delle operazioni legate all'esecuzione di
 solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
 processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
   uscita del processo, come una delle operazioni legate all'esecuzione di

-  \func{_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
+  \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}

 
 

-Il leader di sessione provvederà a creare nuovi raggruppamenti di processi che
-a questo punto non sono orfani in quanto esso resta padre per almeno uno dei
-processi del gruppo (gli altri possono derivare dal primo). Alla terminazione
-del leader di sessione però avremo che, come visto in
+Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
+punto non sono orfani in quanto esso resta padre per almeno uno dei processi
+del gruppo (gli altri possono derivare dal primo). Alla terminazione del
+leader di sessione però avremo che, come visto in

 \secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
 \cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
 group creati direttamente dal leader di sessione (a meno di non aver spostato
 con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
 \secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
 \cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
 group creati direttamente dal leader di sessione (a meno di non aver spostato
 con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non

-viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali:
-\macro{SIGCONT} ne farà proseguire l'esecuzione, e, essendo stato nel
+viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
+\macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel

 frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
 frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per

-quest'ultimo, essi saranno terminati.
-
+quest'ultimo, i processi bloccati verranno automaticamente terminati.

 
 
 
 
 
 


@@ -547,27 +552,14 @@ salvati) saranno settati a quelli dell'utente.
 
 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
 
 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)

-ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
-ambiente già pronto e con file standard di \secref{sec:file_std_descr}
-impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
-che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
-ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
-per ripetere da capo tutto il procedimento.
-
-
-In generale quando con il contollo di sessione è la shell che assume il ruolo
-di processo di controllo, seleziona il gruppo di \textit{foregroud} e gestisce
-l'assegnazione dei process group ai programmi eseguiti sulla stessa riga di
-comando. 
-
-Qualora un processo venga bloccato nella gestione della sessione, sia
-implicitamente, perché cerca di eseguire dell'I/O sul terminale mentre è in
-background, sia esplicitamente con l'uso di \cmd{C-z}, la shell è in grado di
-rilevare l'evento grazie all'uso di \func{waitpid} con l'opzione
-\macro{WUNTRACED}. In questo modo la shell può notificare (di solito prima
-della stampa del prompt, lo stato dei vari processi. 
-
-
+ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
+già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
+terminale, e pronta, nel ruolo di leader di sessione e processo di controllo
+per il terminale, a gestire l'esecuzione dei comandi come illustrato in
+\secref{sec:sess_job_control_overview}. Dato che il processo padre resta
+sempre \cmd{init} quest'ultimo potrà provvedere, ricevendo un \macro{SIGCHLD}
+all'uscita della shell, a rilanciare \cmd{getty} sul terminale per ripetere da
+capo tutto il procedimento.

 
 
 
 
 
 


@@ -593,8 +585,11 @@ servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono
 \section{L'I/O su terminale}
 \label{sec:sess_terminal_io}
 
 \section{L'I/O su terminale}
 \label{sec:sess_terminal_io}
 

-Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo
-conto delle 
+Esamineremo in questa sezione le peculiarità dell'I/O eseguito sui terminali,
+tenendo conto delle differenze che quest'ultimi presentano rispetto ai normali
+file su disco.
+
+

 
 
 %%% Local Variables: 
 
 
 %%% Local Variables: