Riorganizzate varie parti, rimetto in linea la nuova versione
[gapil.git] / fileintro.tex
index d4d4785..4fc1e38 100644 (file)
@@ -56,17 +56,17 @@ percorso che si deve fare per accedere al file.
 Dopo 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 \texttt{/}); tutti gli ulteriori dischi devono poi essere inseriti
+directory \file{/}); tutti gli ulteriori dischi devono poi essere inseriti
 nell'albero utilizzando opportune subdirectory.
 
-Alcuni filesystem speciali (come \texttt{/proc} che contiene un'interfaccia ad
+Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
 alcune strutture interne del kernel) sono generati automaticamente dal kernel
 stesso, ma anche essi devono essere montati all'interno dell'albero.
 
 All'interno dello stesso albero si potranno poi inserire anche gli altri
 oggetti visti attraverso l'interfaccia che manipola i files come le FIFO, i
 link, i socket e gli stessi i file di dispositivo (questi ultimi, per
-convenzione, sono inseriti nella directory \texttt{/dev}).
+convenzione, sono inseriti nella directory \file{/dev}).
 
 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
 medesimi nell'albero descritto in precedenza; una directory comunque, come già
@@ -79,21 +79,22 @@ che contiene le informazioni che associano un nome al contenuto.
 
 I manuale delle glibc chiama i nomi contenuti nelle directory
 \textsl{componenti} (in inglese \textit{file name components}), noi li
-chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla
-directory corrente semplicemente specificando il nome da essa contenuto. Una
-directory contiene semplicemente un elenco di questi nomi, che possono
-corrispondere a un qualunque oggetto del filesystem, compresa un'altra
+chiameremo più semplicemente \textit{nomi}. Un file può essere indicato
+rispetto alla directory corrente semplicemente specificando il nome da essa
+contenuto. Una directory contiene semplicemente un elenco di questi nomi, che
+possono corrispondere a un qualunque oggetto del filesystem, compresa un'altra
 directory; l'albero viene appunto creato inserendo directory in altre
 directory.
 
-Il nome completo di file generico è composto da una serie di questi
-\textsl{componenti} separati da una \texttt{/} (in Linux più \texttt{/}
-consecutive sono considerate equivalenti ad una sola). Il nome completo di un
-file viene usualmente chiamato \textit{pathname}, e anche se il manuale della
-glibc depreca questo nome (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); l'uso è ormai così comune
-che è senz'altro più chiaro dell'alternativa proposta.
+Il nome completo di file generico è composto da una serie di nomi separati da
+una \texttt{/} (in Linux più \texttt{/} consecutive sono considerate
+equivalenti ad una sola). Il nome completo di un file viene usualmente
+chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo
+nome (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 è senz'altro più chiaro
+dell'alternativa proposta.
 
 Il processo con cui si associa ad un pathname uno specifico file è chiamato
 risoluzione del nome (\textit{file name resolution} o \textit{pathname
@@ -112,11 +113,11 @@ equivale alla directory radice dell'albero (come descritto in
 cui torneremo più avanti in \secref{sec:file_work_dir}) ed il pathname è
 detto \textsl{relativo}.
 
-I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
-inseriti in ogni directory, il primo fa riferimento alla directory corrente e
-il secondo alla directory \textsl{genitore} (\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.
+I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
+in ogni directory, il primo fa riferimento alla directory corrente e il
+secondo alla directory \textsl{genitrice} (\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.
 
 
 \subsection{I tipi di files}
@@ -195,8 +196,8 @@ bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 direttamente le system call del kernel (in realtà il kernel effettua al suo
 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
 dispositivi); i file descriptors sono rappresentati da numeri interi (cioè
-semplici variabili di tipo \texttt{int}).  L'interfaccia è definita
-nell'header \texttt{unistd.h}.
+semplici variabili di tipo \type{int}).  L'interfaccia è definita
+nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della glibc chiama degli
 \textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato
@@ -207,10 +208,10 @@ Questa 
 anche su tutti i sistemi non unix. Gli 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 tipo
-\texttt{FILE *}.  L'interfaccia è definita nell'header \texttt{stdio.h}.
+\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 (pipes, socket, device), ma per poter accedere alle
+altri oggetti del VFS (pipe, socket, device), ma per poter accedere alle
 operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
 usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
 devono essere usati i file descriptor se si vuole ricorrere a modalità
@@ -305,7 +306,7 @@ tracciavamo al \capref{cha:intro_unix}.
 In questa sezione esamineremo come viene implementato l'accesso ai files in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 poi in maniera un po' più dettagliata il filesystem standard di Linux,
-l'\texttt{ext2}, come esempio di un filesystem unix-like.
+l'\acr{ext2}, come esempio di un filesystem unix-like.
 
 
 % in particolare si riprenderà, approfondendolo sul piano
@@ -415,18 +416,18 @@ files, ovviamente per non riempire tutta la memoria questa vista 
 richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve
 creare una nuova dentry e caricare l'inode corrispondente in memoria. 
 
-Questo procedimento viene eseguito dal metodo \texttt{lookup()} dell'inode
+Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode
 della directory che contiene il file; questo viene installato nelle relative
 strutture in memoria quando si effettua il montaggio lo specifico filesystem
 su cui l'inode va a vivere.
 
 Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
 diventa possibile accedere alle varie operazioni sul file come la
-\texttt{open} per aprire il file o la \texttt{stat} per leggere i dati
+\func{open} per aprire il file o la \func{stat} per leggere i dati
 dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
-una struttura di tipo \texttt{file} in cui viene inserito un puntatore alla
+una struttura di tipo \var{file} in cui viene inserito un puntatore alla
 dentry e una struttura \verb|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
@@ -527,8 +528,8 @@ torneremo in seguitp; in particolare 
 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
   fisici che contengono i dati e così via; le informazioni che la funzione
-  \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
-  si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
+  \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
+  troverà solo il nome del file e il numero dell'\textit{inode} ad esso
   associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentries} del kernel di
@@ -559,7 +560,7 @@ torneremo in seguitp; in particolare 
 
 Infine è bene avere presente che essendo file pure loro, esiste un numero di
 riferimenti anche per le directories; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \texttt{img} nella
+situazione mostrata in \curfig\ creiamo una nuova directory \file{img} nella
 directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
 chiarezza abbiamo aggiunto dei numeri di inode.
 
@@ -587,7 +588,7 @@ caratteristiche di un filesystem standard unix, 
 filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 
 
-Oltre alle caratteristiche standard \textsl{ext2} fornisce alcune estensioni
+Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
 che non sono presenti sugli altri filesystem unix, le cui principali sono le
 seguenti:
 \begin{itemize}
@@ -602,7 +603,7 @@ seguenti:
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
   di sgid settato (per una descrizione dettagliata del significato di questi
   termini si veda \secref{sec:file_access_control}), nel qual caso file e
-  sottodirectory ereditano sia il group id che il sgid.
+  sottodirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).
@@ -617,7 +618,7 @@ seguenti:
   log).
 \end{itemize}
 
-La struttura di \textsl{ext2} è stata ispirata a quella del filesystem di BSD,
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD,
 un filesystem è composto da un insieme di blocchi, la struttura generale è
 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
 è divisa in gruppi di blocchi.