Lavoro fatto a casa senza ADSL, correzioni multiple agli indici, documentato

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index 78c2a714e4f652c00dfc270aec4234535ee9474a..6fea57d59babf2a0d8e9770e63ae1686b82486b4 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -43,7 +43,6 @@ Questo viene fatto strutturando l'informazione sul disco attraverso quello che
 si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa
 poi viene resa disponibile ai processi attraverso quello che viene chiamato il
 \textsl{montaggio} del \textit{filesystem}.
 si chiama un \textit{filesystem} (vedi sez.~\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 sez.~\ref{sec:file_arch_func}).

 
 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
 
 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


@@ -53,7 +52,7 @@ file ed introducendo le interfacce disponibili e le loro caratteristiche.
 \subsection{L'organizzazione di file e directory}
 \label{sec:file_organization}
 
 \subsection{L'organizzazione di file e directory}
 \label{sec:file_organization}
 

-\index{\textit{pathname}|(} 
+\itindbeg{pathname}

 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
 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


@@ -115,10 +114,10 @@ Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla
 directory radice del processo; questa, a meno di un \func{chroot} (su cui
 torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed
 equivale alla directory radice dell'albero dei file: in questo caso si parla
 directory radice del processo; questa, a meno di un \func{chroot} (su cui
 torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed
 equivale alla directory radice dell'albero dei file: in questo caso si parla

-di un \textsl{pathname assoluto}\index{\textit{pathname}!assoluto}. Altrimenti
-la ricerca parte dalla directory corrente (su cui torneremo in
+di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}.  Altrimenti la
+ricerca parte dalla directory corrente (su cui torneremo in

 sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
 sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname

-relativo}\index{\textit{pathname}!relativo}.
+  relativo} \itindsub{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
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 in ogni directory: il primo fa riferimento alla directory corrente e il


@@ -126,6 +125,7 @@ secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cio
 la directory che contiene il riferimento alla directory corrente; nel caso la
 directory corrente coincida con la directory radice, allora il riferimento è a
 se stessa.
 la directory che contiene il riferimento alla directory corrente; nel caso la
 directory corrente coincida con la directory radice, allora il riferimento è a
 se stessa.

+\itindend{pathname}

 
 
 \subsection{I tipi di file}
 
 
 \subsection{I tipi di file}


@@ -135,7 +135,7 @@ Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 sez.~\ref{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
 sez.~\ref{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

-\textit{Virtual File System}\index{\textit{Virtual~File~System}} è riportato in
+\textit{Virtual File System}\itindex{Virtual~File~System} è riportato in

 tab.~\ref{tab:file_file_types}.
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 tab.~\ref{tab:file_file_types}.
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con


@@ -301,12 +301,6 @@ 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 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 cap.~\ref{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


@@ -314,30 +308,20 @@ prima le caratteristiche generali di un filesystem di un sistema unix-like,
 per poi trattare in maniera un po' più dettagliata il filesystem più usato con
 Linux, l'\acr{ext2}.
 
 per poi trattare in maniera un po' più dettagliata il filesystem più usato con
 Linux, l'\acr{ext2}.
 

-% in particolare si riprenderà, approfondendolo sul piano dell'uso nelle
-% funzioni di libreria, il concetto di \textit{inode} di cui abbiamo brevemente
-% accennato le caratteristiche (dal lato dell'implementazione nel kernel) in
-% sez.~\ref{sec:file_vfs}.
-

 
 \subsection{Il \textit{Virtual File System} di Linux}
 \label{sec:file_vfs}
 
 
 \subsection{Il \textit{Virtual File System} di Linux}
 \label{sec:file_vfs}
 

-% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
-% file.  L'argomento è abbastanza ``esoterico'' e questa sezione può essere
-% saltata ad una prima lettura; è bene però tenere presente che vengono
-% introdotti qui alcuni termini che potranno comparire in seguito, come
-% \textit{inode}, \textit{dentry}, \textit{dcache}.
-
+\itindbeg{Virtual~File~System}

 In Linux il concetto di \textit{everything is a file} è stato implementato
 In Linux il concetto di \textit{everything is a file} è stato implementato

-attraverso il \textit{Virtual File System}\index{\textit{Virtual~File~System}}
-(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 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 i diversi
-filesystem le effettuano, permettendo la coesistenza di filesystem differenti
-all'interno dello stesso albero delle directory.
+attraverso il \textit{Virtual File System} (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 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 i diversi filesystem le effettuano,
+permettendo la coesistenza di filesystem differenti all'interno dello stesso
+albero delle directory.

 
 Quando un processo esegue una system call che opera su un file, il kernel
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
 
 Quando un processo esegue una system call che opera su un file, il kernel
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le


@@ -396,9 +380,8 @@ sui file gi
 \subsection{Il funzionamento del \textit{Virtual File System}}
 \label{sec:file_vfs_work}
 
 \subsection{Il funzionamento del \textit{Virtual File System}}
 \label{sec:file_vfs_work}
 

-La funzione più importante implementata dal
-VFS\index{\textit{Virtual~File~System}} è la system call \func{open} che
-permette di aprire un file. Dato un \index{\textit{pathname}}\textit{pathname}
+La funzione più importante implementata dal VFS è la system call \func{open}
+che permette di aprire un file. Dato un \itindex{pathname}\textit{pathname}

 viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve
 \textit{dcache}), una tabella che contiene tutte le \textit{directory entry}
 (in breve \textit{dentry}) che permette di associare in maniera rapida ed
 viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve
 \textit{dcache}), una tabella che contiene tutte le \textit{directory entry}
 (in breve \textit{dentry}) che permette di associare in maniera rapida ed


@@ -426,7 +409,7 @@ La \textit{dcache} costituisce perci
 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
 parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
 per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
 parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
 per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo

-\index{\textit{pathname}}\textit{pathname} il VFS deve creare una nuova
+\itindex{pathname}\textit{pathname} il VFS deve creare una nuova

 \textit{dentry} e caricare l'inode\index{inode} corrispondente in memoria.
 
 Questo procedimento viene eseguito dal metodo \code{lookup()}
 \textit{dentry} e caricare l'inode\index{inode} corrispondente in memoria.
 
 Questo procedimento viene eseguito dal metodo \code{lookup()}


@@ -493,6 +476,7 @@ 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.
 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.

+\itindend{Virtual~File~System}

 
 
 \subsection{Il funzionamento di un filesystem Unix}
 
 
 \subsection{Il funzionamento di un filesystem Unix}


@@ -670,12 +654,12 @@ L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
 inode\index{inode}. 
 
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
 inode\index{inode}. 
 

-Le directory sono implementate come una linked list con voci di dimensione
-variabile. Ciascuna voce della lista contiene il numero di inode\index{inode},
-la sua lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
-fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi
-per i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio
-disco.
+Le directory sono implementate come una \itindex{linked~list}\textit{linked
+  list} con voci di dimensione variabile. Ciascuna voce della lista contiene
+il numero di inode\index{inode}, la sua lunghezza, il nome del file e la sua
+lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo
+è possibile implementare nomi per i file anche molto lunghi (fino a 1024
+caratteri) senza sprecare spazio disco.