dei normali file di dati.
In questa sezione forniremo una descrizione a grandi linee dell'architettura
-della gestione file in Linux, partendo da una introduzione ai concetti di
-base, per poi illustrare l'organizzazione di file e directory, i tipi di file
-concludendo con una panoramica sulle caratteristiche principali delle
-interfacce con cui i processi accedono ai file.
+della gestione dei file in Linux, partendo da una introduzione ai concetti di
+base, per poi illustrare la struttura dell'albero dei file ed il significato
+dei tipi di file, concludendo con una panoramica sulle caratteristiche
+principali delle due interfacce con cui i processi possono effettuare l'I/O su
+file.
\subsection{Una panoramica generale}
\label{sec:file_arch_overview}
Per poter accedere ai file, il kernel deve mettere a disposizione dei
-programmi delle opportune interfacce che consentano di leggerne il
-contenuto. Questo ha due aspetti: il primo è che il kernel, per il concetto
-dell'\textit{everything is a file}, deve fornire una interfaccia che consenta
-di operare sui file, sia che questi corrispondano ai normali file di dati, sia
-che siano quei file speciali (i cosiddetti \index{file!di~dispositivo} file di
-dispositivo, o \textit{device file}) che permettono di accedere alle
-periferiche.
+programmi delle opportune \textit{system call} che consentano di leggere e
+scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
+il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
+che consenta di operare sui file, sia che questi corrispondano ai normali file
+di dati, sia che siano quei file speciali (i cosiddetti
+\index{file!di~dispositivo} file di dispositivo, o \textit{device file}) che
+permettono di accedere alle periferiche.
Il secondo aspetto è che per poter utilizzare dei normali file di dati il
kernel deve provvedere ad organizzare e rendere accessibile in maniera
``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
sarà accessibile nella forma ordinaria di file e directory.
+\itindbeg{Virtual~File~System}
+
In Linux il concetto di \textit{everything is a file} è stato implementato
attraverso il \textit{Virtual File System} (che da qui in poi abbrevieremo in
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.
+svariati filesystem mantenendo la stessa interfaccia per i programmi in
+\textit{user space}.
-Il VFS fornisce cioè quel livello di indirezione che permette di collegare le
+Il VFS fornisce cioè quel livello di astrazione che permette di collegare le
operazioni interne del kernel per la manipolazione sui file con le
-\textit{system call} relative alle operazioni di I/O, e gestisce
-l'organizzazione dette operazioni nei vari modi in cui i diversi filesystem le
-effettuano, permettendo la coesistenza di filesystem differenti all'interno
+\textit{system call} relative alle operazioni di I/O, e gestisce poi
+l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem
+le effettuano, permettendo la coesistenza di filesystem differenti all'interno
dello stesso albero delle directory. Torneremo su questa interfaccia generica
-fornita dal \textit{Virtual File System} in sez.~\ref{sec:file_vfs_work}.
+fornita dal VFS in sez.~\ref{sec:file_vfs_work}.
-In sostanza quando un processo esegue una \textit{system call} che opera su un
-file, il kernel chiama sempre una funzione implementata nel VFS; la funzione
-eseguirà le manipolazioni sulle strutture generiche e utilizzerà poi la
-chiamata alle opportune funzioni 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 fig.~\ref{fig:file_VFS_scheme}.
+In sostanza quello che accade è che quando un processo esegue una
+\textit{system call} che opera su un file, il kernel chiama sempre una
+funzione implementata nel VFS; la funzione eseguirà le manipolazioni sulle
+strutture generiche e utilizzerà poi la chiamata alle opportune funzioni 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
+fig.~\ref{fig:file_VFS_scheme}.
\begin{figure}[!htb]
\centering
filesystem che accede al disco, il \textit{Virtual File System} eseguirà
direttamente il codice del kernel che permette di accedere alla periferica.
-Come accennato all'inizio una delle funzioni essenziali per il funzionamento
-dell'interfaccia dei file è quella che consente di montare un filesystem
-nell'albero dei file, e rendere così visibili i suoi contenuti. In un sistema
-unix-like infatti, a differenza di quanto avviene in altri sistemi operativi,
-tutti i file vengono mantenuti all'interno di un unico albero la cui radice
-(quella che viene chiamata \textit{root directory}) viene montata all'avvio
-direttamente dal kernel.
+\itindend{Virtual~File~System}
+
+Come accennato in precedenza una delle funzioni essenziali per il
+funzionamento dell'interfaccia dei file è quella che consente di montare un
+filesystem nell'albero dei file, e rendere così visibili i suoi contenuti. In
+un sistema unix-like infatti, a differenza di quanto avviene in altri sistemi
+operativi, tutti i file vengono mantenuti all'interno di un unico albero la
+cui radice (quella che viene chiamata \textit{root directory}) viene montata
+all'avvio direttamente dal kernel.
Come accennato in sez.~\ref{sec:intro_kern_and_sys}) montare la radice è,
insieme al lancio di \cmd{init},\footnote{l'operazione è ovviamente anche
Tutti gli ulteriori filesystem che possono essere disponibili su altri
dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli su
-altrettante directory del filesystem radice. Questo comunque avverrà sempre in
+altrettante directory del filesystem radice, su quelli che vengono chiamati
+\index{mount~point} \textit{mount point}. Questo comunque avverrà sempre in
un secondo tempo, in genere a cura dei programmi eseguiti nella procedura di
inizializzazione del sistema, grazie alle funzioni che tratteremo in
sez.~\ref{sec:sys_file_config}.
\itindbeg{pathname}
-Come appena illustrato sez.~\ref{sec:file_arch_overview} una delle
-caratteristiche distintive di un sistema unix-like è quella di avere un unico
-albero dei file. Un file deve essere identificato dall'utente usando quello
-che viene chiamato il suo \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 la shell cerca 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.} vale a dire tramite il
-percorso che si deve fare per accedere al file a partire da una certa
-``\textit{directory}''.
-
-Una directory, come vedremo in maggior dettaglio in
-sez.~\ref{sec:file_vfs_work}, è anch'essa un file (è cioè un oggetto di un
-filesystem), solo che è un file speciale che il kernel riconosce appunto come
-directory. Il suo scopo è quello di contenere una lista di nomi di file e le
-informazioni che associano ciascun nome al suo contenuto.
-
-Dato che questi nomi possono corrispondere ad un qualunque oggetto del
+Come illustrato sez.~\ref{sec:file_arch_overview} una delle caratteristiche
+distintive di un sistema unix-like è quella di avere un unico albero dei
+file. Un file deve essere identificato dall'utente usando quello che viene
+chiamato il suo \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 la shell cerca 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.} vale a dire tramite il percorso che si
+deve fare per accedere al file a partire da una certa ``\textit{directory}''.
+
+Una directory in realta è anch'essa un file, nel senso che è anch'essa un
+oggetto di un filesystem, solo che è un file particolare che il kernel
+riconosce appositamente come tale per poterlo utilizzare come directory. Il
+suo scopo è quello di contenere una lista di nomi di file e le informazioni
+che associano ciascuno di questi nomi al relativo contenuto.
+
+Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
filesystem, compresa un'altra directory, si ottiene naturalmente
un'organizzazione ad albero inserendo nomi di directory dentro altre
directory. All'interno dello stesso albero si potranno poi inserire anche
torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
\itindsub{pathname}{relativo} \textsl{pathname relativo}.
-Infine nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
+Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
sez.~\ref{sec:file_dir_creat_rem}). 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.
+corrente.
In questo modo con ``\file{..}'' si può usare un \textsl{pathname relativo}
per indicare un file posto al di sopra della directory corrente, tornando
Si tenga ben presente che questa classificazione non ha nulla a che fare con
una classificazione dei file in base al tipo loro del contenuto, dato che in
-tal caso si avrebbe a che fare sempre e solo con dei file di dati, e neanche
-con le eventuali diverse modalità con cui si potrebbe accedere al contenuto.
-La classificazione di tab.~\ref{tab:file_file_types} riguarda invece il tipo
-di oggetti gestiti dal \itindex{Virtual~File~System} \textit{Virtual File
- System}, ed è da notare la presenza dei cosiddetti file
-``\textsl{speciali}''.
+tal caso si avrebbe a che fare sempre e solo con dei file di dati. E non ha
+niente a che fare neanche con le eventuali diverse modalità con cui si
+potrebbe accedere al contenuto dei file di dati. La classificazione di
+tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
+\itindex{Virtual~File~System} \textit{Virtual File System}, ed è da notare la
+presenza dei cosiddetti file ``\textsl{speciali}''.
Alcuni di essi, come le \textit{fifo} (che tratteremo in
sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
alcune funzionalità di comunicazione fornite dal kernel. Gli altri sono
proprio quei \index{file!di~dispositivo} \textsl{file di dispositivo} che
costituiscono una interfaccia diretta per leggere e scrivere sui dispositivi
-fisici. Anche se finora li abbiamo messi insieme essi sono tradizionalmente
-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.
+fisici. Anche se finora li abbiamo chiamati genericamente così, essi sono
+tradizionalmente 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.
I dispositivi a blocchi (ad esempio i dischi) sono quelli 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 i
-dispositivi a caratteri sono quelli per cui l'I/O può essere effettuato senza
-nessuna particolare struttura.
+dati di dimensioni fissate (nel caso dei dischi le dimensioni di un settore),
+mentre i dispositivi a caratteri sono quelli per cui l'I/O può essere
+effettuato senza nessuna particolare struttura, ed in generale anche un byte
+alla volta, da cui il nome.
-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
+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. Non c'è neanche una strutturazione a
kernel deve essere in grado di capire il contenuto sono i binari dei
programmi, per i quali sono supportati solo alcuni formati, anche se oggi
viene usato quasi esclusivamente l'ELF.\footnote{il nome è l'acronimo di
- \textit{Executable and Linkable Format} un formato per eseguibili binari
+ \textit{Executable and Linkable Format}, un formato per eseguibili binari
molto flessibile ed estendibile definito nel 1995 dal \textit{Tool Interface
Standard} che per le sue caratteristiche di non essere legato a nessun
tipo di processore o architettura è stato adottato da molti sistemi
convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
in file con l'estensione \file{.c}. Inoltre una tecnica molto usata per
classificare i contenuti da parte dei programmi è 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.
+byte del file per memorizzare un \itindex{magic~number} ``\textit{magic
+ number}''\footnote{il concetto è quello di un numero intero, solitamente fra
+ 2 e 10 byte, che identifichi il contenuto seguente, dato che questi sono
+ anche caratteri è comune trovare espresso tale numero con stringhe come
+ ``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script.} che ne
+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 per l'accesso ai file}
\label{sec:file_io_api}
-In Linux le interfacce di programmazione per l'accesso al contenuto dei file
-due. La prima è l'interfaccia nativa del sistema, quella che il manuale delle
-\textsl{glibc} chiama interfaccia dei descrittori di file (o \textit{file
- descriptor}). Si tratta di un'interfaccia specifica dei sistemi unix-like e
-fornisce un accesso non bufferizzato.
-
-L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
-bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
-direttamente le \textit{system call} del kernel (in realtà il kernel effettua
-al suo interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso
-ai dispositivi). L'accesso viene gestito attraverso i \index{file!descriptor}
-\textit{file descriptor} che sono rappresentati da numeri interi (cioè
-semplici variabili di tipo \ctyp{int}). L'interfaccia è definita
-nell'\textit{header file} \file{unistd.h} e la tratteremo in dettaglio in
+
+\itindbeg{file~descriptor}
+
+In Linux le interfacce di programmazione per l'I/O su file due. La prima è
+l'interfaccia nativa del sistema, quella che il manuale delle \textsl{glibc}
+chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
+\textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
+sistemi unix-like che fornisce un accesso non bufferizzato.
+
+L'interfaccia è essenziale, l'accesso viene detto non bufferizzato in quanto
+la lettura e la scrittura vengono eseguite chiamando direttamente le
+\textit{system call} del kernel, anche se in realtà il kernel effettua al suo
+interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
+dispositivi. L'accesso viene gestito attraverso i \textit{file descriptor} che
+sono rappresentati da numeri interi (cioè semplici variabili di tipo
+\ctyp{int}). L'interfaccia è definita nell'\textit{header file}
+\file{unistd.h} e la tratteremo in dettaglio in
cap.~\ref{cha:file_unix_interface}.
+\itindbeg{file~stream}
+
La seconda interfaccia è quella che il manuale della \acr{glibc} chiama dei
-\index{file!stream} \textit{file stream} o più semplicemente
-\textit{stream}.\footnote{in realtà una interfaccia con lo stesso nome è stata
- introdotta a livello di kernel negli Unix derivati da \textit{System V},
- come strato di astrazione per file e socket; in Linux questa interfaccia,
- che comunque ha avuto poco successo, non esiste, per cui facendo riferimento
- agli \index{file!stream} \textit{stream} useremo il significato adottato dal
- manuale delle \acr{glibc}.} Essa fornisce funzioni più evolute e un accesso
-bufferizzato, controllato dalla implementazione fatta nella \acr{glibc}.
-Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
-anche su tutti i sistemi non Unix. Gli \index{file!stream} \textit{stream}
-sono oggetti complessi e sono rappresentati da puntatori ad un opportuna
-struttura definita dalle librerie del C, ad essi si accede sempre in maniera
-indiretta utilizzando il tipo \type{FILE *}. L'interfaccia è definita
-nell'\textit{header file} \file{stdio.h} e la tratteremo in dettaglio nel
-cap.~\ref{cha:files_std_interface}.
+\textit{file stream} o più semplicemente degli \textit{stream}.\footnote{in
+ realtà una interfaccia con lo stesso nome è stata introdotta a livello di
+ kernel negli Unix derivati da \textit{System V}, come strato di astrazione
+ per file e socket; in Linux questa interfaccia, che comunque ha avuto poco
+ successo, non esiste, per cui facendo riferimento agli \textit{stream}
+ useremo il significato adottato dal manuale delle \acr{glibc}.} Essa
+fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
+implementazione fatta nella \acr{glibc}. Questa è l'interfaccia standard
+specificata dall'ANSI C e perciò si trova 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, ad essi si
+accede sempre in maniera indiretta utilizzando il tipo \code{FILE *}.
+L'interfaccia è definita nell'\textit{header file} \file{stdio.h} e la
+tratteremo in dettaglio nel cap.~\ref{cha:files_std_interface}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS, ma per poter accedere alle operazioni di controllo
(descritte in sez.~\ref{sec:file_fcntl} e sez.~\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
-\index{file!descriptor} \textit{file descriptor} se si vuole ricorrere a
-modalità speciali di I/O come il \index{file!locking} \textit{file locking} o
-l'I/O non-bloccante (vedi cap.~\ref{cha:file_advanced}).
+con i file descriptor. Allo stesso modo devono essere usati i file descriptor
+se si vuole ricorrere a modalità speciali di I/O come il
+\itindex{file~locking} \textit{file locking} o l'I/O non-bloccante (vedi
+cap.~\ref{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
è che l'interfaccia per le operazioni di input/output è molto 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
-\index{file!stream} \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.
+\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 \textit{stream} sono implementati sopra
l'interfaccia standard di Unix, è sempre possibile estrarre il \textit{file
- descriptor} da uno \textit{stream} ed eseguirvi operazioni di basso livello,
-o associare in un secondo tempo uno \index{file!stream} \textit{stream} ad un
-\index{file!descriptor} \textit{file descriptor} per usare l'interfaccia più
-ricca.
+ descriptor} da uno \textit{stream} ed eseguirvi sopra operazioni di basso
+livello, o associare in un secondo tempo uno \textit{stream} ad un
+\textit{file descriptor} per usare l'interfaccia più sofisticata.
In generale, se non necessitano specificatamente le funzionalità di basso
-livello, è opportuno usare sempre gli \index{file!stream} \textit{stream} per
-la loro maggiore portabilità, essendo questi ultimi definiti nello standard
-ANSI C; l'interfaccia con i \index{file!descriptor} \textit{file descriptor}
-infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed è pertanto di
-portabilità più limitata.
+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.
+\itindend{file~descriptor}
+\itindend{file~stream}
\section{Gli standard}
\label{sec:intro_standard}
projects / gapil.git / blobdiff