Correzioni secondo i suggerimenti di Alessio

diff --git a/ChangeLog b/ChangeLog
index 26d9895f6d660330c70e5097abd16c5648c9af2f..ae3d058674394de96fc29d7f0f4c6ad8be215e89 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2002-03-18  Simone Piccardi  <piccardi@firenze.linux.it>
+
+       * fileintro.tex: Correzioni varie su suggerimenti di A. Frusciante. 
+

 2002-03-02  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * prochand.tex: Aggiunte info sui limiti superiore ed inferiore
 2002-03-02  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * prochand.tex: Aggiunte info sui limiti superiore ed inferiore

diff --git a/fileintro.tex b/fileintro.tex
index 15e2fd82fbd77d9004b4fccd7973c75d691d57c7..2dce07e878e8190bf31b8c060e5bbd8e42e35212 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -47,21 +47,24 @@ In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
 file vengono tenuti all'interno di un unico albero la cui radice (quella che
 viene chiamata \textit{root directory}) viene montata all'avvio.  Un file
 viene identificato dall'utente usando quello che viene chiamato
 file vengono tenuti all'interno di un unico albero la cui radice (quella che
 viene chiamata \textit{root directory}) viene montata all'avvio.  Un file
 viene identificato dall'utente usando quello che viene chiamato

-\textit{pathname}\footnote{anche se il manuale della \acr{glibc} depreca
-  questa nomenclatura, poiché genererebbe confusione, dato che con
-  \textit{path} si indica anche un insieme di directory su cui effettuare una
-  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 a partire dalla \textit{root
-  directory}, che è composto da una serie di nomi separati da una \file{/}.
-
-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.
+\textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa
+  nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
+  un insieme di directory su cui effettuare una ricerca (come quello in cui si
+  cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e
+  di componente per il nome del file all'interno della directory. 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 a partire dalla \textit{root directory}, che è composto da una serie
+di nomi separati da una \file{/}.
+
+All'avvio del sistema, completata 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


@@ -141,9 +144,9 @@ dati) in base al loro contenuto, o tipo di accesso.
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &

-      un file che identifica una periferica ad accesso sequenziale \\
+      un file che identifica una periferica ad accesso a caratteri \\

       \textit{block device} & \textsl{dispositivo a blocchi} &
       \textit{block device} & \textsl{dispositivo a blocchi} &

-      un file che identifica una periferica ad accesso diretto \\
+      un file che identifica una periferica ad accesso a blocchi \\

       \textit{fifo} & \textsl{``coda''} &
       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\
       \textit{fifo} & \textsl{``coda''} &
       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\


@@ -162,9 +165,10 @@ un flusso continuo di byte. Non esiste cio
 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 file di testo e binari che c'è in Windows) né c'è una strutturazione a record
 per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i
 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 file di testo e binari che c'è in Windows) né c'è una strutturazione a record
 per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i

-  kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi
-  (il \textit{raw access}) attraverso dei device file appositi, che però non
-  ha nulla a che fare con questo.}
+  kernel della serie 2.4 è disponibile, attraverso dei device file appositi,
+  una forma di accesso diretto ai dischi (il \textit{raw access}) che però non
+  ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
+  passare attraverso un filesystem.}

 
 Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
 
 Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è


@@ -192,7 +196,7 @@ accedere al loro contenuto.
 
 La prima è l'interfaccia standard di Unix, quella che il manuale delle
 \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
 
 La prima è l'interfaccia standard di Unix, quella che il manuale delle
 \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file

-  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e provvede
+  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce 

 un accesso non bufferizzato; la tratteremo in dettaglio in
 \capref{cha:file_unix_interface}.
 
 un accesso non bufferizzato; la tratteremo in dettaglio in
 \capref{cha:file_unix_interface}.
 


@@ -205,7 +209,7 @@ rappresentati da numeri interi (cio
 L'interfaccia è definita nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 L'interfaccia è definita nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli

-\textit{stream}\index{stream}. Essa provvede funzioni più evolute e un accesso
+\textit{stream}\index{stream}. Essa fornisce funzioni più evolute e un accesso

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


@@ -216,18 +220,19 @@ librerie del C; si accede ad essi sempre in maniera indiretta utilizzando il
 tipo \type{FILE *}.  L'interfaccia è definita nell'header \type{stdio.h}.
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 tipo \type{FILE *}.  L'interfaccia è definita nell'header \type{stdio.h}.
 
 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 su un
-qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
-con i \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}).
+altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio
+a tempo opportuno), ma per poter accedere alle operazioni di controllo
+(descritte in \ref{sec:file_fcntl} e \ref{sec:file_ioctl}) su un qualunque
+tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix con i
+\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
 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
 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 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
+di quella dei \textit{file descriptor}, che forniscono 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
 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


@@ -327,7 +332,7 @@ Linux, l'\acr{ext2}.
 In Linux il concetto di \textit{everything is a file} è stato implementato
 attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
 strato intermedio che il kernel usa per accedere ai più svariati filesystem
 In Linux il concetto di \textit{everything is a file} è stato implementato
 attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
 strato intermedio che il kernel usa per accedere ai più svariati filesystem

-mantenendo la stessa interfaccia per i programmi in user space. Esso provvede
+mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce

 un livello di indirezione che permette di collegare le operazioni di
 manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
 queste ultime nei vari modi in cui diversi filesystem le effettuano,
 un livello di indirezione che permette di collegare le operazioni di
 manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
 queste ultime nei vari modi in cui diversi filesystem le effettuano,