\section{Il \textit{file locking}}
\label{sec:file_locking}
-\index{file!locking|(}
+\itindbeg{file~locking}
In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
sistema unix-like gestisce la condivisione dei file da parte di processi
\subsection{Il \textit{mandatory locking}}
\label{sec:file_mand_locking}
-\itindbeg{mandatory~locking|(}
+\itindbeg{mandatory~locking}
Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
per introdurre un \textit{file locking} che, come dice il nome, fosse
qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
possibilità di modificare il file.
-\index{file!locking|)}
+\itindend{file~locking}
-\itindend{mandatory~locking|(}
+\itindend{mandatory~locking}
\section{L'\textit{I/O multiplexing}}
nel sistema.
\item[\errcode{EMFILE}] si è raggiunto il limite sul numero massimo di
istanze di \textit{epoll} per utente stabilito da
- \procfile{/proc/sys/fs/epoll/max\_user\_instances}.
+ \sysctlfile{fs/epoll/max\_user\_instances}.
\item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
l'istanza.
\end{errlist}
\item[\errcode{EPERM}] il file \param{fd} non supporta \textit{epoll}.
\item[\errcode{ENOSPC}] si è raggiunto il limite massimo di registrazioni
per utente di file descriptor da osservare imposto da
- \procfile{/proc/sys/fs/epoll/max\_user\_watches}.
+ \sysctlfile{fs/epoll/max\_user\_watches}.
\end{errlist}
}
\end{prototype}
impostare la lunghezza della coda dei segnali real-time ad una dimensione
identica al valore massimo del numero di file descriptor
utilizzabili.\footnote{vale a dire impostare il contenuto di
- \procfile{/proc/sys/kernel/rtsig-max} allo stesso valore del contenuto di
- \procfile{/proc/sys/fs/file-max}.}
+ \sysctlfile{kernel/rtsig-max} allo stesso valore del contenuto di
+ \sysctlfile{fs/file-max}.}
% TODO fare esempio che usa O_ASYNC
sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
definita la macro \macro{\_GNU\_SOURCE} prima di includere \file{fcntl.h}.
-\index{file!lease|(}
+\itindbeg{file~lease}
La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
questo è un meccanismo che consente ad un processo, detto \textit{lease
Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
il numero di secondi specificato dal parametro di sistema mantenuto in
-\procfile{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
+\sysctlfile{fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
evitare che un processo blocchi indefinitamente l'accesso ad un file
acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
descriptor che è stato modificato tramite il contenuto della struttura
\struct{siginfo\_t}.
-\index{file!lease|)}
+\itindend{file~lease}
\begin{table}[htb]
\centering
di sistema è previsto che un utente possa utilizzare un numero limitato di
istanze di \textit{inotify}; il valore di default del limite è di 128, ma
questo valore può essere cambiato con \func{sysctl} o usando il file
- \procfile{/proc/sys/fs/inotify/max\_user\_instances}.} si tratta di un file
+ \sysctlfile{fs/inotify/max\_user\_instances}.} si tratta di un file
descriptor speciale che non è associato a nessun file su disco, e che viene
utilizzato solo per notificare gli eventi che sono stati posti in
osservazione. Dato che questo file descriptor non è associato a nessun file o
directory che si vogliono tenere sotto osservazione,\footnote{anche in questo
caso c'è un limite massimo che di default è pari a 8192, ed anche questo
valore può essere cambiato con \func{sysctl} o usando il file
- \procfile{/proc/sys/fs/inotify/max\_user\_watches}.} e si utilizzerà sempre
+ \sysctlfile{fs/inotify/max\_user\_watches}.} e si utilizzerà sempre
un solo file descriptor.
Il tipo di evento che si vuole osservare deve essere specificato
\end{table}
\footnotetext{la coda di notifica ha una dimensione massima specificata dal
- parametro di sistema \procfile{/proc/sys/fs/inotify/max\_queued\_events} che
+ parametro di sistema \sysctlfile{fs/inotify/max\_queued\_events} che
indica il numero massimo di eventi che possono essere mantenuti sulla
stessa; quando detto valore viene ecceduto gli ulteriori eventi vengono
scartati, ma viene comunque generato un evento di tipo
che consentono di controllarne il montaggio e lo smontaggio.
Esamineremo poi le funzioni di libreria che si usano per copiare, spostare e
-cambiare i nomi di file e directory ed esamineremo l'interfaccia che permette
-la manipolazione dei loro attributi. Tratteremo inoltre la struttura di base
-del sistema delle protezioni e del controllo dell'accesso ai file e le
-successive estensioni (\textit{Extended Attributes}, ACL, quote disco,
-\textit{capabilities}). Tutto quello che riguarda invece la manipolazione del
-contenuto dei file è lasciato ai capitoli successivi.
+cambiare i nomi di file e directory e l'interfaccia che permette la
+manipolazione dei loro attributi. Tratteremo inoltre la struttura di base del
+sistema delle protezioni e del controllo dell'accesso ai file e le successive
+estensioni (\textit{Extended Attributes}, ACL, quote disco,
+\textit{capabilities}). Tutto quello che riguarda invece la gestione dell'I/O
+sui file è lasciato al capitolo successivo.
sez.~\ref{sec:file_arch_overview} il \textit{Virtual File System} di Linux e
come il kernel può gestire diversi tipi di filesystem, descrivendo prima le
caratteristiche generali di un filesystem di un sistema unix-like, per poi
-trattare in maniera un po' più dettagliata il filesystem più usato con Linux,
-l'\acr{ext2} (e derivati).
+fare una panoramica sul filesystem più usato con Linux, l'\acr{ext2} ed i suoi
+successori.
\subsection{Il funzionamento del \textit{Virtual File System} di Linux}
concetto di \textit{everything is a file} è stato implementato attraverso il
\textit{Virtual File System}, la cui struttura generale è illustrata in
fig.~\ref{fig:file_VFS_scheme}. Il VFS definisce un insieme di funzioni che
-tutti i filesystem devono implementare. L'interfaccia comprende tutte le
-funzioni che riguardano i file e le operazioni sono suddivise su tre tipi di
-oggetti: \textit{filesystem}, \itindex{inode} \textit{inode} e \textit{file},
-corrispondenti a tre apposite strutture definite nel kernel.
+tutti i filesystem devono implementare per l'accesso ai file che contengono e
+l'interfaccia che consente di eseguire l'I/O sui file, che questi siano di
+dati o dispositivi.
+
+L'interfaccia fornita dal VFS comprende in sostanza tutte le funzioni che
+riguardano i file, le operazioni implementate dal VFS sono realizzate con una
+astrazione che prevede quattro tipi di oggetti strettamente correlati: i
+filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
+corrispondono una serie di apposite strutture definite dal kernel che
+contengono come campi le funzioni di gestione e realizzano l'infrastruttura
+del VFS. L'interfaccia è estremamente complessa, ne faremo pertanto una
+trattazione estremamente semplificata che consenta di comprenderne i principi
+difunzionamento.
Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
-filesystem supportato: quando si vuole inserire il supporto di un nuovo
+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
-\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
-o di qualunque altro dispositivo che può contenere un filesystem, il VFS può
-ricavare dalla citata tabella il puntatore alle funzioni da chiamare nelle
-operazioni di montaggio. Queste sono responsabili inizializzare tutte le
-variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possibile accedere alle funzioni
-specifiche per l'uso di quel filesystem.
-
-Il primo oggetto usato dal VFS è il descrittore di filesystem (o
-\textit{filesystem descriptor}), 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
-\textit{filesystem descriptor} per accedere alle funzioni specifiche di quel
+\code{register\_filesystem} passando come argomento la struttura
+\kstruct{file\_system\_type} (la cui definizione è riportata in
+fig.~\ref{fig:kstruct_file_system_type}) relativa a quel filesystem. Questa
+verrà inserita nella tabella, ed il nuovo filesystem comparirà in
+\procfile{/proc/filesystems}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/file_system_type.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{file\_system\_type} usata dal
+ VFS (da \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_file_system_type}
+\end{figure}
+
+La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
+come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
+ viene riportato in \procfile{/proc/filesystems} e che viene usato come
+ parametro dell'opzione \texttt{-t} del comando \texttt{mount}.} contiene i
+riferimenti alle funzioni di base che consentono l'utilizzo di quel
+filesystem. In particolare la funzione \code{mount} del quarto campo è quella
+che verrà invocata tutte le volte che si dovrà effettuare il montaggio di un
+filesystem di quel tipo. Per ogni nuovo filesystem si dovrà allocare una di
+queste strutture ed inizializzare i relativi campi con i dati specifici diquel
+filesystem, ed in particolare si dovra creare anche la relativa versione della
+funzione \code{mount}.
+
+Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
+restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
+ entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
+la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
+\textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
+vedremo a breve è l'oggetto usato dal kernel per identificare un un
+file.\footnote{in questo caso si parla di file come di un qualunque oggetto
+ generico che sta sul filesystem.} La \textit{dentry} ottenuta dalla chiamata
+alla funzione \code{mount} sarà inserita in corrispondenza al
+\textit{pathname} della directory in cui il filesystem è stato montato.
+
+% NOTA: struct dentry è dichiarata in include/linux/dcache.h
+
+Le \textit{dentry} sono oggetti del VFS che vivono esclusivamente in memoria,
+nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve
+\textit{dcache}). Ogni volta che una \textit{system call} specifica un
+\textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
+ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
+ funzionamento della \textit{dcache} è in effetti di una delle parti più
+ critiche per le prestazioni del sistema.} che a sua ci darà, tramite
+l'\textit{inode}, il riferimento al file.
+
+Dato che normalmente non è possibile mantenere nella \textit{dcache} le
+informazioni relative a tutto l'albero dei file la procedura della
+\textit{pathname resolution} richiede un meccanismo con cui riempire gli
+eventuali vuoti. Il meccanismo prevede che tutte le volte che si arriva ad una
+\textit{dentry} mancante venga invocata la funzione \texttt{lookup} dell'inode
+associato alla \textit{dentry} precedente nella risoluzione del
+\textit{pathname},\footnote{che a questo punto è una directory, per cui si può
+ cercare al suo interno il nome di un file.} il cui scopo è risolvere il nome
+mancante e fornire la sua \textit{dentry} che a questo punto verrà inserita
+nella cache.
+
+Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
+della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
+iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà
+comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
+a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
+filesystem, e come vedremo questo farà sì che venga eseguita una
+\texttt{lookup} adatta per effettuare la risoluzione dei nomi per 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
-relative al file in uso, insieme ai puntatori alle funzioni dello specifico
-filesystem usate per l'accesso dal VFS. In particolare il descrittore
-\itindex{inode} dell'\textit{inode} contiene i puntatori alle funzioni che
-possono essere usate su qualunque file (come \func{link}, \func{stat} e
-\func{open}), mentre il descrittore di file contiene i puntatori alle funzioni
-che vengono usate sui file già aperti.
-
-La funzione più importante implementata dal VFS è la \textit{system call}
-\func{open} che permette di aprire un file. Dato un \itindex{pathname}
-\textit{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 \textit{pathname} a una specifica
-\textit{dentry}.
-
-Una singola \textit{dentry} contiene in genere il puntatore ad un
-\itindex{inode} \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
-\index{file!di~dispositivo} dispositivo, o una qualsiasi altra cosa che possa
-essere rappresentata dal VFS (i tipi di file riportati in
-tab.~\ref{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,
-vengono usate per motivi di velocità, gli \itindex{inode} \textit{inode} invece
-stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
-viene copiato all'indietro sul disco (aggiornando i cosiddetti
-\textsl{metadati} del file), gli \itindex{inode} inode che stanno in memoria
-sono \itindex{inode} inode del VFS ed è ad essi che puntano le singole
-\textit{dentry}.
-
-La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
-l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
-parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
-per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
-\itindex{pathname} \textit{pathname} il VFS deve creare una nuova
-\textit{dentry} e caricare \itindex{inode} l'inode corrispondente in memoria.
-
-Questo procedimento viene eseguito dal metodo \code{lookup()} \itindex{inode}
-dell'inode 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.
-
-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
-\itindex{inode} dell'inode e passarli in user space.
-
-L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
-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 \textit{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 sez.~\ref{sec:file_fd}). Un elenco
-delle operazioni previste dal kernel è riportato in
-tab.~\ref{tab:file_file_operations}.
+% Un secondo effetto della chiamata funzione \texttt{mount} di
+% \kstruct{file\_system\_type} è quello di allocare una struttura
+% \kstruct{super\_block} per ciascuna istanza montata, che contiene le
+% informazioni generali di un qualunque filesystem montato, come le opzioni di
+% montaggio, le dimensioni dei blocchi, quando il filesystem è stato montato
+% ecc. Fra queste però viene pure inserta, nel campo \var{s\_op}, una ulteriore
+% struttura \kstruct{super\_operations}, il cui contenuto sono i puntatori
+% alle funzioni di gestione di un filesystem, anche inizializzata in modo da
+% utilizzare le versioni specifiche di quel filesystem.
+
+L'oggetto più importante per il funzionamento del VFS è probabilmente
+l'\textit{inode}, ma con questo nome si può fare riferimento a due cose
+diverse. La prima è la struttura su disco (su cui torneremo anche in
+sez.~\ref{sec:file_filesystem}) che fa parte della organizzazione dei dati
+realizzata dal filesystem e che contiene le informazioni relative alle
+proprietà (i cosiddetti \textsl{metadati}) di ogni oggetto presente su di esso
+(si intende al solito uno qualunque dei tipi di file di
+tab.~\ref{tab:file_file_types}).
+
+La seconda è la corrispondente struttura \kstruct{inode}, della cui
+definizione si è riportato un estratto in
+fig.~\ref{fig:kstruct_inode}.\footnote{l'estratto fa riferimento alla versione
+ del kernel 2.6.37.} Questa struttura viene mantenuta in memoria ed è a
+questa che facevamo riferimento quando parlavamo dell'\textit{inode} associato
+a ciascuna \textit{dentry}. Nella struttura in memoria sono presenti gli
+stessi \textsl{metadati} memorizzati su disco, che vengono letti quando questa
+struttura viene allocata e trascritti all'indietro se modificati.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/inode.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{inode} del kernel (da
+ \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_inode}
+\end{figure}
+
+Il fatto che la struttura \kstruct{inode} sia mantenuta in memoria,
+direttamente associata ad una \textit{dentry}, rende sostanzialmente immediate
+le operazioni che devono semplicemente effettuare un accesso ai dati in essa
+contenuti: è così ad esempio che viene realizzata la \textit{system call}
+\func{stat} che vedremo in sez.~\ref{sec:file_stat}. Rispetto ai dati salvati
+sul disco questa struttura contiene però anche quanto necessario alla
+implementazione del VFS, ed in particolare è importante il campo \var{i\_op}
+che, come illustrato in fig.~\ref{fig:kstruct_inode}, contiene il puntatore ad
+una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può
+trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
+
+Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè
+è un puntatore ad una funzione, e, come suggerisce il nome della struttura
+stessa, queste funzioni, le principali delle quali sono riportate in
+tab.~\ref{tab:file_inode_operations}) sono quelle che definiscono le
+operazioni che il VFS può compiere su un \textit{inode}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Funzione} & \textbf{Operazione} \\
+ \hline
+ \hline
+ \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi
+ sez.~\ref{sec:file_open}).\\
+ \textsl{\code{link}} & Crea un \textit{hard link} (vedi
+ sez.~\ref{sec:file_link}).\\
+ \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi
+ sez.~\ref{sec:file_link}).\\
+ \textsl{\code{symlink}}& Crea un link simbolico (vedi
+ sez.~\ref{sec:file_symlink}).\\
+ \textsl{\code{mkdir}} & Crea una directory (vedi
+ sez.~\ref{sec:file_dir_creat_rem}).\\
+ \textsl{\code{rmdir}} & Rimuove una directory (vedi
+ sez.~\ref{sec:file_dir_creat_rem}).\\
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
+ sez.~\ref{sec:file_mknod}).\\
+ \textsl{\code{rename}} & Cambia il nome di un file (vedi
+ sez.~\ref{sec:file_remove}).\\
+ \textsl{\code{lookup}}& Risolve il nome di un file.\\
+ \hline
+ \end{tabular}
+ \caption{Le principali operazioni sugli \textit{inode} definite tramite
+ \kstruct{inode\_operation}.}
+ \label{tab:file_inode_operations}
+\end{table}
+
+Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
+identici alle varie \textit{system call} con le quali si gestiscono file e
+directory che tratteremo nel resto del capitolo. Quello che succede è che
+tutte le volte che deve essere eseguita una \textit{system call}, o una
+qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
+andrà ad utilizzare la funzione corrispondente attraverso il puntatore
+\var{i\_op}.
+
+Sarà allora sufficiente che nella realizzazione di un filesystem si crei una
+opportuna istanza di \kstruct{inode\_operation} contenente i puntatori alla
+implementazione di queste funzioni per quel filesystem e quel punto le
+strutture \kstruct{inode} usate per gli oggetti di quel filesystem otterranno
+il puntatore a detta istanza di \kstruct{inode\_operation} e verranno
+automaticamente usate le funzioni corrette.
+
+Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
+funzione \texttt{open} che invece è citata in
+tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
+ invocata dato che nella struttura \kstruct{inode} è presente anche il
+ puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
+ fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
+file richiede comunque un'altra operazione: l'allocazione di una struttura di
+tipo \kstruct{file} che viene associata ad ogni file aperto nel sistema.
+
+I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
+come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
+operazioni eseguite dai processi con l'interfaccia dei file descriptor; ogni
+processo infatti mantiene il riferimento ad una struttura \kstruct{file} per
+ogni file che ha aperto, ed è tramite essa che esegue le operazioni di I/O.
+
+Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
+oggetti posti all'interno di un filesystem e vi si applicano quindi le
+funzioni fornite nell'implementazione di quest'ultimo, quando si apre un file
+questo può essere anche un file di dispositivo, ed in questo caso il VFS
+invece di usare le operazioni fornite dal filesystem (come farebbe per un file
+di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/file.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{file} del kernel (da
+ \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_file}
+\end{figure}
+
+Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
+contiene, oltre ad alcune informazioni usate dall'interfaccia dei file
+descriptor il cui significato emergerà più avanti, il puntatore \struct{f\_op}
+ad una struttura \kstruct{file\_operation}. Questa è l'analoga per i file di
+\kstruct{inode\_operation}, e definisce le operazioni generiche fornite dal
+VFS per i file. Si sono riportate in tab.~\ref{tab:file_file_operations} le
+più significative.
\begin{table}[htb]
\centering
sez.~\ref{sec:file_asyncronous_io}) sul file.\\
\hline
\end{tabular}
- \caption{Operazioni sui file definite nel VFS.}
+ \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.}
\label{tab:file_file_operations}
\end{table}
-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 funzione dichiarata in \struct{f\_ops} appropriata al
-tipo di file in questione.
-
-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.
+Anche in questo caso tutte le volte che deve essere eseguita una
+\textit{system call} o una qualunque altra operazione sul file il VFS andrà ad
+utilizzare la funzione corrispondente attraverso il puntatore
+\var{f\_op}. Dato che è cura del VFS quando crea la struttura all'apertura del
+file, assegnare a \var{f\_op} il puntatore alla versione di
+\kstruct{file\_operation} corretta per quel file, sarà possibile scrivere allo
+stesso modo sulla porta seriale come su un normale file di dati, e lavorare
+sui file allo stesso modo indipendentemente dal filesystem.
+
+Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
+alle funzioni presenti nelle due strutture \kstruct{inode\_operation}
+\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
+possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek}
+non è realizzabile per un dispositivo come la porta seriale o per una fifo,
+mentre sui file del filesystem \texttt{vfat} non sono disponibili i permessi,
+ma resta il fatto che grazie al VFS le \textit{system call} per le operazioni
+sui file restano sempre le stesse nonostante le enormi differenze che possono
+esserci negli oggetti a cui si applicano.
+
+
\itindend{Virtual~File~System}
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à
-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 un sistema unix-like.
+diversi, ognuno dei quali avrà 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 qualunque filesystem di un sistema unix-like.
Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. La strutturazione tipica
+partizione può contenere un filesystem. Una possibile strutturazione
dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys},
-in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
-prevede una separazione dei dati in \textit{block group} che replicano il
-cosiddetto \textit{superblock} (ma sulle caratteristiche di \acr{ext2} e
-derivati torneremo in sez.~\ref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem per Unix, indipendentemente da come poi viene
-strutturata nei dettagli questa informazione, prevedere una divisione fra la
-lista degli \itindex{inode} inode e lo spazio a disposizione per i dati e le
-directory.
+in essa per semplicità si è fatto riferimento alla struttura del filesystem
+\acr{ext2}, che prevede una separazione dei dati in \textit{block group} che
+replicano il cosiddetto \textit{superblock} (sulle caratteristiche di
+\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}). È comunque
+caratteristica comune di tutti i filesystem per Unix, indipendentemente da
+come poi viene strutturata nei dettagli questa informazione, prevedere una
+divisione fra la lista degli \itindex{inode} \textit{inode} e lo spazio a
+disposizione per i dati e le directory.\footnote{questo non è del tutto vero
+ per filesystem evoluti come \textsl{btrfs}, ma per il momento limitiamoci
+ alla implementazione classica.}
\begin{figure}[!htb]
\centering
\end{figure}
Se si va ad esaminare con maggiore dettaglio la strutturazione
-dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
+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
+gruppi dei blocchi, il superblock e tutti i dati di gestione possiamo
esemplificare la situazione con uno schema come quello esposto in
fig.~\ref{fig:file_filesys_detail}.
cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che
contengono i dati e così via. Le informazioni che la funzione \func{stat}
- fornisce provengono dall'\textit{inode}; dentro una directory si troverà
- solo il nome del file e il numero \itindex{inode} dell'\textit{inode} ad esso
- associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
- traduzione dell'inglese \textit{directory entry}, che non useremo anche per
- evitare confusione con le \textit{dentry} del kernel di cui si parlava in
+ (vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}.
+ Dentro una directory si troverà solo il nome del file e il numero
+ \itindex{inode} dell'\textit{inode} ad esso associato, cioè quella che da
+ qui in poi chiameremo una \textsl{voce} (come traduzione dell'inglese
+ \textit{directory entry}, che non useremo anche per evitare confusione con
+ le \textit{dentry} del kernel di cui si parlava in
sez.~\ref{sec:file_vfs_work}).
\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
contatore che contiene il numero di riferimenti che sono stati fatti ad esso
(il cosiddetto \textit{link count}); 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 \itindex{inode}
- nell'\textit{inode}.
+ funzione per cancellare un file si chiama \func{unlink} (vedi
+ sez.~\ref{sec:file_link}), 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 \itindex{inode} nell'\textit{inode}.
\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
nello stesso filesystem e non ci può essere una directory che contiene
del file non viene spostato fisicamente, viene semplicemente creata una
nuova voce per \itindex{inode} 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}). Questa operazione non modifica
- minimamente neanche l'\textit{inode} del file dato che non si opera su
- questo ma sulla directory che lo contiene.
+ attraverso la funzione \func{rename}, vedi
+ sez.~\ref{sec:file_remove}). Questa operazione non modifica minimamente
+ neanche l'\textit{inode} del file dato che non si opera su questo ma sulla
+ directory che lo contiene.
\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
\item[\errcode{EINVAL}] il device \param{source} presenta un
\textit{superblock} non valido, o si è cercato di rimontare un filesystem
non ancora montato, o di montarlo senza che \param{target} sia un
- \textit{mount point} o di spostarlo quando \param{target} non è un
- \textit{mount point} o è \file{/}.
+ \itindex{mount~point} \textit{mount point} o di spostarlo
+ quando \param{target} non è un \itindex{mount~point} \textit{mount point}
+ o è \file{/}.
\item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
componenti del \itindex{pathname} \textit{pathname}, o si è cercato
di montare un filesystem disponibile in sola lettura senza averlo
\errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
\end{prototype}
-La funzione monta sulla directory \param{target}, detta \textit{mount point},
-il filesystem contenuto in \param{source}. In generale un filesystem è
-contenuto su un disco, e l'operazione di montaggio corrisponde a rendere
-visibile al sistema il contenuto del suddetto disco, identificato attraverso
-il file di dispositivo ad esso associato.
+La funzione monta sulla directory \param{target}, detta \itindex{mount~point}
+\textit{mount point}, il filesystem contenuto in \param{source}. In generale
+un filesystem è contenuto su un disco, e l'operazione di montaggio corrisponde
+a rendere visibile al sistema il contenuto del suddetto disco, identificato
+attraverso il file di dispositivo ad esso associato.
Ma la struttura del \textit{Virtual File System} vista in
sez.~\ref{sec:file_vfs_work} è molto più flessibile e può essere usata anche
ignorato.
Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
-disponibile nella directory specificata come \textit{mount point}, il
-precedente contenuto di detta directory viene mascherato dal contenuto della
-directory radice del filesystem montato.
+disponibile nella directory specificata come \itindex{mount~point}
+\textit{mount point}, il precedente contenuto di detta directory viene
+mascherato dal contenuto della directory radice del filesystem montato.
Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
-\textit{mount point} da una directory ad un'altra, sia montare in diversi
-\textit{mount point} lo stesso filesystem, sia montare più filesystem sullo
-stesso \textit{mount point} (nel qual caso vale quanto appena detto, e solo il
+\itindex{mount~point} \textit{mount point} da una directory ad un'altra, sia
+montare in diversi \itindex{mount~point} \textit{mount point} lo stesso
+filesystem, sia montare più filesystem sullo stesso \itindex{mount~point}
+\textit{mount point} (nel qual caso vale quanto appena detto, e solo il
contenuto dell'ultimo filesystem montato sarà visibile).
Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
montaggio con l'argomento \param{mountflags}.
In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \textit{magic number}\footnote{cioè un numero speciale
- usato come identificativo, che nel caso è \code{0xC0ED}; si può usare la
- costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
- riservata al \textit{magic number}.} mentre i 16 meno significativi sono
-usati per specificare le opzioni; essi sono usati come maschera binaria e
-vanno impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i
+significativi sono un \itindex{magic~number} \textit{magic
+ number}\footnote{che nel caso è \code{0xC0ED}, si può usare la costante
+ \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
+ al \textit{magic number}.} mentre i 16 meno significativi sono usati per
+specificare le opzioni; essi sono usati come maschera binaria e vanno
+impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i
valori riportati in tab.~\ref{tab:sys_mount_flags}.
\begin{table}[htb]
separate e la funzione poteva essere usata anche specificando il file di
dispositivo.} in quanto con il kernel 2.4.x è possibile montare lo stesso
dispositivo in più punti. Nel caso più di un filesystem sia stato montato
-sullo stesso \textit{mount point} viene smontato quello che è stato montato
-per ultimo.
+sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
+che è stato montato per ultimo.
Si tenga presente che la funzione fallisce quando il filesystem è
\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
filesystem, se questo contiene la directory di lavoro corrente di un qualunque
-processo o il mount point di un altro filesystem; in questo caso l'errore
-restituito è \errcode{EBUSY}.
+processo o il \itindex{mount~point} \textit{mount point} di un altro
+filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
casi permette di forzare lo smontaggio di un filesystem, anche quando questo
errore nel qual caso \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
- riferimento ad un filesystem montato sullo stesso \textit{mount point}.
+ riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
+ \textit{mount point}.
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
\param{newpath} non supporta i link diretti o è una directory.
\item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
filesystem, ma anche che si faccia riferimento ad essi sullo stesso
-\textit{mount point}.\footnote{si tenga presente infatti (vedi
- sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso
- filesystem può essere montato più volte su directory diverse.}
+\itindex{mount~point} \textit{mount point}.\footnote{si tenga presente infatti
+ (vedi sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno
+ stesso filesystem può essere montato più volte su directory diverse.}
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
non vuota.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
parte di qualche processo (come directory di lavoro o come radice) o del
- sistema (come mount point).
+ sistema (come \itindex{mount~point} \textit{mount point}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
\textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
- \macro{S\_ISREG(m)} & file normale.\\
- \macro{S\_ISDIR(m)} & directory.\\
- \macro{S\_ISCHR(m)} & dispositivo a caratteri.\\
- \macro{S\_ISBLK(m)} & dispositivo a blocchi.\\
- \macro{S\_ISFIFO(m)} & fifo.\\
- \macro{S\_ISLNK(m)} & link simbolico.\\
- \macro{S\_ISSOCK(m)} & socket.\\
+ \macro{S\_ISREG}\texttt{(m)} & file normale.\\
+ \macro{S\_ISDIR}\texttt{(m)} & directory.\\
+ \macro{S\_ISCHR}\texttt{(m)} & dispositivo a caratteri.\\
+ \macro{S\_ISBLK}\texttt{(m)} & dispositivo a blocchi.\\
+ \macro{S\_ISFIFO}\texttt{(m)} & fifo.\\
+ \macro{S\_ISLNK}\texttt{(m)} & link simbolico.\\
+ \macro{S\_ISSOCK}\texttt{(m)} & socket.\\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
\textit{file capabilities}, il \textit{capabilities bounding set} è un
parametro generale di sistema, il cui valore viene riportato nel file
-\procfile{/proc/sys/kernel/cap-bound}. Il suo valore iniziale è definito in
+\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in
sede di compilazione del kernel, e da sempre ha previsto come default la
presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In
questa situazione solo il primo processo eseguito nel sistema (quello con
Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
è diventato una proprietà di ciascun processo, che viene propagata invariata
sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
-\procfile{/proc/sys/kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
\begin{table}[!h!btp]
\centering
\footnotesize
- \begin{tabular}{|l|p{11.9cm}|}
+ \begin{tabular}{|l|p{10.5cm}|}
\hline
\textbf{Capacità}&\textbf{Descrizione}\\
\hline
intercomunicazione fra processi (vedi
sez.~\ref{sec:ipc_sysv}).\\
\const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
- \index{file!lease} (vedi
+ \itindex{file~lease} (vedi
sez.~\ref{sec:file_asyncronous_lease})
pur non essendo proprietari del file (dal kernel
2.4).\\
(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
+di file aperti,\footnote{quello indicato da \sysctlfile{fs/file-max}.}
effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
+++ /dev/null
-%% fileintro.tex
-%%
-%% Copyright (C) 2000-2011 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",
-%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
-%% license is included in the section entitled "GNU Free Documentation
-%% License".
-%%
-
-%\chapter{L'architettura dei file}
-%\label{cha:file_intro}
-
-% capitolo eliminato, inglobando altrove
-
-% LocalWords: everything is device kernel filesystem sez pathname root glibc
-% LocalWords: path filename bootloader proc name components fifo socket dev LF
-% LocalWords: resolution chroot parent Virtual System like tab cap l'I regular
-% LocalWords: inode symbolic char block VFS VMS Windows dell'I raw access Mac
-% LocalWords: CR dos HFS l'XFS SGI magic number descriptor system call int ext
-% LocalWords: nell'header unistd stream dall'ANSI stdio locking POSIX fig type
-% LocalWords: register superblock dell'inode stat entry cache dcache dentry ln
-% LocalWords: l'inode lookup ops read write llseek ioctl readdir poll nell'I
-% LocalWords: multiplexing mmap fsync fasync seek group dall' dell' img
-% LocalWords: count unlink nell' rename gapil second Tb attributes BSD SVr gid
-% LocalWords: sgid append only log fs linux extented linked list third MacOS
-
-
-%%% Local Variables:
-%%% mode: latex
-%%% TeX-master: "gapil"
-%%% End:
\subsection{I \textit{file stream}}
\label{sec:file_stream}
-\index{file!stream|(}
+\itindbeg{file~stream}
Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
basso livello, che non provvede nessuna forma di formattazione dei dati e
Se il programmatore non si cura di effettuare le operazioni in blocchi di
dimensioni adeguate, le prestazioni sono inferiori. La caratteristica
-principale dell'interfaccia degli stream è che essa provvede da sola alla
-gestione dei dettagli della bufferizzazione e all'esecuzione delle operazioni
-di lettura e scrittura in blocchi di dimensioni appropriate all'ottenimento
-della massima efficienza.
+principale dell'interfaccia degli \textit{stream} è che essa provvede da sola
+alla gestione dei dettagli della bufferizzazione e all'esecuzione delle
+operazioni di lettura e scrittura in blocchi di dimensioni appropriate
+all'ottenimento della massima efficienza.
Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
\textit{file stream}, dato che non è più necessario doversi preoccupare
A parte i dettagli legati alla gestione delle operazioni di lettura e
scrittura (sia per quel che riguarda la bufferizzazione, che le
-formattazioni), i file stream restano del tutto equivalenti ai file descriptor
-(sui quali sono basati), ed in particolare continua a valere quanto visto in
-sez.~\ref{sec:file_sharing} a proposito dell'accesso condiviso ed in
+formattazioni), i \textit{file stream} restano del tutto equivalenti ai file
+descriptor (sui quali sono basati), ed in particolare continua a valere quanto
+visto in sez.~\ref{sec:file_sharing} a proposito dell'accesso condiviso ed in
sez.~\ref{sec:file_access_control} per il controllo di accesso.
-\index{file!stream|)}
+\itindend{file~stream}
\subsection{Gli oggetti \type{FILE}}
\label{sec:file_FILE}
-Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
-chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di libreria e
-contengono tutte le informazioni necessarie a gestire le operazioni sugli
-stream, come la posizione corrente, lo stato del buffer e degli indicatori di
-stato e di fine del file.
+Per ragioni storiche la struttura di dati che rappresenta uno \textit{stream}
+è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di
+libreria e contengono tutte le informazioni necessarie a gestire le operazioni
+sugli \textit{stream}, come la posizione corrente, lo stato del buffer e degli
+indicatori di stato e di fine del file.
Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare
queste strutture (che sono dei \index{tipo!opaco} \textsl{tipi opachi}) ma
usare sempre puntatori del tipo \texttt{FILE *} ottenuti dalla libreria stessa
(tanto che in certi casi il termine di puntatore a file è diventato sinonimo
-di stream). Tutte le funzioni della libreria che operano sui file accettano
-come argomenti solo variabili di questo tipo, che diventa accessibile
-includendo l'header file \file{stdio.h}.
+di \textit{stream}). Tutte le funzioni della libreria che operano sui file
+accettano come argomenti solo variabili di questo tipo, che diventa
+accessibile includendo l'header file \file{stdio.h}.
-\subsection{Gli stream standard}
+\subsection{Gli \textit{stream standard}}
\label{sec:file_std_stream}
-Ai tre file descriptor standard (vedi sez.~\ref{sec:file_std_descr})
-aperti per ogni processo, corrispondono altrettanti stream, che
-rappresentano i canali standard di input/output prestabiliti; anche
-questi tre stream sono identificabili attraverso dei nomi simbolici
-definiti nell'header \file{stdio.h} che sono:
+Ai tre file descriptor standard (vedi sez.~\ref{sec:file_std_descr}) aperti
+per ogni processo, corrispondono altrettanti \textit{stream}, che
+rappresentano i canali standard di input/output prestabiliti; anche questi tre
+\textit{stream} sono identificabili attraverso dei nomi simbolici definiti
+nell'header \file{stdio.h} che sono:
\begin{basedescript}{\desclabelwidth{3.0cm}}
\item[\var{FILE *stdin}] Lo \textit{standard input} cioè il \textit{file
\label{sec:file_buffering}
La bufferizzazione è una delle caratteristiche principali dell'interfaccia
-degli stream; lo scopo è quello di ridurre al minimo il numero di system call
-(\func{read} o \func{write}) eseguite nelle operazioni di input/output. Questa
-funzionalità è assicurata automaticamente dalla libreria, ma costituisce anche
-uno degli aspetti più comunemente fraintesi, in particolare per quello che
-riguarda l'aspetto della scrittura dei dati sul file.
-
-I caratteri che vengono scritti su di uno stream normalmente vengono
+degli \textit{stream}; lo scopo è quello di ridurre al minimo il numero di
+system call (\func{read} o \func{write}) eseguite nelle operazioni di
+input/output. Questa funzionalità è assicurata automaticamente dalla libreria,
+ma costituisce anche uno degli aspetti più comunemente fraintesi, in
+particolare per quello che riguarda l'aspetto della scrittura dei dati sul
+file.
+
+I caratteri che vengono scritti su di uno \textit{stream} normalmente vengono
accumulati in un buffer e poi trasmessi in blocco\footnote{questa operazione
viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine
inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in
Per lo stesso motivo, in tutte le situazioni in cui si sta facendo
dell'input/output interattivo, bisognerà tenere presente le caratteristiche
delle operazioni di scaricamento dei dati, poiché non è detto che ad una
-scrittura sullo stream corrisponda una immediata scrittura sul dispositivo (la
-cosa è particolarmente evidente quando con le operazioni di input/output su
-terminale).
+scrittura sullo \textit{stream} corrisponda una immediata scrittura sul
+dispositivo (la cosa è particolarmente evidente quando con le operazioni di
+input/output su terminale).
Per rispondere ad esigenze diverse, lo standard definisce tre distinte
modalità in cui può essere eseguita la bufferizzazione, delle quali
altrimenti.
Il comportamento specificato per standard input e standard output vale anche
-per tutti i nuovi stream aperti da un processo; la selezione comunque avviene
-automaticamente, e la libreria apre lo stream nella modalità più opportuna a
-seconda del file o del dispositivo scelto.
+per tutti i nuovi \textit{stream} aperti da un processo; la selezione comunque
+avviene automaticamente, e la libreria apre lo \textit{stream} nella modalità
+più opportuna a seconda del file o del dispositivo scelto.
La modalità \textit{line buffered} è quella che necessita di maggiori
chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
anche prima che sia stato inviato un carattere di \textit{newline}.
Un secondo punto da tenere presente, particolarmente quando si ha a che fare
-con I/O interattivo, è che quando si effettua una lettura da uno stream che
-comporta l'accesso al kernel\footnote{questo vuol dire che lo stream da cui si
- legge è in modalità \textit{unbuffered}.} viene anche eseguito lo scarico di
-tutti i buffer degli stream in scrittura.
+con I/O interattivo, è che quando si effettua una lettura da uno
+\textit{stream} che comporta l'accesso al kernel\footnote{questo vuol dire che
+ lo \textit{stream} da cui si legge è in modalità \textit{unbuffered}.} viene
+anche eseguito lo scarico di tutti i buffer degli \textit{stream} in
+scrittura.
In sez.~\ref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle
opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
\section{Funzioni base}
\label{sec:file_ansi_base_func}
-Esamineremo in questa sezione le funzioni base dell'interfaccia degli stream,
-analoghe a quelle di sez.~\ref{sec:file_base_func} per i file descriptor. In
-particolare vedremo come aprire, leggere, scrivere e cambiare la posizione
-corrente in uno stream.
+Esamineremo in questa sezione le funzioni base dell'interfaccia degli
+\textit{stream}, analoghe a quelle di sez.~\ref{sec:file_base_func} per i file
+descriptor. In particolare vedremo come aprire, leggere, scrivere e cambiare
+la posizione corrente in uno \textit{stream}.
-\subsection{Apertura e chiusura di uno stream}
+\subsection{Apertura e chiusura di uno \textit{stream}}
\label{sec:file_fopen}
-Le funzioni che si possono usare per aprire uno stream sono solo tre:
+Le funzioni che si possono usare per aprire uno \textit{stream} sono solo tre:
\funcd{fopen}, \funcd{fdopen} e \funcd{freopen},\footnote{\func{fopen} e
\func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
dello standard POSIX.1.} i loro prototipi sono:
\funcdecl{FILE *fopen(const char *path, const char *mode)}
Apre il file specificato da \param{path}.
\funcdecl{FILE *fdopen(int fildes, const char *mode)}
- Associa uno stream al file descriptor \param{fildes}.
+ Associa uno \textit{stream} al file descriptor \param{fildes}.
\funcdecl{FILE *freopen(const char *path, const char *mode, FILE *stream)}
- Apre il file specificato da \param{path} associandolo allo stream
+ Apre il file specificato da \param{path} associandolo allo \textit{stream}
specificato da \param{stream}, se questo è già aperto prima lo chiude.
\bodydesc{Le funzioni ritornano un puntatore valido in caso di successo e
\func{fclose} e \func{fflush} per \func{freopen}.}
\end{functions}
-Normalmente la funzione che si usa per aprire uno stream è \func{fopen},
-essa apre il file specificato nella modalità specificata da
-\param{mode}, che è una stringa che deve iniziare con almeno uno dei
-valori indicati in tab.~\ref{tab:file_fopen_mode} (sono possibili varie
-estensioni che vedremo in seguito).
+Normalmente la funzione che si usa per aprire uno \textit{stream} è
+\func{fopen}, essa apre il file specificato nella modalità specificata da
+\param{mode}, che è una stringa che deve iniziare con almeno uno dei valori
+indicati in tab.~\ref{tab:file_fopen_mode} (sono possibili varie estensioni
+che vedremo in seguito).
L'uso più comune di \func{freopen} è per redirigere uno dei tre file
standard (vedi sez.~\ref{sec:file_std_stream}): il file \param{path} viene
-associato a \param{stream} e se questo è uno stream già aperto viene
+associato a \param{stream} e se questo è uno \textit{stream} già aperto viene
preventivamente chiuso.
-Infine \func{fdopen} viene usata per associare uno stream ad un file
+Infine \func{fdopen} viene usata per associare uno \textit{stream} ad un file
descriptor esistente ottenuto tramite una altra funzione (ad esempio con una
\func{open}, una \func{dup}, o una \func{pipe}) e serve quando si vogliono
-usare gli stream con file come le fifo o i socket, che non possono essere
-aperti con le funzioni delle librerie standard del C.
+usare gli \textit{stream} con file come le fifo o i socket, che non possono
+essere aperti con le funzioni delle librerie standard del C.
\begin{table}[htb]
\centering
\hline
\hline
\texttt{r} & Il file viene aperto, l'accesso viene posto in sola
- lettura, lo stream è posizionato all'inizio del file.\\
+ lettura, lo \textit{stream} è posizionato all'inizio del
+ file.\\
\texttt{r+}& Il file viene aperto, l'accesso viene posto in lettura e
- scrittura, lo stream è posizionato all'inizio del file.\\
+ scrittura, lo \textit{stream} è posizionato all'inizio del
+ file.\\
% \hline
\texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o
creato se non esiste), l'accesso viene posto in sola
- scrittura, lo stream è posizionato all'inizio del file.\\
+ scrittura, lo stream\textit{} è posizionato all'inizio del
+ file.\\
\texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o
creato se non esiste), l'accesso viene posto in scrittura e
- lettura, lo stream è posizionato all'inizio del file.\\
+ lettura, lo \textit{stream} è posizionato all'inizio del
+ file.\\
% \hline
\texttt{a} & Il file viene aperto (o creato se non esiste) in
\itindex{append~mode} \textit{append mode}, l'accesso viene
\texttt{x} & L'apertura fallisce se il file esiste già. \\
\hline
\end{tabular}
- \caption{Modalità di apertura di uno stream dello standard ANSI C che
- sono sempre presenti in qualunque sistema POSIX.}
+ \caption{Modalità di apertura di uno \textit{stream} dello standard ANSI C
+ che sono sempre presenti in qualunque sistema POSIX.}
\label{tab:file_fopen_mode}
\end{table}
Nel caso si usi \func{fdopen} i valori specificati da \param{mode} devono
essere compatibili con quelli con cui il file descriptor è stato aperto.
Inoltre i modi \cmd{w} e \cmd{w+} non troncano il file. La posizione nello
-stream viene impostata a quella corrente nel file descriptor, e le variabili
-di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono cancellate. Il
-file non viene duplicato e verrà chiuso alla chiusura dello stream.
+\textit{stream} viene impostata a quella corrente nel file descriptor, e le
+variabili di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono
+cancellate. Il file non viene duplicato e verrà chiuso alla chiusura dello
+\textit{stream}.
I nuovi file saranno creati secondo quanto visto in
sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
sufficiente a garantire la sincronizzazione.
-Una volta aperto lo stream, si può cambiare la modalità di bufferizzazione
-(si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non si è effettuato
-alcuna operazione di I/O sul file.
+Una volta aperto lo \textit{stream}, si può cambiare la modalità di
+bufferizzazione (si veda sez.~\ref{sec:file_buffering_ctrl}) fintanto che non
+si è effettuato alcuna operazione di I/O sul file.
-Uno stream viene chiuso con la funzione \funcd{fclose} il cui prototipo è:
+Uno \textit{stream} viene chiuso con la funzione \funcd{fclose} il cui
+prototipo è:
\begin{prototype}{stdio.h}{int fclose(FILE *stream)}
- Chiude lo stream \param{stream}.
+ Chiude lo \textit{stream} \param{stream}.
\bodydesc{Restituisce 0 in caso di successo e \val{EOF} in caso di errore,
nel qual caso imposta \var{errno} a \errval{EBADF} se il file descriptor
La funzione effettua lo scarico di tutti i dati presenti nei buffer di uscita
e scarta tutti i dati in ingresso; se era stato allocato un buffer per lo
-stream questo verrà rilasciato. La funzione effettua lo scarico solo per i
-dati presenti nei buffer in user space usati dalle \acr{glibc}; se si vuole
-essere sicuri che il kernel forzi la scrittura su disco occorrerà effettuare
-una \func{sync} (vedi sez.~\ref{sec:file_sync}).
+\textit{stream} questo verrà rilasciato. La funzione effettua lo scarico solo
+per i dati presenti nei buffer in user space usati dalle \acr{glibc}; se si
+vuole essere sicuri che il kernel forzi la scrittura su disco occorrerà
+effettuare una \func{sync} (vedi sez.~\ref{sec:file_sync}).
Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
GNU implementata dalle \acr{glibc}, accessibile avendo definito
\macro{\_GNU\_SOURCE}, il suo prototipo è:
\begin{prototype}{stdio.h}{int fcloseall(void)}
- Chiude tutti gli stream.
+ Chiude tutti gli \textit{stream}.
\bodydesc{Restituisce 0 se non ci sono errori ed \val{EOF} altrimenti.}
\end{prototype}
visto in sez.~\ref{sec:proc_conclusion}).
-\subsection{Lettura e scrittura su uno stream}
+\subsection{Lettura e scrittura su uno \textit{stream}}
\label{sec:file_io}
-Una delle caratteristiche più utili dell'interfaccia degli stream è la
-ricchezza delle funzioni disponibili per le operazioni di lettura e
-scrittura sui file. Sono infatti previste ben tre diverse modalità
-modalità di input/output non formattato:
+Una delle caratteristiche più utili dell'interfaccia degli \textit{stream} è
+la ricchezza delle funzioni disponibili per le operazioni di lettura e
+scrittura sui file. Sono infatti previste ben tre diverse modalità modalità di
+input/output non formattato:
\begin{enumerate*}
\item\textsl{binario} in cui legge/scrive un blocco di dati alla
volta, vedi sez.~\ref{sec:file_binary_io}.
\end{enumerate*}
ed inoltre la modalità di input/output formattato.
-A differenza dell'interfaccia dei file descriptor, con gli stream il
+A differenza dell'interfaccia dei file descriptor, con gli \textit{stream} il
raggiungimento della fine del file è considerato un errore, e viene
notificato come tale dai valori di uscita delle varie funzioni. Nella
maggior parte dei casi questo avviene con la restituzione del valore
negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
valori diversi.} definito anch'esso nell'header \file{stdlib.h}.
-Dato che le funzioni dell'interfaccia degli stream sono funzioni di libreria
-che si appoggiano a delle system call, esse non impostano direttamente la
-variabile \var{errno}, che mantiene il valore impostato dalla system call che
-ha riportato l'errore.
+Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
+libreria che si appoggiano a delle system call, esse non impostano
+direttamente la variabile \var{errno}, che mantiene il valore impostato dalla
+system call che ha riportato l'errore.
Siccome la condizione di end-of-file è anch'essa segnalata come errore, nasce
il problema di come distinguerla da un errore effettivo; basarsi solo sul
una altra occasione, (si veda sez.~\ref{sec:sys_errno} per i dettagli del
funzionamento di \var{errno}).
-Per questo motivo tutte le implementazioni delle librerie standard
-mantengono per ogni stream almeno due flag all'interno dell'oggetto
-\type{FILE}, il flag di \textit{end-of-file}, che segnala che si è
-raggiunta la fine del file in lettura, e quello di errore, che segnala
-la presenza di un qualche errore nelle operazioni di input/output;
-questi due flag possono essere riletti dalle funzioni \funcd{feof} e
-\funcd{ferror}, i cui prototipi sono:
+Per questo motivo tutte le implementazioni delle librerie standard mantengono
+per ogni \textit{stream} almeno due flag all'interno dell'oggetto \type{FILE},
+il flag di \textit{end-of-file}, che segnala che si è raggiunta la fine del
+file in lettura, e quello di errore, che segnala la presenza di un qualche
+errore nelle operazioni di input/output; questi due flag possono essere
+riletti dalle funzioni \funcd{feof} e \funcd{ferror}, i cui prototipi sono:
\begin{functions}
\headdecl{stdio.h}
\funcdecl{int feof(FILE *stream)}
\end{functions}
\noindent si tenga presente comunque che la lettura di questi flag segnala
soltanto che c'è stato un errore, o che si è raggiunta la fine del file in una
-qualunque operazione sullo stream, il controllo quindi deve essere effettuato
-ogni volta che si chiama una funzione di libreria.
+qualunque operazione sullo \textit{stream}, il controllo quindi deve essere
+effettuato ogni volta che si chiama una funzione di libreria.
Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
la funzione \funcd{clearerr}, il cui prototipo è:
corretta la causa di un errore per evitare di mantenere i flag attivi, così da
poter rilevare una successiva ulteriore condizione di errore. Di questa
funzione esiste una analoga \func{clearerr\_unlocked} che non esegue il blocco
-dello stream (vedi sez.~\ref{sec:file_stream_thread}).
+dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}).
\subsection{Input/output binario}
ma il numero di elementi.
La funzione \func{fread} legge sempre un numero intero di elementi, se
-incontra la fine del file l'oggetto letto parzialmente viene scartato
-(lo stesso avviene in caso di errore). In questo caso la posizione dello
-stream viene impostata alla fine del file (e non a quella corrispondente
-alla quantità di dati letti).
+incontra la fine del file l'oggetto letto parzialmente viene scartato (lo
+stesso avviene in caso di errore). In questo caso la posizione dello
+\textit{stream} viene impostata alla fine del file (e non a quella
+corrispondente alla quantità di dati letti).
In caso di errore (o fine del file per \func{fread}) entrambe le
funzioni restituiscono il numero di oggetti effettivamente letti o
Le \acr{glibc} definiscono altre due funzioni per l'I/O binario,
\funcd{fread\_unlocked} e \funcd{fwrite\_unlocked} che evitano il lock
-implicito dello stream, usato per dalla librerie per la gestione delle
+implicito dello \textit{stream}, usato per dalla librerie per la gestione delle
applicazioni \itindex{thread} \textit{multi-thread} (si veda
sez.~\ref{sec:file_stream_thread} per i dettagli), i loro prototipi sono:
\begin{functions}
size\_t nmemb, FILE *stream)}
\bodydesc{Le funzioni sono identiche alle analoghe \func{fread} e
- \func{fwrite} ma non acquisiscono il lock implicito sullo stream.}
+ \func{fwrite} ma non acquisiscono il lock implicito sullo \textit{stream}.}
\end{functions}
\noindent entrambe le funzioni sono estensioni GNU previste solo dalle
\acr{glibc}.
provvedono come estensione, per ciascuna delle funzioni precedenti,
un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
-il lock implicito dello stream.
+il lock implicito dello \textit{stream}.
Per compatibilità con SVID sono inoltre provviste anche due funzioni,
\funcd{getw} e \funcd{putw}, da usare per leggere e scrivere una \textit{word}
Uno degli usi più frequenti dell'input/output a caratteri è nei programmi di
\textit{parsing} in cui si analizza il testo; in questo contesto diventa utile
-poter analizzare il carattere successivo da uno stream senza estrarlo
+poter analizzare il carattere successivo da uno \textit{stream} senza estrarlo
effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
programma possa regolarsi avendo dato una \textsl{sbirciatina} a quello che
viene dopo.
lettura si chiama \funcd{ungetc} ed il suo prototipo è:
\begin{prototype}{stdio.h}{int ungetc(int c, FILE *stream)}
Rimanda indietro il carattere \param{c}, con un cast a \ctyp{unsigned
- char}, sullo stream \param{stream}.
+ char}, sullo \textit{stream} \param{stream}.
\bodydesc{La funzione ritorna \param{c} in caso di successo e
\val{EOF} in caso di errore.}
\acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
-implicito dello stream (vedi sez.~\ref{sec:file_stream_thread}). Come per le
-altre forma di I/O, dette funzioni hanno lo stesso nome della loro analoga
-normale, con l'aggiunta dell'estensione \code{\_unlocked}.
+implicito dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}). Come
+per le altre forma di I/O, dette funzioni hanno lo stesso nome della loro
+analoga normale, con l'aggiunta dell'estensione \code{\_unlocked}.
Come abbiamo visto, le funzioni di lettura per l'input/output di linea
previste dallo standard ANSI C presentano svariati inconvenienti. Benché
liberare \var{ptr} con una \func{free}.
Il valore di ritorno della funzione indica il numero di caratteri letti
-dallo stream (quindi compreso il newline, ma non lo zero di
+dallo \textit{stream} (quindi compreso il newline, ma non lo zero di
terminazione); questo permette anche di distinguere eventuali zeri letti
-dallo stream da quello inserito dalla funzione per terminare la linea.
+dallo \textit{stream} da quello inserito dalla funzione per terminare la linea.
Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
un errore la funzione restituisce -1.
La parte più complessa delle funzioni di scrittura formattata è il formato
della stringa \param{format} che indica le conversioni da fare, e da cui
deriva anche il numero degli argomenti che dovranno essere passati a seguire
-(si noti come tutte queste funzioni siano \index{variadic} \textit{variadic},
-prendendo un numero di argomenti variabile che dipende appunto da quello che
-si è specificato in \param{format}).
+(si noti come tutte queste funzioni siano \index{funzioni!variadic}
+\textit{variadic}, prendendo un numero di argomenti variabile che dipende
+appunto da quello che si è specificato in \param{format}).
\begin{table}[htb]
\centering
\end{table}
Una versione alternativa delle funzioni di output formattato, che permettono
-di usare il puntatore ad una lista di argomenti (vedi
-sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf}, \funcd{vfprintf} e
-\funcd{vsprintf}, i cui prototipi sono:
+di usare il puntatore ad una lista variabile \index{funzioni!variadic} di
+argomenti (vedi sez.~\ref{sec:proc_variadic}), sono \funcd{vprintf},
+\funcd{vfprintf} e \funcd{vsprintf}, i cui prototipi sono:
\begin{functions}
\headdecl{stdio.h}
\end{functions}
\noindent con queste funzioni diventa possibile selezionare gli argomenti che
si vogliono passare ad una funzione di stampa, passando direttamente la lista
-tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista degli
-argomenti dovrà essere opportunamente trattata (l'argomento è esaminato in
-sez.~\ref{sec:proc_variadic}), e dopo l'esecuzione della funzione l'argomento
+tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista
+variabile\index{funzioni!variadic} degli argomenti dovrà essere opportunamente
+trattata (l'argomento è esaminato in sez.~\ref{sec:proc_variadic}), e dopo
+l'esecuzione della funzione l'argomento
\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
\code{va\_end(ap)} ma in Linux questo non è necessario).
leak}.
Infine una ulteriore estensione GNU definisce le due funzioni \func{dprintf} e
-\func{vdprintf}, che prendono un file descriptor al posto dello stream. Altre
-estensioni permettono di scrivere con caratteri estesi. Anche queste funzioni,
-il cui nome è generato dalle precedenti funzioni aggiungendo una \texttt{w}
-davanti a \texttt{print}, sono trattate in dettaglio nella documentazione delle
-\acr{glibc}.
+\func{vdprintf}, che prendono un file descriptor al posto dello
+\textit{stream}. Altre estensioni permettono di scrivere con caratteri
+estesi. Anche queste funzioni, il cui nome è generato dalle precedenti
+funzioni aggiungendo una \texttt{w} davanti a \texttt{print}, sono trattate in
+dettaglio nella documentazione delle \acr{glibc}.
In corrispondenza alla famiglia di funzioni \func{printf} che si usano per
l'output formattato, l'input formattato viene eseguito con le funzioni della
primo elemento di disagio in quanto è molto facile dimenticarsi di questa
caratteristica.
-Le funzioni leggono i caratteri dallo stream (o dalla stringa) di input ed
-eseguono un confronto con quanto indicato in \param{format}, la sintassi di
-questo argomento è simile a quella usata per l'analogo di \func{printf}, ma ci
-sono varie differenze. Le funzioni di input infatti sono più orientate verso
-la lettura di testo libero che verso un input formattato in campi fissi. Uno
-spazio in \param{format} corrisponde con un numero qualunque di caratteri di
-separazione (che possono essere spazi, tabulatori, virgole ecc.), mentre
-caratteri diversi richiedono una corrispondenza esatta. Le direttive di
-conversione sono analoghe a quelle di \func{printf} e si trovano descritte in
-dettaglio nelle pagine di manuale e nel manuale delle \acr{glibc}.
+Le funzioni leggono i caratteri dallo \textit{stream} (o dalla stringa) di
+input ed eseguono un confronto con quanto indicato in \param{format}, la
+sintassi di questo argomento è simile a quella usata per l'analogo di
+\func{printf}, ma ci sono varie differenze. Le funzioni di input infatti sono
+più orientate verso la lettura di testo libero che verso un input formattato
+in campi fissi. Uno spazio in \param{format} corrisponde con un numero
+qualunque di caratteri di separazione (che possono essere spazi, tabulatori,
+virgole ecc.), mentre caratteri diversi richiedono una corrispondenza
+esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e
+si trovano descritte in dettaglio nelle pagine di manuale e nel manuale delle
+\acr{glibc}.
Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
eventuali caratteri diversi indicati dalla stringa di formato) effettuando le
conversioni richieste; in caso la corrispondenza fallisca (o la funzione non
sia in grado di effettuare una delle conversioni richieste) la scansione viene
interrotta immediatamente e la funzione ritorna lasciando posizionato lo
-stream al primo carattere che non corrisponde.
+\textit{stream} al primo carattere che non corrisponde.
Data la notevole complessità di uso di queste funzioni, che richiedono molta
cura nella definizione delle corrette stringhe di formato e sono facilmente
manuale \cite{bison}.} per generare un parser.
-\subsection{Posizionamento su uno stream}
+\subsection{Posizionamento su uno \textit{stream}}
\label{sec:file_fseek}
-Come per i file descriptor anche per gli stream è possibile spostarsi
+Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
all'interno di un file per effettuare operazioni di lettura o scrittura in un
punto prestabilito; sempre che l'operazione di riposizionamento sia supportata
-dal file sottostante lo stream, quando cioè si ha a che fare con quello che
-viene detto un file ad \textsl{accesso casuale}.\footnote{dato che in un
- sistema Unix esistono vari tipi di file, come le fifo ed i
+dal file sottostante lo \textit{stream}, quando cioè si ha a che fare con
+quello che viene detto un file ad \textsl{accesso casuale}.\footnote{dato che
+ in un sistema Unix esistono vari tipi di file, come le fifo ed i
\index{file!di~dispositivo} file di dispositivo, non è scontato che questo
sia sempre vero.}
In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è
espressa da un intero positivo, rappresentato dal tipo \type{off\_t}, il
problema è che alcune delle funzioni usate per il riposizionamento sugli
-stream originano dalle prime versioni di Unix, in cui questo tipo non era
-ancora stato definito, e che in altri sistemi non è detto che la posizione su
-un file venga sempre rappresentata con il numero di caratteri dall'inizio (ad
-esempio in VMS può essere rappresentata come numero di record, più l'offset
-rispetto al record corrente).
+\textit{stream} originano dalle prime versioni di Unix, in cui questo tipo non
+era ancora stato definito, e che in altri sistemi non è detto che la posizione
+su un file venga sempre rappresentata con il numero di caratteri dall'inizio
+(ad esempio in VMS può essere rappresentata come numero di record, più
+l'offset rispetto al record corrente).
Tutto questo comporta la presenza di diverse funzioni che eseguono
sostanzialmente le stesse operazioni, ma usano argomenti di tipo diverso. Le
funzioni tradizionali usate per il riposizionamento della posizione in uno
-stream sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
+\textit{stream} sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
\begin{functions}
\headdecl{stdio.h}
\funcdecl{int fseek(FILE *stream, long offset, int whence)} Sposta la
- posizione nello stream secondo quanto specificato tramite \param{offset}
- e \param{whence}.
+ posizione nello \textit{stream} secondo quanto specificato
+ tramite \param{offset} e \param{whence}.
- \funcdecl{void rewind(FILE *stream)} Riporta la posizione nello stream
- all'inizio del file.
+ \funcdecl{void rewind(FILE *stream)} Riporta la posizione nello
+ \textit{stream} all'inizio del file.
\end{functions}
L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
particolare \param{whence} assume gli stessi valori già visti in
sez.~\ref{sec:file_lseek}. La funzione restituisce 0 in caso di successo e -1
in caso di errore. La funzione \func{rewind} riporta semplicemente la
-posizione corrente all'inizio dello stream, ma non esattamente equivalente ad
-una \code{fseek(stream, 0L, SEEK\_SET)} in quanto vengono cancellati anche i
-flag di errore e fine del file.
+posizione corrente all'inizio dello \textit{stream}, ma non esattamente
+equivalente ad una \code{fseek(stream, 0L, SEEK\_SET)} in quanto vengono
+cancellati anche i flag di errore e fine del file.
Per ottenere la posizione corrente si usa invece la funzione \funcd{ftell}, il
cui prototipo è:
\begin{prototype}{stdio.h}{long ftell(FILE *stream)}
- Legge la posizione attuale nello stream \param{stream}.
+ Legge la posizione attuale nello \textit{stream} \param{stream}.
\bodydesc{La funzione restituisce la posizione corrente, o -1 in caso
di fallimento, che può esser dovuto sia al fatto che il file non
essere espressa con un \ctyp{long int}}
\end{prototype}
\noindent la funzione restituisce la posizione come numero di byte
-dall'inizio dello stream.
+dall'inizio dello \textit{stream}.
Queste funzioni esprimono tutte la posizione nel file come un \ctyp{long int}.
Dato che (ad esempio quando si usa un filesystem indicizzato a 64 bit) questo
\headdecl{stdio.h}
\funcdecl{int fsetpos(FILE *stream, fpos\_t *pos)} Imposta la posizione
- corrente nello stream \param{stream} al valore specificato da \param{pos}.
+ corrente nello \textit{stream} \param{stream} al valore specificato
+ da \param{pos}.
\funcdecl{int fgetpos(FILE *stream, fpos\_t *pos)} Legge la posizione
- corrente nello stream \param{stream} e la scrive in \param{pos}.
+ corrente nello \textit{stream} \param{stream} e la scrive in \param{pos}.
\bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
errore.}
\label{sec:file_stream_adv_func}
In questa sezione esamineremo alcune funzioni avanzate che permettono di
-eseguire operazioni particolari sugli stream, come leggerne gli attributi,
-controllarne le modalità di bufferizzazione, gestire direttamente i lock
-impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
+eseguire operazioni particolari sugli \textit{stream}, come leggerne gli
+attributi, controllarne le modalità di bufferizzazione, gestire direttamente i
+lock impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
\subsection{Le funzioni di controllo}
Al contrario di quanto avviene con i file descriptor, le librerie standard del
C non prevedono nessuna funzione come la \func{fcntl} per il controllo degli
-attributi dei file. Però, dato che ogni stream si appoggia ad un file
+attributi dei file. Però, dato che ogni \textit{stream} si appoggia ad un file
descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
il prototipo della funzione è:
\begin{prototype}{stdio.h}{int fileno(FILE *stream)}
- Legge il file descriptor sottostante lo stream \param{stream}.
+ Legge il file descriptor sottostante lo \textit{stream} \param{stream}.
\bodydesc{Restituisce il numero del file descriptor in caso di successo, e
-1 qualora \param{stream} non sia valido, nel qual caso imposta
\noindent ed in questo modo diventa possibile usare direttamente \func{fcntl}.
Questo permette di accedere agli attributi del file descriptor sottostante lo
-stream, ma non ci dà nessuna informazione riguardo alle proprietà dello stream
-medesimo. Le \acr{glibc} però supportano alcune estensioni derivate da
-Solaris, che permettono di ottenere informazioni utili.
-
-Ad esempio in certi casi può essere necessario sapere se un certo stream è
-accessibile in lettura o scrittura. In genere questa informazione non è
-disponibile, e si deve ricordare come il file è stato aperto. La cosa può
-essere complessa se le operazioni vengono effettuate in una subroutine, che a
-questo punto necessiterà di informazioni aggiuntive rispetto al semplice
-puntatore allo stream; questo può essere evitato con le due funzioni
-\funcd{\_\_freadable} e \funcd{\_\_fwritable} i cui prototipi sono:
+\textit{stream}, ma non ci dà nessuna informazione riguardo alle proprietà
+dello \textit{stream} medesimo. Le \acr{glibc} però supportano alcune
+estensioni derivate da Solaris, che permettono di ottenere informazioni utili.
+
+Ad esempio in certi casi può essere necessario sapere se un certo
+\textit{stream} è accessibile in lettura o scrittura. In genere questa
+informazione non è disponibile, e si deve ricordare come il file è stato
+aperto. La cosa può essere complessa se le operazioni vengono effettuate in
+una subroutine, che a questo punto necessiterà di informazioni aggiuntive
+rispetto al semplice puntatore allo \textit{stream}; questo può essere evitato
+con le due funzioni \funcd{\_\_freadable} e \funcd{\_\_fwritable} i cui
+prototipi sono:
\begin{functions}
\headdecl{stdio\_ext.h}
\funcdecl{int \_\_freadable(FILE *stream)}
\end{functions}
\noindent che permettono di ottenere questa informazione.
-La conoscenza dell'ultima operazione effettuata su uno stream aperto è utile
-in quanto permette di trarre conclusioni sullo stato del buffer e del suo
-contenuto. Altre due funzioni, \funcd{\_\_freading} e \funcd{\_\_fwriting}
+La conoscenza dell'ultima operazione effettuata su uno \textit{stream} aperto
+è utile in quanto permette di trarre conclusioni sullo stato del buffer e del
+suo contenuto. Altre due funzioni, \funcd{\_\_freading} e \funcd{\_\_fwriting}
servono a tale scopo, il loro prototipo è:
\begin{functions}
\headdecl{stdio\_ext.h}
\end{functions}
Le due funzioni permettono di determinare di che tipo è stata l'ultima
-operazione eseguita su uno stream aperto in lettura/scrittura; ovviamente se
-uno stream è aperto in sola lettura (o sola scrittura) la modalità dell'ultima
-operazione è sempre determinata; l'unica ambiguità è quando non sono state
-ancora eseguite operazioni, in questo caso le funzioni rispondono come se una
-operazione ci fosse comunque stata.
+operazione eseguita su uno \textit{stream} aperto in lettura/scrittura;
+ovviamente se uno \textit{stream} è aperto in sola lettura (o sola scrittura)
+la modalità dell'ultima operazione è sempre determinata; l'unica ambiguità è
+quando non sono state ancora eseguite operazioni, in questo caso le funzioni
+rispondono come se una operazione ci fosse comunque stata.
\subsection{Il controllo della bufferizzazione}
\label{sec:file_buffering_ctrl}
Come accennato in sez.~\ref{sec:file_buffering} le librerie definiscono una
-serie di funzioni che permettono di controllare il comportamento degli stream;
-se non si è specificato nulla, la modalità di buffering viene decisa
-autonomamente sulla base del tipo di file sottostante, ed i buffer vengono
-allocati automaticamente.
+serie di funzioni che permettono di controllare il comportamento degli
+\textit{stream}; se non si è specificato nulla, la modalità di buffering viene
+decisa autonomamente sulla base del tipo di file sottostante, ed i buffer
+vengono allocati automaticamente.
-Però una volta che si sia aperto lo stream (ma prima di aver compiuto
+Però una volta che si sia aperto lo \textit{stream} (ma prima di aver compiuto
operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
suo prototipo è:
\begin{prototype}{stdio.h}{int setvbuf(FILE *stream, char *buf, int mode,
size\_t size)}
- Imposta la bufferizzazione dello stream \param{stream} nella modalità
- indicata da \param{mode}, usando \param{buf} come buffer di lunghezza
+ Imposta la bufferizzazione dello \textit{stream} \param{stream} nella
+ modalità indicata da \param{mode}, usando \param{buf} come buffer di
+ lunghezza
\param{size}.
\bodydesc{Restituisce zero in caso di successo, ed un valore qualunque in
Ovviamente se si usa un buffer specificato dall'utente questo deve essere
stato allocato e rimanere disponibile per tutto il tempo in cui si opera sullo
-stream. In genere conviene allocarlo con \func{malloc} e disallocarlo dopo la
-chiusura del file; ma fintanto che il file è usato all'interno di una
+\textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
+dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
funzione, può anche essere usata una \index{variabili!automatiche} variabile
automatica. In \file{stdio.h} è definita la macro \const{BUFSIZ}, che indica
-le dimensioni generiche del buffer di uno stream; queste vengono usate dalla
-funzione \func{setbuf}. Non è detto però che tale dimensione corrisponda
-sempre al valore ottimale (che può variare a seconda del dispositivo).
+le dimensioni generiche del buffer di uno \textit{stream}; queste vengono
+usate dalla funzione \func{setbuf}. Non è detto però che tale dimensione
+corrisponda sempre al valore ottimale (che può variare a seconda del
+dispositivo).
Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
(come delle scritture accidentali sul buffer) e non assicura la scelta delle
vengono sempre ignorati.
Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
-gestione della bufferizzazione di uno stream: \funcd{setbuf}, \funcd{setbuffer}
-e \funcd{setlinebuf}; i loro prototipi sono:
+gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
+\funcd{setbuffer} e \funcd{setlinebuf}; i loro prototipi sono:
\begin{functions}
\headdecl{stdio.h}
la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
- \funcdecl{void setlinebuf(FILE *stream)} Pone lo stream in modalità
+ \funcdecl{void setlinebuf(FILE *stream)} Pone lo \textit{stream} in modalità
\textit{line buffered}.
\end{functions}
\noindent tutte queste funzioni sono realizzate con opportune chiamate a
BSD. Infine le \acr{glibc} provvedono le funzioni non standard\footnote{anche
queste funzioni sono originarie di Solaris.} \funcd{\_\_flbf} e
\funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
-di uno stream; i cui prototipi sono:
+di uno \textit{stream}; i cui prototipi sono:
\begin{functions}
\headdecl{stdio\_ext.h}
\funcd{fflush}, il suo prototipo è:
\begin{prototype}{stdio.h}{int fflush(FILE *stream)}
- Forza la scrittura di tutti i dati bufferizzati dello stream \param{stream}.
+ Forza la scrittura di tutti i dati bufferizzati dello
+ \textit{stream} \param{stream}.
\bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
dello stream.
Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
-stream aperti. Esistono però circostanze, ad esempio quando si vuole essere
-sicuri che sia stato eseguito tutto l'output su terminale, in cui serve poter
-effettuare lo scarico dei dati solo per gli stream in modalità line buffered;
-per questo motivo le \acr{glibc} supportano una estensione di Solaris, la
-funzione \funcd{\_flushlbf}, il cui prototipo è:
+\textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
+essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
+poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
+line buffered; per questo motivo le \acr{glibc} supportano una estensione di
+Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
\begin{prototype}{stdio-ext.h}{void \_flushlbf(void)}
- Forza la scrittura di tutti i dati bufferizzati degli stream in modalità
- line buffered.
+ Forza la scrittura di tutti i dati bufferizzati degli \textit{stream} in
+ modalità line buffered.
\end{prototype}
Si ricordi comunque che lo scarico dei dati dai buffer effettuato da queste
pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
\begin{prototype}{stdio.h}{int fpurge(FILE *stream)}
- Cancella i buffer di input e di output dello stream \param{stream}.
+ Cancella i buffer di input e di output dello \textit{stream} \param{stream}.
\bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
errore.}
\itindbeg{thread}
-Gli stream possono essere usati in applicazioni \textit{multi-thread} allo
-stesso modo in cui sono usati nelle applicazioni normali, ma si deve essere
-consapevoli delle possibili complicazioni anche quando non si usano i
+Gli \textit{stream} possono essere usati in applicazioni \textit{multi-thread}
+allo stesso modo in cui sono usati nelle applicazioni normali, ma si deve
+essere consapevoli delle possibili complicazioni anche quando non si usano i
\textit{thread}, dato che l'implementazione delle librerie è influenzata
pesantemente dalle richieste necessarie per garantirne l'uso con i
\textit{thread}.
Lo standard POSIX richiede che le operazioni sui file siano atomiche rispetto
ai \textit{thread}, per questo le operazioni sui buffer effettuate dalle
-funzioni di libreria durante la lettura e la scrittura di uno stream devono
-essere opportunamente protette (in quanto il sistema assicura l'atomicità solo
-per le system call). Questo viene fatto associando ad ogni stream un opportuno
-blocco che deve essere implicitamente acquisito prima dell'esecuzione di
-qualunque operazione.
+funzioni di libreria durante la lettura e la scrittura di uno \textit{stream}
+devono essere opportunamente protette (in quanto il sistema assicura
+l'atomicità solo per le system call). Questo viene fatto associando ad ogni
+\textit{stream} un opportuno blocco che deve essere implicitamente acquisito
+prima dell'esecuzione di qualunque operazione.
Ci sono comunque situazioni in cui questo non basta, come quando un
-\textit{thread} necessita di compiere più di una operazione sullo stream
-atomicamente, per questo motivo le librerie provvedono anche delle funzioni
-\funcd{flockfile}, \funcd{ftrylockfile} e \funcd{funlockfile}, che permettono
-la gestione esplicita dei blocchi sugli stream; esse sono disponibili
-definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro prototipi sono:
+\textit{thread} necessita di compiere più di una operazione sullo
+\textit{stream} atomicamente, per questo motivo le librerie provvedono anche
+delle funzioni \funcd{flockfile}, \funcd{ftrylockfile} e \funcd{funlockfile},
+che permettono la gestione esplicita dei blocchi sugli \textit{stream}; esse
+sono disponibili definendo \macro{\_POSIX\_THREAD\_SAFE\_FUNCTIONS} ed i loro
+prototipi sono:
\begin{functions}
\headdecl{stdio.h}
\funcdecl{void flockfile(FILE *stream)} Esegue l'acquisizione del lock dello
- stream \param{stream}, bloccandosi se il lock non è disponibile.
+ \textit{stream} \param{stream}, bloccandosi se il lock non è disponibile.
\funcdecl{int ftrylockfile(FILE *stream)} Tenta l'acquisizione del lock
- dello stream \param{stream}, senza bloccarsi se il lock non è disponibile.
- Ritorna zero in caso di acquisizione del lock, diverso da zero altrimenti.
+ dello \textit{stream} \param{stream}, senza bloccarsi se il lock non è
+ disponibile. Ritorna zero in caso di acquisizione del lock, diverso da zero
+ altrimenti.
\funcdecl{void funlockfile(FILE *stream)} Rilascia il lock dello
- stream \param{stream}.
+ \textit{stream} \param{stream}.
\end{functions}
\noindent con queste funzioni diventa possibile acquisire un blocco ed
eseguire tutte le operazioni volute, per poi rilasciarlo.
Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di
-blocco non sono del tutto indolori, e quando il locking dello stream non è
-necessario (come in tutti i programmi che non usano i \textit{thread}), tutta
-la procedura può comportare dei costi pesanti in termini di prestazioni. Per
-questo motivo abbiamo visto come alle usuali funzioni di I/O non formattato
-siano associate delle versioni \code{\_unlocked} (alcune previste dallo stesso
-standard POSIX, altre aggiunte come estensioni dalle \acr{glibc}) che possono
-essere usate quando il locking non serve\footnote{in certi casi dette funzioni
- possono essere usate, visto che sono molto più efficienti, anche in caso di
- necessità di locking, una volta che questo sia stato acquisito manualmente.}
-con prestazioni molto più elevate, dato che spesso queste versioni (come
-accade per \func{getc} e \func{putc}) sono realizzate come macro.
+blocco non sono del tutto indolori, e quando il locking dello \textit{stream}
+non è necessario (come in tutti i programmi che non usano i \textit{thread}),
+tutta la procedura può comportare dei costi pesanti in termini di
+prestazioni. Per questo motivo abbiamo visto come alle usuali funzioni di I/O
+non formattato siano associate delle versioni \code{\_unlocked} (alcune
+previste dallo stesso standard POSIX, altre aggiunte come estensioni dalle
+\acr{glibc}) che possono essere usate quando il locking non serve\footnote{in
+ certi casi dette funzioni possono essere usate, visto che sono molto più
+ efficienti, anche in caso di necessità di locking, una volta che questo sia
+ stato acquisito manualmente.} con prestazioni molto più elevate, dato che
+spesso queste versioni (come accade per \func{getc} e \func{putc}) sono
+realizzate come macro.
La sostituzione di tutte le funzioni di I/O con le relative versioni
\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
lavoro abbastanza noioso; per questo motivo le \acr{glibc} forniscono al
programmatore pigro un'altra via\footnote{anche questa mutuata da estensioni
introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il
-locking degli stream: l'uso della funzione \funcd{\_\_fsetlocking}, il cui
-prototipo è:
+locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
+il cui prototipo è:
\begin{prototype}{stdio\_ext.h}{int \_\_fsetlocking (FILE *stream, int type)}
Specifica o richiede a seconda del valore di \param{type} la modalità in cui
le operazioni di I/O su \param{stream} vengono effettuate rispetto
- all'acquisizione implicita del blocco sullo stream.
+ all'acquisizione implicita del blocco sullo \textit{stream}.
- \bodydesc{Restituisce lo stato di locking interno dello stream con uno dei
- valori \const{FSETLOCKING\_INTERNAL} o \const{FSETLOCKING\_BYCALLER}.}
+ \bodydesc{Restituisce lo stato di locking interno dello \textit{stream} con
+ uno dei valori \const{FSETLOCKING\_INTERNAL} o
+ \const{FSETLOCKING\_BYCALLER}.}
\end{prototype}
-La funzione imposta o legge lo stato della modalità di operazione di uno stream
-nei confronti del locking a seconda del valore specificato con \param{type},
-che può essere uno dei seguenti:
+La funzione imposta o legge lo stato della modalità di operazione di uno
+\textit{stream} nei confronti del locking a seconda del valore specificato
+con \param{type}, che può essere uno dei seguenti:
\begin{basedescript}{\desclabelwidth{4.0cm}}
-\item[\const{FSETLOCKING\_INTERNAL}] Lo stream userà da ora in poi il blocco
- implicito predefinito.
+\item[\const{FSETLOCKING\_INTERNAL}] Lo \textit{stream} userà da ora in poi il
+ blocco implicito predefinito.
\item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
- dover gestire da solo il locking dello stream.
+ dover gestire da solo il locking dello \textit{stream}.
\item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
- di blocco dello stream.
+ di blocco dello \textit{stream}.
\end{basedescript}
\itindend{thread}
Esamineremo in questo capitolo la prima delle due interfacce di programmazione
-per i file, quella dei \index{file!descriptor} \textit{file descriptor},
+per i file, quella dei \itindex{file~descriptor} \textit{file descriptor},
nativa di Unix. Questa è l'interfaccia di basso livello provvista direttamente
dalle system call, che non prevede funzionalità evolute come la
bufferizzazione o funzioni di lettura o scrittura formattata, e sulla quale è
\subsection{L'architettura dei \textit{file descriptor}}
\label{sec:file_fd}
-\index{file!descriptor|(}
+\itindbeg{file~descriptor}
Per poter accedere al contenuto di un file occorre creare un canale di
comunicazione con il kernel che renda possibile operare su di esso (si ricordi
La \itindex{process~table} \textit{process table} è una tabella che contiene
una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
-costituita da una struttura di tipo \struct{task\_struct} nella quale sono
+costituita da una struttura di tipo \kstruct{task\_struct} nella quale sono
raccolte tutte le informazioni relative al processo; fra queste informazioni
c'è anche il puntatore ad una ulteriore struttura di tipo
-\struct{files\_struct}, in cui sono contenute le informazioni relative ai file
-che il processo ha aperto, ed in particolare:
+\kstruct{files\_struct}, in cui sono contenute le informazioni relative ai
+file che il processo ha aperto, ed in particolare:
\begin{itemize*}
\item i flag relativi ai file descriptor.
\item il numero di file aperti.
capire i dettagli del funzionamento dell'interfaccia dei \textit{file
descriptor}.
-\index{file!descriptor|)}
-
\begin{figure}[!htb]
\centering
\includegraphics[width=13cm]{img/procfile}
\label{fig:file_proc_file}
\end{figure}
+\itindend{file~descriptor}
\subsection{I file standard}
In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
-quanto appena detto, avranno come \index{file!descriptor} \textit{file
+quanto appena detto, avranno come \itindex{file~descriptor} \textit{file
descriptor} i valori 0, 1 e 2. Benché questa sia soltanto una convenzione,
essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
portare a gravi problemi di interoperabilità.
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
numero di file aperti era anche soggetto ad un limite massimo dato dalle
dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
-descriptor dentro \struct{file\_struct}; questo limite intrinseco nei kernel
+descriptor dentro \kstruct{files\_struct}; questo limite intrinseco nei kernel
più recenti non sussiste più, dato che si è passati da un vettore ad una
lista, ma restano i limiti imposti dall'amministratore (vedi
sez.~\ref{sec:sys_limits}).
La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
quella che crea l'associazione fra un \itindex{pathname} \textit{pathname} ed
-un \index{file!descriptor} file descriptor, il suo prototipo è:
+un \itindex{file~descriptor} file descriptor, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
\end{prototype}
La chiusura di un file rilascia ogni blocco (il \textit{file locking}
-\index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che il
+\itindex{file~locking} è trattato in sez.~\ref{sec:file_locking}) che il
processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
\itindex{file~table} \textit{file table} vengono rilasciate. Infine se il file
maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
di eseguire alcune operazioni di scrittura in maniera coordinata anche senza
utilizzare meccanismi di sincronizzazione più complessi (come il
-\index{file!locking} \textit{file locking}, che esamineremo in
+\itindex{file~locking} \textit{file locking}, che esamineremo in
sez.~\ref{sec:file_locking}).
Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
in Linux il valore utilizzato è di 5 secondi; con le nuove versioni\footnote{a
partire dal kernel 2.2.8} poi, è il kernel che si occupa direttamente di
tutto quanto attraverso il demone interno \cmd{bdflush}, il cui comportamento
-può essere controllato attraverso il file \procfile{/proc/sys/vm/bdflush} (per
+può essere controllato attraverso il file \sysctlfile{vm/bdflush} (per
il significato dei valori si può leggere la documentazione allegata al kernel
in \file{Documentation/sysctl/vm.txt}).
gestione sia delle loro proprietà, che di tutta una serie di ulteriori
funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
gestiscono con questa funzione varie modalità di I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_operation}) e il \index{file!locking}
+ sez.~\ref{sec:file_asyncronous_operation}) e il \itindex{file~locking}
\textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
Per queste operazioni di manipolazione e di controllo delle varie proprietà e
(come vedremo in sez.~\ref{sec:file_asyncronous_io}).\footnote{i due comandi
\const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
Linux.}
-\item[\const{F\_SETLEASE}] imposta o rimuove un \index{file!lease}
+\item[\const{F\_SETLEASE}] imposta o rimuove un \itindex{file~lease}
\textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui il
processo che detiene un \textit{lease} su un file riceve una notifica
valore nullo in caso di successo o $-1$ in caso di errore. Questa
funzionalità avanzata è trattata in dettaglio in
sez.~\ref{sec:file_asyncronous_lease}.
-\item[\const{F\_GETLEASE}] restituisce il tipo di \index{file!lease}
+\item[\const{F\_GETLEASE}] restituisce il tipo di \itindex{file~lease}
\textit{file lease} che il processo detiene nei confronti del file
descriptor \var{fd} o $-1$ in caso di errore. Con questo comando il terzo
argomento può essere omesso. Questa funzionalità avanzata è trattata in
relative. In particolare le tematiche relative all'I/O asincrono e ai vari
meccanismi di notifica saranno trattate in maniera esaustiva in
sez.~\ref{sec:file_asyncronous_access} mentre quelle relative al
-\index{file!locking} \textit{file locking} saranno esaminate in
+\itindex{file~locking} \textit{file locking} saranno esaminate in
sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
trattato in sez.~\ref{sec:sock_ctrl_func}.
\include{intro}
\include{process}
\include{prochand}
-%\include{fileintro}
\include{filedir}
\include{fileunix}
\include{filestd}
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}
altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
kernel, andando a modificarne la definizione nei relativi header file. A
partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
- scrivendo sui file \procrelfile{/proc/sys/kernel}{shmmni},
- \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/kernel}{sem}
+ scrivendo sui file \sysctlrelfile{kernel}{shmmni},
+ \sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem}
di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
negli header e corrispondenti alle prime tre costanti riportate in
tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
-file \procrelfile{/proc/sys/kernel}{msgmax},
-\procrelfile{/proc/sys/kernel}{msgmnb} e
-\procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}.
+file \sysctlrelfile{kernel}{msgmax},
+\sysctlrelfile{kernel}{msgmnb} e
+\sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}.
\begin{figure}[!htb]
\centering \includegraphics[width=13cm]{img/mqstruct}
serie di limiti, i cui valori sono associati ad altrettante costanti, che si
sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
-direttamente nel file \procfile{/proc/sys/kernel/sem}.
+direttamente nel file \sysctlfile{kernel/sem}.
La funzione che permette di effettuare le varie operazioni di controllo sui
semafori (fra le quali, come accennato, è impropriamente compresa anche la
sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
-problemi, usando il \index{file!locking} \textit{file locking}.
+problemi, usando il \itindex{file~locking} \textit{file locking}.
\subsection{Memoria condivisa}
& \textbf{Significato} \\
\hline
\hline
- \const{SHMALL}& 0x200000&\procrelfile{/proc/sys/kernel}{shmall}
+ \const{SHMALL}& 0x200000&\sysctlrelfile{kernel}{shmall}
& Numero massimo di pagine che
possono essere usate per i segmenti di
memoria condivisa.\\
- \const{SHMMAX}&0x2000000&\procrelfile{/proc/sys/kernel}{shmmax}
+ \const{SHMMAX}&0x2000000&\sysctlrelfile{kernel}{shmmax}
& Dimensione massima di un segmento di memoria
condivisa.\\
- \const{SHMMNI}& 4096&\procrelfile{/proc/sys/kernel}{msgmni}
+ \const{SHMMNI}& 4096&\sysctlrelfile{kernel}{msgmni}
& Numero massimo di segmenti di memoria condivisa
presenti nel kernel.\\
\const{SHMMIN}& 1& --- & Dimensione minima di un segmento di
Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
illustrati in precedenza, la tecnica alternativa di sincronizzazione più
-comune è quella di fare ricorso al \index{file!locking} \textit{file locking}
-(trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file
-creato per l'occasione per ottenere un write lock. In questo modo potremo
+comune è quella di fare ricorso al \itindex{file~locking} \textit{file
+ locking} (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un
+file creato per l'occasione per ottenere un write lock. In questo modo potremo
usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
fatta con un write lock metterà automaticamente il processo in stato di
\end{minipage}
\normalsize
\caption{Il codice delle funzioni che permettono per la gestione dei
- \textit{mutex} con il \index{file!locking} \textit{file locking}.}
+ \textit{mutex} con il \itindex{file~locking} \textit{file locking}.}
\label{fig:ipc_flock_mutex}
\end{figure}
Il codice delle varie funzioni usate per implementare un mutex utilizzando il
-\textit{file locking} \index{file!locking} è riportato in
+\textit{file locking} \itindex{file~locking} è riportato in
fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
analoga alle precedenti funzioni che usano i semafori, anche se le due
interfacce non possono essere completamente equivalenti, specie per quanto
La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
precedente, è stata definita per mantenere una analogia con la corrispondente
funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
-aprire il file da usare per il \index{file!locking} \textit{file locking},
+aprire il file da usare per il \itindex{file~locking} \textit{file locking},
solo che in questo caso le opzioni di \func{open} sono tali che il file in
questione deve esistere di già.
rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il
rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
-chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file
+chiamata a \func{fcntl}. Avendo usato il \itindex{file~locking} \textit{file
locking} in semantica POSIX (si riveda quanto detto
sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
eseguito il lock può sbloccare il mutex.
--- /dev/null
+struct file_operations {
+ struct module *owner;
+ loff_t (*llseek) (struct file *, loff_t, int);
+ ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
+ ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
+ ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
+ ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
+ int (*readdir) (struct file *, void *, filldir_t);
+ unsigned int (*poll) (struct file *, struct poll_table_struct *);
+ long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
+ long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
+ int (*mmap) (struct file *, struct vm_area_struct *);
+ int (*open) (struct inode *, struct file *);
+ int (*flush) (struct file *, fl_owner_t id);
+ int (*release) (struct inode *, struct file *);
+ int (*fsync) (struct file *, int datasync);
+ int (*aio_fsync) (struct kiocb *, int datasync);
+ int (*fasync) (int, struct file *, int);
+ int (*lock) (struct file *, int, struct file_lock *);
+ ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
+ unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
+ int (*check_flags)(int);
+ int (*flock) (struct file *, int, struct file_lock *);
+ ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
+ ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
+ int (*setlease)(struct file *, long, struct file_lock **);
+};
--- /dev/null
+struct file_system_type {
+ const char *name;
+ int fs_flags;
+ int (*get_sb) (struct file_system_type *, int,
+ const char *, void *, struct vfsmount *);
+ struct dentry *(*mount) (struct file_system_type *, int,
+ const char *, void *);
+ void (*kill_sb) (struct super_block *);
+ struct module *owner;
+ struct file_system_type * next;
+ struct list_head fs_supers;
+
+ struct lock_class_key s_lock_key;
+ ...
+};
--- /dev/null
+struct inode {
+ ...
+ unsigned long i_ino;
+ atomic_t i_count;
+ unsigned int i_nlink;
+ uid_t i_uid;
+ gid_t i_gid;
+ dev_t i_rdev;
+ unsigned int i_blkbits;
+ u64 i_version;
+ loff_t i_size;
+ struct timespec i_atime;
+ struct timespec i_mtime;
+ struct timespec i_ctime;
+ ...
+ const struct inode_operations *i_op;
+ const struct file_operations *i_fop;
+ ...
+};
+
--- /dev/null
+struct inode_operations {
+ int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
+ struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
+ int (*link) (struct dentry *,struct inode *,struct dentry *);
+ int (*unlink) (struct inode *,struct dentry *);
+ int (*symlink) (struct inode *,struct dentry *,const char *);
+ int (*mkdir) (struct inode *,struct dentry *,int);
+ int (*rmdir) (struct inode *,struct dentry *);
+ int (*mknod) (struct inode *,struct dentry *,int,dev_t);
+ int (*rename) (struct inode *, struct dentry *,
+ struct inode *, struct dentry *);
+ int (*readlink) (struct dentry *, char __user *,int);
+ void * (*follow_link) (struct dentry *, struct nameidata *);
+ void (*put_link) (struct dentry *, struct nameidata *, void *);
+ void (*truncate) (struct inode *);
+ int (*permission) (struct inode *, int);
+ int (*check_acl)(struct inode *, int);
+ int (*setattr) (struct dentry *, struct iattr *);
+ int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
+ int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
+ ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
+ int (*removexattr) (struct dentry *, const char *);
+ void (*truncate_range)(struct inode *, loff_t, loff_t);
+ long (*fallocate)(struct inode *inode, int mode, loff_t offset,
+ loff_t len);
+ int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start,
+ u64 len);
+};
%\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
}
+\newcommand{\sysctlfile}[1]{%
+\index{file!file di controllo (sotto \texttt{/proc/sys})!{#1}@{{\tt {#1}}}}\texttt{/proc/sys/#1}%
+%\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
+} % /proc/sys file name
+
+\newcommand{\sysctlrelfile}[2]{%
+\index{file!file di controllo (sotto \texttt{/proc/sys})!{#1/#2}@{{\tt {#1/#2}}}}\texttt{#2}%
+%\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
+} % /proc/sys file name
+
+\newcommand{\kstruct}[1]{%
+\index{struttura dati del kernel!{#1}@{{\tt {#1}}}}\texttt{#1}%
+%\index{#1@{{\tt {#1}} (struttura dati)}}\texttt{#1}%
+} % struttura dati
+\newcommand{\kstructd}[1]{%
+\index{struttura dati del kernel!{#1}@{{\tt {#1}}}!definizione di}\texttt{#1}%
+%\index{#1@{{\tt {#1}} (struttura dati)}!definizione di}\texttt{#1}%
+} % struttura dati
\newcommand{\type}[1]{%
\index{tipo di dato!{#1}@{{\tt {#1}}}}\texttt{#1}%
%\index{#1@{{\tt {#1}} (tipo)}}\texttt{#1}%
\subsection{Il passaggio di un numero variabile di argomenti}
\label{sec:proc_variadic}
+\index{funzioni!variadic|(}
+
Come vedremo nei capitoli successivi, non sempre è possibile specificare un
numero fisso di argomenti per una funzione. Lo standard ISO C prevede nella
-sua sintassi la possibilità di definire delle \index{variadic}
-\textit{variadic function} che abbiano un numero variabile di argomenti,
-attraverso l'uso nella dichiarazione della funzione dello speciale costrutto
-``\texttt{...}'', che viene chiamato \textit{ellipsis}.
+sua sintassi la possibilità di definire delle \textit{variadic function} che
+abbiano un numero variabile di argomenti, attraverso l'uso nella dichiarazione
+della funzione dello speciale costrutto ``\texttt{...}'', che viene chiamato
+\textit{ellipsis}.
Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
a seguire quelli addizionali.
\end{itemize*}
-Lo standard ISO C prevede che una \index{variadic} \textit{variadic function}
-abbia sempre almeno un argomento fisso. Prima di effettuare la dichiarazione
-deve essere incluso l'apposito \textit{header file} \file{stdarg.h}; un
-esempio di dichiarazione è il prototipo della funzione \func{execl} che
-vedremo in sez.~\ref{sec:proc_exec}:
+Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
+almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
+incluso l'apposito \textit{header file} \file{stdarg.h}; un esempio di
+dichiarazione è il prototipo della funzione \func{execl} che vedremo in
+sez.~\ref{sec:proc_exec}:
\includecodesnip{listati/exec_sample.c}
in questo caso la funzione prende due argomenti fissi ed un numero variabile
di altri argomenti, che andranno a costituire gli elementi successivi al primo
usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
(vedi sez.~\ref{sec:proc_exec}).
+\index{funzioni!variadic|)}
\subsection{Il controllo di flusso non locale}
\label{sec:proc_longjmp}
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
\itindex{process~table} \textit{process table}. Per ciascun processo viene
mantenuta una voce in questa tabella, costituita da una struttura
-\struct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
+\kstruct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
processo. Tutte le strutture usate a questo scopo sono dichiarate
nell'\textit{header file} \file{linux/sched.h}, ed uno schema semplificato,
che riporta la struttura delle principali informazioni contenute nella
kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
\textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
modificato ed il valore massimo è impostabile attraverso il file
- \procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
+ \sysctlfile{kernel/pid\_max} e di default vale 32768.} che serve a
riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
- figlio che sia terminato normalmente. \\
- \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
- stato di uscita del processo (passato attraverso
- \func{\_exit}, \func{exit} o come valore di
- ritorno di \func{main}); può essere valutata solo
- se \val{WIFEXITED} ha restituito un valore non
- nullo.\\
- \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
- in maniera anomala a causa di un segnale che non
- è stato catturato (vedi
- sez.~\ref{sec:sig_notification}).\\
- \macro{WTERMSIG(s)} & Restituisce il numero del segnale che ha causato
- la terminazione anomala del processo; può essere
- valutata solo se \val{WIFSIGNALED} ha restituito
- un valore non nullo.\\
- \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
- file di \itindex{core~dump} \textit{core
- dump}; può essere valutata solo se
- \val{WIFSIGNALED} ha restituito un valore non
- nullo.\footnotemark \\
- \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
- \func{waitpid} è bloccato; l'uso è possibile solo
- con \func{waitpid} avendo specificato l'opzione
- \const{WUNTRACED}.\\
- \macro{WSTOPSIG(s)} & Restituisce il numero del segnale che ha bloccato
- il processo; può essere valutata solo se
- \val{WIFSTOPPED} ha restituito un valore non
- nullo. \\
- \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
- stato riavviato da un \signal{SIGCONT}
- (disponibile solo a partire dal kernel 2.6.10).\\
+ \macro{WIFEXITED}\texttt{(s)} & Condizione vera (valore non nullo) per
+ un processo figlio che sia terminato
+ normalmente. \\
+ \macro{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
+ significativi dello stato di uscita del
+ processo (passato attraverso
+ \func{\_exit}, \func{exit} o come valore
+ di ritorno di \func{main}); può essere
+ valutata solo se \val{WIFEXITED} ha
+ restituito un valore non nullo.\\
+ \macro{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
+ terminato in maniera anomala a causa di
+ un segnale che non è stato catturato
+ (vedi sez.~\ref{sec:sig_notification}).\\
+ \macro{WTERMSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
+ causato la terminazione anomala del
+ processo; può essere valutata solo se
+ \val{WIFSIGNALED} ha restituito un
+ valore non nullo.\\
+ \macro{WCOREDUMP}\texttt{(s)} & Vera se il processo terminato ha
+ generato un file di \itindex{core~dump}
+ \textit{core dump}; può essere valutata
+ solo se \val{WIFSIGNALED} ha restituito
+ un valore non nullo.\footnotemark \\
+ \macro{WIFSTOPPED}\texttt{(s)} & Vera se il processo che ha causato il
+ ritorno di \func{waitpid} è bloccato;
+ l'uso è possibile solo con
+ \func{waitpid} avendo specificato
+ l'opzione \const{WUNTRACED}.\\
+ \macro{WSTOPSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
+ bloccato il processo; può essere
+ valutata solo se \val{WIFSTOPPED} ha
+ restituito un valore non nullo. \\
+ \macro{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
+ ritorno è stato riavviato da un
+ \signal{SIGCONT} (disponibile solo a
+ partire dal kernel 2.6.10).\\
\hline
\end{tabular}
\caption{Descrizione delle varie macro di preprocessore utilizzabili per
\fdecl{int execvp(const char *file, char *const argv[])}
\fdesc{Eseguono un programma.}
}
-{Le funzioni ritorna solo in caso di errore, restituendo $-1$, i codici di
+{Le funzioni ritornano solo in caso di errore, restituendo $-1$, i codici di
errore sono gli stessi di \func{execve}.
}
\end{funcproto}
binario, questo deve essere un file di testo che deve iniziare con una linea
nella forma:
\begin{Example}
-\#!/path/to/interpreter [argomenti]
+#!/path/to/interpreter [argomenti]
\end{Example}
dove l'interprete indicato deve essere un eseguibile binario e non un altro
script, che verrà chiamato come se si fosse eseguito il comando
politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
automaticamente rimesso in coda alla lista, e la sua esecuzione continua
fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
-volontariamente la CPU (in tal caso, tornando nello stato \textbf{Runnable}
+volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
nel caso che esso sia stato interrotto da un processo a priorità più alta.
cambiato ed un processo che chiama la funzione viene inserito nella lista dei
processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
ripristinare un comportamento analogo al precedente scrivendo il valore 1
- nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.}
+ nel file \sysctlfile{kernel/sched\_compat\_yield}.}
L'uso delle funzione nella programmazione ordinaria può essere utile e
migliorare le prestazioni generali del sistema quando si è appena rilasciata
maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
cui questo numero può non essere sufficiente, e per questo è stato creato
-questo \itindex{tipo!opaco} tipo opaco e una interfaccia di gestione che
+questo \index{tipo!opaco} tipo opaco e una interfaccia di gestione che
permette di usare a basso livello un tipo di dato qualunque rendendosi
indipendenti dal numero di bit e dalla loro disposizione. Per questo le
funzioni richiedono anche che oltre all'insieme di processori si indichi anche
-la dimensione dello stesso con l'argomento \param{setsize}, per il quale,
-se non si usa l'allocazione dinamica che vedremo a breve, ed è in genere
+la dimensione dello stesso con l'argomento \param{setsize}, per il quale, se
+non si usa l'allocazione dinamica che vedremo a breve, ed è in genere
sufficiente passare il valore \code{sizeof(cpu\_set\_t)}.
L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
Il comportamento di default prevede che per tutti i processi si applichi la
politica generale di sistema definita nel file
- \procfile{/proc/sys/vm/memory\_failure\_early\_kill}, ma specificando
+ \sysctlfile{vm/memory\_failure\_early\_kill}, ma specificando
per \param{arg2} il valore \const{PR\_MCE\_KILL\_SET} è possibile impostare
con il contenuto di \param{arg3} una politica specifica del processo
chiamante. Si può tornare alla politica di default del sistema utilizzando
Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
virtualizzazione dei processi, di creare nuovi \textit{namespace} per una
serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei
-file, i \textit{mount point}, la rete, ecc.), che consentono di creare gruppi
-di processi che vivono in una sorta di spazio separato dagli altri, che
-costituisce poi quello che viene chiamato un \textit{container}.
+file, i \itindex{mount~point} \textit{mount point}, la rete, ecc.), che
+consentono di creare gruppi di processi che vivono in una sorta di spazio
+separato dagli altri, che costituisce poi quello che viene chiamato un
+\textit{container}.
La \textit{system call} richiede soltanto due argomenti: il
primo, \param{flags}, consente di controllare le modalità di creazione del
è prendere invece di una lista esplicita di argomenti un unico argomento
finale nella forma di una lista di argomenti passato come \macro{va\_list},
utile qualora si ottengano questi nella invocazione di una funzione
-\index{variadic} \textit{variadic} (si rammenti quanto visto in
+\index{funzioni!variadic} \textit{variadic} (si rammenti quanto visto in
sez.~\ref{sec:proc_variadic}), è \funcd{vsyslog},\footnote{la funzione è
originaria di BSD e per utilizzarla deve essere definito
\macro{\_BSD\_SOURCE}.} il suo prototipo è:
questo modo si può leggere il valore della maschera corrente. Indicando un
valore non nullo per \param{mask} la registrazione dei messaggi viene
disabilitata per tutte quelle priorità che non rientrano nella maschera. In
-genere il valore viene impostato usando la macro \macro{LOG\_MASK(p)} dove
-\code{p} è una delle costanti di tab.~\ref{tab:sess_syslog_priority}. É
-inoltre disponibile anche la macro \macro{LOG\_UPTO(p)} che permette di
-specificare automaticamente tutte le priorità fino a quella indicata da
+genere il valore viene impostato usando la macro \macro{LOG\_MASK}\texttt{(p)}
+dove \code{p} è una delle costanti di tab.~\ref{tab:sess_syslog_priority}. É
+inoltre disponibile anche la macro \macro{LOG\_UPTO}\texttt{(p)} che permette
+di specificare automaticamente tutte le priorità fino a quella indicata da
\code{p}.
Una volta che si sia certi che non si intende registrare più nessun messaggio
console sia collegata).
In particolare la stampa dei messaggi sulla console è controllata dal
-contenuto del file \procfile{/proc/sys/kernel/printk} (o con l'equivalente
+contenuto del file \sysctlfile{kernel/printk} (o con l'equivalente
parametro di \func{sysctl}) che prevede quattro valori numerici interi: il
primo (\textit{console\_loglevel}) indica la priorità corrente oltre la quale
vengono stampati i messaggi sulla console, il secondo
Le operazioni corrispondenti ai valori 6, 7 ed 8 consentono di modificare la
priorità oltre la quale i messaggi vengono stampati direttamente sulla
\textit{console} e fanno riferimento ai parametri del kernel gestiti con le
-variabili contenute in \procfile{/proc/sys/kernel/printk} di cui abbiamo
+variabili contenute in \sysctlfile{kernel/printk} di cui abbiamo
parlato prima, ed in particolare con 6 si imposta come corrente il valore
minimo della terza variabile (\textit{minimum\_console\_level}), ottenendo
l'effetto di ridurre al minimo i messaggi che arrivano in console, mentre con
\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale
che poteva essere impostato come parametro del kernel in
-\procfile{/proc/sys/kernel/rtsig-max};\footnote{ed il valore predefinito era
+\sysctlfile{kernel/rtsig-max};\footnote{ed il valore predefinito era
pari a 1024.} a partire dal kernel 2.6.8 il valore globale è stato rimosso e
sostituito dalla risorsa \const{RLIMIT\_SIGPENDING} associata al singolo
utente, che può essere modificata con \func{setrlimit} come illustrato in
per mantenere dati amministrativi e strutture interne, e solo una parte
viene usata come buffer per i dati, mentre il valore letto da
\func{getsockopt} e quello riportato nei vari parametri di
- \textit{sysctl}\footnote{cioè \procrelfile{/proc/sys/net/core}{wmem\_max} e
- \procrelfile{/proc/sys/net/core}{rmem\_max} in \texttt{/proc/sys/net/core}
- e \procrelfile{/proc/sys/net/ipv4}{tcp\_wmem} e
- \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem} in
+ \textit{sysctl}\footnote{cioè \sysctlrelfile{net/core}{wmem\_max} e
+ \sysctlrelfile{net/core}{rmem\_max} in \texttt{/proc/sys/net/core}
+ e \sysctlrelfile{net/ipv4}{tcp\_wmem} e
+ \sysctlrelfile{net/ipv4}{tcp\_rmem} in
\texttt{/proc/sys/net/ipv4}, vedi sez.~\ref{sec:sock_sysctl}.} indica la
memoria effettivamente impiegata. Si tenga presente inoltre che le
modifiche alle dimensioni dei buffer di ricezione e trasmissione, per poter
\texttt{man 7 socket} sono i seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\procrelfile{/proc/sys/net/core}{rmem\_default}] imposta la dimensione
+\item[\sysctlrelfile{net/core}{rmem\_default}] imposta la dimensione
di default del buffer di ricezione (cioè per i dati in ingresso) dei socket.
-\item[\procrelfile{/proc/sys/net/core}{rmem\_max}] imposta la dimensione
+\item[\sysctlrelfile{net/core}{rmem\_max}] imposta la dimensione
massima che si può assegnare al buffer di ricezione dei socket attraverso
l'uso dell'opzione \const{SO\_RCVBUF}.
-\item[\procrelfile{/proc/sys/net/core}{wmem\_default}] imposta la dimensione
+\item[\sysctlrelfile{net/core}{wmem\_default}] imposta la dimensione
di default del buffer di trasmissione (cioè per i dati in uscita) dei
socket.
-\item[\procrelfile{/proc/sys/net/core}{wmem\_max}] imposta la dimensione
+\item[\sysctlrelfile{net/core}{wmem\_max}] imposta la dimensione
massima che si può assegnare al buffer di trasmissione dei socket attraverso
l'uso dell'opzione \const{SO\_SNDBUF}.
-\item[\procrelfile{/proc/sys/net/core}{message\_cost},
- \procrelfile{/proc/sys/net/core}{message\_burst}] contengono le impostazioni
+\item[\sysctlrelfile{net/core}{message\_cost},
+ \sysctlrelfile{net/core}{message\_burst}] contengono le impostazioni
del \itindex{bucket~filter} \textit{bucket filter} che controlla l'emissione
di messaggi di avviso da parte del kernel per eventi relativi a problemi
sulla rete, imponendo un limite che consente di prevenire eventuali attacchi
emissione (verranno accettati inizialmente fino ad un massimo di
\texttt{message\_cost/message\_burst} messaggi).
-\item[\procrelfile{/proc/sys/net/core}{netdev\_max\_backlog}] numero massimo
+\item[\sysctlrelfile{net/core}{netdev\_max\_backlog}] numero massimo
di pacchetti che possono essere contenuti nella coda di ingresso generale.
-\item[\procrelfile{/proc/sys/net/core}{optmem\_max}] lunghezza massima dei
+\item[\sysctlrelfile{net/core}{optmem\_max}] lunghezza massima dei
dati ancillari e di controllo (vedi sez.~\ref{sec:net_ancillary_data}).
\end{basedescript}
nel file \texttt{Documentation/networking/ip-sysctl.txt}; la maggior parte di
questi però non è documentato:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\procrelfile{/proc/sys/net/core}{dev\_weight}] blocco di lavoro
+\item[\sysctlrelfile{net/core}{dev\_weight}] blocco di lavoro
(\textit{work quantum}) dello scheduler di processo dei pacchetti.
% TODO da documentare meglio
-\item[\procrelfile{/proc/sys/net/core}{lo\_cong}] valore per l'occupazione
+\item[\sysctlrelfile{net/core}{lo\_cong}] valore per l'occupazione
della coda di ricezione sotto la quale si considera di avere una bassa
congestione.
-\item[\procrelfile{/proc/sys/net/core}{mod\_cong}] valore per l'occupazione
+\item[\sysctlrelfile{net/core}{mod\_cong}] valore per l'occupazione
della coda di ricezione sotto la quale si considera di avere una congestione
moderata.
-\item[\procrelfile{/proc/sys/net/core}{no\_cong}] valore per l'occupazione
+\item[\sysctlrelfile{net/core}{no\_cong}] valore per l'occupazione
della coda di ricezione sotto la quale si considera di non avere
congestione.
-\item[\procrelfile{/proc/sys/net/core}{no\_cong\_thresh}] valore minimo
+\item[\sysctlrelfile{net/core}{no\_cong\_thresh}] valore minimo
(\textit{low water mark}) per il riavvio dei dispositivi congestionati.
- % \item[\procrelfile{/proc/sys/net/core}{netdev\_fastroute}] è presente
+ % \item[\sysctlrelfile{net/core}{netdev\_fastroute}] è presente
% soltanto quando si è compilato il kernel con l'apposita opzione di
% ottimizzazione per l'uso come router.
-\item[\procrelfile{/proc/sys/net/core}{somaxconn}] imposta la dimensione
+\item[\sysctlrelfile{net/core}{somaxconn}] imposta la dimensione
massima utilizzabile per il \textit{backlog} della funzione \func{listen}
(vedi sez.~\ref{sec:TCP_func_listen}), e corrisponde al valore della
costante \const{SOMAXCONN}; il suo valore di default è 128.
di manuale accessibile con \texttt{man 7 ip}, sono i seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_default\_ttl}] imposta il valore di
+\item[\sysctlrelfile{net/ipv4}{ip\_default\_ttl}] imposta il valore di
default per il campo TTL (vedi sez.~\ref{sec:IP_header}) di tutti i
pacchetti uscenti, stabilendo così il numero massimo di router che i
pacchetti possono attraversare. Il valore può essere modificato anche per il
quanto in caso di problemi di routing si allunga inutilmente il numero di
ritrasmissioni.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_forward}] abilita l'inoltro dei
+\item[\sysctlrelfile{net/ipv4}{ip\_forward}] abilita l'inoltro dei
pacchetti da una interfaccia ad un altra, e può essere impostato anche per
la singola interfaccia. Prende un valore logico (0 disabilita, diverso da
zero abilita), di default è disabilitato.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_dynaddr}] abilita la riscrittura
+\item[\sysctlrelfile{net/ipv4}{ip\_dynaddr}] abilita la riscrittura
automatica degli indirizzi associati ad un socket quando una interfaccia
cambia indirizzo. Viene usato per le interfacce usate nei collegamenti in
dial-up, il cui indirizzo IP viene assegnato dinamicamente dal provider, e
diverso dai precedenti) la si abilità in modalità \textsl{prolissa}; di
default la funzionalità è disabilitata.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_autoconfig}] specifica se
+\item[\sysctlrelfile{net/ipv4}{ip\_autoconfig}] specifica se
l'indirizzo IP è stato configurato automaticamente dal kernel all'avvio
attraverso DHCP, BOOTP o RARP. Riporta un valore logico (0 falso, 1 vero)
accessibile solo in lettura, è inutilizzato nei kernel recenti ed eliminato
a partire dal kernel 2.6.18.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_local\_port\_range}] imposta
+\item[\sysctlrelfile{net/ipv4}{ip\_local\_port\_range}] imposta
l'intervallo dei valori usati per l'assegnazione delle porte effimere,
permette cioè di modificare i valori illustrati in
fig.~\ref{fig:TCP_port_alloc}; prende due valori interi separati da spazi,
valore iniziale maggiore di 1024 (o meglio ancora di 4096) per evitare
conflitti con le porte usate dai servizi noti.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_no\_pmtu\_disc}] permette di
+\item[\sysctlrelfile{net/ipv4}{ip\_no\_pmtu\_disc}] permette di
disabilitare per i socket \const{SOCK\_STREAM} la ricerca automatica della
\itindex{Maximum~Transfer~Unit} \textit{Path MTU} (vedi
sez.~\ref{sec:net_lim_dim} e sez.~\ref{sec:sock_ipv4_options}). Prende un
perché disabilitare globalmente il procedimento con questo parametro ha
pesanti ripercussioni in termini di prestazioni di rete.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_always\_defrag}] fa si che tutti i
+\item[\sysctlrelfile{net/ipv4}{ip\_always\_defrag}] fa si che tutti i
pacchetti IP frammentati siano riassemblati, anche in caso in successivo
immediato inoltro.\footnote{introdotto con il kernel 2.2.13, nelle versioni
precedenti questo comportamento poteva essere solo stabilito un volta per
\itindex{netfilter} \textit{netfilter}, e questo parametro non è più
presente.
-\item[\procrelfile{/proc/sys/net/ipv4}{ipfrag\_high\_thresh}] indica il limite
+\item[\sysctlrelfile{net/ipv4}{ipfrag\_high\_thresh}] indica il limite
massimo (espresso in numero di byte) sui pacchetti IP frammentati presenti
in coda; quando questo valore viene raggiunta la coda viene ripulita fino al
valore \texttt{ipfrag\_low\_thresh}. Prende un valore intero.
-\item[\procrelfile{/proc/sys/net/ipv4}{ipfrag\_low\_thresh}] soglia bassa
+\item[\sysctlrelfile{net/ipv4}{ipfrag\_low\_thresh}] soglia bassa
(specificata in byte) a cui viene riportata la coda dei pacchetti IP
frammentati quando si raggiunge il valore massimo dato da
\texttt{ipfrag\_high\_thresh}. Prende un valore intero.
-\item[\procrelfile{/proc/sys/net/ipv4}{ip\_nonlocal\_bind}] se abilitato rende
+\item[\sysctlrelfile{net/ipv4}{ip\_nonlocal\_bind}] se abilitato rende
possibile ad una applicazione eseguire \func{bind} anche su un indirizzo che
non è presente su nessuna interfaccia locale. Prende un valore logico e di
default è disabilitato.
pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_abort\_on\_overflow}] indica al
+\item[\sysctlrelfile{net/ipv4}{tcp\_abort\_on\_overflow}] indica al
kernel di azzerare le connessioni quando il programma che le riceve è troppo
lento ed incapace di accettarle. Prende un valore logico ed è disabilitato
di default. Questo consente di recuperare le connessioni se si è avuto un
quando si è sicuri che non è possibile ottimizzare il server in modo che sia
in grado di accettare connessioni più rapidamente.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_adv\_win\_scale}] indica al kernel
+\item[\sysctlrelfile{net/ipv4}{tcp\_adv\_win\_scale}] indica al kernel
quale frazione del buffer associato ad un socket\footnote{quello impostato
- con \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}.} deve essere utilizzata
+ con \sysctlrelfile{net/ipv4}{tcp\_rmem}.} deve essere utilizzata
per la finestra del protocollo TCP\footnote{in sostanza il valore che
costituisce la \itindex{advertised~window} \textit{advertised window}
annunciata all'altro capo del socket.} e quale come buffer applicativo per
negativo. Il default è 2 che significa che al buffer dell'applicazione
viene riservato un quarto del totale.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_app\_win}] indica la frazione
+\item[\sysctlrelfile{net/ipv4}{tcp\_app\_win}] indica la frazione
della finestra TCP che viene riservata per gestire l'overhaed dovuto alla
bufferizzazione. Prende un valore valore intero che consente di calcolare la
dimensione in byte come il massimo fra la \itindex{Maximum~Segment~Size}
% \item[\texttt{tcp\_bic\_low\_window}]
% \item[\texttt{tcp\_bic\_fast\_convergence}]
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_dsack}] abilita il supporto,
+\item[\sysctlrelfile{net/ipv4}{tcp\_dsack}] abilita il supporto,
definito nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}, per il
cosiddetto \textit{Duplicate SACK}.\footnote{si indica con SACK
(\textit{Selective Acknowledgement}) un'opzione TCP, definita
% mettere riferimento nelle appendici
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_ecn}] abilita il meccanismo della
+\item[\sysctlrelfile{net/ipv4}{tcp\_ecn}] abilita il meccanismo della
\textit{Explicit Congestion Notification} (in breve ECN) nelle connessioni
TCP. Prende valore logico che di default è disabilitato. La \textit{Explicit
Congestion Notification} \itindex{Explicit~Congestion~Notification} è un
% mettere riferimento nelle appendici
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_fack}] abilita il supporto per il
+\item[\sysctlrelfile{net/ipv4}{tcp\_fack}] abilita il supporto per il
\textit{TCP Forward Acknowledgement}, un algoritmo per il controllo della
congestione del traffico. Prende un valore logico e di default è abilitato.
% TODO documentare o descrivere che cos'è il TCP Forward Acknowledgement o
% mettere riferimento nelle appendici
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_fin\_timeout}] specifica il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_fin\_timeout}] specifica il numero
di secondi da passare in stato \texttt{FIN\_WAIT2} nell'attesa delle
ricezione del pacchetto FIN conclusivo, passati quali il socket viene
comunque chiuso forzatamente. Prende un valore intero che indica i secondi
ma è utile per fronteggiare alcuni attacchi di
\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_frto}] abilita il supporto per
+\item[\sysctlrelfile{net/ipv4}{tcp\_frto}] abilita il supporto per
l'algoritmo F-RTO, un algoritmo usato per la ritrasmissione dei timeout del
protocollo TCP, che diventa molto utile per le reti wireless dove la perdita
di pacchetti è usualmente dovuta a delle interferenze radio, piuttosto che
alla congestione dei router. Prende un valore logico e di default è
disabilitato.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_keepalive\_intvl}] indica il
+\item[\sysctlrelfile{net/ipv4}{tcp\_keepalive\_intvl}] indica il
numero di secondi che deve trascorrere fra l'emissione di due successivi
pacchetti di test quando è abilitata la funzionalità del \textit{keepalive}
(vedi sez.~\ref{sec:sock_options_main}). Prende un valore intero che di
default è 75.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_keepalive\_probes}] indica il
+\item[\sysctlrelfile{net/ipv4}{tcp\_keepalive\_probes}] indica il
massimo numero pacchetti di \textit{keepalive} (vedi
sez.~\ref{sec:sock_options_main}) che devono essere inviati senza ricevere
risposta prima che il kernel decida che la connessione è caduta e la
termini. Prende un valore intero che di default è 9.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_keepalive\_time}] indica il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_keepalive\_time}] indica il numero
di secondi che devono passare senza traffico sulla connessione prima che il
kernel inizi ad inviare pacchetti di pacchetti di
\textit{keepalive}.\footnote{ha effetto solo per i socket per cui si è
sez.~\ref{sec:sock_options_main}.} Prende un valore intero che di default
è 7200, pari a due ore.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_low\_latency}] indica allo stack
+\item[\sysctlrelfile{net/ipv4}{tcp\_low\_latency}] indica allo stack
TCP del kernel di ottimizzare il comportamento per ottenere tempi di latenza
più bassi a scapito di valori più alti per l'utilizzo della banda. Prende un
valore logico che di default è disabilitato in quanto un maggior utilizzo
riduzione della latenza è più importante (ad esempio per i cluster di
calcolo parallelo) nelle quali lo si può abilitare.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_max\_orphans}] indica il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_max\_orphans}] indica il numero
massimo di socket TCP ``\textsl{orfani}'' (vale a dire non associati a
nessun file descriptor) consentito nel sistema.\footnote{trattasi in genere
delle connessioni relative a socket chiusi che non hanno completato il
% TODO verificare la spiegazione di connessione orfana.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_max\_syn\_backlog}] indica la
+\item[\sysctlrelfile{net/ipv4}{tcp\_max\_syn\_backlog}] indica la
lunghezza della coda delle connessioni incomplete, cioè delle connessioni
per le quali si è ricevuto un SYN di richiesta ma non l'ACK finale del
\itindex{three~way~handshake} \textit{three way handshake} (si riveda quanto
del kernel, in modo che sia $\mathtt{tcp\_max\_syn\_backlog} \ge
\mathtt{16*TCP\_SYNQ\_HSIZE}$, per poi ricompilare il kernel.}
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_max\_tw\_buckets}] indica il
+\item[\sysctlrelfile{net/ipv4}{tcp\_max\_tw\_buckets}] indica il
numero massimo di socket in stato \texttt{TIME\_WAIT} consentito nel
sistema. Prende un valore intero di default è impostato al doppio del valore
del parametro \texttt{NR\_FILE}, ma che viene aggiustato automaticamente a
prevenire alcuni semplici attacchi di \textit{denial of service}.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_mem}] viene usato dallo stack TCP
+\item[\sysctlrelfile{net/ipv4}{tcp\_mem}] viene usato dallo stack TCP
per gestire le modalità con cui esso utilizzerà la memoria. Prende una
tripletta di valori interi, che indicano un numero di pagine:
ogni altro valore specificato dagli altri limiti del kernel.
\end{itemize*}
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_orphan\_retries}] indica il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_orphan\_retries}] indica il numero
massimo di volte che si esegue un tentativo di controllo sull'altro capo di
una connessione che è stata già chiusa dalla nostra parte. Prende un valore
intero che di default è 8.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_reordering}] indica il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_reordering}] indica il numero
massimo di volte che un pacchetto può essere riordinato nel flusso di dati,
prima che lo stack TCP assuma che è andato perso e si ponga nello stato di
\textit{slow start} (si veda sez.~\ref{sec:tcp_protocol_xxx}) viene usata
ritrasmissioni provocate dal riordinamento. Prende un valore intero che di
default che è 3, e che non è opportuno modificare.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retrans\_collapse}] in caso di
+\item[\sysctlrelfile{net/ipv4}{tcp\_retrans\_collapse}] in caso di
pacchetti persi durante una connessione, per ottimizzare l'uso della banda
il kernel cerca di eseguire la ritrasmissione inviando pacchetti della
massima dimensione possibile; in sostanza dati che in precedenza erano stati
pacchetto (o su un numero minore di pacchetti di dimensione
maggiore). Prende un valore logico e di default è abilitato.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retries1}] imposta il massimo
+\item[\sysctlrelfile{net/ipv4}{tcp\_retries1}] imposta il massimo
numero di volte che protocollo tenterà la ritrasmissione si un pacchetto su
una connessione stabilita prima di fare ricorso ad ulteriori sforzi che
coinvolgano anche il livello di rete. Passato questo numero di
aggiornamento della rotta verso la destinazione prima di eseguire ogni
successiva ritrasmissione. Prende un valore intero che di default è 3.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retries2}] imposta il numero di
+\item[\sysctlrelfile{net/ipv4}{tcp\_retries2}] imposta il numero di
tentativi di ritrasmissione di un pacchetto inviato su una connessione già
stabilita per il quale non si sia ricevuto una risposta di ACK (si veda
anche quanto illustrato in sez.~\ref{sec:TCP_server_crash}). Prende un
nell'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} dove è indicato un
massimo di 100 secondi, che però è un valore considerato troppo basso.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_rfc1337}] indica al kernel di
+\item[\sysctlrelfile{net/ipv4}{tcp\_rfc1337}] indica al kernel di
abilitare il comportamento richiesto
nell'\href{http://www.ietf.org/rfc/rfc1337.txt}{RFC~1337}. Prende un valore
logico e di default è disabilitato, il che significa che alla ricezione di
immediatamente senza attendere la conclusione del periodo di
\texttt{TIME\_WAIT}.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}] viene usato dallo stack TCP
+\item[\sysctlrelfile{net/ipv4}{tcp\_rmem}] viene usato dallo stack TCP
per controllare dinamicamente le dimensioni dei propri buffer di ricezione,
anche in rapporto alla memoria disponibile. Prende una tripletta di valori
interi separati da spazi che indicano delle dimensioni in byte:
in sistemi con poca memoria viene automaticamente ridotto a
\const{PAGE\_SIZE}. Questo valore viene usato per assicurare che anche in
situazioni di pressione sulla memoria (vedi quanto detto per
- \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}) le allocazioni al di sotto di
+ \sysctlrelfile{net/ipv4}{tcp\_rmem}) le allocazioni al di sotto di
questo limite abbiamo comunque successo. Questo valore non viene comunque
ad incidere sulla dimensione del buffer di ricezione di un singolo socket
dichiarata con l'opzione \const{SO\_RCVBUF}.
\item il secondo valore, denominato \textit{default} nelle pagine di
manuale, indica la dimensione di default, in byte, del buffer di ricezione
di un socket TCP. Questo valore sovrascrive il default iniziale impostato
- per tutti i socket con \procfile{/proc/sys/net/core/mem\_default} che vale
+ per tutti i socket con \sysctlfile{net/core/mem\_default} che vale
per qualunque protocollo. Il default è 87380 byte, ridotto a 43689 per
sistemi con poca memoria. Se si desiderano dimensioni più ampie per tutti
i socket si può aumentare questo valore, ma se si vuole che in
corrispondenza aumentino anche le dimensioni usate per la finestra TCP si
deve abilitare il \itindex{TCP~window~scaling} \textit{TCP window scaling}
(di default è abilitato, vedi più avanti
- \procrelfile{/proc/sys/net/ipv4}{tcp\_window\_scaling}).
+ \sysctlrelfile{net/ipv4}{tcp\_window\_scaling}).
\item il terzo valore, denominato \textit{max} nelle pagine di manuale,
indica la dimensione massima in byte del buffer di ricezione di un socket
TCP; il default è 174760 byte, che viene ridotto automaticamente a 87380
per sistemi con poca memoria. Il valore non può comunque eccedere il
limite generale per tutti i socket posto con
- \procfile{/proc/sys/net/core/rmem\_max}. Questo valore non viene ad
+ \sysctlfile{net/core/rmem\_max}. Questo valore non viene ad
incidere sulla dimensione del buffer di ricezione di un singolo socket
dichiarata con l'opzione \const{SO\_RCVBUF}.
\end{itemize}
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_sack}] indica al kernel di
+\item[\sysctlrelfile{net/ipv4}{tcp\_sack}] indica al kernel di
utilizzare il meccanismo del \textit{TCP selective acknowledgement} definito
nell'\href{http://www.ietf.org/rfc/rfc2018.txt}{RFC~2018}. Prende un valore
logico e di default è abilitato.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_stdurg}] indica al kernel di
+\item[\sysctlrelfile{net/ipv4}{tcp\_stdurg}] indica al kernel di
utilizzare l'interpretazione che viene data
dall'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} del puntatore dei
\textit{dati urgenti} (vedi sez.~\ref{sec:TCP_urgent_data}) in cui questo
Prende un valore logico e di default è disabilitato, perché abilitarlo può
dar luogo a problemi di interoperabilità.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_synack\_retries}] indica il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_synack\_retries}] indica il numero
massimo di volte che verrà ritrasmesso il segmento SYN/ACK nella creazione di
una connessione (vedi sez.~\ref{sec:TCP_conn_cre}). Prende un valore intero
ed il valore di default è 5; non si deve superare il valore massimo di 255.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_syncookies}] abilita i \textit{TCP
+\item[\sysctlrelfile{net/ipv4}{tcp\_syncookies}] abilita i \textit{TCP
syncookies}.\footnote{per poter usare questa funzionalità è necessario
avere abilitato l'opzione \texttt{CONFIG\_SYN\_COOKIES} nella compilazione
del kernel.} Prende un valore logico, e di default è disabilitato. Questa
con altre funzionalità come le estensioni e può causare problemi per i
client ed il reinoltro dei pacchetti.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_syn\_retries}] imposta il numero
+\item[\sysctlrelfile{net/ipv4}{tcp\_syn\_retries}] imposta il numero
di tentativi di ritrasmissione dei pacchetti SYN di inizio connessione del
\itindex{three~way~handshake} \textit{three way handshake} (si ricordi
quanto illustrato in sez.~\ref{sec:TCP_func_connect}). Prende un valore
intero che di default è 5; non si deve superare il valore massimo di 255.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_timestamps}] abilita l'uso dei
+\item[\sysctlrelfile{net/ipv4}{tcp\_timestamps}] abilita l'uso dei
\textit{TCP timestamps}, come definiti
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
logico e di default è abilitato.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_tw\_recycle}] abilita il
+\item[\sysctlrelfile{net/ipv4}{tcp\_tw\_recycle}] abilita il
riutilizzo rapido dei socket in stato \texttt{TIME\_WAIT}. Prende un valore
logico e di default è disabilitato. Non è opportuno abilitare questa opzione
che può causare problemi con il NAT.\footnote{il \textit{Network Address
\textit{netfilter}, per maggiori dettagli si consulti il cap.~2 di
\cite{FwGL}.}
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_tw\_reuse}] abilita il riutilizzo
+\item[\sysctlrelfile{net/ipv4}{tcp\_tw\_reuse}] abilita il riutilizzo
dello stato \texttt{TIME\_WAIT} quando questo è sicuro dal punto di vista
del protocollo. Prende un valore logico e di default è disabilitato.
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_window\_scaling}] un valore
+\item[\sysctlrelfile{net/ipv4}{tcp\_window\_scaling}] un valore
logico, attivo di default, che abilita la funzionalità del
\itindex{TCP~window~scaling} \textit{TCP window scaling} definita
dall'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
\itindex{TCP~window~scaling} \textit{TCP window scaling} con l'altro capo
della connessione non viene effettuata.
-%\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_vegas\_cong\_avoid}]
+%\item[\sysctlrelfile{net/ipv4}{tcp\_vegas\_cong\_avoid}]
% TODO: controllare su internet
-%\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_westwood}]
+%\item[\sysctlrelfile{net/ipv4}{tcp\_westwood}]
% TODO: controllare su internet
-\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_wmem}] viene usato dallo stack TCP
+\item[\sysctlrelfile{net/ipv4}{tcp\_wmem}] viene usato dallo stack TCP
per controllare dinamicamente le dimensioni dei propri buffer di spedizione,
adeguandole in rapporto alla memoria disponibile. Prende una tripletta di
valori interi separati da spazi che indicano delle dimensioni in byte:
\begin{itemize}
\item il primo valore, chiamato \textit{min}, indica la dimensione minima in
byte del buffer di spedizione; il default è 4Kb. Come per l'analogo di
- \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}) viene usato per assicurare
+ \sysctlrelfile{net/ipv4}{tcp\_rmem}) viene usato per assicurare
che anche in situazioni di pressione sulla memoria (vedi
- \procrelfile{/proc/sys/net/ipv4}{tcp\_mem}) le allocazioni al di sotto di
+ \sysctlrelfile{net/ipv4}{tcp\_mem}) le allocazioni al di sotto di
questo limite abbiamo comunque successo. Di nuovo questo valore non viene
ad incidere sulla dimensione del buffer di trasmissione di un singolo
socket dichiarata con l'opzione \const{SO\_SNDBUF}.
\item il secondo valore, denominato \textit{default}, indica la dimensione
di default in byte del buffer di spedizione di un socket TCP. Questo
valore sovrascrive il default iniziale impostato per tutti i tipi di
- socket con \procfile{/proc/sys/net/core/wmem\_default}. Il default è 87380
+ socket con \sysctlfile{net/core/wmem\_default}. Il default è 87380
byte, ridotto a 43689 per sistemi con poca memoria. Si può aumentare
questo valore quando si desiderano dimensioni più ampie del buffer di
trasmissione per i socket TCP, ma come per il precedente
- \procrelfile{/proc/sys/net/ipv4}{tcp\_rmem}) se si vuole che in
+ \sysctlrelfile{net/ipv4}{tcp\_rmem}) se si vuole che in
corrispondenza aumentino anche le dimensioni usate per la finestra TCP si
deve abilitare il \itindex{TCP~window~scaling} \textit{TCP window scaling}
- con \procrelfile{/proc/sys/net/ipv4}{tcp\_window\_scaling}.
+ con \sysctlrelfile{net/ipv4}{tcp\_window\_scaling}.
\item il terzo valore, denominato \textit{max}, indica la dimensione massima
in byte del buffer di spedizione di un socket TCP; il default è 128Kb, che
viene ridotto automaticamente a 64Kb per sistemi con poca memoria. Il
valore non può comunque eccedere il limite generale per tutti i socket
- posto con \procfile{/proc/sys/net/core/wmem\_max}. Questo valore non viene
+ posto con \sysctlfile{net/core/wmem\_max}. Questo valore non viene
ad incidere sulla dimensione del buffer di trasmissione di un singolo
socket dichiarata con l'opzione \const{SO\_SNDBUF}.
\end{itemize}
Ma oltre alle informazioni ottenibili da \func{sysctl} dentro \file{proc} sono
disponibili moltissime altre informazioni, fra cui ad esempio anche quelle
fornite da \func{uname} (vedi sez.~\ref{sec:sys_uname}) che sono mantenute nei
-file \procrelfile{/proc/sys/kernel}{ostype},
-\procrelfile{/proc/sys/kernel}{hostname},
-\procrelfile{/proc/sys/kernel}{osrelease},
-\procrelfile{/proc/sys/kernel}{version} e
-\procrelfile{/proc/sys/kernel}{domainname} di \file{/proc/sys/kernel/}.
+file \sysctlrelfile{kernel}{ostype}, \sysctlrelfile{kernel}{hostname},
+\sysctlrelfile{kernel}{osrelease}, \sysctlrelfile{kernel}{version} e
+\sysctlrelfile{kernel}{domainname} di \file{/proc/sys/kernel/}.
un errore di \errcode{EFBIG}.\\
\const{RLIMIT\_LOCKS}& È un limite presente solo nelle prime versioni
del kernel 2.4 sul numero massimo di
- \index{file!locking} \textit{file lock} (vedi
+ \itindex{file~locking} \textit{file lock} (vedi
sez.~\ref{sec:file_locking}) che un
processo poteva effettuare.\\
\const{RLIMIT\_MEMLOCK}& L'ammontare massimo di memoria che può essere
del kernel.
Il funzionamento di \func{acct} viene inoltre modificato da uno specifico
-parametro di sistema, modificabile attraverso \procfile{/proc/sys/kernel/acct}
+parametro di sistema, modificabile attraverso \sysctlfile{kernel/acct}
(o tramite la corrispondente \func{sysctl}). Esso contiene tre valori interi,
il primo indica la percentuale di spazio disco libero sopra il quale viene
ripresa una registrazione che era stata sospesa per essere scesi sotto il
secondi per un numero di volte che può essere stabilito dall'utente. Questo
può essere fatto a livello globale con una opportuna
\func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in
- \procfile{/proc/sys/net/ipv4/tcp\_syn\_retries}, vedi
+ \sysctlfile{net/ipv4/tcp\_syn\_retries}, vedi
sez.~\ref{sec:sock_ipv4_sysctl}.} e a livello di singolo socket con
l'opzione \const{TCP\_SYNCNT} (vedi sez.~\ref{sec:sock_tcp_udp_options}). Il
valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
della coda delle connessioni incomplete può essere ancora controllata usando
la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
o scrivendola direttamente in
-\procfile{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
+\sysctlfile{net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
protezione dei syncookies però (con l'opzione da compilare nel kernel e da
-attivare usando \procfile{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
+attivare usando \sysctlfile{net/ipv4/tcp\_syncookies}) questo valore
viene ignorato e non esiste più un valore massimo. In ogni caso in Linux il
valore di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se
è superiore a detta costante (che di default vale 128).\footnote{il valore di
caso di Linux anche dall'impostazione di alcuni dei parametri di sistema che
si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
in questo caso in particolare da
-\procrelfile{/proc/sys/net/ipv4}{tcp\_retries2} (vedi
+\sysctlrelfile{net/ipv4}{tcp\_retries2} (vedi
sez.~\ref{sec:sock_ipv4_sysctl}). Questo parametro infatti specifica il numero
di volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo
di una connessione prima di riportare un errore di timeout. Il valore
projects / gapil.git / commitdiff