Correzioni parte seconda. Tolto un pezzo duplicato

diff --git a/fileintro.tex b/fileintro.tex
index 927dc4da827076a43c36d233593b5aa7e2d8d5cd..010add3be64c39094d05bed03863814924d91641 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -22,7 +22,7 @@ delle modalit
 
 
 
 
 
 

-\section{L'architettura dell'accesso}
+\section{L'architettura generale}

 \label{sec:file_access_arch}
 
 Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
 \label{sec:file_access_arch}
 
 Per poter accedere ai file il kernel deve mettere a disposizione dei programmi


@@ -30,8 +30,9 @@ le opportune interfacce che consentano di leggerne il contenuto; il sistema
 cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
 l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
 fatto strutturando l'informazione sul disco attraverso quello che si chiama un
 cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
 l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
 fatto strutturando l'informazione sul disco attraverso quello che si chiama un

-\textit{filesystem}, essa poi viene resa disponibile ai processi attraverso
-quello che viene chiamato il \textsl{montaggio} del filesystem.
+\textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa
+disponibile ai processi attraverso quello che viene chiamato il
+\textsl{montaggio} del \textit{filesystem}.

 % (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
 
 In questa sezione faremo una panormamica generica su come il sistema presenta
 % (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
 
 In questa sezione faremo una panormamica generica su come il sistema presenta


@@ -52,15 +53,15 @@ viene identificato dall'utente usando quello che viene chiamato
   ricerca (come quello in cui si cercano i comandi) non seguiremo questa
   scelta dato che l'uso della parola \textit{pathname} è ormai così comune che
   mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè
   ricerca (come quello in cui si cercano i comandi) non seguiremo questa
   scelta dato che l'uso della parola \textit{pathname} è ormai così comune che
   mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè

-il percorso che si deve fare per accedere al file, che è composto da una serie
-di nomi separati da una \file{/}.
+il percorso che si deve fare per accedere al file a partire dalla \textit{root
+  directory}, che è composto da una serie di nomi separati da una \file{/}.

 
 

-Dopo la fase di inizializzazione il kernel riceve dal boot loader
-l'indicazione di quale dispositivo contiene il filesystem da usare come punto
-di partenza e questo viene montato come radice dell'albero (cioè nella
-directory \file{/}); tutti gli ulteriori filesystem che possono essere su
-altri dispositivi devono poi essere inseriti nell'albero montandoli su
-opportune directory del filesystem montato come radice.
+All'avvio del sistema, comletata la fase di inizializzazione il kernel riceve
+dal boot loader l'indicazione di quale dispositivo contiene il filesystem da
+usare come punto di partenza e questo viene montato come radice dell'albero
+(cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono
+essere su altri dispositivi dovranno poi essere inseriti nell'albero
+montandoli su opportune directory del filesystem montato come radice.

 
 Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
 alcune strutture interne del kernel) sono generati automaticamente dal kernel
 
 Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
 alcune strutture interne del kernel) sono generati automaticamente dal kernel


@@ -87,7 +88,7 @@ Il nome completo di un file viene chiamato \textit{pathname} ed il
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 risoluzione del nome (\textit{file name resolution} o \textit{pathname
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 risoluzione del nome (\textit{file name resolution} o \textit{pathname
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da

-destra a sinistra e localizzando ogni nome nella directory indicata dal nome
+sinistra a destra e localizzando ogni nome nella directory indicata dal nome

 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
   costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
 perché il procedimento funzioni occorre che i nomi indicati come directory
 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
   costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
 perché il procedimento funzioni occorre che i nomi indicati come directory


@@ -113,7 +114,7 @@ questa sia la directory radice allora il riferimento 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 

-Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
+Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi

 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal


@@ -142,10 +143,10 @@ dati) in base al loro contenuto, o tipo di accesso.
       un file che identifica una periferica ad accesso sequenziale \\
       \textit{block device} & \textsl{dispositivo a blocchi} &
       un file che identifica una periferica ad accesso diretto \\
       un file che identifica una periferica ad accesso sequenziale \\
       \textit{block device} & \textsl{dispositivo a blocchi} &
       un file che identifica una periferica ad accesso diretto \\

-      \textit{fifo} & \textsl{tubo} &
+      \textit{fifo} & \textsl{``tubo''} &

       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\
       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\

-      \textit{socket} & \textsl{manicotto} &
+      \textit{socket} & \textsl{``spina''} &

       un file speciale che identifica una linea di comunicazione software
       (bidirezionale) \\
     \hline
       un file speciale che identifica una linea di comunicazione software
       (bidirezionale) \\
     \hline


@@ -171,18 +172,26 @@ riga 
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 

+Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
+dati e che non c'è nessun supporto del sistema per le estensioni come parte
+del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
+i nomi dei file, ad esempio il codice C normalmente si mette in file con
+l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
+
+

 
 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 
 
 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 

-In unix le modalità di accesso ai file e le relative interfacce di
+In Linux le modalità di accesso ai file e le relative interfacce di

 programmazione sono due, basate su due diversi meccanismi con cui è possibile
 accedere al loro contenuto.
 
 programmazione sono due, basate su due diversi meccanismi con cui è possibile
 accedere al loro contenuto.
 

-La prima è l'interfaccia standard di unix, quella che il manuale delle
+La prima è l'interfaccia standard di Unix, quella che il manuale delle

 \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
 \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file

-  descriptor}).  È un'interfaccia specifica di unix e provvede un accesso non
-bufferizzato, la tratteremo in dettaglio in \capref{cha:file_unix_interface}.
+  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e provvede
+un accesso non bufferizzato; la tratteremo in dettaglio in
+\capref{cha:file_unix_interface}.

 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando


@@ -194,8 +203,8 @@ L'interfaccia 
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 \textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 \textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso

-bufferizzato (controllato dalla implementazione fatta dalle librerie del C),
-la tratteremo in dettaglio in \capref{cha:files_std_interface}.
+bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
+tratteremo in dettaglio nel \capref{cha:files_std_interface}.

 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi


@@ -205,22 +214,21 @@ tipo \type{FILE *}.  L'interfaccia 
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio

-a tempo opportuno), ma per poter accedere alle operazioni di controllo sul
-particolare tipo di oggetto del VFS scelto occorre usare l'interfaccia
-standard di Unix coi \textit{file descriptor}. Allo stesso modo devono essere
-usati i \textit{file descriptor} se si vuole ricorrere a modalità speciali di
-I/O come il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
+a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
+qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
+coi \textit{file descriptor}. Allo stesso modo devono essere usati i
+\textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
+il polling o il non-bloccante (vedi \capref{cha:file_advanced}).

 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra

-quella dei \textit{file descriptor}, che tratta tutti i file nello stesso
-modo, con l'eccezione di poter scegliere tra diversi stili di bufferizzazione.
-Il maggior vantaggio degli \textit{stream} è che l'interfaccia per le
-operazioni di input/output è enormemente più ricca di quella dei \textit{file
-  descriptor}, che provvedono solo funzioni elementari per la
-lettura/scrittura diretta di blocchi di byte.  In particolare gli
-\textit{stream} dispongono di tutte le funzioni di formattazione per l'input e
-l'output adatte per manipolare anche i dati in forma di linee o singoli
-caratteri.
+quella dei \textit{file descriptor}, che permette di poter scegliere tra
+diversi stili di bufferizzazione.  Il maggior vantaggio degli \textit{stream}
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+di quella dei \textit{file descriptor}, che provvedono solo funzioni
+elementari per la lettura/scrittura diretta di blocchi di byte.  In
+particolare gli \textit{stream} dispongono di tutte le funzioni di
+formattazione per l'input e l'output adatte per manipolare anche i dati in
+forma di linee o singoli caratteri.

 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
 standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
 standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da


@@ -229,66 +237,60 @@ tempo uno \textit{stream} ad un \textit{file descriptor}.
 
 In generale, se non necessitano specificatamente le funzionalità di basso
 livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
 
 In generale, se non necessitano specificatamente le funzionalità di basso
 livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore

-portabilità essendo questi ultimi definiti nello standard ANSI C;
-l'interfaccia con i \textit{file descriptor} invece segue solo lo standard
-POSIX.1 dei sistemi unix ed è pertanto di portabilità più limitata.
-
-
-\subsection{Caratteristiche specifiche dei file in Unix}
-\label{sec:fileint_unix_spec}
-
-Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-specifiche di un sistema unix-like che devono essere tenute in conto
-nell'accesso ai file. È infatti normale che più processi o programmi possano
-accedere contemporaneamente allo stesso file e devono poter eseguire le loro
-operazioni indipendentemente da quello che fanno gli altri processi.
-
-Per questo motivo le strutture usate per all'accesso ai file sono relative al
-processo che effettua l'accesso.  All'apertura di ogni file infatti viene
-creata all'interno del processo una apposita struttura in cui sono memorizzati
-tutti gli attributi del medesimo, che viene utilizzata per tutte le
-operazioni. Questa è una struttura che resta locale al processo stesso; in
-questo modo processi diversi possono usare le proprie strutture locali per
-accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
-indipendente.
-
-Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
-sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
-file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
-successiva. Essa è rappresentata da un numero intero che indica il numero di
-byte dall'inizio del file, che viene (a meno che non si apra il file in
-append) inizializzato a zero all'apertura del medesimo.
-
-Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
-ogni processo avrà la sua posizione corrente nel file, che non sarà
-influenzata da quello che altri processi possono fare. Anzi, aprire un file
-significa appunto creare ed inizializzare una tale struttura, per cui se si
-apre due volte lo stesso file all'interno dello stesso processo, si otterranno
-due file descriptor o due stream che avranno ancora una posizione corrente nel
-file assolutamente indipendente.
-
-Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
-accesso è un riferimento all'inode del file, pertanto anche se il file viene
-cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
-dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
-cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
-file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
-saranno disponibili per tutto il tempo in cui il processo è attivo.
-
-Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
-l'input/output sui file, esaminando in dettaglio come tutto ciò viene
-realizzato.
-
-Si ricordi infine che in ambiente unix non esistono i tipi di file e che non
-c'è nessun supporto per le estensioni come parte del filesystem. Ciò non
-ostante molti programmi adottano delle convenzioni per i nomi dei file, ad
-esempio il codice C normalmente si mette in file con l'estensione .c, ma
-questa è, appunto, solo una convenzione.
-
-
-\section{L'architettura di funzionamento}
+portabilità, essendo questi ultimi definiti nello standard ANSI C;
+l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
+POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
+
+
+% \subsection{Caratteristiche specifiche dei file in Unix}
+% \label{sec:fileint_unix_spec}
+
+% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
+% specifiche di un sistema unix-like che devono essere tenute in conto
+% nell'accesso ai file. È infatti normale che più processi o programmi possano
+% accedere contemporaneamente allo stesso file e devono poter eseguire le loro
+% operazioni indipendentemente da quello che fanno gli altri processi.
+
+% Per questo motivo le strutture usate per all'accesso ai file sono relative al
+% processo che effettua l'accesso.  All'apertura di ogni file infatti viene
+% creata all'interno del processo una apposita struttura in cui sono memorizzati
+% tutti gli attributi del medesimo, che viene utilizzata per tutte le
+% operazioni. Questa è una struttura che resta locale al processo stesso; in
+% questo modo processi diversi possono usare le proprie strutture locali per
+% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
+% indipendente.
+
+% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
+% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
+% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
+% successiva. Essa è rappresentata da un numero intero che indica il numero di
+% byte dall'inizio del file, che viene (a meno che non si apra il file in
+% append) inizializzato a zero all'apertura del medesimo.
+
+% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
+% ogni processo avrà la sua posizione corrente nel file, che non sarà
+% influenzata da quello che altri processi possono fare. Anzi, aprire un file
+% significa appunto creare ed inizializzare una tale struttura, per cui se si
+% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
+% due file descriptor o due stream che avranno ancora una posizione corrente nel
+% file assolutamente indipendente.
+
+% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
+% accesso è un riferimento all'inode del file, pertanto anche se il file viene
+% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
+% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
+% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+% in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
+% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+% saranno disponibili per tutto il tempo in cui il processo è attivo.
+
+% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
+% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
+% realizzato.
+
+
+\section{L'architettura della gestione dei file}

 \label{sec:file_arch_func}
 
 Per capire fino in fondo le proprietà di file e directory in un sistema
 \label{sec:file_arch_func}
 
 Per capire fino in fondo le proprietà di file e directory in un sistema

diff --git a/prochand.tex b/prochand.tex
index 173c0bed7e7d585913bacce51ee78a8742d1f6ff..4eb3d74603609dbed04093089a5cf81e3d6bd93d 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -991,13 +991,13 @@ le apposite funzioni trattate in \secref{sec:sig_strsignal}.
 \subsection{Le funzioni \func{wait3} e \func{wait4}}
 \label{sec:proc_wait4}
 
 \subsection{Le funzioni \func{wait3} e \func{wait4}}
 \label{sec:proc_wait4}
 

-Linux, seguendo una estensione di BSD, supporta altre due funzioni,
-\func{wait} e \func{waitpd}, per la lettura dello stato di terminazione di un
-processo, analoghe alle precedenti ma che prevedono un ulteriore parametro
-attraverso il quale il kernel può restituire al padre informazioni sulle
-risorse usate dal processo terminato e dai vari figli.  I prototipi di queste
-funzioni, che diventano accessibili definendo la costante \macro{\_USE\_BSD},
-sono:
+Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
+lettura dello stato di terminazione di un processo \func{wait3} e
+\func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
+parametro attraverso il quale il kernel può restituire al padre informazioni
+sulle risorse usate dal processo terminato e dai vari figli.  I prototipi di
+queste funzioni, che diventano accessibili definendo la costante
+\macro{\_USE\_BSD}, sono:

 \begin{functions}
   \headdecl{sys/times.h} 
   \headdecl{sys/types.h} 
 \begin{functions}
   \headdecl{sys/times.h} 
   \headdecl{sys/types.h} 


@@ -1052,8 +1052,9 @@ famiglia di funzioni) che possono essere usate per questo compito, in realt
   \begin{errlist}
   \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
     montato in \cmd{noexec}, oppure non è un file normale o un interprete.
   \begin{errlist}
   \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
     montato in \cmd{noexec}, oppure non è un file normale o un interprete.

-  \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non
-    è root o il filesystem è montato con \cmd{nosuid}, oppure
+  \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
+    è root, e o il processo viene tracciato, o il filesystem è montato con
+    l'opzione \cmd{nosuid}.

   \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
     riconosciuto come tale, o compilato per un'altra architettura.
   \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
   \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
     riconosciuto come tale, o compilato per un'altra architettura.
   \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete


@@ -1211,12 +1212,12 @@ speciale 
 può anche non essere resettato a \macro{SIG\_DFL} (si veda
 \secref{sec:sig_xxx}).
 
 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_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.
+La gestione dei file aperti dipende dal valore che ha il flag di
+\textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
+descriptor. 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.

 
 Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
 attraverso una \func{exec}, in genere questo è fatto dalla funzione
 
 Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
 attraverso una \func{exec}, in genere questo è fatto dalla funzione


@@ -1226,9 +1227,9 @@ maniera trasparente all'utente.
 
 Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
 
 Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per

-l'\textit{effective user id} ed l'\textit{effective group id}, tranne il caso
-in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid}
-bit settato, nel qual caso \textit{effective user id} e \textit{effective
+l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
+il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
+settato, in questo caso l'\textit{effective user id} e l'\textit{effective

   group id} vengono settati rispettivamente all'utente o al gruppo cui il file
 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
 
   group id} vengono settati rispettivamente all'utente o al gruppo cui il file
 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
 


@@ -1260,8 +1261,8 @@ parametri connessi ai processi.
 In questa sezione esamineremo le problematiche relative al controllo di
 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
 usati, come questi possono essere modificati nella creazione e nel lancio di
 In questa sezione esamineremo le problematiche relative al controllo di
 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
 usati, come questi possono essere modificati nella creazione e nel lancio di

-nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte
-le problematiche connesse ad una gestione accorta dei privilegi.
+nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
+problematiche connesse ad una gestione accorta dei privilegi.

 
 
 \subsection{Gli identificatori del controllo di accesso}
 
 
 \subsection{Gli identificatori del controllo di accesso}


@@ -1294,12 +1295,12 @@ evidente che per poter implementare un controllo sulle operazioni occorre
 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
 anche a ciascun processo è associato un utente e a un gruppo.
 
 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
 anche a ciascun processo è associato un utente e a un gruppo.
 

-Un semplice controllo di una corrispondenza fra identificativi però non
-garantisce però sufficiente flessibilità per tutti quei casi in cui è
-necessario poter disporre di privilegi diversi, o dover impersonare un altro
-utente per un limitato insieme di operazioni. Per questo motivo in generale
-tutti gli Unix prevedono che i processi abbiano almeno due gruppi di
-identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
+Un semplice controllo di una corrispondenza fra identificativi non garantisce
+però sufficiente flessibilità per tutti quei casi in cui è necessario poter
+disporre di privilegi diversi, o dover impersonare un altro utente per un
+limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
+prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
+rispettivamente \textit{real} ed \textit{effective}.

 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize


@@ -1341,8 +1342,8 @@ cui si accede al sistema (e relativo gruppo di default). Servono per
 l'identificazione dell'utente e normalmente non vengono mai cambiati. In
 realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
 solo ad un processo che abbia i privilegi di amministratore; questa
 l'identificazione dell'utente e normalmente non vengono mai cambiati. In
 realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
 solo ad un processo che abbia i privilegi di amministratore; questa

-possibilità è usata ad esempio da \cmd{login} che una volta completata la
-procedura di autenticazione lancia una shell per la quale setta questi
+possibilità è usata ad esempio da \cmd{login} che, una volta completata la
+procedura di autenticazione, lancia una shell per la quale setta questi

 identificatori ai valori corrispondenti all'utente che entra nel sistema.
 
 Al secondo gruppo appartengono l'\textit{effective user id} e
 identificatori ai valori corrispondenti all'utente che entra nel sistema.
 
 Al secondo gruppo appartengono l'\textit{effective user id} e


@@ -1357,7 +1358,7 @@ Questi identificatori normalmente sono identici ai corrispondenti del gruppo
 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
 \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
 dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
 \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
 dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati

-all'utente e al gruppo proprietari del file; questo consente, per programmi in
+all'utente e al gruppo proprietari del file. Questo consente, per programmi in

 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
 di un'altro (o dell'amministratore).
 
 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
 di un'altro (o dell'amministratore).
 


@@ -1447,8 +1448,7 @@ corrente.
 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
 la prima; la seconda si comporta esattamente allo stesso modo facendo
 riferimento al \textit{group id} invece che all'\textit{user id}.  Gli
 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
 la prima; la seconda si comporta esattamente allo stesso modo facendo
 riferimento al \textit{group id} invece che all'\textit{user id}.  Gli

-eventuali \textit{supplementary group id} non vengono modificati da nessuna
-delle funzioni che tratteremo in questa sezione.
+eventuali \textit{supplementary group id} non vengono modificati.

 
 
 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
 
 
 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se


@@ -1465,16 +1465,16 @@ riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
 eventualmente tornare indietro.
 
 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
 eventualmente tornare indietro.
 

-Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
+Come esempio per chiarire dell'uso di queste funzioni prendiamo quello con cui

 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
 registrato chi sta usando il sistema al momento corrente; chiaramente non può
 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
 falsificare la registrazione. Per questo motivo questo file (e l'analogo
 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
 registrato chi sta usando il sistema al momento corrente; chiaramente non può
 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
 falsificare la registrazione. Per questo motivo questo file (e l'analogo
 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad

-esempio tutti i programmi di terminale in X, o il programma \cmd{screen}
-che crea terminali multipli su una console) appartengono a questo gruppo ed
-hanno il bit \acr{sgid} settato.
+esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
+crea terminali multipli su una console) appartengono a questo gruppo ed hanno
+il bit \acr{sgid} settato.

 
 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la
 situazione degli identificatori è la seguente:
 
 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la
 situazione degli identificatori è la seguente:


@@ -1526,7 +1526,7 @@ ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
 \label{sec:proc_setreuid}
 
 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
 \label{sec:proc_setreuid}
 
 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino

-  alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i
+  alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i

 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
 e \textit{real id}. I loro prototipi sono:
 \begin{functions}
 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
 e \textit{real id}. I loro prototipi sono:
 \begin{functions}


@@ -1750,8 +1750,8 @@ ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo 
     restituisce 0 in caso di successo e -1 in caso di fallimento.}
 \end{functions}
 \noindent la funzione esegue una scansione del database dei gruppi (si veda
     restituisce 0 in caso di successo e -1 in caso di fallimento.}
 \end{functions}
 \noindent la funzione esegue una scansione del database dei gruppi (si veda

-\secref{sec:sys_xxx}) e ritorna in \param{groups} la lista di quelli a cui
-l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
+\secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
+cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore

 perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1
 e passando indietro il numero dei gruppi trovati.
 
 perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1
 e passando indietro il numero dei gruppi trovati.
 


@@ -1823,11 +1823,10 @@ occorre tenere conto di una serie di problematiche che normalmente non
 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
 programma alla volta.
 
 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
 programma alla volta.
 

-Pur essendo questo argomento di carattere generale, in questa sezione
-conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi ci
-è parso opportuno introdurre sinteticamente queste problematiche, che
-ritroveremo a più riprese in capitoli successivi, dando una breve descrizione
-delle loro caratteristiche principali e della terminologia relativa.
+Pur essendo questo argomento di carattere generale, ci è parso opportuno
+introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
+in capitoli successivi, in questa sezione conclusiva del capitolo in cui
+abbiamo affrontato la gestione dei processi.

 
 
 \subsection{Le operazioni atomiche}
 
 
 \subsection{Le operazioni atomiche}


@@ -1849,7 +1848,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
 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 nelle 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
 \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


@@ -1865,13 +1864,13 @@ operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
 il cui accesso è assicurato essere atomico.  In pratica comunque si può
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
 il cui accesso è assicurato essere atomico.  In pratica comunque si può

-assumere che in ogni piattaforma su cui è implementato Linux il tipo
-\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono
+assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
+\type{int}, gli altri interi di dimensione inferiore ed i puntatori sono

 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per

-le strutture. In questi casi è anche opportuno marcare come \type{volatile} le
-variabili che possono essere interessate ad accesso condiviso, onde evitare
-problemi con le ottimizzazioni del codice.
+le strutture. In tutti questi casi è anche opportuno marcare come
+\type{volatile} le variabili che possono essere interessate ad accesso
+condiviso, onde evitare problemi con le ottimizzazioni del codice.

 
 
 \subsection{Le \textit{race condition} e i \textit{deadlock}}
 
 
 \subsection{Le \textit{race condition} e i \textit{deadlock}}


@@ -1880,7 +1879,7 @@ problemi con le ottimizzazioni del codice.
 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
 diversi operano su una risorsa comune, ed in cui il risultato viene a
 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
 diversi operano su una risorsa comune, ed in cui il risultato viene a
 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso

-tipico è quella di una operazione che viene eseguita da un processo in più
+tipico è quello di una operazione che viene eseguita da un processo in più

 passi, e può essere compromessa dall'intervento di un altro processo che
 accede alla stessa risorsa quando ancora non tutti i passi sono stati
 completati.
 passi, e può essere compromessa dall'intervento di un altro processo che
 accede alla stessa risorsa quando ancora non tutti i passi sono stati
 completati.


@@ -1900,8 +1899,8 @@ gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
 condivisa. In questi casi, se non si dispone della possibilità di eseguire
 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
 condivisa. In questi casi, se non si dispone della possibilità di eseguire
 atomicamente le operazioni necessarie, occorre che quelle parti di codice in

-cui si compiono le operazioni critiche sulle risorse condivise, le cosiddette
-\textsl{sezioni critiche} del programma, siano opportunamente protette da
+cui si compiono le operazioni sulle risorse condivise (le cosiddette
+\textsl{sezioni critiche}) del programma, siano opportunamente protette da

 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
 tipo in \secref{sec:ipc_semaph}).
 
 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
 tipo in \secref{sec:ipc_semaph}).
 


@@ -1919,8 +1918,7 @@ quest'ultima diventer
 In tutti questi casi è di fondamentale importanza il concetto di atomicità
 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
 In tutti questi casi è di fondamentale importanza il concetto di atomicità
 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile

-eseguire in maniera atomica le operazioni necessarie, proteggendo con gli
-adeguati meccanismi le \textsl{sezioni critiche} del programma.
+eseguire in maniera atomica le operazioni necessarie.

 
 
 \subsection{Le funzioni rientranti}
 
 
 \subsection{Le funzioni rientranti}