Correzioni varie

diff --git a/filedir.tex b/filedir.tex
index 514705b61e32b47f3b97ad09cbdb42b964d65c2e..1964e7d38808d439f4e865805832723b51071365 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -61,8 +61,8 @@ astrazione che prevede quattro tipi di oggetti strettamente correlati: i
 filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
 corrispondono una serie di apposite strutture definite dal kernel che
 contengono come campi le funzioni di gestione e realizzano l'infrastruttura
 filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
 corrispondono una serie di apposite strutture definite dal kernel che
 contengono come campi le funzioni di gestione e realizzano l'infrastruttura

-del VFS. L'interfaccia è estremamente complessa, ne faremo pertanto una
-trattazione estremamente semplificata che consenta di comprenderne i principi
+del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione
+estremamente semplificata che consenta di comprenderne i principi

 difunzionamento.
 
 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
 difunzionamento.
 
 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun


@@ -88,14 +88,14 @@ verrà inserita nella tabella, ed il nuovo filesystem comparirà in
 La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
 come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
   viene riportato in \procfile{/proc/filesystems} e che viene usato come
 La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
 come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
   viene riportato in \procfile{/proc/filesystems} e che viene usato come

-  parametro dell'opzione \texttt{-t} del comando \texttt{mount}.}  contiene i
-riferimenti alle funzioni di base che consentono l'utilizzo di quel
-filesystem. In particolare la funzione \code{mount} del quarto campo è quella
-che verrà invocata tutte le volte che si dovrà effettuare il montaggio di un
-filesystem di quel tipo. Per ogni nuovo filesystem si dovrà allocare una di
-queste strutture ed inizializzare i relativi campi con i dati specifici diquel
-filesystem, ed in particolare si dovra creare anche la relativa versione della
-funzione \code{mount}.
+  valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che
+  indica il tipo di filesystem.}  contiene i riferimenti alle funzioni di base
+che consentono l'utilizzo di quel filesystem. In particolare la funzione
+\code{mount} del quarto campo è quella che verrà invocata tutte le volte che
+si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo
+filesystem si dovrà allocare una di queste strutture ed inizializzare i
+relativi campi con i dati specifici di quel filesystem, ed in particolare si
+dovrà creare anche la relativa versione della funzione \code{mount}.

 
 Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
 restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
 
 Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
 restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory


@@ -104,9 +104,10 @@ la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
 \textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
 vedremo a breve è l'oggetto usato dal kernel per identificare un un
 file.\footnote{in questo caso si parla di file come di un qualunque oggetto
 \textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
 vedremo a breve è l'oggetto usato dal kernel per identificare un un
 file.\footnote{in questo caso si parla di file come di un qualunque oggetto

-  generico che sta sul filesystem.} La \textit{dentry} ottenuta dalla chiamata
-alla funzione \code{mount} sarà inserita in corrispondenza al
-\textit{pathname} della directory in cui il filesystem è stato montato.
+  generico che sta sul filesystem e non dell'oggetto file del VFS cui
+  accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
+\code{mount} sarà inserita in corrispondenza al \textit{pathname} della
+directory in cui il filesystem è stato montato.

 
 % NOTA: struct dentry è dichiarata in include/linux/dcache.h
 
 
 % NOTA: struct dentry è dichiarata in include/linux/dcache.h
 


@@ -116,7 +117,7 @@ nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve
 \textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
 ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
   funzionamento della \textit{dcache} è in effetti di una delle parti più
 \textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
 ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
   funzionamento della \textit{dcache} è in effetti di una delle parti più

-  critiche per le prestazioni del sistema.} che a sua ci darà, tramite
+  critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite

 l'\textit{inode}, il riferimento al file.
 
 Dato che normalmente non è possibile mantenere nella \textit{dcache} le
 l'\textit{inode}, il riferimento al file.
 
 Dato che normalmente non è possibile mantenere nella \textit{dcache} le


@@ -190,10 +191,10 @@ una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può
 trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
 
 Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè
 trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
 
 Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè

-è un puntatore ad una funzione, e, come suggerisce il nome della struttura
-stessa, queste funzioni, le principali delle quali sono riportate in
-tab.~\ref{tab:file_inode_operations}) sono quelle che definiscono le
-operazioni che il VFS può compiere su un \textit{inode}.
+è un puntatore ad una funzione e, come suggerisce il nome della struttura
+stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS
+può compiere su un \textit{inode}. Si sono riportate in
+tab.~\ref{tab:file_inode_operations} le più rilevanti.

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


@@ -229,18 +230,19 @@ operazioni che il VFS può compiere su un \textit{inode}.
 
 Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
 identici alle varie \textit{system call} con le quali si gestiscono file e
 
 Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
 identici alle varie \textit{system call} con le quali si gestiscono file e

-directory che tratteremo nel resto del capitolo. Quello che succede è che
+directory, che tratteremo nel resto del capitolo. Quello che succede è che

 tutte le volte che deve essere eseguita una \textit{system call}, o una
 qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
 andrà ad utilizzare la funzione corrispondente attraverso il puntatore
 \var{i\_op}.
 
 Sarà allora sufficiente che nella realizzazione di un filesystem si crei una
 tutte le volte che deve essere eseguita una \textit{system call}, o una
 qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
 andrà ad utilizzare la funzione corrispondente attraverso il puntatore
 \var{i\_op}.
 
 Sarà allora sufficiente che nella realizzazione di un filesystem si crei una

-opportuna istanza di \kstruct{inode\_operation} contenente i puntatori alla
-implementazione di queste funzioni per quel filesystem e quel punto le
-strutture \kstruct{inode} usate per gli oggetti di quel filesystem otterranno
-il puntatore a detta istanza di \kstruct{inode\_operation} e verranno
-automaticamente usate le funzioni corrette.
+implementazione di queste funzioni per quel filesystem e si allochi una
+opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette
+funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di
+quel filesystem otterranno il puntatore alla relativa istanza di
+\kstruct{inode\_operation} e verranno automaticamente usate le funzioni
+corrette.

 
 Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
 funzione \texttt{open} che invece è citata in
 
 Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
 funzione \texttt{open} che invece è citata in


@@ -248,8 +250,9 @@ tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
   invocata dato che nella struttura \kstruct{inode} è presente anche il
   puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
   fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
   invocata dato che nella struttura \kstruct{inode} è presente anche il
   puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
   fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un

-file richiede comunque un'altra operazione: l'allocazione di una struttura di
-tipo \kstruct{file} che viene associata ad ogni file aperto nel sistema.
+file richiede comunque un'altra operazione che mette in gioco l'omonimo
+oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
+viene associata ad ogni file aperto nel sistema.

 
 I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
 come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
 
 I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
 come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le


@@ -327,7 +330,7 @@ stesso modo sulla porta seriale come su un normale file di dati, e lavorare
 sui file allo stesso modo indipendentemente dal filesystem.
 
 Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
 sui file allo stesso modo indipendentemente dal filesystem.
 
 Il VFS realizza la quasi totalità delle operazioni relative ai file grazie

-alle funzioni presenti nelle due strutture \kstruct{inode\_operation}
+alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e

 \kstruct{file\_operation}.  Ovviamente non è detto che tutte le operazioni
 possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek}
 non è realizzabile per un dispositivo come la porta seriale o per una fifo,
 \kstruct{file\_operation}.  Ovviamente non è detto che tutte le operazioni
 possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek}
 non è realizzabile per un dispositivo come la porta seriale o per una fifo,


@@ -352,34 +355,39 @@ proprie.  Per questo non entreremo nei dettagli di un filesystem specifico, ma
 daremo una descrizione a grandi linee che si adatta alle caratteristiche
 comuni di qualunque filesystem di un sistema unix-like.
 
 daremo una descrizione a grandi linee che si adatta alle caratteristiche
 comuni di qualunque filesystem di un sistema unix-like.
 

-Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. Una possibile strutturazione
-dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys},
-in essa per semplicità si è fatto riferimento alla struttura del filesystem
-\acr{ext2}, che prevede una separazione dei dati in \textit{block group} che
-replicano il cosiddetto \textit{superblock} (sulle caratteristiche di
-\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}). È comunque
-caratteristica comune di tutti i filesystem per Unix, indipendentemente da
-come poi viene strutturata nei dettagli questa informazione, prevedere una
-divisione fra la lista degli \itindex{inode} \textit{inode} e lo spazio a
-disposizione per i dati e le directory.\footnote{questo non è del tutto vero
-  per filesystem evoluti come \textsl{btrfs}, ma per il momento limitiamoci
-  alla implementazione classica.}
+Una possibile strutturazione dell'informazione su un disco è riportata in
+fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
+partizioni. In essa per semplicità si è fatto riferimento alla struttura del
+filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
+  group}.  All'interno di ciascun \textit{block group} viene anzitutto
+replicato il cosiddetto \textit{superblock}, (la struttura che contiene
+l'indice iniziale del filesystem e che consente di accedere a tutti i dati
+sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
+per accedere agli stessi.  Sulle caratteristiche di \acr{ext2} e derivati
+torneremo in sez.~\ref{sec:file_ext2}.
+
+È comunque caratteristica comune di tutti i filesystem per Unix,
+indipendentemente da come poi viene strutturata nei dettagli questa
+informazione, prevedere la presenza di due tipi di risorse: gli
+\itindex{inode} \textit{inode}, cui abbiamo già accennato in
+sez.~\ref{sec:file_vfs_work}, che sono le strutture che identificano i singoli
+oggetti sul filesystem, e i blocchi, che invece attengono allo spazio disco
+che viene messo a disposizione per i dati in essi contenuti.

 
 \begin{figure}[!htb]
   \centering
 
 \begin{figure}[!htb]
   \centering

-  \includegraphics[width=14cm]{img/disk_struct}
+  \includegraphics[width=12cm]{img/disk_struct}

   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}
 \end{figure}
 
 Se si va ad esaminare con maggiore dettaglio la strutturazione
   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}
 \end{figure}
 
 Se si va ad esaminare con maggiore dettaglio la strutturazione

-dell'informazione all'interno del singolo filesystem, tralasciando i dettagli
-relativi al funzionamento del filesystem stesso come la strutturazione in
-gruppi dei blocchi, il superblock e tutti i dati di gestione possiamo
-esemplificare la situazione con uno schema come quello esposto in
-fig.~\ref{fig:file_filesys_detail}.
+dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
+dettagli relativi al funzionamento del filesystem stesso come la
+strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
+gestione possiamo esemplificare la situazione con uno schema come quello
+esposto in fig.~\ref{fig:file_filesys_detail}.

 
 \begin{figure}[!htb]
   \centering
 
 \begin{figure}[!htb]
   \centering


@@ -389,24 +397,26 @@ fig.~\ref{fig:file_filesys_detail}.
 \end{figure}
 
 Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
 \end{figure}
 
 Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle

-caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
-visto che sono fondamentali per capire il funzionamento delle funzioni che
-manipolano i file e le directory che tratteremo nel prossimo capitolo; in
-particolare è opportuno ricordare sempre che:
+caratteristiche di base di un filesystem, che restano le stesse anche su
+filesystem la cui organizzazione dei dati è totalmente diversa da quella
+illustrata, e sulle quali è bene porre attenzione visto che sono fondamentali
+per capire il funzionamento delle funzioni che manipolano i file e le
+directory che tratteremo nel prosieguo del capitolo. In particolare è
+opportuno tenere sempre presente che:

 
 \begin{enumerate}
   
 
 \begin{enumerate}
   

-\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni (i
-  cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
+\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni, i
+  cosiddetti \textsl{metadati}, 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 \func{stat}
   (vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}.
   Dentro una directory si troverà solo il nome del file e il numero
   \itindex{inode} dell'\textit{inode} ad esso associato, cioè quella che da
   permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che
   contengono i dati e così via. Le informazioni che la funzione \func{stat}
   (vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}.
   Dentro una directory si troverà solo il nome del file e il numero
   \itindex{inode} dell'\textit{inode} ad esso associato, cioè quella che da

-  qui in poi chiameremo una \textsl{voce} (come traduzione dell'inglese
-  \textit{directory entry}, che non useremo anche per evitare confusione con
-  le \textit{dentry} del kernel di cui si parlava in
-  sez.~\ref{sec:file_vfs_work}).
+  qui in poi chiameremo una \textsl{voce}, che abbiamo scelto come traduzione
+  dell'inglese \textit{directory entry}, che non useremo anche per evitare
+  confusione con le \textit{dentry} del kernel di cui si parlava in
+  sez.~\ref{sec:file_vfs_work}.

   
 \item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
   
 \item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un


@@ -418,11 +428,13 @@ particolare è opportuno ricordare sempre che:
   file, ma si limita ad eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti \itindex{inode} nell'\textit{inode}.
   
   file, ma si limita ad eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti \itindex{inode} nell'\textit{inode}.
   

-\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
-  nello stesso filesystem e non ci può essere una directory che contiene
-  riferimenti ad \itindex{inode} \textit{inode} relativi ad altri filesystem.
-  Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
-  file esistente con la funzione \func{link}) al filesystem corrente.
+\item All'interno di ogni filesystem ogni \textit{inode} è identificato da un
+  numero univoco. Il numero di \textit{inode} nella voce si riferisce ad un
+  \textit{inode} a questo numero e non ci può essere una directory che
+  contiene riferimenti ad \itindex{inode} \textit{inode} relativi ad altri
+  filesystem.  Questo limita l'uso del comando \cmd{ln} (che crea una nuova
+  voce per un file esistente con la funzione \func{link}) al filesystem
+  corrente.

   
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
   
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una

diff --git a/img/dir_links.dia b/img/dir_links.dia
index 82ac44f90415efc35b77a068814b69248e74b688..7b0faf1c962344975a4c4c1faa3b56f61964de62 100644 (file)
Binary files a/img/dir_links.dia and b/img/dir_links.dia differ

diff --git a/img/filesys_struct.dia b/img/filesys_struct.dia
index f9562562f36fac45e83aa6a4cc7cffa570ee8c25..c08ed10d3f49d733d2b3915a880e2f3dda20eaec 100644 (file)
Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ

diff --git a/listati/file_system_type.h b/listati/file_system_type.h
index 4f4ceb90987b976ffd0bfafcfe9e4e05b67558f7..dabe30973751190f39f5f932a30c420cca7691a2 100644 (file)
--- a/listati/file_system_type.h
+++ b/listati/file_system_type.h
@@ -9,7 +9,5 @@ struct file_system_type {
         struct module *owner;
         struct file_system_type * next;
         struct list_head fs_supers;
         struct module *owner;
         struct file_system_type * next;
         struct list_head fs_supers;

-
-        struct lock_class_key s_lock_key;

         ...
 };
         ...
 };