Correzioni varie
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 12 Nov 2001 18:33:40 +0000 (18:33 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 12 Nov 2001 18:33:40 +0000 (18:33 +0000)
errors.tex
filedir.tex
fileintro.tex
img/port_alloc.dia
intro.tex
process.tex
prochand.tex
signal.tex
system.tex

index 751647e..5f7958d 100644 (file)
@@ -88,7 +88,7 @@ gestione dei file.
 \item \macro{EROFS} \textit{Read-only file system}.  il file risiede su un filesystem read-only.
 \item \macro{EMLINK} \textit{Too many links}. Ci sono troppi link al file (il
    numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
-  \secref{sec:xxx_limits}).
+  \secref{sec:sys_limits}).
 \item \macro{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
   leggendo l'altro capo della pipe. Ogni funzione che restituisce questo
   errore genera anche un segnale \macro{SIGPIPE}, la cui azione di default è
index 7627aaf..be2d5c6 100644 (file)
@@ -69,7 +69,7 @@ principali, come risultano dalla man page, sono le seguenti:
     già.
   \item \macro{EMLINK} ci sono troppi link al file \var{oldpath} (il
     numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
-    \secref{sec:xxx_limits}).
+    \secref{sec:sys_limits}).
   \end{errlist}
   ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOTDIR},
   \macro{EFAULT}, \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP},
@@ -574,7 +574,7 @@ Di questa funzione esiste una versione \func{char * getwd(char * buffer)}
 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi
-\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
+\secref{sec:sys_limits}); il problema è che in Linux non esiste una dimensione
 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
 contenere il nome del file, e questa è la ragione principale per cui questa
 funzione è deprecata.
index 78c63b5..6d9fec8 100644 (file)
@@ -220,7 +220,7 @@ operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
 usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
 devono essere usati i file descriptor se si vuole ricorrere a modalità
 speciali di I/O come il polling o il non-bloccante (vedi
-\secref{sec:file_xxx}).
+\secref{sec:file_noblocking}).
 
 Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
 dei file descriptor, che tratta tutti i file nello stesso modo, con
index 2acd1b2..a9ae7ae 100644 (file)
Binary files a/img/port_alloc.dia and b/img/port_alloc.dia differ
index 43efa10..39cf4c8 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -67,7 +67,7 @@ eccedenza.
 Le periferiche infine vengono viste in genere attraverso un'interfaccia
 astratta che permette di trattarle come fossero file, secondo il concetto per
 cui \textit{everything is a file}, su cui torneremo in dettaglio in
-\capref{cha:files_intro}, (questo non è vero per le interfacce di rete, che
+\capref{cha:file_intro}, (questo non è vero per le interfacce di rete, che
 hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
 il lavoro di accesso e gestione a basso livello è effettuato dal kernel).
 
index d83d5fb..3c1b49d 100644 (file)
@@ -523,7 +523,7 @@ particolare:
 \begin{itemize*}
 \item se la variabile è posta a zero gli errori vengono ignorati.
 \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
-  (vedi \secref{sec:file_stdfiles}).
+  (vedi \secref{sec:file_std_stream}).
 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
   l'immediata conclusione del programma.
 \end{itemize*}
index 699b040..f5decd7 100644 (file)
@@ -210,7 +210,7 @@ Tutti i processi figli dello stesso processo padre sono detti
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
-\secref{cap:session}, dove esamineremo gli altri identificativi associati ad
+\secref{cha:session}, dove esamineremo gli altri identificativi associati ad
 un processo e le varie relazioni fra processi utilizzate per definire una
 sessione.
 
@@ -219,7 +219,7 @@ sessione, ad ogni processo sono associati altri identificatori, usati per il
 controllo di accesso, che servono per determinare se il processo può o meno
 eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di
 chi lo ha posto in esecuzione; su questi torneremo in dettagli più avanti in
-\secref{sec:proc_perm}.
+\secref{sec:proc_perms}.
 
 
 \subsection{La funzione \func{fork}}
@@ -1164,24 +1164,24 @@ la lista completa 
   \secref{sec:file_work_dir}).
 \item la maschera di creazione dei file (\var{umask}, vedi
   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
-  \secref{sec:file_xxx}).
+  \secref{sec:file_locking}).
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   \secref{sec:sig_xxx}).
-\item i limiti sulle risorse (vedi \secref{sec:limits_xxx})..
+\item i limiti sulle risorse (vedi \secref{sec:sys_limits})..
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
-  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
+  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
 \end{itemize*}
 
 Oltre a questo i segnali che sono stati settati per essere ignorati nel
-processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
-gli altri segnali vengono settati alla loro azione di default. Un caso
-speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+processo chiamante mantengono lo stesso settaggio pure nel nuovo programma,
+tutti gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN},
 può anche non essere resettato a \macro{SIG\_DFL} (si veda
 \secref{sec:sig_xxx}).
 
 La gestione dei file aperti dipende dal valore del flag di
 \textit{close-on-exec} per ciascun file descriptor (si veda
-\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli
 altri file restano aperti. Questo significa che il comportamento di default è
 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
 esplicita a \func{fcntl} che setti il suddetto flag.
@@ -1682,7 +1682,7 @@ cui non erano ancora state completate.
 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
-\capref{cha:ipc}) o nella operazioni con i file (vedremo alcuni esempi in
+\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
 funzioni di libreria per compiere le operazioni necessarie è garanzia
 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
index f7e8bc5..239544c 100644 (file)
@@ -29,8 +29,8 @@ segnale sono vari; un breve elenco di possibile cause 
 \item una richiesta dell'utente di terminare o fermare il programma. In genere
   si realizza attraverso un segnale mandato dalla shell in corrispondenza
   della pressione di tasti del terminale come 'ctrl-c' o 'ctrl-z'.
-\item l'esecuzione di una \texttt{kill} o di una \texttt{raise} da parte del
-  processo stesso o di un'altro (solo nel caso della \texttt{kill}).
+\item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
+  processo stesso o di un'altro (solo nel caso della \func{kill}).
 \end{itemize}
 
 Ciascuno di questi eventi (tranne gli ultimi due che sono controllati
@@ -181,7 +181,7 @@ esempi di segnali di questo tipo sono quelli legati all'arrivo di dati di
 input, scadenze di un timer, terminazione di processi figli.
 
 Una richiesta esplicita significa l'uso di una chiamata di sistema (come
-\texttt{kill} o \texttt{raise}) per la generazione di un segnale, cosa che
+\func{kill} o \func{raise}) per la generazione di un segnale, cosa che
 viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
 di stop o di suspend, ma può essere pure inserita all'interno di un programma.
 
@@ -219,7 +219,7 @@ volta per
 
 Una volta che il segnale viene notificato (che questo avvenga subito o dopo
 una attesa più o meno lunga) viene eseguita l'azione specificata per detto
-segnale. Per alcuni segnali (\texttt{SIGKILL} e \texttt{SIGSTOP}) questa azione
+segnale. Per alcuni segnali (\macro{SIGKILL} e \macro{SIGSTOP}) questa azione
 è fissa e non può essere cambiata, ma per tutti gli altri il programma può
 specificare una scelta fra le tre seguenti:
 
@@ -231,7 +231,7 @@ specificare una scelta fra le tre seguenti:
 \end{itemize}
 
 Il programma può specificare queste scelte usano le due routine
-\texttt{signal} e \texttt{sigaction}; se si è installato un manipolatore sarà
+\func{signal} e \func{sigaction}; se si è installato un manipolatore sarà
 quest'ultimo a intercettare il segnale ed ad essere eseguito, e mentre viene
 eseguito (onde evitare race conditions) il segnale viene bloccato.
 
@@ -249,7 +249,7 @@ l'azione standard 
 
 Quando un segnale termina un processo, il padre può determinare la causa della
 terminazione esaminando il codice di stato riportato delle funzioni
-\texttt{wait} e \texttt{waitpid} in cui è riportato anche se la causa è un
+\func{wait} e \func{waitpid} in cui è riportato anche se la causa è un
 segnale e nel caso quale; questo è il modo in cui la shell determina i motivi
 della terminazione di un programma e scrive un eventuale messaggio di errore.
 
@@ -258,7 +258,7 @@ violazioni di accesso) hanno anche la caratteristica di scrivere un file
 \textit{core dump} che registra lo stato del processo prima della terminazione
 e può essere esaminato da un debugger per investigare sulla causa dell'errore.
 Lo stesso avviene se i suddetti segnale vengono generati artificialmente con
-una \texttt{kill}.
+una \func{kill}.
 
 
 
@@ -274,7 +274,7 @@ Per questo ad ogni tipo di segnale viene associato un nome, che corrisponde,
 tramite una macro di preprocessore, al suddetto numero. Sono questi nomi, che
 sono standardizzati e uniformi rispetto alle varie implementazioni, che si
 devono usare nei programmi. Tutti i nomi e le funzioni che concernono i
-segnali sono definiti nell'header di sistema \texttt{signal.h}.
+segnali sono definiti nell'header di sistema \file{signal.h}.
 
 Il numero totale di segnali presenti è dato dalla macro \macro{NSIG}, e dato
 che i numeri dei segnali sono allocati progressivamente, essa corrisponde
index 7a44a35..2ca86bf 100644 (file)
@@ -29,7 +29,7 @@ per i tempi all'interno del sistema, essi sono rispettivamente chiamati
   operazione del timer, e corrisponde dunque al numero di tick al secondo.  Lo
   standard POSIX definisce allo stesso modo la costante \macro{CLK\_TCK});
   questo valore può comunque essere ottenuto con \func{sysconf} (vedi
-  \secref{sec:intro_limits}).
+  \secref{sec:sys_limits}).
 \end{itemize}
 
 In genere si usa il \textit{calendar time} per tenere le date dei file e le
@@ -148,7 +148,7 @@ globale\footnote{anche questa 
 attualmente in esecuzione.
 
 Una seconda funzione usata per riportare i codici di errore in maniera
-automatizzata sullo standard error (vedi \secref{sec:file_stdfiles}) è
+automatizzata sullo standard error (vedi \secref{sec:file_std_descr}) è
 \func{perror}, il cui prototipo è:
 \begin{prototype}{stdio.h}{void perror (const char *message)} 
   La funzione stampa il messaggio di errore relativo al valore corrente di