Correzioni secondo i suggerimenti di Alessio
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 18 Mar 2002 17:20:08 +0000 (17:20 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 18 Mar 2002 17:20:08 +0000 (17:20 +0000)
ChangeLog
fileintro.tex

index 26d9895..ae3d058 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
index 15e2fd8..2dce07e 100644 (file)
@@ -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
-\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
@@ -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} &
-      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} &
-      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) \\
@@ -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
-  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 è
@@ -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
-  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}.
 
@@ -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
-\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}.
 
@@ -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
-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
-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
@@ -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
-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,