Correzioni secondo i suggerimenti di Alessio

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index 40d8e2575d262890ff440b6f165c95eb1f563537..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


@@ -90,10 +93,11 @@ risoluzione del nome (\textit{file name resolution} o \textit{pathname
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 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
+  costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
+perché il procedimento funzioni, occorre che i nomi indicati come directory

 esistano e siano effettivamente directory, inoltre i permessi (si veda
 esistano e siano effettivamente directory, inoltre i permessi (si veda

-\secref{sec:file_access_control}) devono consentire l'accesso.
+\secref{sec:file_access_control}) devono consentire l'accesso all'intero
+\textit{pathname}.

 
 Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
 radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
 
 Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
 radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in


@@ -105,16 +109,16 @@ parte dalla directory corrente (su cui torneremo in
   relativo}\index{pathname relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
   relativo}\index{pathname relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti

-in ogni directory, il primo fa riferimento alla directory corrente e il
+in ogni directory: il primo fa riferimento alla directory corrente e il

 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
 la directory che contiene il riferimento alla directory corrente; nel caso
 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
 la directory che contiene il riferimento alla directory corrente; nel caso

-questa sia la directory radice allora il riferimento è a se stessa.
+questa sia la directory radice, allora il riferimento è a se stessa.

 
 
 \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


@@ -140,13 +144,13 @@ 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 \\
-      \textit{fifo} & \textsl{``tubo''} &
+      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) \\
       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\

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

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


@@ -160,27 +164,29 @@ VMS o Windows) 
 un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
 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
 un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
 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}.
+per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i
+  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 è
 
 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 è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
-(\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
+codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
+il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
+del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
+  dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una
+  conversione fra questi due formati di testo.} Questo può causare alcuni

 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
 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
+del filesystem. Ciò nonostante 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 è, per quanto usata ed accettata in maniera
 universale, solo una convenzione.
 
 
 i nomi dei file, ad esempio il codice C normalmente si mette in file con
 l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
 universale, 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}
 


@@ -190,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}.
 


@@ -203,29 +209,30 @@ 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}.
 
 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
 e sono rappresentati da puntatori ad un opportuna struttura definita dalle
 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
 e sono rappresentati da puntatori ad un opportuna struttura definita dalle

-librerie del C, si accede ad essi sempre in maniera indiretta utilizzando il
+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
-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}).
+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


@@ -325,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,