Alcuni indici e materiale sulle ACL

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index 3522bbb2a2ae78f252a3516711b28ff3d41885ff..76bd1bc1979e66f4a99d8b6f16640a59c36fdfc4 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -218,7 +218,6 @@ prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
 non ritorna mai (in quanto con essa viene eseguito un altro programma).
 
 
-
 \section{Le funzioni di base}% della gestione dei processi}
 \label{sec:proc_handling}
 
@@ -250,10 +249,12 @@ basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
   al kernel 2.4.x, sono definiti dalla macro \const{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 direttamente dal kernel.  Per questo
-motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di avvio
-(\cmd{init}) ha sempre il \acr{pid} uguale a uno.
+  allocazione dei \acr{pid} è stato modificato; il valore massimo è
+  impostabile attraverso il file \procfile{/proc/sys/kernel/pid\_max} e di
+  default vale 32768.} che serve a riservare i \acr{pid} più bassi ai processi
+eseguiti direttamente dal kernel.  Per questo motivo, come visto in
+sez.~\ref{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
@@ -477,9 +478,9 @@ rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
 
 In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
 \textit{scheduler} di Ingo Molnar esegue sempre per primo il
-figlio;\footnote{i risultati precedenti sono stati ottenuti su un kernel della
-  serie 2.4.}  questa è una ottimizzazione che serve a evitare che il padre,
-effettuando per primo una operazione di scrittura in memoria, attivi il
+figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
+  della serie 2.4.}  questa è una ottimizzazione che serve a evitare che il
+padre, effettuando per primo una operazione di scrittura in memoria, attivi il
 meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
 operazione infatti potrebbe risultare del tutto inutile qualora il figlio
 fosse stato creato solo per eseguire una \func{exec}, in tal caso infatti si
@@ -489,7 +490,7 @@ indirizzi, rendendo superflua la copia della memoria modificata dal padre.
 Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
 avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
 viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4, per mantenere la portabilità è però
+allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
 opportuno non fare affidamento su questo comportamento, che non si riscontra
 in altri Unix e nelle versioni del kernel precendenti a quella indicata.
 
@@ -1441,7 +1442,7 @@ la lista completa 
 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
 \item la directory radice e la directory di lavoro corrente (vedi
   sez.~\ref{sec:file_work_dir});
-\item la maschera di creazione dei file (\var{umask}, vedi
+\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
   sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
   sez.~\ref{sec:file_locking});
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
@@ -2134,6 +2135,9 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.23;
   come LIDS (vedi \href{http://www.lids.org}{\textsf{http://www.lids.org/})}
   che realizzano qualcosa di simile.}
 
+% TODO verificare per process capability bounding set, vedi:
+%  http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+
 
 \begin{table}[!h!bt]
   \centering
@@ -2786,6 +2790,8 @@ funzione.
 % TODO documentare prctl ...
  
 
+% TODO: rivedere alla luce degli aggiornamenti del 2.6 (man sched_setscheduler)
+
 \section{La gestione della priorità di esecuzione}
 \label{sec:proc_priority}
 
@@ -2874,6 +2880,8 @@ fintanto che esso si trova in uno qualunque degli altri stati.
   \label{tab:proc_proc_states}
 \end{table}
 
+% TODO nel 2.6.25 è stato aggiunto TASK_KILLABLE, da capire dova va messo.
+
 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
 dello scopo del programma non è detto neanche che sia la più importante (molti
@@ -3168,6 +3176,8 @@ assolute diverse da zero o politiche \const{SCHED\_FIFO} e \const{SCHED\_RR}.
     \const{SCHED\_RR}   & Scheduling real-time con politica \textit{Round
       Robin}. \\
     \const{SCHED\_OTHER}& Scheduling ordinario.\\
+    \const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di
+    lavoro \textit{CPU intensive}.\footnotemark\\
     \hline
   \end{tabular}
   \caption{Valori dell'argomento \param{policy} per la funzione
@@ -3175,6 +3185,8 @@ assolute diverse da zero o politiche \const{SCHED\_FIFO} e \const{SCHED\_RR}.
   \label{tab:proc_sched_policy}
 \end{table}
 
+\footnotetext{introdotto con il kernel 2.6.16.}
+
 Il valore della priorità è passato attraverso la struttura
 \struct{sched\_param} (riportata in fig.~\ref{fig:sig_sched_param}), il cui
 solo campo attualmente definito è \var{sched\_priority}, che nel caso delle