From: Simone Piccardi Date: Mon, 12 Nov 2001 18:33:40 +0000 (+0000) Subject: Correzioni varie X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=b6d559b9429afcc0d64137913e8f16d49857a6c9;p=gapil.git Correzioni varie --- diff --git a/errors.tex b/errors.tex index 751647e..5f7958d 100644 --- a/errors.tex +++ b/errors.tex @@ -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 è diff --git a/filedir.tex b/filedir.tex index 7627aaf..be2d5c6 100644 --- a/filedir.tex +++ b/filedir.tex @@ -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. diff --git a/fileintro.tex b/fileintro.tex index 78c63b5..6d9fec8 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -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 diff --git a/img/port_alloc.dia b/img/port_alloc.dia index 2acd1b2..a9ae7ae 100644 Binary files a/img/port_alloc.dia and b/img/port_alloc.dia differ diff --git a/intro.tex b/intro.tex index 43efa10..39cf4c8 100644 --- 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). diff --git a/process.tex b/process.tex index d83d5fb..3c1b49d 100644 --- a/process.tex +++ b/process.tex @@ -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*} diff --git a/prochand.tex b/prochand.tex index 699b040..f5decd7 100644 --- a/prochand.tex +++ b/prochand.tex @@ -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 diff --git a/signal.tex b/signal.tex index f7e8bc5..239544c 100644 --- a/signal.tex +++ b/signal.tex @@ -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 diff --git a/system.tex b/system.tex index 7a44a35..2ca86bf 100644 --- a/system.tex +++ b/system.tex @@ -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