X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=569e06bed7c94ab4311b48e8b6ca85bcd26870a1;hp=9272a20e0bdb429978f21b24de0d56ca4cbbb6fd;hb=85a775d4f7a3dae1e72e449f2c05f03170a3295d;hpb=69542c2b97bf49839e1e4a19252e37b6d39235a2

diff --git a/prochand.tex b/prochand.tex
index 9272a20..569e06b 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -974,9 +974,10 @@ generato dalla terminazione di un figlio, avremo la certezza che la chiamata a
                              valutata solo se \val{WIFSIGNALED} ha restituito
                              un valore non nullo.\\ 
     \macro{WCOREDUMP(s)}   & Vera se il processo terminato ha generato un
-                             file di \textit{core dump}. Può essere valutata
-                             solo se \val{WIFSIGNALED} ha restituito un valore
-                             non nullo.\footnotemark \\ 
+                             file di \itindex{core~dump}\textit{core
+                               dump}. Può essere valutata solo se
+                             \val{WIFSIGNALED} ha restituito un valore non
+                             nullo.\footnotemark \\
     \macro{WIFSTOPPED(s)}  & Vera se il processo che ha causato il ritorno di
                              \func{waitpid} è bloccato. L'uso è possibile solo
                              avendo specificato l'opzione \const{WUNTRACED}. \\
@@ -995,15 +996,16 @@ generato dalla terminazione di un figlio, avremo la certezza che la chiamata a
     presente come estensione sia in Linux che in altri Unix.}
 
 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
-processo tramite il puntatore \param{status} (se non interessa memorizzare lo
-stato si può passare un puntatore nullo). Il valore restituito da entrambe le
-funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
-genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
-indicare il segnale che ha causato la terminazione (in caso di conclusione
-anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
-  definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
-  questo file non deve mai essere usato direttamente, esso viene incluso
-  attraverso \file{<sys/wait.h>}.}
+processo tramite il puntatore \param{status} (se non interessa memorizzare
+lo stato si può passare un puntatore nullo). Il valore restituito da
+entrambe le funzioni dipende dall'implementazione, e tradizionalmente alcuni
+bit (in genere 8) sono riservati per memorizzare lo stato di uscita, e altri
+per indicare il segnale che ha causato la terminazione (in caso di
+conclusione anomala), uno per indicare se è stato generato un
+\itindex{core~dump}\textit{core dump}, ecc.\footnote{le definizioni esatte
+  si possono trovare in \file{<bits/waitstatus.h>} ma questo file non deve
+  mai essere usato direttamente, esso viene incluso attraverso
+  \file{<sys/wait.h>}.}
 
 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
 analizzare lo stato di uscita. Esse sono definite sempre in
@@ -1305,13 +1307,14 @@ problematiche connesse ad una gestione accorta dei privilegi.
 
 Come accennato in sez.~\ref{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; 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}, o 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
+  flessibile e controllabile, come le
+  \itindex{capability}\textit{capabilities}, le ACL per i file 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}, o
+  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.
@@ -1856,10 +1859,10 @@ compila con il flag \cmd{-ansi}, 
 scrivere codice portabile.
 
 
-%\subsection{La gestione delle capabilities}
-%\label{sec:proc_capabilities}
-
+\subsection{La gestione delle capabilities}
+\label{sec:proc_capabilities}
 
+Da fare 
 
 
 \section{La gestione della priorità di esecuzione}
@@ -2184,7 +2187,7 @@ eseguito per primo quello con priorit
 processi con la stessa priorità assoluta questi vengono tenuti in una coda e
 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:
+scelta; lo standard ne prevede due:
 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\textit{FIFO}] \textit{First In First Out}. Il processo viene eseguito
   fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si