Risistemata flock, aggiunta figura sulla struttura del sistema

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index ef75e52dd8c52b2235666884701029c885a738a7..3f093759180ae0c364bfd34bbe6e39df922b76f5 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -109,9 +109,10 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda

-\secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
-comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
-base c'è \cmd{init} che è progenitore di tutti gli altri processi.
+\secref{sec:file_organization}); in \figref{fig:proc_tree} si è mostrato il
+risultato del comando \cmd{pstree} che permette di visualizzare questa
+struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
+processi.

 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
 \textit{process table}; per ciascun processo viene mantenuta una voce nella
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
 \textit{process table}; per ciascun processo viene mantenuta una voce nella


@@ -120,7 +121,7 @@ contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
 uno schema semplificato, che riporta la struttura delle principali informazioni
 contenute nella \type{task\_struct} (che in seguito incontreremo a più
 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
 uno schema semplificato, che riporta la struttura delle principali informazioni
 contenute nella \type{task\_struct} (che in seguito incontreremo a più

-riprese), è mostrato in \nfig.
+riprese), è mostrato in \figref{fig:proc_task_struct}.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -219,12 +220,14 @@ Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
 processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
 positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
 Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
 processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
 positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
 Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a

-partire da un minimo di 300,\footnote{questi valori sono definiti dalla macro
-  \macro{PID\_MAX} in \file{threads.h} e direttamente in \file{fork.c} nei
-  sorgenti del kernel.} che serve a riservare i \acr{pid} più bassi ai processi
-eseguiti dal direttamente dal kernel.  Per questo motivo, come visto in
-\secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
-\acr{pid} uguale a uno.
+partire da un minimo di 300,\footnote{questi valori, fino al kernel 2.4.x,
+  sono definiti dalla macro \macro{PID\_MAX} in \file{threads.h} e
+  direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia
+  per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei
+  \acr{pid} è stato modificato.} che serve a riservare i \acr{pid} più bassi
+ai processi eseguiti dal direttamente dal kernel.  Per questo motivo, come
+visto in \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha
+sempre il \acr{pid} uguale a uno.

 
 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 
 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da


@@ -689,13 +692,14 @@ eseguite alla chiusura di un processo 
   \cmd{init}).
 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
   \secref{sec:sig_sigchld}).
   \cmd{init}).
 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
   \secref{sec:sig_sigchld}).

-\item se il processo è un leader di sessione viene mandato un segnale di
-  \macro{SIGHUP} a tutti i processi in background e il terminale di
-  controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
+\item se il processo è un leader di sessione ed il suo terminale di controllo
+  è quello della sessione viene mandato un segnale di \macro{SIGHUP} a tutti i
+  processi del gruppo di foreground e il terminale di controllo viene
+  disconnesso (vedi \secref{sec:sess_ctrl_term}).

 \item se la conclusione di un processo rende orfano un \textit{process
     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
 \item se la conclusione di un processo rende orfano un \textit{process
     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}

-  (vedi \secref{sec:sess_ctrl_term}).
+  (vedi ancora \secref{sec:sess_ctrl_term}).

 \end{itemize*}
 
 Oltre queste operazioni è però necessario poter disporre di un meccanismo
 \end{itemize*}
 
 Oltre queste operazioni è però necessario poter disporre di un meccanismo


@@ -1121,10 +1125,11 @@ linea di comando e l'ambiente ricevuti dal nuovo processo.
 \end{functions}
 
 Per capire meglio le differenze fra le funzioni della famiglia si può fare
 \end{functions}
 
 Per capire meglio le differenze fra le funzioni della famiglia si può fare

-riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
-le modalità di passaggio dei parametri che poi andranno a costituire gli
-argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
-dalla funzione \func{main} del programma chiamato). 
+riferimento allo specchietto riportato in \tabref{tab:proc_exec_scheme}. La
+prima differenza riguarda le modalità di passaggio dei parametri che poi
+andranno a costituire gli argomenti a linea di comando (cioè i valori di
+\var{argv} e \var{argc} visti dalla funzione \func{main} del programma
+chiamato).

 
 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
 
 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso


@@ -1882,6 +1887,7 @@ sia la sua priorit
 fintanto che esso si trova in uno qualunque degli altri stati.
 
 \begin{table}[htb]
 fintanto che esso si trova in uno qualunque degli altri stati.
 
 \begin{table}[htb]

+  \footnotesize

   \centering
   \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
     \hline
   \centering
   \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
     \hline


@@ -2111,9 +2117,10 @@ priorit
 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si

-  siano installate le patch di RTLinux o RTAI, con i quali è possibile
+  siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile

   ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
   ottenere un sistema effettivamente hard real-time. In tal caso infatti gli

-  interrupt vengono intercettati dall'interfaccia real-time, e gestiti
+  interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
+  Adeos gestiti dalle code del nano-kernel), in modo da poterlo controllare

   direttamente qualora ci sia la necessità di avere un processo con priorità
   più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
 page fault\index{page fault} si possono avere ritardi non previsti. Se
   direttamente qualora ci sia la necessità di avere un processo con priorità
   più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
 page fault\index{page fault} si possono avere ritardi non previsti. Se


@@ -2137,17 +2144,16 @@ eseguito per primo quello con priorit
 processi con la stessa priorità assoluta questi vengono tenuti in una coda
 tocca al kernel decidere quale deve essere eseguito. 
 
 processi con la stessa priorità assoluta questi vengono tenuti in una coda
 tocca al kernel decidere quale deve essere eseguito. 
 

-
-

 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
 di scheduling che si è scelto; lo standard ne prevede due:
 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
 di scheduling che si è scelto; lo standard ne prevede due:

-\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
-\item[\textit{FIFO}] il processo viene eseguito fintanto che non cede
-  volontariamente la CPU, si blocca, finisce o viene interrotto da un processo
-  a priorità più alta.
-\item[\textit{Round Robin}] ciascun processo viene eseguito a turno per un
-  certo periodo di tempo (una \textit{time slice}). Solo i processi con la
-  stessa priorità ed in stato \textit{runnable} entrano nel circolo.
+\begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{FIFO}] \textit{First In First Out}. Il processo viene eseguito
+  fintanto che non cede volontariamente la CPU, si blocca, finisce o viene
+  interrotto da un processo a priorità più alta.
+\item[\textit{RR}] \textit{Round Robin}. Ciascun processo viene eseguito a
+  turno per un certo periodo di tempo (una \textit{time slice}). Solo i
+  processi con la stessa priorità ed in stato \textit{runnable} entrano nel
+  circolo.

 \end{basedescript}
 
 La funzione per impostare le politiche di scheduling (sia real-time che
 \end{basedescript}
 
 La funzione per impostare le politiche di scheduling (sia real-time che