Correzioni varie.

diff --git a/filedir.tex b/filedir.tex
index 4585831c23a899e35b998a19c45bc399ce5bdfa1..4ae79e697eef22fea76c36c4398380e7cf828b9c 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -95,8 +95,8 @@ campo \var{st\_mode} sono riportate in \ntab.
 
 Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
 seconda che si riferiscano a file, link simbolici o directory, qui ci
 
 Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
 seconda che si riferiscano a file, link simbolici o directory, qui ci

-limiteremo ad un riassunto delle regole generali, entrando nei
-dettagli più avanti.
+limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
+avanti.

 
 La prima regola è che per poter accedere ad un file attraverso il suo pathname
 occorre il permesso di esecuzione in ciascuna delle directory che compongono
 
 La prima regola è che per poter accedere ad un file attraverso il suo pathname
 occorre il permesso di esecuzione in ciascuna delle directory che compongono


@@ -607,13 +607,13 @@ generali relative alle caratteristiche di ciascun file, a partire dalle
 informazioni relative al controllo di accesso, sono mantenute nell'inode.
 
 Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
 informazioni relative al controllo di accesso, sono mantenute nell'inode.
 
 Vedremo in questa sezione come sia possibile leggere tutte queste informazioni

-usando la funzione \texttt{stat}, che permette l'accesso a tutti i dati
+usando la funzione \func{stat}, che permette l'accesso a tutti i dati

 memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare
 tutte queste informazioni (eccetto quelle che riguardano la gestione del
 memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare
 tutte queste informazioni (eccetto quelle che riguardano la gestione del

-controllo di accesso, già trattate in in \secref{sec:file_access_control}).
+controllo di accesso, trattate in in \secref{sec:file_access_control}).

 
 
 
 

-\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
+\subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}}

 \label{sec:file_stat}
 
 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
 \label{sec:file_stat}
 
 La lettura delle informazioni relative ai file è fatta attraverso la famiglia


@@ -643,7 +643,7 @@ funzioni sono i seguenti:
   \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
 \end{functions}
 
   \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
 \end{functions}
 

-La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
+La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in

 generale dipende dall'implementazione, la versione usata da Linux è mostrata
 in \nfig, così come riportata dalla man page (in realtà la definizione
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
 generale dipende dall'implementazione, la versione usata da Linux è mostrata
 in \nfig, così come riportata dalla man page (in realtà la definizione
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi


@@ -679,7 +679,7 @@ struct stat {
 
 Si noti come i vari membri della struttura siano specificati come tipi nativi
 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
 
 Si noti come i vari membri della struttura siano specificati come tipi nativi
 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in

-\texttt{sys/types.h}). 
+\file{sys/types.h}). 

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


@@ -687,14 +687,14 @@ del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
 
 Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e
 alle directory esistono vari altri oggetti che possono stare su un filesystem;
 
 Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e
 alle directory esistono vari altri oggetti che possono stare su un filesystem;

-il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}
+il tipo di file è ritornato dalla \func{stat} nel campo \var{st\_mode}

 (che è quello che contiene anche le informazioni relative ai permessi).
 
 Dato che il valore numerico può variare a seconda delle implementazioni, lo
 standard POSIX definisce un insieme di macro per verificare il tipo di files,
 queste vengono usate anche da Linux che supporta pure le estensioni per link
 (che è quello che contiene anche le informazioni relative ai permessi).
 
 Dato che il valore numerico può variare a seconda delle implementazioni, lo
 standard POSIX definisce un insieme di macro per verificare il tipo di files,
 queste vengono usate anche da Linux che supporta pure le estensioni per link

-simbolici e socket definite da BSD, l'elenco completo di tutte le macro
-definite in GNU/Linux è riportato in \ntab.
+simbolici e socket definite da BSD, l'elenco completo di tutte le macro è
+riportato in \ntab.

 \begin{table}[htb]
   \centering
   \footnotesize
 \begin{table}[htb]
   \centering
   \footnotesize


@@ -982,7 +982,7 @@ creazione del file, usato da molti altri sistemi operativi, che in unix non
 esiste.
 
 
 esiste.
 
 

-\subsection{La funzione \texttt{utime}}
+\subsection{La funzione \func{utime}}

 \label{sec:file_utime}
 
 I tempi di ultimo accesso e modifica possono essere cambiati usando la
 \label{sec:file_utime}
 
 I tempi di ultimo accesso e modifica possono essere cambiati usando la


@@ -998,8 +998,8 @@ questa 
 La funzione restituisce zero in caso di successo e -1 in caso di errore, nel
 qual caso \var{errno} è settata opportunamente.
 \begin{errlist}
 La funzione restituisce zero in caso di successo e -1 in caso di errore, nel
 qual caso \var{errno} è settata opportunamente.
 \begin{errlist}

-\item \texttt{EACCESS} non si ha il permesso di scrittura sul file.
-\item \texttt{ENOENT} \var{filename} non esiste.
+\item \macro{EACCESS} non si ha il permesso di scrittura sul file.
+\item \macro{ENOENT} \var{filename} non esiste.

 \end{errlist}
 \end{prototype}
  
 \end{errlist}
 \end{prototype}
  


@@ -1030,14 +1030,14 @@ molto pi
 
 \section{La manipolazione di file e directory}
 
 
 \section{La manipolazione di file e directory}
 

-Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like
-i file hanno delle caratteristiche specifiche dipendenti dall'architettura del
+Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like i
+file hanno delle caratteristiche specifiche dipendenti dall'architettura del

 sistema, esamineremo qui allora le funzioni usate per la creazione di link
 sistema, esamineremo qui allora le funzioni usate per la creazione di link

-simbolici e diretti  e per la gestione delle directory, approfondendo quanto
+simbolici e diretti e per la gestione delle directory, approfondendo quanto

 già accennato in precedenza.
 
 
 già accennato in precedenza.
 
 

-\subsection{Le funzioni \texttt{link} e \texttt{unlink}}
+\subsection{Le funzioni \func{link} e \func{unlink}}

 \label{sec:file_link}
 
 Una delle caratteristiche comuni a vari sistemi operativi è quella di poter
 \label{sec:file_link}
 
 Una delle caratteristiche comuni a vari sistemi operativi è quella di poter


@@ -1055,27 +1055,27 @@ stesso file pu
 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
 questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
 
 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
 questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
 

-Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si
+Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si

 suole chiamare questo tipo di associazione un collegamento diretto (o
 \textit{hard link}).  Il prototipo della funzione e le sue caratteristiche
 principali, come risultano dalla man page, sono le seguenti:
 \begin{prototype}{unistd.h}
 {int link(const char * oldpath, const char * newpath)}
 suole chiamare questo tipo di associazione un collegamento diretto (o
 \textit{hard link}).  Il prototipo della funzione e le sue caratteristiche
 principali, come risultano dalla man page, sono le seguenti:
 \begin{prototype}{unistd.h}
 {int link(const char * oldpath, const char * newpath)}

-  Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath}
-  dandogli nome \texttt{newpath}.
+  Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
+  dandogli nome \var{newpath}.

   
   La funzione restituisce zero in caso di successo e -1 in caso di errore. La
   
   La funzione restituisce zero in caso di successo e -1 in caso di errore. La

-  variabile \texttt{errno} viene settata opportunamente, i principali codici
+  variabile \var{errno} viene settata opportunamente, i principali codici

   di errore sono:
   \begin{errlist}
   di errore sono:
   \begin{errlist}

-  \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
+  \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo

     stesso filesystem.
     stesso filesystem.

-  \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e
-    \texttt{newpath} non supporta i link diretti o è una directory.
-  \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di
+  \item \macro{EPERM} il filesystem che contiene \var{oldpath} e
+    \macro{newpath} non supporta i link diretti o è una directory.
+  \item \macro{EEXIST} un file (o una directory) con quel nome esiste di

     già.
     già.

-  \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il
-    numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
+  \item \macro{EMLINK} ci sono troppi link al file \vat{oldpath} (il
+    numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi

     \secref{sec:xxx_limits}).
   \end{errlist}
   
     \secref{sec:xxx_limits}).
   \end{errlist}
   


@@ -1090,20 +1090,20 @@ diverse directory.
 Per quanto dicevamo in \secref{sec:file_filesystem} la creazione del
 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
 Per quanto dicevamo in \secref{sec:file_filesystem} la creazione del
 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è

-il caso ad esempio del filesystem \texttt{vfat} di Windows).
+il caso ad esempio del filesystem \acr{vfat} di Windows).

 
 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
 in alcuni filesystem solo l'amministratore è in grado di creare un
 collegamento diretto ad un'altra directory, questo lo si fa perché in questo
 caso è possibile creare dei circoli nel filesystem (vedi
 
 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
 in alcuni filesystem solo l'amministratore è in grado di creare un
 collegamento diretto ad un'altra directory, questo lo si fa perché in questo
 caso è possibile creare dei circoli nel filesystem (vedi

-\secref{sec:file_symlink}) che molti programmi non sono in grado di
-gestire e la cui rimozione diventa estremamente complicata (in genere occorre
-far girare il programma \texttt{fsck} per riparare il filesystem); data la sua
+\secref{sec:file_symlink}) che molti programmi non sono in grado di gestire e
+la cui rimozione diventerebbe estremamente complicata (in genere occorre far
+girare il programma \cmd{fsck} per riparare il filesystem); data la sua

 pericolosità in generale nei filesystem usati in Linux questa caratteristica è
 pericolosità in generale nei filesystem usati in Linux questa caratteristica è

-stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}.
+stata disabilitata, e la funzione restituisce l'errore \macro{EPERM}.

 
 La rimozione di un file (o più precisamente della voce che lo referenzia) si
 
 La rimozione di un file (o più precisamente della voce che lo referenzia) si

-effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
+effettua con la funzione \func{unlink}; il suo prototipo è il seguente:

 
 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
   Cancella il nome specificato dal pathname nella relativa directory e
 
 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
   Cancella il nome specificato dal pathname nella relativa directory e

diff --git a/fileintro.tex b/fileintro.tex
index 479ff86bf653717444cc04653c5819336984ff5e..330f812b8a2a02dab3ebcc9bd94cbf10e93b93f9 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -391,32 +391,34 @@ file gi
 \label{sec:file_vfs_work}
 
 La funzione più fondamentale implementata dal VFS è la system call
 \label{sec:file_vfs_work}
 
 La funzione più fondamentale implementata dal VFS è la system call

-\texttt{open} che permette di aprire un file. Dato un pathname viene eseguita
+\func{open} che permette di aprire un file. Dato un pathname viene eseguita

 una ricerca dentro la \textit{directory entry cache} (in breve
 \textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
   entry} (in breve \textit{dentry}) che permette di associare in maniera
 rapida ed efficiente il pathname a una specifica dentry.
 
 una ricerca dentro la \textit{directory entry cache} (in breve
 \textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
   entry} (in breve \textit{dentry}) che permette di associare in maniera
 rapida ed efficiente il pathname a una specifica dentry.
 

-Una singola dentry contiene in genere il puntatore ad un \textit{inode};
-quest'ultimo è la struttura base che sta sul disco e che identifica un singolo
-oggetto del VFS sia esso un file ordinario, una directory, una FIFO, un file
-di dispositivo, o una qualsiasi altra cosa che possa essere rappresentata dal
-VFS (sui tipi di ``file'' possibili torneremo in seguito). A ciascuno di essi
-è associata pure una struttura che sta in memoria, e che oltre alle
-informazioni sullo specifico file contiene pure il riferimento alle funzioni
-(i \textsl{metodi}) da usare per poterlo manipolare.
-
-Le dentry ``vivono'' in memoria e non vengono mai salvate su disco, vengono
-usate per motivi di velocità, gli inode invece stanno su disco e vengono
-copiati in memoria quando serve, ed ogni cambiamento viene copiato
-all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS
-ed è ad essi che puntano le singole dentry.
-
-La dcache costituisce perciò una sorta di vista completa di tutto l'albero dei
-file, ovviamente per non riempire tutta la memoria questa vista è parziale
-(la dcache cioè contiene solo le dentry per i file per i quali è stato
-richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve
-creare una nuova dentry e caricare l'inode corrispondente in memoria. 
+Una singola \textit{dentry} contiene in genere il puntatore ad un
+\textit{inode}; quest'ultimo è la struttura base che sta sul 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, o una
+qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di
+``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure
+una struttura che sta in memoria, e che oltre alle informazioni sullo
+specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi})
+da usare per poterlo manipolare.
+
+Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
+vengono usate per motivi di velocità, gli inode invece stanno su disco e
+vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato
+all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed
+è ad essi che puntano le singole \textit{dentry}.
+
+La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
+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
+pathname il VFS deve creare una nuova \textit{dentry} e caricare l'inode
+corrispondente in memoria.

 
 Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode
 della directory che contiene il file; questo viene installato nelle relative
 
 Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode
 della directory che contiene il file; questo viene installato nelle relative


@@ -430,12 +432,12 @@ dell'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
 
 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

-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
-saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo
-torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle operazioni
-previste dal kernel è riportato in \ntab.
+\textit{dentry} e una struttura \var{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
+(su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
+operazioni previste dal kernel è riportato in \ntab.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -469,12 +471,12 @@ previste dal kernel 
 In questo modo per ciascun file diventano utilizzabili una serie di operazioni
 (non è dette che tutte siano disponibili), che costituiscono l'interfaccia
 astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
 In questo modo per ciascun file diventano utilizzabili una serie di operazioni
 (non è dette che tutte siano disponibili), che costituiscono l'interfaccia
 astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad

-utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo
+utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo

 di file in questione. 
 
 Così sarà possibile scrivere sulla porta seriale come su un file di dati
 normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
 di file in questione. 
 
 Così sarà possibile scrivere sulla porta seriale come su un file di dati
 normale; ovviamente certe operazioni (nel caso della seriale ad esempio la

-\textit{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
+\func{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.
 
 diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
 (relativamente) trasparente per l'utente ed il programmatore.
 


@@ -494,9 +496,9 @@ comuni di un qualunque filesystem standard unix.
 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
 partizione può contenere un filesystem; la strutturazione tipica
 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
 partizione può contenere un filesystem; la strutturazione tipica
 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento

-alla struttura del filesystem ext2, che prevede una separazione dei dati in
-\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di
-ext2 torneremo in \secref{sec:file_ext2}). È comunque caratteristica
+alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
+in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
+di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica

 comune di tutti i filesystem unix, indipendentemente da come poi viene
 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 comune di tutti i filesystem unix, indipendentemente da come poi viene
 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.


@@ -586,7 +588,7 @@ adesso sar
 \label{sec:file_ext2}
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
 \label{sec:file_ext2}
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended

-  filesystem}, identificato dalla sigla \textsl{ext2}. Esso supporta tutte le
+  filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le

 caratteristiche di un filesystem standard unix, è in grado di gestire
 filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 
 caratteristiche di un filesystem standard unix, è in grado di gestire
 filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 


@@ -604,9 +606,9 @@ seguenti:
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SYSV comporta che i file vengono creati con l'identificatore del
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SYSV comporta che i file vengono creati con l'identificatore del
   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
-  sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}.
+  di \acr{sgid} settato (per una descrizione dettagliata del significato di
+  questi termini si veda \secref{sec:file_access_control}), nel qual caso file
+  e sotto-directory 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).
 \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).


@@ -631,7 +633,6 @@ filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 superblock principale.
 
 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 superblock principale.
 

-

 \begin{figure}[htb]
   \centering
   \includegraphics[width=9cm]{img/dir_struct.eps}  
 \begin{figure}[htb]
   \centering
   \includegraphics[width=9cm]{img/dir_struct.eps}