% fileintro.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Prefazione",
\textsl{montaggio} del \textit{filesystem}.
% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
-In questa sezione faremo una panormamica generica su come il sistema presenta
+In questa sezione faremo una panoramica generica su come il sistema presenta
i file ai processi, trattando l'organizzazione di file e directory, i tipi di
file ed introducendo le interfacce disponibili e le loro caratteristiche.
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
+riceve dal bootloader 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
un file che identifica una periferica ad accesso a caratteri \\
\textit{block device} & \textsl{dispositivo a blocchi} &
un file che identifica una periferica ad accesso a blocchi \\
- \textit{fifo} & \textsl{``coda''} &
+ \textit{fifo} & ``\textsl{coda}'' &
un file speciale che identifica una linea di comunicazione software
unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\
- \textit{socket}\index{socket} & \textsl{``presa''} &
+ \textit{socket}\index{socket} & ``\textsl{presa}''&
un file speciale che identifica una linea di comunicazione software
bidirezionale (vedi \capref{cha:socket_intro}) \\
\hline
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
+il cosiddetto ``\textsl{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\index{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).}
\section{L'architettura della gestione dei file}
\label{sec:file_arch_func}
-Per capire fino in fondo le proprietà di file e directory in un sistema
-unix-like ed il comportamento delle relative funzioni di manipolazione,
-occorre una breve introduzione al funzionamento 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}.
+%% Per capire fino in fondo le proprietà di file e directory in un sistema
+%% unix-like ed il comportamento delle relative funzioni di manipolazione,
+%% occorre una breve introduzione al funzionamento della gestione dei file da
+%% parte del kernel e sugli oggetti su cui è basato un filesystem. In particolare
+%% occorre tenere presente dov'è che si situa la divisione fondamentale fra
+%% kernel space e user space che tracciavamo al \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
filesystem supportato: quando si vuole inserire il supporto di un nuovo
filesystem tutto quello che occorre è chiamare la funzione
\code{register\_filesystem} passandole un'apposita struttura
-(\var{file\_system\_type}) che contiene i dettagli per il riferimento
+\code{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
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\index{file!di dispositivo}, o una qualsiasi altra cosa che possa
-essere rappresentata dal VFS (i tipi di ``file'' riportati in
+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)
dell'inode\index{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
-\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
+una struttura di tipo \struct{file} in cui viene inserito un puntatore alla
+\textit{dentry} e una struttura \struct{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
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.
+utilizzare l'opportuna routine dichiarata in \struct{f\_ops} appropriata al
+tipo di file in questione.
-Pertanto è 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
+Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
+normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
+esempio la \code{seek}) non saranno disponibili, però con questo sistema
l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
immediato e (relativamente) trasparente per l'utente ed il programmatore.
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 nomi di
-file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di
+file lunghi (256 caratteri, estensibili a 1012) con una dimensione massima di
4~Tb.
Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
projects / gapil.git / blobdiff