Prova di endianess
[gapil.git] / fileintro.tex
index e309ea954febb4b20c99265896fda52e9001c1b7..92efd2abf427b68a5802689583509c9697537cda 100644 (file)
@@ -1,6 +1,6 @@
 % fileintro.tex
 %%
 % fileintro.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
@@ -45,7 +45,7 @@ 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}).
 
 \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
+In questa sezione faremo una panoramica generica su come il sistema presenta
 i file ai processi, trattando l'organizzazione di file e directory, i tipi di
 file ed introducendo le interfacce disponibili e le loro caratteristiche.
 
 i file ai processi, trattando l'organizzazione di file e directory, i tipi di
 file ed introducendo le interfacce disponibili e le loro caratteristiche.
 
@@ -69,7 +69,7 @@ accedere al file a partire dalla \textit{root directory}, che 
 una serie di nomi separati da una \file{/}.
 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 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
+riceve dal bootloader 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
 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
@@ -175,10 +175,10 @@ in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in
       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 a blocchi \\
       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 a blocchi \\
-      \textit{fifo} & \textsl{``coda''} &
+      \textit{fifo} & ``\textsl{coda}'' &
       un file speciale che identifica una linea di comunicazione software
       unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\
       un file speciale che identifica una linea di comunicazione software
       unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\
-      \textit{socket}\index{socket} & \textsl{``presa''} &
+      \textit{socket}\index{socket} & ``\textsl{presa}''&
       un file speciale che identifica una linea di comunicazione software
       bidirezionale (vedi \capref{cha:socket_intro}) \\
     \hline
       un file speciale che identifica una linea di comunicazione software
       bidirezionale (vedi \capref{cha:socket_intro}) \\
     \hline
@@ -192,12 +192,12 @@ Windows) 
 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
 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{questo vale
-  anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di
-  dimensione fissa avviene solo all'interno del kernel, ed è completamente
-  trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
-    diretto} riferendosi alla capacità, che non ha niente a che fare con tutto
-  ciò, di effettuare, attraverso degli appositi file di
+il cosiddetto ``\textsl{accesso diretto}'' come nel caso del
+VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
+  dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
+  ed è completamente trasparente all'utente. Inoltre talvolta si parla di
+  \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
+  fare con tutto ciò, di effettuare, attraverso degli appositi file di
   dispositivo\index{file!di dispositivo}, operazioni di I/O direttamente sui
   dischi senza passare attraverso un filesystem (il cosiddetto \textit{raw
     access}, introdotto coi kernel della serie 2.4.x).}
   dispositivo\index{file!di dispositivo}, operazioni di I/O direttamente sui
   dischi senza passare attraverso un filesystem (il cosiddetto \textit{raw
     access}, introdotto coi kernel della serie 2.4.x).}
@@ -346,12 +346,12 @@ portabilit
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
 
 \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
-unix-like ed il comportamento delle relative funzioni di manipolazione,
-occorre una breve introduzione al funzionamento gestione dei file da parte del
-kernel e sugli oggetti su cui è basato un filesystem. In particolare occorre
-tenere presente dov'è che si situa la divisione fondamentale fra kernel space
-e user space che tracciavamo al \capref{cha:intro_unix}.
+%% Per capire fino in fondo le proprietà di file e directory in un sistema
+%% unix-like ed il comportamento delle relative funzioni di manipolazione,
+%% occorre una breve introduzione al funzionamento della gestione dei file da
+%% parte del kernel e sugli oggetti su cui è basato un filesystem. In particolare
+%% occorre tenere presente dov'è che si situa la divisione fondamentale fra
+%% kernel space e user space che tracciavamo al \capref{cha:intro_unix}.
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
@@ -409,7 +409,7 @@ Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
 filesystem supportato: quando si vuole inserire il supporto di un nuovo
 filesystem tutto quello che occorre è chiamare la funzione
 \code{register\_filesystem} passandole un'apposita struttura
 filesystem supportato: quando si vuole inserire il supporto di un nuovo
 filesystem tutto quello che occorre è chiamare la funzione
 \code{register\_filesystem} passandole un'apposita struttura
-(\var{file\_system\_type}) che contiene i dettagli per il riferimento
+\code{file\_system\_type} che contiene i dettagli per il riferimento
 all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
 
 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
 all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
 
 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
@@ -453,7 +453,7 @@ Una singola \textit{dentry} contiene in genere il puntatore ad un
 disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
 una directory, un link simbolico, una FIFO, un file di
 dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa
 disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
 una directory, un link simbolico, una FIFO, un file di
 dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa
-essere rappresentata dal VFS (i tipi di ``file'' riportati in
+essere rappresentata dal VFS (i tipi di file riportati in
 \tabref{tab:file_file_types}). A ciascuno di essi è associata pure una
 struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
 file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
 \tabref{tab:file_file_types}). A ciascuno di essi è associata pure una
 struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
 file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
@@ -484,8 +484,8 @@ la \func{open} per aprire il file o la \func{stat} per leggere i dati
 dell'inode\index{inode} e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 dell'inode\index{inode} e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
-una struttura di tipo \var{file} in cui viene inserito un puntatore alla
-\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
+una struttura di tipo \struct{file} in cui viene inserito un puntatore alla
+\textit{dentry} e una struttura \struct{f\_ops} che contiene i puntatori ai
 metodi che implementano le operazioni disponibili sul file. In questo modo i
 processi in user space possono accedere alle operazioni attraverso detti
 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
 metodi che implementano le operazioni disponibili sul file. In questo modo i
 processi in user space possono accedere alle operazioni attraverso detti
 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
@@ -528,12 +528,12 @@ operazioni previste dal kernel 
 In questo modo per ciascun file diventano possibili una serie di operazioni
 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia
 astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
 In questo modo per ciascun file diventano possibili una serie di operazioni
 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia
 astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
-utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
-di file in questione.
+utilizzare l'opportuna routine dichiarata in \struct{f\_ops} appropriata al
+tipo di file in questione.
 
 
-Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su
-normale un file di dati; ovviamente certe operazioni (nel caso della seriale
-ad esempio la \code{seek}) non saranno disponibili, però con questo sistema
+Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
+normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
+esempio la \code{seek}) non saranno disponibili, però con questo sistema
 l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 
 l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 
@@ -654,7 +654,7 @@ adesso sar
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
-file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di
+file lunghi (256 caratteri, estensibili a 1012) con una dimensione massima di
 4~Tb.
 
 Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
 4~Tb.
 
 Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che