X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=48af070bd1e6a7980b68b773fb3737c5ddfbd424;hp=5432fa6bc42e28db2b3fa07798acf295c062d960;hb=3f0b7dc79bb38d391505385754c9e3c222b6c86d;hpb=813faeabc683ae5e07061dea550d48af557ca406

diff --git a/prochand.tex b/prochand.tex
index 5432fa6..48af070 100644
--- 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
-\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
@@ -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ù
-riprese), è mostrato in \nfig.
+riprese), è mostrato in \figref{fig:proc_task_struct}.
 
 \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
-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
@@ -1122,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
-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
@@ -1488,10 +1492,10 @@ all'\textsl{userid salvato}. Negli altri casi viene segnalato un errore (con
 \macro{EPERM}).
 
 Come accennato l'uso principale di queste funzioni è quello di poter
-consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati di
-riportare l'\textsl{userid effettivo} a quello dell'utente che ha lanciato il
-programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
-eventualmente tornare indietro.
+consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
+\secref{sec:file_suid_sgid}) di riportare l'\textsl{userid effettivo} a quello
+dell'utente che ha lanciato il programma, effettuare il lavoro che non
+necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
 
 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
@@ -1883,6 +1887,7 @@ sia la sua priorit
 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
@@ -2112,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
-  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
-  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
@@ -2138,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. 
 
-
-
 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