Rimessi a posto tutti i riferimenti a figure e tabelle cancellando

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index 47e002c1c5373919527ef7a72bbb8be251bc15f5..794d61159b96fe74cb463c39be53c3697fbdc405 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -1,10 +1,11 @@
 \chapter{L'architettura dei file}
 \label{cha:file_intro}
 
 \chapter{L'architettura dei file}
 \label{cha:file_intro}
 

-Uno dei concetti fondamentali della architettura di unix è il cosiddetto
-\textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi
-di input/output del computer viene effettuato attraverso un'interfaccia
-astratta che tratta le periferiche allo stesso modo degli usuali file di dati.
+Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
+cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
+dispositivi di input/output del computer viene effettuato attraverso
+un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
+file di dati.

 
 Questo significa che si può accedere a qualunque periferica del computer,
 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
 
 Questo significa che si può accedere a qualunque periferica del computer,
 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i


@@ -13,127 +14,134 @@ speciali agendo sui quali i programmi possono leggere, scrivere e compiere
 operazioni direttamente sulle periferiche, usando le stesse funzioni che si
 usano per i normali file di dati.
 
 operazioni direttamente sulle periferiche, usando le stesse funzioni che si
 usano per i normali file di dati.
 

-In questo capitolo forniremo un'introduzione all'architettura della gestione
-dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che
-nelle particolarità che ha la specifica implementazione usata da Linux. Al
-contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
-varie caratteristiche distintive.
+In questo capitolo forniremo una descrizione dell'architettura dei file in
+Linux, iniziando da una panoramica sulle caratteristiche principali delle
+interfacce con cui i processi accedono ai file (che tratteremo in dettaglio
+nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
+delle modalità con cui detto accesso viene realizzato dal sistema.

 
 
 
 
 
 

-\section{L'organizzazione di file e directory}
-\label{sec:file_organization}
-
-Il primo passo nella trattazione dell'architettura della gestione dei file in
-un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
-di quale è la struttura che hanno all'interno del sistema.
-
+\section{L'architettura generale}
+\label{sec:file_access_arch}

 
 

-\subsection{La struttura di file e directory}
-\label{sec:file_file_struct}
+Per poter accedere ai file, il kernel deve mettere a disposizione dei
+programmi le opportune interfacce che consentano di leggerne il contenuto; il
+sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
+opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
+Questo viene fatto strutturando l'informazione sul disco attraverso quello che
+si chiama un \textit{filesystem} (vedi \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 \secref{sec:file_arch_func}).

 
 

-Partiamo allora da come viene strutturata nel sistema la disposizione dei
-file: per potervi accedere il kernel usa una apposita interfaccia che permetta
-di accedere all'informazione tenuta sullo spazio grezzo disponibile sui
-dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
-  brevità questo nome al posto della più prolissa traduzione italiana sistema
-  di file}, che descriveremo in dettaglio in \secref{sec:file_vfs}.
+In questa sezione faremo una panormamica 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.

 
 

-Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
-memorizzati all'interno del disco stesso, strutturando l'informazione in file
-e directory.  Per poter accedere ai file contenuti in un disco occorrerà
-perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco
-(o la partizione del disco).

 
 

-%In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
-%informazioni riservate che tengono conto degli inodes allocati, di quelli
-%liberi, e delle posizioni fisiche su disco dei dati contenuti nei file, per
-
-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 (la directory
-di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato
-dall'utente usando quello che viene chiamato \textit{pathname}, cioè il
-percorso che si deve fare per accedere al file.
+\subsection{L'organizzazione di file e directory}
+\label{sec:file_organization}

 
 

-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 \file{/}); tutti gli ulteriori dischi devono poi essere inseriti
-nell'albero utilizzando opportune subdirectory.
+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
+viene identificato dall'utente usando quello che viene chiamato
+\textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa
+  nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
+  un insieme di directory su cui effettuare una ricerca (come quello in cui si
+  cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e
+  di componente per il nome del file all'interno della directory. Non
+  seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
+  ormai così comune che mantenerne l'uso è senz'altro più chiaro
+  dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
+al file a partire dalla \textit{root directory}, che è composto da 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
+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
+nell'albero montandoli su opportune directory del filesystem montato come
+radice.

 
 Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
 alcune strutture interne del kernel) sono generati automaticamente dal kernel
 
 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 file come le FIFO, i
-link, i socket e gli stessi i file di dispositivo (questi ultimi, per
-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à
-specificato in \secref{sec:file_vfs}, è solo un particolare tipo di file
-che contiene le informazioni che associano un nome al contenuto.
-
-% Per questo, anche se è usuale parlare di ``file in una directory'' in realtà
-% una directory contiene solo delle etichette per fare riferimento ai file
-% stessi.
-
-I manuale delle glibc chiama i nomi contenuti nelle directory
-\textsl{componenti} (in inglese \textit{file name components}), noi li
-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 nomi separati da
-una \file{/} (in Linux più \file{/} 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
+stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
+
+Una directory, come vedremo in maggior dettaglio in
+\secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+particolare che il kernel riconosce come tale. Il suo scopo è quello di
+contenere una lista di nomi di file e le informazioni che associano ciascun
+nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
+oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
+un'organizzazione ad albero inserendo directory in altre directory.
+
+Un file può essere indicato rispetto alla directory corrente semplicemente
+specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
+  contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
+    components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
+contenuto.  All'interno dello stesso albero si potranno poi inserire anche
+tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
+come le fifo, i link, i socket e gli stessi i file di dispositivo (questi
+ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
+
+Il nome completo di un file viene chiamato \textit{pathname} ed il
+procedimento con cui si individua il file a cui esso fa riferimento è chiamato

 risoluzione del nome (\textit{file name resolution} o \textit{pathname
 risoluzione del nome (\textit{file name resolution} o \textit{pathname

-  resolution}).  La risoluzione viene fatta esaminando il pathname da destra a
-sinistra e localizzando ogni nome nella directory indicata dal nome
-precedente: ovviamente perché il procedimento funzioni occorre che i nomi
-indicati come directory esistano e siano effettivamente directory, inoltre i
-permessi devono consentire l'accesso.
-
-Se il pathname comincia per \file{/} la ricerca parte dalla directory radice
-del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
-seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
-equivale alla directory radice dell'albero (come descritto in
-\secref{sec:file_organization}): in questo caso si parla di un pathname
-\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
-cui torneremo più avanti in \secref{sec:file_work_dir}) ed il pathname è
-detto \textsl{relativo}.
+  resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
+sinistra a destra e localizzando ogni nome nella directory indicata dal nome
+precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
+  costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
+perché il procedimento funzioni, occorre che i nomi indicati come directory
+esistano e siano effettivamente directory, inoltre i permessi (si veda
+\secref{sec:file_access_control}) devono consentire l'accesso all'intero
+\textit{pathname}.
+
+Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
+radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
+\secref{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{pathname assoluto}. Altrimenti la ricerca
+parte dalla directory corrente (su cui torneremo in
+\secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
+  relativo}\index{pathname relativo}.

 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 
 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.
+in ogni directory: il primo fa riferimento alla directory corrente e il
+secondo alla directory \textsl{genitrice} (o \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 file}
 \label{sec:file_file_types}
 
 
 
 \subsection{I tipi di file}
 \label{sec:file_file_types}
 

-Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
+Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi

 sono implementati come oggetti del \textit{Virtual File System} (vedi
 sono implementati come oggetti del \textit{Virtual File System} (vedi

-\secref{sec:file_vfs}) e sono presenti in tutti i filesystem unix-like
-utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual
-File System è riportato in \ntab.
+\secref{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{Virtual File System} è riportato in
+\tabref{tab:file_file_types}.

 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con

-la classificazione sui tipi di file (che in questo caso sono sempre file di
-dati) in base al loro contenuto, o tipo di accesso.
+la classificazione dei file (che in questo caso sono sempre file di dati) in
+base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
+oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
+Alcuni di essi, come le \textit{fifo} (che tratteremo in
+\secref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
+\capref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
+delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
+\textsl{file di dispositivo} (o \textit{device file}) che costituiscono una
+interfaccia diretta per leggere e scrivere sui dispositivi fisici; essi
+vengono suddivisi in due grandi categorie, \textsl{a blocchi} e \textsl{a
+  caratteri} a seconda delle modalità in cui il dispositivo sottostante
+effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi
+  (ad esempio i dischi) corrispondono a periferiche per le quali è richiesto
+  che l'I/O venga effettuato per blocchi di dati di dimensioni fissate (ad
+  esempio le dimensioni di un settore), mentre nei dispositivi a caratteri
+  l'I/O viene effettuato senza nessuna particolare struttura.}

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


@@ -143,20 +151,21 @@ dati) in base al loro contenuto, o tipo di accesso.
     \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
     \hline
     \hline
     \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
     \hline
     \hline

-      \textit{regular file} & \textsl{file normale} &
+      \textit{regular file} & \textsl{file regolare} &

       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &

-      un file che contiene una lista di nomi associati a degli inodes \\
+      un file che contiene una lista di nomi associati a degli \textit{inodes}
+      (vedi \secref{sec:file_vfs}).  \\

       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &

-      un file che identifica una periferica ad accesso sequenziale \\
+      un file che identifica una periferica ad accesso a caratteri \\

       \textit{block device} & \textsl{dispositivo a blocchi} &
       \textit{block device} & \textsl{dispositivo a blocchi} &

-      un file che identifica una periferica ad accesso diretto \\
-      \textit{fifo} & \textsl{tubo} &
+      un file che identifica una periferica ad accesso a blocchi \\
+      \textit{fifo} & \textsl{``coda''} &

       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\
       un file speciale che identifica una linea di comunicazione software
       (unidirezionale) \\

-      \textit{socket} & \textsl{manicotto} &
+      \textit{socket} & \textsl{``presa''} &

       un file speciale che identifica una linea di comunicazione software
       (bidirezionale) \\
     \hline
       un file speciale che identifica una linea di comunicazione software
       (bidirezionale) \\
     \hline


@@ -165,161 +174,181 @@ dati) in base al loro contenuto, o tipo di accesso.
     \label{tab:file_file_types}
 \end{table}
 
     \label{tab:file_file_types}
 \end{table}
 

-Infatti una delle differenze principali con altri sistemi operativi (come il
-VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
-un 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{con i
-  kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi
-  (il \textit{raw access}) attraverso dei device file appositi, che però non
-  ha nulla a che fare con questo}.
-
-Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
-codificata in maniera diversa da Windows o Mac, in particolare il fine
-riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
-(\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
+Una delle differenze principali con altri sistemi operativi (come il VMS o
+Windows) è che per Unix tutti i file di dati sono identici e contengono un
+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 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).}
+
+Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
+codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
+il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
+del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
+  dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una
+  conversione fra questi due formati di testo.} Questo può causare alcuni

 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 

+Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
+tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
+estensioni come parte del filesystem.\footnote{non è così ad esempio nel
+  filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
+  che specificano fra l'altro il contenuto ed il programma da usare per
+  leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la
+  possibilità di associare delle risorse ai file, ma è una caratteristica
+  tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei
+  file in un sistema Unix.} Ciò nonostante molti programmi adottano delle
+convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
+in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di
+utilizzare i primi 4 byte del file per memorizzare un \textit{magic number}
+che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed
+accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
+demandato alle applicazioni stesse.
+

 
 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 
 
 \subsection{Le due interfacce ai file}
 \label{sec:file_io_api}
 

-In unix le modalità di accesso ai file e le relative interfacce di
+In Linux le modalità di accesso ai file e le relative interfacce di

 programmazione sono due, basate su due diversi meccanismi con cui è possibile
 accedere al loro contenuto.
 
 programmazione sono due, basate su due diversi meccanismi con cui è possibile
 accedere al loro contenuto.
 

-La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
-chiama interfaccia dei descrittori di file (o \textit{file descriptor}).  È
-un'interfaccia specifica di unix e provvede un accesso non bufferizzato, la
-tratteremo in dettaglio in \capref{cha:file_unix_interface}.
+La prima è l'interfaccia standard di Unix, quella che il manuale delle
+\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
+  descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce 
+un accesso non bufferizzato; la tratteremo in dettaglio in
+\capref{cha:file_unix_interface}.

 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 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
 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 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 descriptor sono rappresentati da numeri interi (cioè
-semplici variabili di tipo \type{int}).  L'interfaccia è definita
-nell'header \file{unistd.h}.
+dispositivi); i \textit{file descriptor}\index{file descriptor} sono
+rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{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
-(controllato dalla implementazione fatta dalle librerie del C), la tratteremo
-in dettaglio in \capref{cha:files_std_interface}.
+La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
+\textit{stream}\index{stream}. Essa fornisce funzioni più evolute e un accesso
+bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
+tratteremo in dettaglio nel \capref{cha:files_std_interface}.

 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova

-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
-\type{FILE *}.  L'interfaccia è definita nell'header \type{stdio.h}.
+anche su tutti i sistemi non Unix. Gli \textit{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 \ctyp{FILE *}.  L'interfaccia è definita nell'header \file{stdio.h}.

 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli

-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 descriptor. Allo stesso modo
-devono essere usati i file descriptor se si vuole ricorrere a modalità
-speciali di I/O come il polling o il non-bloccante (vedi
-\secref{sec:file_noblocking}).
-
-Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
-dei file descriptor, che tratta tutti i file nello stesso modo, con
-l'eccezione di poter scegliere tra diversi stili di bufferizzazione.  Il
-maggior vantaggio degli stream è che l'interfaccia per le operazioni di
-input/output è enormemente più ricca di quella dei file descriptor, che
-provvedono solo funzioni elementari per la lettura/scrittura diretta di
-blocchi di byte.  In particolare gli stream dispongono di tutte le funzioni
-di formattazione per l'input e l'output adatte per manipolare anche i dati in
+altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio
+a tempo opportuno), ma per poter accedere alle operazioni di controllo
+(descritte in \ref{sec:file_fcntl} e \ref{sec:file_ioctl}) su un qualunque
+tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix con i
+\textit{file descriptor}. Allo stesso modo devono essere usati i \textit{file
+  descriptor} se si vuole ricorrere a modalità speciali di I/O come il polling
+o il non-bloccante (vedi \capref{cha:file_advanced}).
+
+Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
+quella dei \textit{file descriptor}, che permette di poter scegliere tra
+diversi stili di bufferizzazione.  Il maggior vantaggio degli \textit{stream}
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+di quella dei \textit{file descriptor}, che forniscono solo funzioni
+elementari per la lettura/scrittura diretta di blocchi di byte.  In
+particolare gli \textit{stream} dispongono di tutte le funzioni di
+formattazione per l'input e l'output adatte per manipolare anche i dati in

 forma di linee o singoli caratteri.
 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
 forma di linee o singoli caratteri.
 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia

-standard di unix, è sempre possibile estrarre il file descriptor da uno stream
-ed eseguirvi operazioni di basso livello, o associare in un secondo tempo uno
-stream ad un file descriptor.
+standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
+uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
+tempo uno \textit{stream} ad un \textit{file descriptor}.

 
 In generale, se non necessitano specificatamente le funzionalità di basso
 
 In generale, se non necessitano specificatamente le funzionalità di basso

-livello, è opportuno usare sempre gli stream per la loro maggiore portabilità
-essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file
-descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è
-pertanto di portabilità più limitata.
-
-
-\subsection{Caratteristiche specifiche dei file in unix}
-\label{sec:fileint_unix_spec}
-
-Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-specifiche di un sistema unix-like che devono essere tenute in conto
-nell'accesso ai file. È infatti normale che più processi o programmi possano
-accedere contemporaneamente allo stesso file e devono poter eseguire le loro
-operazioni indipendentemente da quello che fanno gli altri processi.
-
-Per questo motivo le strutture usate per all'accesso ai file sono relative al
-processo che effettua l'accesso.  All'apertura di ogni file infatti viene
-creata all'interno del processo una apposita struttura in cui sono memorizzati
-tutti gli attributi del medesimo, che viene utilizzata per tutte le
-operazioni. Questa è una struttura che resta locale al processo stesso; in
-questo modo processi diversi possono usare le proprie strutture locali per
-accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
-indipendente.
-
-Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
-sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
-file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
-successiva. Essa è rappresentata da un numero intero che indica il numero di
-byte dall'inizio del file, che viene (a meno che non si apra il file in
-append) inizializzato a zero all'apertura del medesimo.
-
-Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
-ogni processo avrà la sua posizione corrente nel file, che non sarà
-influenzata da quello che altri processi possono fare. Anzi, aprire un file
-significa appunto creare ed inizializzare una tale struttura, per cui se si
-apre due volte lo stesso file all'interno dello stesso processo, si otterranno
-due file descriptor o due stream che avranno ancora una posizione corrente nel
-file assolutamente indipendente.
-
-Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
-accesso è un riferimento all'inode del file, pertanto anche se il file viene
-cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
-dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
-cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
-file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
-saranno disponibili per tutto il tempo in cui il processo è attivo.
-
-Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
-esaminando in dettaglio come tutto ciò viene realizzato.
-
-Si ricordi infine che in ambiente unix non esistono i tipi di file e che non
-c'è nessun supporto per le estensioni come parte del filesystem. Ciò non
-ostante molti programmi adottano delle convenzioni per i nomi dei file, ad
-esempio il codice C normalmente si mette in file con l'estensione .c, ma
-questa è, appunto, solo una convenzione.
+livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
+portabilità, essendo questi ultimi definiti nello standard ANSI C;
+l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
+POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
+
+
+% \subsection{Caratteristiche specifiche dei file in Unix}
+% \label{sec:fileint_unix_spec}
+
+% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
+% specifiche di un sistema unix-like che devono essere tenute in conto
+% nell'accesso ai file. È infatti normale che più processi o programmi possano
+% accedere contemporaneamente allo stesso file e devono poter eseguire le loro
+% operazioni indipendentemente da quello che fanno gli altri processi.
+
+% Per questo motivo le strutture usate per all'accesso ai file sono relative al
+% processo che effettua l'accesso.  All'apertura di ogni file infatti viene
+% creata all'interno del processo una apposita struttura in cui sono memorizzati
+% tutti gli attributi del medesimo, che viene utilizzata per tutte le
+% operazioni. Questa è una struttura che resta locale al processo stesso; in
+% questo modo processi diversi possono usare le proprie strutture locali per
+% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
+% indipendente.
+
+% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
+% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
+% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
+% successiva. Essa è rappresentata da un numero intero che indica il numero di
+% byte dall'inizio del file, che viene (a meno che non si apra il file in
+% append) inizializzato a zero all'apertura del medesimo.
+
+% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
+% ogni processo avrà la sua posizione corrente nel file, che non sarà
+% influenzata da quello che altri processi possono fare. Anzi, aprire un file
+% significa appunto creare ed inizializzare una tale struttura, per cui se si
+% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
+% due file descriptor o due stream che avranno ancora una posizione corrente nel
+% file assolutamente indipendente.
+
+% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
+% accesso è un riferimento all'inode del file, pertanto anche se il file viene
+% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
+% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
+% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+% in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
+% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+% saranno disponibili per tutto il tempo in cui il processo è attivo.
+
+% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
+% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
+% realizzato.

 
 
 \section{L'architettura della gestione dei file}
 
 
 \section{L'architettura della gestione dei file}

-\label{sec:file_architecture}
+\label{sec:file_arch_func}

 
 Per capire fino in fondo le proprietà di file e directory in un sistema
 
 Per capire fino in fondo le proprietà di file e directory in un sistema

-unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
-una breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è
-basato un filesystem di tipo unix. 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}.
+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}.

 
 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

-poi in maniera un po' più dettagliata il filesystem standard di Linux,
-l'\acr{ext2}, come esempio di un filesystem unix-like.
+prima le caratteristiche generali di un filesystem di un sistema unix-like,
+per poi trattare in maniera un po' più dettagliata il filesystem standard di
+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
+% \secref{sec:file_vfs}.

 
 

-% 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 \secref{sec:file_vfs}.

 
 

-
-\subsection{Il \textit{virtual filesystem} di Linux}
+\subsection{Il \textit{Virtual Filesystem} di Linux}

 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i


@@ -329,32 +358,35 @@ l'\acr{ext2}, come esempio di un filesystem unix-like.
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato

-attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è
-l'interfaccia che il kernel rende disponibile ai programmi in user space
-attraverso la quale vengono manipolati i file; esso provvede un livello di
-indirezione che permette di collegare le operazioni di manipolazione sui file
-alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
-modi in cui diversi filesystem la 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
+attraverso il \textit{Virtual Filesystem} (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
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le

-manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alla
+manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle

 opportune routine del filesystem specifico a cui si fa riferimento. Saranno
 queste a chiamare le funzioni di più basso livello che eseguono le operazioni
 opportune routine del filesystem specifico a cui si fa riferimento. Saranno
 queste a chiamare le funzioni di più basso livello che eseguono le operazioni

-di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.
+di I/O sul dispositivo fisico, secondo lo schema riportato in
+\figref{fig:file_VFS_scheme}.

 
 \begin{figure}[htb]
   \centering
   \includegraphics[width=7cm]{img/vfs}
 
 \begin{figure}[htb]
   \centering
   \includegraphics[width=7cm]{img/vfs}

-  \caption{Schema delle operazioni del VFS}
+  \caption{Schema delle operazioni del VFS.}

   \label{fig:file_VFS_scheme}
 \end{figure}
 
 Il VFS definisce un insieme di funzioni che tutti i filesystem devono
   \label{fig:file_VFS_scheme}
 \end{figure}
 
 Il VFS definisce un insieme di funzioni che tutti i filesystem devono

-implementare. L'interfaccia comprende tutte le funzioni che riguardano i
-file; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode
-e file, corrispondenti a tre apposite strutture definite nel kernel.
+implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
+le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
+\textit{inode} e \textit{file}, corrispondenti a tre apposite strutture
+definite nel kernel.

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


@@ -363,22 +395,21 @@ filesystem tutto quello che occorre 
 (\var{file\_system\_type}) che contiene i dettagli per il riferimento
 all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
 
 (\var{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
 (o qualunque altro \textit{block device} che può contenere un filesystem), il
 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
 (o qualunque altro \textit{block device} che può contenere un filesystem), il
 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco

-il superblock (vedi \ref{sec:file_ext2}), inizializzare tutte le
-variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possibile accedere alle routine
-specifiche per l'uso di quel filesystem.
+il superblock (vedi \secref{sec:file_ext2}), inizializzare tutte le variabili
+interne e restituire uno speciale descrittore dei filesystem montati al VFS;
+attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
+l'uso di quel filesystem.

 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così

-usare le funzioni contenute nel filesystem descriptor per accedere alle routine
-specifiche di quel filesystem.
+usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
+alle routine specifiche di quel filesystem.

 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni


@@ -393,28 +424,28 @@ file gi
 \subsection{Il funzionamento del VFS}
 \label{sec:file_vfs_work}
 
 \subsection{Il funzionamento del VFS}
 \label{sec:file_vfs_work}
 

-La funzione più fondamentale implementata dal VFS è la system call
-\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.
+La funzione più importante implementata dal VFS è la system call \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 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 \textit{dentry}.

 
 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
 
 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.
+qualsiasi altra cosa che possa 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) da usare per poterlo manipolare.

 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
 
 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}.
+vengono usate per motivi di velocità, gli \textit{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 è
 
 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 è


@@ -428,9 +459,9 @@ 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.
 
 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
-\func{open} per aprire il file o la \func{stat} per leggere i dati
+Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
+\textit{inode}) diventa possibile accedere alle varie operazioni sul file come
+la \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
 dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di


@@ -440,76 +471,83 @@ 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
 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.
+operazioni previste dal kernel è riportato in
+\tabref{tab:file_file_operations}.

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

-  \begin{tabular}[c]{|l|p{7cm}|}
+  \begin{tabular}[c]{|l|p{8cm}|}

     \hline
     \textbf{Funzione} & \textbf{Operazione} \\
     \hline
     \hline
     \hline
     \textbf{Funzione} & \textbf{Operazione} \\
     \hline
     \hline

-    \textsl{\code{open}}   & apre il file \\
-    \textsl{\code{read}}   & legge dal file \\
-    \textsl{\code{write}}  & scrive sul file \\ 
-    \textsl{\code{llseek}} & sposta la posizione corrente sul file \\
+    \textsl{\code{open}}   & apre il file (vedi \secref{sec:file_open}). \\
+    \textsl{\code{read}}   & legge dal file (vedi \secref{sec:file_read}).\\
+    \textsl{\code{write}}  & scrive sul file (vedi \secref{sec:file_write}).\\ 
+    \textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi
+                             \secref{sec:file_lseek}). \\

     \textsl{\code{ioctl}}  & accede alle operazioni di controllo 
     \textsl{\code{ioctl}}  & accede alle operazioni di controllo 

-                       (tramite la \func{ioctl})\\
-    \textsl{\code{readdir}}& per leggere il contenuto di una directory \\
-    \textsl{\code{poll}}   & \\
-    \textsl{\code{mmap}}   & chiamata dalla system call \func{mmap}. 
-                       mappa il file in memoria\\
+                             (vedi \secref{sec:file_ioctl}).\\
+    \textsl{\code{readdir}}& legge il contenuto di una directory \\
+    \textsl{\code{poll}}   & usata nell'I/O multiplexing (vedi
+                             \secref{sec:file_multiplexing}). \\
+    \textsl{\code{mmap}}   & mappa il file in memoria (vedi 
+                             \secref{sec:file_memory_map}). \\

     \textsl{\code{release}}& chiamata quando l'ultima referenza a un file 
     \textsl{\code{release}}& chiamata quando l'ultima referenza a un file 

-                       aperto è chiusa\\
-    \textsl{\code{fsync}}  & chiamata dalla system call \func{fsync} \\
-    \textsl{\code{fasync}} & chiamate da \func{fcntl} quando è abilitato 
-                           il modo asincrono per l'I/O su file. \\
+                             aperto è chiusa. \\
+    \textsl{\code{fsync}}  & sincronizza il contenuto del file (vedi
+                             \secref{sec:file_sync}). \\
+    \textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
+                             \secref{sec:file_asyncronous_io}) sul file. \\

     \hline
   \end{tabular}
   \caption{Operazioni sui file definite nel VFS.}
   \label{tab:file_file_operations}
 \end{table}
 
     \hline
   \end{tabular}
   \caption{Operazioni sui file definite nel VFS.}
   \label{tab:file_file_operations}
 \end{table}
 

-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 \var{f\_ops} appropriata al tipo
-di file in questione. 
+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.

 
 

-Così sarà possibile scrivere sulla porta seriale come su un file di dati
-normale; 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.
+In questo modo è 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 l'utilizzo di diversi filesystem (come quelli usati da Windows o
+MacOs) è immediato e (relativamente) trasparente per l'utente ed il
+programmatore.

 
 
 
 

-\subsection{Il funzionamento di un filesystem unix}
+\subsection{Il funzionamento di un filesystem Unix}

 \label{sec:file_filesystem}
 
 \label{sec:file_filesystem}
 

-Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
-in generale) organizza i dati che tiene su disco attraverso l'uso di un
-filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
-quella di poter supportare grazie al VFS una enorme quantità di filesystem
+Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
+unix-like) organizza i dati che tiene su disco attraverso l'uso di un
+filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
+quella di poter supportare, grazie al VFS, una enorme quantità di filesystem

 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità

-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 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
-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.
+proprie.  Per questo, per il momento 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 sistema unix-like.
+
+Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
+partizione può contenere un filesystem. La strutturazione tipica
+dell'informazione su un disco è riportata in \figref{fig:file_disk_filesys};
+in essa si fa riferimento 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 per 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.

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

-  \includegraphics[width=9cm]{img/disk_struct}
-  \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
+  \includegraphics[width=14cm]{img/disk_struct}
+  \caption{Organizzazione dello spazio su un disco in partizioni e
+  filesystem.}

   \label{fig:file_disk_filesys}
 \end{figure}
 
   \label{fig:file_disk_filesys}
 \end{figure}
 


@@ -517,19 +555,21 @@ 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
 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 \nfig.
+esemplificare la situazione con uno schema come quello esposto in
+\figref{fig:file_filesys_detail}.

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

-  \includegraphics[width=11cm]{img/filesys_struct}
-  \caption{Strutturazione dei dati all'interno di un filesystem}
+  \includegraphics[width=14cm]{img/filesys_struct}
+  \caption{Strutturazione dei dati all'interno di un filesystem.}

   \label{fig:file_filesys_detail}
 \end{figure}
 
   \label{fig:file_filesys_detail}
 \end{figure}
 

-Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
-cui è bene porre attenzione in quanto sono fondamentali per capire il
-funzionamento delle funzioni che manipolano i file e le directory su cui
-torneremo in seguito; in particolare è opportuno ricordare sempre che:
+Da \figref{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:

 
 \begin{enumerate}
   
 
 \begin{enumerate}
   


@@ -538,44 +578,45 @@ torneremo in seguito; in particolare 
   fisici che contengono i dati e così via; le informazioni che la funzione
   \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
   fisici che contengono i dati e così via; le informazioni che la funzione
   \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{dentry} del kernel di
-  cui si parlava in \secref{sec:file_vfs}).
-  
-\item Come mostrato in \curfig si possono avere più voci che puntano allo
-  stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
-  numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
-  solo quando questo contatore si annulla i dati del file vengono
-  effettivamente rimossi dal disco. Per questo la funzione per cancellare un
-  file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
-  file, ma si limita a eliminare la relativa voce da una directory e
-  decrementare il numero di riferimenti nell'\textit{inode}.
+  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
+  \secref{sec:file_vfs}).

   
   

+\item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
+  voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
+  contatore che contiene il numero di riferimenti (\textit{link count}) che
+  sono stati fatti ad esso; solo quando questo contatore si annulla i dati del
+  file vengono effettivamente rimossi dal disco. Per questo la funzione per
+  cancellare un file si chiama \func{unlink}, ed in realtà non cancella
+  affatto i dati del file, ma si limita ad eliminare la relativa voce da una
+  directory e decrementare il numero di riferimenti 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 \textit{inodes} 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 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 \textit{inodes} 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 deve essere spostato, viene semplicemente creata una nuova voce
-  per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
-  in cui opera normalmente il comando \cmd{mv} attraverso la funzione
-  \func{rename}).
+\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
+  del file non viene spostato fisicamente, viene semplicemente creata una
+  nuova voce per l'\textit{inode} in questione e rimossa la vecchia (questa è
+  la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
+  funzione \func{rename}).

 
 \end{enumerate}
 
 
 \end{enumerate}
 

-Infine è bene avere presente che essendo file pure loro, esiste un numero di
-riferimenti anche per le directory; per cui se ad esempio a partire dalla
-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.
+Infine è bene avere presente che, essendo file pure loro, esiste un numero di
+riferimenti anche per le directory; per cui, se a partire dalla situazione
+mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory
+\file{img} nella directory \file{gapil}, avremo una situazione come quella in
+\figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di
+inode.

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

-  \includegraphics[width=11cm]{img/dir_links}
-  \caption{Organizzazione dei link per le directory}
+  \includegraphics[width=14cm]{img/dir_links}
+  \caption{Organizzazione dei link per le directory.}

   \label{fig:file_dirs_link}
 \end{figure}
 
   \label{fig:file_dirs_link}
 \end{figure}
 


@@ -583,8 +624,8 @@ La nuova directory avr
 è referenziata dalla directory da cui si era partiti (in cui è inserita la
 nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
 è referenziata dalla directory da cui si era partiti (in cui è inserita la
 nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
 che è sempre inserita in ogni directory; questo vale sempre per ogni directory

-che non contenga a sua volta altre directory. Al contempo la directory da
-cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
+che non contenga a sua volta altre directory. Al contempo, la directory da
+cui si era partiti avrà un numero di riferimenti di almeno tre, in quanto

 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
 
 
 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
 
 


@@ -593,16 +634,15 @@ adesso sar
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 
 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
-filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
-4~Tb. 
+caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
+file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di
+4~Tb.

 
 

-Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
-che non sono presenti sugli altri filesystem unix, le cui principali sono le
-seguenti:
+Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
+non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:

 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del

-  kernel quando agisce su gruppi di file. Possono essere settati su file e
+  kernel quando agisce su gruppi di file. Possono essere impostati su file e

   directory e in quest'ultimo caso i nuovi file creati nella directory
   ereditano i suoi attributi.
 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
   directory e in quest'ultimo caso i nuovi file creati nella directory
   ereditano i suoi attributi.
 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di


@@ -610,7 +650,7 @@ seguenti:
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SVr4 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 SVr4 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 \acr{sgid} settato (per una descrizione dettagliata del significato di
+  di \acr{sgid} impostato (per una descrizione dettagliata del significato di

   questi termini si veda \secref{sec:file_access_control}), nel qual caso file
   e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   questi termini si veda \secref{sec:file_access_control}), nel qual caso file
   e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem


@@ -627,7 +667,7 @@ seguenti:
   log).
 \end{itemize}
 
   log).
 \end{itemize}
 

-La struttura di \acr{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.
 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.


@@ -650,9 +690,14 @@ inode.
 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua
 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua

-lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
-in questo modo è possibile implementare nomi per i file anche molto lunghi
-(fino a 1024 caratteri) senza sprecare spazio disco.
+lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
+\figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per
+i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.
+

 
 
 
 
 
 

+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: