strumenti per la compilazione e la costruzione di programmi e librerie, e gli
strumenti di gestione dei sorgenti e di controllo di versione.
-Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
+Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
obsoleto.
un programma ed effettuare una compilazione intelligente di tutti i file
relativi ad un progetto software, ricompilando solo i file necessari ed
eseguendo automaticamente tutte le operazioni che possono essere necessarie
-alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
+alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
applica solo ai programmi, ma in generale alla automazione di processi di
costruzione, ad esempio anche la creazione dei file di questa guida viene
fatta con \texttt{make}.}
\label{sec:make_intro}
Con \texttt{make} si possono definire i simboli del preprocessore C che
-consentono la compilazione condizionale dei programmi (anche in Fortran); è
+consentono la compilazione condizionale dei programmi (anche in Fortran); è
pertanto possibile gestire la ricompilazione dei programmi con diverse
configurazioni con la modifica di un unico file.
La sintassi normale del comando (quella che si usa quasi sempre, per le
-opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
+opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
comando esegue le istruzioni contenute in un file standard (usualmente
\texttt{Makefile}, o \texttt{makefile} nella directory corrente).
-Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
+Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
\begin{verbatim}
bersaglio: dipendenza1 dipendenza2 ...
regola1
regola2
...
\end{verbatim}
-dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
+dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
errore comune, fortunatamente ben segnalato dalle ultime versioni del
programma), il bersaglio e le dipendenze nomi di file e le regole comandi di
shell.
-Il concetto di base è che se uno dei file di dipendenza è più recente (nel
+Il concetto di base è che se uno dei file di dipendenza è più recente (nel
senso di tempo di ultima modifica) del file bersaglio quest'ultimo viene
ricostruito di nuovo usando le regole elencate nelle righe successive.
Il comando \texttt{make} ricostruisce di default il primo bersaglio che viene
trovato nella scansione del \texttt{Makefile}, se in un \texttt{Makefile} sono
-contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
+contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
sia il primo passandolo esplicitamente al comando come argomento, con qualcosa
del tipo di: \texttt{make altrobersaglio}.
Si tenga presente che le dipendenze stesse possono essere dichiarate come
-bersagli dipendenti da altri file; in questo modo è possibile creare una
+bersagli dipendenti da altri file; in questo modo è possibile creare una
catena di ricostruzioni.
-In esempio comune di quello che si fa è mettere come primo bersaglio il
+In esempio comune di quello che si fa è mettere come primo bersaglio il
programma principale che si vuole usare, e come dipendenze tutte gli oggetti
delle funzioni subordinate che utilizza, con i quali deve essere collegato; a
loro volta questi oggetti sono bersagli che hanno come dipendenza i relativi
\end{verbatim}
\normalsize
-Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
+Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
commento e non viene presa in considerazione.
Con \texttt{make} possono essere definite delle variabili, da potersi riusare
-a piacimento, per leggibilità si tende a definirle tutte maiuscole,
+a piacimento, per leggibilità si tende a definirle tutte maiuscole,
nell'esempio ne sono definite varie: \small
\begin{verbatim}
FC=g77
\end{verbatim}
\normalsize
-La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
+La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
(nel caso \texttt{FC}, \texttt{FLAGS}, \texttt{CC}, \texttt{CFLAGS}) in quanto
sono usati da \texttt{make} nelle cosiddette \textsl{regole implicite} (su cui
torneremo dopo).
\begin{verbatim}
$(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
\end{verbatim}
-e questo significa che la regola verrà trattata come se avessimo scritto
+e questo significa che la regola verrà trattata come se avessimo scritto
esplicitamente i valori delle variabili.
Veniamo ora alla parte principale del makefile che esegue la costruzione del
$(OBJ): commondef.f
\end{verbatim}
-Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
+Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
programma di riduzione dei dati; esso dipende dal suo sorgente da tutti gli
oggetti definiti dalla variabile \texttt{OBJ}, dal file di definizioni
\texttt{commondef.f} e dalla routine C \texttt{readfile.o}; si noti il
Il secondo bersaglio definisce le regole per la compilazione della routine
in C; essa dipende solo dal suo sorgente. Si noti che per la compilazione
vengono usate le variabili relative al compilatore C. Si noti anche che se
-questa regola viene usata, allora lo sarà anche la precedente, dato che
+questa regola viene usata, allora lo sarà anche la precedente, dato che
\texttt{riduzione} dipende da \texttt{readfile.o}.
-Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
+Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
solo il riferimento alla variabile \texttt{OBJ} con una sola dipendenza e
-nessuna regola, essa però mostra le possibilità (oltre che la
-complessità) di \texttt{make} connesse alla presenza di quelle regole
+nessuna regola, essa però mostra le possibilità (oltre che la
+complessità) di \texttt{make} connesse alla presenza di quelle regole
implicite a cui avevamo accennato.
-Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
+Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
bersagli per una stessa regola (nell'esempio quelli contenuti nella variabile
\texttt{OBJ} che viene espansa in una lista); in questo caso la regola di
-costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
+costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
facendo riferimento con la variabile automatica: \texttt{\$@}. L'esempio
-usato per la nostra costruzione però sembra non avere neanche la regola di
+usato per la nostra costruzione però sembra non avere neanche la regola di
costruzione.
Questa mancanza sia di regola che di dipendenze (ad esempio dai vari sorgenti)
-illustra le capacità di funzionamento automatico di \texttt{make}.
-Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che
+illustra le capacità di funzionamento automatico di \texttt{make}.
+Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che
per ottenere l'oggetto si debba compilare quest'ultimo.
-Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
-oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
+Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
+oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
specificare il sorgente, ma il programma lo va a cercare nella directory
-corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
-nel manuale). Nel caso specifico allora si è messo come dipendenza solo il
+corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
+nel manuale). Nel caso specifico allora si è messo come dipendenza solo il
file delle definizioni che viene incluso in ogni subroutine.
Inoltre come dicevamo in genere per costruire un oggetto si deve compilarne il
sorgente; \texttt{make} sa anche questo e sulla base dell'estensione del
-sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
-implicita. In questo caso la regola è quella di chiamare il compilatore
+sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
+implicita. In questo caso la regola è quella di chiamare il compilatore
fortran applicato al file oggetto e al relativo sorgente, questo viene fatto
-usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
+usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
regole implicite (come \texttt{CC} nel caso di file \texttt{.c}); per una
-maggiore flessibilità poi la regola standard usa anche la variabile
+maggiore flessibilità poi la regola standard usa anche la variabile
\texttt{FFLAGS} per specificare, a scelta dell'utente che non ha che da
definirla, quali flag di compilazione usare (nella documentazione sono
riportate tutte le regole implicite e le relative variabili usate).
-In questo modo è stato possibile usare una sola riga per indicare la serie di
+In questo modo è stato possibile usare una sola riga per indicare la serie di
dipendenze e relative compilazioni delle singole subroutine; inoltre con l'uso
della variabile \texttt{OBJ} l'aggiunta di una nuova eventuale routine
\texttt{nuova.f} comporta solo l'aggiunta di \texttt{nuova.o} alla definizione
\section{Source Control Management}
\label{sec:build_scm}
-Uno dei problemi più comuni che si hanno nella programmazione è quella di
+Uno dei problemi più comuni che si hanno nella programmazione è quella di
poter disporre di un sistema che consenta di tenere conto del lavoro
effettuato, di tracciare l'evoluzione del codice, e, soprattutto nel caso di
-progetti portati avanti da più persone, consentire un accesso opportunamente
+progetti portati avanti da più persone, consentire un accesso opportunamente
coordinato fra i vari partecipanti alla base comune dei sorgenti dello
sviluppo.
I programmi che servono a questo scopo vanno sotto il nome comune di SCM
(\textit{Source Control Manager}), e ne esistono di diversi tipi con diverse
-filosofie progettuali, in particolare nelle modalità con cui gestiscono
+filosofie progettuali, in particolare nelle modalità con cui gestiscono
l'accesso alla base di codice comune da parte dei singoli programmatori che vi
accedono.
-Fra questi uno dei più usati, nonostante la sua architettura sia considerata
-superata, è Subversion, un sistema di archiviazione centralizzata del codice
+Fra questi uno dei più usati, nonostante la sua architettura sia considerata
+superata, è Subversion, un sistema di archiviazione centralizzata del codice
che consente di tenere traccia di tutte le modifiche e di condividere un
archivio comune per progetti portati avanti da diverse persone.
\subsection{Introduzione a Subversion}
\label{sec:build_subversion}
-Subversion è basato sul concetto di \textit{repository}, un archivio
+Subversion è basato sul concetto di \textit{repository}, un archivio
centralizzato in cui vengono riposti e da cui vengono presi i sorgenti dei
programmi. L'archivio tiene traccia delle diverse versioni registrate; i
programmatori inviano le modifiche usando una copia locale che hanno nella
loro directory di lavoro.
-Subversion può gestire più di un progetto all'interno di un singolo server,
+Subversion può gestire più di un progetto all'interno di un singolo server,
ciascuno dei quali viene associato ad un \textit{repository} distinto, ma si
possono anche creare sotto-progetti suddividendo un \textit{repository} in
-diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad
+diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad
esempio quelli che consentono di inviare email all'inserimento di nuovo
codice) comuni.
Una delle caratteristiche che contraddistinguono Subversion dal suo
-predecessore CVS è quella di essere gestibile in maniera molto flessibile
-l'accesso al repository, che può avvenire sia in maniera diretta facendo
-riferimento alla directory in cui questo è stato installato che via rete,
-tramite diversi protocolli. L'accesso più comune è fatto direttamente via
-HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
+predecessore CVS è quella di essere gestibile in maniera molto flessibile
+l'accesso al repository, che può avvenire sia in maniera diretta facendo
+riferimento alla directory in cui questo è stato installato che via rete,
+tramite diversi protocolli. L'accesso più comune è fatto direttamente via
+HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
passare attraverso SSH o fornire un servizio di rete dedicato.\footnote{esiste
- all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
- scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
- diversi; la modalità di accesso preferita resta quella tramite le estensioni
+ all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
+ scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
+ diversi; la modalità di accesso preferita resta quella tramite le estensioni
al protocollo DAV.}
-In generale è comunque necessario preoccuparsi delle modalità di accesso al
-codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
+In generale è comunque necessario preoccuparsi delle modalità di accesso al
+codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
identificare o con il pathname alla directory dove questo si trova o con una
opportuna URL (con il comune accesso via web del tutto analoga a quella che si
-usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
-copia locale dei dati ed il riferimento diventerà implicito.
+usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
+copia locale dei dati ed il riferimento diventerà implicito.
-Il programma prevede infatti che in ogni directory che si è ottenuta come
+Il programma prevede infatti che in ogni directory che si è ottenuta come
copia locale sia presente una directory \texttt{.svn} contenente tutti i dati
necessari al programma. Inoltre il programma usa la directory
\texttt{.subversion} nella home dell'utente per mantenere le configurazioni
Tutte le operazioni di lavoro sul \textit{repository} vengono effettuate lato
client tramite il comando \texttt{svn} che vedremo in
sez.~\ref{sec:build_subversion} ma la creazione e la inizializzazione dello
-stesso (così come la gestione lato server) devono essere fatte tramite il
+stesso (così come la gestione lato server) devono essere fatte tramite il
comando \texttt{svnadmin} eseguito sulla macchina che lo ospita. In generale
infatti il comando \texttt{svn} richiede che si faccia riferimento ad un
\textit{repository} (al limite anche vuoto) esistente e questo deve essere
Il comando \texttt{svnadmin} utilizza una sintassi che richiede sempre
l'ulteriore specificazione di un sotto-comando, seguito da eventuali altri
-argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
+argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
sempre vuoto) viene eseguita con il comando:
\begin{verbatim}
svnadmin create /path/to/repository
\end{verbatim}
-dove \texttt{/path/to/repository} è la directory dove verranno creati e
-mantenuti tutti i file, una volta creato il \textit{repository} si potrà
+dove \texttt{/path/to/repository} è la directory dove verranno creati e
+mantenuti tutti i file, una volta creato il \textit{repository} si potrà
iniziare ad utilizzarlo ed inserirvi i contenuti con il comando \texttt{svn}.
Non essendo questo un testo di amministrazione di sistema non tratteremo qui i
\subsection{Utilizzo di \texttt{svn}}
\label{sec:build_svn_use}
-Una volta che si abbia a disposizione un \textit{repository} si potrà creare
+Una volta che si abbia a disposizione un \textit{repository} si potrà creare
un nuovo progetto sottoposto a controllo di versione importando al suo interno
-i dati disponibili. In genere è pratica comune suddividere il contenuto di un
+i dati disponibili. In genere è pratica comune suddividere il contenuto di un
repository in tre directory secondo il seguente schema:
\begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{trunk}] contiene la versione corrente i sviluppo, su cui vengono
effettuate normalmente le modifiche e gli aggiornamenti;
\item[\texttt{tags}] contiene le diverse versioni \textsl{fotografate} ad un
certo istante del processo di sviluppo, ad esempio in occasione del rilascio
- di una versione stabile, così che sia possibile identificarle facilmente;
+ di una versione stabile, così che sia possibile identificarle facilmente;
\item[\texttt{branches}] contiene \textsl{rami} alternativi di sviluppo, ad
esempio quello delle correzioni eseguite ad una versione stabile, che
vengono portati avanti in maniera indipendente dalla versione principale.
\end{basedescript}
-Questa suddivisione consente di sfruttare la capacità di Subversion di creare
+Questa suddivisione consente di sfruttare la capacità di Subversion di creare
senza spesa copie diverse del proprio contenuto, pertanto in genere si pone il
proprio progetto di sviluppo sotto \texttt{trunk}, e si copia quest'ultima in
occasione delle varie versioni di rilascio in altrettante sottocartelle di
\texttt{tags} e qualora si voglia aprire un ramo alternativo di sviluppo
-basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
+basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
iniziare ad eseguire le modifiche su di esso.
Le operazioni di gestione di un progetto con Subversion vengono eseguite con
il comando \texttt{svn}, che analogamente al precedente \texttt{svnadmin}
utilizza una sintassi basata sulla specificazione degli opportuni
-sotto-comandi. Si sono riportati quelli più importanti in
+sotto-comandi. Si sono riportati quelli più importanti in
tab.~\ref{tab:svn_mainsubcommands}.
\begin{table}[htb]
\label{tab:svn_mainsubcommands}
\end{table}
-In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
-molto più comune avere una qualche versione iniziale dei propri file
-all'interno di una cartella. In questo caso il primo passo è quello di
+In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
+molto più comune avere una qualche versione iniziale dei propri file
+all'interno di una cartella. In questo caso il primo passo è quello di
eseguire una inizializzazione del \textit{repository} importando al suo
-interno quanto già esistente. Per far questo occorre eseguire il comando:
+interno quanto già esistente. Per far questo occorre eseguire il comando:
\begin{verbatim}
svn import [/pathname] URL
\end{verbatim}
-questo può essere eseguito direttamente nella directory contenente la versione
+questo può essere eseguito direttamente nella directory contenente la versione
iniziale dei propri sorgenti nel qual caso il comando richiede come ulteriore
argomento la directory o la URL con la quale indicare il \textit{repository}
-da usare. Alternativamente si può passare come primo argomento il pathname
+da usare. Alternativamente si può passare come primo argomento il pathname
della directory da importare, seguito dall'indicazione della URL del
\textit{repository}.
Si tenga presente che l'operazione di importazione inserisce sul
\textit{repository} il contenuto completo della directory indicata, compresi
-eventuali file nascosti e sotto-directory. È anche possibile eseguire
-l'importazione di più directory da inserire in diverse sezioni del
-\textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
+eventuali file nascosti e sotto-directory. È anche possibile eseguire
+l'importazione di più directory da inserire in diverse sezioni del
+\textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
diversa \textit{release}. Ad ogni operazione di modifica del
\textit{repository} viene infatti assegnato un numero progressivo che consente
di identificarne la storia delle modifiche e riportarsi ad un dato punto della
assegna un numero di versione progressivo distinto ad ogni file, ma un
numero di \textit{release} progressivo ad ogni cambiamento globale del
repository, pertanto non esiste il concetto di versione di un singolo file,
- quanto di stato di tutto il \textit{repository} ad un dato momento, è
+ quanto di stato di tutto il \textit{repository} ad un dato momento, è
comunque possibile richiedere in maniera indipendente la versione di ogni
singolo file a qualunque \textit{release} si desideri.}
-Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
+Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
la directory originale e ripartire dal progetto appena creato. L'operazione di
recuperare ex-novo di tutti i file che fanno parte di un progetto, chiamata
usualmente \textit{checkout}, viene eseguita con il
-comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
+comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
co}.}
\begin{verbatim}
svn checkout URL [/pathname]
\end{verbatim}
-che creerà nella directory corrente una directory corrispondente al nome
+che creerà nella directory corrente una directory corrispondente al nome
specificato in coda alla URL passata come argomento, scaricando l'ultima
-versione dei file archiviati sul repository; alternativamente si può
+versione dei file archiviati sul repository; alternativamente si può
specificare come ulteriore argomento la directory su cui scaricare i file.
-Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
+Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
operare su una qualunque sotto cartella contenuta all'interno di un
-\textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
+\textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
indicare in sede di importazione o di estrazione iniziale un pathname o una
URL che identifichi quella parte del progetto.
-Se quando si effettua lo scaricamento non si vuole usare la versione più
-aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
-seguita da un numero che scaricherà esattamente quella \textit{release},
-alternativamente al posto del numero si può indicare una data, e verrà presa
-la \textit{release} più prossima a quella data.
+Se quando si effettua lo scaricamento non si vuole usare la versione più
+aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
+seguita da un numero che scaricherà esattamente quella \textit{release},
+alternativamente al posto del numero si può indicare una data, e verrà presa
+la \textit{release} più prossima a quella data.
A differenza di CVS Subversion non supporta l'uso di \textsl{etichette}
-associate ad una certa versione del proprio progetto, per questo è invalso
+associate ad una certa versione del proprio progetto, per questo è invalso
l'uso di strutturare il repository secondo lo schema illustrato inizialmente;
-è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
+è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
copie complete di una qualunque parte del \textit{repository} su un'altra
-parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
-\texttt{trunk} sarà possibile creare banalmente una versione con etichetta
+parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
+\texttt{trunk} sarà possibile creare banalmente una versione con etichetta
\texttt{label} (o quel che si preferisce) semplicemente con una copia eseguita
con:
\begin{verbatim}
svn cp trunk tags/label
\end{verbatim}
-Il risultato di questo comando è la creazione della nuova cartella
-\texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
+Il risultato di questo comando è la creazione della nuova cartella
+\texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
contenuto (e nella sua storia) a quanto presente in \texttt{trunk} al momento
dell'esecuzione del comando. In questo modo, una volta salvate le
-modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
- \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
+modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
+ \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
versione \texttt{label} del proprio progetto semplicemente eseguendo un
\textit{checkout} di \texttt{tags/label} in un'altra
directory.\footnote{ovviamente una volta presa la suddetta versione si deve
questo se si deve modificare una versione etichettata si usa
\texttt{branches}.}
-Una volta creata la propria copia locale dei programmi, è possibile lavorare
+Una volta creata la propria copia locale dei programmi, è possibile lavorare
su di essi ponendosi nella relativa directory, e apportare tutte le modifiche
che si vogliono ai file ivi presenti; due comandi permettono inoltre di
schedulare la rimozione o l'aggiunta di file al
\begin{verbatim}
svn commit [file]
\end{verbatim}
-ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
+ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
file, indicandolo come ulteriore argomento, mentre se non si indica nulla
verranno inviate tutte le modifiche presenti.
-Si tenga presente però che il \textit{commit} non verrà eseguito se nel
+Si tenga presente però che il \textit{commit} non verrà eseguito se nel
frattempo i file del \textit{repository} sono stati modificati; in questo caso
-\texttt{svn} rileverà la presenza di differenze fra la propria
-\textit{release} e quella del \textit{repository} e chiederà che si effettui
-preventivamente un aggiornamento. Questa è una delle operazioni di base di
+\texttt{svn} rileverà la presenza di differenze fra la propria
+\textit{release} e quella del \textit{repository} e chiederà che si effettui
+preventivamente un aggiornamento. Questa è una delle operazioni di base di
Subversion, che in genere si compie tutte le volte che si inizia a lavorare,
-il comando che la esegue è:
+il comando che la esegue è:
\begin{verbatim}
svn update
\end{verbatim}
Fintanto che sono state modificate parti indipendenti di un file di testo in
genere il processo di \textit{merging} ha successo e le modifiche vengono
incorporate automaticamente in conseguenza dell'aggiornamento, ma quando le
-modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
-ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
+modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
+ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
intervenire manualmente sui file per i quali sono stati rilevati i conflitti
per risolverli.
>>>>>>> r.122
\end{verbatim}
-In questo caso si c'è stata una modifica sul file (mostrata nella parte
+In questo caso si c'è stata una modifica sul file (mostrata nella parte
superiore) incompatibile con quella fatta nel \textit{repository} (mostrata
-nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
+nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
pertanto integrare le modifiche e salvare nuovamente il file rimuovendo i
-marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
+marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
esplicitare la risoluzione del conflitto con il comando:
\begin{verbatim}
svn resolved file
\end{table}
-Infine per capire la situazione della propria copia locale si può utilizzare
+Infine per capire la situazione della propria copia locale si può utilizzare
il comando \texttt{svn status} che confronta i file presenti nella directory
locale rispetto alla ultima versione scaricata dal \textit{repository} e per
tutti quelli che non corrispondono stampa a schermo delle informazioni di
accessibili attraverso l'inclusione del file di header \file{errno.h}, che
definisce anche la variabile globale \var{errno}. Per ogni errore definito
riporteremo la stringa stampata da \func{perror} ed una breve spiegazione. Si
-tenga presente che spiegazioni più particolareggiate del significato
+tenga presente che spiegazioni più particolareggiate del significato
dell'errore, qualora necessarie per casi specifici, possono essere trovate
-nella descrizione del prototipo della funzione per cui detto errore si è
+nella descrizione del prototipo della funzione per cui detto errore si è
verificato.
I codici di errore sono riportati come costanti di tipo \ctyp{int}, i valori
delle costanti sono definiti da macro di preprocessore nel file citato, e
-possono variare da architettura a architettura; è pertanto necessario
+possono variare da architettura a architettura; è pertanto necessario
riferirsi ad essi tramite i nomi simbolici. Le funzioni \func{perror} e
\func{strerror} (vedi sez.~\ref{sec:sys_strerror}) possono essere usate per
-ottenere dei messaggi di errore più espliciti.
+ottenere dei messaggi di errore più espliciti.
\section{Gli errori dei file}
gestione dei file.
\begin{description}
-\item \errcode{EPERM} \textit{Operation not permitted}. L'operazione non è
+\item \errcode{EPERM} \textit{Operation not permitted}. L'operazione non è
permessa: solo il proprietario del file o un processo con sufficienti
- privilegi può eseguire l'operazione.
+ privilegi può eseguire l'operazione.
\item \errcode{ENOENT} \textit{No such file or directory}. Il file indicato
dal \itindex{pathname} \textit{pathname} non esiste: o una delle componenti
non esiste o il \textit{pathname} contiene un link simbolico spezzato.
per riportare errori hardware in lettura/scrittura su un dispositivo.
\item \errcode{ENXIO} \textit{No such device or address}. Dispositivo
inesistente: il sistema ha tentato di usare un dispositivo attraverso il
- file specificato, ma non lo ha trovato. Può significare che il file di
- dispositivo non è corretto, che il modulo relativo non è stato caricato nel
- kernel, o che il dispositivo è fisicamente assente o non funzionante.
+ file specificato, ma non lo ha trovato. Può significare che il file di
+ dispositivo non è corretto, che il modulo relativo non è stato caricato nel
+ kernel, o che il dispositivo è fisicamente assente o non funzionante.
\item \errcode{ENOEXEC} \textit{Invalid executable file format}. Il file non ha
- un formato eseguibile, è un errore riscontrato dalle funzioni \func{exec}.
+ un formato eseguibile, è un errore riscontrato dalle funzioni \func{exec}.
\item \errcode{EBADF} \textit{Bad file descriptor}. File descriptor non valido:
- si è usato un file descriptor inesistente, o aperto in sola lettura per
- scrivere, o viceversa, o si è cercato di eseguire un'operazione non
+ si è usato un file descriptor inesistente, o aperto in sola lettura per
+ scrivere, o viceversa, o si è cercato di eseguire un'operazione non
consentita per quel tipo di file descriptor.
\item \errcode{EACCES} \textit{Permission denied}. Permesso negato; l'accesso
- al file o alla directory non è consentito: i permessi del file o della
+ al file o alla directory non è consentito: i permessi del file o della
directory non consentono l'operazione richiesta.
\item \errcode{ELOOP} \textit{Too many symbolic links encountered}. Ci sono
troppi link simbolici nella risoluzione di un
\itindex{pathname}\textit{pathname}.
-\item \errcode{ENAMETOOLONG} \textit{File name too long}. Si è indicato un
+\item \errcode{ENAMETOOLONG} \textit{File name too long}. Si è indicato un
\itindex{pathname} \textit{pathname} troppo lungo per un file o una
directory.
-\item \errcode{ENOTBLK} \textit{Block device required}. Si è specificato un
- file che non è un \textit{block device} in un contesto in cui era necessario
- specificare un \textit{block device} (ad esempio si è tentato di montare un
+\item \errcode{ENOTBLK} \textit{Block device required}. Si è specificato un
+ file che non è un \textit{block device} in un contesto in cui era necessario
+ specificare un \textit{block device} (ad esempio si è tentato di montare un
file ordinario).
-\item \errcode{EEXIST} \textit{File exists}. Si è specificato un file esistente
+\item \errcode{EEXIST} \textit{File exists}. Si è specificato un file esistente
in un contesto in cui ha senso solo specificare un nuovo file.
\item \errcode{EBUSY} \textit{Resource busy}. Una risorsa di sistema che non
- può essere condivisa è occupata. Ad esempio si è tentato di cancellare la
- directory su cui si è montato un filesystem.
-\item \errcode{EXDEV} \textit{Cross-device link}. Si è tentato di creare un
+ può essere condivisa è occupata. Ad esempio si è tentato di cancellare la
+ directory su cui si è montato un filesystem.
+\item \errcode{EXDEV} \textit{Cross-device link}. Si è tentato di creare un
link diretto che attraversa due filesystem differenti.
-\item \errcode{ENODEV} \textit{No such device}. Si è indicato un tipo di device
+\item \errcode{ENODEV} \textit{No such device}. Si è indicato un tipo di device
sbagliato ad una funzione che ne richiede uno specifico.
-\item \errcode{ENOTDIR} \textit{Not a directory}. Si è specificato un file che
- non è una directory in una operazione che richiede una directory.
-\item \errcode{EISDIR} \textit{Is a directory}. Il file specificato è una
- directory; non può essere aperto in scrittura, né si possono creare o
+\item \errcode{ENOTDIR} \textit{Not a directory}. Si è specificato un file che
+ non è una directory in una operazione che richiede una directory.
+\item \errcode{EISDIR} \textit{Is a directory}. Il file specificato è una
+ directory; non può essere aperto in scrittura, né si possono creare o
rimuovere link diretti ad essa.
\item \errcode{EMFILE} \textit{Too many open files}. Il processo corrente ha
- troppi file aperti e non può aprirne altri. Anche i descrittori duplicati ed
+ troppi file aperti e non può aprirne altri. Anche i descrittori duplicati ed
i socket vengono tenuti in conto.\footnote{il numero massimo di file aperti
- è controllabile dal sistema; in Linux si può impostare usando il comando
- \cmd{ulimit}, esso è in genere indicato dalla costante \const{OPEN\_MAX},
+ è controllabile dal sistema; in Linux si può impostare usando il comando
+ \cmd{ulimit}, esso è in genere indicato dalla costante \const{OPEN\_MAX},
vedi sez.~\ref{sec:sys_limits}.}
\item \errcode{ENFILE} \textit{File table overflow}. Il sistema ha troppi file
aperti in contemporanea. Si tenga presente che anche i socket contano come
- file. Questa è una condizione temporanea, ed è molto difficile che si
+ file. Questa è una condizione temporanea, ed è molto difficile che si
verifichi nei sistemi moderni.
-\item \errcode{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
- controllo relativa ad un terminale su un file che non lo è.
-\item \errcode{ETXTBSY} \textit{Text file busy}. Si è cercato di eseguire un
- file che è aperto in scrittura, o di scrivere su un file che è in
+\item \errcode{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
+ controllo relativa ad un terminale su un file che non lo è.
+\item \errcode{ETXTBSY} \textit{Text file busy}. Si è cercato di eseguire un
+ file che è aperto in scrittura, o di scrivere su un file che è in
esecuzione.
-\item \errcode{EFBIG} \textit{File too big}. Si è ecceduto il limite imposto
- dal sistema sulla dimensione massima che un file può avere.
+\item \errcode{EFBIG} \textit{File too big}. Si è ecceduto il limite imposto
+ dal sistema sulla dimensione massima che un file può avere.
\item \errcode{ENOSPC} \textit{No space left on device}. La directory in cui si
- vuole creare il link non ha spazio per ulteriori voci, o si è cercato di
- scrivere o di creare un nuovo file su un dispositivo che è già pieno.
+ vuole creare il link non ha spazio per ulteriori voci, o si è cercato di
+ scrivere o di creare un nuovo file su un dispositivo che è già pieno.
\item \errcode{ESPIPE} \textit{Invalid seek operation}. Si cercato di eseguire
una \func{seek} su un file che non supporta questa operazione (ad esempio su
una pipe).
-\item \errcode{EROFS} \textit{Read-only file system}. Si è cercato di
+\item \errcode{EROFS} \textit{Read-only file system}. Si è cercato di
eseguire una operazione di scrittura su un file o una directory che risiede
su un filesystem montato un sola lettura.
-\item \errcode{EMLINK} \textit{Too many links}. Ci sono già troppi link al
- file (il numero massimo è specificato dalla variabile \const{LINK\_MAX},
+\item \errcode{EMLINK} \textit{Too many links}. Ci sono già troppi link al
+ file (il numero massimo è specificato dalla variabile \const{LINK\_MAX},
vedi sez.~\ref{sec:sys_limits}).
-\item \errcode{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
+\item \errcode{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
leggendo l'altro capo della pipe. Ogni funzione che restituisce questo
- errore genera anche un segnale \const{SIGPIPE}, la cui azione predefinita è
- terminare il programma; pertanto non si potrà vedere questo errore fintanto
+ errore genera anche un segnale \const{SIGPIPE}, la cui azione predefinita è
+ terminare il programma; pertanto non si potrà vedere questo errore fintanto
che \const{SIGPIPE} non viene gestito o bloccato.
-\item \errcode{ENOTEMPTY} \textit{Directory not empty}. La directory non è
- vuota quando l'operazione richiede che lo sia. È l'errore tipico che si ha
+\item \errcode{ENOTEMPTY} \textit{Directory not empty}. La directory non è
+ vuota quando l'operazione richiede che lo sia. È l'errore tipico che si ha
quando si cerca di cancellare una directory contenente dei file.
\item \errcode{EUSERS} \textit{Too many users}. Troppi utenti, il sistema delle
quote rileva troppi utenti nel sistema.
-\item \errcode{EDQUOT} \textit{Quota exceeded}. Si è ecceduta la quota di disco
+\item \errcode{EDQUOT} \textit{Quota exceeded}. Si è ecceduta la quota di disco
dell'utente.
\item \errcode{ESTALE} \textit{Stale NFS file handle}. Indica un problema
interno a NFS causato da cambiamenti del filesystem del sistema remoto. Per
- recuperare questa condizione in genere è necessario smontare e rimontare il
+ recuperare questa condizione in genere è necessario smontare e rimontare il
filesystem NFS.
-\item \errcode{EREMOTE} \textit{Object is remote}. Si è fatto un tentativo di
- montare via NFS un filesystem remoto con un nome che già specifica un
+\item \errcode{EREMOTE} \textit{Object is remote}. Si è fatto un tentativo di
+ montare via NFS un filesystem remoto con un nome che già specifica un
filesystem montato via NFS.
-\item \errcode{ENOLCK} \textit{No locks available}. È usato dalle utilità per
- la gestione del file locking; non viene generato da un sistema GNU, ma può
+\item \errcode{ENOLCK} \textit{No locks available}. È usato dalle utilità per
+ la gestione del file locking; non viene generato da un sistema GNU, ma può
risultare da un'operazione su un server NFS di un altro sistema.
-\item \errcode{EFTYPE} \textit{Inappropriate file type or format}. Il file è
+\item \errcode{EFTYPE} \textit{Inappropriate file type or format}. Il file è
di tipo sbagliato rispetto all'operazione richiesta o un file di dati ha un
formato sbagliato. Alcuni sistemi restituiscono questo errore quando si
cerca di impostare lo \itindex{sticky~bit} \textit{sticky bit} su un file che
- non è una directory.
+ non è una directory.
\end{description}
Non esiste un processo o un \itindex{process~group} \textit{process group}
corrispondenti al valore dell'identificativo specificato.
\item \errcode{E2BIG} \textit{Argument list too long}. La lista degli
- argomenti passati è troppo lunga: è una condizione prevista da POSIX quando
+ argomenti passati è troppo lunga: è una condizione prevista da POSIX quando
la lista degli argomenti passata ad una delle funzioni \func{exec} occupa
- troppa memoria, non può mai accadere in GNU/Linux.
+ troppa memoria, non può mai accadere in GNU/Linux.
\item \errcode{ECHILD} \textit{There are no child processes}. Non esistono
processi figli di cui attendere la terminazione. Viene rilevato dalle
funzioni \func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}).
\item \errcode{EPROCLIM} \textit{Too many processes}. Il limite dell'utente
- per nuovi processi (vedi sez.~\ref{sec:sys_resource_limit}) sarà ecceduto
- alla prossima \func{fork}; è un codice di errore di BSD, che non viene
+ per nuovi processi (vedi sez.~\ref{sec:sys_resource_limit}) sarà ecceduto
+ alla prossima \func{fork}; è un codice di errore di BSD, che non viene
utilizzato al momento su Linux.
\end{description}
\begin{description}
-\item \errcode{ENOTSOCK} \textit{Socket operation on non-socket}. Si è tentata
- un'operazione su un file descriptor che non è un socket quando invece era
+\item \errcode{ENOTSOCK} \textit{Socket operation on non-socket}. Si è tentata
+ un'operazione su un file descriptor che non è un socket quando invece era
richiesto un socket.
\item \errcode{EMSGSIZE} \textit{Message too long}. Le dimensioni di un
messaggio inviato su un socket sono eccedono la massima lunghezza supportata.
sbagliato per il socket. Il socket usato non supporta il protocollo di
comunicazione richiesto.
\item \errcode{ENOPROTOOPT} \textit{Protocol not available}. Protocollo non
- disponibile. Si è richiesta un'opzione per il socket non disponibile con il
+ disponibile. Si è richiesta un'opzione per il socket non disponibile con il
protocollo usato.
\item \errcode{EPROTONOSUPPORT} \textit{Protocol not supported}. Protocollo non
supportato. Il tipo di socket non supporta il protocollo richiesto (un
probabile errore nella specificazione del protocollo).
\item \errcode{ESOCKTNOSUPPORT} \textit{Socket type not supported}. Socket non
- supportato. Il tipo di socket scelto non è supportato.
+ supportato. Il tipo di socket scelto non è supportato.
\item \errcode{EOPNOTSUPP} \textit{Operation not supported on transport
- endpoint}. L'operazione richiesta non è supportata. Alcune funzioni non
+ endpoint}. L'operazione richiesta non è supportata. Alcune funzioni non
hanno senso per tutti i tipi di socket, ed altre non sono implementate per
tutti i protocolli di trasmissione. Questo errore quando un socket non
supporta una particolare operazione, e costituisce una indicazione generica
che il server non sa cosa fare per la chiamata effettuata.
\item \errcode{EPFNOSUPPORT} \textit{Protocol family not supported}. Famiglia
- di protocolli non supportata. La famiglia di protocolli richiesta non è
+ di protocolli non supportata. La famiglia di protocolli richiesta non è
supportata.
\item \errcode{EAFNOSUPPORT} \textit{Address family not supported by protocol}.
Famiglia di indirizzi non supportata. La famiglia di indirizzi richiesta non
- è supportata, o è inconsistente con il protocollo usato dal socket.
+ è supportata, o è inconsistente con il protocollo usato dal socket.
\item \errcode{EADDRINUSE} \textit{Address already in use}. L'indirizzo del
- socket richiesto è già utilizzato (ad esempio si è eseguita \func{bind}
- su una porta già in uso).
+ socket richiesto è già utilizzato (ad esempio si è eseguita \func{bind}
+ su una porta già in uso).
\item \errcode{EADDRNOTAVAIL} \textit{Cannot assign requested
- address}. L'indirizzo richiesto non è disponibile (ad esempio si
- è cercato di dare al socket un nome che non corrisponde al nome
+ address}. L'indirizzo richiesto non è disponibile (ad esempio si
+ è cercato di dare al socket un nome che non corrisponde al nome
della stazione locale), o l'interfaccia richiesta non esiste.
-\item \errcode{ENETDOWN} \textit{Network is down}. L'operazione sul socket è
- fallita perché la rete è sconnessa.
-\item \errcode{ENETUNREACH} \textit{Network is unreachable}. L'operazione è
- fallita perché l'indirizzo richiesto è irraggiungibile (ad esempio la
- sottorete della stazione remota è irraggiungibile).
+\item \errcode{ENETDOWN} \textit{Network is down}. L'operazione sul socket è
+ fallita perché la rete è sconnessa.
+\item \errcode{ENETUNREACH} \textit{Network is unreachable}. L'operazione è
+ fallita perché l'indirizzo richiesto è irraggiungibile (ad esempio la
+ sottorete della stazione remota è irraggiungibile).
\item \errcode{ENETRESET} \textit{Network dropped connection because of reset}.
- Una connessione è stata cancellata perché l'host remoto è caduto.
+ Una connessione è stata cancellata perché l'host remoto è caduto.
\item \errcode{ECONNABORTED} \textit{Software caused connection abort}. Una
- connessione è stata abortita localmente.
-\item \errcode{ECONNRESET} \textit{Connection reset by peer}. Una connessione è
+ connessione è stata abortita localmente.
+\item \errcode{ECONNRESET} \textit{Connection reset by peer}. Una connessione è
stata chiusa per ragioni fuori dal controllo dell'host locale, come il
riavvio di una macchina remota o un qualche errore non recuperabile sul
protocollo.
\item \errcode{ENOBUFS} \textit{No buffer space available}. Tutti i buffer per
- le operazioni di I/O del kernel sono occupati. In generale questo errore è
+ le operazioni di I/O del kernel sono occupati. In generale questo errore è
sinonimo di \errcode{ENOMEM}, ma attiene alle funzioni di input/output. In
- caso di operazioni sulla rete si può ottenere questo errore invece
+ caso di operazioni sulla rete si può ottenere questo errore invece
dell'altro.
-\item \errcode{EISCONN} \textit{Transport endpoint is already connected}. Si è
- tentato di connettere un socket che è già connesso.
+\item \errcode{EISCONN} \textit{Transport endpoint is already connected}. Si è
+ tentato di connettere un socket che è già connesso.
\item \errcode{ENOTCONN} \textit{Transport endpoint is not connected}. Il
- socket non è connesso a niente. Si ottiene questo errore quando si cerca di
+ socket non è connesso a niente. Si ottiene questo errore quando si cerca di
trasmettere dati su un socket senza avere specificato in precedenza la loro
destinazione. Nel caso di socket senza connessione (ad esempio socket UDP)
- l'errore che si ottiene è \errcode{EDESTADDRREQ}.
-\item \errcode{EDESTADDRREQ} \textit{Destination address required}. Non c'è un
+ l'errore che si ottiene è \errcode{EDESTADDRREQ}.
+\item \errcode{EDESTADDRREQ} \textit{Destination address required}. Non c'è un
indirizzo di destinazione predefinito per il socket. Si ottiene questo
errore mandando dato su un socket senza connessione senza averne prima
specificato una destinazione.
\item \errcode{ETIMEDOUT} \textit{Connection timed out}. Un'operazione sul
socket non ha avuto risposta entro il periodo di timeout.
\item \errcode{ECONNREFUSED} \textit{Connection refused}. Un host remoto ha
- rifiutato la connessione (in genere dipende dal fatto che non c'è un server
+ rifiutato la connessione (in genere dipende dal fatto che non c'è un server
per soddisfare il servizio richiesto).
\item \errcode{EHOSTDOWN} \textit{Host is down}. L'host remoto di una
- connessione è giù.
+ connessione è giù.
\item \errcode{EHOSTUNREACH} \textit{No route to host}. L'host remoto di una
- connessione non è raggiungibile.
+ connessione non è raggiungibile.
\end{description}
\section{Errori generici}
\begin{description}
\item \errcode{EINTR} \textit{Interrupted function call}. Una funzione di
- libreria è stata interrotta. In genere questo avviene causa di un segnale
+ libreria è stata interrotta. In genere questo avviene causa di un segnale
asincrono al processo che impedisce la conclusione della chiamata, la
funzione ritorna con questo errore una volta che si sia correttamente
- eseguito il gestore del segnale. In questo caso è necessario ripetere la
+ eseguito il gestore del segnale. In questo caso è necessario ripetere la
chiamata alla funzione.
-\item \errcode{ENOMEM} \textit{No memory available}. Il kernel non è in grado
+\item \errcode{ENOMEM} \textit{No memory available}. Il kernel non è in grado
di allocare ulteriore memoria per completare l'operazione richiesta.
\item \errcode{EDEADLK} \textit{Deadlock avoided}. L'allocazione di una
risorsa avrebbe causato un \itindex{deadlock} \textit{deadlock}. Non sempre
- il sistema è in grado di riconoscere queste situazioni, nel qual caso si
+ il sistema è in grado di riconoscere queste situazioni, nel qual caso si
avrebbe il blocco.
\item \errcode{EFAULT} \textit{Bad address}. Una stringa passata come
- argomento è fuori dello spazio di indirizzi del processo, in genere questa
+ argomento è fuori dello spazio di indirizzi del processo, in genere questa
situazione provoca direttamente l'emissione di un segnale di
\itindex{segment~violation} \textit{segment violation} (\const{SIGSEGV}).
\item \errcode{EINVAL} \textit{Invalid argument}. Errore utilizzato per
segnalare vari tipi di problemi dovuti all'aver passato un argomento
sbagliato ad una funzione di libreria.
-\item \errcode{EDOM} \textit{Domain error}. È usato dalle funzioni matematiche
- quando il valore di un argomento è al di fuori dell'intervallo in cui esse
+\item \errcode{EDOM} \textit{Domain error}. È usato dalle funzioni matematiche
+ quando il valore di un argomento è al di fuori dell'intervallo in cui esse
sono definite.
-\item \errcode{ERANGE} \textit{Range error}. È usato dalle funzioni
- matematiche quando il risultato dell'operazione non è rappresentabile nel
+\item \errcode{ERANGE} \textit{Range error}. È usato dalle funzioni
+ matematiche quando il risultato dell'operazione non è rappresentabile nel
valore di ritorno a causa di un overflow o di un underflow.
-\item \errcode{EAGAIN} \textit{Resource temporarily unavailable}. La funzione è
+\item \errcode{EAGAIN} \textit{Resource temporarily unavailable}. La funzione è
fallita ma potrebbe funzionare se la chiamata fosse ripetuta. Questo errore
accade in due tipologie di situazioni:
\begin{itemize}
- \item Si è effettuata un'operazione che si sarebbe bloccata su un oggetto
- che è stato posto in modalità non bloccante. Nei vecchi sistemi questo era
+ \item Si è effettuata un'operazione che si sarebbe bloccata su un oggetto
+ che è stato posto in modalità non bloccante. Nei vecchi sistemi questo era
un codice diverso, \errcode{EWOULDBLOCK}. In genere questo ha a che fare
- con file o socket, per i quali si può usare la funzione \func{select} per
+ con file o socket, per i quali si può usare la funzione \func{select} per
vedere quando l'operazione richiesta (lettura, scrittura o connessione)
diventa possibile.
- \item Indica la carenza di una risorsa di sistema che non è al momento
- disponibile (ad esempio \func{fork} può fallire con questo errore se si è
+ \item Indica la carenza di una risorsa di sistema che non è al momento
+ disponibile (ad esempio \func{fork} può fallire con questo errore se si è
esaurito il numero di processi contemporanei disponibili). La ripetizione
della chiamata in un periodo successivo, in cui la carenza della risorsa
- richiesta può essersi attenuata, può avere successo. Questo tipo di
- carenza è spesso indice di qualcosa che non va nel sistema, è pertanto
+ richiesta può essersi attenuata, può avere successo. Questo tipo di
+ carenza è spesso indice di qualcosa che non va nel sistema, è pertanto
opportuno segnalare esplicitamente questo tipo di errori.
\end{itemize}
\item \errcode{EWOULDBLOCK} \textit{Operation would block}. Indica che
l'operazione richiesta si bloccherebbe, ad esempio se si apre un file in
- modalità non bloccante, una \func{read} restituirebbe questo errore per
- indicare che non ci sono dati; in Linux è identico a \errcode{EAGAIN}, ma in
- altri sistemi può essere specificato un valore diverso.
+ modalità non bloccante, una \func{read} restituirebbe questo errore per
+ indicare che non ci sono dati; in Linux è identico a \errcode{EAGAIN}, ma in
+ altri sistemi può essere specificato un valore diverso.
\item \errcode{EINPROGRESS} \textit{Operation now in progress}. Operazione in
- corso. Un'operazione che non può essere completata immediatamente è stata
- avviata su un oggetto posto in modalità non-bloccante. Questo errore viene
+ corso. Un'operazione che non può essere completata immediatamente è stata
+ avviata su un oggetto posto in modalità non-bloccante. Questo errore viene
riportato per operazioni che si dovrebbero sempre bloccare (come per una
\func{connect}) e che pertanto non possono riportare \errcode{EAGAIN},
- l'errore indica che l'operazione è stata avviata correttamente e occorrerà
- del tempo perché si possa completare. La ripetizione della chiamata darebbe
+ l'errore indica che l'operazione è stata avviata correttamente e occorrerà
+ del tempo perché si possa completare. La ripetizione della chiamata darebbe
luogo ad un errore \errcode{EALREADY}.
-\item \errcode{EALREADY} \textit{Operation already in progress}. L'operazione è
- già in corso. Si è tentata un'operazione già in corso su un oggetto posto in
- modalità non-bloccante.
+\item \errcode{EALREADY} \textit{Operation already in progress}. L'operazione è
+ già in corso. Si è tentata un'operazione già in corso su un oggetto posto in
+ modalità non-bloccante.
\item \errcode{ENOSYS} \textit{Function not implemented}. Indica che la
- funzione non è supportata o nelle librerie del C o nel kernel. Può dipendere
- sia dalla mancanza di una implementazione, che dal fatto che non si è
- abilitato l'opportuno supporto nel kernel; nel caso di Linux questo può
- voler dire anche che un modulo necessario non è stato caricato nel sistema.
+ funzione non è supportata o nelle librerie del C o nel kernel. Può dipendere
+ sia dalla mancanza di una implementazione, che dal fatto che non si è
+ abilitato l'opportuno supporto nel kernel; nel caso di Linux questo può
+ voler dire anche che un modulo necessario non è stato caricato nel sistema.
\item \errcode{ENOTSUP} \textit{Not supported}. Una funzione ritorna questo
- errore quando gli argomenti sono validi ma l'operazione richiesta non è
+ errore quando gli argomenti sono validi ma l'operazione richiesta non è
supportata. Questo significa che la funzione non implementa quel particolare
comando o opzione o che, in caso di oggetti specifici (file descriptor o
- altro) non è in grado di supportare i parametri richiesti.
+ altro) non è in grado di supportare i parametri richiesti.
\item \errcode{EILSEQ} \textit{Illegal byte sequence}. Nella decodifica di un
- carattere esteso si è avuta una sequenza errata o incompleta o si è
+ carattere esteso si è avuta una sequenza errata o incompleta o si è
specificato un valore non valido.
\end{description}
messaggio.
\item \errcode{EMULTIHOP} \textit{Multihop attempted}. Definito da POSIX come
- errore dovuto all'accesso a file remoti attraverso più macchine, quando ciò
- non è consentito. Non viene mai generato su Linux.
+ errore dovuto all'accesso a file remoti attraverso più macchine, quando ciò
+ non è consentito. Non viene mai generato su Linux.
\item \errcode{EIDRM} \textit{Identifier removed}. Indica che l'oggetto del
- \textit{SysV IPC} a cui si fa riferimento è stato cancellato.
+ \textit{SysV IPC} a cui si fa riferimento è stato cancellato.
\item \errcode{ENODATA} \textit{No data available}. Viene indicato da POSIX
come restituito da una \func{read} eseguita su un file descriptor in
- modalità non bloccante quando non ci sono dati. In realtà in questo caso su
- Linux viene utilizzato \errcode{EAGAIN}. Lo stesso valore valore però viene
+ modalità non bloccante quando non ci sono dati. In realtà in questo caso su
+ Linux viene utilizzato \errcode{EAGAIN}. Lo stesso valore valore però viene
usato come sinonimo di \errcode{ENOATTR}.
-\item \errcode{ENOATTR} \textit{No such attribute}. È un codice di errore
+\item \errcode{ENOATTR} \textit{No such attribute}. È un codice di errore
specifico di Linux utilizzato dalle funzioni per la gestione degli attributi
estesi dei file (vedi sez.~\ref{sec:file_xattr}) quando il nome
dell'attributo richiesto non viene trovato.
-\item \errcode{ENOLINK} \textit{Link has been severed}. È un errore il cui
- valore è indicato come \textsl{riservato} nelle \textit{Single Unix
- Specification}. Dovrebbe indicare l'impossibilità di accedere ad un file a
+\item \errcode{ENOLINK} \textit{Link has been severed}. È un errore il cui
+ valore è indicato come \textsl{riservato} nelle \textit{Single Unix
+ Specification}. Dovrebbe indicare l'impossibilità di accedere ad un file a
causa di un errore sul collegamento di rete, ma non ci sono indicazioni
precise del suo utilizzo. Per quanto riguarda Linux viene riportato nei
sorgenti del kernel in alcune operazioni relative ad operazioni di rete.
\item \errcode{ENOMSG} \textit{No message of desired type}. Indica che in una
- coda di messaggi del \textit{SysV IPC} non è presente nessun messaggio del
+ coda di messaggi del \textit{SysV IPC} non è presente nessun messaggio del
tipo desiderato.
\item \errcode{ENOSR} \textit{Out of streams resources}. Errore relativo agli
\textit{STREAMS}, che indica l'assenza di risorse sufficienti a completare
l'operazione richiesta. Quella degli \textit{STREAMS}\footnote{che non vanno
- confusi con gli \textit{stream} di cap.~\ref{cha:files_std_interface}.} è
- interfaccia di programmazione originaria di System V, che non è implementata
+ confusi con gli \textit{stream} di cap.~\ref{cha:files_std_interface}.} è
+ interfaccia di programmazione originaria di System V, che non è implementata
da Linux, per cui questo errore non viene utilizzato.
\item \errcode{ENOSTR} \textit{Device not a stream}. Altro errore relativo
agli \textit{STREAMS}, anch'esso non utilizzato da Linux.
-\item \errcode{EOVERFLOW} \textit{Value too large for defined data type}. Si è
+\item \errcode{EOVERFLOW} \textit{Value too large for defined data type}. Si è
chiesta la lettura di un dato dal \textit{SysV IPC} con \const{IPC\_STAT} ma
il valore eccede la dimensione usata nel buffer di lettura.
-\item \errcode{EPROTO} \textit{Protocol error}. Indica che c'è stato un errore
+\item \errcode{EPROTO} \textit{Protocol error}. Indica che c'è stato un errore
nel protocollo di rete usato dal socket; viene usato come errore generico
- dall'interfaccia degli \textit{STREAMS} quando non si è in grado di
- specificare un altro codice di errore che esprima più accuratamente la
+ dall'interfaccia degli \textit{STREAMS} quando non si è in grado di
+ specificare un altro codice di errore che esprima più accuratamente la
situazione.
-\item \errcode{ETIME} \textit{Timer expired}. Indica che è avvenuto un timeout
+\item \errcode{ETIME} \textit{Timer expired}. Indica che è avvenuto un timeout
nell'accesso ad una risorsa (ad esempio un semaforo). Compare nei sorgenti
del kernel (in particolare per le funzioni relativa al bus USB) come
indicazione di una mancata risposta di un dispositivo, con una descrizione
\label{cha:file_advanced}
In questo capitolo affronteremo le tematiche relative alla gestione avanzata
dei file. Inizieremo con la trattazione delle problematiche del \textit{file
- locking} e poi prenderemo in esame le varie funzionalità avanzate che
-permettono una gestione più sofisticata dell'I/O su file, a partire da quelle
-che consentono di gestire l'accesso contemporaneo a più file esaminando le
-varie modalità alternative di gestire l'I/O per concludere con la gestione dei
+ locking} e poi prenderemo in esame le varie funzionalità avanzate che
+permettono una gestione più sofisticata dell'I/O su file, a partire da quelle
+che consentono di gestire l'accesso contemporaneo a più file esaminando le
+varie modalità alternative di gestire l'I/O per concludere con la gestione dei
file mappati in memoria e le altre funzioni avanzate che consentono un
-controllo più dettagliato delle modalità di I/O.
+controllo più dettagliato delle modalità di I/O.
\section{Il \textit{file locking}}
\index{file!locking|(}
-In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
+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
-diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
-in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
-contemporaneamente sullo stesso file non è possibile determinare la sequenza
+diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
+in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
+contemporaneamente sullo stesso file non è possibile determinare la sequenza
in cui essi opereranno.
-Questo causa la possibilità di una \itindex{race~condition} \textit{race
- condition}; in generale le situazioni più comuni sono due: l'interazione fra
+Questo causa la possibilità di una \itindex{race~condition} \textit{race
+ condition}; in generale le situazioni più comuni sono due: l'interazione fra
un processo che scrive e altri che leggono, in cui questi ultimi possono
leggere informazioni scritte solo in maniera parziale o incompleta; o quella
in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro
output sul file.
-In tutti questi casi il \textit{file locking} è la tecnica che permette di
+In tutti questi casi il \textit{file locking} è la tecnica che permette di
evitare le \itindex{race~condition} \textit{race condition}, attraverso una
serie di funzioni che permettono di bloccare l'accesso al file da parte di
-altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
+altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
delle operazioni di lettura o scrittura.
\subsection{L'\textit{advisory locking}}
\label{sec:file_record_locking}
-La prima modalità di \textit{file locking} che è stata implementata nei
-sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
+La prima modalità di \textit{file locking} che è stata implementata nei
+sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
come al \textit{record locking}, dizione utilizzata anche dal manuale delle
\acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
mentre questo nome viene usato da Stevens per riferirsi al \textit{file
- locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
+ locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
ambigua, in quanto in un sistema Unix non esiste niente che possa fare
- riferimento al concetto di \textit{record}, alla fine si è scelto di
+ riferimento al concetto di \textit{record}, alla fine si è scelto di
mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
processi, e non il sistema, che si incaricano di asserire e verificare se
esistono delle condizioni di blocco per l'accesso ai file.
Questo significa che le funzioni \func{read} o \func{write} vengono eseguite
comunque e non risentono affatto della presenza di un eventuale \textit{lock};
-pertanto è sempre compito dei vari processi che intendono usare il
+pertanto è sempre compito dei vari processi che intendono usare il
\textit{file locking}, controllare esplicitamente lo stato dei file condivisi
prima di accedervi, utilizzando le relative funzioni.
In generale si distinguono due tipologie di \textit{file lock};\footnote{di
seguito ci riferiremo sempre ai blocchi di accesso ai file con la
- nomenclatura inglese di \textit{file lock}, o più brevemente con
+ nomenclatura inglese di \textit{file lock}, o più brevemente con
\textit{lock}, per evitare confusioni linguistiche con il blocco di un
- processo (cioè la condizione in cui il processo viene posto in stato di
- \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
+ processo (cioè la condizione in cui il processo viene posto in stato di
+ \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
\textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
-file affinché il suo contenuto non venga modificato mentre lo si legge. Si
-parla appunto di \textsl{blocco condiviso} in quanto più processi possono
+file affinché il suo contenuto non venga modificato mentre lo si legge. Si
+parla appunto di \textsl{blocco condiviso} in quanto più processi possono
richiedere contemporaneamente uno \textit{shared lock} su un file per
proteggere il loro accesso in lettura.
-La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
+La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
\textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
lettura che in scrittura) da parte di altri processi mentre lo si sta
-scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
-processo alla volta può richiedere un \textit{exclusive lock} su un file per
+scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
+processo alla volta può richiedere un \textit{exclusive lock} su un file per
proteggere il suo accesso in scrittura.
In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
- locking}, la prima è quella derivata da BSD, che è basata sulla funzione
-\func{flock}, la seconda è quella recepita dallo standard POSIX.1 (che è
-derivata dall'interfaccia usata in System V), che è basata sulla funzione
+ locking}, la prima è quella derivata da BSD, che è basata sulla funzione
+\func{flock}, la seconda è quella recepita dallo standard POSIX.1 (che è
+derivata dall'interfaccia usata in System V), che è basata sulla funzione
\func{fcntl}. I \textit{file lock} sono implementati in maniera completamente
-indipendente nelle due interfacce,\footnote{in realtà con Linux questo avviene
+indipendente nelle due interfacce,\footnote{in realtà con Linux questo avviene
solo dalla serie 2.0 dei kernel.} che pertanto possono coesistere senza
interferenze.
comportamento non bloccante) viene posto in stato di sleep. Una volta finite
le operazioni sul file si deve provvedere a rimuovere il blocco.
-La situazione delle varie possibilità che si possono verificare è riassunta in
+La situazione delle varie possibilità che si possono verificare è riassunta in
tab.~\ref{tab:file_file_lock}, dove si sono riportati, a seconda delle varie
-tipologie di blocco già presenti su un file, il risultato che si avrebbe in
+tipologie di blocco già presenti su un file, il risultato che si avrebbe in
corrispondenza di una ulteriore richiesta da parte di un processo di un blocco
nelle due tipologie di \textit{file lock} menzionate, con un successo o meno
della richiesta.
Si tenga presente infine che il controllo di accesso e la gestione dei
permessi viene effettuata quando si apre un file, l'unico controllo residuo
-che si può avere riguardo il \textit{file locking} è che il tipo di blocco che
-si vuole ottenere su un file deve essere compatibile con le modalità di
+che si può avere riguardo il \textit{file locking} è che il tipo di blocco che
+si vuole ottenere su un file deve essere compatibile con le modalità di
apertura dello stesso (in lettura per un \textit{read lock} e in scrittura per
un \textit{write lock}).
%% Si ricordi che
-%% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
-%% già un \textit{exclusive lock} attivo, mentre per acquisire un
+%% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
+%% già un \textit{exclusive lock} attivo, mentre per acquisire un
%% \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
La prima interfaccia per il \textit{file locking}, quella derivata da BSD,
permette di eseguire un blocco solo su un intero file; la funzione usata per
-richiedere e rimuovere un \textit{file lock} è \funcd{flock}, ed il suo
-prototipo è:
+richiedere e rimuovere un \textit{file lock} è \funcd{flock}, ed il suo
+prototipo è:
\begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
Applica o rimuove un \textit{file lock} sul file \param{fd}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EWOULDBLOCK}] il file ha già un blocco attivo, e si è
+ \item[\errcode{EWOULDBLOCK}] il file ha già un blocco attivo, e si è
specificato \const{LOCK\_NB}.
\end{errlist}
}
\end{prototype}
-La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
+La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
a seconda di quanto specificato tramite il valore dell'argomento
\param{operation}; questo viene interpretato come maschera binaria, e deve
essere passato costruendo il valore con un OR aritmetico delle costanti
I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
-bloccherà qualora il \textit{file lock} non possa essere acquisito, ma
-ritornerà subito con un errore di \errcode{EWOULDBLOCK}. Per rilasciare un
-\textit{file lock} si dovrà invece usare \const{LOCK\_UN}.
+bloccherà qualora il \textit{file lock} non possa essere acquisito, ma
+ritornerà subito con un errore di \errcode{EWOULDBLOCK}. Per rilasciare un
+\textit{file lock} si dovrà invece usare \const{LOCK\_UN}.
-Si tenga presente che non esiste una modalità per eseguire atomicamente un
+Si tenga presente che non esiste una modalità per eseguire atomicamente un
cambiamento del tipo di blocco (da \textit{shared lock} a \textit{esclusive
- lock}), il blocco deve essere prima rilasciato e poi richiesto, ed è sempre
+ lock}), il blocco deve essere prima rilasciato e poi richiesto, ed è sempre
possibile che nel frattempo abbia successo un'altra richiesta pendente,
facendo fallire la riacquisizione.
-Si tenga presente infine che \func{flock} non è supportata per i file
-mantenuti su NFS, in questo caso, se si ha la necessità di utilizzare il
+Si tenga presente infine che \func{flock} non è supportata per i file
+mantenuti su NFS, in questo caso, se si ha la necessità di utilizzare il
\textit{file locking}, occorre usare l'interfaccia del \textit{file locking}
-POSIX basata su \func{fcntl} che è in grado di funzionare anche attraverso
+POSIX basata su \func{fcntl} che è in grado di funzionare anche attraverso
NFS, a condizione ovviamente che sia il client che il server supportino questa
-funzionalità.
+funzionalità.
-La semantica del \textit{file locking} di BSD inoltre è diversa da quella del
+La semantica del \textit{file locking} di BSD inoltre è diversa da quella del
\textit{file locking} POSIX, in particolare per quanto riguarda il
comportamento dei \textit{file lock} nei confronti delle due funzioni
\func{dup} e \func{fork}. Per capire queste differenze occorre descrivere con
maggiore dettaglio come viene realizzato dal kernel il \textit{file locking}
per entrambe le interfacce.
-In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
+In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
dell'implementazione del \textit{file locking} in stile BSD su Linux. Il punto
-fondamentale da capire è che un \textit{file lock}, qualunque sia
+fondamentale da capire è che un \textit{file lock}, qualunque sia
l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
-agisce sempre su di un file; perciò le informazioni relative agli eventuali
+agisce sempre su di un file; perciò le informazioni relative agli eventuali
\textit{file lock} sono mantenute dal kernel a livello di
inode\index{inode},\footnote{in particolare, come accennato in
fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti in una
\itindex{linked~list} \textit{linked list} di strutture
- \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+ \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
mantenuto dal campo \var{i\_flock} della struttura \struct{inode} (per le
definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
del kernel). Un bit del campo \var{fl\_flags} di specifica se si tratta di
un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
-dato che questo è l'unico riferimento in comune che possono avere due processi
+dato che questo è l'unico riferimento in comune che possono avere due processi
diversi che aprono lo stesso file.
\begin{figure}[htb]
\end{figure}
La richiesta di un \textit{file lock} prevede una scansione della lista per
-determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
-un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
+determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
+un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
Nel caso dei blocchi creati con \func{flock} la semantica della funzione
prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un
\textit{file lock} quanto piuttosto degli ulteriori riferimenti allo
stesso. Questo viene realizzato dal kernel secondo lo schema di
fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock}
-un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
+un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
\struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file
- table} da cui si è richiesto il blocco, che così ne identifica il titolare.
+ table} da cui si è richiesto il blocco, che così ne identifica il titolare.
Questa struttura prevede che, quando si richiede la rimozione di un
\textit{file lock}, il kernel acconsenta solo se la richiesta proviene da un
file descriptor che fa riferimento ad una voce nella \itindex{file~table}
\textit{file table} corrispondente a quella registrata nel blocco. Allora se
ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
+sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
ereditati in un processo figlio puntano sempre alla stessa voce nella
-\itindex{file~table} \textit{file table}, si può capire immediatamente quali
+\itindex{file~table} \textit{file table}, si può capire immediatamente quali
sono le conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
-Sarà così possibile rimuovere un \textit{file lock} attraverso uno qualunque
+Sarà così possibile rimuovere un \textit{file lock} attraverso uno qualunque
dei file descriptor che fanno riferimento alla stessa voce nella
-\itindex{file~table} \textit{file table}, anche se questo è diverso da quello
-con cui lo si è creato,\footnote{attenzione, questo non vale se il file
+\itindex{file~table} \textit{file table}, anche se questo è diverso da quello
+con cui lo si è creato,\footnote{attenzione, questo non vale se il file
descriptor fa riferimento allo stesso file, ma attraverso una voce diversa
della \itindex{file~table} \textit{file table}, come accade tutte le volte
- che si apre più volte lo stesso file.} o se si esegue la rimozione in un
+ che si apre più volte lo stesso file.} o se si esegue la rimozione in un
processo figlio. Inoltre una volta tolto un \textit{file lock} su un file, la
-rimozione avrà effetto su tutti i file descriptor che condividono la stessa
+rimozione avrà effetto su tutti i file descriptor che condividono la stessa
voce nella \itindex{file~table} \textit{file table}, e quindi, nel caso di
file descriptor ereditati attraverso una \func{fork}, anche per processi
diversi.
dei \textit{file lock}, quando un file viene chiuso il kernel provvede anche a
rimuovere tutti i blocchi ad esso associati. Anche in questo caso occorre
tenere presente cosa succede quando si hanno file descriptor duplicati; in tal
-caso infatti il file non verrà effettivamente chiuso (ed il blocco rimosso)
+caso infatti il file non verrà effettivamente chiuso (ed il blocco rimosso)
fintanto che non viene rilasciata la relativa voce nella \itindex{file~table}
-\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
+\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
siano duplicati o processi figli che mantengono ancora aperto un file
descriptor, il \textit{file lock} non viene rilasciato.
\subsection{Il \textit{file locking} POSIX}
\label{sec:file_posix_lock}
-La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
+La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
-già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
+già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
essa viene usata solo secondo il seguente prototipo:
\begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
Applica o rimuove un \textit{file lock} sul file \param{fd}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EACCES}] l'operazione è proibita per la presenza di
+ \item[\errcode{EACCES}] l'operazione è proibita per la presenza di
\textit{file lock} da parte di altri processi.
\item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
- sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
- dei \textit{file lock}, o il protocollo per il blocco remoto è fallito.
- \item[\errcode{EDEADLK}] si è richiesto un \textit{lock} su una regione
- bloccata da un altro processo che è a sua volta in attesa dello sblocco
+ sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
+ dei \textit{file lock}, o il protocollo per il blocco remoto è fallito.
+ \item[\errcode{EDEADLK}] si è richiesto un \textit{lock} su una regione
+ bloccata da un altro processo che è a sua volta in attesa dello sblocco
di un \textit{lock} mantenuto dal processo corrente; si avrebbe pertanto
- un \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
+ un \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
riconosca sempre questa situazione.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
di poter acquisire un \textit{file lock}.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EFAULT}.
\end{prototype}
Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
-\func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
+\func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
relative agli eventuali blocchi preesistenti. Per poter fare tutto questo la
funzione utilizza come terzo argomento una apposita struttura \struct{flock}
-(la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
+(la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
inserire tutti i dati relativi ad un determinato blocco. Si tenga presente poi
che un \textit{file lock} fa sempre riferimento ad una regione, per cui si
-potrà avere un conflitto anche se c'è soltanto una sovrapposizione parziale
+potrà avere un conflitto anche se c'è soltanto una sovrapposizione parziale
con un'altra regione bloccata.
\begin{figure}[!bht]
\const{SEEK\_SET}, \const{SEEK\_CUR} e \const{SEEK\_END}, (si vedano le
relative descrizioni in sez.~\ref{sec:file_lseek}).
-Si tenga presente che un \textit{file lock} può essere richiesto anche per una
-regione al di là della corrente fine del file, così che una eventuale
+Si tenga presente che un \textit{file lock} può essere richiesto anche per una
+regione al di là della corrente fine del file, così che una eventuale
estensione dello stesso resti coperta dal blocco. Inoltre se si specifica un
valore nullo per \var{l\_len} il blocco si considera esteso fino alla
-dimensione massima del file; in questo modo è possibile bloccare una qualunque
+dimensione massima del file; in questo modo è possibile bloccare una qualunque
regione a partire da un certo punto fino alla fine del file, coprendo
automaticamente quanto eventualmente aggiunto in coda allo stesso.
\end{table}
Il tipo di \textit{file lock} richiesto viene specificato dal campo
-\var{l\_type}, esso può assumere i tre valori definiti dalle costanti
+\var{l\_type}, esso può assumere i tre valori definiti dalle costanti
riportate in tab.~\ref{tab:file_flock_type}, che permettono di richiedere
rispettivamente uno \textit{shared lock}, un \textit{esclusive lock}, e la
rimozione di un blocco precedentemente acquisito. Infine il campo \var{l\_pid}
\textit{file lock}.
Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
-effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
-\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
+effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
+\param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
l'azione da compiere; i valori relativi al \textit{file locking} sono tre:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{F\_GETLK}] verifica se il \textit{file lock} specificato dalla
- struttura puntata da \param{lock} può essere acquisito: in caso negativo
- sovrascrive la struttura \param{flock} con i valori relativi al blocco già
+ struttura puntata da \param{lock} può essere acquisito: in caso negativo
+ sovrascrive la struttura \param{flock} con i valori relativi al blocco già
esistente che ne blocca l'acquisizione, altrimenti si limita a impostarne il
campo \var{l\_type} con il valore \const{F\_UNLCK}.
\item[\const{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
- \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
- corrispondente \textit{file lock}, se è \const{F\_UNLCK} lo rilascia. Nel
+ \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
+ corrispondente \textit{file lock}, se è \const{F\_UNLCK} lo rilascia. Nel
caso la richiesta non possa essere soddisfatta a causa di un blocco
preesistente la funzione ritorna immediatamente con un errore di
\errcode{EACCES} o di \errcode{EAGAIN}.
-\item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
- non può essere soddisfatta per la presenza di un altro blocco, mette il
+\item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
+ non può essere soddisfatta per la presenza di un altro blocco, mette il
processo in stato di attesa fintanto che il blocco precedente non viene
rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
con un errore di \errcode{EINTR}.
\end{basedescript}
Si noti che per quanto detto il comando \const{F\_GETLK} non serve a rilevare
-una presenza generica di blocco su un file, perché se ne esistono altri
+una presenza generica di blocco su un file, perché se ne esistono altri
compatibili con quello richiesto, la funzione ritorna comunque impostando
\var{l\_type} a \const{F\_UNLCK}. Inoltre a seconda del valore di
-\var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di
-blocco (se è \const{F\_WRLCK}) o di \textit{write lock} (se è
-\const{F\_RDLCK}). Si consideri poi che può esserci più di un blocco che
+\var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di
+blocco (se è \const{F\_WRLCK}) o di \textit{write lock} (se è
+\const{F\_RDLCK}). Si consideri poi che può esserci più di un blocco che
impedisce l'acquisizione di quello richiesto (basta che le regioni si
-sovrappongano), ma la funzione ne riporterà sempre soltanto uno, impostando
+sovrappongano), ma la funzione ne riporterà sempre soltanto uno, impostando
\var{l\_whence} a \const{SEEK\_SET} ed i valori \var{l\_start} e \var{l\_len}
-per indicare quale è la regione bloccata.
+per indicare quale è la regione bloccata.
Infine si tenga presente che effettuare un controllo con il comando
-\const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
+\const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
operazione atomica (un altro processo potrebbe acquisire un blocco fra le due
chiamate) per cui si deve sempre verificare il codice di ritorno di
\func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
- è comunque una buona norma di programmazione, che permette di evitare un
- sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
+ è comunque una buona norma di programmazione, che permette di evitare un
+ sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
quando la si invoca con \const{F\_SETLK}, per controllare che il blocco sia
stato effettivamente acquisito.
introduce un'ulteriore complicazione; consideriamo la situazione illustrata in
fig.~\ref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
processo B la regione 2. Supponiamo che successivamente il processo A richieda
-un lock sulla regione 2 che non può essere acquisito per il preesistente lock
-del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
+un lock sulla regione 2 che non può essere acquisito per il preesistente lock
+del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
-volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
+volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
Per capire meglio il funzionamento del \textit{file locking} in semantica
POSIX (che differisce alquanto rispetto da quello di BSD, visto
-sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
-kernel. Lo schema delle strutture utilizzate è riportato in
-fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
+sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
+kernel. Lo schema delle strutture utilizzate è riportato in
+fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
sono evidenziati solo i campi di \struct{file\_lock} significativi per la
semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
\acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
- bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
- comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
+ bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
+ comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
- usato.} il blocco è sempre associato \index{inode} all'inode, solo che in
-questo caso la titolarità non viene identificata con il riferimento ad una
+ usato.} il blocco è sempre associato \index{inode} all'inode, solo che in
+questo caso la titolarità non viene identificata con il riferimento ad una
voce nella \itindex{file~table} \textit{file table}, ma con il valore del
\acr{pid} del processo.
\end{figure}
Quando si richiede un \textit{file lock} il kernel effettua una scansione di
-tutti i blocchi presenti sul file\footnote{scandisce cioè la
+tutti i blocchi presenti sul file\footnote{scandisce cioè la
\itindex{linked~list} \textit{linked list} delle strutture
\struct{file\_lock}, scartando automaticamente quelle per cui
- \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
+ \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
ben separate.} per verificare se la regione richiesta non si sovrappone ad
-una già bloccata, in caso affermativo decide in base al tipo di blocco, in
+una già bloccata, in caso affermativo decide in base al tipo di blocco, in
caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
Nel caso di rimozione invece questa viene effettuata controllando che il
\acr{pid} del processo richiedente corrisponda a quello contenuto nel blocco.
-Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
-dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
+Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
+dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
-figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
+figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
\func{exec} in quanto il \acr{pid} resta lo stesso. Questo comporta che, al
contrario di quanto avveniva con la semantica BSD, quando un processo termina
tutti i \textit{file lock} da esso detenuti vengono immediatamente rilasciati.
-La seconda conseguenza è che qualunque file descriptor che faccia riferimento
+La seconda conseguenza è che qualunque file descriptor che faccia riferimento
allo stesso file (che sia stato ottenuto con una \func{dup} o con una
-\func{open} in questo caso non fa differenza) può essere usato per rimuovere
-un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
+\func{open} in questo caso non fa differenza) può essere usato per rimuovere
+un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
questo deriva una ulteriore sottile differenza di comportamento: dato che alla
chiusura di un file i blocchi ad esso associati vengono rimossi, nella
-semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
+semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
tutti i blocchi relativi al file cui esso faceva riferimento, anche se questi
fossero stati creati usando altri file descriptor che restano aperti.
Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del
\acr{pid} del processo, possiamo anche prendere in considerazione un altro
-degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
+degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno
stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
solo sul \acr{pid} del processo che chiama la funzione, queste richieste
avranno sempre successo.
Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
-accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
- cioè si richiede più volte lo stesso \textit{file lock}, o più blocchi sulla
+accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
+ cioè si richiede più volte lo stesso \textit{file lock}, o più blocchi sulla
stessa sezione di file, le richieste non si cumulano e basta una sola
richiesta di rilascio per cancellare il blocco.} la cosa non ha alcun
effetto; la funzione ritorna con successo, senza che il kernel debba
modificare la lista dei \textit{file lock}. In questo caso invece si possono
-avere una serie di situazioni diverse: ad esempio è possibile rimuovere con
-una sola chiamata più \textit{file lock} distinti (indicando in una regione
+avere una serie di situazioni diverse: ad esempio è possibile rimuovere con
+una sola chiamata più \textit{file lock} distinti (indicando in una regione
che si sovrapponga completamente a quelle di questi ultimi), o rimuovere solo
una parte di un blocco preesistente (indicando una regione contenuta in quella
di un altro blocco), creando un buco, o coprire con un nuovo blocco altri
-\textit{file lock} già ottenuti, e così via, a secondo di come si
+\textit{file lock} già ottenuti, e così via, a secondo di come si
sovrappongono le regioni richieste e del tipo di operazione richiesta. Il
comportamento seguito in questo caso che la funzione ha successo ed esegue
-l'operazione richiesta sulla regione indicata; è compito del kernel
+l'operazione richiesta sulla regione indicata; è compito del kernel
preoccuparsi di accorpare o dividere le voci nella lista dei \textit{file
lock} per far si che le regioni bloccate da essa risultanti siano coerenti
con quanto necessario a soddisfare l'operazione richiesta.
\label{fig:file_flock_code}
\end{figure}
-Per fare qualche esempio sul \textit{file locking} si è scritto un programma che
+Per fare qualche esempio sul \textit{file locking} si è scritto un programma che
permette di bloccare una sezione di un file usando la semantica POSIX, o un
-intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
-riportata il corpo principale del codice del programma, (il testo completo è
+intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
+riportata il corpo principale del codice del programma, (il testo completo è
allegato nella directory dei sorgenti).
-La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
+La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
funzione che stampa le istruzioni per l'uso del programma, essa si cura di
impostare le variabili \var{type}, \var{start} e \var{len}; queste ultime due
vengono inizializzate al valore numerico fornito rispettivamente tramite gli
switch \code{-s} e \cmd{-l}, mentre il valore della prima viene impostato con
le opzioni \cmd{-w} e \cmd{-r} si richiede rispettivamente o un \textit{write
lock} o \textit{read lock} (i due valori sono esclusivi, la variabile
-assumerà quello che si è specificato per ultimo). Oltre a queste tre vengono
+assumerà quello che si è specificato per ultimo). Oltre a queste tre vengono
pure impostate la variabile \var{bsd}, che abilita la semantica omonima quando
-si invoca l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la
-semantica POSIX), e la variabile \var{cmd} che specifica la modalità di
+si invoca l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la
+semantica POSIX), e la variabile \var{cmd} che specifica la modalità di
richiesta del \textit{file lock} (bloccante o meno), a seconda dell'opzione
\cmd{-b}.
reimpostare il valore di \var{cmd} per l'uso con \func{flock}; infatti il
valore preimpostato fa riferimento alla semantica POSIX e vale rispettivamente
\const{F\_SETLKW} o \const{F\_SETLK} a seconda che si sia impostato o meno la
-modalità bloccante.
+modalità bloccante.
Nel caso si sia scelta la semantica BSD (\texttt{\small 25--34}) prima si
controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se
opportunamente, dopo di che a seconda del tipo di blocco al valore viene
aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock}
vuole un argomento \param{operation} in forma di maschera binaria. Nel caso
-invece che si sia scelta la semantica POSIX le operazioni sono molto più
+invece che si sia scelta la semantica POSIX le operazioni sono molto più
immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
esegue (\texttt{\small 41}).
In entrambi i casi dopo aver richiesto il blocco viene controllato il
risultato uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un
messaggio (\texttt{\small 47--49}) in caso di successo. Infine il programma si
-pone in attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c}
+pone in attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c}
dato da tastiera) non lo interrompa; in questo caso il programma termina, e
tutti i blocchi vengono rilasciati.
\end{verbatim}%$
\end{minipage}\vspace{1mm}
\par\noindent
-il programma segnalerà di aver acquisito un blocco e si bloccherà; in questo
-caso si è usato il \textit{file locking} POSIX e non avendo specificato niente
+il programma segnalerà di aver acquisito un blocco e si bloccherà; in questo
+caso si è usato il \textit{file locking} POSIX e non avendo specificato niente
riguardo alla sezione che si vuole bloccare sono stati usati i valori
preimpostati che bloccano tutto il file. A questo punto se proviamo ad
eseguire lo stesso comando in un altro terminale, e avremo lo stesso
\end{verbatim}%$
\end{minipage}\vspace{1mm}
\par\noindent
-come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
-blocco, dato che il file è bloccato dal precedente \textit{read lock}. Si noti
-che il risultato è lo stesso anche se si richiede il blocco su una sola parte
+come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
+blocco, dato che il file è bloccato dal precedente \textit{read lock}. Si noti
+che il risultato è lo stesso anche se si richiede il blocco su una sola parte
del file con il comando:
\vspace{1mm}
\end{verbatim}%$
\end{minipage}\vspace{1mm}
\par\noindent
-come ci aspettiamo questo non sarà consentito.
+come ci aspettiamo questo non sarà consentito.
-Il programma di norma esegue il tentativo di acquisire il lock in modalità non
-bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
+Il programma di norma esegue il tentativo di acquisire il lock in modalità non
+bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
bloccante, riproviamo allora a ripetere le prove precedenti con questa
opzione:
\end{minipage}\vspace{1mm}
\par\noindent
il primo comando acquisisce subito un \textit{read lock}, e quindi non cambia
-nulla, ma se proviamo adesso a richiedere un \textit{write lock} che non potrà
+nulla, ma se proviamo adesso a richiedere un \textit{write lock} che non potrà
essere acquisito otterremo:
\vspace{1mm}
\end{verbatim}%$
\end{minipage}\vspace{1mm}
\par\noindent
-il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
+il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
punto rilasciamo il precedente blocco (terminando il primo comando un
\texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
blocco viene acquisito, con la comparsa di una nuova riga:
\end{minipage}\vspace{3mm}
\par\noindent
-Un'altra cosa che si può controllare con il nostro programma è l'interazione
-fra i due tipi di blocco; se ripartiamo dal primo comando con cui si è
+Un'altra cosa che si può controllare con il nostro programma è l'interazione
+fra i due tipi di blocco; se ripartiamo dal primo comando con cui si è
ottenuto un blocco in lettura sull'intero file, possiamo verificare cosa
succede quando si cerca di ottenere un blocco in scrittura con la semantica
BSD:
\label{sec:file_lockf}
Abbiamo visto come l'interfaccia POSIX per il \textit{file locking} sia molto
-più potente e flessibile di quella di BSD, questo comporta anche una maggiore
-complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
-motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
-che utilizza la funzione \funcd{lockf}, il cui prototipo è:
+più potente e flessibile di quella di BSD, questo comporta anche una maggiore
+complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
+motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
+che utilizza la funzione \funcd{lockf}, il cui prototipo è:
\begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EWOULDBLOCK}] non è possibile acquisire il lock, e si è
- selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
- file è mappato in memoria.
+ \item[\errcode{EWOULDBLOCK}] non è possibile acquisire il lock, e si è
+ selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
+ file è mappato in memoria.
\item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
- sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
+ sono troppi segmenti di \textit{lock} aperti, si è esaurita la tabella
dei \textit{file lock}.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EINVAL}.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
+ \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
mantenere un blocco condiviso sullo stesso file.\\
\const{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
- alla volta può mantenere un blocco esclusivo su un file.\\
+ alla volta può mantenere un blocco esclusivo su un file.\\
\const{LOCK\_UN}& Sblocca il file.\\
- \const{LOCK\_NB}& Non blocca la funzione quando il blocco non è disponibile,
+ \const{LOCK\_NB}& Non blocca la funzione quando il blocco non è disponibile,
si specifica sempre insieme ad una delle altre operazioni
con un OR aritmetico dei valori.\\
\hline
\end{table}
Qualora il blocco non possa essere acquisito, a meno di non aver specificato
-\const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
-Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
-delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
+\const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
+Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
+delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
affatto equivalente a \func{flock}).
\itindbeg{mandatory~locking|(}
-Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
+Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
per introdurre un \textit{file locking} che, come dice il nome, fosse
effettivo indipendentemente dai controlli eseguiti da un processo. Con il
-\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
-direttamente al sistema, così che, anche qualora non si predisponessero le
+\textit{mandatory locking} infatti è possibile far eseguire il blocco del file
+direttamente al sistema, così che, anche qualora non si predisponessero le
opportune verifiche nei processi, questo verrebbe comunque rispettato.
-Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
+Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
utilizzato per cambiare il group-ID effettivo con cui viene eseguito un
-programma, ed è pertanto sempre associato alla presenza del permesso di
+programma, ed è pertanto sempre associato alla presenza del permesso di
esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
-esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
+esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
quest'ultimo venga attivato per il file in questione. In questo modo una
combinazione dei permessi originariamente non contemplata, in quanto senza
significato, diventa l'indicazione della presenza o meno del \textit{mandatory
locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
- sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
+ sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
cancellato (come misura di sicurezza) quando di scrive su un file, questo
non vale quando esso viene utilizzato per attivare il \textit{mandatory
locking}.}
L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
-neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
-un processo che blocchi un file cruciale può renderlo completamente
+neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
+un processo che blocchi un file cruciale può renderlo completamente
inaccessibile, rendendo completamente inutilizzabile il sistema\footnote{il
problema si potrebbe risolvere rimuovendo il bit \itindex{sgid~bit}
- \acr{sgid}, ma non è detto che sia così facile fare questa operazione con un
- sistema bloccato.} inoltre con il \textit{mandatory locking} si può
+ \acr{sgid}, ma non è detto che sia così facile fare questa operazione con un
+ sistema bloccato.} inoltre con il \textit{mandatory locking} si può
bloccare completamente un server NFS richiedendo una lettura su un file su cui
-è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
- locking} è di norma disabilitata, e deve essere attivata filesystem per
+è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
+ locking} è di norma disabilitata, e deve essere attivata filesystem per
filesystem in fase di montaggio (specificando l'apposita opzione di
\func{mount} riportata in tab.~\ref{tab:sys_mount_flags}, o con l'opzione
\code{-o mand} per il comando omonimo).
Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
ha nessun effetto sui \textit{file lock} richiesti con l'interfaccia di
-\func{flock}, e che la granularità del blocco è quella del singolo byte, come
+\func{flock}, e che la granularità del blocco è quella del singolo byte, come
per \func{fcntl}.
-La sintassi di acquisizione dei blocchi è esattamente la stessa vista in
-precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
-\textit{mandatory lock} attivato non è più necessario controllare la
-disponibilità di accesso al file, ma si potranno usare direttamente le
-ordinarie funzioni di lettura e scrittura e sarà compito del kernel gestire
+La sintassi di acquisizione dei blocchi è esattamente la stessa vista in
+precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
+\textit{mandatory lock} attivato non è più necessario controllare la
+disponibilità di accesso al file, ma si potranno usare direttamente le
+ordinarie funzioni di lettura e scrittura e sarà compito del kernel gestire
direttamente il \textit{file locking}.
-Questo significa che in caso di \textit{read lock} la lettura dal file potrà
-avvenire normalmente con \func{read}, mentre una \func{write} si bloccherà
+Questo significa che in caso di \textit{read lock} la lettura dal file potrà
+avvenire normalmente con \func{read}, mentre una \func{write} si bloccherà
fino al rilascio del blocco, a meno di non aver aperto il file con
-\const{O\_NONBLOCK}, nel qual caso essa ritornerà immediatamente con un errore
+\const{O\_NONBLOCK}, nel qual caso essa ritornerà immediatamente con un errore
di \errcode{EAGAIN}.
-Se invece si è acquisito un \textit{write lock} tutti i tentativi di leggere o
+Se invece si è acquisito un \textit{write lock} tutti i tentativi di leggere o
scrivere sulla regione del file bloccata fermeranno il processo fino al
rilascio del blocco, a meno che il file non sia stato aperto con
-\const{O\_NONBLOCK}, nel qual caso di nuovo si otterrà un ritorno immediato
+\const{O\_NONBLOCK}, nel qual caso di nuovo si otterrà un ritorno immediato
con l'errore di \errcode{EAGAIN}.
Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
sole ad operare sui contenuti di un file, e che sia \func{creat} che
\func{open} (quando chiamata con \const{O\_TRUNC}) effettuano dei cambiamenti,
-così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
+così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
con un errore di \errcode{EAGAIN}) su un file su cui sia presente un qualunque
dimensioni del file vada a sovrapporsi ad una regione bloccata).
L'ultimo aspetto della interazione del \textit{mandatory locking} con le
-funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
+funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
abbiamo trattato in sez.~\ref{sec:file_memory_map}); anche in tal caso
infatti, quando si esegue la mappatura con l'opzione \const{MAP\_SHARED}, si
ha un accesso al contenuto del file. Lo standard SVID prevede che sia
impossibile eseguire il memory mapping di un file su cui sono presenti dei
-blocchi\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
+blocchi\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
impediscono anche in caso di \textit{advisory locking}, anche se questo
comportamento non ha molto senso, dato che comunque qualunque accesso
- diretto al file è consentito.} in Linux è stata però fatta la scelta
+ diretto al file è consentito.} in Linux è stata però fatta la scelta
implementativa\footnote{per i dettagli si possono leggere le note relative
all'implementazione, mantenute insieme ai sorgenti del kernel nel file
\file{Documentation/mandatory.txt}.} di seguire questo comportamento
soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
-possibilità di modificare il file.
+possibilità di modificare il file.
\index{file!locking|)}
Uno dei problemi che si presentano quando si deve operare contemporaneamente
su molti file usando le funzioni illustrate in
-cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
-si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
+cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
+si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
essere disponibile. L'\textit{I/O multiplexing} nasce risposta a questo
problema. In questa sezione forniremo una introduzione a questa problematica
-ed analizzeremo le varie funzioni usate per implementare questa modalità di
+ed analizzeremo le varie funzioni usate per implementare questa modalità di
I/O.
Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
\textit{fast} e \textit{slow} system call,\index{system~call~lente} che in
certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si
- ricordi però che questo può accadere solo per le pipe, i socket ed alcuni
+ ricordi però che questo può accadere solo per le pipe, i socket ed alcuni
file di dispositivo\index{file!di~dispositivo}; sui file normali le funzioni
di lettura e scrittura ritornano sempre subito.} Ad esempio le operazioni
di lettura possono bloccarsi quando non ci sono dati disponibili sul
descrittore su cui si sta operando.
-Questo comportamento causa uno dei problemi più comuni che ci si trova ad
+Questo comportamento causa uno dei problemi più comuni che ci si trova ad
affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
-più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
-possibile prevedere quando questo può avvenire (il caso più classico è quello
-di un server in attesa di dati in ingresso da vari client). Quello che può
-accadere è di restare bloccati nell'eseguire una operazione su un file
-descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
+più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
+possibile prevedere quando questo può avvenire (il caso più classico è quello
+di un server in attesa di dati in ingresso da vari client). Quello che può
+accadere è di restare bloccati nell'eseguire una operazione su un file
+descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
altro disponibile. Questo comporta nel migliore dei casi una operazione
ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre
nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
potrebbe addirittura arrivare ad un \itindex{deadlock} \textit{deadlock}.
-Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
+Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
questo tipo di comportamento delle funzioni di I/O aprendo un file in
-\textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
+\textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
nella chiamata di \func{open}. In questo caso le funzioni di input/output
eseguite sul file che si sarebbero bloccate, ritornano immediatamente,
-restituendo l'errore \errcode{EAGAIN}. L'utilizzo di questa modalità di I/O
+restituendo l'errore \errcode{EAGAIN}. L'utilizzo di questa modalità di I/O
permette di risolvere il problema controllando a turno i vari file descriptor,
in un ciclo in cui si ripete l'accesso fintanto che esso non viene garantito.
-Ovviamente questa tecnica, detta \itindex{polling} \textit{polling}, è
+Ovviamente questa tecnica, detta \itindex{polling} \textit{polling}, è
estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
eseguire in continuazione delle system call che nella gran parte dei casi
falliranno.
-Per superare questo problema è stato introdotto il concetto di \textit{I/O
- multiplexing}, una nuova modalità di operazioni che consente di tenere sotto
-controllo più file descriptor in contemporanea, permettendo di bloccare un
+Per superare questo problema è stato introdotto il concetto di \textit{I/O
+ multiplexing}, una nuova modalità di operazioni che consente di tenere sotto
+controllo più file descriptor in contemporanea, permettendo di bloccare un
processo quando le operazioni volute non sono possibili, e di riprenderne
l'esecuzione una volta che almeno una di quelle richieste sia effettuabile, in
modo da poterla eseguire con la sicurezza di non restare bloccati.
-Dato che, come abbiamo già accennato, per i normali file su disco non si ha
-mai un accesso bloccante, l'uso più comune delle funzioni che esamineremo nei
-prossimi paragrafi è per i server di rete, in cui esse vengono utilizzate per
+Dato che, come abbiamo già accennato, per i normali file su disco non si ha
+mai un accesso bloccante, l'uso più comune delle funzioni che esamineremo nei
+prossimi paragrafi è per i server di rete, in cui esse vengono utilizzate per
tenere sotto controllo dei socket; pertanto ritorneremo su di esse con
ulteriori dettagli e qualche esempio di utilizzo concreto in
sez.~\ref{sec:TCP_sock_multiplexing}.
\label{sec:file_select}
Il primo kernel unix-like ad introdurre una interfaccia per l'\textit{I/O
- multiplexing} è stato BSD,\footnote{la funzione \func{select} è apparsa in
- BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i sistemi che
+ multiplexing} è stato BSD,\footnote{la funzione \func{select} è apparsa in
+ BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i sistemi che
supportano i socket, compreso le varianti di System V.} con la funzione
-\funcd{select}, il cui prototipo è:
+\funcd{select}, il cui prototipo è:
\begin{functions}
\headdecl{sys/time.h}
\headdecl{sys/types.h}
\bodydesc{La funzione in caso di successo restituisce il numero di file
descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
- caso \var{errno} assumerà uno dei valori:
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+ \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
degli insiemi.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
- \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
o un valore non valido per \param{timeout}.
\end{errlist}
ed inoltre \errval{ENOMEM}.
Rimuove il file descriptor \param{fd} dall'insieme.
\funcdecl{int \macro{FD\_ISSET}(int fd, fd\_set *set)}
- Controlla se il file descriptor \param{fd} è nell'insieme.
+ Controlla se il file descriptor \param{fd} è nell'insieme.
\end{functions}
-In genere un \textit{file descriptor set} può contenere fino ad un massimo di
+In genere un \textit{file descriptor set} può contenere fino ad un massimo di
\const{FD\_SETSIZE} file descriptor. Questo valore in origine corrispondeva
al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma da
-quando, come nelle versioni più recenti del kernel, questo limite è stato
+quando, come nelle versioni più recenti del kernel, questo limite è stato
rimosso, esso indica le dimensioni massime dei numeri usati nei \textit{file
descriptor set}.\footnote{il suo valore, secondo lo standard POSIX
- 1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.}
+ 1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.}
Si tenga presente che i \textit{file descriptor set} devono sempre essere
inizializzati con \macro{FD\_ZERO}; passare a \func{select} un valore non
-inizializzato può dar luogo a comportamenti non prevedibili; allo stesso modo
+inizializzato può dar luogo a comportamenti non prevedibili; allo stesso modo
usare \macro{FD\_SET} o \macro{FD\_CLR} con un file descriptor il cui valore
-eccede \const{FD\_SETSIZE} può dare luogo ad un comportamento indefinito.
+eccede \const{FD\_SETSIZE} può dare luogo ad un comportamento indefinito.
La funzione richiede di specificare tre insiemi distinti di file descriptor;
-il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
-effettuare una lettura,\footnote{per essere precisi la funzione ritornerà in
+il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
+effettuare una lettura,\footnote{per essere precisi la funzione ritornerà in
tutti i casi in cui la successiva esecuzione di \func{read} risulti non
bloccante, quindi anche in caso di \textit{end-of-file}; inoltre con Linux
possono verificarsi casi particolari, ad esempio quando arrivano dati su un
- socket dalla rete che poi risultano corrotti e vengono scartati, può
+ socket dalla rete che poi risultano corrotti e vengono scartati, può
accadere che \func{select} riporti il relativo file descriptor come
leggibile, ma una successiva \func{read} si blocchi.} il secondo,
-\param{writefds}, per verificare la possibilità di effettuare una scrittura ed
+\param{writefds}, per verificare la possibilità di effettuare una scrittura ed
il terzo, \param{exceptfds}, per verificare l'esistenza di eccezioni (come i
dati urgenti \itindex{out-of-band} su un socket, vedi
sez.~\ref{sec:TCP_urgent_data}).
Dato che in genere non si tengono mai sotto controllo fino a
\const{FD\_SETSIZE} file contemporaneamente la funzione richiede di
-specificare qual è il valore più alto fra i file descriptor indicati nei tre
+specificare qual è il valore più alto fra i file descriptor indicati nei tre
insiemi precedenti. Questo viene fatto per efficienza, per evitare di passare
-e far controllare al kernel una quantità di memoria superiore a quella
+e far controllare al kernel una quantità di memoria superiore a quella
necessaria. Questo limite viene indicato tramite l'argomento \param{ndfs}, che
deve corrispondere al valore massimo aumentato di uno.\footnote{si ricordi che
i file descriptor sono numerati progressivamente a partire da zero, ed il
- valore indica il numero più alto fra quelli da tenere sotto controllo;
- dimenticarsi di aumentare di uno il valore di \param{ndfs} è un errore
+ valore indica il numero più alto fra quelli da tenere sotto controllo;
+ dimenticarsi di aumentare di uno il valore di \param{ndfs} è un errore
comune.}
Infine l'argomento \param{timeout}, espresso con una struttura di tipo
\struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct}) specifica un tempo
massimo di attesa prima che la funzione ritorni; se impostato a \val{NULL} la
-funzione attende indefinitamente. Si può specificare anche un tempo nullo
-(cioè una struttura \struct{timeval} con i campi impostati a zero), qualora si
+funzione attende indefinitamente. Si può specificare anche un tempo nullo
+(cioè una struttura \struct{timeval} con i campi impostati a zero), qualora si
voglia semplicemente controllare lo stato corrente dei file descriptor.
-La funzione restituisce il numero di file descriptor pronti,\footnote{questo è
+La funzione restituisce il numero di file descriptor pronti,\footnote{questo è
il comportamento previsto dallo standard, ma la standardizzazione della
- funzione è recente, ed esistono ancora alcune versioni di Unix che non si
+ funzione è recente, ed esistono ancora alcune versioni di Unix che non si
comportano in questo modo.} e ciascun insieme viene sovrascritto per
indicare quali sono i file descriptor pronti per le operazioni ad esso
relative, in modo da poterli controllare con \macro{FD\_ISSET}. Se invece si
ha un timeout viene restituito un valore nullo e gli insiemi non vengono
modificati. In caso di errore la funzione restituisce -1, ed i valori dei tre
-insiemi sono indefiniti e non si può fare nessun affidamento sul loro
+insiemi sono indefiniti e non si può fare nessun affidamento sul loro
contenuto.
\itindend{file~descriptor~set}
-Una volta ritornata la funzione si potrà controllare quali sono i file
-descriptor pronti ed operare su di essi, si tenga presente però che si tratta
+Una volta ritornata la funzione si potrà controllare quali sono i file
+descriptor pronti ed operare su di essi, si tenga presente però che si tratta
solo di un suggerimento, esistono infatti condizioni\footnote{ad esempio
- quando su un socket arrivano dei dati che poi vengono scartati perché
- corrotti.} in cui \func{select} può riportare in maniera spuria che un file
-descriptor è pronto in lettura, quando una successiva lettura si bloccherebbe.
-Per questo quando si usa \textit{I/O multiplexing} è sempre raccomandato l'uso
-delle funzioni di lettura e scrittura in modalità non bloccante.
+ quando su un socket arrivano dei dati che poi vengono scartati perché
+ corrotti.} in cui \func{select} può riportare in maniera spuria che un file
+descriptor è pronto in lettura, quando una successiva lettura si bloccherebbe.
+Per questo quando si usa \textit{I/O multiplexing} è sempre raccomandato l'uso
+delle funzioni di lettura e scrittura in modalità non bloccante.
In Linux \func{select} modifica anche il valore di \param{timeout},
impostandolo al tempo restante, quando la funzione viene interrotta da un
segnale. In tal caso infatti si ha un errore di \errcode{EINTR}, ed occorre
-rilanciare la funzione; in questo modo non è necessario ricalcolare tutte le
-volte il tempo rimanente. Questo può causare problemi di portabilità sia
+rilanciare la funzione; in questo modo non è necessario ricalcolare tutte le
+volte il tempo rimanente. Questo può causare problemi di portabilità sia
quando si usa codice scritto su Linux che legge questo valore, sia quando si
usano programmi scritti per altri sistemi che non dispongono di questa
caratteristica e ricalcolano \param{timeout} tutte le volte.\footnote{in
- genere questa caratteristica è disponibile nei sistemi che derivano da
- System V e non è disponibile per quelli che derivano da BSD; lo standard
+ genere questa caratteristica è disponibile nei sistemi che derivano da
+ System V e non è disponibile per quelli che derivano da BSD; lo standard
POSIX.1-2001 non permette questo comportamento.}
-Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
+Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
comportamento dipende dal valore del file descriptor che si vuole tenere sotto
controllo. Infatti il kernel riceve con \param{ndfs} un limite massimo per
tale valore, e per capire quali sono i file descriptor da tenere sotto
-controllo dovrà effettuare una scansione su tutto l'intervallo, che può anche
-essere molto ampio anche se i file descriptor sono solo poche unità; tutto ciò
+controllo dovrà effettuare una scansione su tutto l'intervallo, che può anche
+essere molto ampio anche se i file descriptor sono solo poche unità; tutto ciò
ha ovviamente delle conseguenze ampiamente negative per le prestazioni.
-Inoltre c'è anche il problema che il numero massimo dei file che si possono
-tenere sotto controllo, la funzione è nata quando il kernel consentiva un
-numero massimo di 1024 file descriptor per processo, adesso che il numero può
+Inoltre c'è anche il problema che il numero massimo dei file che si possono
+tenere sotto controllo, la funzione è nata quando il kernel consentiva un
+numero massimo di 1024 file descriptor per processo, adesso che il numero può
essere arbitrario si viene a creare una dipendenza del tutto artificiale dalle
-dimensioni della struttura \type{fd\_set}, che può necessitare di essere
+dimensioni della struttura \type{fd\_set}, che può necessitare di essere
estesa, con ulteriori perdite di prestazioni.
-Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
+Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
multiplexing}, introdotto solo con le ultime revisioni dello standard (POSIX
-1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
+1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
vengano dichiarate nell'header \file{sys/select.h}, che sostituisce i
precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
\acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
- senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
- \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
- \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
- maggiore di 600.} il cui prototipo è:
+ senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
+ \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
+ \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
+ maggiore di 600.} il cui prototipo è:
\begin{prototype}{sys/select.h}
{int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
struct timespec *timeout, sigset\_t *sigmask)}
\bodydesc{La funzione in caso di successo restituisce il numero di file
descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
- caso \var{errno} assumerà uno dei valori:
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+ \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
degli insiemi.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
- \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINVAL}] si è specificato per \param{ndfs} un valore negativo
o un valore non valido per \param{timeout}.
\end{errlist}
ed inoltre \errval{ENOMEM}.}
\end{prototype}
-La funzione è sostanzialmente identica a \func{select}, solo che usa una
+La funzione è sostanzialmente identica a \func{select}, solo che usa una
struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timespec_struct}) per
indicare con maggiore precisione il timeout e non ne aggiorna il valore in
-caso di interruzione.\footnote{in realtà la system call di Linux aggiorna il
+caso di interruzione.\footnote{in realtà la system call di Linux aggiorna il
valore al tempo rimanente, ma la funzione fornita dalle \acr{glibc} modifica
questo comportamento passando alla system call una variabile locale, in modo
da mantenere l'aderenza allo standard POSIX che richiede che il valore di
\param{timeout} non sia modificato.} Inoltre prende un argomento aggiuntivo
-\param{sigmask} che è il puntatore ad una maschera di segnali (si veda
+\param{sigmask} che è il puntatore ad una maschera di segnali (si veda
sez.~\ref{sec:sig_sigmask}). La maschera corrente viene sostituita da questa
immediatamente prima di eseguire l'attesa, e ripristinata al ritorno della
funzione.
-L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
+L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
\textit{race condition} \itindex{race~condition} quando ci si deve porre in
-attesa sia di un segnale che di dati. La tecnica classica è quella di
+attesa sia di un segnale che di dati. La tecnica classica è quella di
utilizzare il gestore per impostare una variabile globale e controllare questa
nel corpo principale del programma; abbiamo visto in
sez.~\ref{sec:sig_example} come questo lasci spazio a possibili race
Nel nostro caso il problema si pone quando oltre al segnale si devono tenere
sotto controllo anche dei file descriptor con \func{select}, in questo caso si
-può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta
+può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta
e si potrebbero eseguire di conseguenza le operazioni relative al segnale e
alla gestione dati con un ciclo del tipo:
\includecodesnip{listati/select_race.c}
-qui però emerge una \itindex{race~condition} \textit{race condition}, perché
-se il segnale arriva prima della chiamata a \func{select}, questa non verrà
-interrotta, e la ricezione del segnale non sarà rilevata.
+qui però emerge una \itindex{race~condition} \textit{race condition}, perché
+se il segnale arriva prima della chiamata a \func{select}, questa non verrà
+interrotta, e la ricezione del segnale non sarà rilevata.
-Per questo è stata introdotta \func{pselect} che attraverso l'argomento
+Per questo è stata introdotta \func{pselect} che attraverso l'argomento
\param{sigmask} permette di riabilitare la ricezione il segnale
-contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
+contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
kernel 2.6.16, non era presente la relativa system call, e la funzione era
implementata nelle \acr{glibc} attraverso \func{select} (vedi \texttt{man
- select\_tut}) per cui la possibilità di \itindex{race~condition}
- \textit{race condition} permaneva; in tale situazione si può ricorrere ad una
+ select\_tut}) per cui la possibilità di \itindex{race~condition}
+ \textit{race condition} permaneva; in tale situazione si può ricorrere ad una
soluzione alternativa, chiamata \itindex{self-pipe trick} \textit{self-pipe
trick}, che consiste nell'aprire una pipe (vedi sez.~\ref{sec:ipc_pipes})
- ed usare \func{select} sul capo in lettura della stessa; si può indicare
+ ed usare \func{select} sul capo in lettura della stessa; si può indicare
l'arrivo di un segnale scrivendo sul capo in scrittura all'interno del
gestore dello stesso; in questo modo anche se il segnale va perso prima
- della chiamata di \func{select} questa lo riconoscerà comunque dalla
- presenza di dati sulla pipe.} ribloccandolo non appena essa ritorna, così
+ della chiamata di \func{select} questa lo riconoscerà comunque dalla
+ presenza di dati sulla pipe.} ribloccandolo non appena essa ritorna, così
che il precedente codice potrebbe essere riscritto nel seguente modo:
\includecodesnip{listati/pselect_norace.c}
in questo caso utilizzando \var{oldmask} durante l'esecuzione di
-\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
+\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
interruzione si potranno eseguire le relative operazioni.
\label{sec:file_poll}
Nello sviluppo di System V, invece di utilizzare l'interfaccia di
-\func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra
-interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è
- prevista dallo standard XPG4, ed è stata introdotta in Linux come system
+\func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra
+interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è
+ prevista dallo standard XPG4, ed è stata introdotta in Linux come system
call a partire dal kernel 2.1.23 ed inserita nelle \acr{libc} 5.4.28.} il
-cui prototipo è:
+cui prototipo è:
\begin{prototype}{sys/poll.h}
{int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
La funzione attende un cambiamento di stato su un insieme di file
descriptor.
- \bodydesc{La funzione restituisce il numero di file descriptor con attività
- in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
- ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
+ \bodydesc{La funzione restituisce il numero di file descriptor con attività
+ in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
+ ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+ \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
degli insiemi.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
\macro{RLIMIT\_NOFILE}.
\end{errlist}
La funzione permette di tenere sotto controllo contemporaneamente \param{ndfs}
file descriptor, specificati attraverso il puntatore \param{ufds} ad un
-vettore di strutture \struct{pollfd}. Come con \func{select} si può
+vettore di strutture \struct{pollfd}. Come con \func{select} si può
interrompere l'attesa dopo un certo tempo, questo deve essere specificato con
l'argomento \param{timeout} in numero di millisecondi: un valore negativo
indica un'attesa indefinita, mentre un valore nullo comporta il ritorno
-immediato (e può essere utilizzato per impiegare \func{poll} in modalità
+immediato (e può essere utilizzato per impiegare \func{poll} in modalità
\textsl{non-bloccante}).
Per ciascun file da controllare deve essere inizializzata una struttura
\struct{pollfd} nel vettore indicato dall'argomento \param{ufds}. La
-struttura, la cui definizione è riportata in fig.~\ref{fig:file_pollfd},
+struttura, la cui definizione è riportata in fig.~\ref{fig:file_pollfd},
prevede tre campi: in \var{fd} deve essere indicato il numero del file
descriptor da controllare, in \var{events} deve essere specificata una
maschera binaria di flag che indichino il tipo di evento che si vuole
-controllare, mentre in \var{revents} il kernel restituirà il relativo
+controllare, mentre in \var{revents} il kernel restituirà il relativo
risultato. Usando un valore negativo per \param{fd} la corrispondente
-struttura sarà ignorata da \func{poll}. Dato che i dati in ingresso sono del
+struttura sarà ignorata da \func{poll}. Dato che i dati in ingresso sono del
tutto indipendenti da quelli in uscita (che vengono restituiti in
-\var{revents}) non è necessario reinizializzare tutte le volte il valore delle
+\var{revents}) non è necessario reinizializzare tutte le volte il valore delle
strutture \struct{pollfd} a meno di non voler cambiare qualche condizione.
\begin{figure}[!htb]
\end{minipage}
\normalsize
\caption{La struttura \structd{pollfd}, utilizzata per specificare le
- modalità di controllo di un file descriptor alla funzione \func{poll}.}
+ modalità di controllo di un file descriptor alla funzione \func{poll}.}
\label{fig:file_pollfd}
\end{figure}
binarie dei campi \var{events} e \var{revents} sono riportati in
tab.~\ref{tab:file_pollfd_flags}, insieme al loro significato. Le si sono
suddivise in tre gruppi, nel primo gruppo si sono indicati i bit utilizzati
-per controllare l'attività in ingresso, nel secondo quelli per l'attività in
+per controllare l'attività in ingresso, nel secondo quelli per l'attività in
uscita, mentre il terzo gruppo contiene dei valori che vengono utilizzati solo
nel campo \var{revents} per notificare delle condizioni di errore.
\textbf{Flag} & \textbf{Significato} \\
\hline
\hline
- \const{POLLIN} & È possibile la lettura.\\
+ \const{POLLIN} & È possibile la lettura.\\
\const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\
\const{POLLRDBAND}& Sono disponibili in lettura dati prioritari.\\
- \const{POLLPRI} & È possibile la lettura di \itindex{out-of-band} dati
+ \const{POLLPRI} & È possibile la lettura di \itindex{out-of-band} dati
urgenti.\\
\hline
- \const{POLLOUT} & È possibile la scrittura immediata.\\
- \const{POLLWRNORM}& È possibile la scrittura di dati normali.\\
- \const{POLLWRBAND}& È possibile la scrittura di dati prioritari.\\
+ \const{POLLOUT} & È possibile la scrittura immediata.\\
+ \const{POLLWRNORM}& È possibile la scrittura di dati normali.\\
+ \const{POLLWRBAND}& È possibile la scrittura di dati prioritari.\\
\hline
- \const{POLLERR} & C'è una condizione di errore.\\
- \const{POLLHUP} & Si è verificato un hung-up.\\
- \const{POLLRDHUP} & Si è avuta una \textsl{half-close} su un
+ \const{POLLERR} & C'è una condizione di errore.\\
+ \const{POLLHUP} & Si è verificato un hung-up.\\
+ \const{POLLRDHUP} & Si è avuta una \textsl{half-close} su un
socket.\footnotemark\\
- \const{POLLNVAL} & Il file descriptor non è aperto.\\
+ \const{POLLNVAL} & Il file descriptor non è aperto.\\
\hline
- \const{POLLMSG} & Definito per compatibilità con SysV.\\
+ \const{POLLMSG} & Definito per compatibilità con SysV.\\
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit dei campi
\textit{half-close} (\textsl{mezza chiusura}) su cui torneremo con maggiori
dettagli in sez.~\ref{sec:TCP_shutdown}.}
-Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
-compatibilità con l'implementazione di SysV che usa gli
+Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
+compatibilità con l'implementazione di SysV che usa gli
\textit{stream};\footnote{essi sono una interfaccia specifica di SysV non
presente in Linux, e non hanno nulla a che fare con i file \textit{stream}
- delle librerie standard del C.} è da questi che derivano i nomi di alcune
+ delle librerie standard del C.} è da questi che derivano i nomi di alcune
costanti, in quanto per essi sono definite tre classi di dati:
\textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In Linux la
distinzione ha senso solo per i dati urgenti \itindex{out-of-band} dei socket
in stile SysV (in particolare le ultime due non vengono usate su Linux), e
sono utilizzabili soltanto qualora si sia definita la macro
\macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in testa al
- file, definirla soltanto prima di includere \file{sys/poll.h} non è
+ file, definirla soltanto prima di includere \file{sys/poll.h} non è
sufficiente.}
In caso di successo funzione ritorna restituendo il numero di file (un valore
-positivo) per i quali si è verificata una delle condizioni di attesa richieste
-o per i quali si è verificato un errore, nel qual caso vengono utilizzati i
+positivo) per i quali si è verificata una delle condizioni di attesa richieste
+o per i quali si è verificato un errore, nel qual caso vengono utilizzati i
valori di tab.~\ref{tab:file_pollfd_flags} esclusivi di \var{revents}. Un
-valore nullo indica che si è raggiunto il timeout, mentre un valore negativo
+valore nullo indica che si è raggiunto il timeout, mentre un valore negativo
indica un errore nella chiamata, il cui codice viene riportato al solito
tramite \var{errno}.
\textit{file descriptor set} e la dimensione dei dati passati al kernel
dipende solo dal numero dei file descriptor che si vogliono controllare, non
dal loro valore.\footnote{anche se usando dei bit un \textit{file descriptor
- set} può essere più efficiente di un vettore di strutture \struct{pollfd},
+ set} può essere più efficiente di un vettore di strutture \struct{pollfd},
qualora si debba osservare un solo file descriptor con un valore molto alto
- ci si troverà ad utilizzare inutilmente un maggiore quantitativo di
+ ci si troverà ad utilizzare inutilmente un maggiore quantitativo di
memoria.}
Inoltre con \func{select} lo stesso \itindex{file~descriptor~set} \textit{file
- descriptor set} è usato sia in ingresso che in uscita, e questo significa
+ descriptor set} è usato sia in ingresso che in uscita, e questo significa
che tutte le volte che si vuole ripetere l'operazione occorre reinizializzarlo
-da capo. Questa operazione, che può essere molto onerosa se i file descriptor
-da tenere sotto osservazione sono molti, non è invece necessaria con
+da capo. Questa operazione, che può essere molto onerosa se i file descriptor
+da tenere sotto osservazione sono molti, non è invece necessaria con
\func{poll}.
Abbiamo visto in sez.~\ref{sec:file_select} come lo standard POSIX preveda una
variante di \func{select} che consente di gestire correttamente la ricezione
dei segnali nell'attesa su un file descriptor. Con l'introduzione di una
-implementazione reale di \func{pselect} nel kernel 2.6.16, è stata aggiunta
+implementazione reale di \func{pselect} nel kernel 2.6.16, è stata aggiunta
anche una analoga funzione che svolga lo stesso ruolo per \func{poll}.
-In questo caso si tratta di una estensione che è specifica di Linux e non è
-prevista da nessuno standard; essa può essere utilizzata esclusivamente se si
+In questo caso si tratta di una estensione che è specifica di Linux e non è
+prevista da nessuno standard; essa può essere utilizzata esclusivamente se si
definisce la macro \macro{\_GNU\_SOURCE} ed ovviamente non deve essere usata
-se si ha a cuore la portabilità. La funzione è \funcd{ppoll}, ed il suo
-prototipo è:
+se si ha a cuore la portabilità. La funzione è \funcd{ppoll}, ed il suo
+prototipo è:
\begin{prototype}{sys/poll.h}
{int ppoll(struct pollfd *fds, nfds\_t nfds, const struct timespec *timeout,
const sigset\_t *sigmask)}
La funzione attende un cambiamento di stato su un insieme di file
descriptor.
- \bodydesc{La funzione restituisce il numero di file descriptor con attività
- in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
- ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
+ \bodydesc{La funzione restituisce il numero di file descriptor con attività
+ in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
+ ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
+ \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato in uno
degli insiemi.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
\macro{RLIMIT\_NOFILE}.
\end{errlist}
ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
\end{prototype}
-La funzione ha lo stesso comportamento di \func{poll}, solo che si può
+La funzione ha lo stesso comportamento di \func{poll}, solo che si può
specificare, con l'argomento \param{sigmask}, il puntatore ad una maschera di
-segnali; questa sarà la maschera utilizzata per tutto il tempo che la funzione
-resterà in attesa, all'uscita viene ripristinata la maschera originale. L'uso
-di questa funzione è cioè equivalente, come illustrato nella pagina di
+segnali; questa sarà la maschera utilizzata per tutto il tempo che la funzione
+resterà in attesa, all'uscita viene ripristinata la maschera originale. L'uso
+di questa funzione è cioè equivalente, come illustrato nella pagina di
manuale, all'esecuzione atomica del seguente codice:
\includecodesnip{listati/ppoll_means.c}
\itindbeg{epoll}
Nonostante \func{poll} presenti alcuni vantaggi rispetto a \func{select},
-anche questa funzione non è molto efficiente quando deve essere utilizzata con
+anche questa funzione non è molto efficiente quando deve essere utilizzata con
un gran numero di file descriptor,\footnote{in casi del genere \func{select}
- viene scartata a priori, perché può avvenire che il numero di file
+ viene scartata a priori, perché può avvenire che il numero di file
descriptor ecceda le dimensioni massime di un \itindex{file~descriptor~set}
\textit{file descriptor set}.} in particolare nel caso in cui solo pochi di
-questi diventano attivi. Il problema in questo caso è che il tempo impiegato
-da \func{poll} a trasferire i dati da e verso il kernel è proporzionale al
-numero di file descriptor osservati, non a quelli che presentano attività.
+questi diventano attivi. Il problema in questo caso è che il tempo impiegato
+da \func{poll} a trasferire i dati da e verso il kernel è proporzionale al
+numero di file descriptor osservati, non a quelli che presentano attività.
Quando ci sono decine di migliaia di file descriptor osservati e migliaia di
-eventi al secondo,\footnote{il caso classico è quello di un server web di un
- sito con molti accessi.} l'uso di \func{poll} comporta la necessità di
+eventi al secondo,\footnote{il caso classico è quello di un server web di un
+ sito con molti accessi.} l'uso di \func{poll} comporta la necessità di
trasferire avanti ed indietro da user space a kernel space la lunga lista
delle strutture \struct{pollfd} migliaia di volte al secondo. A questo poi si
-aggiunge il fatto che la maggior parte del tempo di esecuzione sarà impegnato
+aggiunge il fatto che la maggior parte del tempo di esecuzione sarà impegnato
ad eseguire una scansione su tutti i file descriptor tenuti sotto controllo
per determinare quali di essi (in genere una piccola percentuale) sono
diventati attivi. In una situazione come questa l'uso delle funzioni classiche
Per risolvere questo tipo di situazioni sono state ideate delle interfacce
specialistiche\footnote{come \texttt{/dev/poll} in Solaris, o \texttt{kqueue}
- in BSD.} il cui scopo fondamentale è quello di restituire solamente le
+ in BSD.} il cui scopo fondamentale è quello di restituire solamente le
informazioni relative ai file descriptor osservati che presentano una
-attività, evitando così le problematiche appena illustrate. In genere queste
+attività, evitando così le problematiche appena illustrate. In genere queste
prevedono che si registrino una sola volta i file descriptor da tenere sotto
osservazione, e forniscono un meccanismo che notifica quali di questi
-presentano attività.
+presentano attività.
-Le modalità con cui avviene la notifica sono due, la prima è quella classica
+Le modalità con cui avviene la notifica sono due, la prima è quella classica
(quella usata da \func{poll} e \func{select}) che viene chiamata \textit{level
- triggered}.\footnote{la nomenclatura è stata introdotta da Jonathan Lemon in
+ triggered}.\footnote{la nomenclatura è stata introdotta da Jonathan Lemon in
un articolo su \texttt{kqueue} al BSDCON 2000, e deriva da quella usata
- nell'elettronica digitale.} In questa modalità vengono notificati i file
+ nell'elettronica digitale.} In questa modalità vengono notificati i file
descriptor che sono \textsl{pronti} per l'operazione richiesta, e questo
avviene indipendentemente dalle operazioni che possono essere state fatte su
di essi a partire dalla precedente notifica. Per chiarire meglio il concetto
ricorriamo ad un esempio: se su un file descriptor sono diventati disponibili
-in lettura 2000 byte ma dopo la notifica ne sono letti solo 1000 (ed è quindi
-possibile eseguire una ulteriore lettura dei restanti 1000), in modalità
-\textit{level triggered} questo sarà nuovamente notificato come
+in lettura 2000 byte ma dopo la notifica ne sono letti solo 1000 (ed è quindi
+possibile eseguire una ulteriore lettura dei restanti 1000), in modalità
+\textit{level triggered} questo sarà nuovamente notificato come
\textsl{pronto}.
-La seconda modalità, è detta \textit{edge triggered}, e prevede che invece
+La seconda modalità, è detta \textit{edge triggered}, e prevede che invece
vengano notificati solo i file descriptor che hanno subito una transizione da
-\textsl{non pronti} a \textsl{pronti}. Questo significa che in modalità
+\textsl{non pronti} a \textsl{pronti}. Questo significa che in modalità
\textit{edge triggered} nel caso del precedente esempio il file descriptor
-diventato pronto da cui si sono letti solo 1000 byte non verrà nuovamente
+diventato pronto da cui si sono letti solo 1000 byte non verrà nuovamente
notificato come pronto, nonostante siano ancora disponibili in lettura 1000
byte. Solo una volta che si saranno esauriti tutti i dati disponibili, e che
-il file descriptor sia tornato non essere pronto, si potrà ricevere una
+il file descriptor sia tornato non essere pronto, si potrà ricevere una
ulteriore notifica qualora ritornasse pronto.
Nel caso di Linux al momento la sola interfaccia che fornisce questo tipo di
-servizio è \textit{epoll},\footnote{l'interfaccia è stata creata da Davide
- Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44, ma la
- sua forma definitiva è stata raggiunta nel kernel 2.5.66.} anche se sono in
+servizio è \textit{epoll},\footnote{l'interfaccia è stata creata da Davide
+ Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44, ma la
+ sua forma definitiva è stata raggiunta nel kernel 2.5.66.} anche se sono in
discussione altre interfacce con le quali si potranno effettuare lo stesso
tipo di operazioni;\footnote{al momento della stesura di queste note (Giugno
- 2007) un'altra interfaccia proposta è quella di \textit{kevent}, che
+ 2007) un'altra interfaccia proposta è quella di \textit{kevent}, che
fornisce un sistema di notifica di eventi generico in grado di fornire le
- stesse funzionalità di \textit{epoll}, esiste però una forte discussione
- intorno a tutto ciò e niente di definito.} \textit{epoll} è in grado di
-operare sia in modalità \textit{level triggered} che \textit{edge triggered}.
+ stesse funzionalità di \textit{epoll}, esiste però una forte discussione
+ intorno a tutto ciò e niente di definito.} \textit{epoll} è in grado di
+operare sia in modalità \textit{level triggered} che \textit{edge triggered}.
La prima versione \textit{epoll} prevedeva l'apertura di uno speciale file di
dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
utilizzare con le funzioni dell'interfaccia,\footnote{il backporting
dell'interfaccia per il kernel 2.4, non ufficiale, utilizza sempre questo
- file.} ma poi si è passati all'uso di apposite \textit{system call}. Il
-primo passo per usare l'interfaccia di \textit{epoll} è pertanto quello
+ file.} ma poi si è passati all'uso di apposite \textit{system call}. Il
+primo passo per usare l'interfaccia di \textit{epoll} è pertanto quello
ottenere detto file descriptor chiamando una delle funzioni
\funcd{epoll\_create} e \funcd{epoll\_create1},\footnote{l'interfaccia di
- \textit{epoll} è stata inserita nel kernel a partire dalla versione 2.5.44,
- ed il supporto è stato aggiunto alle \acr{glibc} 2.3.2.} i cui prototipi
+ \textit{epoll} è stata inserita nel kernel a partire dalla versione 2.5.44,
+ ed il supporto è stato aggiunto alle \acr{glibc} 2.3.2.} i cui prototipi
sono:
\begin{functions}
\headdecl{sys/epoll.h}
\bodydesc{Le funzioni restituiscono un file descriptor per \textit{epoll} in
caso di successo, o $-1$ in caso di errore, nel qual caso \var{errno}
- assumerà uno dei valori:
+ assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un valore di \param{size} non
+ \item[\errcode{EINVAL}] si è specificato un valore di \param{size} non
positivo o non valido per \param{flags}.
- \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
+ \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
nel sistema.
- \item[\errcode{EMFILE}] si è raggiunto il limite sul numero massimo di
+ \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}.
- \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
l'istanza.
\end{errlist}
}
\end{functions}
Entrambe le funzioni restituiscono un file descriptor speciale,\footnote{esso
- non è associato a nessun file su disco, inoltre a differenza dei normali
- file descriptor non può essere inviato ad un altro processo attraverso un
+ non è associato a nessun file su disco, inoltre a differenza dei normali
+ file descriptor non può essere inviato ad un altro processo attraverso un
socket locale (vedi sez.~\ref{sec:sock_fd_passing}).} detto anche
\textit{epoll descriptor}, che viene associato alla infrastruttura utilizzata
dal kernel per gestire la notifica degli eventi. Nel caso di
numero di file descriptor che si vorranno tenere sotto controllo, e costituiva
solo un suggerimento per semplificare l'allocazione di risorse sufficienti,
non un valore massimo.\footnote{ma a partire dal kernel 2.6.8 esso viene
- totalmente ignorato e l'allocazione è sempre dinamica.}
+ totalmente ignorato e l'allocazione è sempre dinamica.}
-La seconda versione della funzione, \func{epoll\_create1} è stata
-introdotta\footnote{è disponibile solo a partire dal kernel 2.6.27.} come
+La seconda versione della funzione, \func{epoll\_create1} è stata
+introdotta\footnote{è disponibile solo a partire dal kernel 2.6.27.} come
estensione della precedente, per poter passare dei flag di controllo come
maschera binaria in fase di creazione del file descriptor. Al momento l'unico
-valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC},
+valore legale per \param{flags} (a parte lo zero) è \const{EPOLL\_CLOEXEC},
che consente di impostare in maniera atomica sul file descriptor il flag di
\itindex{close-on-exec} \textit{close-on-exec} (si veda il significato di
\const{O\_CLOEXEC} in tab.~\ref{tab:file_open_flags}), senza che sia
necessaria una successiva chiamata a \func{fcntl}.
-Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
+Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
indicare quali file descriptor mettere sotto osservazione e quali operazioni
controllare, per questo si deve usare la seconda funzione dell'interfaccia,
-\funcd{epoll\_ctl}, il cui prototipo è:
+\funcd{epoll\_ctl}, il cui prototipo è:
\begin{prototype}{sys/epoll.h}
{int epoll\_ctl(int epfd, int op, int fd, struct epoll\_event *event)}
Esegue le operazioni di controllo di \textit{epoll}.
\bodydesc{La funzione restituisce $0$ in caso di successo o $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}] il file descriptor \param{epfd} o \param{fd} non sono
validi.
- \item[\errcode{EEXIST}] l'operazione richiesta è \const{EPOLL\_CTL\_ADD} ma
- \param{fd} è già stato inserito in \param{epfd}.
- \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
- con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
- l'operazione richiesta con \param{op} non è supportata.
- \item[\errcode{ENOENT}] l'operazione richiesta è \const{EPOLL\_CTL\_MOD} o
- \const{EPOLL\_CTL\_DEL} ma \param{fd} non è inserito in \param{epfd}.
- \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel gestire
+ \item[\errcode{EEXIST}] l'operazione richiesta è \const{EPOLL\_CTL\_ADD} ma
+ \param{fd} è già stato inserito in \param{epfd}.
+ \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
+ con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
+ l'operazione richiesta con \param{op} non è supportata.
+ \item[\errcode{ENOENT}] l'operazione richiesta è \const{EPOLL\_CTL\_MOD} o
+ \const{EPOLL\_CTL\_DEL} ma \param{fd} non è inserito in \param{epfd}.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel gestire
l'operazione richiesta.
\item[\errcode{EPERM}] il file \param{fd} non supporta \textit{epoll}.
- \item[\errcode{ENOSPC}] si è raggiunto il limite massimo di registrazioni
+ \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}.
\end{errlist}
\param{fd} alla lista dei file descriptor
controllati tramite \param{epfd}, in
\param{event} devono essere specificate le
- modalità di osservazione.\\
- \const{EPOLL\_CTL\_MOD}& Modifica le modalità di osservazione del file
+ modalità di osservazione.\\
+ \const{EPOLL\_CTL\_MOD}& Modifica le modalità di osservazione del file
descriptor \param{fd} secondo il contenuto di
\param{event}.\\
\const{EPOLL\_CTL\_DEL}& Rimuove il file descriptor \param{fd} dalla lista
La funzione prende sempre come primo argomento un file descriptor di
\textit{epoll}, \param{epfd}, che deve essere stato ottenuto in precedenza con
una chiamata a \func{epoll\_create}. L'argomento \param{fd} indica invece il
-file descriptor che si vuole tenere sotto controllo, quest'ultimo può essere
+file descriptor che si vuole tenere sotto controllo, quest'ultimo può essere
un qualunque file descriptor utilizzabile con \func{poll}, ed anche un altro
file descriptor di \textit{epoll}, ma non lo stesso \param{epfd}.
sotto controllo. L'argomento viene ignorato con l'operazione
\const{EPOLL\_CTL\_DEL}.\footnote{fino al kernel 2.6.9 era comunque richiesto
che questo fosse un puntatore valido, anche se poi veniva ignorato; a
- partire dal 2.6.9 si può specificare anche un valore \texttt{NULL} ma se si
- vuole mantenere la compatibilità con le versioni precedenti occorre usare un
+ partire dal 2.6.9 si può specificare anche un valore \texttt{NULL} ma se si
+ vuole mantenere la compatibilità con le versioni precedenti occorre usare un
puntatore valido.}
\begin{figure}[!htb]
\label{fig:epoll_event}
\end{figure}
-La struttura \struct{epoll\_event} è l'analoga di \struct{pollfd} e come
+La struttura \struct{epoll\_event} è l'analoga di \struct{pollfd} e come
quest'ultima serve sia in ingresso (quando usata con \func{epoll\_ctl}) ad
impostare quali eventi osservare, che in uscita (nei risultati ottenuti con
\func{epoll\_wait}) per ricevere le notifiche degli eventi avvenuti. La sua
-definizione è riportata in fig.~\ref{fig:epoll_event}.
+definizione è riportata in fig.~\ref{fig:epoll_event}.
-Il primo campo, \var{events}, è una maschera binaria in cui ciascun bit
-corrisponde o ad un tipo di evento, o una modalità di notifica; detto campo
+Il primo campo, \var{events}, è una maschera binaria in cui ciascun bit
+corrisponde o ad un tipo di evento, o una modalità di notifica; detto campo
deve essere specificato come OR aritmetico delle costanti riportate in
-tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, è una \ctyp{union}
+tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, è una \ctyp{union}
che serve a identificare il file descriptor a cui si intende fare riferimento,
-ed in astratto può contenere un valore qualsiasi (specificabile in diverse
-forme) che ne permetta una indicazione univoca. Il modo più comune di usarlo
-però è quello in cui si specifica il terzo argomento di \func{epoll\_ctl}
+ed in astratto può contenere un valore qualsiasi (specificabile in diverse
+forme) che ne permetta una indicazione univoca. Il modo più comune di usarlo
+però è quello in cui si specifica il terzo argomento di \func{epoll\_ctl}
nella forma \var{event.data.fd}, assegnando come valore di questo campo lo
stesso valore dell'argomento \param{fd}, cosa che permette una immediata
identificazione del file descriptor.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{EPOLLIN} & Il file è pronto per le operazioni di lettura
+ \const{EPOLLIN} & Il file è pronto per le operazioni di lettura
(analogo di \const{POLLIN}).\\
- \const{EPOLLOUT} & Il file è pronto per le operazioni di scrittura
+ \const{EPOLLOUT} & Il file è pronto per le operazioni di scrittura
(analogo di \const{POLLOUT}).\\
\const{EPOLLRDHUP} & L'altro capo di un socket di tipo
\const{SOCK\_STREAM} (vedi sez.~\ref{sec:sock_type})
\const{EPOLLPRI} & Ci sono \itindex{out-of-band} dati urgenti
disponibili in lettura (analogo di
\const{POLLPRI}); questa condizione viene comunque
- riportata in uscita, e non è necessaria impostarla
+ riportata in uscita, e non è necessaria impostarla
in ingresso.\\
- \const{EPOLLERR} & Si è verificata una condizione di errore
+ \const{EPOLLERR} & Si è verificata una condizione di errore
(analogo di \const{POLLERR}); questa condizione
- viene comunque riportata in uscita, e non è
+ viene comunque riportata in uscita, e non è
necessaria impostarla in ingresso.\\
- \const{EPOLLHUP} & Si è verificata una condizione di hung-up; questa
+ \const{EPOLLHUP} & Si è verificata una condizione di hung-up; questa
condizione viene comunque riportata in uscita, e non
- è necessaria impostarla in ingresso.\\
- \const{EPOLLET} & Imposta la notifica in modalità \textit{edge
+ è necessaria impostarla in ingresso.\\
+ \const{EPOLLET} & Imposta la notifica in modalità \textit{edge
triggered} per il file descriptor associato.\\
- \const{EPOLLONESHOT}& Imposta la modalità \textit{one-shot} per il file
+ \const{EPOLLONESHOT}& Imposta la modalità \textit{one-shot} per il file
descriptor associato.\footnotemark\\
\hline
\end{tabular}
\label{tab:epoll_events}
\end{table}
-\footnotetext{questa modalità è disponibile solo a partire dal kernel 2.6.17,
- ed è utile per riconoscere la chiusura di una connessione dall'altro capo
- quando si lavora in modalità \textit{edge triggered}.}
+\footnotetext{questa modalità è disponibile solo a partire dal kernel 2.6.17,
+ ed è utile per riconoscere la chiusura di una connessione dall'altro capo
+ quando si lavora in modalità \textit{edge triggered}.}
-\footnotetext[48]{questa modalità è disponibile solo a partire dal kernel
+\footnotetext[48]{questa modalità è disponibile solo a partire dal kernel
2.6.2.}
-Le modalità di utilizzo di \textit{epoll} prevedono che si definisca qual'è
+Le modalità di utilizzo di \textit{epoll} prevedono che si definisca qual'è
l'insieme dei file descriptor da tenere sotto controllo tramite un certo
\textit{epoll descriptor} \param{epfd} attraverso una serie di chiamate a
-\const{EPOLL\_CTL\_ADD}.\footnote{un difetto dell'interfaccia è che queste
+\const{EPOLL\_CTL\_ADD}.\footnote{un difetto dell'interfaccia è che queste
chiamate devono essere ripetute per ciascun file descriptor, incorrendo in
una perdita di prestazioni qualora il numero di file descriptor sia molto
- grande; per questo è stato proposto di introdurre come estensione una
+ grande; per questo è stato proposto di introdurre come estensione una
funzione \func{epoll\_ctlv} che consenta di effettuare con una sola chiamata
le impostazioni per un blocco di file descriptor.} L'uso di
-\const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di
-osservazione di un file descriptor che sia già stato aggiunto alla lista di
+\const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di
+osservazione di un file descriptor che sia già stato aggiunto alla lista di
osservazione.
Le impostazioni di default prevedono che la notifica degli eventi richiesti
-sia effettuata in modalità \textit{level triggered}, a meno che sul file
-descriptor non si sia impostata la modalità \textit{edge triggered},
+sia effettuata in modalità \textit{level triggered}, a meno che sul file
+descriptor non si sia impostata la modalità \textit{edge triggered},
registrandolo con \const{EPOLLET} attivo nel campo \var{events}. Si tenga
-presente che è possibile tenere sotto osservazione uno stesso file descriptor
+presente che è possibile tenere sotto osservazione uno stesso file descriptor
su due \textit{epoll descriptor} diversi, ed entrambi riceveranno le
-notifiche, anche se questa pratica è sconsigliata.
+notifiche, anche se questa pratica è sconsigliata.
-Qualora non si abbia più interesse nell'osservazione di un file descriptor lo
-si può rimuovere dalla lista associata a \param{epfd} con
+Qualora non si abbia più interesse nell'osservazione di un file descriptor lo
+si può rimuovere dalla lista associata a \param{epfd} con
\const{EPOLL\_CTL\_DEL}; si tenga conto inoltre che i file descriptor sotto
osservazione che vengono chiusi sono eliminati dalla lista automaticamente e
-non è necessario usare \const{EPOLL\_CTL\_DEL}.
+non è necessario usare \const{EPOLL\_CTL\_DEL}.
-Infine una particolare modalità di notifica è quella impostata con
+Infine una particolare modalità di notifica è quella impostata con
\const{EPOLLONESHOT}: a causa dell'implementazione di \textit{epoll} infatti
-quando si è in modalità \textit{edge triggered} l'arrivo in rapida successione
-di dati in blocchi separati\footnote{questo è tipico con i socket di rete, in
- quanto i dati arrivano a pacchetti.} può causare una generazione di eventi
+quando si è in modalità \textit{edge triggered} l'arrivo in rapida successione
+di dati in blocchi separati\footnote{questo è tipico con i socket di rete, in
+ quanto i dati arrivano a pacchetti.} può causare una generazione di eventi
(ad esempio segnalazioni di dati in lettura disponibili) anche se la
-condizione è già stata rilevata.\footnote{si avrebbe cioè una rottura della
+condizione è già stata rilevata.\footnote{si avrebbe cioè una rottura della
logica \textit{edge triggered}.}
-Anche se la situazione è facile da gestire, la si può evitare utilizzando
-\const{EPOLLONESHOT} per impostare la modalità \textit{one-shot}, in cui la
+Anche se la situazione è facile da gestire, la si può evitare utilizzando
+\const{EPOLLONESHOT} per impostare la modalità \textit{one-shot}, in cui la
notifica di un evento viene effettuata una sola volta, dopo di che il file
descriptor osservato, pur restando nella lista di osservazione, viene
automaticamente disattivato,\footnote{la cosa avviene contestualmente al
ritorno di \func{epoll\_wait} a causa dell'evento in questione.} e per
-essere riutilizzato dovrà essere riabilitato esplicitamente con una successiva
+essere riutilizzato dovrà essere riabilitato esplicitamente con una successiva
chiamata con \const{EPOLL\_CTL\_MOD}.
Una volta impostato l'insieme di file descriptor che si vogliono osservare con
i relativi eventi, la funzione che consente di attendere l'occorrenza di uno
-di tali eventi è \funcd{epoll\_wait}, il cui prototipo è:
+di tali eventi è \funcd{epoll\_wait}, il cui prototipo è:
\begin{prototype}{sys/epoll.h}
{int epoll\_wait(int epfd, struct epoll\_event * events, int maxevents, int
timeout)}
\bodydesc{La funzione restituisce il numero di file descriptor pronti in
caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
- assumerà uno dei valori:
+ assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] il file descriptor \param{epfd} non è valido.
- \item[\errcode{EFAULT}] il puntatore \param{events} non è valido.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
+ \item[\errcode{EBADF}] il file descriptor \param{epfd} non è valido.
+ \item[\errcode{EFAULT}] il puntatore \param{events} non è valido.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
della scadenza di \param{timeout}.
- \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
- con \func{epoll\_create}, o \param{maxevents} non è maggiore di zero.
+ \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
+ con \func{epoll\_create}, o \param{maxevents} non è maggiore di zero.
\end{errlist}
}
\end{prototype}
La funzione ritorna il numero di eventi rilevati, o un valore nullo qualora
sia scaduto il tempo massimo impostato con \param{timeout}. Per quest'ultimo,
-oltre ad un numero di millisecondi, si può utilizzare il valore nullo, che
+oltre ad un numero di millisecondi, si può utilizzare il valore nullo, che
indica di non attendere e ritornare immediatamente,\footnote{anche in questo
- caso il valore di ritorno sarà nullo.} o il valore $-1$, che indica
-un'attesa indefinita. L'argomento \param{maxevents} dovrà invece essere sempre
+ caso il valore di ritorno sarà nullo.} o il valore $-1$, che indica
+un'attesa indefinita. L'argomento \param{maxevents} dovrà invece essere sempre
un intero positivo.
Come accennato la funzione restituisce i suoi risultati nel vettore di
strutture \struct{epoll\_event} puntato da \param{events}; in tal caso nel
campo \param{events} di ciascuna di esse saranno attivi i flag relativi agli
-eventi accaduti, mentre nel campo \var{data} sarà restituito il valore che era
-stato impostato per il file descriptor per cui si è verificato l'evento quando
+eventi accaduti, mentre nel campo \var{data} sarà restituito il valore che era
+stato impostato per il file descriptor per cui si è verificato l'evento quando
questo era stato registrato con le operazioni \const{EPOLL\_CTL\_MOD} o
\const{EPOLL\_CTL\_ADD}, in questo modo il campo \var{data} consente di
-identificare il file descriptor.\footnote{ed è per questo che, come accennato,
- è consuetudine usare per \var{data} il valore del file descriptor stesso.}
+identificare il file descriptor.\footnote{ed è per questo che, come accennato,
+ è consuetudine usare per \var{data} il valore del file descriptor stesso.}
Si ricordi che le occasioni per cui \func{epoll\_wait} ritorna dipendono da
-come si è impostata la modalità di osservazione (se \textit{level triggered} o
+come si è impostata la modalità di osservazione (se \textit{level triggered} o
\textit{edge triggered}) del singolo file descriptor. L'interfaccia assicura
-che se arrivano più eventi fra due chiamate successive ad \func{epoll\_wait}
+che se arrivano più eventi fra due chiamate successive ad \func{epoll\_wait}
questi vengano combinati. Inoltre qualora su un file descriptor fossero
presenti eventi non ancora notificati, e si effettuasse una modifica
dell'osservazione con \const{EPOLL\_CTL\_MOD}, questi verrebbero riletti alla
luce delle modifiche.
-Si tenga presente infine che con l'uso della modalità \textit{edge triggered}
-il ritorno di \func{epoll\_wait} indica che un file descriptor è pronto e
-resterà tale fintanto che non si sono completamente esaurite le operazioni su
+Si tenga presente infine che con l'uso della modalità \textit{edge triggered}
+il ritorno di \func{epoll\_wait} indica che un file descriptor è pronto e
+resterà tale fintanto che non si sono completamente esaurite le operazioni su
di esso. Questa condizione viene generalmente rilevata dall'occorrere di un
errore di \errcode{EAGAIN} al ritorno di una \func{read} o una
-\func{write},\footnote{è opportuno ricordare ancora una volta che l'uso
- dell'\textit{I/O multiplexing} richiede di operare sui file in modalità non
- bloccante.} ma questa non è la sola modalità possibile, ad esempio la
-condizione può essere riconosciuta anche per il fatto che sono stati
+\func{write},\footnote{è opportuno ricordare ancora una volta che l'uso
+ dell'\textit{I/O multiplexing} richiede di operare sui file in modalità non
+ bloccante.} ma questa non è la sola modalità possibile, ad esempio la
+condizione può essere riconosciuta anche per il fatto che sono stati
restituiti meno dati di quelli richiesti.
-Come già per \func{select} e \func{poll} anche per l'interfaccia di
+Come già per \func{select} e \func{poll} anche per l'interfaccia di
\textit{epoll} si pone il problema di gestire l'attesa di segnali e di dati
contemporaneamente per le osservazioni fatte in sez.~\ref{sec:file_select},
-per fare questo di nuovo è necessaria una variante della funzione di attesa
+per fare questo di nuovo è necessaria una variante della funzione di attesa
che consenta di reimpostare all'uscita una maschera di segnali, analoga alle
estensioni \func{pselect} e \func{ppoll} che abbiamo visto in precedenza per
\func{select} e \func{poll}; in questo caso la funzione si chiama
-\funcd{epoll\_pwait}\footnote{la funziona è stata introdotta a partire dal
- kernel 2.6.19, ed è come tutta l'interfaccia di \textit{epoll}, specifica di
- Linux.} ed il suo prototipo è:
+\funcd{epoll\_pwait}\footnote{la funziona è stata introdotta a partire dal
+ kernel 2.6.19, ed è come tutta l'interfaccia di \textit{epoll}, specifica di
+ Linux.} ed il suo prototipo è:
\begin{prototype}{sys/epoll.h}
{int epoll\_pwait(int epfd, struct epoll\_event * events, int maxevents,
int timeout, const sigset\_t *sigmask)}
\bodydesc{La funzione restituisce il numero di file descriptor pronti in
caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
- assumerà uno dei valori già visti con \funcd{epoll\_wait}.
+ assumerà uno dei valori già visti con \funcd{epoll\_wait}.
}
\end{prototype}
-La funzione è del tutto analoga \funcd{epoll\_wait}, soltanto che alla sua
+La funzione è del tutto analoga \funcd{epoll\_wait}, soltanto che alla sua
uscita viene ripristinata la maschera di segnali originale, sostituita durante
l'esecuzione da quella impostata con l'argomento \param{sigmask}; in sostanza
-la chiamata a questa funzione è equivalente al seguente codice, eseguito però
+la chiamata a questa funzione è equivalente al seguente codice, eseguito però
in maniera atomica:
\includecodesnip{listati/epoll_pwait_means.c}
prevalentemente con i server di rete, quando si devono tenere sotto
osservazione un gran numero di socket; per questo motivo rimandiamo anche in
questo caso la trattazione di un esempio concreto a quando avremo esaminato in
-dettaglio le caratteristiche dei socket; in particolare si potrà trovare un
+dettaglio le caratteristiche dei socket; in particolare si potrà trovare un
programma che utilizza questa interfaccia in sez.~\ref{sec:TCP_serv_epoll}.
\itindend{epoll}
estensioni dello standard POSIX e funzioni apposite come \func{pselect},
\func{ppoll} e \funcd{epoll\_pwait}.
-Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
+Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
processi, la loro interfaccia di programmazione, che comporta l'esecuzione di
una funzione di gestione in maniera asincrona e totalmente scorrelata
-dall'ordinario flusso di esecuzione del processo, si è però dimostrata quasi
-subito assai problematica. Oltre ai limiti relativi ai limiti al cosa si può
+dall'ordinario flusso di esecuzione del processo, si è però dimostrata quasi
+subito assai problematica. Oltre ai limiti relativi ai limiti al cosa si può
fare all'interno della funzione del gestore di segnali (quelli illustrati in
-sez.~\ref{sec:sig_signal_handler}), c'è il problema più generale consistente
-nel fatto che questa modalità di funzionamento cozza con altre interfacce di
+sez.~\ref{sec:sig_signal_handler}), c'è il problema più generale consistente
+nel fatto che questa modalità di funzionamento cozza con altre interfacce di
programmazione previste dal sistema in cui si opera in maniera
\textsl{sincrona}, come quelle dell'I/O multiplexing appena illustrate.
In questo tipo di interfacce infatti ci si aspetta che il processo gestisca
gli eventi a cui vuole rispondere in maniera sincrona generando le opportune
risposte, mentre con l'arrivo di un segnale si possono avere interruzioni
-asincrone in qualunque momento. Questo comporta la necessità di dover
+asincrone in qualunque momento. Questo comporta la necessità di dover
gestire, quando si deve tener conto di entrambi i tipi di eventi, le
interruzioni delle funzioni di attesa sincrone, ed evitare possibili
\itindex{race~condition} \textit{race conditions}.\footnote{in sostanza se non
fossero per i segnali non ci sarebbe da doversi preoccupare, fintanto che si
- effettuano operazioni all'interno di un processo, della non atomicità delle
+ effettuano operazioni all'interno di un processo, della non atomicità delle
\index{system~call~lente} system call lente che vengono interrotte e devono
essere riavviate.}
-Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
+Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
\textit{real-time} sono state introdotte anche delle interfacce di gestione
sincrona dei segnali con la funzione \func{sigwait} e le sue affini. Queste
funzioni consentono di gestire i segnali bloccando un processo fino alla
avvenuta ricezione e disabilitando l'esecuzione asincrona rispetto al resto
del programma del gestore del segnale. Questo consente di risolvere i problemi
-di atomicità nella gestione degli eventi associati ai segnali, avendo tutto il
-controllo nel flusso principale del programma, ottenendo così una gestione
+di atomicità nella gestione degli eventi associati ai segnali, avendo tutto il
+controllo nel flusso principale del programma, ottenendo così una gestione
simile a quella dell'\textit{I/O multiplexing}, ma non risolve i problemi
-delle interazioni con quest'ultimo, perché o si aspetta la ricezione di un
+delle interazioni con quest'ultimo, perché o si aspetta la ricezione di un
segnale o si aspetta che un file descriptor sia accessibile e nessuna delle
rispettive funzioni consente di fare contemporaneamente entrambe le cose.
-Per risolvere questo problema nello sviluppo del kernel si è pensato di
+Per risolvere questo problema nello sviluppo del kernel si è pensato di
introdurre un meccanismo alternativo alla notifica dei segnali (esteso anche
ad altri eventi generici) che, ispirandosi di nuovo alla filosofia di Unix per
-cui tutto è un file, consentisse di eseguire la notifica con l'uso di
-opportuni file descriptor.\footnote{ovviamente si tratta di una funzionalità
+cui tutto è un file, consentisse di eseguire la notifica con l'uso di
+opportuni file descriptor.\footnote{ovviamente si tratta di una funzionalità
specifica di Linux, non presente in altri sistemi unix-like, e non prevista
- da nessuno standard, per cui va evitata se si ha a cuore la portabilità.}
+ da nessuno standard, per cui va evitata se si ha a cuore la portabilità.}
-In sostanza, come per \func{sigwait}, si può disabilitare l'esecuzione di un
+In sostanza, come per \func{sigwait}, si può disabilitare l'esecuzione di un
gestore in occasione dell'arrivo di un segnale, e rilevarne l'avvenuta
ricezione leggendone la notifica tramite l'uso di uno speciale file
-descriptor. Trattandosi di un file descriptor questo potrà essere tenuto sotto
+descriptor. Trattandosi di un file descriptor questo potrà essere tenuto sotto
osservazione con le ordinarie funzioni dell'\textit{I/O multiplexing} (vale a
dire con le solite \func{select}, \func{poll} e \funcd{epoll\_wait}) allo
-stesso modo di quelli associati a file o socket, per cui alla fine si potrà
-attendere in contemporanea sia l'arrivo del segnale che la disponibilità di
+stesso modo di quelli associati a file o socket, per cui alla fine si potrà
+attendere in contemporanea sia l'arrivo del segnale che la disponibilità di
accesso ai dati relativi a questi ultimi.
La funzione che permette di abilitare la ricezione dei segnali tramite file
-descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è
+descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è
l'interfaccia alla funzione fornita dalle \acr{glibc}, esistono infatti due
versioni diverse della \textit{system call}; una prima versione,
\func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
\acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
- versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
+ versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
maschera dei segnali, il cui valore viene impostato automaticamente dalle
- \acr{glibc}.} il cui prototipo è:
+ \acr{glibc}.} il cui prototipo è:
\begin{prototype}{sys/signalfd.h}
{int signalfd(int fd, const sigset\_t *mask, int flags)}
Crea o modifica un file descriptor per la ricezione dei segnali.
\bodydesc{La funzione restituisce un numero di file descriptor in caso di
- successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
\item[\errcode{EBADF}] il valore \param{fd} non indica un file descriptor.
- \item[\errcode{EINVAL}] il file descriptor \param{fd} non è stato ottenuto
- con \func{signalfd} o il valore di \param{flags} non è valido.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
+ \item[\errcode{EINVAL}] il file descriptor \param{fd} non è stato ottenuto
+ con \func{signalfd} o il valore di \param{flags} non è valido.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
descriptor di \func{signalfd}.
- \item[\errcode{ENODEV}] il kernel non può montare internamente il
+ \item[\errcode{ENODEV}] il kernel non può montare internamente il
dispositivo per la gestione anonima degli inode associati al file
descriptor.
\end{errlist}
La funzione consente di creare o modificare le caratteristiche di un file
descriptor speciale su cui ricevere le notifiche della ricezione di
-segnali. Per creare ex-novo uno di questi file descriptor è necessario passare
-$-1$ come valore per l'argomento \param{fd}, ogni altro valore positivo verrà
+segnali. Per creare ex-novo uno di questi file descriptor è necessario passare
+$-1$ come valore per l'argomento \param{fd}, ogni altro valore positivo verrà
invece interpretato come il numero del file descriptor (che deve esser stato
precedentemente creato sempre con \func{signalfd}) di cui si vogliono
-modificare le caratteristiche. Nel primo caso la funzione ritornerà il valore
+modificare le caratteristiche. Nel primo caso la funzione ritornerà il valore
del nuovo file descriptor e nel secondo caso il valore indicato
-con \param{fd}, in caso di errore invece verrà restituito $-1$.
+con \param{fd}, in caso di errore invece verrà restituito $-1$.
L'elenco dei segnali che si vogliono gestire con \func{signalfd} deve essere
specificato tramite l'argomento \param{mask}. Questo deve essere passato come
-puntatore ad una maschera di segnali creata con l'uso delle apposite macro già
+puntatore ad una maschera di segnali creata con l'uso delle apposite macro già
illustrate in sez.~\ref{sec:sig_sigset}. La maschera deve indicare su quali
-segnali si intende operare con \func{signalfd}; l'elenco può essere modificato
+segnali si intende operare con \func{signalfd}; l'elenco può essere modificato
con una successiva chiamata a \func{signalfd}. Dato che \const{SIGKILL} e
\const{SIGSTOP} non possono essere intercettati (e non prevedono neanche la
-possibilità di un gestore) un loro inserimento nella maschera verrà ignorato
+possibilità di un gestore) un loro inserimento nella maschera verrà ignorato
senza generare errori.
L'argomento \param{flags} consente di impostare direttamente in fase di
creazione due flag per il file descriptor analoghi a quelli che si possono
impostare con una creazione ordinaria con \func{open}, evitando una
-impostazione successiva con \func{fcntl}.\footnote{questo è un argomento
+impostazione successiva con \func{fcntl}.\footnote{questo è un argomento
aggiuntivo, introdotto con la versione fornita a partire dal kernel 2.6.27,
per kernel precedenti il valore deve essere nullo.} L'argomento deve essere
specificato come maschera binaria dei valori riportati in
Si tenga presente che la chiamata a \func{signalfd} non disabilita la gestione
ordinaria dei segnali indicati da \param{mask}; questa, se si vuole effettuare
-la ricezione tramite il file descriptor, dovrà essere disabilitata
+la ricezione tramite il file descriptor, dovrà essere disabilitata
esplicitamente bloccando gli stessi segnali con \func{sigprocmask}, altrimenti
verranno comunque eseguite le azioni di default (o un eventuale gestore
installato in precedenza).\footnote{il blocco non ha invece nessun effetto sul
- file descriptor restituito da \func{signalfd}, dal quale sarà possibile
+ file descriptor restituito da \func{signalfd}, dal quale sarà possibile
pertanto ricevere qualunque segnale, anche se questo risultasse bloccato.}
Si tenga presente inoltre che la lettura di una struttura
-\struct{signalfd\_siginfo} relativa ad un segnale pendente è equivalente alla
-esecuzione di un gestore, vale a dire che una volta letta il segnale non sarà
-più pendente e non potrà essere ricevuto, qualora si ripristino le normali
-condizioni di gestione, né da un gestore né dalla funzione \func{sigwaitinfo}.
+\struct{signalfd\_siginfo} relativa ad un segnale pendente è equivalente alla
+esecuzione di un gestore, vale a dire che una volta letta il segnale non sarà
+più pendente e non potrà essere ricevuto, qualora si ripristino le normali
+condizioni di gestione, né da un gestore né dalla funzione \func{sigwaitinfo}.
Come anticipato, essendo questo lo scopo principale della nuova interfaccia,
-il file descriptor può essere tenuto sotto osservazione tramite le funzioni
+il file descriptor può essere tenuto sotto osservazione tramite le funzioni
dell'\textit{I/O multiplexing} (vale a dire con le solite \func{select},
-\func{poll} e \funcd{epoll\_wait}), e risulterà accessibile in lettura quando
-uno o più dei segnali indicati tramite \param{mask} sarà pendente.
-
-La funzione può essere chiamata più volte dallo stesso processo, consentendo
-così di tenere sotto osservazione segnali diversi tramite file descriptor
-diversi. Inoltre è anche possibile tenere sotto osservazione lo stesso segnale
-con più file descriptor, anche se la pratica è sconsigliata; in tal caso la
-ricezione del segnale potrà essere effettuata con una lettura da uno qualunque
-dei file descriptor a cui è associato, ma questa potrà essere eseguita
+\func{poll} e \funcd{epoll\_wait}), e risulterà accessibile in lettura quando
+uno o più dei segnali indicati tramite \param{mask} sarà pendente.
+
+La funzione può essere chiamata più volte dallo stesso processo, consentendo
+così di tenere sotto osservazione segnali diversi tramite file descriptor
+diversi. Inoltre è anche possibile tenere sotto osservazione lo stesso segnale
+con più file descriptor, anche se la pratica è sconsigliata; in tal caso la
+ricezione del segnale potrà essere effettuata con una lettura da uno qualunque
+dei file descriptor a cui è associato, ma questa potrà essere eseguita
soltanto una volta.\footnote{questo significa che tutti i file descriptor su
- cui è presente lo stesso segnale risulteranno pronti in lettura per le
+ cui è presente lo stesso segnale risulteranno pronti in lettura per le
funzioni di \textit{I/O multiplexing}, ma una volta eseguita la lettura su
- uno di essi il segnale sarà considerato ricevuto ed i relativi dati non
- saranno più disponibili sugli altri file descriptor, che (a meno di una
- ulteriore occorrenza del segnale nel frattempo) di non saranno più pronti.}
+ uno di essi il segnale sarà considerato ricevuto ed i relativi dati non
+ saranno più disponibili sugli altri file descriptor, che (a meno di una
+ ulteriore occorrenza del segnale nel frattempo) di non saranno più pronti.}
-Quando il file descriptor per la ricezione dei segnali non serve più potrà
+Quando il file descriptor per la ricezione dei segnali non serve più potrà
essere chiuso con \func{close} liberando tutte le risorse da esso allocate. In
tal caso qualora vi fossero segnali pendenti questi resteranno tali, e
potranno essere ricevuti normalmente una volta che si rimuova il blocco
pendenti attraverso una \func{exec}.
Analogamente il file descriptor resta sempre disponibile attraverso una
-\func{fork} per il processo figlio, che ne riceve una copia; in tal caso però
-il figlio potrà leggere dallo stesso soltanto i dati relativi ai segnali
+\func{fork} per il processo figlio, che ne riceve una copia; in tal caso però
+il figlio potrà leggere dallo stesso soltanto i dati relativi ai segnali
ricevuti da lui stesso. Nel caso di \textit{thread} viene nuovamente seguita
la semantica ordinaria dei segnali, che prevede che un singolo \textit{thread}
possa ricevere dal file descriptor solo le notifiche di segnali inviati
L'interfaccia fornita da \func{signalfd} prevede che la ricezione dei segnali
sia eseguita leggendo i dati relativi ai segnali pendenti dal file descriptor
restituito dalla funzione con una normalissima \func{read}. Qualora non vi
-siano segnali pendenti la \func{read} si bloccherà a meno di non aver
-impostato la modalità di I/O non bloccante sul file descriptor, o direttamente
+siano segnali pendenti la \func{read} si bloccherà a meno di non aver
+impostato la modalità di I/O non bloccante sul file descriptor, o direttamente
in fase di creazione con il flag \const{SFD\_NONBLOCK}, o in un momento
successivo con \func{fcntl}.
\end{figure}
I dati letti dal file descriptor vengono scritti sul buffer indicato come
-secondo argomento di \func{read} nella forma di una sequenza di una o più
-strutture \struct{signalfd\_siginfo} (la cui definizione si è riportata in
+secondo argomento di \func{read} nella forma di una sequenza di una o più
+strutture \struct{signalfd\_siginfo} (la cui definizione si è riportata in
fig.~\ref{fig:signalfd_siginfo}) a seconda sia della dimensione del buffer che
del numero di segnali pendenti. Per questo motivo il buffer deve essere almeno
di dimensione pari a quella di \struct{signalfd\_siginfo}, qualora sia di
dimensione maggiore potranno essere letti in unica soluzione i dati relativi
-ad eventuali più segnali pendenti, fino al numero massimo di strutture
+ad eventuali più segnali pendenti, fino al numero massimo di strutture
\struct{signalfd\_siginfo} che possono rientrare nel buffer.
Il contenuto di \struct{signalfd\_siginfo} ricalca da vicino quella della
analoga struttura \struct{siginfo\_t} (illustrata in
fig.~\ref{fig:sig_siginfo_t}) usata dall'interfaccia ordinaria dei segnali, e
restituisce dati simili. Come per \struct{siginfo\_t} i campi che vengono
-avvalorati dipendono dal tipo di segnale e ricalcano i valori che abbiamo già
-illustrato in sez.~\ref{sec:sig_sigaction}.\footnote{si tenga presente però
+avvalorati dipendono dal tipo di segnale e ricalcano i valori che abbiamo già
+illustrato in sez.~\ref{sec:sig_sigaction}.\footnote{si tenga presente però
che per un bug i kernel fino al 2.6.25 non avvalorano correttamente i campi
\var{ssi\_ptr} e \var{ssi\_int} per segnali inviati con \func{sigqueue}.}
-Lo stesso paradigma di notifica tramite file descriptor usato per i segnali è
+Lo stesso paradigma di notifica tramite file descriptor usato per i segnali è
stato adottato anche per i timer; in questo caso, rispetto a quanto visto in
-sez.~\ref{sec:sig_timer_adv}, la scadenza di un timer potrà essere letta da un
+sez.~\ref{sec:sig_timer_adv}, la scadenza di un timer potrà essere letta da un
file descriptor, senza dover ricorrere ad altri meccanismi di notifica come un
segnale o un \textit{thread}. Di nuovo questo ha il vantaggio di poter
utilizzare le funzioni dell'\textit{I/O multiplexing} per attendere allo
-stesso tempo la disponibilità di dati o la ricezione di un segnale
-qualunque.\footnote{in realtà per questo sarebbe già sufficiente
- \func{signalfd} per ricevere i segnali associati ai timer, ma la nuova
- interfaccia semplifica notevolmente la gestione.}
+stesso tempo la disponibilità di dati o la ricezione scadenza di un
+timer.\footnote{in realtà per questo sarebbe già sufficiente \func{signalfd}
+ per ricevere i segnali associati ai timer, ma la nuova interfaccia
+ semplifica notevolmente la gestione e diminuisce l'\textit{overhead}.}
Le funzioni di questa interfaccia riprendono da vicino quelle introdotte da
POSIX.1-2001 illustrate sez.~\ref{sec:sig_timer_adv}. La prima funzione, che
-consente di creare un \textit{timer} è \funcd{timerfd\_create}, il cui
-prototipo è:
+consente di creare un \textit{timer} è \funcd{timerfd\_create}, il cui
+prototipo è:
\begin{prototype}{sys/timerfd.h}
{int timerfd\_create(int clockid, int flags)}
Crea un timer associato ad un file descriptor per la notifica.
\bodydesc{La funzione restituisce un numero di file descriptor in caso di
- successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] l'argomento \param{clockid} non è
+ \item[\errcode{EINVAL}] l'argomento \param{clockid} non è
\const{CLOCK\_MONOTONIC} o \const{CLOCK\_REALTIME}, o
- l'argomento \param{flag} non è valido o diverso da zero per kernel
+ l'argomento \param{flag} non è valido o diverso da zero per kernel
precedenti il 2.6.27.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
descriptor di \func{signalfd}.
- \item[\errcode{ENODEV}] il kernel non può montare internamente il
+ \item[\errcode{ENODEV}] il kernel non può montare internamente il
dispositivo per la gestione anonima degli inode associati al file
descriptor.
\end{errlist}
\end{prototype}
La funzione prende come primo argomento il tipo di orologio a cui il timer
-deve fare riferimento, ed i soli valori validi sono \const{CLOCK\_REALTIME},
-per indicare
+deve fare riferimento, il cui significato è già stato illustrato in
+tab.~\ref{tab:sig_timer_clockid_types}, ma i soli valori validi sono
+\const{CLOCK\_REALTIME} e \const{CLOCK\_MONOTONIC}.
% TODO trattare qui eventfd, timerfd introdotte con il 2.6.22
-% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
+% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
% vedi: http://lwn.net/Articles/233462/
% http://lwn.net/Articles/245533/
% http://lwn.net/Articles/267331/
\section{L'accesso \textsl{asincrono} ai file}
\label{sec:file_asyncronous_access}
-Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
-le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
-debba operare su più file contemporaneamente, esistono altre modalità di
+Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
+le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
+debba operare su più file contemporaneamente, esistono altre modalità di
gestione delle stesse problematiche. In particolare sono importanti in questo
-contesto le modalità di accesso ai file eseguibili in maniera
-\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
-attesa della disponibilità dell'accesso al file, ma può proseguire
+contesto le modalità di accesso ai file eseguibili in maniera
+\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
+attesa della disponibilità dell'accesso al file, ma può proseguire
nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
norma un segnale, ma esistono anche altre interfacce, come \itindex{inotify}
-\textit{inotify}), per essere avvisato della possibilità di eseguire le
+\textit{inotify}), per essere avvisato della possibilità di eseguire le
operazioni di I/O volute.
\itindbeg{signal~driven~I/O}
-Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
+Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso
l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e
- dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
- specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è
-possibile attivare in un secondo tempo questa modalità impostando questo flag
+ dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è
+ specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è
+possibile attivare in un secondo tempo questa modalità impostando questo flag
attraverso l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi
-sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità
+sez.~\ref{sec:file_fcntl}). In realtà parlare di apertura in modalità
asincrona non significa che le operazioni di lettura o scrittura del file
-vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più
+vengono eseguite in modo asincrono (tratteremo questo, che è ciò che più
propriamente viene chiamato \textsl{I/O asincrono}, in
sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione un meccanismo di
notifica asincrona delle variazione dello stato del file descriptor aperto in
questo modo.
-Quello che succede è che per tutti i file posti in questa modalità\footnote{si
- tenga presente però che essa non è utilizzabile con i file ordinari ma solo
+Quello che succede è che per tutti i file posti in questa modalità\footnote{si
+ tenga presente però che essa non è utilizzabile con i file ordinari ma solo
con socket, file di terminale o pseudo terminale, ed anche, a partire dal
kernel 2.6, anche per fifo e pipe.} il sistema genera un apposito segnale,
\const{SIGIO}, tutte le volte che diventa possibile leggere o scrivere dal
-file descriptor che si è posto in questa modalità. Inoltre è possibile, come
+file descriptor che si è posto in questa modalità. Inoltre è possibile, come
illustrato in sez.~\ref{sec:file_fcntl}, selezionare con il comando
\const{F\_SETOWN} di \func{fcntl} quale processo o quale gruppo di processi
-dovrà ricevere il segnale. In questo modo diventa possibile effettuare le
-operazioni di I/O in risposta alla ricezione del segnale, e non ci sarà più la
-necessità di restare bloccati in attesa della disponibilità di accesso ai
+dovrà ricevere il segnale. In questo modo diventa possibile effettuare le
+operazioni di I/O in risposta alla ricezione del segnale, e non ci sarà più la
+necessità di restare bloccati in attesa della disponibilità di accesso ai
file.
% TODO: per i thread l'uso di F_SETOWN ha un significato diverso
Per questo motivo Stevens, ed anche le pagine di manuale di Linux, chiamano
-questa modalità ``\textit{Signal driven I/O}''. Si tratta di un'altra
-modalità di gestione dell'I/O, alternativa all'uso di \itindex{epoll}
+questa modalità ``\textit{Signal driven I/O}''. Si tratta di un'altra
+modalità di gestione dell'I/O, alternativa all'uso di \itindex{epoll}
\textit{epoll},\footnote{anche se le prestazioni ottenute con questa tecnica
- sono inferiori, il vantaggio è che questa modalità è utilizzabile anche con
+ sono inferiori, il vantaggio è che questa modalità è utilizzabile anche con
kernel che non supportano \textit{epoll}, come quelli della serie 2.4,
ottenendo comunque prestazioni superiori a quelle che si hanno con
\func{poll} e \func{select}.} che consente di evitare l'uso delle funzioni
quando vengono usate con un numero molto grande di file descriptor, non hanno
buone prestazioni.
-Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
-presenta notevoli problemi, dato che non è possibile determinare, quando i
-file descriptor sono più di uno, qual è quello responsabile dell'emissione del
+Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
+presenta notevoli problemi, dato che non è possibile determinare, quando i
+file descriptor sono più di uno, qual è quello responsabile dell'emissione del
segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
-illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
-descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
+illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
+descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
verrebbero notificati una volta sola.
-Linux però supporta le estensioni POSIX.1b dei segnali real-time, che vengono
+Linux però supporta le estensioni POSIX.1b dei segnali real-time, che vengono
accodati e che permettono di riconoscere il file descriptor che li ha emessi.
-In questo caso infatti si può fare ricorso alle informazioni aggiuntive
+In questo caso infatti si può fare ricorso alle informazioni aggiuntive
restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma
estesa \var{sa\_sigaction} del gestore installata con il flag
\const{SA\_SIGINFO} (si riveda quanto illustrato in
sez.~\ref{sec:sig_sigaction}).
-Per far questo però occorre utilizzare le funzionalità dei segnali real-time
+Per far questo però occorre utilizzare le funzionalità dei segnali real-time
(vedi sez.~\ref{sec:sig_real_time}) impostando esplicitamente con il comando
\const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
-I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
-gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo
+I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
+gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo
\var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia il
- segnale che si è associato all'I/O, ed indica appunto che il segnale è stato
- generato a causa di attività di I/O.} di \struct{siginfo\_t}, troverà nel
+ segnale che si è associato all'I/O, ed indica appunto che il segnale è stato
+ generato a causa di attività di I/O.} di \struct{siginfo\_t}, troverà nel
campo \var{si\_fd} il valore del file descriptor che ha generato il segnale.
-Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
-ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
-file descriptor; inoltre sarà possibile stabilire delle priorità nella
+Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
+ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
+file descriptor; inoltre sarà possibile stabilire delle priorità nella
risposta a seconda del segnale usato, dato che i segnali real-time supportano
-anche questa funzionalità. In questo modo si può identificare immediatamente
-un file su cui l'accesso è diventato possibile evitando completamente l'uso di
+anche questa funzionalità. In questo modo si può identificare immediatamente
+un file su cui l'accesso è diventato possibile evitando completamente l'uso di
funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura
la coda.
Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo
-più assicurare il comportamento corretto per un segnale real-time, invierà al
+più assicurare il comportamento corretto per un segnale real-time, invierà al
suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali
-in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
-diventati attivi. L'unico modo per essere sicuri che questo non avvenga è di
+in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
+diventati attivi. L'unico modo per essere sicuri che questo non avvenga è di
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
\subsection{I meccanismi di notifica asincrona.}
\label{sec:file_asyncronous_lease}
-Una delle domande più frequenti nella programmazione in ambiente unix-like è
+Una delle domande più frequenti nella programmazione in ambiente unix-like è
quella di come fare a sapere quando un file viene modificato. La
risposta\footnote{o meglio la non risposta, tanto che questa nelle Unix FAQ
\cite{UnixFAQ} viene anche chiamata una \textit{Frequently Unanswered
- Question}.} è che nell'architettura classica di Unix questo non è
+ Question}.} è che nell'architettura classica di Unix questo non è
possibile. Al contrario di altri sistemi operativi infatti un kernel unix-like
classico non prevedeva alcun meccanismo per cui un processo possa essere
-\textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
+\textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
motivo per cui i demoni devono essere \textsl{avvisati} in qualche
modo\footnote{in genere questo vien fatto inviandogli un segnale di
\const{SIGHUP} che, per una convenzione adottata dalla gran parte di detti
programmi, causa la rilettura della configurazione.} se il loro file di
-configurazione è stato modificato, perché possano rileggerlo e riconoscere le
+configurazione è stato modificato, perché possano rileggerlo e riconoscere le
modifiche.
-Questa scelta è stata fatta perché provvedere un simile meccanismo a livello
-generico per qualunque file comporterebbe un notevole aumento di complessità
+Questa scelta è stata fatta perché provvedere un simile meccanismo a livello
+generico per qualunque file comporterebbe un notevole aumento di complessità
dell'architettura della gestione dei file, il tutto per fornire una
-funzionalità che serve soltanto in alcuni casi particolari. Dato che
+funzionalità che serve soltanto in alcuni casi particolari. Dato che
all'origine di Unix i soli programmi che potevano avere una tale esigenza
erano i demoni, attenendosi a uno dei criteri base della progettazione, che
era di far fare al kernel solo le operazioni strettamente necessarie e
lasciare tutto il resto a processi in user space, non era stata prevista
-nessuna funzionalità di notifica.
+nessuna funzionalità di notifica.
-Visto però il crescente interesse nei confronti di una funzionalità di questo
-tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad
+Visto però il crescente interesse nei confronti di una funzionalità di questo
+tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad
interfaccia grafica, quando si deve presentare all'utente lo stato del
filesystem, sono state successivamente introdotte delle estensioni che
-permettessero la creazione di meccanismi di notifica più efficienti dell'unica
-soluzione disponibile con l'interfaccia tradizionale, che è quella del
+permettessero la creazione di meccanismi di notifica più efficienti dell'unica
+soluzione disponibile con l'interfaccia tradizionale, che è quella del
\itindex{polling} \textit{polling}.
-Queste nuove funzionalità sono delle estensioni specifiche, non
+Queste nuove funzionalità sono delle estensioni specifiche, non
standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
supportano meccanismi simili). Alcune di esse sono realizzate, e solo a
partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
\textsl{comandi} aggiuntivi per la funzione \func{fcntl} (vedi
-sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
+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|(}
-La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
-questo è un meccanismo che consente ad un processo, detto \textit{lease
+La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
+questo è un meccanismo che consente ad un processo, detto \textit{lease
holder}, di essere notificato quando un altro processo, chiamato a sua volta
\textit{lease breaker}, cerca di eseguire una \func{open} o una
\func{truncate} sul file del quale l'\textit{holder} detiene il
\textit{lease}.
La notifica avviene in maniera analoga a come illustrato in precedenza per
l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
-il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
+il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
- può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
- in genere è opportuno farlo, come in precedenza, per utilizzare segnali
- real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
-si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
-valore del file descriptor del file sul quale è stato compiuto l'accesso; in
-questo modo un processo può mantenere anche più di un \textit{file lease}.
+ può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
+ in genere è opportuno farlo, come in precedenza, per utilizzare segnali
+ real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
+si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
+valore del file descriptor del file sul quale è stato compiuto l'accesso; in
+questo modo un processo può mantenere anche più di un \textit{file lease}.
Esistono due tipi di \textit{file lease}: di lettura (\textit{read lease}) e
di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
un altro processo esegue l'apertura del file in scrittura o usa
\func{truncate} per troncarlo. Nel secondo caso la notifica avviene anche se
-il file viene aperto in lettura; in quest'ultimo caso però il \textit{lease}
-può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
+il file viene aperto in lettura; in quest'ultimo caso però il \textit{lease}
+può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
Come accennato in sez.~\ref{sec:file_fcntl} il comando di \func{fcntl} che
-consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
+consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
utilizzato anche per rilasciarlo. In tal caso il file descriptor \param{fd}
-passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
+passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
operare, mentre per indicare il tipo di operazione (acquisizione o rilascio)
-occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
+occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
uno dei tre valori di tab.~\ref{tab:file_lease_fctnl}.
\begin{table}[htb]
\end{table}
Se invece si vuole conoscere lo stato di eventuali \textit{file lease}
-occorrerà chiamare \func{fcntl} sul relativo file descriptor \param{fd} con il
-comando \const{F\_GETLEASE}, e si otterrà indietro nell'argomento \param{arg}
+occorrerà chiamare \func{fcntl} sul relativo file descriptor \param{fd} con il
+comando \const{F\_GETLEASE}, e si otterrà indietro nell'argomento \param{arg}
uno dei valori di tab.~\ref{tab:file_lease_fctnl}, che indicheranno la
presenza del rispettivo tipo di \textit{lease}, o, nel caso di
\const{F\_UNLCK}, l'assenza di qualunque \textit{file lease}.
-Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
-su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
+Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
+su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
(pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
-può ottenere un \textit{lease} soltanto per un file appartenente ad un
+può ottenere un \textit{lease} soltanto per un file appartenente ad un
\acr{uid} corrispondente a quello del processo. Soltanto un processo con
-privilegi di amministratore (cioè con la \itindex{capabilities} capability
-\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
+privilegi di amministratore (cioè con la \itindex{capabilities} capability
+\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
\textit{lease} su qualunque file.
-Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
+Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
esegue una \func{truncate} o una \func{open} che confligge con
-esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
+esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
se eseguita in sola lettura, non confligge se si tratta di un \textit{read
lease}.} la funzione si blocca\footnote{a meno di non avere aperto il file
con \const{O\_NONBLOCK}, nel qual caso \func{open} fallirebbe con un errore
di \errcode{EWOULDBLOCK}.} e viene eseguita la notifica al \textit{lease
- holder}, così che questo possa completare le sue operazioni sul file e
+ holder}, così che questo possa completare le sue operazioni sul file e
rilasciare il \textit{lease}. In sostanza con un \textit{read lease} si
rilevano i tentativi di accedere al file per modificarne i dati da parte di un
altro processo, mentre con un \textit{write lease} si rilevano anche i
altro processo inizi con le sue operazioni di scrittura o di lettura su di
esso. In genere un \textit{lease holder} che riceve una notifica deve
provvedere a completare le necessarie operazioni (ad esempio scaricare
-eventuali buffer), per poi rilasciare il \textit{lease} così che il
+eventuali buffer), per poi rilasciare il \textit{lease} così che il
\textit{lease breaker} possa eseguire le sue operazioni. Questo si fa con il
comando \const{F\_SETLEASE}, o rimuovendo il \textit{lease} con
\const{F\_UNLCK}, o, nel caso di \textit{write lease} che confligge con una
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
-declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
+\procfile{/proc/sys/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
+ acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
rilasciato o declassato (che questo sia fatto dal \textit{lease holder} o dal
-kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
+kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
\textit{lease breaker} rimaste bloccate proseguono automaticamente.
-Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
-parte di più processi, l'uso dei \textit{file lease} non consente comunque di
+Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
+parte di più processi, l'uso dei \textit{file lease} non consente comunque di
risolvere il problema di rilevare automaticamente quando un file o una
-directory vengono modificati,\footnote{questa funzionalità venne aggiunta
+directory vengono modificati,\footnote{questa funzionalità venne aggiunta
principalmente ad uso di Samba per poter facilitare l'emulazione del
comportamento di Windows sui file, ma ad oggi viene considerata una
- interfaccia mal progettata ed il suo uso è fortemente sconsigliato a favore
- di \textit{inotify}.} che è quanto necessario ad esempio ai programma di
+ interfaccia mal progettata ed il suo uso è fortemente sconsigliato a favore
+ di \textit{inotify}.} che è quanto necessario ad esempio ai programma di
gestione dei file dei vari desktop grafici.
\itindbeg{dnotify}
-Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata
-un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
+Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata
+un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
specifica di Linux che deve essere evitata se si vogliono scrivere programmi
- portabili, e che le funzionalità illustrate sono disponibili soltanto se è
+ portabili, e che le funzionalità illustrate sono disponibili soltanto se è
stata definita la macro \macro{\_GNU\_SOURCE}.} chiamata \textit{dnotify},
che consente di richiedere una notifica quando una directory, o uno qualunque
dei file in essa contenuti, viene modificato. Come per i \textit{file lease}
la notifica avviene di default attraverso il segnale \const{SIGIO}, ma se ne
-può utilizzare un altro.\footnote{e di nuovo, per le ragioni già esposte in
- precedenza, è opportuno che si utilizzino dei segnali real-time.} Inoltre,
-come in precedenza, si potrà ottenere nel gestore del segnale il file
-descriptor che è stato modificato tramite il contenuto della struttura
+può utilizzare un altro.\footnote{e di nuovo, per le ragioni già esposte in
+ precedenza, è opportuno che si utilizzino dei segnali real-time.} Inoltre,
+come in precedenza, si potrà ottenere nel gestore del segnale il file
+descriptor che è stato modificato tramite il contenuto della struttura
\struct{siginfo\_t}.
\index{file!lease|)}
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
+ \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
\func{read}, \func{pread}, \func{readv}.\\
- \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
+ \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
fra \func{write}, \func{pwrite}, \func{writev},
\func{truncate}, \func{ftruncate}.\\
- \const{DN\_CREATE} & È stato creato un file nella directory, con
+ \const{DN\_CREATE} & È stato creato un file nella directory, con
l'esecuzione di una fra \func{open}, \func{creat},
\func{mknod}, \func{mkdir}, \func{link},
\func{symlink}, \func{rename} (da un'altra
directory).\\
- \const{DN\_DELETE} & È stato cancellato un file dalla directory con
+ \const{DN\_DELETE} & È stato cancellato un file dalla directory con
l'esecuzione di una fra \func{unlink}, \func{rename}
(su un'altra directory), \func{rmdir}.\\
- \const{DN\_RENAME} & È stato rinominato un file all'interno della
+ \const{DN\_RENAME} & È stato rinominato un file all'interno della
directory (con \func{rename}).\\
- \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
+ \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
l'esecuzione di una fra \func{chown}, \func{chmod},
\func{utime}.\\
\const{DN\_MULTISHOT}& Richiede una notifica permanente di tutti gli
\label{tab:file_notify}
\end{table}
-Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
+Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
certa directory eseguendo la funzione \func{fcntl} su un file descriptor
associato alla stessa con il comando \const{F\_NOTIFY}. In questo caso
l'argomento \param{arg} di \func{fcntl} serve ad indicare per quali classi
eventi si vuole ricevere la notifica, e prende come valore una maschera
-binaria composta dall'OR aritmetico di una o più delle costanti riportate in
+binaria composta dall'OR aritmetico di una o più delle costanti riportate in
tab.~\ref{tab:file_notify}.
A meno di non impostare in maniera esplicita una notifica permanente usando il
-valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
-sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
+valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
+sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
richiesta. Questo significa che un programma deve registrarsi un'altra volta
se desidera essere notificato di ulteriori cambiamenti. Se si eseguono diverse
chiamate con \const{F\_NOTIFY} e con valori diversi per \param{arg} questi
-ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
-specificate in chiamate successive vengono aggiunte a quelle già impostate
+ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
+specificate in chiamate successive vengono aggiunte a quelle già impostate
nelle precedenti. Se si vuole rimuovere la notifica si deve invece
specificare un valore nullo.
\itindbeg{inotify}
-Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
+Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
usare un file descriptor per ciascuna directory che si vuole tenere sotto
controllo, il che porta facilmente ad avere un eccesso di file aperti. Inoltre
-quando la directory che si controlla è all'interno di un dispositivo
+quando la directory che si controlla è all'interno di un dispositivo
rimovibile, mantenere il relativo file descriptor aperto comporta
-l'impossibilità di smontare il dispositivo e di rimuoverlo, il che in genere
+l'impossibilità di smontare il dispositivo e di rimuoverlo, il che in genere
complica notevolmente la gestione dell'uso di questi dispositivi.
-Un altro problema è che l'interfaccia di \textit{dnotify} consente solo di
+Un altro problema è che l'interfaccia di \textit{dnotify} consente solo di
tenere sotto controllo il contenuto di una directory; la modifica di un file
-viene segnalata, ma poi è necessario verificare di quale file si tratta
-(operazione che può essere molto onerosa quando una directory contiene un gran
+viene segnalata, ma poi è necessario verificare di quale file si tratta
+(operazione che può essere molto onerosa quando una directory contiene un gran
numero di file). Infine l'uso dei segnali come interfaccia di notifica
comporta tutti i problemi di gestione visti in sez.~\ref{sec:sig_management} e
sez.~\ref{sec:sig_adv_control}. Per tutta questa serie di motivi in generale
-quella di \textit{dnotify} viene considerata una interfaccia di usabilità
-problematica ed il suo uso oggi è fortemente sconsigliato.
+quella di \textit{dnotify} viene considerata una interfaccia di usabilità
+problematica ed il suo uso oggi è fortemente sconsigliato.
\itindend{dnotify}
-Per risolvere i problemi appena illustrati è stata introdotta una nuova
+Per risolvere i problemi appena illustrati è stata introdotta una nuova
interfaccia per l'osservazione delle modifiche a file o directory, chiamata
-\textit{inotify}.\footnote{l'interfaccia è disponibile a partire dal kernel
+\textit{inotify}.\footnote{l'interfaccia è disponibile a partire dal kernel
2.6.13, le relative funzioni sono state introdotte nelle glibc 2.4.} Anche
-questa è una interfaccia specifica di Linux (pertanto non deve essere usata se
-si devono scrivere programmi portabili), ed è basata sull'uso di una coda di
+questa è una interfaccia specifica di Linux (pertanto non deve essere usata se
+si devono scrivere programmi portabili), ed è basata sull'uso di una coda di
notifica degli eventi associata ad un singolo file descriptor, il che permette
di risolvere il principale problema di \itindex{dnotify} \textit{dnotify}. La
coda viene creata attraverso la funzione \funcd{inotify\_init}, il cui
-prototipo è:
+prototipo è:
\begin{prototype}{sys/inotify.h}
{int inotify\_init(void)}
Inizializza una istanza di \textit{inotify}.
\bodydesc{La funzione restituisce un file descriptor in caso di successo, o
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
+ \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
\textit{inotify} consentite all'utente.
- \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
+ \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
nel sistema.
- \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
l'istanza.
\end{errlist}
}
La funzione non prende alcun argomento; inizializza una istanza di
\textit{inotify} e restituisce un file descriptor attraverso il quale verranno
effettuate le operazioni di notifica;\footnote{per evitare abusi delle risorse
- 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
+ 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
-descriptor speciale che non è associato a nessun file su disco, e che viene
+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
+osservazione. Dato che questo file descriptor non è associato a nessun file o
directory reale, l'inconveniente di non poter smontare un filesystem i cui
file sono tenuti sotto osservazione viene completamente
-eliminato.\footnote{anzi, una delle capacità dell'interfaccia di
- \textit{inotify} è proprio quella di notificare il fatto che il filesystem
- su cui si trova il file o la directory osservata è stato smontato.}
+eliminato.\footnote{anzi, una delle capacità dell'interfaccia di
+ \textit{inotify} è proprio quella di notificare il fatto che il filesystem
+ su cui si trova il file o la directory osservata è stato smontato.}
-Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
+Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
-con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
+con l'interfaccia di \textit{epoll};\footnote{ed a partire dal kernel 2.6.25 è
stato introdotto anche il supporto per il \itindex{signal~driven~I/O}
\texttt{signal-driven I/O} trattato in
sez.~\ref{sec:file_asyncronous_operation}.} siccome gli eventi vengono
notificati come dati disponibili in lettura, dette funzioni ritorneranno tutte
-le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i
+le volte che si avrà un evento di notifica. Così, invece di dover utilizzare i
segnali,\footnote{considerati una pessima scelta dal punto di vista
- dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
-una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
+ dell'interfaccia utente.} si potrà gestire l'osservazione degli eventi con
+una qualunque delle modalità di \textit{I/O multiplexing} illustrate in
sez.~\ref{sec:file_multiplexing}. Qualora si voglia cessare l'osservazione,
-sarà sufficiente chiudere il file descriptor e tutte le risorse allocate
+sarà sufficiente chiudere il file descriptor e tutte le risorse allocate
saranno automaticamente rilasciate.
Infine l'interfaccia di \textit{inotify} consente di mettere sotto
osservazione, oltre che una directory, anche singoli file. Una volta creata
la coda di notifica si devono definire gli eventi da tenere sotto
osservazione; questo viene fatto attraverso una \textsl{lista di osservazione}
-(o \textit{watch list}) che è associata alla coda. Per gestire la lista di
-osservazione l'interfaccia fornisce due funzioni, la prima di queste è
-\funcd{inotify\_add\_watch}, il cui prototipo è:
+(o \textit{watch list}) che è associata alla coda. Per gestire la lista di
+osservazione l'interfaccia fornisce due funzioni, la prima di queste è
+\funcd{inotify\_add\_watch}, il cui prototipo è:
\begin{prototype}{sys/inotify.h}
{int inotify\_add\_watch(int fd, const char *pathname, uint32\_t mask)}
Aggiunge un evento di osservazione alla lista di osservazione di \param{fd}.
\bodydesc{La funzione restituisce un valore positivo in caso di successo, o
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCESS}] non si ha accesso in lettura al file indicato.
\item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd}
- non è un file descriptor di \textit{inotify}.
- \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
+ non è un file descriptor di \textit{inotify}.
+ \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
osservazione o il kernel non ha potuto allocare una risorsa necessaria.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENOMEM} e \errval{EBADF}.}
La funzione consente di creare un ``\textsl{osservatore}'' (il cosiddetto
``\textit{watch}'') nella lista di osservazione di una coda di notifica, che
deve essere indicata specificando il file descriptor ad essa associato
-nell'argomento \param{fd}.\footnote{questo ovviamente dovrà essere un file
+nell'argomento \param{fd}.\footnote{questo ovviamente dovrà essere un file
descriptor creato con \func{inotify\_init}.} Il file o la directory da
porre sotto osservazione vengono invece indicati per nome, da passare
nell'argomento \param{pathname}. Infine il terzo argomento, \param{mask},
indica che tipo di eventi devono essere tenuti sotto osservazione e le
-modalità della stessa. L'operazione può essere ripetuta per tutti i file e le
+modalità della stessa. L'operazione può essere ripetuta per tutti i file e le
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
+ 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
un solo file descriptor.
Il tipo di evento che si vuole osservare deve essere specificato
\textbf{Valore} & & \textbf{Significato} \\
\hline
\hline
- \const{IN\_ACCESS} &$\bullet$& C'è stato accesso al file in
+ \const{IN\_ACCESS} &$\bullet$& C'è stato accesso al file in
lettura.\\
\const{IN\_ATTRIB} &$\bullet$& Ci sono stati cambiamenti sui dati
dell'inode (o sugli attributi
estesi, vedi
sez.~\ref{sec:file_xattr}).\\
- \const{IN\_CLOSE\_WRITE} &$\bullet$& È stato chiuso un file aperto in
+ \const{IN\_CLOSE\_WRITE} &$\bullet$& È stato chiuso un file aperto in
scrittura.\\
- \const{IN\_CLOSE\_NOWRITE}&$\bullet$& È stato chiuso un file aperto in
+ \const{IN\_CLOSE\_NOWRITE}&$\bullet$& È stato chiuso un file aperto in
sola lettura.\\
- \const{IN\_CREATE} &$\bullet$& È stato creato un file o una
+ \const{IN\_CREATE} &$\bullet$& È stato creato un file o una
directory in una directory sotto
osservazione.\\
- \const{IN\_DELETE} &$\bullet$& È stato cancellato un file o una
+ \const{IN\_DELETE} &$\bullet$& È stato cancellato un file o una
directory in una directory sotto
osservazione.\\
- \const{IN\_DELETE\_SELF} & -- & È stato cancellato il file (o la
+ \const{IN\_DELETE\_SELF} & -- & È stato cancellato il file (o la
directory) sotto osservazione.\\
- \const{IN\_MODIFY} &$\bullet$& È stato modificato il file.\\
- \const{IN\_MOVE\_SELF} & & È stato rinominato il file (o la
+ \const{IN\_MODIFY} &$\bullet$& È stato modificato il file.\\
+ \const{IN\_MOVE\_SELF} & & È stato rinominato il file (o la
directory) sotto osservazione.\\
- \const{IN\_MOVED\_FROM} &$\bullet$& Un file è stato spostato fuori dalla
+ \const{IN\_MOVED\_FROM} &$\bullet$& Un file è stato spostato fuori dalla
directory sotto osservazione.\\
- \const{IN\_MOVED\_TO} &$\bullet$& Un file è stato spostato nella
+ \const{IN\_MOVED\_TO} &$\bullet$& Un file è stato spostato nella
directory sotto osservazione.\\
- \const{IN\_OPEN} &$\bullet$& Un file è stato aperto.\\
+ \const{IN\_OPEN} &$\bullet$& Un file è stato aperto.\\
\hline
\const{IN\_CLOSE} & & Combinazione di
\const{IN\_CLOSE\_WRITE} e
tipo di evento avvenuto, \func{inotify\_add\_watch} supporta ulteriori
flag,\footnote{i flag \const{IN\_DONT\_FOLLOW}, \const{IN\_MASK\_ADD} e
\const{IN\_ONLYDIR} sono stati introdotti a partire dalle glibc 2.5, se si
- usa la versione 2.4 è necessario definirli a mano.} riportati in
-tab.~\ref{tab:inotify_add_watch_flag}, che indicano le modalità di
+ usa la versione 2.4 è necessario definirli a mano.} riportati in
+tab.~\ref{tab:inotify_add_watch_flag}, che indicano le modalità di
osservazione (da passare sempre nell'argomento \param{mask}) e che al
contrario dei precedenti non vengono mai impostati nei risultati in uscita.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{IN\_DONT\_FOLLOW}& Non dereferenzia \param{pathname} se questo è un
+ \const{IN\_DONT\_FOLLOW}& Non dereferenzia \param{pathname} se questo è un
link simbolico.\\
- \const{IN\_MASK\_ADD} & Aggiunge a quelli già impostati i flag indicati
+ \const{IN\_MASK\_ADD} & Aggiunge a quelli già impostati i flag indicati
nell'argomento \param{mask}, invece di
sovrascriverli.\\
\const{IN\_ONESHOT} & Esegue l'osservazione su \param{pathname} per una
sola volta, rimuovendolo poi dalla \textit{watch
list}.\\
- \const{IN\_ONLYDIR} & Se \param{pathname} è una directory riporta
+ \const{IN\_ONLYDIR} & Se \param{pathname} è una directory riporta
soltanto gli eventi ad essa relativi e non
quelli per i file che contiene.\\
\hline
\end{tabular}
\caption{Le costanti che identificano i bit della maschera binaria
dell'argomento \param{mask} di \func{inotify\_add\_watch} che indicano le
- modalità di osservazione.}
+ modalità di osservazione.}
\label{tab:inotify_add_watch_flag}
\end{table}
Se non esiste nessun \textit{watch} per il file o la directory specificata
-questo verrà creato per gli eventi specificati dall'argomento \param{mask},
-altrimenti la funzione sovrascriverà le impostazioni precedenti, a meno che
+questo verrà creato per gli eventi specificati dall'argomento \param{mask},
+altrimenti la funzione sovrascriverà le impostazioni precedenti, a meno che
non si sia usato il flag \const{IN\_MASK\_ADD}, nel qual caso gli eventi
-specificati saranno aggiunti a quelli già presenti.
+specificati saranno aggiunti a quelli già presenti.
Come accennato quando si tiene sotto osservazione una directory vengono
restituite le informazioni sia riguardo alla directory stessa che ai file che
-essa contiene; questo comportamento può essere disabilitato utilizzando il
+essa contiene; questo comportamento può essere disabilitato utilizzando il
flag \const{IN\_ONLYDIR}, che richiede di riportare soltanto gli eventi
relativi alla directory stessa. Si tenga presente inoltre che quando si
osserva una directory vengono riportati solo gli eventi sui file che essa
contiene direttamente, non quelli relativi a file contenuti in eventuali
-sottodirectory; se si vogliono osservare anche questi sarà necessario creare
+sottodirectory; se si vogliono osservare anche questi sarà necessario creare
ulteriori \textit{watch} per ciascuna sottodirectory.
-Infine usando il flag \const{IN\_ONESHOT} è possibile richiedere una notifica
-singola;\footnote{questa funzionalità però è disponibile soltanto a partire dal
+Infine usando il flag \const{IN\_ONESHOT} è possibile richiedere una notifica
+singola;\footnote{questa funzionalità però è disponibile soltanto a partire dal
kernel 2.6.16.} una volta verificatosi uno qualunque fra gli eventi
-richiesti con \func{inotify\_add\_watch} l'\textsl{osservatore} verrà
+richiesti con \func{inotify\_add\_watch} l'\textsl{osservatore} verrà
automaticamente rimosso dalla lista di osservazione e nessun ulteriore evento
-sarà più notificato.
+sarà più notificato.
In caso di successo \func{inotify\_add\_watch} ritorna un intero positivo,
detto \textit{watch descriptor}, che identifica univocamente un
la eventuale rimozione dello stesso.
La seconda funzione per la gestione delle code di notifica, che permette di
-rimuovere un \textsl{osservatore}, è \funcd{inotify\_rm\_watch}, ed il suo
-prototipo è:
+rimuovere un \textsl{osservatore}, è \funcd{inotify\_rm\_watch}, ed il suo
+prototipo è:
\begin{prototype}{sys/inotify.h}
{int inotify\_rm\_watch(int fd, uint32\_t wd)}
Rimuove un \textsl{osservatore} da una coda di notifica.
\bodydesc{La funzione restituisce 0 in caso di successo, o $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
+ \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
valido.
- \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
- non è associato ad una coda di notifica.
+ \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
+ non è associato ad una coda di notifica.
\end{errlist}
}
\end{prototype}
La funzione rimuove dalla coda di notifica identificata dall'argomento
\param{fd} l'osservatore identificato dal \textit{watch descriptor}
\param{wd};\footnote{ovviamente deve essere usato per questo argomento un
- valore ritornato da \func{inotify\_add\_watch}, altrimenti si avrà un errore
+ valore ritornato da \func{inotify\_add\_watch}, altrimenti si avrà un errore
di \errval{EINVAL}.} in caso di successo della rimozione, contemporaneamente
-alla cancellazione dell'osservatore, sulla coda di notifica verrà generato un
+alla cancellazione dell'osservatore, sulla coda di notifica verrà generato un
evento di tipo \const{IN\_IGNORED} (vedi
tab.~\ref{tab:inotify_read_event_flag}). Si tenga presente che se un file
viene cancellato o un filesystem viene smontato i relativi osservatori vengono
-rimossi automaticamente e non è necessario utilizzare
+rimossi automaticamente e non è necessario utilizzare
\func{inotify\_rm\_watch}.
Come accennato l'interfaccia di \textit{inotify} prevede che gli eventi siano
notificati come dati presenti in lettura sul file descriptor associato alla
-coda di notifica. Una applicazione pertanto dovrà leggere i dati da detto file
-con una \func{read}, che ritornerà sul buffer i dati presenti nella forma di
-una o più strutture di tipo \struct{inotify\_event} (la cui definizione è
+coda di notifica. Una applicazione pertanto dovrà leggere i dati da detto file
+con una \func{read}, che ritornerà sul buffer i dati presenti nella forma di
+una o più strutture di tipo \struct{inotify\_event} (la cui definizione è
riportata in fig.~\ref{fig:inotify_event}). Qualora non siano presenti dati la
-\func{read} si bloccherà (a meno di non aver impostato il file descriptor in
-modalità non bloccante) fino all'arrivo di almeno un evento.
+\func{read} si bloccherà (a meno di non aver impostato il file descriptor in
+modalità non bloccante) fino all'arrivo di almeno un evento.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:inotify_event}
\end{figure}
-Una ulteriore caratteristica dell'interfaccia di \textit{inotify} è che essa
+Una ulteriore caratteristica dell'interfaccia di \textit{inotify} è che essa
permette di ottenere con \func{ioctl}, come per i file descriptor associati ai
socket (si veda sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in
lettura sul file descriptor, utilizzando su di esso l'operazione
-\const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file
- (vedi sez.~\ref{sec:file_ioctl}), che è disponibile solo per i socket e per
- i file descriptor creati con \func{inotify\_init}.} Si può così utilizzare
+\const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file
+ (vedi sez.~\ref{sec:file_ioctl}), che è disponibile solo per i socket e per
+ i file descriptor creati con \func{inotify\_init}.} Si può così utilizzare
questa operazione, oltre che per predisporre una operazione di lettura con un
buffer di dimensioni adeguate, anche per ottenere rapidamente il numero di
file che sono cambiati.
-Una volta effettuata la lettura con \func{read} a ciascun evento sarà
+Una volta effettuata la lettura con \func{read} a ciascun evento sarà
associata una struttura \struct{inotify\_event} contenente i rispettivi dati.
Per identificare a quale file o directory l'evento corrisponde viene
restituito nel campo \var{wd} il \textit{watch descriptor} con cui il relativo
-osservatore è stato registrato. Il campo \var{mask} contiene invece una
+osservatore è stato registrato. Il campo \var{mask} contiene invece una
maschera di bit che identifica il tipo di evento verificatosi; in essa
compariranno sia i bit elencati nella prima parte di
tab.~\ref{tab:inotify_event_watch}, che gli eventuali valori
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{IN\_IGNORED} & L'osservatore è stato rimosso, sia in maniera
+ \const{IN\_IGNORED} & L'osservatore è stato rimosso, sia in maniera
esplicita con l'uso di \func{inotify\_rm\_watch},
che in maniera implicita per la rimozione
dell'oggetto osservato o per lo smontaggio del
filesystem su cui questo si trova.\\
\const{IN\_ISDIR} & L'evento avvenuto fa riferimento ad una directory
- (consente così di distinguere, quando si pone
+ (consente così di distinguere, quando si pone
sotto osservazione una directory, fra gli eventi
relativi ad essa e quelli relativi ai file che
essa contiene).\\
\const{IN\_Q\_OVERFLOW}& Si sono eccedute le dimensioni della coda degli
eventi (\textit{overflow} della coda); in questo
- caso il valore di \var{wd} è $-1$.\footnotemark\\
+ caso il valore di \var{wd} è $-1$.\footnotemark\\
\const{IN\_UNMOUNT} & Il filesystem contenente l'oggetto posto sotto
- osservazione è stato smontato.\\
+ osservazione è stato smontato.\\
\hline
\end{tabular}
\caption{Le costanti che identificano i bit aggiuntivi usati nella maschera
\const{IN\_Q\_OVERFLOW}.}
Il campo \var{cookie} contiene invece un intero univoco che permette di
-identificare eventi correlati (per i quali avrà lo stesso valore), al momento
+identificare eventi correlati (per i quali avrà lo stesso valore), al momento
viene utilizzato soltanto per rilevare lo spostamento di un file, consentendo
-così all'applicazione di collegare la corrispondente coppia di eventi
+così all'applicazione di collegare la corrispondente coppia di eventi
\const{IN\_MOVED\_TO} e \const{IN\_MOVED\_FROM}.
Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
-l'evento è relativo ad un file presente in una directory posta sotto
+l'evento è relativo ad un file presente in una directory posta sotto
osservazione, in tal caso essi contengono rispettivamente il nome del file
(come pathname relativo alla directory osservata) e la relativa dimensione in
byte. Il campo \var{name} viene sempre restituito come stringa terminata da
-NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di
+NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di
allineamento del risultato, ed il valore di \var{len} corrisponde al totale
della dimensione di \var{name}, zeri aggiuntivi compresi. La stringa con il
nome del file viene restituita nella lettura subito dopo la struttura
len}.
Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
-semplice programma che permette di mettere sotto osservazione uno o più file e
+semplice programma che permette di mettere sotto osservazione uno o più file e
directory. Il programma si chiama \texttt{inotify\_monitor.c} ed il codice
-completo è disponibile coi sorgenti allegati alla guida, il corpo principale
+completo è disponibile coi sorgenti allegati alla guida, il corpo principale
del programma, che non contiene la sezione di gestione delle opzioni e le
-funzioni di ausilio è riportato in fig.~\ref{fig:inotify_monitor_example}.
+funzioni di ausilio è riportato in fig.~\ref{fig:inotify_monitor_example}.
\begin{figure}[!htbp]
\footnotesize \centering
ottenendo con \func{inotify\_init} il relativo file descriptor (oppure usce in
caso di errore).
-Il passo successivo è aggiungere (\texttt{\small 21--30}) alla coda di
+Il passo successivo è aggiungere (\texttt{\small 21--30}) alla coda di
notifica gli opportuni osservatori per ciascuno dei file o directory indicati
all'invocazione del comando; questo viene fatto eseguendo un ciclo
(\texttt{\small 22--29}) fintanto che la variabile \var{i}, inizializzata a
-zero (\texttt{\small 21}) all'inizio del ciclo, è minore del numero totale di
+zero (\texttt{\small 21}) all'inizio del ciclo, è minore del numero totale di
argomenti rimasti. All'interno del ciclo si invoca (\texttt{\small 23})
\func{inotify\_add\_watch} per ciascuno degli argomenti, usando la maschera
degli eventi data dalla variabile \var{mask} (il cui valore viene impostato
Completa l'inizializzazione di \textit{inotify} inizia il ciclo principale
(\texttt{\small 32--56}) del programma, nel quale si resta in attesa degli
eventi che si intendono osservare. Questo viene fatto eseguendo all'inizio del
-ciclo (\texttt{\small 33}) una \func{read} che si bloccherà fintanto che non
+ciclo (\texttt{\small 33}) una \func{read} che si bloccherà fintanto che non
si saranno verificati eventi.
-Dato che l'interfaccia di \textit{inotify} può riportare anche più eventi in
-una sola lettura, si è avuto cura di passare alla \func{read} un buffer di
+Dato che l'interfaccia di \textit{inotify} può riportare anche più eventi in
+una sola lettura, si è avuto cura di passare alla \func{read} un buffer di
dimensioni adeguate, inizializzato in (\texttt{\small 7}) ad un valore di
-approssimativamente 512 eventi.\footnote{si ricordi che la quantità di dati
- restituita da \textit{inotify} è variabile a causa della diversa lunghezza
+approssimativamente 512 eventi.\footnote{si ricordi che la quantità di dati
+ restituita da \textit{inotify} è variabile a causa della diversa lunghezza
del nome del file restituito insieme a \struct{inotify\_event}.} In caso di
errore di lettura (\texttt{\small 35--40}) il programma esce con un messaggio
di errore (\texttt{\small 37--39}), a meno che non si tratti di una
interruzione della system call, nel qual caso (\texttt{\small 36}) si ripete la
lettura.
-Se la lettura è andata a buon fine invece si esegue un ciclo (\texttt{\small
+Se la lettura è andata a buon fine invece si esegue un ciclo (\texttt{\small
43--52}) per leggere tutti gli eventi restituiti, al solito si inizializza
l'indice \var{i} a zero (\texttt{\small 42}) e si ripetono le operazioni
(\texttt{\small 43}) fintanto che esso non supera il numero di byte restituiti
utilizzato il valore del campo \var{event->len} e non al fatto che
\var{event->name} riporti o meno un puntatore nullo.\footnote{l'interfaccia
infatti, qualora il nome non sia presente, non avvalora il campo
- \var{event->name}, che si troverà a contenere quello che era precedentemente
- presente nella rispettiva locazione di memoria, nel caso più comune il
+ \var{event->name}, che si troverà a contenere quello che era precedentemente
+ presente nella rispettiva locazione di memoria, nel caso più comune il
puntatore al nome di un file osservato in precedenza.} Si utilizza poi
(\texttt{\small 50}) la funzione \code{printevent}, che interpreta il valore
del campo \var{event->mask} per stampare il tipo di eventi
IN_CLOSE_NOWRITE,
\end{verbatim}
-I lettori più accorti si saranno resi conto che nel ciclo di lettura degli
+I lettori più accorti si saranno resi conto che nel ciclo di lettura degli
eventi appena illustrato non viene trattato il caso particolare in cui la
-funzione \func{read} restituisce in \var{nread} un valore nullo. Lo si è fatto
-perché con \textit{inotify} il ritorno di una \func{read} con un valore nullo
+funzione \func{read} restituisce in \var{nread} un valore nullo. Lo si è fatto
+perché con \textit{inotify} il ritorno di una \func{read} con un valore nullo
avviene soltanto, come forma di avviso, quando si sia eseguita la funzione
specificando un buffer di dimensione insufficiente a contenere anche un solo
evento. Nel nostro caso le dimensioni erano senz'altro sufficienti, per cui
-tale evenienza non si verificherà mai.
+tale evenienza non si verificherà mai.
-Ci si potrà però chiedere cosa succede se il buffer è sufficiente per un
-evento, ma non per tutti gli eventi verificatisi. Come si potrà notare nel
-codice illustrato in precedenza non si è presa nessuna precauzione per
+Ci si potrà però chiedere cosa succede se il buffer è sufficiente per un
+evento, ma non per tutti gli eventi verificatisi. Come si potrà notare nel
+codice illustrato in precedenza non si è presa nessuna precauzione per
verificare che non ci fossero stati troncamenti dei dati. Anche in questo caso
-il comportamento scelto è corretto, perché l'interfaccia di \textit{inotify}
+il comportamento scelto è corretto, perché l'interfaccia di \textit{inotify}
garantisce automaticamente, anche quando ne sono presenti in numero maggiore,
di restituire soltanto il numero di eventi che possono rientrare completamente
-nelle dimensioni del buffer specificato.\footnote{si avrà cioè, facendo
+nelle dimensioni del buffer specificato.\footnote{si avrà cioè, facendo
riferimento sempre al codice di fig.~\ref{fig:inotify_monitor_example}, che
- \var{read} sarà in genere minore delle dimensioni di \var{buffer} ed uguale
+ \var{read} sarà in genere minore delle dimensioni di \var{buffer} ed uguale
soltanto qualora gli eventi corrispondano esattamente alle dimensioni di
- quest'ultimo.} Se gli eventi sono di più saranno restituiti solo quelli che
+ quest'ultimo.} Se gli eventi sono di più saranno restituiti solo quelli che
entrano interamente nel buffer e gli altri saranno restituiti alla successiva
chiamata di \func{read}.
-Infine un'ultima caratteristica dell'interfaccia di \textit{inotify} è che gli
-eventi restituiti nella lettura formano una sequenza ordinata, è cioè
+Infine un'ultima caratteristica dell'interfaccia di \textit{inotify} è che gli
+eventi restituiti nella lettura formano una sequenza ordinata, è cioè
garantito che se si esegue uno spostamento di un file gli eventi vengano
generati nella sequenza corretta. L'interfaccia garantisce anche che se si
-verificano più eventi consecutivi identici (vale a dire con gli stessi valori
+verificano più eventi consecutivi identici (vale a dire con gli stessi valori
dei campi \var{wd}, \var{mask}, \var{cookie}, e \var{name}) questi vengono
raggruppati in un solo evento.
\subsection{L'interfaccia POSIX per l'I/O asincrono}
\label{sec:file_asyncronous_io}
-Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
-dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
- asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
+Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
+dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
+ asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
di I/O non attendono il completamento delle operazioni prima di ritornare,
-così che il processo non viene bloccato. In questo modo diventa ad esempio
+così che il processo non viene bloccato. In questo modo diventa ad esempio
possibile effettuare una richiesta preventiva di dati, in modo da poter
effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
-Benché la modalità di apertura asincrona di un file possa risultare utile in
+Benché la modalità di apertura asincrona di un file possa risultare utile in
varie occasioni (in particolar modo con i socket e gli altri file per i quali
-le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
-comunque limitata alla notifica della disponibilità del file descriptor per le
+le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
+comunque limitata alla notifica della disponibilità del file descriptor per le
operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo
standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono vero
e proprio, che prevede un insieme di funzioni dedicate per la lettura e la
scrittura dei file, completamente separate rispetto a quelle usate
normalmente.
-In generale questa interfaccia è completamente astratta e può essere
+In generale questa interfaccia è completamente astratta e può essere
implementata sia direttamente nel kernel, che in user space attraverso l'uso
di \itindex{thread} \textit{thread}. Per le versioni del kernel meno recenti
esiste una implementazione di questa interfaccia fornita delle \acr{glibc},
-che è realizzata completamente in user space, ed è accessibile linkando i
-programmi con la libreria \file{librt}. Nelle versioni più recenti (a partire
-dalla 2.5.32) è stato introdotto direttamente nel kernel un nuovo layer per
+che è realizzata completamente in user space, ed è accessibile linkando i
+programmi con la libreria \file{librt}. Nelle versioni più recenti (a partire
+dalla 2.5.32) è stato introdotto direttamente nel kernel un nuovo layer per
l'I/O asincrono.
Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
\textit{asyncronous I/O control block}), che viene passata come argomento a
tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
-\file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
+\file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
-disponibilità dell'interfaccia per l'I/O asincrono.
+disponibilità dell'interfaccia per l'I/O asincrono.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:file_aiocb}
\end{figure}
-Le operazioni di I/O asincrono possono essere effettuate solo su un file già
+Le operazioni di I/O asincrono possono essere effettuate solo su un file già
aperto; il file deve inoltre supportare la funzione \func{lseek}, pertanto
-terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
+terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
contemporanee effettuabili su un singolo file. Ogni operazione deve
inizializzare opportunamente un \textit{control block}. Il file descriptor su
cui operare deve essere specificato tramite il campo \var{aio\_fildes}; dato
-che più operazioni possono essere eseguita in maniera asincrona, il concetto
+che più operazioni possono essere eseguita in maniera asincrona, il concetto
di posizione corrente sul file viene a mancare; pertanto si deve sempre
specificare nel campo \var{aio\_offset} la posizione sul file da cui i dati
saranno letti o scritti. Nel campo \var{aio\_buf} deve essere specificato
l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza
del blocco di dati da trasferire.
-Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
-di I/O.\footnote{in generale perché ciò sia possibile occorre che la
+Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
+di I/O.\footnote{in generale perché ciò sia possibile occorre che la
piattaforma supporti questa caratteristica, questo viene indicato definendo
le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
- \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
+ \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
partire da quella del processo chiamante (vedi sez.~\ref{sec:proc_priority}),
cui viene sottratto il valore di questo campo. Il campo
-\var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
+\var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
come vedremo, permette di eseguire con una sola chiamata una serie di
operazioni, usando un vettore di \textit{control block}. Tramite questo campo
-si specifica quale è la natura di ciascuna di esse.
+si specifica quale è la natura di ciascuna di esse.
-Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
+Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
(illustrata in in fig.~\ref{fig:struct_sigevent}) che serve a specificare il
modo in cui si vuole che venga effettuata la notifica del completamento delle
-operazioni richieste; per la trattazione delle modalità di utilizzo della
-stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
+operazioni richieste; per la trattazione delle modalità di utilizzo della
+stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
Le due funzioni base dell'interfaccia per l'I/O asincrono sono
\funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
\param{aiocbp}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
- \item[\errcode{ENOSYS}] la funzione non è implementata.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per i campi
+ \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
+ \item[\errcode{ENOSYS}] la funzione non è implementata.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per i campi
\var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
- \item[\errcode{EAGAIN}] la coda delle richieste è momentaneamente piena.
+ \item[\errcode{EAGAIN}] la coda delle richieste è momentaneamente piena.
\end{errlist}
}
\end{functions}
Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
-richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
+richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
\errcode{EINVAL} siano rilevati immediatamente al momento della chiamata,
potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
Si tenga inoltre presente che deallocare la memoria indirizzata da
\param{aiocbp} o modificarne i valori prima della conclusione di una
-operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
-campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
+operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
+campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
richiesta. Questo comporta che non si devono usare per \param{aiocbp}
variabili automatiche e che non si deve riutilizzare la stessa struttura per
un'altra operazione fintanto che la precedente non sia stata ultimata. In
generale per ogni operazione si deve utilizzare una diversa struttura
\struct{aiocb}.
-Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
+Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
\func{aio\_write} non implica che le operazioni siano state effettivamente
eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
altre due funzioni, che permettono di controllare lo stato di esecuzione. La
-prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
-errore; il suo prototipo è:
+prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
+errore; il suo prototipo è:
\begin{prototype}{aio.h}
{int aio\_error(const struct aiocb *aiocbp)}
fallimento.}
\end{prototype}
-Se l'operazione non si è ancora completata viene restituito l'errore di
-\errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
+Se l'operazione non si è ancora completata viene restituito l'errore di
+\errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
conclusa con successo, altrimenti restituisce il codice dell'errore
verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
-codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
+codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
del caso, i codici di errore delle system call \func{read}, \func{write} e
\func{fsync}.
-Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
+Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
che una chiamata ad \func{aio\_error} non ha restituito
-\errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
+\errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
permette di verificare il completamento delle operazioni di I/O asincrono; il
-suo prototipo è:
+suo prototipo è:
\begin{prototype}{aio.h}
{ssize\_t aio\_return(const struct aiocb *aiocbp)}
\end{prototype}
La funzione deve essere chiamata una sola volte per ciascuna operazione
-asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
-associate. É per questo motivo che occorre chiamare la funzione solo dopo che
-l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
+asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
+associate. É per questo motivo che occorre chiamare la funzione solo dopo che
+l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
precedente il completamento delle operazioni darebbe risultati indeterminati.
La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
-così come ricavato dalla sottostante system call (il numero di byte letti,
-scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre
+così come ricavato dalla sottostante system call (il numero di byte letti,
+scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre
questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
asincrono non verrebbero liberate, rischiando di arrivare ad un loro
esaurimento.
disposizione un'altra operazione, quella di sincronizzazione dell'I/O,
compiuta dalla funzione \funcd{aio\_fsync}, che ha lo stesso effetto della
analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
-è:
+è:
\begin{prototype}{aio.h}
{int aio\_fsync(int op, struct aiocb *aiocbp)}
Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, che può essere, con le stesse modalità di \func{aio\_read},
+ errore, che può essere, con le stesse modalità di \func{aio\_read},
\errval{EAGAIN}, \errval{EBADF} o \errval{EINVAL}.}
\end{prototype}
La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
-immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
+immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
di lettura e scrittura. L'argomento \param{op} permette di indicare la
-modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
+modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
operazioni saranno completate con una chiamata a \func{fdatasync}, se si
specifica \const{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
sez.~\ref{sec:file_sync}).
Il successo della chiamata assicura la sincronizzazione delle operazioni fino
-allora richieste, niente è garantito riguardo la sincronizzazione dei dati
-relativi ad eventuali operazioni richieste successivamente. Se si è
-specificato un meccanismo di notifica questo sarà innescato una volta che le
+allora richieste, niente è garantito riguardo la sincronizzazione dei dati
+relativi ad eventuali operazioni richieste successivamente. Se si è
+specificato un meccanismo di notifica questo sarà innescato una volta che le
operazioni di sincronizzazione dei dati saranno completate.
-In alcuni casi può essere necessario interrompere le operazioni (in genere
+In alcuni casi può essere necessario interrompere le operazioni (in genere
quando viene richiesta un'uscita immediata dal programma), per questo lo
standard POSIX.1b prevede una funzione apposita, \funcd{aio\_cancel}, che
permette di cancellare una operazione richiesta in precedenza; il suo
-prototipo è:
+prototipo è:
\begin{prototype}{aio.h}
{int aio\_cancel(int fildes, struct aiocb *aiocbp)}
La funzione permette di cancellare una operazione specifica sul file
\param{fildes}, o tutte le operazioni pendenti, specificando \val{NULL} come
valore di \param{aiocbp}. Quando una operazione viene cancellata una
-successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
-codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
-di notifica non verrà invocato. Se si specifica una operazione relativa ad un
-altro file descriptor il risultato è indeterminato. In caso di successo, i
+successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
+codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
+di notifica non verrà invocato. Se si specifica una operazione relativa ad un
+altro file descriptor il risultato è indeterminato. In caso di successo, i
possibili valori di ritorno per \func{aio\_cancel} (anch'essi definiti in
\file{aio.h}) sono tre:
\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
- cancellazione sono state già completate,
+\item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
+ cancellazione sono state già completate,
\item[\const{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
state cancellate,
corso e non sono state cancellate.
\end{basedescript}
-Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
+Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
\func{aio\_error} per determinare quali sono le operazioni effettivamente
cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
del loro avvenuto completamento.
-Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
+Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
fornisce anche una apposita funzione, \funcd{aio\_suspend}, che permette di
sospendere l'esecuzione del processo chiamante fino al completamento di una
-specifica operazione; il suo prototipo è:
+specifica operazione; il suo prototipo è:
\begin{prototype}{aio.h}
{int aio\_suspend(const struct aiocb * const list[], int nent, const struct
timespec *timeout)}
Attende, per un massimo di \param{timeout}, il completamento di una delle
operazioni specificate da \param{list}.
- \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
- completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
+ \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
+ completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
+ \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
\param{timeout}.
- \item[\errcode{ENOSYS}] la funzione non è implementata.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{ENOSYS}] la funzione non è implementata.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
}
\end{prototype}
La funzione permette di bloccare il processo fintanto che almeno una delle
-\param{nent} operazioni specificate nella lista \param{list} è completata, per
+\param{nent} operazioni specificate nella lista \param{list} è completata, per
un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
-segnale.\footnote{si tenga conto che questo segnale può anche essere quello
+segnale.\footnote{si tenga conto che questo segnale può anche essere quello
utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
con delle strutture \struct{aiocb} relative ad operazioni effettivamente
-richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
-siano specificati valori non validi l'effetto è indefinito. Un valore
+richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
+siano specificati valori non validi l'effetto è indefinito. Un valore
\val{NULL} per \param{timout} comporta l'assenza di timeout.
Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{lio\_listio},
che permette di effettuare la richiesta di una intera lista di operazioni di
-lettura o scrittura; il suo prototipo è:
+lettura o scrittura; il suo prototipo è:
\begin{prototype}{aio.h}
{int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
sigevent *sig)}
Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
- secondo la modalità \param{mode}.
+ secondo la modalità \param{mode}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
+ \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
\param{timeout}.
- \item[\errcode{EINVAL}] si è passato un valore di \param{mode} non valido
+ \item[\errcode{EINVAL}] si è passato un valore di \param{mode} non valido
o un numero di operazioni \param{nent} maggiore di
\const{AIO\_LISTIO\_MAX}.
- \item[\errcode{ENOSYS}] la funzione non è implementata.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{ENOSYS}] la funzione non è implementata.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
}
\end{prototype}
La funzione esegue la richiesta delle \param{nent} operazioni indicate nella
lista \param{list} che deve contenere gli indirizzi di altrettanti
-\textit{control block} opportunamente inizializzati; in particolare dovrà
+\textit{control block} opportunamente inizializzati; in particolare dovrà
essere specificato il tipo di operazione con il campo \var{aio\_lio\_opcode},
-che può prendere i valori:
+che può prendere i valori:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{LIO\_READ}] si richiede una operazione di lettura.
\item[\const{LIO\_WRITE}] si richiede una operazione di scrittura.
usato il valore \const{LIO\_WAIT} la funzione si blocca fino al completamento
di tutte le operazioni richieste; se si usa \const{LIO\_NOWAIT} la funzione
ritorna immediatamente dopo aver messo in coda tutte le richieste. In tal caso
-il chiamante può richiedere la notifica del completamento di tutte le
+il chiamante può richiedere la notifica del completamento di tutte le
richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa
per il campo \var{aio\_sigevent} di \struct{aiocb}.
-\section{Altre modalità di I/O avanzato}
+\section{Altre modalità di I/O avanzato}
\label{sec:file_advanced_io}
-Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
- asincrono}, esistono altre funzioni che implementano delle modalità di
-accesso ai file più evolute rispetto alle normali funzioni di lettura e
+Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
+ asincrono}, esistono altre funzioni che implementano delle modalità di
+accesso ai file più evolute rispetto alle normali funzioni di lettura e
scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in
memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O avanzato.
\label{sec:file_memory_map}
\itindbeg{memory~mapping}
-Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
-rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
+Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
+rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
\textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
\label{fig:file_mmap_layout}
\end{figure}
-Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
+Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
file viene \textsl{mappata} direttamente nello spazio degli indirizzi del
programma. Tutte le operazioni di lettura e scrittura su variabili contenute
in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto
del file attraverso il sistema della memoria virtuale \index{memoria~virtuale}
che in maniera analoga a quanto avviene per le pagine che vengono salvate e
-rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
+rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
segmento di memoria con quello del file mappato su di esso. Per questo motivo
-si può parlare tanto di \textsl{file mappato in memoria}, quanto di
+si può parlare tanto di \textsl{file mappato in memoria}, quanto di
\textsl{memoria mappata su file}.
L'uso del \textit{memory-mapping} comporta una notevole semplificazione delle
-operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
-intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
+operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
+intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
acceduti direttamente nella sezione di memoria mappata; inoltre questa
-interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
+interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
di caricare in memoria solo le parti del file che sono effettivamente usate ad
un dato istante.
-Infatti, dato che l'accesso è fatto direttamente attraverso la
+Infatti, dato che l'accesso è fatto direttamente attraverso la
\index{memoria~virtuale} memoria virtuale, la sezione di memoria mappata su
-cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e
+cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e
solo per le parti effettivamente usate, il tutto in maniera completamente
-trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
+trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
allo stesso modo con cui vengono caricate in memoria le pagine che sono state
salvate sullo swap.
-Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
-vengono salvate automaticamente, così come le pagine dei programmi vengono
+Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
+vengono salvate automaticamente, così come le pagine dei programmi vengono
scritte sulla swap; questo consente di accedere ai file su dimensioni il cui
-solo limite è quello dello spazio di indirizzi disponibile, e non della
+solo limite è quello dello spazio di indirizzi disponibile, e non della
memoria su cui possono esserne lette delle porzioni.
L'interfaccia POSIX implementata da Linux prevede varie funzioni per la
gestione del \textit{memory mapped I/O}, la prima di queste, che serve ad
-eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
-è:
+eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
+è:
\begin{functions}
\headdecl{unistd.h}
\bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
in caso di successo, e \const{MAP\_FAILED} (-1) in caso di errore, nel
- qual caso \var{errno} assumerà uno dei valori:
+ qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] il file descriptor non è valido, e non si è usato
+ \item[\errcode{EBADF}] il file descriptor non è valido, e non si è usato
\const{MAP\_ANONYMOUS}.
\item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare,
- o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
- o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
- \param{fd} non è aperto in lettura/scrittura, o si è impostato
- \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
+ o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
+ o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
+ \param{fd} non è aperto in lettura/scrittura, o si è impostato
+ \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
\item[\errcode{EINVAL}] i valori di \param{start}, \param{length} o
\param{offset} non sono validi (o troppo grandi o non allineati sulla
dimensione delle pagine).
- \item[\errcode{ETXTBSY}] si è impostato \const{MAP\_DENYWRITE} ma
- \param{fd} è aperto in scrittura.
- \item[\errcode{EAGAIN}] il file è bloccato, o si è bloccata troppa memoria
+ \item[\errcode{ETXTBSY}] si è impostato \const{MAP\_DENYWRITE} ma
+ \param{fd} è aperto in scrittura.
+ \item[\errcode{EAGAIN}] il file è bloccato, o si è bloccata troppa memoria
rispetto a quanto consentito dai limiti di sistema (vedi
sez.~\ref{sec:sys_resource_limit}).
- \item[\errcode{ENOMEM}] non c'è memoria o si è superato il limite sul
+ \item[\errcode{ENOMEM}] non c'è memoria o si è superato il limite sul
numero di mappature possibili.
\item[\errcode{ENODEV}] il filesystem di \param{fd} non supporta il memory
mapping.
\item[\errcode{EPERM}] l'argomento \param{prot} ha richiesto
- \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
+ \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
l'opzione \texttt{noexec}.
- \item[\errcode{ENFILE}] si è superato il limite del sistema sul numero di
+ \item[\errcode{ENFILE}] si è superato il limite del sistema sul numero di
file aperti (vedi sez.~\ref{sec:sys_resource_limit}).
\end{errlist}
}
\const{PROT\_EXEC} & Le pagine possono essere eseguite.\\
\const{PROT\_READ} & Le pagine possono essere lette.\\
\const{PROT\_WRITE} & Le pagine possono essere scritte.\\
- \const{PROT\_NONE} & L'accesso alle pagine è vietato.\\
+ \const{PROT\_NONE} & L'accesso alle pagine è vietato.\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
\end{table}
Il valore dell'argomento \param{prot} indica la protezione\footnote{come
- accennato in sez.~\ref{sec:proc_memory} in Linux la memoria reale è divisa
- in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti
+ accennato in sez.~\ref{sec:proc_memory} in Linux la memoria reale è divisa
+ in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti
lineari di memoria virtuale. Per ciascuno di questi segmenti il kernel
mantiene nella \itindex{page~table} \textit{page table} la mappatura sulle
- pagine di memoria reale, ed le modalità di accesso (lettura, esecuzione,
+ pagine di memoria reale, ed le modalità di accesso (lettura, esecuzione,
scrittura); una loro violazione causa quella una \itindex{segment~violation}
\textit{segment violation}, e la relativa emissione del segnale
\const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
-specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
+specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
riportati in tab.~\ref{tab:file_mmap_prot}; il valore specificato deve essere
-compatibile con la modalità di accesso con cui si è aperto il file.
+compatibile con la modalità di accesso con cui si è aperto il file.
-L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
-le opzioni relative alle modalità con cui è effettuata la mappatura e alle
-modalità con cui le modifiche alla memoria mappata vengono condivise o
+L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
+le opzioni relative alle modalità con cui è effettuata la mappatura e alle
+modalità con cui le modifiche alla memoria mappata vengono condivise o
mantenute private al processo che le ha effettuate. Deve essere specificato
-come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
+come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
tab.~\ref{tab:file_mmap_flag}.
\begin{table}[htb]
\hline
\hline
\const{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
- da \param{start}, se questo non può essere usato
+ da \param{start}, se questo non può essere usato
\func{mmap} fallisce. Se si imposta questo flag il
valore di \param{start} deve essere allineato
alle dimensioni di una pagina.\\
\const{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
riportati sul file e saranno immediatamente
visibili agli altri processi che mappano lo stesso
- file.\footnotemark Il file su disco però non sarà
+ file.\footnotemark Il file su disco però non sarà
aggiornato fino alla chiamata di \func{msync} o
\func{munmap}), e solo allora le modifiche saranno
visibili per l'I/O convenzionale. Incompatibile
accesso. Le modifiche sono mantenute attraverso
il meccanismo del \textit{copy on
write} \itindex{copy~on~write} e
- salvate su swap in caso di necessità. Non è
+ salvate su swap in caso di necessità. Non è
specificato se i cambiamenti sul file originale
vengano riportati sulla regione
mappata. Incompatibile con \const{MAP\_SHARED}.\\
\textit{copy on write} \itindex{copy~on~write}
per mantenere le
modifiche fatte alla regione mappata, in
- questo caso dopo una scrittura, se non c'è più
+ questo caso dopo una scrittura, se non c'è più
memoria disponibile, si ha l'emissione di
un \const{SIGSEGV}.\\
\const{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine
\const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} \textit{stack}.
Indica che la mappatura deve essere effettuata
con gli indirizzi crescenti verso il basso.\\
- \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
+ \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
argomenti \param{fd} e \param{offset} sono
ignorati.\footnotemark\\
\const{MAP\_ANON} & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
- \const{MAP\_FILE} & Valore di compatibilità, ignorato.\\
+ \const{MAP\_FILE} & Valore di compatibilità, ignorato.\\
\const{MAP\_32BIT} & Esegue la mappatura sui primi 2Gb dello spazio
degli indirizzi, viene supportato solo sulle
- piattaforme \texttt{x86-64} per compatibilità con
- le applicazioni a 32 bit. Viene ignorato se si è
+ piattaforme \texttt{x86-64} per compatibilità con
+ le applicazioni a 32 bit. Viene ignorato se si è
richiesto \const{MAP\_FIXED}.\\
\const{MAP\_POPULATE} & Esegue il \itindex{prefaulting}
\textit{prefaulting} delle pagine di memoria
necessarie alla mappatura.\\
- \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che
+ \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che
non causa I/O.\footnotemark\\
% \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area
% mappata con \func{mremap}, proposto ma pare non
\footnotetext[68]{dato che tutti faranno riferimento alle stesse pagine di
memoria.}
-\footnotetext[69]{l'uso di questo flag con \const{MAP\_SHARED} è stato
+\footnotetext[69]{l'uso di questo flag con \const{MAP\_SHARED} è stato
implementato in Linux a partire dai kernel della serie 2.4.x; esso consente
di creare segmenti di memoria condivisa e torneremo sul suo utilizzo in
sez.~\ref{sec:ipc_mmap_anonymous}.}
\footnotetext{questo flag ed il precedente \const{MAP\_POPULATE} sono stati
introdotti nel kernel 2.5.46 insieme alla mappatura non lineare di cui
- parleremo più avanti.}
+ parleremo più avanti.}
Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
piuttosto complessi, essi si possono comprendere solo tenendo presente che
-tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
-memoria virtuale. Questo comporta allora una serie di conseguenze. La più
-ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
-avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
+tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
+memoria virtuale. Questo comporta allora una serie di conseguenze. La più
+ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
+avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
dato che i permessi sul segmento di memoria relativo non consentono questo
tipo di accesso.
-È invece assai diversa la questione relativa agli accessi al di fuori della
-regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
+È invece assai diversa la questione relativa agli accessi al di fuori della
+regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
ritenere che anch'essi debbano generare un segnale di violazione di accesso;
-questo però non tiene conto del fatto che, essendo basata sul meccanismo della
-\index{paginazione} paginazione, la mappatura in memoria non può che essere
+questo però non tiene conto del fatto che, essendo basata sul meccanismo della
+\index{paginazione} paginazione, la mappatura in memoria non può che essere
eseguita su un segmento di dimensioni rigorosamente multiple di quelle di una
pagina, ed in generale queste potranno non corrispondere alle dimensioni
effettive del file o della sezione che si vuole mappare.
\label{fig:file_mmap_boundary}
\end{figure}
-Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
+Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
in cui la sezione di file non rientra nei confini di una pagina: in tal caso
-verrà il file sarà mappato su un segmento di memoria che si estende fino al
+verrà il file sarà mappato su un segmento di memoria che si estende fino al
bordo della pagina successiva.
-In questo caso è possibile accedere a quella zona di memoria che eccede le
+In questo caso è possibile accedere a quella zona di memoria che eccede le
dimensioni specificate da \param{length}, senza ottenere un \const{SIGSEGV}
-poiché essa è presente nello spazio di indirizzi del processo, anche se non è
-mappata sul file. Il comportamento del sistema è quello di restituire un
+poiché essa è presente nello spazio di indirizzi del processo, anche se non è
+mappata sul file. Il comportamento del sistema è quello di restituire un
valore nullo per quanto viene letto, e di non riportare su file quanto viene
scritto.
-Un caso più complesso è quello che si viene a creare quando le dimensioni del
-file mappato sono più corte delle dimensioni della mappatura, oppure quando il
-file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
+Un caso più complesso è quello che si viene a creare quando le dimensioni del
+file mappato sono più corte delle dimensioni della mappatura, oppure quando il
+file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
quella della mappatura in memoria.
In questa situazione, per la sezione di pagina parzialmente coperta dal
contenuto del file, vale esattamente quanto visto in precedenza; invece per la
parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
-sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
+sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
\const{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
Non tutti i file possono venire mappati in memoria, dato che, come illustrato
in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
biunivoca fra una sezione di un file ed una sezione di memoria. Questo
-comporta che ad esempio non è possibile mappare in memoria file descriptor
+comporta che ad esempio non è possibile mappare in memoria file descriptor
relativi a pipe, socket e fifo, per i quali non ha senso parlare di
\textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
dispongono della relativa operazione \func{mmap} (si ricordi quanto esposto in
-sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
-di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
+sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
+di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
che sono utilizzabili solo con questa interfaccia.
\begin{figure}[htb]
Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
copiato integralmente, i file mappati in memoria verranno ereditati in maniera
trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
-padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
-stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
-ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
+padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
+stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
+ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
nuovo programma.
Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
-esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
-valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
-dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
+esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
+valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
+dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
una pagina mappata su un file aggiorna questo tempo. I valori di
-\var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
-consentita la scrittura sul file (cioè per un file mappato con
+\var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
+consentita la scrittura sul file (cioè per un file mappato con
\const{PROT\_WRITE} e \const{MAP\_SHARED}) e sono aggiornati dopo la scrittura
o in corrispondenza di una eventuale \func{msync}.
direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere
consapevoli delle interazioni che possono esserci con operazioni effettuate
con l'interfaccia standard dei file di cap.~\ref{cha:file_unix_interface}. Il
-problema è che una volta che si è mappato un file, le operazioni di lettura e
+problema è che una volta che si è mappato un file, le operazioni di lettura e
scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
autonoma dal sistema della memoria virtuale.
Pertanto se si modifica un file con l'interfaccia standard queste modifiche
potranno essere visibili o meno a seconda del momento in cui la memoria
-virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
+virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
del tutto imprevedibile il risultato della modifica di un file nei confronti
-del contenuto della memoria su cui è mappato.
+del contenuto della memoria su cui è mappato.
-Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
-l'interfaccia standard quando lo si è mappato in memoria, è invece possibile
-usare l'interfaccia standard per leggere un file mappato in memoria, purché si
+Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
+l'interfaccia standard quando lo si è mappato in memoria, è invece possibile
+usare l'interfaccia standard per leggere un file mappato in memoria, purché si
abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette
a disposizione la funzione \funcd{msync} per sincronizzare il contenuto della
-memoria mappata con il file su disco; il suo prototipo è:
+memoria mappata con il file su disco; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
Sincronizza i contenuti di una sezione di un file mappato in memoria.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore nel qual caso \var{errno} assumerà uno dei valori:
+ errore nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] o \param{start} non è multiplo di
- \const{PAGE\_SIZE}, o si è specificato un valore non valido per
+ \item[\errcode{EINVAL}] o \param{start} non è multiplo di
+ \const{PAGE\_SIZE}, o si è specificato un valore non valido per
\param{flags}.
\item[\errcode{EFAULT}] l'intervallo specificato non ricade in una zona
precedentemente mappata.
La funzione esegue la sincronizzazione di quanto scritto nella sezione di
memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
-file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
-relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
+file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
+relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
del file aggiornato.
\hline
\hline
\const{MS\_SYNC} & richiede una sincronizzazione e ritorna soltanto
- quando questa è stata completata.\\
+ quando questa è stata completata.\\
\const{MS\_ASYNC} & richiede una sincronizzazione, ma ritorna subito
non attendendo che questa sia finita.\\
\const{MS\_INVALIDATE} & invalida le pagine per tutte le mappature
- in memoria così da rendere necessaria una
+ in memoria così da rendere necessaria una
rilettura immediata delle stesse.\\
\hline
\end{tabular}
\label{tab:file_mmap_msync}
\end{table}
-L'argomento \param{flag} è specificato come maschera binaria composta da un OR
-dei valori riportati in tab.~\ref{tab:file_mmap_msync}, di questi però
+L'argomento \param{flag} è specificato come maschera binaria composta da un OR
+dei valori riportati in tab.~\ref{tab:file_mmap_msync}, di questi però
\const{MS\_ASYNC} e \const{MS\_SYNC} sono incompatibili; con il primo valore
infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
-flag fa sì che vengano invalidate, per tutte le mappature dello stesso file,
-le pagine di cui si è richiesta la sincronizzazione, così che esse possano
+flag fa sì che vengano invalidate, per tutte le mappature dello stesso file,
+le pagine di cui si è richiesta la sincronizzazione, così che esse possano
essere immediatamente aggiornate con i nuovi valori.
-Una volta che si sono completate le operazioni di I/O si può eliminare la
-mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
+Una volta che si sono completate le operazioni di I/O si può eliminare la
+mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
Rilascia la mappatura sulla sezione di memoria specificata.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore nel qual caso \var{errno} assumerà uno dei valori:
+ errore nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] l'intervallo specificato non ricade in una zona
precedentemente mappata.
\end{functions}
La funzione cancella la mappatura per l'intervallo specificato con
-\param{start} e \param{length}; ogni successivo accesso a tale regione causerà
+\param{start} e \param{length}; ogni successivo accesso a tale regione causerà
un errore di accesso in memoria. L'argomento \param{start} deve essere
allineato alle dimensioni di una pagina, e la mappatura di tutte le pagine
-contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
-Indicare un intervallo che non contiene mappature non è un errore. Si tenga
-presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
+contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
+Indicare un intervallo che non contiene mappature non è un errore. Si tenga
+presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
automaticamente rilasciata, mentre la chiusura del file descriptor usato per
il \textit{memory mapping} non ha alcun effetto su di esso.
Lo standard POSIX prevede anche una funzione che permetta di cambiare le
protezioni delle pagine di memoria; lo standard prevede che essa si applichi
solo ai \textit{memory mapping} creati con \func{mmap}, ma nel caso di Linux
-la funzione può essere usata con qualunque pagina valida nella memoria
-virtuale. Questa funzione è \funcd{mprotect} ed il suo prototipo è:
+la funzione può essere usata con qualunque pagina valida nella memoria
+virtuale. Questa funzione è \funcd{mprotect} ed il suo prototipo è:
\begin{functions}
% \headdecl{unistd.h}
\headdecl{sys/mman.h}
specificato.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore nel qual caso \var{errno} assumerà uno dei valori:
+ errore nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
+ \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
multiplo di \const{PAGE\_SIZE}.
- \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
+ \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
cercato di marcare con \const{PROT\_WRITE} un segmento di memoria cui si
ha solo accesso in lettura.
-% \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
+% \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
% necessarie all'interno del kernel.
-% \item[\errcode{EFAULT}] si è specificato un indirizzo di memoria non
+% \item[\errcode{EFAULT}] si è specificato un indirizzo di memoria non
% accessibile.
\end{errlist}
ed inoltre \errval{ENOMEM} ed \errval{EFAULT}.
allineato alle dimensioni delle pagine di memoria, ed una dimensione
\param{size}. La nuova protezione deve essere specificata in \param{prot} con
una combinazione dei valori di tab.~\ref{tab:file_mmap_prot}. La nuova
-protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
+protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
dall'intervallo fra \param{addr} e \param{addr}+\param{size}-1.
Infine Linux supporta alcune operazioni specifiche non disponibili su altri
-kernel unix-like. La prima di queste è la possibilità di modificare un
+kernel unix-like. La prima di queste è la possibilità di modificare un
precedente \textit{memory mapping}, ad esempio per espanderlo o restringerlo.
-Questo è realizzato dalla funzione \funcd{mremap}, il cui prototipo è:
+Questo è realizzato dalla funzione \funcd{mremap}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
\bodydesc{La funzione restituisce l'indirizzo alla nuova area di memoria in
caso di successo od il valore \const{MAP\_FAILED} (pari a \texttt{(void *)
- -1}) in caso di errore, nel qual caso \var{errno} assumerà uno dei
+ -1}) in caso di errore, nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
+ \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
puntatore valido.
\item[\errcode{EFAULT}] ci sono indirizzi non validi nell'intervallo
specificato da \param{old\_address} e \param{old\_size}, o ci sono altre
mappature di tipo non corrispondente a quella richiesta.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
- memoria non può essere espansa all'indirizzo virtuale corrente, e non si
- è specificato \const{MREMAP\_MAYMOVE} nei flag.
- \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
+ memoria non può essere espansa all'indirizzo virtuale corrente, e non si
+ è specificato \const{MREMAP\_MAYMOVE} nei flag.
+ \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
essere rimappato.
\end{errlist}
}
allineato alle dimensioni di una pagina di memoria) che specifica il
precedente indirizzo del \textit{memory mapping} e \param{old\_size}, che ne
indica la dimensione. Con \param{new\_size} si specifica invece la nuova
-dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
+dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
maschera binaria per i flag che controllano il comportamento della funzione.
-Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
+Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
utilizzare questa costante occorre aver definito \macro{\_GNU\_SOURCE} prima
di includere \file{sys/mman.h}.} che consente di eseguire l'espansione
-anche quando non è possibile utilizzare il precedente indirizzo. Per questo
-motivo, se si è usato questo flag, la funzione può restituire un indirizzo
-della nuova zona di memoria che non è detto coincida con \param{old\_address}.
+anche quando non è possibile utilizzare il precedente indirizzo. Per questo
+motivo, se si è usato questo flag, la funzione può restituire un indirizzo
+della nuova zona di memoria che non è detto coincida con \param{old\_address}.
La funzione si appoggia al sistema della \index{memoria~virtuale} memoria
virtuale per modificare l'associazione fra gli indirizzi virtuali del processo
e le pagine di memoria, modificando i dati direttamente nella
\itindex{page~table} \textit{page table} del processo. Come per
-\func{mprotect} la funzione può essere usata in generale, anche per pagine di
-memoria non corrispondenti ad un \textit{memory mapping}, e consente così di
+\func{mprotect} la funzione può essere usata in generale, anche per pagine di
+memoria non corrispondenti ad un \textit{memory mapping}, e consente così di
implementare la funzione \func{realloc} in maniera molto efficiente.
-Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
-memoria di un file viene eseguita in maniera lineare, cioè parti successive di
+Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
+memoria di un file viene eseguita in maniera lineare, cioè parti successive di
un file vengono mappate linearmente su indirizzi successivi in memoria.
-Esistono però delle applicazioni\footnote{in particolare la tecnica è usata
- dai database o dai programmi che realizzano macchine virtuali.} in cui è
+Esistono però delle applicazioni\footnote{in particolare la tecnica è usata
+ dai database o dai programmi che realizzano macchine virtuali.} in cui è
utile poter mappare sezioni diverse di un file su diverse zone di memoria.
-Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
+Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
\func{mmap} per ciascuna delle diverse aree del file che si vogliono mappare
-in sequenza non lineare,\footnote{ed in effetti è quello che veniva fatto
+in sequenza non lineare,\footnote{ed in effetti è quello che veniva fatto
anche con Linux prima che fossero introdotte queste estensioni.} ma questo
approccio ha delle conseguenze molto pesanti in termini di prestazioni.
Infatti per ciascuna mappatura in memoria deve essere definita nella
questa diventi visibile nello spazio degli indirizzi come illustrato in
fig.~\ref{fig:file_mmap_layout}.
-Quando un processo esegue un gran numero di mappature diverse\footnote{si può
+Quando un processo esegue un gran numero di mappature diverse\footnote{si può
arrivare anche a centinaia di migliaia.} per realizzare a mano una mappatura
-non-lineare si avrà un accrescimento eccessivo della sua \itindex{page~table}
-\textit{page table}, e lo stesso accadrà per tutti gli altri processi che
+non-lineare si avrà un accrescimento eccessivo della sua \itindex{page~table}
+\textit{page table}, e lo stesso accadrà per tutti gli altri processi che
utilizzano questa tecnica. In situazioni in cui le applicazioni hanno queste
-esigenze si avranno delle prestazioni ridotte, dato che il kernel dovrà
+esigenze si avranno delle prestazioni ridotte, dato che il kernel dovrà
impiegare molte risorse\footnote{sia in termini di memoria interna per i dati
delle \itindex{page~table} \textit{page table}, che di CPU per il loro
- aggiornamento.} solo per mantenere i dati di una gran quantità di
+ aggiornamento.} solo per mantenere i dati di una gran quantità di
\textit{memory mapping}.
-Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
-Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
+Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
+Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
una caratteristica specifica di Linux, non presente in altri sistemi
-unix-like. Diventa così possibile utilizzare una sola mappatura
+unix-like. Diventa così possibile utilizzare una sola mappatura
iniziale\footnote{e quindi una sola \textit{virtual memory area} nella
\itindex{page~table} \textit{page table} del processo.} e poi rimappare a
-piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
-nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
+piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
+nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
\begin{functions}
\headdecl{sys/mman.h}
Permette di rimappare non linearmente un precedente \textit{memory mapping}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è usato un valore non valido per uno degli
+ \item[\errcode{EINVAL}] si è usato un valore non valido per uno degli
argomenti o \param{start} non fa riferimento ad un \textit{memory
mapping} valido creato con \const{MAP\_SHARED}.
\end{errlist}
Per poter utilizzare questa funzione occorre anzitutto effettuare
preliminarmente una chiamata a \func{mmap} con \const{MAP\_SHARED} per
-definire l'area di memoria che poi sarà rimappata non linearmente. Poi di
-chiamerà questa funzione per modificare le corrispondenze fra pagine di
+definire l'area di memoria che poi sarà rimappata non linearmente. Poi di
+chiamerà questa funzione per modificare le corrispondenze fra pagine di
memoria e pagine del file; si tenga presente che \func{remap\_file\_pages}
-permette anche di mappare la stessa pagina di un file in più pagine della
+permette anche di mappare la stessa pagina di un file in più pagine della
regione mappata.
La funzione richiede che si identifichi la sezione del file che si vuole
riposizionare all'interno del \textit{memory mapping} con gli argomenti
\param{pgoff} e \param{size}; l'argomento \param{start} invece deve indicare
un indirizzo all'interno dell'area definita dall'\func{mmap} iniziale, a
-partire dal quale la sezione di file indicata verrà rimappata. L'argomento
+partire dal quale la sezione di file indicata verrà rimappata. L'argomento
\param{prot} deve essere sempre nullo, mentre \param{flags} prende gli stessi
valori di \func{mmap} (quelli di tab.~\ref{tab:file_mmap_prot}) ma di tutti i
flag solo \const{MAP\_NONBLOCK} non viene ignorato.
Il problema si pone tutte le volte che si vuole mappare in memoria un file di
grosse dimensioni. Il comportamento normale del sistema della
-\index{memoria~virtuale} memoria virtuale è quello per cui la regione mappata
+\index{memoria~virtuale} memoria virtuale è quello per cui la regione mappata
viene aggiunta alla \itindex{page~table} \textit{page table} del processo, ma
-i dati verranno effettivamente utilizzati (si avrà cioè un
+i dati verranno effettivamente utilizzati (si avrà cioè un
\itindex{page~fault} \textit{page fault} che li trasferisce dal disco alla
memoria) soltanto in corrispondenza dell'accesso a ciascuna delle pagine
interessate dal \textit{memory mapping}.
-Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
+Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
pagina alla volta con un gran numero di \itindex{page~fault} \textit{page
- fault}, chiaramente se si sa in anticipo che il file verrà utilizzato
-immediatamente, è molto più efficiente eseguire un \itindex{prefaulting}
+ fault}, chiaramente se si sa in anticipo che il file verrà utilizzato
+immediatamente, è molto più efficiente eseguire un \itindex{prefaulting}
\textit{prefaulting} in cui tutte le pagine di memoria interessate alla
mappatura vengono ``\textsl{popolate}'' in una sola volta, questo
comportamento viene abilitato quando si usa con \func{mmap} il flag
\const{MAP\_POPULATE}.
-Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
-rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
+Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
+rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
flag, \const{MAP\_NONBLOCK}, che esegue un \itindex{prefaulting}
-\textit{prefaulting} più limitato in cui vengono popolate solo le pagine della
-mappatura che già si trovano nella cache del kernel.\footnote{questo può
+\textit{prefaulting} più limitato in cui vengono popolate solo le pagine della
+mappatura che già si trovano nella cache del kernel.\footnote{questo può
essere utile per il linker dinamico, in particolare quando viene effettuato
il \textit{prelink} delle applicazioni.}
Per i vantaggi illustrati all'inizio del paragrafo l'interfaccia del
-\textit{memory mapped I/O} viene usata da una grande varietà di programmi,
-spesso con esigenze molto diverse fra di loro riguardo le modalità con cui
-verranno eseguiti gli accessi ad un file; è ad esempio molto comune per i
-database effettuare accessi ai dati in maniera pressoché casuale, mentre un
-riproduttore audio o video eseguirà per lo più letture sequenziali.
+\textit{memory mapped I/O} viene usata da una grande varietà di programmi,
+spesso con esigenze molto diverse fra di loro riguardo le modalità con cui
+verranno eseguiti gli accessi ad un file; è ad esempio molto comune per i
+database effettuare accessi ai dati in maniera pressoché casuale, mentre un
+riproduttore audio o video eseguirà per lo più letture sequenziali.
-Per migliorare le prestazioni a seconda di queste modalità di accesso è
+Per migliorare le prestazioni a seconda di queste modalità di accesso è
disponibile una apposita funzione, \funcd{madvise},\footnote{tratteremo in
sez.~\ref{sec:file_fadvise} le funzioni che consentono di ottimizzare
l'accesso ai file con l'interfaccia classica.} che consente di fornire al
-kernel delle indicazioni su dette modalità, così che possano essere adottate
-le opportune strategie di ottimizzazione. Il suo prototipo è:
+kernel delle indicazioni su dette modalità, così che possano essere adottate
+le opportune strategie di ottimizzazione. Il suo prototipo è:
\begin{functions}
\headdecl{sys/mman.h}
Fornisce indicazioni sull'uso previsto di un \textit{memory mapping}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}] la mappatura esiste ma non corrisponde ad un file.
- \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
- una pagina, \param{length} ha un valore negativo, o \param{advice} non è
- un valore valido, o si è richiesto il rilascio (con
+ \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
+ una pagina, \param{length} ha un valore negativo, o \param{advice} non è
+ un valore valido, o si è richiesto il rilascio (con
\const{MADV\_DONTNEED}) di pagine bloccate o condivise.
\item[\errcode{EIO}] la paginazione richiesta eccederebbe i limiti (vedi
sez.~\ref{sec:sys_resource_limit}) sulle pagine residenti in memoria del
processo (solo in caso di \const{MADV\_WILLNEED}).
\item[\errcode{ENOMEM}] gli indirizzi specificati non sono mappati, o, in
- caso \const{MADV\_WILLNEED}, non c'è sufficiente memoria per soddisfare
+ caso \const{MADV\_WILLNEED}, non c'è sufficiente memoria per soddisfare
la richiesta.
\end{errlist}
ed inoltre \errval{EAGAIN} e \errval{ENOSYS}.
\param{length}, il valore di \param{start} deve essere allineato,
mentre \param{length} deve essere un numero positivo.\footnote{la versione di
Linux consente anche un valore nullo per \param{length}, inoltre se una
- parte dell'intervallo non è mappato in memoria l'indicazione viene comunque
+ parte dell'intervallo non è mappato in memoria l'indicazione viene comunque
applicata alle restanti parti, anche se la funzione ritorna un errore di
\errval{ENOMEM}.} L'indicazione viene espressa dall'argomento \param{advice}
che deve essere specificato con uno dei valori\footnote{si tenga presente che
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{MADV\_NORMAL} & nessuna indicazione specifica, questo è il valore
- di default usato quando non si è chiamato
+ \const{MADV\_NORMAL} & nessuna indicazione specifica, questo è il valore
+ di default usato quando non si è chiamato
\func{madvise}.\\
\const{MADV\_RANDOM} & ci si aspetta un accesso casuale all'area
indicata, pertanto l'applicazione di una lettura
anticipata con il meccanismo del
\itindex{read-ahead} \textit{read-ahead} (vedi
- sez.~\ref{sec:file_fadvise}) è di
- scarsa utilità e verrà disabilitata.\\
+ sez.~\ref{sec:file_fadvise}) è di
+ scarsa utilità e verrà disabilitata.\\
\const{MADV\_SEQUENTIAL}& ci si aspetta un accesso sequenziale al file,
- quindi da una parte sarà opportuno eseguire una
+ quindi da una parte sarà opportuno eseguire una
lettura anticipata, e dall'altra si potranno
scartare immediatamente le pagine una volta che
queste siano state lette.\\
\const{MADV\_DONTNEED}& non ci si aspetta nessun accesso nell'immediato
futuro, pertanto le pagine possono essere
liberate dal kernel non appena necessario; l'area
- di memoria resterà accessibile, ma un accesso
- richiederà che i dati vengano ricaricati dal file
+ di memoria resterà accessibile, ma un accesso
+ richiederà che i dati vengano ricaricati dal file
a cui la mappatura fa riferimento.\\
\hline
\const{MADV\_REMOVE} & libera un intervallo di pagine di memoria ed il
- relativo supporto sottostante; è supportato
+ relativo supporto sottostante; è supportato
soltanto sui filesystem in RAM \textit{tmpfs} e
\textit{shmfs}.\footnotemark\\
\const{MADV\_DONTFORK}& impedisce che l'intervallo specificato venga
meccanismo del \itindex{copy~on~write}
\textit{copy on write} effettui la rilocazione
delle pagine quando il padre scrive sull'area
- di memoria dopo la \func{fork}, cosa che può
+ di memoria dopo la \func{fork}, cosa che può
causare problemi per l'hardware che esegue
operazioni in DMA su quelle pagine.\\
\const{MADV\_DOFORK} & rimuove l'effetto della precedente
\footnotetext{se usato su altri tipi di filesystem causa un errore di
\errcode{ENOSYS}.}
-\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
+\footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
identifica pagine di memoria identiche e le accorpa in una unica pagina
(soggetta al \textit{copy-on-write} per successive modifiche); per evitare
di controllare tutte le pagine solo quelle marcate con questo flag vengono
prese in considerazione per l'accorpamento; in questo modo si possono
migliorare le prestazioni nella gestione delle macchine virtuali diminuendo
- la loro occupazione di memoria, ma il meccanismo può essere usato anche in
+ la loro occupazione di memoria, ma il meccanismo può essere usato anche in
altre applicazioni in cui sian presenti numerosi processi che usano gli
stessi dati; per maggiori dettagli si veda
\href{http://kernelnewbies.org/Linux_2_6_32\#head-d3f32e41df508090810388a57efce73f52660ccb}{\texttt{http://kernelnewbies.org/Linux\_2\_6\_32}}.}
La funzione non ha, tranne il caso di \const{MADV\_DONTFORK}, nessun effetto
-sul comportamento di un programma, ma può influenzarne le prestazioni fornendo
-al kernel indicazioni sulle esigenze dello stesso, così che sia possibile
+sul comportamento di un programma, ma può influenzarne le prestazioni fornendo
+al kernel indicazioni sulle esigenze dello stesso, così che sia possibile
scegliere le opportune strategie per la gestione del \itindex{read-ahead}
\textit{read-ahead} e del caching dei dati. A differenza da quanto specificato
-nello standard POSIX.1b, per il quale l'uso di \func{madvise} è a scopo
+nello standard POSIX.1b, per il quale l'uso di \func{madvise} è a scopo
puramente indicativo, Linux considera queste richieste come imperative, per
cui ritorna un errore qualora non possa soddisfarle.\footnote{questo
comportamento differisce da quanto specificato nello standard.}
\subsection{I/O vettorizzato: \func{readv} e \func{writev}}
\label{sec:file_multiple_io}
-Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
+Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
serie multipla di operazioni di I/O, come una serie di letture o scritture di
-vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
-una struttura ed essi devono essere caricati o salvati su un file. Benché
+vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
+una struttura ed essi devono essere caricati o salvati su un file. Benché
l'operazione sia facilmente eseguibile attraverso una serie multipla di
chiamate a \func{read} e \func{write}, ci sono casi in cui si vuole poter
-contare sulla atomicità delle operazioni.
+contare sulla atomicità delle operazioni.
Per questo motivo fino da BSD 4.2 vennero introdotte delle nuove system call
che permettessero di effettuare con una sola chiamata una serie di letture o
\bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
- assumerà uno dei valori:
+ assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
- argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}).
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
+ argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}).
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
di avere eseguito una qualunque lettura o scrittura.
- \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
+ \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
non ci sono dati in lettura.
- \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
+ \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
\end{errlist}
ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT}
(se non sono stati allocati correttamente i buffer specificati nei campi
- \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
+ \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
scrittura eseguite su \param{fd}.}
\end{functions}
-Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
+Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono
-essere letti o scritti ed in che quantità. Il primo campo della struttura,
+essere letti o scritti ed in che quantità. Il primo campo della struttura,
\var{iov\_base}, contiene l'indirizzo del buffer ed il secondo,
\var{iov\_len}, la dimensione dello stesso.
\end{figure}
La lista dei buffer da utilizzare viene indicata attraverso l'argomento
-\param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
-è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux
+\param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
+è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux
usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta
- logica, che però è stata dismessa per restare aderenti allo standard
- POSIX.1-2001.} Ciascuna struttura dovrà essere inizializzata opportunamente
-per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento
+ logica, che però è stata dismessa per restare aderenti allo standard
+ POSIX.1-2001.} Ciascuna struttura dovrà essere inizializzata opportunamente
+per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento
dei dati. Essi verranno letti (o scritti) nell'ordine in cui li si sono
specificati nel vettore \param{vector}.
\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
sez.~\ref{sec:sys_sysconf}).
-Nel caso di Linux il limite di sistema è di 1024, però se si usano le
+Nel caso di Linux il limite di sistema è di 1024, però se si usano le
\acr{glibc} queste forniscono un \textit{wrapper} per le system call che si
-accorge se una operazione supererà il precedente limite, in tal caso i dati
+accorge se una operazione supererà il precedente limite, in tal caso i dati
verranno letti o scritti con le usuali \func{read} e \func{write} usando un
buffer di dimensioni sufficienti appositamente allocato e sufficiente a
-contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
-ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
+contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
+ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
Si tenga presente infine che queste funzioni operano sui file con
-l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
+l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
l'interfaccia classica dei \textit{file stream} di
cap.~\ref{cha:files_std_interface}; a causa delle bufferizzazioni interne di
quest'ultima infatti si potrebbero avere risultati indefiniti e non
\bodydesc{Le funzioni hanno gli stessi valori di ritorno delle
corrispondenti \func{readv} e \func{writev}; anche gli eventuali errori
- sono gli stessi già visti in precedenza, ma ad essi si possono aggiungere
+ sono gli stessi già visti in precedenza, ma ad essi si possono aggiungere
per \var{errno} anche i valori:
\begin{errlist}
- \item[\errcode{EOVERFLOW}] \param{offset} ha un valore che non può essere
+ \item[\errcode{EOVERFLOW}] \param{offset} ha un valore che non può essere
usato come \ctyp{off\_t}.
- \item[\errcode{ESPIPE}] \param{fd} è associato ad un socket o una pipe.
+ \item[\errcode{ESPIPE}] \param{fd} è associato ad un socket o una pipe.
\end{errlist}
}
\end{functions}
vettorizzata a partire dalla posizione \param{offset} sul file indicato
da \param{fd}, la posizione corrente sul file, come vista da eventuali altri
processi che vi facciano riferimento, non viene alterata. A parte la presenza
-dell'ulteriore argomento il comportamento delle funzioni è identico alle
+dell'ulteriore argomento il comportamento delle funzioni è identico alle
precedenti \func{readv} e \func{writev}.
Con l'uso di queste funzioni si possono evitare eventuali
\func{splice}}
\label{sec:file_sendfile_splice}
-Uno dei problemi che si presentano nella gestione dell'I/O è quello in cui si
-devono trasferire grandi quantità di dati da un file descriptor ed un altro;
+Uno dei problemi che si presentano nella gestione dell'I/O è quello in cui si
+devono trasferire grandi quantità di dati da un file descriptor ed un altro;
questo usualmente comporta la lettura dei dati dal primo file descriptor in un
buffer in memoria, da cui essi vengono poi scritti sul secondo.
-Benché il kernel ottimizzi la gestione di questo processo quando si ha a che
+Benché il kernel ottimizzi la gestione di questo processo quando si ha a che
fare con file normali, in generale quando i dati da trasferire sono molti si
-pone il problema di effettuare trasferimenti di grandi quantità di dati da
-kernel space a user space e all'indietro, quando in realtà potrebbe essere più
+pone il problema di effettuare trasferimenti di grandi quantità di dati da
+kernel space a user space e all'indietro, quando in realtà potrebbe essere più
efficiente mantenere tutto in kernel space. Tratteremo in questa sezione
alcune funzioni specialistiche che permettono di ottimizzare le prestazioni in
questo tipo di situazioni.
-La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
-fra due file descriptor è \func{sendfile};\footnote{la funzione è stata
+La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
+fra due file descriptor è \func{sendfile};\footnote{la funzione è stata
introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
- 2.1.} la funzione è presente in diverse versioni di Unix,\footnote{la si
- ritrova ad esempio in FreeBSD, HPUX ed altri Unix.} ma non è presente né in
-POSIX.1-2001 né in altri standard,\footnote{pertanto si eviti di utilizzarla
+ 2.1.} la funzione è presente in diverse versioni di Unix,\footnote{la si
+ ritrova ad esempio in FreeBSD, HPUX ed altri Unix.} ma non è presente né in
+POSIX.1-2001 né in altri standard,\footnote{pertanto si eviti di utilizzarla
se si devono scrivere programmi portabili.} per cui per essa vengono
utilizzati prototipi e semantiche differenti; nel caso di Linux il prototipo
-di \funcd{sendfile} è:
+di \funcd{sendfile} è:
\begin{functions}
\headdecl{sys/sendfile.h}
Copia dei dati da un file descriptor ad un altro.
\bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
+ \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
\param{out\_fd} e la scrittura si bloccherebbe.
\item[\errcode{EINVAL}] i file descriptor non sono validi, o sono bloccati
- (vedi sez.~\ref{sec:file_locking}), o \func{mmap} non è disponibile per
+ (vedi sez.~\ref{sec:file_locking}), o \func{mmap} non è disponibile per
\param{in\_fd}.
- \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
+ \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
\param{in\_fd}.
\end{errlist}
ed inoltre \errcode{EBADF} e \errcode{EFAULT}.
\param{in\_fd} al file descriptor \param{out\_fd}; in caso di successo
funzione ritorna il numero di byte effettivamente copiati da \param{in\_fd} a
\param{out\_fd} o $-1$ in caso di errore; come le ordinarie \func{read} e
-\func{write} questo valore può essere inferiore a quanto richiesto con
+\func{write} questo valore può essere inferiore a quanto richiesto con
\param{count}.
-Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
-dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
+Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
+dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
posizione indicata dal valore puntato da \param{offset}; in questo caso detto
-valore sarà aggiornato, come \textit{value result argument}, per indicare la
-posizione del byte successivo all'ultimo che è stato letto, mentre la
-posizione corrente sul file non sarà modificata. Se invece \param{offset} è
-nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
+valore sarà aggiornato, come \textit{value result argument}, per indicare la
+posizione del byte successivo all'ultimo che è stato letto, mentre la
+posizione corrente sul file non sarà modificata. Se invece \param{offset} è
+nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
letti da \param{in\_fd}.
-Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file
+Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file
descriptor, e permette di sostituire la invocazione successiva di una
\func{read} e una \func{write} (e l'allocazione del relativo buffer) con una
-sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di
+sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di
chiamate al sistema e risparmiare in trasferimenti di dati da kernel space a
-user space e viceversa. La massima utilità della funzione si ha comunque per
+user space e viceversa. La massima utilità della funzione si ha comunque per
il trasferimento di dati da un file su disco ad un socket di
-rete,\footnote{questo è il caso classico del lavoro eseguito da un server web,
+rete,\footnote{questo è il caso classico del lavoro eseguito da un server web,
ed infatti Apache ha una opzione per il supporto esplicito di questa
funzione.} dato che in questo caso diventa possibile effettuare il
trasferimento diretto via DMA dal controller del disco alla scheda di rete,
-senza neanche allocare un buffer nel kernel,\footnote{il meccanismo è detto
+senza neanche allocare un buffer nel kernel,\footnote{il meccanismo è detto
\textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel, che
si limita a programmare solo le operazioni di lettura e scrittura via DMA.}
ottenendo la massima efficienza possibile senza pesare neanche sul processore.
-In seguito però ci si è accorti che, fatta eccezione per il trasferimento
+In seguito però ci si è accorti che, fatta eccezione per il trasferimento
diretto da file a socket, non sempre \func{sendfile} comportava miglioramenti
significativi delle prestazioni rispetto all'uso in sequenza di \func{read} e
\func{write},\footnote{nel caso generico infatti il kernel deve comunque
user space che ha una conoscenza diretta su come questi sono strutturati.} e
che anzi in certi casi si potevano avere anche dei peggioramenti. Questo ha
portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
- questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
+ questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
in \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
{\textsf{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
alla decisione di consentire l'uso della funzione soltanto quando il file da
cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
-non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
-casi l'uso di \func{sendfile} darà luogo ad un errore di \errcode{EINVAL}.
+non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
+casi l'uso di \func{sendfile} darà luogo ad un errore di \errcode{EINVAL}.
Nonostante ci possano essere casi in cui \func{sendfile} non migliora le
prestazioni, resta il dubbio se la scelta di disabilitarla sempre per il
trasferimento fra file di dati sia davvero corretta. Se ci sono peggioramenti
-di prestazioni infatti si può sempre fare ricorso al metodo ordinario, ma
+di prestazioni infatti si può sempre fare ricorso al metodo ordinario, ma
lasciare a disposizione la funzione consentirebbe se non altro di semplificare
la gestione della copia dei dati fra file, evitando di dover gestire
l'allocazione di un buffer temporaneo per il loro trasferimento.
-Questo dubbio si può comunque ritenere superato con l'introduzione, avvenuta a
+Questo dubbio si può comunque ritenere superato con l'introduzione, avvenuta a
partire dal kernel 2.6.17, della nuova \textit{system call} \func{splice}. Lo
-scopo di questa funzione è quello di fornire un meccanismo generico per il
+scopo di questa funzione è quello di fornire un meccanismo generico per il
trasferimento di dati da o verso un file utilizzando un buffer gestito
internamente dal kernel. Descritta in questi termini \func{splice} sembra
semplicemente un ``\textsl{dimezzamento}'' di \func{sendfile}.\footnote{nel
senso che un trasferimento di dati fra due file con \func{sendfile} non
sarebbe altro che la lettura degli stessi su un buffer seguita dalla
relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
- chiamate a \func{splice}.} In realtà le due system call sono profondamente
+ chiamate a \func{splice}.} In realtà le due system call sono profondamente
diverse nel loro meccanismo di funzionamento;\footnote{questo fino al kernel
- 2.6.23, dove \func{sendfile} è stata reimplementata in termini di
+ 2.6.23, dove \func{sendfile} è stata reimplementata in termini di
\func{splice}, pur mantenendo disponibile la stessa interfaccia verso l'user
space.} \func{sendfile} infatti, come accennato, non necessita di avere a
-disposizione un buffer interno, perché esegue un trasferimento diretto di
-dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
-applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
+disposizione un buffer interno, perché esegue un trasferimento diretto di
+dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
+applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
specifici.\footnote{e nel caso di Linux questi sono anche solo quelli in cui
- essa può essere effettivamente utilizzata.}
+ essa può essere effettivamente utilizzata.}
-Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
- realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
- scopi da \func{sendfile}, quello che rende \func{splice} davvero diversa è
- stata la reinterpretazione che ne è stata fatta nell'implementazione su
+Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
+ realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
+ scopi da \func{sendfile}, quello che rende \func{splice} davvero diversa è
+ stata la reinterpretazione che ne è stata fatta nell'implementazione su
Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
dallo stesso Linus Torvalds in \href{http://kerneltrap.org/node/6505}
{\textsf{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
funzione che consente di fare in maniera del tutto generica delle operazioni
di trasferimento di dati fra un file e un buffer gestito interamente in kernel
space. In questo caso il cuore della funzione (e delle affini \func{vmsplice}
-e \func{tee}, che tratteremo più avanti) è appunto l'uso di un buffer in
-kernel space, e questo è anche quello che ne ha semplificato l'adozione,
-perché l'infrastruttura per la gestione di un tale buffer è presente fin dagli
+e \func{tee}, che tratteremo più avanti) è appunto l'uso di un buffer in
+kernel space, e questo è anche quello che ne ha semplificato l'adozione,
+perché l'infrastruttura per la gestione di un tale buffer è presente fin dagli
albori di Unix per la realizzazione delle \textit{pipe} (vedi
sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale allora \func{splice}
-non è altro che una diversa interfaccia (rispetto alle \textit{pipe}) con cui
+non è altro che una diversa interfaccia (rispetto alle \textit{pipe}) con cui
utilizzare in user space l'oggetto ``\textsl{buffer in kernel space}''.
-Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
+Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
come area di memoria (vedi fig.~\ref{fig:ipc_pipe_singular}) dove appoggiare i
dati che vengono trasferiti da un capo all'altro della stessa per creare un
meccanismo di comunicazione fra processi, nel caso di \func{splice} il buffer
fornisce quindi una interfaccia generica che consente di trasferire dati da un
buffer ad un file o viceversa; il suo prototipo, accessibile solo dopo aver
definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
- funzione non è contemplata da nessuno standard, è presente solo su Linux, e
+ funzione non è contemplata da nessuno standard, è presente solo su Linux, e
pertanto deve essere evitata se si vogliono scrivere programmi portabili.}
-è il seguente:
+è il seguente:
\begin{functions}
\headdecl{fcntl.h}
Trasferisce dati da un file verso una pipe o viceversa.
\bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
\item[\errcode{EBADF}] uno o entrambi fra \param{fd\_in} e \param{fd\_out}
non sono file descriptor validi o, rispettivamente, non sono stati
aperti in lettura o scrittura.
\item[\errcode{EINVAL}] il filesystem su cui si opera non supporta
- \func{splice}, oppure nessuno dei file descriptor è una pipe, oppure si
- è dato un valore a \param{off\_in} o \param{off\_out} ma il
- corrispondente file è un dispositivo che non supporta la funzione
+ \func{splice}, oppure nessuno dei file descriptor è una pipe, oppure si
+ è dato un valore a \param{off\_in} o \param{off\_out} ma il
+ corrispondente file è un dispositivo che non supporta la funzione
\func{seek}.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
\item[\errcode{ESPIPE}] o \param{off\_in} o \param{off\_out} non sono
- \const{NULL} ma il corrispondente file descriptor è una \textit{pipe}.
+ \const{NULL} ma il corrispondente file descriptor è una \textit{pipe}.
\end{errlist}
}
\end{functions}
La funzione esegue un trasferimento di \param{len} byte dal file descriptor
\param{fd\_in} al file descriptor \param{fd\_out}, uno dei quali deve essere
-una \textit{pipe}; l'altro file descriptor può essere
-qualunque.\footnote{questo significa che può essere, oltre che un file di
+una \textit{pipe}; l'altro file descriptor può essere
+qualunque.\footnote{questo significa che può essere, oltre che un file di
dati, anche un altra \textit{pipe}, o un socket.} Come accennato una
-\textit{pipe} non è altro che un buffer in kernel space, per cui a seconda che
-essa sia usata per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la
+\textit{pipe} non è altro che un buffer in kernel space, per cui a seconda che
+essa sia usata per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la
copia dei dati dal buffer al file o viceversa.
-In caso di successo la funzione ritorna il numero di byte trasferiti, che può
+In caso di successo la funzione ritorna il numero di byte trasferiti, che può
essere, come per le normali funzioni di lettura e scrittura su file, inferiore
-a quelli richiesti; un valore negativo indicherà un errore mentre un valore
-nullo indicherà che non ci sono dati da trasferire (ad esempio si è giunti
+a quelli richiesti; un valore negativo indicherà un errore mentre un valore
+nullo indicherà che non ci sono dati da trasferire (ad esempio si è giunti
alla fine del file in lettura). Si tenga presente che, a seconda del verso del
trasferimento dei dati, la funzione si comporta nei confronti del file
descriptor che fa riferimento al file ordinario, come \func{read} o
-\func{write}, e pertanto potrà anche bloccarsi (a meno che non si sia aperto
-il suddetto file in modalità non bloccante).
+\func{write}, e pertanto potrà anche bloccarsi (a meno che non si sia aperto
+il suddetto file in modalità non bloccante).
I due argomenti \param{off\_in} e \param{off\_out} consentono di specificare,
come per l'analogo \param{offset} di \func{sendfile}, la posizione all'interno
del file da cui partire per il trasferimento dei dati. Come per
\func{sendfile} un valore nullo indica di usare la posizione corrente sul
-file, ed essa sarà aggiornata automaticamente secondo il numero di byte
+file, ed essa sarà aggiornata automaticamente secondo il numero di byte
trasferiti. Un valore non nullo invece deve essere un puntatore ad una
-variabile intera che indica la posizione da usare; questa verrà aggiornata, al
+variabile intera che indica la posizione da usare; questa verrà aggiornata, al
ritorno della funzione, al byte successivo all'ultimo byte trasferito.
-Ovviamente soltanto uno di questi due argomenti, e più precisamente quello che
-fa riferimento al file descriptor non associato alla \textit{pipe}, può essere
+Ovviamente soltanto uno di questi due argomenti, e più precisamente quello che
+fa riferimento al file descriptor non associato alla \textit{pipe}, può essere
specificato come valore non nullo.
Infine l'argomento \param{flags} consente di controllare alcune
-caratteristiche del funzionamento della funzione; il contenuto è una maschera
+caratteristiche del funzionamento della funzione; il contenuto è una maschera
binaria e deve essere specificato come OR aritmetico dei valori riportati in
tab.~\ref{tab:splice_flag}. Alcuni di questi valori vengono utilizzati anche
dalle funzioni \func{vmsplice} e \func{tee} per cui la tabella riporta le
di memoria contenenti i dati invece di
copiarle;\footnotemark viene usato soltanto
da \func{splice}.\\
- \const{SPLICE\_F\_NONBLOCK}& Richiede di operare in modalità non
+ \const{SPLICE\_F\_NONBLOCK}& Richiede di operare in modalità non
bloccante; questo flag influisce solo sulle
operazioni che riguardano l'I/O da e verso la
\textit{pipe}. Nel caso di \func{splice}
- questo significa che la funzione potrà
+ questo significa che la funzione potrà
comunque bloccarsi nell'accesso agli altri
file descriptor (a meno che anch'essi non
- siano stati aperti in modalità non
+ siano stati aperti in modalità non
bloccante).\\
- \const{SPLICE\_F\_MORE} & Indica al kernel che ci sarà l'invio di
+ \const{SPLICE\_F\_MORE} & Indica al kernel che ci sarà l'invio di
ulteriori dati in una \func{splice}
- successiva, questo è un suggerimento utile
- che viene usato quando \param{fd\_out} è un
+ successiva, questo è un suggerimento utile
+ che viene usato quando \param{fd\_out} è un
socket.\footnotemark Attualmente viene usato
- solo da \func{splice}, potrà essere
+ solo da \func{splice}, potrà essere
implementato in futuro anche per
\func{vmsplice} e \func{tee}.\\
\const{SPLICE\_F\_GIFT} & Le pagine di memoria utente sono
``\textsl{donate}'' al kernel;\footnotemark
se impostato una seguente \func{splice} che
- usa \const{SPLICE\_F\_MOVE} potrà spostare le
+ usa \const{SPLICE\_F\_MOVE} potrà spostare le
pagine con successo, altrimenti esse dovranno
essere copiate; per usare questa opzione i
dati dovranno essere opportunamente allineati
sez.~\ref{sec:net_sendmsg}.}
\footnotetext{questo significa che la cache delle pagine e i dati su disco
- potranno differire, e che l'applicazione non potrà modificare quest'area di
+ potranno differire, e che l'applicazione non potrà modificare quest'area di
memoria.}
Per capire meglio il funzionamento di \func{splice} vediamo un esempio con un
semplice programma che usa questa funzione per effettuare la copia di un file
su un altro senza utilizzare buffer in user space. Il programma si chiama
-\texttt{splicecp.c} ed il codice completo è disponibile coi sorgenti allegati
+\texttt{splicecp.c} ed il codice completo è disponibile coi sorgenti allegati
alla guida, il corpo principale del programma, che non contiene la sezione di
-gestione delle opzioni e le funzioni di ausilio è riportato in
+gestione delle opzioni e le funzioni di ausilio è riportato in
fig.~\ref{fig:splice_example}.
-Lo scopo del programma è quello di eseguire la copia dei con \func{splice},
-questo significa che si dovrà usare la funzione due volte, prima per leggere i
+Lo scopo del programma è quello di eseguire la copia dei con \func{splice},
+questo significa che si dovrà usare la funzione due volte, prima per leggere i
dati e poi per scriverli, appoggiandosi ad un buffer in kernel space (vale a
-dire ad una \textit{pipe}); lo schema del flusso dei dati è illustrato in
+dire ad una \textit{pipe}); lo schema del flusso dei dati è illustrato in
fig.~\ref{fig:splicecp_data_flux}.
\begin{figure}[htb]
Una volta trattate le opzioni il programma verifica che restino
(\texttt{\small 13--16}) i due argomenti che indicano il file sorgente ed il
-file destinazione. Il passo successivo è aprire il file sorgente
+file destinazione. Il passo successivo è aprire il file sorgente
(\texttt{\small 18--22}), quello di destinazione (\texttt{\small 23--27}) ed
-infine (\texttt{\small 28--31}) la \textit{pipe} che verrà usata come buffer.
+infine (\texttt{\small 28--31}) la \textit{pipe} che verrà usata come buffer.
\begin{figure}[!phtb]
\footnotesize \centering
Il ciclo principale (\texttt{\small 33--58}) inizia con la lettura dal file
sorgente tramite la prima \func{splice} (\texttt{\small 34--35}), in questo
-caso si è usato come primo argomento il file descriptor del file sorgente e
+caso si è usato come primo argomento il file descriptor del file sorgente e
come terzo quello del capo in scrittura della \textit{pipe} (il funzionamento
delle \textit{pipe} e l'uso della coppia di file descriptor ad esse associati
-è trattato in dettaglio in sez.~\ref{sec:ipc_unix}; non ne parleremo qui dato
+è trattato in dettaglio in sez.~\ref{sec:ipc_unix}; non ne parleremo qui dato
che nell'ottica dell'uso di \func{splice} questa operazione corrisponde
semplicemente al trasferimento dei dati dal file al buffer).
La lettura viene eseguita in blocchi pari alla dimensione specificata
-dall'opzione \texttt{-s} (il default è 4096); essendo in questo caso
+dall'opzione \texttt{-s} (il default è 4096); essendo in questo caso
\func{splice} equivalente ad una \func{read} sul file, se ne controlla il
valore di uscita in \var{nread} che indica quanti byte sono stati letti, se
-detto valore è nullo (\texttt{\small 36}) questo significa che si è giunti
-alla fine del file sorgente e pertanto l'operazione di copia è conclusa e si
-può uscire dal ciclo arrivando alla conclusione del programma (\texttt{\small
- 59}). In caso di valore negativo (\texttt{\small 37--44}) c'è stato un
-errore ed allora si ripete la lettura (\texttt{\small 36}) se questo è dovuto
+detto valore è nullo (\texttt{\small 36}) questo significa che si è giunti
+alla fine del file sorgente e pertanto l'operazione di copia è conclusa e si
+può uscire dal ciclo arrivando alla conclusione del programma (\texttt{\small
+ 59}). In caso di valore negativo (\texttt{\small 37--44}) c'è stato un
+errore ed allora si ripete la lettura (\texttt{\small 36}) se questo è dovuto
ad una interruzione, o altrimenti si esce con un messaggio di errore
(\texttt{\small 41--43}).
del file di destinazione.
Di nuovo si controlla il numero di byte effettivamente scritti restituito in
-\var{nwrite} e in caso di errore al solito si ripete la scrittura se questo è
+\var{nwrite} e in caso di errore al solito si ripete la scrittura se questo è
dovuto a una interruzione o si esce con un messaggio negli altri casi
(\texttt{\small 48--55}). Infine si chiude il ciclo di scrittura sottraendo
-(\texttt{\small 57}) il numero di byte scritti a quelli di cui è richiesta la
+(\texttt{\small 57}) il numero di byte scritti a quelli di cui è richiesta la
scrittura,\footnote{in questa parte del ciclo \var{nread}, il cui valore
- iniziale è dato dai byte letti dalla precedente chiamata a \func{splice},
- viene ad assumere il significato di byte da scrivere.} così che il ciclo di
+ iniziale è dato dai byte letti dalla precedente chiamata a \func{splice},
+ viene ad assumere il significato di byte da scrivere.} così che il ciclo di
scrittura venga ripetuto fintanto che il valore risultante sia maggiore di
zero, indice che la chiamata a \func{splice} non ha esaurito tutti i dati
presenti sul buffer.
Si noti come il programma sia concettualmente identico a quello che si sarebbe
scritto usando \func{read} al posto della prima \func{splice} e \func{write}
al posto della seconda, utilizzando un buffer in user space per eseguire la
-copia dei dati, solo che in questo caso non è stato necessario allocare nessun
-buffer e non si è trasferito nessun dato in user space.
+copia dei dati, solo che in questo caso non è stato necessario allocare nessun
+buffer e non si è trasferito nessun dato in user space.
Si noti anche come si sia usata la combinazione \texttt{SPLICE\_F\_MOVE |
SPLICE\_F\_MORE } per l'argomento \param{flags} di \func{splice}, infatti
Come accennato con l'introduzione di \func{splice} sono state realizzate anche
altre due \textit{system call}, \func{vmsplice} e \func{tee}, che utilizzano
la stessa infrastruttura e si basano sullo stesso concetto di manipolazione e
-trasferimento di dati attraverso un buffer in kernel space; benché queste non
+trasferimento di dati attraverso un buffer in kernel space; benché queste non
attengono strettamente ad operazioni di trasferimento dati fra file
descriptor, le tratteremo qui, essendo strettamente correlate fra loro.
-La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
+La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
indica il suo nome consente di trasferire i dati dalla memoria virtuale di un
processo (ad esempio per un file mappato in memoria) verso una \textit{pipe};
-il suo prototipo è:
+il suo prototipo è:
\begin{functions}
\headdecl{fcntl.h}
\headdecl{sys/uio.h}
Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.
\bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
+ \item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
fa riferimento ad una \textit{pipe}.
- \item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
- oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
+ \item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
+ oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
\end{errlist}
}
\end{functions}
-La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
+La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
file descriptor corrispondente al suo capo aperto in scrittura (di nuovo si
faccia riferimento a sez.~\ref{sec:ipc_unix}), mentre per indicare quali
segmenti della memoria del processo devono essere trasferiti verso di essa si
-dovrà utilizzare un vettore di strutture \struct{iovec} (vedi
+dovrà utilizzare un vettore di strutture \struct{iovec} (vedi
fig.~\ref{fig:file_iovec}), esattamente con gli stessi criteri con cui le si
usano per l'I/O vettorizzato, indicando gli indirizzi e le dimensioni di
ciascun segmento di memoria su cui si vuole operare; le dimensioni del
In caso di successo la funzione ritorna il numero di byte trasferiti sulla
\textit{pipe}. In generale, se i dati una volta creati non devono essere
-riutilizzati (se cioè l'applicazione che chiama \func{vmsplice} non
-modificherà più la memoria trasferita), è opportuno utilizzare
-per \param{flag} il valore \const{SPLICE\_F\_GIFT}; questo fa sì che il kernel
-possa rimuovere le relative pagine dalla cache della memoria virtuale, così
-che queste possono essere utilizzate immediatamente senza necessità di
+riutilizzati (se cioè l'applicazione che chiama \func{vmsplice} non
+modificherà più la memoria trasferita), è opportuno utilizzare
+per \param{flag} il valore \const{SPLICE\_F\_GIFT}; questo fa sì che il kernel
+possa rimuovere le relative pagine dalla cache della memoria virtuale, così
+che queste possono essere utilizzate immediatamente senza necessità di
eseguire una copia dei dati che contengono.
-La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
-suo nome all'omonimo comando in user space, perché in analogia con questo
+La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
+suo nome all'omonimo comando in user space, perché in analogia con questo
permette di duplicare i dati in ingresso su una \textit{pipe} su un'altra
\textit{pipe}. In sostanza, sempre nell'ottica della manipolazione dei dati su
dei buffer in kernel space, la funzione consente di eseguire una copia del
-contenuto del buffer stesso. Il prototipo di \funcd{tee} è il seguente:
+contenuto del buffer stesso. Il prototipo di \funcd{tee} è il seguente:
\begin{functions}
\headdecl{fcntl.h}
Duplica \param{len} byte da una \textit{pipe} ad un'altra.
\bodydesc{La funzione restituisce il numero di byte copiati in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] o uno fra \param{fd\_in} e \param{fd\_out} non fa
riferimento ad una \textit{pipe} o entrambi fanno riferimento alla
stessa \textit{pipe}.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
\end{errlist}
}
momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio
2010, in futuro potrebbe essere implementato anche \const{SPLICE\_F\_MORE}.}
il solo valore utilizzabile per \param{flag}, fra quelli elencati in
-tab.~\ref{tab:splice_flag}, è \const{SPLICE\_F\_NONBLOCK} che rende la
+tab.~\ref{tab:splice_flag}, è \const{SPLICE\_F\_NONBLOCK} che rende la
funzione non bloccante.
La funzione restituisce il numero di byte copiati da una \textit{pipe}
all'altra (o $-1$ in caso di errore), un valore nullo indica che non ci sono
-byte disponibili da copiare e che il capo in scrittura della pipe è stato
-chiuso.\footnote{si tenga presente però che questo non avviene se si è
+byte disponibili da copiare e che il capo in scrittura della pipe è stato
+chiuso.\footnote{si tenga presente però che questo non avviene se si è
impostato il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si
avrebbe un errore di \errcode{EAGAIN}.} Un esempio di realizzazione del
comando \texttt{tee} usando questa funzione, ripreso da quello fornito nella
-pagina di manuale e dall'esempio allegato al patch originale, è riportato in
+pagina di manuale e dall'esempio allegato al patch originale, è riportato in
fig.~\ref{fig:tee_example}. Il programma consente di copiare il contenuto
dello standard input sullo standard output e su un file specificato come
argomento, il codice completo si trova nel file \texttt{tee.c} dei sorgenti
Il ciclo principale (\texttt{\small 37--58}) inizia con la chiamata a
\func{tee} che duplica il contenuto dello standard input sullo standard output
-(\texttt{\small 39}), questa parte è del tutto analoga ad una lettura ed
+(\texttt{\small 39}), questa parte è del tutto analoga ad una lettura ed
infatti come nell'esempio di fig.~\ref{fig:splice_example} si controlla il
-valore di ritorno della funzione in \var{len}; se questo è nullo significa che
-non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 40}), se
-è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
+valore di ritorno della funzione in \var{len}; se questo è nullo significa che
+non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 40}), se
+è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
dovuto ad una interruzione (\texttt{\small 42--44}) o si stampa un messaggio
di errore e si esce negli altri casi (\texttt{\small 44--47}).
estrarre dalla standard input e scrivere sul file, di nuovo su usa un ciclo di
scrittura (\texttt{\small 50--58}) in cui si ripete una chiamata a
\func{splice} (\texttt{\small 51}) fintanto che non si sono scritti tutti i
-\var{len} byte copiati in precedenza con \func{tee} (il funzionamento è
+\var{len} byte copiati in precedenza con \func{tee} (il funzionamento è
identico all'analogo ciclo di scrittura del precedente esempio di
fig.~\ref{fig:splice_example}).
Infine una nota finale riguardo \func{splice}, \func{vmsplice} e \func{tee}:
-occorre sottolineare che benché finora si sia parlato di trasferimenti o copie
-di dati in realtà nella implementazione di queste system call non è affatto
+occorre sottolineare che benché finora si sia parlato di trasferimenti o copie
+di dati in realtà nella implementazione di queste system call non è affatto
detto che i dati vengono effettivamente spostati o copiati, il kernel infatti
realizza le \textit{pipe} come un insieme di puntatori\footnote{per essere
precisi si tratta di un semplice buffer circolare, un buon articolo sul tema
si trova su \href{http://lwn.net/Articles/118750/}
{\textsf{http://lwn.net/Articles/118750/}}.} alle pagine di memoria interna
che contengono i dati, per questo una volta che i dati sono presenti nella
-memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
+memoria del kernel tutto quello che viene fatto è creare i suddetti puntatori
ed aumentare il numero di referenze; questo significa che anche con \func{tee}
non viene mai copiato nessun byte, vengono semplicemente copiati i puntatori.
Nell'uso generico dell'interfaccia per l'accesso al contenuto dei file le
operazioni di lettura e scrittura non necessitano di nessun intervento di
-supervisione da parte dei programmi, si eseguirà una \func{read} o una
-\func{write}, i dati verranno passati al kernel che provvederà ad effettuare
+supervisione da parte dei programmi, si eseguirà una \func{read} o una
+\func{write}, i dati verranno passati al kernel che provvederà ad effettuare
tutte le operazioni (e a gestire il \textit{caching} dei dati) per portarle a
-termine in quello che ritiene essere il modo più efficiente.
+termine in quello che ritiene essere il modo più efficiente.
-Il problema è che il concetto di migliore efficienza impiegato dal kernel è
+Il problema è che il concetto di migliore efficienza impiegato dal kernel è
relativo all'uso generico, mentre esistono molti casi in cui ci sono esigenze
specifiche dei singoli programmi, che avendo una conoscenza diretta di come
verranno usati i file, possono necessitare di effettuare delle ottimizzazioni
-specifiche, relative alle proprie modalità di I/O sugli stessi. Tratteremo in
+specifiche, relative alle proprie modalità di I/O sugli stessi. Tratteremo in
questa sezione una serie funzioni che consentono ai programmi di ottimizzare
il loro accesso ai dati dei file e controllare la gestione del relativo
\textit{caching}.
\itindbeg{read-ahead}
-Una prima funzione che può essere utilizzata per modificare la gestione
-ordinaria dell'I/O su un file è \funcd{readahead},\footnote{questa è una
+Una prima funzione che può essere utilizzata per modificare la gestione
+ordinaria dell'I/O su un file è \funcd{readahead},\footnote{questa è una
funzione specifica di Linux, introdotta con il kernel 2.4.13, e non deve
essere usata se si vogliono scrivere programmi portabili.} che consente di
-richiedere una lettura anticipata del contenuto dello stesso in cache, così
+richiedere una lettura anticipata del contenuto dello stesso in cache, così
che le seguenti operazioni di lettura non debbano subire il ritardo dovuto
-all'accesso al disco; il suo prototipo è:
+all'accesso al disco; il suo prototipo è:
\begin{functions}
\headdecl{fcntl.h}
Esegue una lettura preventiva del contenuto di un file in cache.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
- valido o non è aperto in lettura.
+ \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+ valido o non è aperto in lettura.
\item[\errcode{EINVAL}] l'argomento \param{fd} si riferisce ad un tipo di
file che non supporta l'operazione (come una pipe o un socket).
\end{errlist}
corrispondenti alle dimensioni delle pagine di memoria, ed i valori di
\param{offset} e \param{count} vengono arrotondati di conseguenza.
-La funzione estende quello che è un comportamento normale del kernel che
+La funzione estende quello che è un comportamento normale del kernel che
quando si legge un file, aspettandosi che l'accesso prosegua, esegue sempre
-una lettura preventiva di una certa quantità di dati; questo meccanismo di
+una lettura preventiva di una certa quantità di dati; questo meccanismo di
lettura anticipata viene chiamato \textit{read-ahead}, da cui deriva il nome
della funzione. La funzione \func{readahead}, per ottimizzare gli accessi a
disco, effettua la lettura in cache della sezione richiesta e si blocca
viene modificata ed indipendentemente da quanto indicato con \param{count} la
lettura dei dati si interrompe una volta raggiunta la fine del file.
-Si può utilizzare questa funzione per velocizzare le operazioni di lettura
+Si può utilizzare questa funzione per velocizzare le operazioni di lettura
all'interno di un programma tutte le volte che si conosce in anticipo quanti
-dati saranno necessari nelle elaborazioni successive. Si potrà così
+dati saranno necessari nelle elaborazioni successive. Si potrà così
concentrare in un unico momento (ad esempio in fase di inizializzazione) la
-lettura dei dati da disco, così da ottenere una migliore velocità di risposta
+lettura dei dati da disco, così da ottenere una migliore velocità di risposta
nelle operazioni successive.
\itindend{read-ahead}
Il concetto di \func{readahead} viene generalizzato nello standard
POSIX.1-2001 dalla funzione \func{posix\_fadvise},\footnote{anche se
- l'argomento \param{len} è stato modificato da \ctyp{size\_t} a \ctyp{off\_t}
+ l'argomento \param{len} è stato modificato da \ctyp{size\_t} a \ctyp{off\_t}
nella revisione POSIX.1-2003 TC5.} che consente di ``\textsl{avvisare}'' il
-kernel sulle modalità con cui si intende accedere nel futuro ad una certa
-porzione di un file,\footnote{la funzione però è stata introdotta su Linux
- solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
-opportune ottimizzazioni; il prototipo di \funcd{posix\_fadvise}, che è
-disponibile soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad
-valore di almeno 600, è:
+kernel sulle modalità con cui si intende accedere nel futuro ad una certa
+porzione di un file,\footnote{la funzione però è stata introdotta su Linux
+ solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
+opportune ottimizzazioni; il prototipo di \funcd{posix\_fadvise}, che è
+disponibile soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad
+valore di almeno 600, è:
\begin{functions}
\headdecl{fcntl.h}
\funcdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
- Dichiara al kernel le future modalità di accesso ad un file.
+ Dichiara al kernel le future modalità di accesso ad un file.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+ \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
valido.
- \item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
+ \item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
\param{fd} si riferisce ad un tipo di file che non supporta l'operazione
(come una pipe o un socket).
- \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una pipe o
+ \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una pipe o
un socket (ma su Linux viene restituito \errcode{EINVAL}).
\end{errlist}
}
\end{functions}
-La funzione dichiara al kernel le modalità con cui intende accedere alla
+La funzione dichiara al kernel le modalità con cui intende accedere alla
regione del file indicato da \param{fd} che inizia alla posizione
\param{offset} e si estende per \param{len} byte. Se per \param{len} si usa un
-valore nullo la regione coperta sarà da \param{offset} alla fine del
-file.\footnote{questo è vero solo per le versioni più recenti, fino al kernel
- 2.6.6 il valore nullo veniva interpretato letteralmente.} Le modalità sono
-indicate dall'argomento \param{advice} che è una maschera binaria dei valori
+valore nullo la regione coperta sarà da \param{offset} alla fine del
+file.\footnote{questo è vero solo per le versioni più recenti, fino al kernel
+ 2.6.6 il valore nullo veniva interpretato letteralmente.} Le modalità sono
+indicate dall'argomento \param{advice} che è una maschera binaria dei valori
illustrati in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato
-degli analoghi già visti in sez.~\ref{sec:file_memory_map} per
-\func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
+degli analoghi già visti in sez.~\ref{sec:file_memory_map} per
+\func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
in questo caso applicata direttamente al sistema ai contenuti di un file
invece che alla sua mappatura in memoria.} Si tenga presente comunque che la
-funzione dà soltanto un avvertimento, non esiste nessun vincolo per il kernel,
+funzione dà soltanto un avvertimento, non esiste nessun vincolo per il kernel,
che utilizza semplicemente l'informazione.
\begin{table}[htb]
\hline
\hline
\const{POSIX\_FADV\_NORMAL} & Non ci sono avvisi specifici da fare
- riguardo le modalità di accesso, il
- comportamento sarà identico a quello che si
+ riguardo le modalità di accesso, il
+ comportamento sarà identico a quello che si
avrebbe senza nessun avviso.\\
\const{POSIX\_FADV\_SEQUENTIAL}& L'applicazione si aspetta di accedere di
accedere ai dati specificati in maniera
- sequenziale, a partire dalle posizioni più
+ sequenziale, a partire dalle posizioni più
basse.\\
\const{POSIX\_FADV\_RANDOM} & I dati saranno letti in maniera
completamente causale.\\
\hline
\end{tabular}
\caption{Valori delle costanti usabili per l'argomento \param{advice} di
- \func{posix\_fadvise}, che indicano la modalità con cui si intende accedere
+ \func{posix\_fadvise}, che indicano la modalità con cui si intende accedere
ad un file.}
\label{tab:posix_fadvise_flag}
\end{table}
dal kernel; in particolare utilizzando il valore
\const{POSIX\_FADV\_SEQUENTIAL} si raddoppia la dimensione dell'ammontare di
dati letti preventivamente rispetto al default, aspettandosi appunto una
-lettura sequenziale che li utilizzerà, mentre con \const{POSIX\_FADV\_RANDOM}
+lettura sequenziale che li utilizzerà, mentre con \const{POSIX\_FADV\_RANDOM}
si disabilita del tutto il suddetto meccanismo, dato che con un accesso del
-tutto casuale è inutile mettersi a leggere i dati immediatamente successivi
+tutto casuale è inutile mettersi a leggere i dati immediatamente successivi
gli attuali; infine l'uso di \const{POSIX\_FADV\_NORMAL} consente di
riportarsi al comportamento di default.
-Le due modalità \const{POSIX\_FADV\_NOREUSE} e \const{POSIX\_FADV\_WILLNEED}
+Le due modalità \const{POSIX\_FADV\_NOREUSE} e \const{POSIX\_FADV\_WILLNEED}
fino al kernel 2.6.18 erano equivalenti, a partire da questo kernel la prima
-viene non ha più alcun effetto, mentre la seconda dà inizio ad una lettura in
-cache della regione del file indicata. La quantità di dati che verranno letti
-è ovviamente limitata in base al carico che si viene a creare sul sistema
+viene non ha più alcun effetto, mentre la seconda dà inizio ad una lettura in
+cache della regione del file indicata. La quantità di dati che verranno letti
+è ovviamente limitata in base al carico che si viene a creare sul sistema
della memoria virtuale, ma in genere una lettura di qualche megabyte viene
-sempre soddisfatta (ed un valore superiore è solo raramente di qualche
-utilità). In particolare l'uso di \const{POSIX\_FADV\_WILLNEED} si può
+sempre soddisfatta (ed un valore superiore è solo raramente di qualche
+utilità). In particolare l'uso di \const{POSIX\_FADV\_WILLNEED} si può
considerare l'equivalente POSIX di \func{readahead}.
Infine con \const{POSIX\_FADV\_DONTNEED} si dice al kernel di liberare le
pagine di cache occupate dai dati presenti nella regione di file indicata.
-Questa è una indicazione utile che permette di alleggerire il carico sulla
-cache, ed un programma può utilizzare periodicamente questa funzione per
-liberare pagine di memoria da dati che non sono più utilizzati per far posto a
+Questa è una indicazione utile che permette di alleggerire il carico sulla
+cache, ed un programma può utilizzare periodicamente questa funzione per
+liberare pagine di memoria da dati che non sono più utilizzati per far posto a
nuovi dati utili.\footnote{la pagina di manuale riporta l'esempio dello
- streaming di file di grosse dimensioni, dove le pagine occupate dai dati già
+ streaming di file di grosse dimensioni, dove le pagine occupate dai dati già
inviati possono essere tranquillamente scartate.}
Sia \func{posix\_fadvise} che \func{readahead} attengono alla ottimizzazione
dell'accesso in lettura; lo standard POSIX.1-2001 prevede anche una funzione
specifica per le operazioni di scrittura,
-\funcd{posix\_fallocate},\footnote{la funzione è stata introdotta a partire
+\funcd{posix\_fallocate},\footnote{la funzione è stata introdotta a partire
dalle glibc 2.1.94.} che consente di preallocare dello spazio disco per
assicurarsi che una seguente scrittura non fallisca, il suo prototipo,
anch'esso disponibile solo se si definisce la macro \macro{\_XOPEN\_SOURCE} ad
-almeno 600, è:
+almeno 600, è:
\begin{functions}
\headdecl{fcntl.h}
\bodydesc{La funzione restituisce 0 in caso di successo e direttamente un
codice di errore, in caso di fallimento, in questo caso \var{errno} non
- viene impostata, ma sarà restituito direttamente uno dei valori:
+ viene impostata, ma sarà restituito direttamente uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
- valido o non è aperto in scrittura.
+ \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+ valido o non è aperto in scrittura.
\item[\errcode{EINVAL}] o \param{offset} o \param{len} sono minori di
zero.
\item[\errcode{EFBIG}] il valore di (\param{offset} + \param{len}) eccede
la dimensione massima consentita per un file.
\item[\errcode{ENODEV}] l'argomento \param{fd} non fa riferimento ad un
file regolare.
- \item[\errcode{ENOSPC}] non c'è sufficiente spazio disco per eseguire
+ \item[\errcode{ENOSPC}] non c'è sufficiente spazio disco per eseguire
l'operazione.
- \item[\errcode{ESPIPE}] l'argomento \param{fd} è una pipe.
+ \item[\errcode{ESPIPE}] l'argomento \param{fd} è una pipe.
\end{errlist}
}
\end{functions}
-La funzione assicura che venga allocato sufficiente spazio disco perché sia
+La funzione assicura che venga allocato sufficiente spazio disco perché sia
possibile scrivere sul file indicato dall'argomento \param{fd} nella regione
che inizia dalla posizione \param{offset} e si estende per \param{len} byte;
se questa regione si estende oltre la fine del file le dimensioni di
quest'ultimo saranno incrementate di conseguenza. Dopo aver eseguito con
-successo la funzione è garantito che una successiva scrittura nella regione
-indicata non fallirà per mancanza di spazio disco. La funzione non ha nessun
-effetto né sul contenuto, né sulla posizione corrente del file.
+successo la funzione è garantito che una successiva scrittura nella regione
+indicata non fallirà per mancanza di spazio disco. La funzione non ha nessun
+effetto né sul contenuto, né sulla posizione corrente del file.
-Ci si può chiedere a cosa possa servire una funzione come
-\func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
+Ci si può chiedere a cosa possa servire una funzione come
+\func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
eseguendo esplicitamente sul file la scrittura\footnote{usando \funcd{pwrite}
per evitare spostamenti della posizione corrente sul file.} di una serie di
zeri per l'estensione di spazio necessaria qualora il \itindex{sparse~file}
buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e che
l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
\itindex{sparse~file} \textit{sparse file} (vedi sez.~\ref{sec:file_lseek})
- senza una effettiva allocazione dello spazio disco.} In realtà questa è la
-modalità con cui la funzione veniva realizzata nella prima versione fornita
+ senza una effettiva allocazione dello spazio disco.} In realtà questa è la
+modalità con cui la funzione veniva realizzata nella prima versione fornita
dalle \acr{glibc}, per cui la funzione costituiva in sostanza soltanto una
-standardizzazione delle modalità di esecuzione di questo tipo di allocazioni.
+standardizzazione delle modalità di esecuzione di questo tipo di allocazioni.
-Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
+Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
scrittura su tutto lo spazio disco necessario, da fare al momento della
richiesta di allocazione, pagandone il conseguente prezzo in termini di
-prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
+prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
spazio per poi andarci a scrivere, una sola volta, quando il contenuto finale
diventa effettivamente disponibile.
-Per poter fare tutto questo è però necessario il supporto da parte del kernel,
-e questo è divenuto disponibile solo a partire dal kernel 2.6.23 in cui è
+Per poter fare tutto questo è però necessario il supporto da parte del kernel,
+e questo è divenuto disponibile solo a partire dal kernel 2.6.23 in cui è
stata introdotta la nuova \textit{system call} \func{fallocate},\footnote{non
- è detto che la funzione sia disponibile per tutti i filesystem, ad esempio
- per XFS il supporto è stato introdotto solo a partire dal kernel 2.6.25.}
+ è detto che la funzione sia disponibile per tutti i filesystem, ad esempio
+ per XFS il supporto è stato introdotto solo a partire dal kernel 2.6.25.}
che consente di realizzare direttamente all'interno del kernel l'allocazione
-dello spazio disco così da poter realizzare una versione di
-\func{posix\_fallocate} con prestazioni molto più elevate.\footnote{nelle
+dello spazio disco così da poter realizzare una versione di
+\func{posix\_fallocate} con prestazioni molto più elevate.\footnote{nelle
\acr{glibc} la nuova \textit{system call} viene sfruttata per la
realizzazione di \func{posix\_fallocate} a partire dalla versione 2.10.}
come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
in maniera indiretta con l'ausilio di \func{syscall}, vedi
sez.~\ref{sec:intro_syscall}, come \code{long fallocate(int fd, int mode,
- loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
- stato fornito un supporto esplicito; il suo prototipo è:
+ loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
+ stato fornito un supporto esplicito; il suo prototipo è:
\begin{functions}
\headdecl{linux/fcntl.h}
Prealloca dello spazio disco per un file.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non fa riferimento ad un file descriptor
valido aperto in scrittura.
\item[\errcode{EFBIG}] la somma di \param{offset} e \param{len} eccede le
dimensioni massime di un file.
- \item[\errcode{EINVAL}] \param{offset} è minore di zero o \param{len} è
+ \item[\errcode{EINVAL}] \param{offset} è minore di zero o \param{len} è
minore o uguale a zero.
\item[\errcode{ENODEV}] \param{fd} non fa riferimento ad un file ordinario
o a una directory.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per l'operazione.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per l'operazione.
\item[\errcode{ENOSYS}] il filesystem contenente il file associato
a \param{fd} non supporta \func{fallocate}.
\item[\errcode{EOPNOTSUPP}] il filesystem contenente il file associato
La funzione prende gli stessi argomenti di \func{posix\_fallocate} con lo
stesso significato, a cui si aggiunge l'argomento \param{mode} che indica le
-modalità di allocazione; al momento quest'ultimo può soltanto essere nullo o
+modalità di allocazione; al momento quest'ultimo può soltanto essere nullo o
assumere il valore \const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la
dimensione del file\footnote{quella ottenuta nel campo \var{st\_size} di una
struttura \struct{stat} dopo una chiamata a \texttt{fstat}.} non venga
modificata anche quando la somma di \param{offset} e \param{len} eccede la
dimensione corrente.
-Se \param{mode} è nullo invece la dimensione totale del file in caso di
+Se \param{mode} è nullo invece la dimensione totale del file in caso di
estensione dello stesso viene aggiornata, come richiesto per
-\func{posix\_fallocate}, ed invocata in questo modo si può considerare
+\func{posix\_fallocate}, ed invocata in questo modo si può considerare
\func{fallocate} come l'implementazione ottimale di \func{posix\_fallocate} a
livello di kernel.
\chapter{File e directory}
\label{cha:files_and_dirs}
-In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
+In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
file e directory, iniziando dalle funzioni di libreria che si usano per
copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
permette la manipolazione dei vari attributi di file e directory ed alla fine
-faremo una trattazione dettagliata su come è strutturato il sistema base di
+faremo una trattazione dettagliata su come è strutturato il sistema base di
protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono
la gestione. Tutto quello che riguarda invece la manipolazione del contenuto
-dei file è lasciato ai capitoli successivi.
+dei file è lasciato ai capitoli successivi.
\section{La gestione di file e directory}
\label{sec:file_dir}
-Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
+Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
la gestione dei file ha delle caratteristiche specifiche che derivano
direttamente dall'architettura del sistema. In questa sezione esamineremo le
funzioni usate per la manipolazione di file e directory, per la creazione di
\subsection{Le funzioni \func{link} e \func{unlink}}
\label{sec:file_link}
-Una caratteristica comune a diversi sistemi operativi è quella di poter creare
+Una caratteristica comune a diversi sistemi operativi è quella di poter creare
dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows o i
nomi logici del VMS) che permettono di fare riferimento allo stesso file
chiamandolo con nomi diversi o accedendovi da directory diverse.
-Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
+Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo
la gestione dei file (ed in particolare quanto trattato in
sez.~\ref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per
Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
file su disco avviene passando attraverso il suo \itindex{inode}
-\textit{inode}, che è la struttura usata dal kernel che lo identifica
+\textit{inode}, che è la struttura usata dal kernel che lo identifica
univocamente all'interno di un singolo filesystem. Il nome del file che si
-trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
+trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
della directory, che viene associata ad un puntatore che fa riferimento al
suddetto \textit{inode}.
Questo significa che, fintanto che si resta sullo stesso filesystem, la
-realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
+realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}
\textit{inode} effettuate tramite ``etichette'' diverse in directory
diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
-particolare preferenza o originalità rispetto agli altri, in quanto tutti
+particolare preferenza o originalità rispetto agli altri, in quanto tutti
fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
Per aggiungere ad una directory una voce che faccia riferimento ad un
-\itindex{inode} \textit{inode} già esistente si utilizza la funzione
+\itindex{inode} \textit{inode} già esistente si utilizza la funzione
\func{link}; si suole chiamare questo tipo di associazione un collegamento
-diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
+diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
\begin{prototype}{unistd.h}
{int link(const char *oldpath, const char *newpath)}
Crea un nuovo collegamento diretto.
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
riferimento ad un filesystem montato sullo stesso \textit{mount point}.
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
- \param{newpath} non supporta i link diretti o è una directory.
+ \param{newpath} non supporta i link diretti o è una directory.
\item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
- esiste già.
+ esiste già.
\item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
- numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
+ numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
\end{errlist}
ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOTDIR},
si limita a creare una voce nella directory specificata da \param{newpath} e
ad aumentare di uno il numero di riferimenti al file (riportato nel campo
\var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat})
-aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
-essere così chiamato con vari nomi in diverse directory.
+aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
+essere così chiamato con vari nomi in diverse directory.
Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
-collegamento diretto è possibile solo se entrambi i \itindex{pathname}
+collegamento diretto è possibile solo se entrambi i \itindex{pathname}
\textit{pathname} sono nello stesso filesystem; inoltre il filesystem deve
-supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
-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
+supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
+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.}
+ 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
-l'amministratore è in grado di creare un collegamento diretto ad un'altra
-directory: questo viene fatto perché con una tale operazione è possibile
+l'amministratore è in grado di creare un collegamento diretto ad un'altra
+directory: questo viene fatto perché con una tale operazione è possibile
creare dei \textit{loop} nel filesystem (vedi l'esempio mostrato in
sez.~\ref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
non sono in grado di gestire e la cui rimozione diventerebbe estremamente
complicata (in genere per questo tipo di errori occorre far girare il
programma \cmd{fsck} per riparare il filesystem).
-Data la pericolosità di questa operazione e la disponibilità dei link
-simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nel caso di Linux questa capacità è stata completamente disabilitata, e al
+Data la pericolosità di questa operazione e la disponibilità dei link
+simbolici che possono fornire la stessa funzionalità senza questi problemi,
+nel caso di Linux questa capacità è stata completamente disabilitata, e al
tentativo di creare un link diretto ad una directory la funzione \func{link}
restituisce l'errore \errcode{EPERM}.
-Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
+Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
prevederebbe che quest'ultimo venga risolto e che il collegamento sia
effettuato rispetto al file cui esso punta, e che venga riportato un errore
qualora questo non esista o non sia un file. Questo era anche il comportamento
iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
precisione il comportamento era quello previsto dallo standard POSIX fino al
- kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
+ kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
attuale fino ad oggi (per riferimento si veda
\href{http://lwn.net/Articles/293902}
- {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
-comportamento che non segue più lo standard per cui l'\textit{hard link} viene
+ {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
+comportamento che non segue più lo standard per cui l'\textit{hard link} viene
creato rispetto al link simbolico, e non al file cui questo punta.
La ragione di questa differenza rispetto allo standard, presente anche in
-altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
+altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
riferimento anche ad un file non esistente o a una directory, per i quali
-l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
-link simbolico è stata ritenuta una scelta scorretta nella progettazione
+l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
+link simbolico è stata ritenuta una scelta scorretta nella progettazione
dell'interfaccia. Infatti se non ci fosse il comportamento adottato da Linux
-sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
+sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
la funzione lo risolverebbe e l'\textit{hard link} verrebbe creato verso la
destinazione. Invece evitando di seguire lo standard l'operazione diventa
-possibile, ed anche il comportamento della funzione risulta molto più
-comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
- link} rispetto alla destinazione di un link simbolico è sempre possibile
-farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
+possibile, ed anche il comportamento della funzione risulta molto più
+comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
+ link} rispetto alla destinazione di un link simbolico è sempre possibile
+farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
standard possa causare problemi, come nell'esempio descritto nell'articolo
citato nella nota precedente, a programmi che non si aspettano questa
differenza rispetto allo standard POSIX.}
-La rimozione di un file (o più precisamente della voce che lo referenzia
+La rimozione di un file (o più precisamente della voce che lo referenzia
all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
-suo prototipo è il seguente:
+suo prototipo è il seguente:
\begin{prototype}{unistd.h}{int unlink(const char *pathname)}
Cancella un file.
\begin{errlist}
\item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory.
\footnotemark
- \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
+ \item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
lettura.
\item[\errcode{EISDIR}] \param{pathname} fa riferimento a una directory.
\end{errlist}
\errval{EIO}.}
\end{prototype}
-\footnotetext{questo è un valore specifico ritornato da Linux che non consente
+\footnotetext{questo è un valore specifico ritornato da Linux che non consente
l'uso di \func{unlink} con le directory (vedi sez.~\ref{sec:file_remove}).
- Non è conforme allo standard POSIX, che prescrive invece l'uso di
+ Non è conforme allo standard POSIX, che prescrive invece l'uso di
\errcode{EPERM} in caso l'operazione non sia consentita o il processo non
abbia privilegi sufficienti.}
il nome, ma come per i file i processi che hanno aperto uno di questi oggetti
possono continuare ad utilizzarlo.
-Per cancellare una voce in una directory è necessario avere il permesso di
+Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
il diritto di esecuzione sulla directory che la contiene (affronteremo in
dettaglio l'argomento dei permessi di file e directory in
sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit}
-\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
-occorrerà anche essere proprietari del file o proprietari della directory (o
-root, per cui nessuna delle restrizioni è applicata).
+\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
+occorrerà anche essere proprietari del file o proprietari della directory (o
+root, per cui nessuna delle restrizioni è applicata).
-Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
+Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
nome dalla directory e l'incremento/decremento del numero di riferimenti
\itindex{inode} nell'\textit{inode} devono essere effettuati in maniera
atomica (si veda sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni
\itindex{inode} \textit{inode} ad essi relativi. Prima di procedere alla
cancellazione dello spazio occupato su disco dal contenuto di un file il
kernel controlla anche questa tabella, per verificare che anche in essa non
- ci sia più nessun riferimento all'\textit{inode} in questione.} e cioè che
+ ci sia più nessun riferimento all'\textit{inode} in questione.} e cioè che
non ci siano processi che abbiano il suddetto file aperto).
-Questa proprietà viene spesso usata per essere sicuri di non lasciare file
-temporanei su disco in caso di crash dei programmi; la tecnica è quella di
+Questa proprietà viene spesso usata per essere sicuri di non lasciare file
+temporanei su disco in caso di crash dei programmi; la tecnica è quella di
aprire il file e chiamare \func{unlink} subito dopo, in questo modo il
-contenuto del file è sempre disponibile all'interno del processo attraverso il
+contenuto del file è sempre disponibile all'interno del processo attraverso il
suo file descriptor (vedi sez.~\ref{sec:file_fd}) fintanto che il processo non
chiude il file, ma non ne resta traccia in nessuna directory, e lo spazio
occupato su disco viene immediatamente rilasciato alla conclusione del
\subsection{Le funzioni \func{remove} e \func{rename}}
\label{sec:file_remove}
-Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
-\func{unlink} sulle directory; per cancellare una directory si può usare la
+Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
+\func{unlink} sulle directory; per cancellare una directory si può usare la
funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}), oppure la
funzione \funcd{remove}.
-Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
+Questa è la funzione prevista dallo standard ANSI C per cancellare un file o
una directory (e funziona anche per i sistemi che non supportano i link
-diretti). Per i file è identica a \func{unlink} e per le directory è identica
-a \func{rmdir}; il suo prototipo è:
+diretti). Per i file è identica a \func{unlink} e per le directory è identica
+a \func{rmdir}; il suo prototipo è:
\begin{prototype}{stdio.h}{int remove(const char *pathname)}
Cancella un nome dal filesystem.
errore, nel qual caso il file non viene toccato.
I codici di errore riportati in \var{errno} sono quelli della chiamata
- utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
+ utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
descrizioni di \func{unlink} e \func{rmdir}.}
\end{prototype}
La funzione utilizza la funzione \func{unlink}\footnote{questo vale usando le
- \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
- semplice alias alla funzione \func{unlink} e quindi non può essere usata per
+ \acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
+ semplice alias alla funzione \func{unlink} e quindi non può essere usata per
le directory.} per cancellare i file e la funzione \func{rmdir} per
cancellare le directory; si tenga presente che per alcune implementazioni del
-protocollo NFS utilizzare questa funzione può comportare la scomparsa di file
+protocollo NFS utilizzare questa funzione può comportare la scomparsa di file
ancora in uso.
Per cambiare nome ad un file o a una directory (che devono comunque essere
nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la
- funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
+ funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
standard POSIX estende la funzione anche alle directory.} il cui prototipo
-è:
+è:
\begin{prototype}{stdio.h}
{int rename(const char *oldpath, const char *newpath)}
errore, nel qual caso il file non viene toccato. La variabile
\var{errno} viene impostata secondo i seguenti codici di errore:
\begin{errlist}
- \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
- \param{oldpath} non è una directory.
+ \item[\errcode{EISDIR}] \param{newpath} è una directory mentre
+ \param{oldpath} non è una directory.
\item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
stesso filesystem.
- \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
+ \item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
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).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
- \param{oldpath} o più in generale si è cercato di creare una directory come
+ \param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
\item[\errcode{ENOTDIR}] uno dei componenti dei \itindex{pathname}
- \textit{pathname} non è una directory o \param{oldpath} è una directory e
- \param{newpath} esiste e non è una directory.
+ \textit{pathname} non è una directory o \param{oldpath} è una directory e
+ \param{newpath} esiste e non è una directory.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
\errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
necessario lo spostamento di un file fra directory diverse. Eventuali altri
link diretti allo stesso file non vengono influenzati.
-Il comportamento della funzione è diverso a seconda che si voglia rinominare
+Il comportamento della funzione è diverso a seconda che si voglia rinominare
un file o una directory; se ci riferisce ad un file allora \param{newpath}, se
esiste, non deve essere una directory (altrimenti si ha l'errore
\errcode{EISDIR}). Nel caso \param{newpath} indichi un file esistente questo
viene cancellato e rimpiazzato (atomicamente).
-Se \param{oldpath} è una directory allora \param{newpath}, se esiste, deve
+Se \param{oldpath} è una directory allora \param{newpath}, se esiste, deve
essere una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR}
-(se non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
-\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
+(se non è una directory) o \errcode{ENOTEMPTY} (se non è vuota). Chiaramente
+\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
\errcode{EINVAL}.
-Se \param{oldpath} si riferisce ad un link simbolico questo sarà rinominato; se
-\param{newpath} è un link simbolico verrà cancellato come qualunque altro
+Se \param{oldpath} si riferisce ad un link simbolico questo sarà rinominato; se
+\param{newpath} è un link simbolico verrà cancellato come qualunque altro
file. Infine qualora \param{oldpath} e \param{newpath} siano due nomi dello
stesso file lo standard POSIX prevede che la funzione non dia errore, e non
faccia nulla, lasciando entrambi i nomi; Linux segue questo standard, anche
-se, come fatto notare dal manuale delle \textit{glibc}, il comportamento più
+se, come fatto notare dal manuale delle \textit{glibc}, il comportamento più
ragionevole sarebbe quello di cancellare \param{oldpath}.
Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
-\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
-può esistere cioè nessun istante in cui un altro processo può trovare attivi
+\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
+può esistere cioè nessun istante in cui un altro processo può trovare attivi
entrambi i nomi dello stesso file, o, in caso di sostituzione di un file
esistente, non trovare quest'ultimo prima che la sostituzione sia stata
eseguita.
In ogni caso se \param{newpath} esiste e l'operazione fallisce per un qualche
motivo (come un crash del kernel), \func{rename} garantisce di lasciare
-presente un'istanza di \param{newpath}. Tuttavia nella sovrascrittura potrà
+presente un'istanza di \param{newpath}. Tuttavia nella sovrascrittura potrà
esistere una finestra in cui sia \param{oldpath} che \param{newpath} fanno
riferimento allo stesso file.
\label{sec:file_symlink}
Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea
-riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare
+riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare
soltanto per file che risiedono sullo stesso filesystem e solo per un
-filesystem di tipo Unix. Inoltre abbiamo visto che in Linux non è consentito
+filesystem di tipo Unix. Inoltre abbiamo visto che in Linux non è consentito
eseguire un link diretto ad una directory.
Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
come avviene in altri sistemi operativi, dei file speciali che contengono
-semplicemente il riferimento ad un altro file (o directory). In questo modo è
+semplicemente il riferimento ad un altro file (o directory). In questo modo è
possibile effettuare link anche attraverso filesystem diversi, a file posti in
filesystem che non supportano i link diretti, a delle directory, ed anche a
file che non esistono ancora.
Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal
-kernel\footnote{è uno dei diversi tipi di file visti in
+kernel\footnote{è uno dei diversi tipi di file visti in
tab.~\ref{tab:file_file_types}, contrassegnato come tale
nell'\textit{inode}, e riconoscibile dal valore del campo \var{st\_mode}
della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui
alcune funzioni di libreria (come \func{open} o \func{stat}) quando ricevono
come argomento un link simbolico vengono automaticamente applicate al file da
esso specificato. La funzione che permette di creare un nuovo link simbolico
-è \funcd{symlink}, ed il suo prototipo è:
+è \funcd{symlink}, ed il suo prototipo è:
\begin{prototype}{unistd.h}
{int symlink(const char *oldpath, const char *newpath)}
- Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
+ Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
\param{oldpath}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso la variabile \var{errno} assumerà i valori:
+ errore, nel qual caso la variabile \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EPERM}] il filesystem che contiene \param{newpath} non
supporta i link simbolici.
\item[\errcode{ENOENT}] una componente di \param{newpath} non esiste o
- \param{oldpath} è una stringa vuota.
- \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
- \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
+ \param{oldpath} è una stringa vuota.
+ \item[\errcode{EEXIST}] esiste già un file \param{newpath}.
+ \item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
lettura.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
-nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
+nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
che non esiste: in questo caso si ha quello che viene chiamato un
\textit{dangling link}, letteralmente un \textsl{link ciondolante}.
Come accennato i link simbolici sono risolti automaticamente dal kernel
all'invocazione delle varie system call; in tab.~\ref{tab:file_symb_effect} si
-è riportato un elenco dei comportamenti delle varie funzioni di libreria che
+è riportato un elenco dei comportamenti delle varie funzioni di libreria che
operano sui file nei confronti della risoluzione dei link simbolici,
specificando quali seguono il link simbolico e quali invece possono operare
direttamente sul suo contenuto.
\footnotetext{a partire dalla serie 2.0, e contrariamente a quanto indicato
dallo standard POSIX, si veda quanto detto in sez.~\ref{sec:file_link}.}
-Si noti che non si è specificato il comportamento delle funzioni che operano
+Si noti che non si è specificato il comportamento delle funzioni che operano
con i file descriptor, in quanto la risoluzione del link simbolico viene in
genere effettuata dalla funzione che restituisce il file descriptor
(normalmente la \func{open}, vedi sez.~\ref{sec:file_open}) e tutte le
\func{open} seguono i link simbolici, occorrono funzioni apposite per accedere
alle informazioni del link invece che a quelle del file a cui esso fa
riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa
-la funzione \funcd{readlink}, il cui prototipo è:
+la funzione \funcd{readlink}, il cui prototipo è:
\begin{prototype}{unistd.h}
{int readlink(const char *path, char *buff, size\_t size)}
Legge il contenuto del link simbolico indicato da \param{path} nel buffer
\bodydesc{La funzione restituisce il numero di caratteri letti dentro
\param{buff} o -1 per un errore, nel qual caso la variabile
- \var{errno} assumerà i valori:
+ \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{path} non è un link simbolico o \param{size}
- non è positiva.
+ \item[\errcode{EINVAL}] \param{path} non è un link simbolico o \param{size}
+ non è positiva.
\end{errlist}
ed inoltre \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{EACCES}, \errval{ELOOP}, \errval{EIO}, \errval{EFAULT} e
\label{fig:file_link_loop}
\end{figure}
-Un caso comune che si può avere con i link simbolici è la creazione dei
-cosiddetti \textit{loop}. La situazione è illustrata in
+Un caso comune che si può avere con i link simbolici è la creazione dei
+cosiddetti \textit{loop}. La situazione è illustrata in
fig.~\ref{fig:file_link_loop}, che riporta la struttura della directory
-\file{/boot}. Come si vede si è creato al suo interno un link simbolico che
+\file{/boot}. Come si vede si è creato al suo interno un link simbolico che
punta di nuovo a \file{/boot}.\footnote{il loop mostrato in
- fig.~\ref{fig:file_link_loop} è un usato per poter permettere a \cmd{grub}
+ fig.~\ref{fig:file_link_loop} è un usato per poter permettere a \cmd{grub}
(un bootloader in grado di leggere direttamente da vari filesystem il file
da lanciare come sistema operativo) di vedere i file contenuti nella
directory \file{/boot} con lo stesso \textit{pathname} con cui verrebbero
visti dal sistema operativo, anche se essi si trovano, come accade spesso,
su una partizione separata (che \cmd{grub}, all'avvio, vede come radice).}
-Questo può causare problemi per tutti quei programmi che effettuano la
+Questo può causare problemi per tutti quei programmi che effettuano la
scansione di una directory senza tener conto dei link simbolici, ad esempio se
lanciassimo un comando del tipo \code{grep -r linux *}, il loop nella
directory porterebbe il comando ad esaminare \file{/boot}, \file{/boot/boot},
-\file{/boot/boot/boot} e così via.
+\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
un \itindex{pathname} \textit{pathname} possano essere seguiti un numero
-limitato di link simbolici, il cui valore limite è specificato dalla costante
+limitato di link simbolici, il cui valore limite è specificato dalla costante
\const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
errore ed \var{errno} viene impostata al valore \errcode{ELOOP}.
-Un punto da tenere sempre presente è che, come abbiamo accennato, un link
-simbolico può fare riferimento anche ad un file che non esiste; ad esempio
+Un punto da tenere sempre presente è che, come abbiamo accennato, un link
+simbolico può fare riferimento anche ad un file che non esiste; ad esempio
possiamo creare un file temporaneo nella nostra directory con un link del
tipo:
\begin{verbatim}
$ ln -s /tmp/tmp_file temporaneo
\end{verbatim}%$
-anche se \file{/tmp/tmp\_file} non esiste. Questo può generare confusione, in
-quanto aprendo in scrittura \file{temporaneo} verrà creato
+anche se \file{/tmp/tmp\_file} non esiste. Questo può generare confusione, in
+quanto aprendo in scrittura \file{temporaneo} verrà creato
\file{/tmp/tmp\_file} e scritto; ma accedendo in sola lettura a
\file{temporaneo}, ad esempio con \cmd{cat}, otterremmo:
\begin{verbatim}
$ cat temporaneo
cat: temporaneo: No such file or directory
\end{verbatim}%$
-con un errore che può sembrare sbagliato, dato che un'ispezione con \cmd{ls}
+con un errore che può sembrare sbagliato, dato che un'ispezione con \cmd{ls}
ci mostrerebbe invece l'esistenza di \file{temporaneo}.
\subsection{La creazione e la cancellazione delle directory}
\label{sec:file_dir_creat_rem}
-Benché in sostanza le directory non siano altro che dei file contenenti
-elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle
+Benché in sostanza le directory non siano altro che dei file contenenti
+elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle
come file ordinari e devono essere create direttamente dal kernel attraverso
-una opportuna system call.\footnote{questo è quello che permette anche,
+una opportuna system call.\footnote{questo è quello che permette anche,
attraverso l'uso del VFS, l'utilizzo di diversi formati per la gestione dei
- suddetti elenchi.} La funzione usata per creare una directory è
-\funcd{mkdir}, ed il suo prototipo è:
+ suddetti elenchi.} La funzione usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/stat.h}
\headdecl{sys/types.h}
Crea una nuova directory.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EEXIST}] un file (o una directory) con quel nome esiste di
- già.
- \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory in
+ già.
+ \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory in
cui si vuole inserire la nuova directory.
\item[\errcode{EMLINK}] la directory in cui si vuole creare la nuova
directory contiene troppi file; sotto Linux questo normalmente non avviene
- perché il filesystem standard consente la creazione di un numero di file
+ perché il filesystem standard consente la creazione di un numero di file
maggiore di quelli che possono essere contenuti nel disco, ma potendo
- avere a che fare anche con filesystem di altri sistemi questo errore può
+ avere a che fare anche con filesystem di altri sistemi questo errore può
presentarsi.
- \item[\errcode{ENOSPC}] non c'è abbastanza spazio sul file system per creare
- la nuova directory o si è esaurita la quota disco dell'utente.
+ \item[\errcode{ENOSPC}] non c'è abbastanza spazio sul file system per creare
+ la nuova directory o si è esaurita la quota disco dell'utente.
\end{errlist}
ed inoltre anche \errval{EPERM}, \errval{EFAULT}, \errval{ENAMETOOLONG},
\errval{ENOENT}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
\errval{EROFS}.}
\end{functions}
-La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
-standard presenti in ogni directory (cioè ``\file{.}'' e ``\file{..}''), con
-il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato
+La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
+standard presenti in ogni directory (cioè ``\file{.}'' e ``\file{..}''), con
+il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato
sia come \itindex{pathname} \textit{pathname} assoluto che come
\itindex{pathname} \textit{pathname} relativo.
directory viene creata sono specificati dall'argomento \param{mode}, i cui
possibili valori sono riportati in tab.~\ref{tab:file_permission_const}; si
tenga presente che questi sono modificati dalla maschera di creazione dei file
-(si veda sez.~\ref{sec:file_perm_management}). La titolarità della nuova
-directory è impostata secondo quanto riportato in
+(si veda sez.~\ref{sec:file_perm_management}). La titolarità della nuova
+directory è impostata secondo quanto riportato in
sez.~\ref{sec:file_ownership_management}.
-La funzione che permette la cancellazione di una directory è invece
-\funcd{rmdir}, ed il suo prototipo è:
+La funzione che permette la cancellazione di una directory è invece
+\funcd{rmdir}, ed il suo prototipo è:
\begin{prototype}{sys/stat.h}{int rmdir(const char *dirname)}
Cancella una directory.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
directory, oppure la directory che contiene \param{dirname} ha lo
\itindex{sticky~bit} \textit{sticky bit} impostato e l'user-ID effettivo
del processo non corrisponde al proprietario della directory.
- \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
- che contiene la directory che si vuole cancellare, o non c'è il permesso
+ \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
+ che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
+ \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
radice di qualche processo.
- \item[\errcode{ENOTEMPTY}] la directory non è vuota.
+ \item[\errcode{ENOTEMPTY}] la directory non è vuota.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP}, \errval{EROFS}.}
\end{prototype}
La funzione cancella la directory \param{dirname}, che deve essere vuota (la
-directory deve cioè contenere soltanto le due voci standard ``\file{.}'' e
-``\file{..}''). Il nome può essere indicato con il \itindex{pathname}
+directory deve cioè contenere soltanto le due voci standard ``\file{.}'' e
+``\file{..}''). Il nome può essere indicato con il \itindex{pathname}
\textit{pathname} assoluto o relativo.
-La modalità con cui avviene la cancellazione è analoga a quella di
+La modalità con cui avviene la cancellazione è analoga a quella di
\func{unlink}: fintanto che il numero di link \itindex{inode}
all'\textit{inode} della directory non diventa nullo e nessun processo ha la
directory aperta lo spazio occupato su disco non viene rilasciato. Se un
processo ha la directory aperta la funzione rimuove il link \itindex{inode}
all'\textit{inode} e nel caso sia l'ultimo, pure le voci standard ``\file{.}''
-e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi
+e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi
file nella directory.
\index{file!di~dispositivo|(}
Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
-sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
+sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
degli altri tipi di file speciali, come i file di dispositivo, le fifo ed i
socket (questi ultimi sono un caso a parte, essendo associati anche alla
comunicazione via rete, per cui ci saranno trattati in dettaglio a partire da
cap.~\ref{cha:socket_intro}).
La manipolazione delle caratteristiche di questi diversi tipi di file e la
-loro cancellazione può essere effettuata con le stesse funzioni che operano
+loro cancellazione può essere effettuata con le stesse funzioni che operano
sui file regolari; ma quando li si devono creare sono necessarie delle
-funzioni apposite. La prima di queste funzioni è \funcd{mknod}, il cui
-prototipo è:
+funzioni apposite. La prima di queste funzioni è \funcd{mknod}, il cui
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
Crea un \textit{inode} del tipo specificato sul filesystem.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
- l'\texttt{inode}, o il filesystem su cui si è cercato di
+ l'\texttt{inode}, o il filesystem su cui si è cercato di
creare \param{pathname} non supporta l'operazione.
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
fifo, un socket o un dispositivo.
- \item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
+ \item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
\errval{ENOENT}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
La funzione, come suggerisce il nome, permette di creare un ``\textsl{nodo}''
sul filesystem, e viene in genere utilizzata per creare i file di dispositivo,
-ma si può usare anche per creare file regolari. L'argomento
+ma si può usare anche per creare file regolari. L'argomento
\param{mode} specifica sia il tipo di file che si vuole creare che i relativi
permessi, secondo i valori riportati in tab.~\ref{tab:file_mode_flags}, che
vanno combinati con un OR binario. I permessi sono comunque modificati nella
maniera usuale dal valore di \itindex{umask} \textit{umask} (si veda
sez.~\ref{sec:file_perm_management}).
-Per il tipo di file può essere specificato solo uno fra i seguenti valori:
-\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
+Per il tipo di file può essere specificato solo uno fra i seguenti valori:
+\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
\const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un
dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO}
-per una fifo;\footnote{con Linux la funzione non può essere usata per creare
+per una fifo;\footnote{con Linux la funzione non può essere usata per creare
directory o link simbolici, si dovranno usare le funzioni \func{mkdir} e
- \func{symlink} a questo dedicate.} un valore diverso comporterà l'errore
+ \func{symlink} a questo dedicate.} un valore diverso comporterà l'errore
\errcode{EINVAL}.
Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire
-o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
+o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo
-valore verrà ignorato. Solo l'amministratore può creare un file di
+valore verrà ignorato. Solo l'amministratore può creare un file di
dispositivo usando questa funzione (il processo deve avere la
\itindex{capabilities} \textit{capability} \const{CAP\_MKNOD}), ma in
-Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è
- prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e
+Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è
+ prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e
4.4BSD, ma esistono differenze nei comportamenti e nei codici di errore,
- tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la
+ tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la
definisce portabile solo quando viene usata per creare delle fifo, ma
comunque deprecata essendo utilizzabile a tale scopo la specifica
\func{mkfifo}.} l'uso per la creazione di un file ordinario, di una fifo o
-di un socket è consentito anche agli utenti normali.
+di un socket è consentito anche agli utenti normali.
I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno
al proprietario e al gruppo del processo che li ha creati, a meno che non si
\itindex{inode} l'\textit{inode}.
Nella creazione di un file di dispositivo occorre poi specificare
-correttamente il valore di \param{dev}; questo infatti è di tipo
-\type{dev\_t}, che è un tipo primitivo (vedi
+correttamente il valore di \param{dev}; questo infatti è di tipo
+\type{dev\_t}, che è un tipo primitivo (vedi
tab.~\ref{tab:intro_primitive_types}) riservato per indicare un
\textsl{numero} di dispositivo; il kernel infatti identifica ciascun
dispositivo con un valore numerico. Originariamente questo era un intero a 16
Il \itindex{major~number} \textit{major number} identifica una classe di
dispositivi (ad esempio la seriale, o i dischi IDE) e serve in sostanza per
-indicare al kernel quale è il modulo che gestisce quella classe di
+indicare al kernel quale è il modulo che gestisce quella classe di
dispositivi; per identificare uno specifico dispositivo di quella classe (ad
esempio una singola porta seriale, o una partizione di un disco) si usa invece
il \itindex{minor~number} \textit{minor number}. L'elenco aggiornato di questi
-numeri con le relative corrispondenze ai vari dispositivi può essere trovato
+numeri con le relative corrispondenze ai vari dispositivi può essere trovato
nel file \texttt{Documentation/devices.txt} allegato alla documentazione dei
sorgenti del kernel.
Data la crescita nel numero di dispositivi supportati, ben presto il limite
-massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
-serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
+massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
+serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
\type{dev\_t}, con delle dimensioni passate a 12 bit per il
\itindex{major~number} \textit{major number} e 20 bit per il
-\itindex{minor~number} \textit{minor number}. La transizione però ha anche
-comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di
-specificare il numero tramite delle opportune macro, così da non avere
-problemi di compatibilità con eventuali ulteriori estensioni.
+\itindex{minor~number} \textit{minor number}. La transizione però ha anche
+comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di
+specificare il numero tramite delle opportune macro, così da non avere
+problemi di compatibilità con eventuali ulteriori estensioni.
Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
automaticamente incluso quando si include \file{sys/types.h}; si possono
\param{dev}.
\end{functions}
\noindent mentre una volta che siano noti \itindex{major~number} \textit{major
- number} e \itindex{minor~number} \textit{minor number} si potrà costruire il
+ number} e \itindex{minor~number} \textit{minor number} si potrà costruire il
relativo identificativo con la macro \macro{makedev}:
\begin{functions}
\headdecl{sys/types.h}
\index{file!di~dispositivo|)}
-Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica
+Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica
per creare una fifo (tratteremo le fifo in in sez.~\ref{sec:ipc_named_pipe});
-la funzione è \funcd{mkfifo} ed il suo prototipo è:
+la funzione è \funcd{mkfifo} ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{sys/stat.h}
Crea una fifo.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà i valori \errval{EACCES},
+ errore, nel qual caso \var{errno} assumerà i valori \errval{EACCES},
\errval{EEXIST}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC},
\errval{ENOTDIR} e \errval{EROFS}.}
\end{functions}
\subsection{Accesso alle directory}
\label{sec:file_dir_read}
-Benché le directory alla fine non siano altro che dei file che contengono
+Benché le directory alla fine non siano altro che dei file che contengono
delle liste di nomi ed \itindex{inode} \textit{inode}, per il ruolo che
rivestono nella struttura del sistema, non possono essere trattate come dei
normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del
-filesystem, solo il kernel può scrivere il contenuto di una directory, e non
-può essere un processo a inserirvi direttamente delle voci con le usuali
+filesystem, solo il kernel può scrivere il contenuto di una directory, e non
+può essere un processo a inserirvi direttamente delle voci con le usuali
funzioni di scrittura.
-Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
+Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
kernel, sono molte le situazioni in cui i processi necessitano di poterne
-leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
-in sez.~\ref{sec:file_open} che è possibile aprire una directory come se fosse
+leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
+in sez.~\ref{sec:file_open} che è possibile aprire una directory come se fosse
un file, anche se solo in sola lettura) in generale il formato con cui esse
-sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
+sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
in tab.~\ref{tab:file_file_operations}, il VFS del kernel prevede una apposita
funzione per la lettura delle directory.
Tutto questo si riflette nello standard POSIX\footnote{le funzioni sono
previste pure in BSD e SVID.} che ha introdotto una apposita interfaccia per
la lettura delle directory, basata sui cosiddetti \textit{directory stream}
-(chiamati così per l'analogia con i file stream dell'interfaccia standard ANSI
+(chiamati così per l'analogia con i file stream dell'interfaccia standard ANSI
C di cap.~\ref{cha:files_std_interface}). La prima funzione di questa
-interfaccia è \funcd{opendir}, il cui prototipo è:
+interfaccia è \funcd{opendir}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
\bodydesc{La funzione restituisce un puntatore al \textit{directory stream}
in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
- assumerà i valori \errval{EACCES}, \errval{EMFILE}, \errval{ENFILE},
+ assumerà i valori \errval{EACCES}, \errval{EMFILE}, \errval{ENFILE},
\errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}.}
\end{functions}
La funzione apre un \textit{directory stream} per la directory
\param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
-è il \index{tipo!opaco} tipo opaco usato dalle librerie per gestire i
+è il \index{tipo!opaco} tipo opaco usato dalle librerie per gestire i
\textit{directory stream}) da usare per tutte le operazioni successive, la
funzione inoltre posiziona lo stream sulla prima voce contenuta nella
directory.
-Dato che le directory sono comunque dei file, in alcuni casi può servire
+Dato che le directory sono comunque dei file, in alcuni casi può servire
conoscere il \textit{file descriptor} associato ad un \textit{directory
- stream}, a questo scopo si può usare la funzione \funcd{dirfd}, il cui
-prototipo è:
+ stream}, a questo scopo si può usare la funzione \funcd{dirfd}, il cui
+prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
caso di successo e -1 in caso di errore.}
\end{functions}
-La funzione\footnote{questa funzione è una estensione di BSD non presente in
- POSIX, introdotta con BSD 4.3-Reno; è presente in Linux con le libc5 (a
+La funzione\footnote{questa funzione è una estensione di BSD non presente in
+ POSIX, introdotta con BSD 4.3-Reno; è presente in Linux con le libc5 (a
partire dalla versione 5.1.2) e con le \acr{glibc}.} restituisce il file
-descriptor associato al \textit{directory stream} \param{dir}, essa è
+descriptor associato al \textit{directory stream} \param{dir}, essa è
disponibile solo definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}. Di
solito si utilizza questa funzione in abbinamento alla funzione \func{fchdir}
per cambiare la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) a
quella relativa allo stream che si sta esaminando.
-Viceversa se si è aperto un file descriptor corrispondente ad una directory è
+Viceversa se si è aperto un file descriptor corrispondente ad una directory è
possibile associarvi un \textit{directory stream} con la funzione
-\funcd{fopendir},\footnote{questa funzione è però disponibile solo a partire
+\funcd{fopendir},\footnote{questa funzione è però disponibile solo a partire
dalla versione 2.4 delle \acr{glibc}, e pur essendo candidata per
- l'inclusione nella successiva revisione dello standard POSIX.1-2001, non è
- ancora presente in nessuna specifica formale.} il cui prototipo è:
+ l'inclusione nella successiva revisione dello standard POSIX.1-2001, non è
+ ancora presente in nessuna specifica formale.} il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{dirent.h}
\bodydesc{La funzione restituisce un puntatore al \textit{directory stream}
in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
- assumerà il valore \errval{EBADF}.}
+ assumerà il valore \errval{EBADF}.}
\end{functions}
-La funzione è identica a \func{opendir}, ma ritorna un \textit{directory
+La funzione è identica a \func{opendir}, ma ritorna un \textit{directory
stream} facendo riferimento ad un file descriptor \param{fd} che deve essere
-stato aperto in precedenza e la funzione darà un errore qualora questo non
-corrisponda ad una directory. Una volta utilizzata il file descriptor verrà
+stato aperto in precedenza e la funzione darà un errore qualora questo non
+corrisponda ad una directory. Una volta utilizzata il file descriptor verrà
usato dalle funzioni che operano sul \textit{directory stream} e non deve
-essere più utilizzato direttamente all'interno del proprio programma.
+essere più utilizzato direttamente all'interno del proprio programma.
Una volta che si sia aperto un \textit{directory stream} la lettura del
contenuto della directory viene effettuata attraverso la funzione
-\funcd{readdir}, il suo prototipo è:
+\funcd{readdir}, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
\bodydesc{La funzione restituisce il puntatore alla struttura contenente i
dati in caso di successo e \val{NULL} altrimenti, in caso di descrittore
- non valido \var{errno} assumerà il valore \errval{EBADF}, il valore
+ non valido \var{errno} assumerà il valore \errval{EBADF}, il valore
\val{NULL} viene restituito anche quando si raggiunge la fine dello
stream.}
\end{functions}
La funzione legge la voce corrente nella directory, posizionandosi sulla voce
successiva. Pertanto se si vuole leggere l'intero contenuto di una directory
-occorrerà ripetere l'esecuzione della funzione fintanto che non si siano
+occorrerà ripetere l'esecuzione della funzione fintanto che non si siano
esaurite tutte le voci in essa presenti.
I dati vengono memorizzati in una struttura \struct{dirent} (la cui
-definizione\footnote{la definizione è quella usata a Linux, che si trova nel
+definizione\footnote{la definizione è quella usata a Linux, che si trova nel
file \file{/usr/include/bits/dirent.h}, essa non contempla la presenza del
campo \var{d\_namlen} che indica la lunghezza del nome del file (ed infatti
- la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).} è riportata in
+ la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).} è riportata in
fig.~\ref{fig:file_dirent_struct}). La funzione restituisce il puntatore alla
-struttura; si tenga presente però che quest'ultima è allocata staticamente,
+struttura; si tenga presente però che quest'ultima è allocata staticamente,
per cui viene sovrascritta tutte le volte che si ripete la lettura di una voce
sullo stesso \textit{directory stream}.
Di questa funzione esiste anche una versione \index{funzioni!rientranti}
rientrante, \func{readdir\_r}, che non usa una struttura allocata
-staticamente, e può essere utilizzata anche con i \itindex{thread}
-\textit{thread}, il suo prototipo è:
+staticamente, e può essere utilizzata anche con i \itindex{thread}
+\textit{thread}, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
\itindex{value~result~argument} \textit{value result argument}) l'indirizzo
dove sono stati salvati i dati, che di norma corrisponde a quello della
struttura precedentemente allocata e specificata dall'argomento \param{entry}
-(anche se non è assicurato che la funzione usi lo spazio fornito dall'utente).
+(anche se non è assicurato che la funzione usi lo spazio fornito dall'utente).
\begin{figure}[!htb]
\footnotesize \centering
I vari campi di \struct{dirent} contengono le informazioni relative alle voci
presenti nella directory; sia BSD che SVr4\footnote{lo standard POSIX prevede
invece solo la presenza del campo \var{d\_fileno}, identico \var{d\_ino},
- che in Linux è definito come alias di quest'ultimo. Il campo \var{d\_name} è
+ che in Linux è definito come alias di quest'ultimo. Il campo \var{d\_name} è
considerato dipendente dall'implementazione.} prevedono che siano sempre
presenti il campo \var{d\_name}, che contiene il nome del file nella forma di
una stringa terminata da uno zero,\footnote{lo standard POSIX non specifica
una lunghezza, ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del
- campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
+ campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
byte usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero
-di \itindex{inode} \textit{inode} cui il file è associato (di solito
+di \itindex{inode} \textit{inode} cui il file è associato (di solito
corrisponde al campo \var{st\_ino} di \struct{stat}).
-La presenza di ulteriori campi opzionali è segnalata dalla definizione di
-altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
+La presenza di ulteriori campi opzionali è segnalata dalla definizione di
+altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
il nome del relativo campo; nel nostro caso sono definite le macro
\macro{\_DIRENT\_HAVE\_D\_TYPE}, \macro{\_DIRENT\_HAVE\_D\_OFF} e
\macro{\_DIRENT\_HAVE\_D\_RECLEN}.
varie voci, spostarsi all'interno dello stream usando la funzione
\funcd{seekdir},\footnote{sia questa funzione che \func{telldir}, sono
estensioni prese da BSD, non previste dallo standard POSIX.} il cui
-prototipo è:
+prototipo è:
\begin{prototype}{dirent.h}{void seekdir(DIR *dir, off\_t offset)}
Cambia la posizione all'interno di un \textit{directory stream}.
\end{prototype}
-La funzione non ritorna nulla e non segnala errori, è però necessario che il
+La funzione non ritorna nulla e non segnala errori, è però necessario che il
valore dell'argomento \param{offset} sia valido per lo stream \param{dir};
esso pertanto deve essere stato ottenuto o dal valore di \var{d\_off} di
\struct{dirent} o dal valore restituito dalla funzione \funcd{telldir}, che
-legge la posizione corrente; il prototipo di quest'ultima è:
+legge la posizione corrente; il prototipo di quest'ultima è:
\begin{prototype}{dirent.h}{off\_t telldir(DIR *dir)}
Ritorna la posizione corrente in un \textit{directory stream}.
\end{prototype}
La sola funzione di posizionamento nello stream prevista dallo standard POSIX
-è \funcd{rewinddir}, che riporta la posizione a quella iniziale; il suo
-prototipo è:
+è \funcd{rewinddir}, che riporta la posizione a quella iniziale; il suo
+prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
\end{functions}
-Una volta completate le operazioni si può chiudere il \textit{directory
- stream} con la funzione \funcd{closedir}, il cui prototipo è:
+Una volta completate le operazioni si può chiudere il \textit{directory
+ stream} con la funzione \funcd{closedir}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
qual caso \var{errno} assume il valore \errval{EBADF}.}
\end{functions}
-A parte queste funzioni di base in BSD 4.3 è stata introdotta un'altra
+A parte queste funzioni di base in BSD 4.3 è stata introdotta un'altra
funzione che permette di eseguire una scansione completa (con tanto di ricerca
-ed ordinamento) del contenuto di una directory; la funzione è
-\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
- \acr{libc4}.} ed il suo prototipo è:
+ed ordinamento) del contenuto di una directory; la funzione è
+\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
+ \acr{libc4}.} ed il suo prototipo è:
\begin{prototype}{dirent.h}{int scandir(const char *dir,
struct dirent ***namelist, int(*filter)(const struct dirent *),
int(*compar)(const struct dirent **, const struct dirent **))}
\end{prototype}
Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il
-prototipo non è molto comprensibile; queste funzioni però sono quelle che
+prototipo non è molto comprensibile; queste funzioni però sono quelle che
controllano rispettivamente la selezione di una voce (quella passata con
l'argomento \param{filter}) e l'ordinamento di tutte le voci selezionate
(quella specificata dell'argomento \param{compar}).
Qualora si specifichi un valore \val{NULL} per l'argomento \func{filter} non
viene fatta nessuna selezione e si ottengono tutte le voci presenti.
-Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
+Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
del riordinamento possono essere personalizzate usando la funzione
\param{compar} come criterio di ordinamento di \func{qsort}, la funzione
prende come argomenti le due strutture \struct{dirent} da confrontare
maggiore del secondo.}
\end{functions}
-La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
-\acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{libc5} usa però come
+La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
+\acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{libc5} usa però come
argomenti dei puntatori a delle strutture \struct{dirent}; le glibc usano il
prototipo originario di BSD, mostrato anche nella definizione, che prevede
puntatori a \ctyp{void}.} e deve essere specificata come argomento
estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
\func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
-ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
+ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
\texttt{file10} viene comunque dopo \texttt{file4}.)
-Un semplice esempio dell'uso di queste funzioni è riportato in
-fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
+Un semplice esempio dell'uso di queste funzioni è riportato in
+fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
programma che, usando la funzione di scansione illustrata in
fig.~\ref{fig:file_dirscan}, stampa i nomi dei file contenuti in una directory
e la relativa dimensione (in sostanza una versione semplificata del comando
\label{fig:file_my_ls}
\end{figure}
-Il programma è estremamente semplice; in fig.~\ref{fig:file_my_ls} si è omessa
+Il programma è estremamente semplice; in fig.~\ref{fig:file_my_ls} si è omessa
la parte di gestione delle opzioni (che prevede solo l'uso di una funzione per
-la stampa della sintassi, anch'essa omessa) ma il codice completo potrà essere
+la stampa della sintassi, anch'essa omessa) ma il codice completo potrà essere
trovato coi sorgenti allegati nel file \file{myls.c}.
In sostanza tutto quello che fa il programma, dopo aver controllato
-(\texttt{\small 10--13}) di avere almeno un argomento (che indicherà la
-directory da esaminare) è chiamare (\texttt{\small 14}) la funzione
+(\texttt{\small 10--13}) di avere almeno un argomento (che indicherà la
+directory da esaminare) è chiamare (\texttt{\small 14}) la funzione
\func{DirScan} per eseguire la scansione, usando la funzione \code{do\_ls}
(\texttt{\small 20--26}) per fare tutto il lavoro.
Quest'ultima si limita (\texttt{\small 23}) a chiamare \func{stat} sul file
-indicato dalla directory entry passata come argomento (il cui nome è appunto
+indicato dalla directory entry passata come argomento (il cui nome è appunto
\var{direntry->d\_name}), memorizzando in una opportuna struttura \var{data} i
dati ad esso relativi, per poi provvedere (\texttt{\small 24}) a stampare il
nome del file e la dimensione riportata in \var{data}.
-Dato che la funzione verrà chiamata all'interno di \func{DirScan} per ogni
-voce presente questo è sufficiente a stampare la lista completa dei file e
+Dato che la funzione verrà chiamata all'interno di \func{DirScan} per ogni
+voce presente questo è sufficiente a stampare la lista completa dei file e
delle relative dimensioni. Si noti infine come si restituisca sempre 0 come
valore di ritorno per indicare una esecuzione senza errori.
\label{fig:file_dirscan}
\end{figure}
-Tutto il grosso del lavoro è svolto dalla funzione \func{DirScan}, riportata
-in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e permette
+Tutto il grosso del lavoro è svolto dalla funzione \func{DirScan}, riportata
+in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e permette
di eseguire una funzione, passata come secondo argomento, su tutte le voci di
una directory. La funzione inizia con l'aprire (\texttt{\small 19--23}) uno
stream sulla directory passata come primo argomento, stampando un messaggio in
caso di errore.
-Il passo successivo (\texttt{\small 24--25}) è cambiare directory di lavoro
+Il passo successivo (\texttt{\small 24--25}) è cambiare directory di lavoro
(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzione
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
+\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
(\texttt{\small 27--31}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
+all'interno della directory.\footnote{questo è essenziale al funzionamento
della funzione \code{do\_ls} (e ad ogni funzione che debba usare il campo
\var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
struttura \struct{dirent} sono sempre relativi alla directory in questione,
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
-directory è molto semplice; si legge una voce alla volta (\texttt{\small 27})
+directory è molto semplice; si legge una voce alla volta (\texttt{\small 27})
all'interno di una istruzione di \code{while} e fintanto che si riceve una
-voce valida (cioè un puntatore diverso da \val{NULL}) si esegue
+voce valida (cioè un puntatore diverso da \val{NULL}) si esegue
(\texttt{\small 27}) la funzione di elaborazione \var{compare} (che nel nostro
-caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
+caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
28}) qualora questa presenti una anomalia (identificata da un codice di
ritorno negativo). Una volta terminato il ciclo la funzione si conclude con la
chiusura (\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo
- subito dopo la chiamata, questo non servirebbe, in generale però
- l'operazione è necessaria, dato che la funzione può essere invocata molte
+ subito dopo la chiamata, questo non servirebbe, in generale però
+ l'operazione è necessaria, dato che la funzione può essere invocata molte
volte all'interno dello stesso processo, per cui non chiudere i
\textit{directory stream} comporterebbe un consumo progressivo di risorse,
con conseguente rischio di esaurimento delle stesse.} e la restituzione
\itindbeg{pathname}
-Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
+Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
- della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
+ della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
precisamente nel campo \texttt{pwd} della sotto-struttura
- \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
+ \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
\textsl{directory di lavoro} (in inglese \textit{current working directory}).
-La directory di lavoro è quella da cui si parte quando un
-\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
+La directory di lavoro è quella da cui si parte quando un
+\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
dove il ``\textsl{relativa}'' fa riferimento appunto a questa directory.
Quando un utente effettua il login, questa directory viene impostata alla
sez.~\ref{sec:proc_fork}), la directory corrente della shell diventa anche la
directory corrente di qualunque comando da essa lanciato.
-Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode}
+Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode}
dell'\textit{inode} della directory di lavoro, per ottenerne il
\textit{pathname} occorre usare una apposita funzione di libreria,
-\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
+\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
dalla versione 2.1.9, in precedenza il valore doveva essere ottenuto tramite
il filesystem \texttt{/proc} da \procfile{/proc/self/cwd}.} il cui prototipo
-è:
+è:
\begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
Legge il \textit{pathname} della directory di lavoro corrente.
\bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
\val{NULL} se fallisce, in quest'ultimo caso la variabile
- \var{errno} è impostata con i seguenti codici di errore:
+ \var{errno} è impostata con i seguenti codici di errore:
\begin{errlist}
- \item[\errcode{EINVAL}] l'argomento \param{size} è zero e \param{buffer} non
- è nullo.
- \item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
+ \item[\errcode{EINVAL}] l'argomento \param{size} è zero e \param{buffer} non
+ è nullo.
+ \item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
lunghezza del \textit{pathname}.
\item[\errcode{EACCES}] manca il permesso di lettura o di ricerca su uno dei
- componenti del \textit{pathname} (cioè su una delle directory superiori
+ componenti del \textit{pathname} (cioè su una delle directory superiori
alla corrente).
- \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata.
+ \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata.
\end{errlist}}
\end{prototype}
lavoro corrente nella stringa puntata da \param{buffer}, che deve essere
precedentemente allocata, per una dimensione massima di \param{size}. Il
buffer deve essere sufficientemente largo da poter contenere il
-\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
+\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
un errore.
-Si può anche specificare un puntatore nullo come
-\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
- supportata da Linux e dalla \acr{glibc}.} nel qual caso la stringa sarà
+Si può anche specificare un puntatore nullo come
+\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
+ supportata da Linux e dalla \acr{glibc}.} nel qual caso la stringa sarà
allocata automaticamente per una dimensione pari a \param{size} qualora questa
sia diversa da zero, o della lunghezza esatta del \textit{pathname}
altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
volta cessato il suo utilizzo.
Di questa funzione esiste una versione \code{char *getwd(char *buffer)} fatta
-per compatibilità all'indietro con BSD, che non consente di specificare la
+per compatibilità all'indietro con BSD, che non consente di specificare la
dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \const{PATH\_MAX} (di solito 256 byte, vedi
-sez.~\ref{sec:sys_limits}); il problema è che in Linux non esiste una
-dimensione superiore per un \textit{pathname}, per cui non è detto che il
-buffer sia sufficiente a contenere il nome del file, e questa è la ragione
-principale per cui questa funzione è deprecata.
+sez.~\ref{sec:sys_limits}); il problema è che in Linux non esiste una
+dimensione superiore per un \textit{pathname}, per cui non è detto che il
+buffer sia sufficiente a contenere il nome del file, e questa è la ragione
+principale per cui questa funzione è deprecata.
-Un uso comune di \func{getcwd} è quello di salvare la directory di lavoro
+Un uso comune di \func{getcwd} è quello di salvare la directory di lavoro
iniziale per poi potervi tornare in un tempo successivo, un metodo alternativo
-più veloce, se non si è a corto di file descriptor, è invece quello di aprire
+più veloce, se non si è a corto di file descriptor, è invece quello di aprire
la directory corrente (vale a dire ``\texttt{.}'') e tornarvi in seguito con
\func{fchdir}.
-Una seconda usata per ottenere la directory di lavoro è \code{char
- *get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
+Una seconda usata per ottenere la directory di lavoro è \code{char
+ *get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
\code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
+della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
attraverso eventuali link simbolici.
-Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
+Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
-\textit{change directory}, il suo prototipo è:
+\textit{change directory}, il suo prototipo è:
\begin{prototype}{unistd.h}{int chdir(const char *pathname)}
Cambia la directory di lavoro in \param{pathname}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
- nel qual caso \var{errno} assumerà i valori:
+ nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOTDIR}] non si è specificata una directory.
+ \item[\errcode{ENOTDIR}] non si è specificata una directory.
\item[\errcode{EACCES}] manca il permesso di ricerca su uno dei componenti
di \param{path}.
\end{errlist}
\noindent ed ovviamente \param{pathname} deve indicare una directory per la
quale si hanno i permessi di accesso.
-Dato che anche le directory sono file, è possibile riferirsi ad esse anche
+Dato che anche le directory sono file, è possibile riferirsi ad esse anche
tramite il file descriptor, e non solo tramite il \textit{pathname}, per fare
-questo si usa \funcd{fchdir}, il cui prototipo è:
+questo si usa \funcd{fchdir}, il cui prototipo è:
\begin{prototype}{unistd.h}{int fchdir(int fd)}
Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
\textit{pathname}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, in caso di errore \var{errno} assumerà i valori \errval{EBADF} o
+ errore, in caso di errore \var{errno} assumerà i valori \errval{EBADF} o
\errval{EACCES}.}
\end{prototype}
\noindent anche in questo caso \param{fd} deve essere un file descriptor
valido che fa riferimento ad una directory. Inoltre l'unico errore di accesso
-possibile (tutti gli altri sarebbero occorsi all'apertura di \param{fd}), è
+possibile (tutti gli altri sarebbero occorsi all'apertura di \param{fd}), è
quello in cui il processo non ha il permesso di accesso alla directory
specificata da \param{fd}.
\subsection{I file temporanei}
\label{sec:file_temp_file}
-In molte occasioni è utile poter creare dei file temporanei; benché la cosa
-sembri semplice, in realtà il problema è più sottile di quanto non appaia a
+In molte occasioni è utile poter creare dei file temporanei; benché la cosa
+sembri semplice, in realtà il problema è più sottile di quanto non appaia a
prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
creare il file dopo aver controllato che questo non esista, nel momento fra il
controllo e la creazione si ha giusto lo spazio per una possibile
sez.~\ref{sec:proc_race_cond}).
Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
-di cui si abbia certezza di unicità (al momento della generazione); la prima
-di queste funzioni è \funcd{tmpnam} il cui prototipo è:
+di cui si abbia certezza di unicità (al momento della generazione); la prima
+di queste funzioni è \funcd{tmpnam} il cui prototipo è:
\begin{prototype}{stdio.h}{char *tmpnam(char *string)}
Restituisce il puntatore ad una stringa contente un nome di file valido e
non esistente al momento dell'invocazione.
\bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
\val{NULL} in caso di fallimento. Non sono definiti errori.}
\end{prototype}
-\noindent se si è passato un puntatore \param{string} non nullo questo deve
+\noindent se si è passato un puntatore \param{string} non nullo questo deve
essere di dimensione \const{L\_tmpnam} (costante definita in \file{stdio.h},
-come \const{P\_tmpdir} e \const{TMP\_MAX}) ed il nome generato vi verrà
-copiato automaticamente; altrimenti il nome sarà generato in un buffer statico
-interno che verrà sovrascritto ad una chiamata successiva. Successive
+come \const{P\_tmpdir} e \const{TMP\_MAX}) ed il nome generato vi verrà
+copiato automaticamente; altrimenti il nome sarà generato in un buffer statico
+interno che verrà sovrascritto ad una chiamata successiva. Successive
invocazioni della funzione continueranno a restituire nomi unici fino ad un
massimo di \const{TMP\_MAX} volte. Al nome viene automaticamente aggiunto come
prefisso la directory specificata da \const{P\_tmpdir}.
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
-il file esplicitamente, il suo prototipo è:
+il file esplicitamente, il suo prototipo è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
Restituisce il puntatore ad una stringa contente un nome di file valido e
non esistente al momento dell'invocazione.
\end{prototype}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
ricordarsi di disallocare con \code{free} il puntatore che restituisce.
L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
nome provvisorio. La funzione assegna come directory per il file temporaneo
(verificando che esista e sia accessibili), la prima valida delle seguenti:
\begin{itemize}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
- definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
+\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+ definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
\item Il valore della costante \const{P\_tmpdir}.
\item la directory \file{/tmp}.
\end{itemize}
-In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
+In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
ottenere un nome duplicato, nulla assicura che un altro processo non possa
avere creato, fra l'ottenimento del nome e l'apertura del file, un altro file
con lo stesso nome; per questo motivo quando si usa il nome ottenuto da una di
-queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
-(cioè con l'opzione \const{O\_EXCL} per i file descriptor o con il flag
-\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
+queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
+(cioè con l'opzione \const{O\_EXCL} per i file descriptor o con il flag
+\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
esistente.
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
-maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
+maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
\begin{prototype}{stdio.h}{FILE *tmpfile (void)}
Restituisce un file temporaneo aperto in lettura/scrittura.
\bodydesc{La funzione ritorna il puntatore allo stream associato al file
temporaneo in caso di successo e \val{NULL} in caso di errore, nel qual
- caso \var{errno} assumerà i valori:
+ caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
- \item[\errcode{EEXIST}] non è stato possibile generare un nome univoco.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EEXIST}] non è stato possibile generare un nome univoco.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{EMFILE}, \errval{ENFILE},
\errval{ENOSPC}, \errval{EROFS} e \errval{EACCES}.}
\end{prototype}
-La funzione restituisce direttamente uno stream già aperto (in modalità
+La funzione restituisce direttamente uno stream già aperto (in modalità
\code{r+b}, si veda sez.~\ref{sec:file_fopen}) e pronto per l'uso, che viene
automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
-standard non specifica in quale directory verrà aperto il file, ma le
+standard non specifica in quale directory verrà aperto il file, ma le
\acr{glibc} prima tentano con \const{P\_tmpdir} e poi con \file{/tmp}. Questa
-funzione è \index{funzioni!rientranti} rientrante e non soffre di problemi di
+funzione è \index{funzioni!rientranti} rientrante e non soffre di problemi di
\itindex{race~condition} \textit{race condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
modificano una stringa di input che serve da modello e che deve essere
conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice
-unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
-il suo prototipo è:
+unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
+il suo prototipo è:
\begin{prototype}{stlib.h}{char *mktemp(char *template)}
Genera un filename univoco sostituendo le \code{XXXXXX} finali di
\param{template}.
\bodydesc{La funzione ritorna il puntatore \param{template} in caso di
successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
- assumerà i valori:
+ assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
\end{errlist}}
\end{prototype}
\noindent dato che \param{template} deve poter essere modificata dalla
-funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
+funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
alle possibili \itindex{race~condition} \textit{race condition} date per
\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
-del processo più una lettera, il che mette a disposizione solo 26 possibilità
+del processo più una lettera, il che mette a disposizione solo 26 possibilità
diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
-Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
+Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
usata.
-La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
+La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
\func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
-prototipo è:
+prototipo è:
\begin{prototype}{stlib.h}{int mkstemp(char *template)}
Genera un file temporaneo con un nome ottenuto sostituendo le \code{XXXXXX}
finali di \param{template}.
\bodydesc{La funzione ritorna il file descriptor in caso successo e
- -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
+ -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
- \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
- contenuto di \param{template} è indefinito.
+ \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
+ contenuto di \param{template} è indefinito.
\end{errlist}}
\end{prototype}
-\noindent come per \func{mktemp} anche in questo caso \param{template} non può
+\noindent come per \func{mktemp} anche in questo caso \param{template} non può
essere una stringa costante. La funzione apre un file in lettura/scrittura con
la funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
sez.~\ref{sec:file_open}), in questo modo al ritorno della funzione si ha la
certezza di essere i soli utenti del file. I permessi sono impostati al valore
-\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
+\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
versioni precedenti delle \acr{glibc} e le vecchie \acr{libc5} e \acr{libc4}
usavano il valore \code{0666} che permetteva a chiunque di leggere i
contenuti del file.} (si veda sez.~\ref{sec:file_perm_overview}).
-In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
+In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,
-\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
+\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
\begin{prototype}{stlib.h}{char *mkdtemp(char *template)}
- Genera una directory temporaneo il cui nome è ottenuto sostituendo le
+ Genera una directory temporaneo il cui nome è ottenuto sostituendo le
\code{XXXXXX} finali di \param{template}.
\bodydesc{La funzione ritorna il puntatore al nome della directory in caso
successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
- assumerà i valori:
+ assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
\end{errlist}
- più gli altri eventuali codici di errore di \func{mkdir}.}
+ più gli altri eventuali codici di errore di \func{mkdir}.}
\end{prototype}
-\noindent la directory è creata con permessi \code{0700} (al solito si veda
+\noindent la directory è creata con permessi \code{0700} (al solito si veda
cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
-della directory è sempre esclusiva i precedenti problemi di
+della directory è sempre esclusiva i precedenti problemi di
\itindex{race~condition} \textit{race condition} non si pongono.
\subsection{La lettura delle caratteristiche dei file}
\label{sec:file_stat}
-La lettura delle informazioni relative ai file è fatta attraverso la famiglia
+La lettura delle informazioni relative ai file è fatta attraverso la famiglia
delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
-questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
+questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
e mostrare tutti i dati relativi ad un file. I prototipi di queste funzioni
sono i seguenti:
\begin{functions}
\param{buf}.
\funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
- \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
+ \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
lette le informazioni relative ad esso e non al file a cui fa riferimento.
\funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
descriptor \param{filedes}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
+ errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
\errval{ENOENT}, \errval{ENOTDIR}, \errval{ELOOP}, \errval{EFAULT},
\errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
\end{functions}
-\noindent il loro comportamento è identico, solo che operano rispettivamente
+\noindent il loro comportamento è identico, solo che operano rispettivamente
su un file, su un link simbolico e su un file descriptor.
-La struttura \struct{stat} usata da queste funzioni è definita nell'header
+La struttura \struct{stat} usata da queste funzioni è definita nell'header
\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
-usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
-riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
+usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
+riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
-riservati per estensioni come tempi dei file più precisi (vedi
+riservati per estensioni come tempi dei file più precisi (vedi
sez.~\ref{sec:file_file_times}), o per il padding dei campi.
\begin{figure}[!htb]
Come riportato in tab.~\ref{tab:file_file_types} in Linux oltre ai file e alle
directory esistono altri oggetti che possono stare su un filesystem. Il tipo
-di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
+di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
\var{st\_mode} (che contiene anche le informazioni relative ai permessi) di
una struttura \struct{stat}.
-Dato che il valore numerico può variare a seconda delle implementazioni, lo
+Dato che il valore numerico può variare a seconda delle implementazioni, lo
standard POSIX definisce un insieme di macro per verificare il tipo di file,
queste vengono usate anche da Linux che supporta pure le estensioni allo
standard per i link simbolici e i socket definite da BSD; l'elenco completo
-delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
+delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
riportato in tab.~\ref{tab:file_type_macro}.
\begin{table}[htb]
\centering
\label{tab:file_type_macro}
\end{table}
-Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
+Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
direttamente il valore di \var{st\_mode} per ricavare il tipo di file
controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
\file{sys/stat.h} sono definite le costanti numeriche riportate in
tab.~\ref{tab:file_mode_flags}.
-Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
+Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
possono essere usati per effettuare la selezione sul tipo di file voluto, con
\end{table}
Ad esempio se si volesse impostare una condizione che permetta di controllare
-se un file è una directory o un file ordinario si potrebbe definire la macro
+se un file è una directory o un file ordinario si potrebbe definire la macro
di preprocessore:
\includecodesnip{listati/is_file_dir.h}
in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
del file in byte, se si tratta di un file regolare. Nel caso di un link
-simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
-il link stesso contiene; per le fifo questo campo è sempre nullo.
+simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
+il link stesso contiene; per le fifo questo campo è sempre nullo.
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
-i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
+i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
dimensione inferiore sarebbe inefficiente.
-Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
+Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
detto che corrisponda all'occupazione dello spazio su disco per via della
possibile esistenza dei cosiddetti \index{file!\textit{hole}} \textit{holes}
(letteralmente \textsl{buchi}) che si formano tutte le volte che si va a
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
-numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
+numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso
+caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso
risultato di \cmd{ls}.
-Se è sempre possibile allargare un file, scrivendoci sopra od usando la
+Se è sempre possibile allargare un file, scrivendoci sopra od usando la
funzione \func{lseek} per spostarsi oltre la sua fine, esistono anche casi in
-cui si può avere bisogno di effettuare un troncamento, scartando i dati
-presenti al di là della dimensione scelta come nuova fine del file.
+cui si può avere bisogno di effettuare un troncamento, scartando i dati
+presenti al di là della dimensione scelta come nuova fine del file.
-Un file può sempre essere troncato a zero aprendolo con il flag
-\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
+Un file può sempre essere troncato a zero aprendolo con il flag
+\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
dimensione si possono usare le due funzioni \funcd{truncate} e
\funcd{ftruncate}, i cui prototipi sono:
\begin{functions}
errore, nel qual caso \var{errno} viene impostata opportunamente; per
\func{ftruncate} si hanno i valori:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un socket, non a un
- file o non è aperto in scrittura.
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+ \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un socket, non a un
+ file o non è aperto in scrittura.
\end{errlist}
per \func{truncate} si hanno:
\begin{errlist}
\item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
permesso di esecuzione una delle directory del \itindex{pathname}
\textit{pathname}.
- \item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
+ \item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
\end{errlist}
ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
\end{functions}
-Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
-perduti; il comportamento in caso di lunghezza inferiore non è specificato e
-dipende dall'implementazione: il file può essere lasciato invariato o esteso
+Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
+perduti; il comportamento in caso di lunghezza inferiore non è specificato e
+dipende dall'implementazione: il file può essere lasciato invariato o esteso
fino alla lunghezza scelta; nel caso di Linux viene esteso con la creazione di
un \index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e
ad una lettura si otterranno degli zeri.
possono essere letti tramite la funzione \func{stat}, che li restituisce
attraverso tre campi della struttura \struct{stat} di
fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
-campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
+campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il
-valore è espresso nel cosiddetto \itindex{calendar~time} \textit{calendar
+valore è espresso nel cosiddetto \itindex{calendar~time} \textit{calendar
time}, su cui torneremo in dettaglio in sez.~\ref{sec:sys_time}.
\begin{table}[htb]
\label{tab:file_file_times}
\end{table}
-Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
+Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di
cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il primo
infatti fa riferimento ad una modifica del contenuto di un file, mentre il
\cmd{make} per decidere quali file necessitano di essere ricompilati o
(talvolta insieme anche al tempo di cambiamento di stato) per decidere quali
file devono essere archiviati per il backup. Il tempo di ultimo accesso viene
-di solito usato per identificare i file che non vengono più utilizzati per un
+di solito usato per identificare i file che non vengono più utilizzati per un
certo lasso di tempo. Ad esempio un programma come \texttt{leafnode} lo usa
-per cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per
+per cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per
marcare i messaggi di posta che risultano letti. Il sistema non tiene conto
dell'ultimo accesso \itindex{inode} all'\textit{inode}, pertanto funzioni come
\func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il
tempi dei file secondo lo schema riportato nell'ultima colonna di
tab.~\ref{tab:file_file_times}.
-L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
-difetto progettuale di Unix, questo infatti comporta la necessità di
+L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
+difetto progettuale di Unix, questo infatti comporta la necessità di
effettuare un accesso in scrittura sul disco anche in tutti i casi in cui
questa informazione non interessa e sarebbe possibile avere un semplice
accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia
portatili, o cicli di riscrittura per i dischi su memorie riscrivibili.
Per questo motivo, onde evitare di mantenere una informazione che nella
-maggior parte dei casi non interessa, è sempre stato possibile disabilitare
+maggior parte dei casi non interessa, è sempre stato possibile disabilitare
l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio
-\texttt{noatime}. Dato però che questo può creare problemi a qualche
-programma, in Linux è stata introdotta la opzione \texttt{relatime} che esegue
-l'aggiornamento soltanto se il tempo di ultimo accesso è precedente al tempo di
-ultima modifica o cambiamento, così da rendere evidente che vi è stato un
+\texttt{noatime}. Dato però che questo può creare problemi a qualche
+programma, in Linux è stata introdotta la opzione \texttt{relatime} che esegue
+l'aggiornamento soltanto se il tempo di ultimo accesso è precedente al tempo di
+ultima modifica o cambiamento, così da rendere evidente che vi è stato un
accesso dopo la scrittura, ed evitando al contempo ulteriori operazioni su
disco negli accessi successivi. In questo modo l'informazione relativa al
fatto che un file sia stato letto resta disponibile, e ad esempio i programmi
citati in precedenza continuano a funzionare. Questa opzione, a partire dal
-kernel 2.6.30, è diventata il comportamento di default e non deve più essere
-specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
+kernel 2.6.30, è diventata il comportamento di default e non deve più essere
+specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
comportamento usando la opzione di montaggio \texttt{strictatime}.}
-L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
+L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
gli effetti sia per il file a cui si fa riferimento, sia per la directory che
lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto
-già detto, e cioè che anche le directory sono file (che contengono una lista
+già detto, e cioè che anche le directory sono file (che contengono una lista
di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri.
\begin{table}[htb]
Per questo motivo tutte le volte che compiremo un'operazione su un file che
comporta una modifica del nome contenuto nella directory, andremo anche a
scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
-esempio di questo può essere la cancellazione di un file, invece leggere o
+esempio di questo può essere la cancellazione di un file, invece leggere o
scrivere o cambiare i permessi di un file ha effetti solo sui tempi di
quest'ultimo.
creazione del file, usato in molti altri sistemi operativi, ma che in Unix non
esiste. Per questo motivo quando si copia un file, a meno di preservare
esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
-avrà sempre il tempo corrente come data di ultima modifica.
+avrà sempre il tempo corrente come data di ultima modifica.
I tempi di ultimo accesso e modifica possono essere modificati esplicitamente
-usando la funzione \funcd{utime}, il cui prototipo è:
+usando la funzione \funcd{utime}, il cui prototipo è:
\begin{prototype}{utime.h}
{int utime(const char *filename, struct utimbuf *times)}
Cambia i tempi di ultimo accesso e modifica \itindex{inode}
dell'\textit{inode} specificato da \param{filename} secondo i valori dei
- campi \var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL}
+ campi \var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL}
allora viene usato il tempo corrente.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si ha il permesso di scrittura sul file.
- \item[\errcode{EPERM}] non si è proprietari del file.
+ \item[\errcode{EPERM}] non si è proprietari del file.
\end{errlist}
ed inoltre \errval{EROFS} e \errval{ENOENT}.}
\end{prototype}
La funzione prende come argomento \param{times} una struttura
-\struct{utimbuf}, la cui definizione è riportata in
+\struct{utimbuf}, la cui definizione è riportata in
fig.~\ref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
valori che si vogliono impostare per tempi.
\end{figure}
L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
-cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
-tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
-si è specificato un valore la funzione avrà successo solo se si è proprietari
+cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
+tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
+si è specificato un valore la funzione avrà successo solo se si è proprietari
del file (o si hanno i privilegi di amministratore).
-Si tenga presente che non è comunque possibile specificare il tempo di
+Si tenga presente che non è comunque possibile specificare il tempo di
cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla
chiamata di \func{utime}). Questo serve anche come misura di sicurezza per
evitare che si possa modificare un file nascondendo completamente le proprie
-tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
+tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
\index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul
disco senza passare attraverso il filesystem, ma ovviamente in questo modo la
-cosa è molto più complicata da realizzare.
+cosa è molto più complicata da realizzare.
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
-tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
-nanosecondi per la gran parte dei filesystem. La ulteriore informazione può
+tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
+nanosecondi per la gran parte dei filesystem. La ulteriore informazione può
essere acceduta attraverso altri campi appositamente aggiunti alla struttura
\struct{stat}. Se si sono definite le macro \macro{\_BSD\_SOURCE} o
\macro{\_SVID\_SOURCE} questi sono \var{st\_atim.tv\_nsec},
supporto per questa maggior precisione sia assente questi campi aggiuntivi
saranno nulli.
-Per la gestione di questi nuovi valori è stata definita una seconda funzione
+Per la gestione di questi nuovi valori è stata definita una seconda funzione
di modifica, \funcd{utimes}, che consente di specificare tempi con maggior
-precisione; il suo prototipo è:
+precisione; il suo prototipo è:
\begin{prototype}
{sys/time.h}
{int utimes(const char *filename, struct timeval times[2])}
Cambia i tempi di ultimo accesso e modifica \itindex{inode}
dell'\textit{inode} specificato da \param{filename} secondo i valori
- specificati da \param{times}. Se questo è \val{NULL} allora viene usato il
+ specificati da \param{times}. Se questo è \val{NULL} allora viene usato il
tempo corrente.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si ha il permesso di scrittura sul file.
- \item[\errcode{EPERM}] non si è proprietari del file.
+ \item[\errcode{EPERM}] non si è proprietari del file.
\end{errlist}
ed inoltre \errval{EROFS} e \errval{ENOENT}.}
\end{prototype}
-La funzione è del tutto analoga alla precedente \func{utime} ma usa come
+La funzione è del tutto analoga alla precedente \func{utime} ma usa come
argomento \param{times}, un vettore di due strutture \struct{timeval}, la cui
-definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
+definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
di indicare i tempi con una precisione del microsecondo. Il primo elemento
di \param{times} indica il valore per il tempo di ultimo accesso, il secondo
quello per il tempo di ultima modifica.
due funzioni non sono definite in nessuno standard, ma sono presenti, oltre
che su Linux, anche su BSD.} \funcd{futimes} e \funcd{lutimes}, che
consentono rispettivamente di effettuare la modifica utilizzando un file
-già aperto o di eseguirla direttamente su un link simbolico. I relativi
+già aperto o di eseguirla direttamente su un link simbolico. I relativi
prototipi sono:
\begin{functions}
\headdecl{sys/time.h}
\funcdecl{int futimes(int fd, const struct timeval tv[2])} Cambia i tempi
- di un file già aperto specificato tramite il file descriptor \param{fd}.
+ di un file già aperto specificato tramite il file descriptor \param{fd}.
\funcdecl{int lutimes(const char *filename, const struct timeval tv[2])}
- Cambia i tempi di \param{filename} anche se questo è un link simbolico.
+ Cambia i tempi di \param{filename} anche se questo è un link simbolico.
\bodydesc{Le funzioni restituiscono zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà gli stessi valori di
- \func{utimes}, con in più per \func{futimes}:
+ errore, nel qual caso \var{errno} assumerà gli stessi valori di
+ \func{utimes}, con in più per \func{futimes}:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+ \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
\end{errlist}}
\end{functions}
Le due funzioni anno lo stesso comportamento di \texttt{utimes} e richiedono
-gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
-si può indicare il file su cui operare facendo riferimento al relativo file
+gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
+si può indicare il file su cui operare facendo riferimento al relativo file
descriptor (tratteremo in dettaglio l'argomento in
sez.~\ref{cha:file_unix_interface}) mentre con \func{lutimes} nel caso in
cui \param{filename} sia un link simbolico saranno modificati i suoi tempi
\headdecl{sys/time.h}
\funcdecl{futimens(int fd, const struct timespec times[2])} Cambia i tempi
- di un file già aperto, specificato dal file descriptor \param{fd}.
+ di un file già aperto, specificato dal file descriptor \param{fd}.
\funcdecl{int utimensat(int dirfd, const char *pathname, const struct
timespec times[2], int flags)} Cambia i tempi del file \param{pathname}.
\bodydesc{Le funzioni restituiscono zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà gli stessi valori di
- \func{utimes}, con in più per \func{futimes}:
+ errore, nel qual caso \var{errno} assumerà gli stessi valori di
+ \func{utimes}, con in più per \func{futimes}:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+ \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
\end{errlist}}
\end{functions}
Entrambe le funzioni utilizzano per indicare i valori dei tempi un
vettore \param{times} di due strutture \struct{timespec} che permette di
specificare un valore di tempo con una precisione fino al nanosecondo, la cui
-definizione è riportata in fig.~\ref{fig:sys_timespec_struct}.
+definizione è riportata in fig.~\ref{fig:sys_timespec_struct}.
\begin{figure}[!htb]
\footnotesize \centering
Come per le precedenti funzioni il primo elemento di \param{times} indica il
tempo di ultimo accesso ed il secondo quello di ultima modifica, e se si usa
-il valore \const{NULL} verrà impostato il tempo corrente sia per l'ultimo
+il valore \const{NULL} verrà impostato il tempo corrente sia per l'ultimo
accesso che per l'ultima modifica. Nei singoli elementi di \param{times} si
possono inoltre utilizzare due valori speciali per il campo \var{tv\_nsec}:
con \const{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
-\const{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
+\const{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
aggiornare in maniera specifica soltanto uno fra il tempo di ultimo accesso e
quello di ultima modifica. Quando si usa uno di questi valori speciali per
\var{tv\_nsec} il corrispondente valore di \var{tv\_sec} viene ignorato.
kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta
la funzione \func{futimesat} seguendo una bozza della revisione dello
- standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
- stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
- essere più utilizzata: pertanto non la tratteremo.} La prima è
+ standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
+ stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
+ essere più utilizzata: pertanto non la tratteremo.} La prima è
sostanzialmente una estensione di \func{futimes} che consente di specificare i
tempi con precisione maggiore, la seconda supporta invece, rispetto ad
-\func{utimes}, una sintassi più complessa che, come vedremo in
+\func{utimes}, una sintassi più complessa che, come vedremo in
sez.~\ref{sec:file_openat},\footnote{si rimanda pertanto la spiegazione del
significato degli argomenti aggiuntivi alla trattazione generica delle varie
funzioni che usano la stessa sintassi, effettuata in
sez.~\ref{sec:file_openat}.} consente una indicazione sicura dei
\textit{pathname relativi} specificando la directory da usare come riferimento
-in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
+in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
funzione di dereferenziare o meno i link simbolici.
\section{Il controllo di accesso ai file}
\label{sec:file_access_control}
-Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
+Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
del controllo di accesso ai file, che viene implementato per qualunque
filesystem standard.\footnote{per standard si intende che implementa le
caratteristiche previste dallo standard POSIX; in Linux sono disponibili
\subsection{I permessi per l'accesso ai file}
\label{sec:file_perm_overview}
-Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
+Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
sono accessibili da programma tramite la funzione \func{stat}, e sono
mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
-\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
- per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
+\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
+ per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
Windows, che non fornisce nessun supporto per l'accesso multiutente, e per
il quale i permessi vengono assegnati in maniera fissa con un opzione in
fase di montaggio.}
Esistono varie estensioni a questo modello,\footnote{come le \textit{Access
Control List} che sono state aggiunte ai filesystem standard con opportune
estensioni (vedi sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di
- controllo ancora più sofisticati come il \textit{mandatory access control}
- di SE-Linux.} ma nella maggior parte dei casi il meccanismo standard è più
-che sufficiente a soddisfare tutte le necessità più comuni. I tre permessi di
+ controllo ancora più sofisticati come il \textit{mandatory access control}
+ di SE-Linux.} ma nella maggior parte dei casi il meccanismo standard è più
+che sufficiente a soddisfare tutte le necessità più comuni. I tre permessi di
base associati ad ogni file sono:
\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
I restanti tre bit (noti come \itindex{suid~bit} \textit{suid bit},
\itindex{sgid~bit} \textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
- bit}) sono usati per indicare alcune caratteristiche più complesse del
+ bit}) sono usati per indicare alcune caratteristiche più complesse del
meccanismo del controllo di accesso su cui torneremo in seguito (in
-sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
+sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
riportato in fig.~\ref{fig:file_perm_bit}.
Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
\textbf{\var{st\_mode}} bit & \textbf{Significato} \\
\hline
\hline
- \const{S\_IRUSR} & \textit{user-read}, l'utente può leggere.\\
- \const{S\_IWUSR} & \textit{user-write}, l'utente può scrivere.\\
- \const{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire.\\
+ \const{S\_IRUSR} & \textit{user-read}, l'utente può leggere.\\
+ \const{S\_IWUSR} & \textit{user-write}, l'utente può scrivere.\\
+ \const{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire.\\
\hline
- \const{S\_IRGRP} & \textit{group-read}, il gruppo può leggere.\\
- \const{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere.\\
- \const{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire.\\
+ \const{S\_IRGRP} & \textit{group-read}, il gruppo può leggere.\\
+ \const{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere.\\
+ \const{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire.\\
\hline
\const{S\_IROTH} & \textit{other-read}, tutti possono leggere.\\
\const{S\_IWOTH} & \textit{other-write}, tutti possono scrivere.\\
I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda
che si riferiscano a dei file, dei link simbolici o delle directory; qui ci
-limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
+limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
avanti.
-La prima regola è che per poter accedere ad un file attraverso il suo
+La prima regola è che per poter accedere ad un file attraverso il suo
\itindex{pathname} \textit{pathname} occorre il permesso di esecuzione in
ciascuna delle directory che compongono il \textit{pathname}; lo stesso vale
per aprire un file nella directory corrente (per la quale appunto serve il
diritto di esecuzione).
-Per una directory infatti il permesso di esecuzione significa che essa può
+Per una directory infatti il permesso di esecuzione significa che essa può
essere attraversata nella risoluzione del \itindex{pathname}
-\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
-che si può leggere il contenuto della directory.
+\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
+che si può leggere il contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
-lettura si potrà lo stesso aprire un file in una directory (se si hanno i
-permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
-(mentre per crearlo occorrerà anche il permesso di scrittura per la
+lettura si potrà lo stesso aprire un file in una directory (se si hanno i
+permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
+(mentre per crearlo occorrerà anche il permesso di scrittura per la
directory).
Avere il permesso di lettura per un file consente di aprirlo con le opzioni
(si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
-il contenuto, lo stesso permesso è necessario per poter troncare il file.
+il contenuto, lo stesso permesso è necessario per poter troncare il file.
-Non si può creare un file fintanto che non si disponga del permesso di
+Non si può creare un file fintanto che non si disponga del permesso di
esecuzione e di quello di scrittura per la directory di destinazione; gli
stessi permessi occorrono per cancellare un file da una directory (si ricordi
che questo non implica necessariamente la rimozione del contenuto del file dal
-disco), non è necessario nessun tipo di permesso per il file stesso (infatti
+disco), non è necessario nessun tipo di permesso per il file stesso (infatti
esso non viene toccato, viene solo modificato il contenuto della directory,
rimuovendo la voce che ad esso fa riferimento).
fa riferimento; per questo in genere il comando \cmd{ls} riporta per un link
simbolico tutti i permessi come concessi; utente e gruppo a cui esso
appartiene vengono pure ignorati quando il link viene risolto, vengono
-controllati solo quando viene richiesta la rimozione del link e quest'ultimo è
+controllati solo quando viene richiesta la rimozione del link e quest'ultimo è
in una directory con lo \itindex{sticky~bit} \textit{sticky bit} impostato (si
veda sez.~\ref{sec:file_special_perm}).
l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
\var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID
effettivo e gli eventuali group-ID supplementari del processo.\footnote{in
- realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
+ realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
\begin{enumerate}
-\item Se l'user-ID effettivo del processo è zero (corrispondente
- all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
- controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
+\item Se l'user-ID effettivo del processo è zero (corrispondente
+ all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
+ controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
tutti i file.
-\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del
- proprietario del file (nel qual caso si dice che il processo è proprietario
+\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del
+ proprietario del file (nel qual caso si dice che il processo è proprietario
del file) allora:
\begin{itemize*}
\item se il relativo\footnote{per relativo si intende il bit di user-read se
il processo vuole accedere in lettura, quello di user-write per
- l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
- impostato, l'accesso è consentito
- \item altrimenti l'accesso è negato
+ l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
+ impostato, l'accesso è consentito
+ \item altrimenti l'accesso è negato
\end{itemize*}
\item Se il group-ID effettivo del processo o uno dei group-ID supplementari
dei processi corrispondono al \acr{gid} del file allora:
\begin{itemize*}
- \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
+ \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
consentito,
- \item altrimenti l'accesso è negato
+ \item altrimenti l'accesso è negato
\end{itemize*}
-\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
- l'accesso è consentito, altrimenti l'accesso è negato.
+\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
+ l'accesso è consentito, altrimenti l'accesso è negato.
\end{enumerate}
Si tenga presente che questi passi vengono eseguiti esattamente in
-quest'ordine. Questo vuol dire che se un processo è il proprietario di un file,
-l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
+quest'ordine. Questo vuol dire che se un processo è il proprietario di un file,
+l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
permessi per il gruppo non vengono neanche controllati. Lo stesso vale se il
processo appartiene ad un gruppo appropriato, in questo caso i permessi per
tutti gli altri non vengono controllati.
\itindbeg{suid~bit}
\itindbeg{sgid~bit}
-Come si è accennato (in sez.~\ref{sec:file_perm_overview}) nei dodici bit del
+Come si è accennato (in sez.~\ref{sec:file_perm_overview}) nei dodici bit del
campo \var{st\_mode} di \struct{stat} che vengono usati per il controllo di
accesso oltre ai bit dei permessi veri e propri, ci sono altri tre bit che
-vengono usati per indicare alcune proprietà speciali dei file. Due di questi
+vengono usati per indicare alcune proprietà speciali dei file. Due di questi
sono i bit detti \acr{suid} (da \textit{set-user-ID bit}) e \acr{sgid} (da
\textit{set-group-ID bit}) che sono identificati dalle costanti
\const{S\_ISUID} e \const{S\_ISGID}.
Come spiegato in dettaglio in sez.~\ref{sec:proc_exec}, quando si lancia un
-programma il comportamento normale del kernel è quello di impostare gli
+programma il comportamento normale del kernel è quello di impostare gli
identificatori del gruppo \textit{effective} del nuovo processo al valore dei
corrispondenti del gruppo \textit{real} del processo corrente, che normalmente
-corrispondono a quelli dell'utente con cui si è entrati nel sistema.
+corrispondono a quelli dell'utente con cui si è entrati nel sistema.
-Se però il file del programma (che ovviamente deve essere
+Se però il file del programma (che ovviamente deve essere
eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del
+kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del
proprietario del file al posto dell'\acr{uid} del processo originario. Avere
il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del
processo.
I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
-di usare programmi che richiedono privilegi speciali; l'esempio classico è il
-comando \cmd{passwd} che ha la necessità di modificare il file delle password,
-quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è
+di usare programmi che richiedono privilegi speciali; l'esempio classico è il
+comando \cmd{passwd} che ha la necessità di modificare il file delle password,
+quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è
necessario chiamare l'amministratore per cambiare la propria password. Infatti
il comando \cmd{passwd} appartiene a root ma ha il bit \acr{suid} impostato
per cui quando viene lanciato da un utente normale parte con i privilegi di
Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
programmi devono essere scritti accuratamente per evitare che possano essere
-usati per guadagnare privilegi non consentiti (l'argomento è affrontato in
+usati per guadagnare privilegi non consentiti (l'argomento è affrontato in
dettaglio in sez.~\ref{sec:proc_perms}).
-La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
+La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
il comando \cmd{ls -l}, che visualizza una lettera \cmd{s} al posto della
\cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
-\cmd{s} può essere usata nel comando \cmd{chmod} per impostare questi bit.
+\cmd{s} può essere usata nel comando \cmd{chmod} per impostare questi bit.
Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
l'uso delle due costanti \const{S\_ISUID} e \const{S\_IGID}, i cui valori sono
riportati in tab.~\ref{tab:file_mode_flags}.
da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo
sia anche il corrispondente bit di esecuzione viene utilizzato per attivare
per quel file il \itindex{mandatory~locking} \textit{mandatory locking}
-(affronteremo questo argomento in dettaglio più avanti, in
+(affronteremo questo argomento in dettaglio più avanti, in
sez.~\ref{sec:file_mand_locking}).
\itindend{suid~bit}
\itindbeg{sticky~bit}
-L'ultimo dei bit rimanenti, identificato dalla costante \const{S\_ISVTX}, è in
+L'ultimo dei bit rimanenti, identificato dalla costante \const{S\_ISVTX}, è in
parte un rimasuglio delle origini dei sistemi Unix. A quell'epoca infatti la
memoria virtuale e l'accesso ai file erano molto meno sofisticati e per
-ottenere la massima velocità possibile per i programmi usati più comunemente
+ottenere la massima velocità possibile per i programmi usati più comunemente
si poteva impostare questo bit.
L'effetto di questo bit era che il \index{segmento!testo} segmento di testo
fino al riavvio della macchina (da questo il nome di \textsl{sticky bit});
essendo la swap un file continuo o una partizione indicizzata direttamente si
poteva risparmiare in tempo di caricamento rispetto alla ricerca attraverso la
-struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
+struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
\texttt{t} al posto della \texttt{x} nei permessi per gli altri.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
costante. Le attuali implementazioni di memoria virtuale e filesystem rendono
sostanzialmente inutile questo procedimento.
-Benché ormai non venga più utilizzato per i file, lo \textit{sticky bit} ha
+Benché ormai non venga più utilizzato per i file, lo \textit{sticky bit} ha
invece assunto un uso importante per le directory;\footnote{lo \textit{sticky
- bit} per le directory è un'estensione non definita nello standard POSIX,
- Linux però la supporta, così come BSD e SVr4.} in questo caso se tale bit è
-impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
-il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
+ bit} per le directory è un'estensione non definita nello standard POSIX,
+ Linux però la supporta, così come BSD e SVr4.} in questo caso se tale bit è
+impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
+il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
condizioni:
\begin{itemize*}
-\item l'utente è proprietario del file
-\item l'utente è proprietario della directory
-\item l'utente è l'amministratore
+\item l'utente è proprietario del file
+\item l'utente è proprietario della directory
+\item l'utente è l'amministratore
\end{itemize*}
-un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
+un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
permessi infatti di solito sono i seguenti:
\begin{verbatim}
$ ls -ld /tmp
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
\end{verbatim}%$
quindi con lo \textit{sticky bit} bit impostato. In questo modo qualunque
-utente nel sistema può creare dei file in questa directory (che, come
-suggerisce il nome, è normalmente utilizzata per la creazione di file
-temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
-rinominarlo. In questo modo si evita che un utente possa, più o meno
+utente nel sistema può creare dei file in questa directory (che, come
+suggerisce il nome, è normalmente utilizzata per la creazione di file
+temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
+rinominarlo. In questo modo si evita che un utente possa, più o meno
consapevolmente, cancellare i file temporanei creati degli altri utenti.
\itindend{sticky~bit}
Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
+ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e
\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
-sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
+sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
-Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
+Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
\begin{prototype}{unistd.h}
{int access(const char *pathname, int mode)}
Verifica i permessi di accesso.
-\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
- è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
- assumerà i valori:
+\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
+ è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
+ assumerà i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
- \item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
+ \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
+ \item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
permesso di attraversare una delle directory di \param{pathname}.
- \item[\errcode{EROFS}] si è richiesto l'accesso in scrittura per un file su
+ \item[\errcode{EROFS}] si è richiesto l'accesso in scrittura per un file su
un filesystem montato in sola lettura.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\param{mode} sono esprimibili come combinazione delle costanti numeriche
riportate in tab.~\ref{tab:file_access_mode_val} (attraverso un OR binario
delle stesse). I primi tre valori implicano anche la verifica dell'esistenza
-del file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK},
+del file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK},
o anche direttamente \func{stat}. Nel caso in cui \param{pathname} si
-riferisca ad un link simbolico, questo viene seguito ed il controllo è fatto
+riferisca ad un link simbolico, questo viene seguito ed il controllo è fatto
sul file a cui esso fa riferimento.
La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
\label{tab:file_access_mode_val}
\end{table}
-Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
+Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
l'utente originale ha i permessi per accedere ad un certo file.
Del tutto analoghe a \func{access} sono le due funzioni \funcd{euidaccess} e
-\funcd{eaccess} che ripetono lo stesso controllo usando però gli
-identificatori del gruppo effettivo, verificando quindi le effettive capacità
+\funcd{eaccess} che ripetono lo stesso controllo usando però gli
+identificatori del gruppo effettivo, verificando quindi le effettive capacità
di accesso ad un file. Le funzioni hanno entrambe lo stesso
-prototipo\footnote{in realtà \func{eaccess} è solo un sinonimo di
- \func{euidaccess} fornita per compatibilità con l'uso di questo nome in
- altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
+prototipo\footnote{in realtà \func{eaccess} è solo un sinonimo di
+ \func{euidaccess} fornita per compatibilità con l'uso di questo nome in
+ altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
codici di errore.
il file descriptor \param{fd} per indicare il file.
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
- un errore, in caso di errore \var{errno} può assumere i valori:
+ un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del
- proprietario del file o non è zero.
- \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
+ proprietario del file o non è zero.
+ \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
\end{errlist}
ed inoltre \errval{EIO}; \func{chmod} restituisce anche \errval{EFAULT},
\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
\end{table}
Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
-in tab.~\ref{tab:file_permission_const}. Il valore di \param{mode} può essere
+in tab.~\ref{tab:file_permission_const}. Il valore di \param{mode} può essere
ottenuto combinando fra loro con un OR binario le costanti simboliche relative
ai vari bit, o specificato direttamente, come per l'omonimo comando di shell,
con un valore numerico (la shell lo vuole in ottale, dato che i bit dei
-permessi sono divisibili in gruppi di tre), che si può calcolare direttamente
+permessi sono divisibili in gruppi di tre), che si può calcolare direttamente
usando lo schema si utilizzo dei bit illustrato in
fig.~\ref{fig:file_perm_bit}.
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'user-ID effettivo del processo
+funzioni infatti è possibile solo se l'user-ID effettivo del processo
corrisponde a quello del proprietario del file o dell'amministratore,
altrimenti esse falliranno con un errore di \errcode{EPERM}.
Ma oltre a questa regola generale, di immediata comprensione, esistono delle
-limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
+limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
in particolare accade che:
\begin{enumerate}
-\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
- \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
+\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
+ \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
viene automaticamente cancellato (senza notifica di errore) qualora sia
stato indicato in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
- creazione dei nuovi file, si può avere il caso in cui il file creato da un
- processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
+ creazione dei nuovi file, si può avere il caso in cui il file creato da un
+ processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
Per evitare che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad
un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
automaticamente cancellato da \param{mode} (senza notifica di errore)
qualora il gruppo del file non corrisponda a quelli associati al processo
- (la cosa non avviene quando l'user-ID effettivo del processo è zero).
+ (la cosa non avviene quando l'user-ID effettivo del processo è zero).
\end{enumerate}
-Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
- mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
+Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
+ \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
+ mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
consiste nel cancellare automaticamente questi bit dai permessi di un file
qualora un processo che non appartenga all'amministratore\footnote{per la
- precisione un processo che non dispone della \itindex{capabilities} capacità
+ precisione un processo che non dispone della \itindex{capabilities} capacità
\const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} effettui una
scrittura. In questo modo anche se un utente malizioso scopre un file
-\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
+\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
questo privilegio.
Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
-permessi di un file, resta però il problema di quali sono i permessi assegnati
+permessi di un file, resta però il problema di quali sono i permessi assegnati
quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
vedremo in sez.~\ref{sec:file_open}, permettono di indicare esplicitamente i
-permessi di creazione di un file, ma questo non è possibile per le funzioni
+permessi di creazione di un file, ma questo non è possibile per le funzioni
dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
permessi non vengono indicati esplicitamente.
\itindbeg{umask}
Per le funzioni dell'interfaccia standard ANSI C l'unico riferimento possibile
-è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
-lettura), che però può fornire un valore che è lo stesso per tutti e tre i
-permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
+è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
+lettura), che però può fornire un valore che è lo stesso per tutti e tre i
+permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
$222$ nel secondo). Per questo motivo il sistema associa ad ogni
-processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
+processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
\struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
verranno tolti.}
La funzione che permette di impostare il valore di questa maschera di
-controllo è \funcd{umask}, ed il suo prototipo è:
+controllo è \funcd{umask}, ed il suo prototipo è:
\begin{prototype}{stat.h}
{mode\_t umask(mode\_t mask)}
Imposta la maschera dei permessi dei bit al valore specificato da \param{mask}
(di cui vengono presi solo i 9 bit meno significativi).
- \bodydesc{La funzione ritorna il precedente valore della maschera. È una
+ \bodydesc{La funzione ritorna il precedente valore della maschera. È una
delle poche funzioni che non restituisce codici di errore.}
\end{prototype}
In genere si usa questa maschera per impostare un valore predefinito che
escluda preventivamente alcuni permessi (usualmente quello di scrittura per il
gruppo e gli altri, corrispondente ad un valore per \param{mask} pari a
-$022$). In questo modo è possibile cancellare automaticamente i permessi non
+$022$). In questo modo è possibile cancellare automaticamente i permessi non
voluti. Di norma questo valore viene impostato una volta per tutte al login a
$022$, e gli utenti non hanno motivi per modificarlo.
\itindend{umask}
-\subsection{La gestione della titolarità dei file}
+\subsection{La gestione della titolarità dei file}
\label{sec:file_ownership_management}
Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
-nuovi file, in tale occasione vedremo che è possibile specificare in sede di
-creazione quali permessi applicare ad un file, però non si può indicare a
+nuovi file, in tale occasione vedremo che è possibile specificare in sede di
+creazione quali permessi applicare ad un file, però non si può indicare a
quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
per la creazione di nuove directory (procedimento descritto in
sez.~\ref{sec:file_dir_creat_rem}).
Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
+due diverse possibilità:
\begin{itemize*}
\item il \acr{gid} del file corrisponde al group-ID effettivo del processo.
\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
- esso è creato.
+ esso è creato.
\end{itemize*}
-in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
+in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
-norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
+\acr{gid} del processo, se però la directory in cui viene creato il file ha il
bit \acr{sgid} impostato allora viene usata la seconda opzione.
Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
automaticamente propagato, restando coerente a quello della directory di
partenza, in tutte le sotto-directory.
-La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
risultato di coerenza che si ha con BSD necessita che quando si creano nuove
-directory venga anche propagato anche il bit \acr{sgid}. Questo è il
-comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
+directory venga anche propagato anche il bit \acr{sgid}. Questo è il
+comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
esempio che le varie distribuzioni assicurano che le sotto-directory create
nella home di un utente restino sempre con il \acr{gid} del gruppo primario
dello stesso.
-La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
+La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
directory contenenti file condivisi all'intero di un gruppo in cui possono
scrivere tutti i membri dello stesso, dato che assicura che i file che gli
utenti vi creano appartengano sempre allo stesso gruppo. Questo non risolve
-però completamente i problemi di accesso da parte di altri utenti dello stesso
+però completamente i problemi di accesso da parte di altri utenti dello stesso
gruppo, in quanto i permessi assegnati al gruppo potrebbero non essere
sufficienti; in tal caso si deve aver cura di usare un valore di
\itindex{umask} \textit{umask} che ne lasci di sufficienti.\footnote{in tal
- caso si può assegnare agli utenti del gruppo una \textit{umask} di $002$,
- anche se la soluzione migliore in questo caso è usare una ACL di default
+ caso si può assegnare agli utenti del gruppo una \textit{umask} di $002$,
+ anche se la soluzione migliore in questo caso è usare una ACL di default
(vedi sez.~\ref{sec:file_ACL}).}
Come avviene nel caso dei permessi il sistema fornisce anche delle funzioni,
specificati dalle variabili \param{owner} e \param{group}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
- errore, nel qual caso caso \var{errno} assumerà i valori:
+ errore, nel qual caso caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del
- proprietario del file o non è zero, o utente e gruppo non sono validi
+ proprietario del file o non è zero, o utente e gruppo non sono validi
\end{errlist}
Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
\errval{EIO}; \func{chown} restituisce anche \errval{EFAULT},
\end{functions}
Con Linux solo l'amministratore\footnote{o in generale un processo con la
- \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
- sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
+ \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
+ sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
in questo viene seguita la semantica usata da BSD che non consente agli utenti
di assegnare i loro file ad altri utenti evitando eventuali aggiramenti delle
-quote. L'amministratore può cambiare sempre il gruppo di un file, il
-proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
-se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
+quote. L'amministratore può cambiare sempre il gruppo di un file, il
+proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
+se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
La funzione \func{chown} segue i link simbolici, per operare direttamente su
un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
- allora questo comportamento è stato assegnato alla funzione \func{lchown},
- introdotta per l'occasione, ed è stata creata una nuova system call per
+ allora questo comportamento è stato assegnato alla funzione \func{lchown},
+ introdotta per l'occasione, ed è stata creata una nuova system call per
\func{chown} che seguisse i link simbolici.} La funzione \func{fchown} opera
-su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
-Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
+su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
+Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
valore per \param{owner} e \param{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
privilegi di root entrambi i bit \itindex{suid~bit} \acr{suid} e
\itindex{sgid~bit} \acr{sgid} vengono cancellati. Questo non avviene per il
bit \acr{sgid} nel caso in cui esso sia usato (in assenza del corrispondente
-permesso di esecuzione) per indicare che per il file è attivo il
+permesso di esecuzione) per indicare che per il file è attivo il
\itindex{mandatory~locking} \textit{mandatory locking} (vedi
sez.~\ref{sec:file_mand_locking}).
1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario.\\
-&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario.\\
-&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking}
- \textit{mandatory locking} è abilitato.\\
+ \textit{mandatory locking} è abilitato.\\
-&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
-&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario.\\
-&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per il proprietario.\\
\label{tab:file_fileperm_bits}
\end{table}
-Nella parte superiore di tab.~\ref{tab:file_fileperm_bits} si è riassunto il
+Nella parte superiore di tab.~\ref{tab:file_fileperm_bits} si è riassunto il
significato dei vari bit dei permessi per un file ordinario; per quanto
riguarda l'applicazione dei permessi per proprietario, gruppo ed altri si
ricordi quanto illustrato in sez.~\ref{sec:file_perm_overview}. Per
\itindex{sticky~bit} con la notazione illustrata anche in
fig.~\ref{fig:file_perm_bit}. Nella parte inferiore si sono invece riassunti
i significati dei vari bit dei permessi per una directory; anche in questo
-caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid},
+caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid},
\itindex{sgid~bit} \textit{sgid} e \textit{sticky} \itindex{sticky~bit} la
notazione illustrata in fig.~\ref{fig:file_perm_bit}.
Si ricordi infine che i permessi non hanno alcun significato per i link
simbolici, mentre per i \index{file!di~dispositivo} file di dispositivo hanno
senso soltanto i permessi di lettura e scrittura, che si riflettono sulla
-possibilità di compiere dette operazioni sul dispositivo stesso.
+possibilità di compiere dette operazioni sul dispositivo stesso.
-Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
-bit in questione non è influente rispetto a quanto indicato nella riga della
+Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
+bit in questione non è influente rispetto a quanto indicato nella riga della
tabella; la descrizione del significato fa riferimento soltanto alla
-combinazione di bit per i quali è stato riportato esplicitamente un valore.
+combinazione di bit per i quali è stato riportato esplicitamente un valore.
Si rammenti infine che il valore dei bit dei permessi non ha alcun effetto
qualora il processo possieda i privilegi di amministratore.
-\section{Caratteristiche e funzionalità avanzate}
+\section{Caratteristiche e funzionalità avanzate}
\label{sec:file_dir_advances}
-Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione
+Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione
di file e directory, affrontando anche una serie di estensioni
dell'interfaccia classica dei sistemi unix-like, principalmente utilizzate a
-scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
+scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
Linux.
modifiche, o marcare un file come immutabile.} una volta che questa sia
stata effettuata e si siano ottenuti i privilegi di amministratore, queste
potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
- nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
- la marcatura di immutabilità.}
+ nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+ la marcatura di immutabilità.}
Il problema consiste nel fatto che nell'architettura tradizionale di un
sistema unix-like i controlli di accesso sono basati su un solo livello di
diritti di amministratore non potesse eseguire certe operazioni, o per cedere
definitivamente alcuni privilegi da un certo momento in poi.
-Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
suddividere i vari privilegi tradizionalmente associati all'amministratore in
-un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
+un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
potessero essere abilitate e disabilitate in maniera indipendente per ciascun
-processo con privilegi di amministratore, permettendo così una granularità
-molto più fine nella distribuzione degli stessi che evitasse la originaria
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
situazione di ``\textsl{tutto o nulla}''.
Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
- si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
- poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
-singoli file eseguibili, in modo da poter stabilire quali capacità possono
+ si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
+ poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
+singoli file eseguibili, in modo da poter stabilire quali capacità possono
essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità è stato introdotto soltanto a partire dal
+il supporto per questa funzionalità è stato introdotto soltanto a partire dal
kernel 2.6.24; fino ad allora doveva essere il programma stesso ad eseguire
-una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
-funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
+una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
+funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
\index{SELinux} SELinux.
-Per gestire questo meccanismo ciascun processo porta con sé tre distinti
+Per gestire questo meccanismo ciascun processo porta con sé tre distinti
insiemi di \textit{capabilities}, che vengono denominati rispettivamente
\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
all'interno della \struct{task\_struct} di ciascun processo (vedi
fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
\texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
- \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+ \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
-ciascun bit corrisponde ad una capacità diversa.
+ciascun bit corrisponde ad una capacità diversa.
L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
sono mantenuti i diversi insiemi di identificatori di
-sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
+sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\textit{effective}] l'insieme delle \textit{capabilities}
- ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+ ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
kernel quando deve eseguire il controllo di accesso per le varie operazioni
compiute dal processo.
\item[\textit{permitted}] l'insieme delle \textit{capabilities}
- ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
- \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
- capacità da questo insieme non potrà più riassumerla (almeno che non esegua
- un programma che è \acr{suid} di root).
+ ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+ \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+ capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+ un programma che è \acr{suid} di root).
\item[\textit{inherited}] l'insieme delle \textit{capabilities}
- ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+ ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
del caso che questo sia \acr{suid} di root).
\label{sec:capabilities_set}
volta che un programma viene posto in esecuzione con \func{exec} il contenuto
degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
un \textsl{AND} binario del contenuto corrente del \textit{capabilities
- bounding set}, così che il nuovo processo potrà disporre soltanto delle
-capacità in esso elencate.
+ bounding set}, così che il nuovo processo potrà disporre soltanto delle
+capacità in esso elencate.
-Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
+Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
questa sua caratteristica consente di impostare un limite generale alle
-capacità che possono essere accordate ai vari processi. Questo valore può
+capacità che possono essere accordate ai vari processi. Questo valore può
essere impostato ad un valore arbitrario esclusivamente dal primo processo
-eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
-eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
-eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
-già presenti dell'insieme: questo significa che una volta rimossa una
-\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
+eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
+eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
disponibile, neanche per l'amministratore, a meno di un riavvio.
-Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
\func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
- bounding set}. In questo modo si può far si che ad un processo eseguito in
+ bounding set}. In questo modo si può far si che ad un processo eseguito in
un secondo tempo possano essere trasmesse solo un insieme limitato di
-capacità, impedendogli di recuperare quelle assenti nell'insieme
+capacità, impedendogli di recuperare quelle assenti nell'insieme
\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
-vengono mantenute le stesse capacità del processo padre.
+vengono mantenute le stesse capacità del processo padre.
% TODO verificare per process capability bounding set, vedi:
Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
-breve descrizione ed il nome delle costanti che le identificano, è riportato
+breve descrizione ed il nome delle costanti che le identificano, è riportato
in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
- aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
+ capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
+ aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
+POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
+tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+che è opportuno dettagliare maggiormente.
\begin{table}[!h!bt]
\centering
\footnotesize
\begin{tabular}{|l|p{12cm}|}
\hline
- \textbf{Capacità}&\textbf{Descrizione}\\
+ \textbf{Capacità}&\textbf{Descrizione}\\
\hline
\hline
%
% POSIX-draft defined capabilities.
%
- \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+ \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
auditing del kernel (dal kernel 2.6.11).\\
- \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+ \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
controllo dell'auditing (dal kernel 2.6.11).\\
% TODO verificare questa roba dell'auditing
- \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
+ \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
proprietario di un file (vedi
sez.~\ref{sec:file_ownership_management}).\\
- \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+ \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
permessi di lettura, scrittura ed esecuzione dei
file,\footnotemark (vedi
sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+ \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
permessi di lettura ed esecuzione per
le directory (vedi
sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_FOWNER} & La capacità di evitare il controllo della
- proprietà di un file per tutte
+ \const{CAP\_FOWNER} & La capacità di evitare il controllo della
+ proprietà di un file per tutte
le operazioni privilegiate non coperte dalle
precedenti \const{CAP\_DAC\_OVERRIDE} e
\const{CAP\_DAC\_READ\_SEARCH}.\\
- \const{CAP\_FSETID} & La capacità di evitare la cancellazione
+ \const{CAP\_FSETID} & La capacità di evitare la cancellazione
automatica dei bit \itindex{suid~bit} \acr{suid}
e \itindex{sgid~bit} \acr{sgid} quando un file
per i quali sono impostati viene modificato da
- un processo senza questa capacità e la capacità
+ un processo senza questa capacità e la capacità
di impostare il bit \acr{sgid} su un file anche
- quando questo è relativo ad un gruppo cui non si
+ quando questo è relativo ad un gruppo cui non si
appartiene (vedi
sez.~\ref{sec:file_perm_management}).\\
- \const{CAP\_SETFCAP} & La capacità di impostare le
+ \const{CAP\_SETFCAP} & La capacità di impostare le
\textit{capabilities} di un file (dal kernel
2.6.24).\\
- \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
+ \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
+ \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
processi, sia il principale che i supplementari,
(vedi sez.~\ref{sec:proc_setgroups}) che quelli
trasmessi tramite i socket \textit{unix domain}
(vedi sez.~\ref{sec:unix_socket}).\\
- \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
+ \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
processo (vedi sez.~\ref{sec:proc_setuid}) e di
trasmettere un user ID arbitrario nel passaggio
delle credenziali coi socket \textit{unix
% Linux specific capabilities
%
\hline
- \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
+ \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
locking} \itindex{memory~locking} con le
funzioni \func{mlock}, \func{mlockall},
\func{shmctl}, \func{mmap} (vedi
sez.~\ref{sec:proc_mem_lock} e
sez.~\ref{sec:file_memory_map}). \\
- \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+ \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
per le operazioni sugli oggetti di
intercomunicazione fra processi (vedi
sez.~\ref{sec:ipc_sysv}).\\
- \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
+ \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
\index{file!lease} (vedi
sez.~\ref{sec:file_asyncronous_lease})
pur non essendo proprietari del file (dal kernel
2.4).\\
- \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+ \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
attributi \textit{immutable} e
\itindex{append~mode} \textit{append only} (se
supportati).\\
- \const{CAP\_MKNOD} & La capacità di creare
+ \const{CAP\_MKNOD} & La capacità di creare
\index{file!di~dispositivo} file di dispositivo
con \func{mknod} (vedi
sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
- \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+ \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
privilegiate sulla rete.\\
- \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+ \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
su porte riservate (vedi
sez.~\ref{sec:TCP_func_bind}).\\
- \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+ \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
\itindex{broadcast} \textit{broadcast} e
\itindex{multicast} \textit{multicast}.\\
- \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
+ \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
\texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
- \const{CAP\_SETPCAP} & La capacità di impostare o rimuovere una
- capacità.\\
+ \const{CAP\_SETPCAP} & La capacità di impostare o rimuovere una
+ capacità.\\
% TODO cambiata nel 2.4.24 rc1 ?
- \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+ \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
amministrativi. \\
- \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
+ \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
sistema.\\
% TODO trattare reboot e kexec
- \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+ \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
\func{chroot} (vedi
sez.~\ref{sec:file_chroot}).\\
- \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
+ \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
kernel 2.6.25).\\
- \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
+ \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
kernel 2.6.25).\\
- \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+ \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
kernel. \\
- \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei
+ \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei
processi. \\
- \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+ \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
\textit{accounting} dei processi (vedi
sez.~\ref{sec:sys_bsd_accounting}).\\
- \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
\func{ptrace} (vedi
sez.~\ref{sec:xxx_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
+ \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
di I/O con \func{ioperm} e \func{iopl} (vedi
sez.~\ref{sec:file_io_port}).\\
- \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
+ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
risorse.\\
- \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
(vedi sez.~\ref{sec:sys_time}).\\
- \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
della console, con la funzione
\func{vhangup}.\\
\hline
controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
\textit{Discrectionary Access Control} (da cui il nome DAC).}
-La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
-rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
+La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
+rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
impostazioni degli attributi estesi e delle ACL (vedi
sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
-sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
+sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
-Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
-la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
+Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
+la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
tabella di instradamento.
-Una terza \textit{capability} con vasto campo di applicazione è
+Una terza \textit{capability} con vasto campo di applicazione è
\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
disattivare la swap, montare, rimontare e smontare filesystem (vedi
sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
(vedi sez.~\ref{sec:process_clone}).
-Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
-aumentare le priorità di esecuzione dei processi, come la diminuzione del
+Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
+aumentare le priorità di esecuzione dei processi, come la diminuzione del
valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
-priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
-l'impostazione delle affinità di processore (vedi
-sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
+priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
+l'impostazione delle affinità di processore (vedi
+sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
-alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
+alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
-possibilità di superare i limiti imposti sulle risorse di sistema, come usare
+possibilità di superare i limiti imposti sulle risorse di sistema, come usare
lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
\bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
- di errore, nel qual caso \var{errno} può assumere i valori:
+ di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
- \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
+ \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+ \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
nell'insieme delle \textit{capabilities} permesse, o di impostare una
- capacità non presente nell'insieme di quelle permesse negli insieme
- delle effettive o ereditate, o si è cercato di impostare una
+ capacità non presente nell'insieme di quelle permesse negli insieme
+ delle effettive o ereditate, o si è cercato di impostare una
\textit{capability} di un altro processo senza avare
\const{CAP\_SETPCAP}.
\end{errlist}
definiti come puntatori a due strutture specifiche di Linux, illustrate in
fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
- utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
+ utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
\texttt{sys/capability.h}.} Si tenga presente che le strutture di
fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
\func{capget} e \func{capset}, sono soggette ad essere modificate con il
cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
-anche se finora l'interfaccia è risultata stabile, non c'è nessuna
+anche se finora l'interfaccia è risultata stabile, non c'è nessuna
assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
- utilizzo di questa funzionalità ci sono state varie discussioni fra gli
+ utilizzo di questa funzionalità ci sono state varie discussioni fra gli
sviluppatori del kernel relative all'eliminarla o al modificarla
radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
-possano essere eseguiti su qualunque versione del kernel è opportuno
+possano essere eseguiti su qualunque versione del kernel è opportuno
utilizzare le interfacce di alto livello.
\begin{figure}[!htb]
fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
della versione in uso. La struttura a cui deve puntare l'argomento
-\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
-delle capacità del processo.
+\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
+delle capacità del processo.
Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
-garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
+garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
-una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
- Debian può essere installata con il pacchetto omonimo.} pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
+ Debian può essere installata con il pacchetto omonimo.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
libreria attraverso l'opzione \texttt{-lcap} del compilatore.
Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
-dati delle \textit{capabilities}. In questo modo è possibile mascherare i
+dati delle \textit{capabilities}. In questo modo è possibile mascherare i
dettagli della gestione di basso livello, che potranno essere modificati senza
dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
ad oggetti di questo tipo. L'interfaccia pertanto non soltanto fornisce le
funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
per gestire i dati attraverso \type{cap\_t}.
-La prima funzione dell'interfaccia è quella che permette di inizializzare un
+La prima funzione dell'interfaccia è quella che permette di inizializzare un
\textit{capability state}, allocando al contempo la memoria necessaria per i
-relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
+relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
Crea ed inizializza un \textit{capability state}.
\bodydesc{La funzione ritorna un valore non nullo in caso di successo e
- \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
+ \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
valore \errval{ENOMEM}.
}
\end{functions}
La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
-con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
-non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
+con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
+non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
ed \var{errno} viene impostata a \errval{ENOMEM}. La memoria necessaria a
-mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
-essere disallocata esplicitamente quando non è più necessaria utilizzando, per
+mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
+essere disallocata esplicitamente quando non è più necessaria utilizzando, per
questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
-prototipo è:
+prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
Disalloca la memoria allocata per i dati delle \textit{capabilities}.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
}
\end{functions}
La funzione permette di liberare la memoria allocata dalle altre funzioni
della libreria sia per un \textit{capability state}, nel qual caso l'argomento
-dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
-dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
- \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
-tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
+dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
+dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
+ \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
+tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
-le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
+le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
di \errval{EINVAL}.
-Infine si può creare una copia di un \textit{capability state} ottenuto in
-precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
+Infine si può creare una copia di un \textit{capability state} ottenuto in
+precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
Duplica un \textit{capability state} restituendone una copia.
\bodydesc{La funzione ritorna un valore non nullo in caso di successo e
- \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
+ \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
valori \errval{ENOMEM} o \errval{EINVAL}.
}
\end{functions}
La funzione crea una copia del \textit{capability state} posto all'indirizzo
-\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
-copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
+\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
+copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
nell'originale. La memoria necessaria viene allocata automaticamente dalla
funzione. Una volta effettuata la copia i due \textit{capability state}
potranno essere modificati in maniera completamente
-indipendente.\footnote{alla fine delle operazioni si ricordi però di
+indipendente.\footnote{alla fine delle operazioni si ricordi però di
disallocare anche la copia, oltre all'originale. }
Una seconda classe di funzioni di servizio previste dall'interfaccia sono
quelle per la gestione dei dati contenuti all'interno di un \textit{capability
- state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
+ state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
\textit{capabilities}.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
}
\end{functions}
Imposta il valore di una \textit{capability}.
\bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
}
\end{functions}
\textit{capability state} su cui operare, mentre l'argomento \param{flag}
indica su quale dei tre insiemi illustrati a
pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
-specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
-esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
+specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
+esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
verificare dalla sua definizione che si trova in
\texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
tab.~\ref{tab:cap_set_identifier}.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
- \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
- \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
+ \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
+ \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
+ \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
\hline
\end{tabular}
\caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
\label{tab:cap_set_identifier}
\end{table}
-La capacità che si intende controllare o impostare invece deve essere
-specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
+La capacità che si intende controllare o impostare invece deve essere
+specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
prendere come valore uno qualunque di quelli riportati in
-tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
+tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
combinare diversi valori in una maschera binaria, una variabile di tipo
-\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
- header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
+\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
+ header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
come \ctyp{int}, ma i valori validi sono soltanto quelli di
tab.~\ref{tab:proc_capabilities}.}
-Infine lo stato di una capacità è descritto ad una variabile di tipo
-\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
-uno\footnote{anche questo è un tipo enumerato.} dei valori di
+Infine lo stato di una capacità è descritto ad una variabile di tipo
+\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
+uno\footnote{anche questo è un tipo enumerato.} dei valori di
tab.~\ref{tab:cap_value_type}.
\begin{table}[htb]
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{CAP\_CLEAR}& La capacità non è impostata.\\
- \const{CAP\_SET} & La capacità è impostata.\\
+ \const{CAP\_CLEAR}& La capacità non è impostata.\\
+ \const{CAP\_SET} & La capacità è impostata.\\
\hline
\end{tabular}
\caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
- indica lo stato di una capacità.}
+ indica lo stato di una capacità.}
\label{tab:cap_value_type}
\end{table}
-La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
+La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
-puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
-stato di una capacità alla volta.
+puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
+stato di una capacità alla volta.
-La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
-più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
+La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
impostazione) viene indicato dall'argomento \param{value}.
Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
-prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
+prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
\bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
- errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
\errval{ENOMEM}.
}
\end{functions}
come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
della stringa. La stringa restituita viene allocata automaticamente dalla
-funzione e pertanto dovrà essere liberata con \func{cap\_free}.
+funzione e pertanto dovrà essere liberata con \func{cap\_free}.
Fin quei abbiamo trattato solo le funzioni di servizio relative alla
manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
-prevede però anche le funzioni per la gestione delle \textit{capabilities}
-stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
-delle \textit{capabilities} del processo corrente, il suo prototipo è:
+prevede però anche le funzioni per la gestione delle \textit{capabilities}
+stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
+delle \textit{capabilities} del processo corrente, il suo prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
Legge le \textit{capabilities} del processo corrente.
\bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
- successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
+ successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}. }
\end{functions}
La funzione legge il valore delle \textit{capabilities} associate al processo
da cui viene invocata, restituendo il risultato tramite il puntatore ad un
\textit{capabilities state} contenente tutti i dati che provvede ad allocare
-autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
-non sarà più utilizzato.
+autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
+non sarà più utilizzato.
Se invece si vogliono leggere le \textit{capabilities} di un processo
specifico occorre usare la funzione \funcd{capgetp}, il cui
-prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
+prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
- ma il valore di ritorno è intero, come si può verificare anche dalla
- dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+ ma il valore di ritorno è intero, come si può verificare anche dalla
+ dichiarazione della stessa in \texttt{sys/capability.h}.} è:
\begin{functions}
\headdecl{sys/capability.h}
Legge le \textit{capabilities} del processo indicato da \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
\errval{EPERM} o \errval{ENOMEM}.
}
\end{functions}
\textit{capabilities state} posto all'indirizzo indicato con l'argomento
\param{cap\_d}; a differenza della precedente in questo caso il
\textit{capability state} deve essere stato creato in precedenza. Qualora il
-processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
+processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
valori possono essere letti direttamente nel filesystem \textit{proc}, nei
-file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
+file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
qualcosa del tipo:
\begin{Verbatim}
...
Infine per impostare le \textit{capabilities} del processo corrente (non
esiste una funzione che permetta di cambiare le \textit{capabilities} di un
altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
-prototipo è:
+prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
Imposta le \textit{capabilities} del processo corrente.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
\errval{EPERM} o \errval{ENOMEM}.
}
\end{functions}
La funzione modifica le \textit{capabilities} del processo corrente secondo
quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
-possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
-impostare capacità non presenti nell'insieme di quelle permesse). In caso di
+possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
+impostare capacità non presenti nell'insieme di quelle permesse). In caso di
successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
-di fallimento invece lo stato delle capacità resterà invariato. Si tenga
-presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
-devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
-quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
+di fallimento invece lo stato delle capacità resterà invariato. Si tenga
+presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
+devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
+quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
(neanche per le parti eventualmente permesse).
Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
-si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
-\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
- quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
+si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
+\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
+ quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
sono le \textit{capabilities} standard che ottiene un processo lanciato
dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
processo qualunque il cui pid viene passato come parametro dell'opzione.
\label{fig:proc_getcap}
\end{figure}
-La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
-e si basa su una condizione sulla variabile \var{pid} che se si è usato
-l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
-che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
+e si basa su una condizione sulla variabile \var{pid} che se si è usato
+l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
+che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
-\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
+\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
-stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
+stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
processo indicato.
-Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
+Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
-funzioni che permettono di modificarle. Si sarà notato come in realtà queste
-informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix
+funzioni che permettono di modificarle. Si sarà notato come in realtà queste
+informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix
origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
-minime. Con il venir meno di queste restrizioni è incominciata ad emergere
+minime. Con il venir meno di queste restrizioni è incominciata ad emergere
l'esigenza di poter associare ai file delle ulteriori informazioni astratte
-(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
+(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
trovare spazio nei dati classici mantenuti negli \itindex{inode}
\textit{inode}.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
Linux) hanno introdotto un meccanismo generico che consenta di associare delle
-informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
+informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
che tratteremo nella prossima sezione, ma si possono inserire anche altre
informazioni.} detto \textit{Extended Attributes}. Gli \textsl{attributi
estesi} non sono altro che delle coppie nome/valore che sono associate
possono essere mantenute ulteriori informazioni, che possono essere accedute
con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
-che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
-contenere solo una quantità limitata di informazione) hanno il grande
-vantaggio di essere molto più semplici da realizzare, più
+che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
+contenere solo una quantità limitata di informazione) hanno il grande
+vantaggio di essere molto più semplici da realizzare, più
efficienti,\footnote{cosa molto importante, specie per le applicazioni che
richiedono una gran numero di accessi, come le ACL.} e di garantire
-l'atomicità di tutte le operazioni.
+l'atomicità di tutte le operazioni.
In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
Attributes}, in particolare al momento della scrittura di queste dispense
essi sono presenti solo su \textsl{ext2}, \textsl{ext3} e \textsl{XFS}.
Inoltre a seconda della implementazione ci possono essere dei limiti sulla
-quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
- di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
+ di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
all'interno di un singolo blocco (pertanto con dimensioni massime pari a
1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
- mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
+ mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
gruppo proprietari del file.
gestione. Per questo motivo il nome di un attributo deve essere sempre
specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
fa riferimento alla classe a cui l'attributo appartiene, mentre
-\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
+\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
\end{table}
-Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
+Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
\itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
\index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
dalle politiche di sicurezza implementate all'interno dal modulo di
- sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
- stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
+ sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
+ stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
consentito a tutti i processi, mentre quello in scrittura solo ai processi
con privilegi amministrativi dotati della \index{capabilities}
\textit{capability} \const{CAP\_SYS\_ADMIN}.
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
attributes} dipende dalle politiche di accesso che il kernel realizza
anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
- delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
- processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
+ delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
+ processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
il permesso di lettura sulla directory che contiene il file) ed in scrittura
al proprietario del file o ai processi dotati della \textit{capability}
\index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
- per la lettura che per la scrittura, è consentito soltanto ai processi con
+ per la lettura che per la scrittura, è consentito soltanto ai processi con
privilegi amministrativi dotati della \index{capabilities}
\textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
utilizzare questi attributi per realizzare in user space dei meccanismi di
controllo che accedono ad informazioni non disponibili ai processi ordinari.
-\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
+\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
regolato dai normali permessi dei file: occorre avere il permesso di lettura
per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
- di questi attributi si è scelto di applicare al loro accesso gli stessi
+ di questi attributi si è scelto di applicare al loro accesso gli stessi
criteri che si usano per l'accesso al contenuto dei file (o delle directory)
- cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
+ cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
directory ordinarie, se valesse in generale infatti si avrebbe un serio
problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
- quali è normale avere avere il permesso di scrittura consentito a tutti gli
+ quali è normale avere avere il permesso di scrittura consentito a tutti gli
utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di
dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli
\textit{extended user attributes} un utente qualunque potrebbe inserirvi
- dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
+ dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
comportamento permetteva, non essendovi limiti sullo spazio occupabile
dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il
disco.}
La semantica del controllo di accesso indicata inoltre non avrebbe alcun
senso al di fuori di file e directory: i permessi di lettura e scrittura per
- un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
- di accesso al dispositivo sottostante,\footnote{motivo per cui si può
- formattare un disco anche se \texttt{/dev} è su un filesystem in sola
+ un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
+ di accesso al dispositivo sottostante,\footnote{motivo per cui si può
+ formattare un disco anche se \texttt{/dev} è su un filesystem in sola
lettura.} mentre per i link simbolici questi vengono semplicemente
ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
file, e nella discussione relativa all'uso degli \textit{extended user
- attributes} nessuno è mai stato capace di indicare una qualche forma
+ attributes} nessuno è mai stato capace di indicare una qualche forma
sensata di utilizzo degli stessi per link simbolici o
\index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
socket. Per questo motivo essi sono stati completamente disabilitati per
- tutto ciò che non sia un file regolare o una directory.\footnote{si può
+ tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
- dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
+ dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
- \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
- user attributes} soltanto se si è proprietari della stessa, o si hanno i
+ \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
+ user attributes} soltanto se si è proprietari della stessa, o si hanno i
privilegi amministrativi della capability \index{capabilities}
\const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
-installata a parte;\footnote{la versione corrente della libreria è
- \texttt{libattr1}.} pertanto se un programma le utilizza si dovrà indicare
+installata a parte;\footnote{la versione corrente della libreria è
+ \texttt{libattr1}.} pertanto se un programma le utilizza si dovrà indicare
esplicitamente l'uso della suddetta libreria invocando il compilatore con
l'opzione \texttt{-lattr}.
\bodydesc{Le funzioni restituiscono un intero positivo che indica la
dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
\item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
- non è sufficiente per contenere il risultato.
+ non è sufficiente per contenere il risultato.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
un pathname che indica il file di cui si vuole richiedere un attributo, la
-sola differenza è che la seconda, se il pathname indica un link simbolico,
+sola differenza è che la seconda, se il pathname indica un link simbolico,
restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
un numero di file descriptor, e richiede gli attributi del file ad esso
indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
-Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
+Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
possono essere costituiti arbitrariamente da dati testuali o binari.} se
-quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
Per evitare di dover indovinare la dimensione di un attributo per tentativi si
-può eseguire una interrogazione utilizzando un valore nullo per \param{size};
-in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
+può eseguire una interrogazione utilizzando un valore nullo per \param{size};
+in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
ritorno della funzione chiamata la dimensione totale dell'attributo esteso
-richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
-sufficienti.\footnote{si parla di stima perché anche se le funzioni
+richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
+sufficienti.\footnote{si parla di stima perché anche se le funzioni
restituiscono la dimensione esatta dell'attributo al momento in cui sono
eseguite, questa potrebbe essere modificata in qualunque momento da un
successivo accesso eseguito da un altro processo.}
-Un secondo gruppo di funzioni è quello che consente di impostare il valore di
+Un secondo gruppo di funzioni è quello che consente di impostare il valore di
un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
link simbolico o specificando un file descriptor; i loro prototipi sono:
Impostano il valore di un attributo esteso.
\bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
+ \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
l'attributo richiesto non esiste.
- \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
- l'attributo esiste già.
+ \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
+ l'attributo esiste già.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
(completo di suffisso) dell'attributo su cui si vuole operare.
-Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
-puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
+Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
+puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
-controllare le modalità di sovrascrittura dell'attributo esteso, esso può
+controllare le modalità di sovrascrittura dell'attributo esteso, esso può
prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
-esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
+esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
-caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
+modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
+modificato se è già presente, o creato se non c'è.
Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
\bodydesc{Le funzioni restituiscono un intero positivo che indica la
dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
- qual caso \var{errno} assumerà i valori:
+ qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
- non è sufficiente per contenere il risultato.
+ non è sufficiente per contenere il risultato.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
La lista viene fornita come sequenza non ordinata dei nomi dei singoli
attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
-dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
+dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
uno di seguito all'altro. Il valore di ritorno della funzione indica la
dimensione totale della lista in byte.
Come per le funzioni di lettura dei singoli attributi se le dimensioni del
-buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
+buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
valore di ritorno della funzione una stima della dimensione totale della lista
usando per \param{size} un valore nullo.
Rimuovono un attributo esteso di un file.
\bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
\param{name} rispettivamente di un file, un link simbolico o specificando un
file descriptor, da specificare con il loro primo argomento. Anche in questo
-caso l'argomento \param{name} deve essere specificato con le modalità già
+caso l'argomento \param{name} deve essere specificato con le modalità già
illustrate in precedenza per le altre funzioni relative agli attributi estesi.
\itindend{Extended~Attributes}
\subsection{Le \textit{Access Control List}}
\label{sec:file_ACL}
-% la documentazione di sistema è nei pacchetti libacl1-dev e acl
+% la documentazione di sistema è nei pacchetti libacl1-dev e acl
% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
\itindbeg{Access~Control~List}
Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
-è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
-le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
+è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
+le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
rispondere in maniera adeguata a situazioni che richiedono una gestione
-complessa dei permessi di accesso.\footnote{già un requisito come quello di
+complessa dei permessi di accesso.\footnote{già un requisito come quello di
dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
- si può soddisfare in maniera semplice.}
+ si può soddisfare in maniera semplice.}
Per questo motivo erano state progressivamente introdotte nelle varie versioni
-di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
+di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
forma delle cosiddette \textit{Access Control List} (indicate usualmente con
-la sigla ACL). Nello sforzo di standardizzare queste funzionalità era stato
+la sigla ACL). Nello sforzo di standardizzare queste funzionalità era stato
creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
di programmazione e la POSIX 1003.2c per i comandi di shell.
-Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
+Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
-uno standard, dato però che una parte della documentazione prodotta era di
-alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
+uno standard, dato però che una parte della documentazione prodotta era di
+alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
-che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
+che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
ACL}.
-A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
+A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
scelto di realizzare le ACL attraverso l'uso degli
\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
Anche in questo caso le funzioni di questa libreria non fanno parte delle
\acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
- della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
+ della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
- per i file di sviluppo.} pertanto se un programma le utilizza si dovrà
+ per i file di sviluppo.} pertanto se un programma le utilizza si dovrà
indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
poterle utilizzare le ACL devono essere attivate esplicitamente montando il
-filesystem\footnote{che deve supportarle, ma questo è ormai vero per
- praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
- quale esiste però un supporto sperimentale.} su cui le si vogliono
+filesystem\footnote{che deve supportarle, ma questo è ormai vero per
+ praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
+ quale esiste però un supporto sperimentale.} su cui le si vogliono
utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una
-estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
+estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
-Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
+Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
costituita da un \textsl{tipo}, da un eventuale
\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
-Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
+Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si
-può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
-indicare quale dovrà essere la ACL assegnata di default nella creazione di un
+può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+indicare quale dovrà essere la ACL assegnata di default nella creazione di un
file all'interno della directory stessa. Come avviene per i permessi le ACL
possono essere impostate solo del proprietario del file, o da un processo con
la capability \index{capabilities} \const{CAP\_FOWNER}.
\end{table}
L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
-del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
+del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
file (proprietario, gruppo proprietario e tutti gli altri) e per questo una
ACL valida deve sempre contenere una ed una sola voce per ciascuno di questi
tipi.
-Una ACL può poi contenere un numero arbitrario di voci di tipo
-\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
+Una ACL può poi contenere un numero arbitrario di voci di tipo
+\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
-ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
-in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
+in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
-casi è opzionale.
+casi è opzionale.
Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
\const{ACL\_GROUP\_OBJ}; se in una di queste voci si fosse specificato un
permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
-una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
+una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
associata ad una \textit{default ACL} su una directory, in quanto i permessi
-così specificati verranno ereditati da tutti i file creati nella stessa
-directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
+così specificati verranno ereditati da tutti i file creati nella stessa
+directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
associata ad un oggetto sul filesystem piuttosto che a un processo.
Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno
qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si
intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
- filesystem può essere montato senza abilitare le ACL.} e viceversa. In
-realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
+ filesystem può essere montato senza abilitare le ACL.} e viceversa. In
+realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
-se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
+se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
non presenti in \const{ACL\_MASK}.\footnote{questo diverso comportamento a
- seconda delle condizioni è stato introdotto dalla standardizzazione
+ seconda delle condizioni è stato introdotto dalla standardizzazione
\textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui
sistemi dotati di ACL per tutte quelle applicazioni che sono conformi
soltanto all'ordinario standard \textit{POSIX 1003.1}.}
-Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
+Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
filesystem, il comportamento discusso vale per le funzioni \func{open} e
\func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
- sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
+ sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
presenza di una \textit{default ACL} sulla directory che contiene quel file.
-Se questa non c'è valgono le regole usuali illustrate in
+Se questa non c'è valgono le regole usuali illustrate in
sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
-\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
+\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
permessi ordinari da esse risultanti vengono automaticamente rimappati anche
su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
soltanto le tre corrispondenti voci di tipo \const{ACL\_USER\_OBJ},
\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
-Se invece è presente una ACL di default sulla directory che contiene il nuovo
-file questa diventerà automaticamente la sua ACL di accesso, a meno di non
+Se invece è presente una ACL di default sulla directory che contiene il nuovo
+file questa diventerà automaticamente la sua ACL di accesso, a meno di non
aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
valore per i permessi ordinari;\footnote{tutte le funzioni citate in
precedenza supportano un argomento \var{mode} che indichi un insieme di
permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
nella ACL tutti quelli non presenti in tale indicazione.
-Dato che questa è la ragione che ha portato alla loro creazione, la principale
-modifica introdotta con la presenza della ACL è quella alle regole del
+Dato che questa è la ragione che ha portato alla loro creazione, la principale
+modifica introdotta con la presenza della ACL è quella alle regole del
controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
Come nel caso ordinario per il controllo vengono sempre utilizzati gli
identificatori del gruppo \textit{effective} del processo, ma in presenza di
ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
sono i seguenti:
\begin{enumerate*}
-\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
+\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
nessun controllo.
\item Se l'user-ID del processo corrisponde al proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
- l'accesso è consentito;
- \item altrimenti l'accesso è negato.
+ l'accesso è consentito;
+ \item altrimenti l'accesso è negato.
\end{itemize*}
\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
presente in una voce \const{ACL\_USER} allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER} corrispondente e la voce
- \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
consentito;
- \item altrimenti l'accesso è negato.
+ \item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
+\item Se è il group-ID del processo o uno dei group-ID supplementari
corrisponde al gruppo proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
\const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
- può non essere presente) contengono entrambe il permesso richiesto,
- l'accesso è consentito;
- \item altrimenti l'accesso è negato.
+ può non essere presente) contengono entrambe il permesso richiesto,
+ l'accesso è consentito;
+ \item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
+\item Se è il group-ID del processo o uno dei group-ID supplementari
corrisponde ad un qualunque qualificatore presente in una voce
\const{ACL\_GROUP} allora:
\begin{itemize*}
\item se la voce \const{ACL\_GROUP} corrispondente e la voce
- \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
consentito;
- \item altrimenti l'accesso è negato.
+ \item altrimenti l'accesso è negato.
\end{itemize*}
\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
- l'accesso è consentito, altrimenti l'accesso è negato.
+ l'accesso è consentito, altrimenti l'accesso è negato.
\end{enumerate*}
I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
per identificare i permessi standard di lettura, scrittura ed esecuzione.}
tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
-queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
-è:
+queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
+è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
- assumerà uno dei valori:
+ assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
- \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
+ \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
\end{errlist}
}
\end{functions}
-La funzione alloca ed inizializza un'area di memoria che verrà usata per
+La funzione alloca ed inizializza un'area di memoria che verrà usata per
mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte
le altre funzioni che operano sulla ACL. La funzione si limita alla
allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota.
Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
-``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
che un puntatore all'area di memoria allocata per i dati richiesti; pertanto
-in caso di fallimento verrà restituito un puntatore nullo e si dovrà
+in caso di fallimento verrà restituito un puntatore nullo e si dovrà
confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
-allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
-funzione \funcd{acl\_free}, il cui prototipo è:
+allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
+funzione \funcd{acl\_free}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
Disalloca la memoria riservata per i dati di una ACL.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
- \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
- assumerà il valore \errcode{EINVAL}
+ \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
+ assumerà il valore \errcode{EINVAL}
}
\end{functions}
Si noti come la funzione richieda come argomento un puntatore di tipo
-``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
+``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
memoria allocata per i dati di una ACL, ma anche per quella usata per creare
le stringhe di descrizione testuale delle ACL o per ottenere i valori dei
-qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
+qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
\textit{cast} a ``\ctyp{void *}'' del tipo di dato di cui si vuole eseguire la
disallocazione. Si tenga presente poi che oltre a \func{acl\_init} esistono
-molte altre funzioni che possono allocare memoria per i dati delle ACL, è
-pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
-delle operazioni tutta la memoria allocata dovrà essere liberata con
+molte altre funzioni che possono allocare memoria per i dati delle ACL, è
+pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
+delle operazioni tutta la memoria allocata dovrà essere liberata con
\func{acl\_free}.
Una volta che si abbiano a disposizione i dati di una ACL tramite il
riferimento ad oggetto di tipo \type{acl\_t} questi potranno essere copiati
-con la funzione \funcd{acl\_dup}, il cui prototipo è:
+con la funzione \funcd{acl\_dup}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
- \var{errno} assumerà uno dei valori:
+ \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
+ \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
per una ACL.
- \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
la copia.
\end{errlist}
}
\param{acl}, allocando autonomamente tutto spazio necessario alla copia e
restituendo un secondo oggetto di tipo \type{acl\_t} come riferimento a
quest'ultima. Valgono per questo le stesse considerazioni fatte per il valore
-di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
+di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
prevedere una ulteriore chiamata esplicita a \func{acl\_free} per liberare la
memoria occupata dalla copia.
-Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
-dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
+Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
+dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
\funcd{acl\_from\_mode} che consente di creare una ACL a partire da un valore
-di permessi ordinari, il prototipo della funzione è:
+di permessi ordinari, il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
- \var{errno} assumerà il valore \errval{ENOMEM}.
+ \var{errno} assumerà il valore \errval{ENOMEM}.
}
\end{functions}
La funzione restituisce una ACL inizializzata con le tre voci obbligatorie
-\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
+\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
impostate secondo la corrispondenza ai valori dei permessi ordinari indicati
-dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
-estensione usata dalle ACL di Linux e non è portabile, ma consente di
+dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
+estensione usata dalle ACL di Linux e non è portabile, ma consente di
semplificare l'inizializzazione in maniera molto comoda.
-Altre due funzioni che consentono di creare una ACL già inizializzata sono
-\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
+Altre due funzioni che consentono di creare una ACL già inizializzata sono
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
sono:
\begin{functions}
\bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
- \var{errno} assumerà uno dei valori:
+ \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
\item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
supporta le ACL.
\end{errlist}
\end{functions}
Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
-della ACL correntemente associata ad un file, che può essere identificato
+della ACL correntemente associata ad un file, che può essere identificato
tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
-\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
+\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
anche la ACL relativa ad una directory, il secondo argomento \param{type}
consente di specificare se si vuole ottenere la ACL di default o quella di
-accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
+accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
\begin{table}[htb]
\label{tab:acl_type}
\end{table}
-Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
+Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli
attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
-inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
-soltanto per una directory, e verrà restituita solo se presente, altrimenti
-verrà restituita una ACL vuota.
+inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
+soltanto per una directory, e verrà restituita solo se presente, altrimenti
+verrà restituita una ACL vuota.
-Infine si potrà creare una ACL direttamente dalla sua rappresentazione
-testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+Infine si potrà creare una ACL direttamente dalla sua rappresentazione
+testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
- \var{errno} assumerà uno dei valori:
+ \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
\item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
- \param{buf\_p} non è valida.
+ \param{buf\_p} non è valida.
\end{errlist}
}
\end{functions}
-La funzione prende come argomento il puntatore ad un buffer dove si è inserita
+La funzione prende come argomento il puntatore ad un buffer dove si è inserita
la rappresentazione testuale della ACL che si vuole creare, la memoria
necessaria viene automaticamente allocata ed in caso di successo viene
restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
-contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+contenuto della stessa, che come per le precedenti funzioni, dovrà essere
disallocato esplicitamente al termine del suo utilizzo.
-La rappresentazione testuale di una ACL è quella usata anche dai comandi
+La rappresentazione testuale di una ACL è quella usata anche dai comandi
ordinari per la gestione delle ACL (\texttt{getfacl} e \texttt{setfacl}), che
prevede due diverse forme, estesa e breve, entrambe supportate da
\func{acl\_from\_text}. La forma estesa prevede che sia specificata una voce
\begin{Verbatim}
tipo:qualificatore:permessi
\end{Verbatim}
-dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
-e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
+dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
+e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
permessi sono espressi con una tripletta di lettere analoga a quella usata per
i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
rispettivamente per indicare delle voci relative ad utenti e
-gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
+gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
\const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
\const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
del file che a quelli generici; quelle dei proprietari si riconoscono per
l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
-Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
+Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
questa forma si possono anche inserire dei commenti precedendoli con il
carattere ``\texttt{\#}''.
La forma breve prevede invece la scrittura delle singole voci su una riga,
separate da virgole; come specificatori del tipo di voce si possono usare le
-iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
+iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
voce sono le stesse. In questo caso non sono consentiti permessi.
Per la conversione inversa, che consente di ottenere la rappresentazione
testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
-di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
+di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce il puntatore ad una stringa con la
rappresentazione testuale della ACL in caso di successo e
- \code(acl\_t){NULL} in caso di errore, nel qual caso \var{errno} assumerà
+ \code(acl\_t){NULL} in caso di errore, nel qual caso \var{errno} assumerà
uno dei valori:
\begin{errlist}
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
}
La funzione restituisce il puntatore ad una stringa terminata da NUL
contenente la rappresentazione in forma estesa della ACL passata come
-argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
-essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita la dimensione della stringa con la
+intera in questa verrà restituita la dimensione della stringa con la
rappresentazione testuale (non comprendente il carattere nullo finale).
La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
dovizia di dettagli la generazione della stringa contenente la
-rappresentazione testuale della ACL, il suo prototipo è:
+rappresentazione testuale della ACL, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce il puntatore ad una stringa con la
rappresentazione testuale della ACL in caso di successo e \code{NULL} in
- caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
}
La funzione converte in formato testo la ACL indicata dall'argomento
\param{acl}, usando il carattere \param{separator} come separatore delle
-singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
+singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
indicata viene utilizzata come prefisso per le singole voci.
-L'ultimo argomento, \param{options}, consente di controllare la modalità con
+L'ultimo argomento, \param{options}, consente di controllare la modalità con
cui viene generata la rappresentazione testuale. Un valore nullo fa si che
vengano usati gli identificatori standard \texttt{user}, \texttt{group},
\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
-ai loro valori numerici. Altrimenti si può specificare un valore in forma di
+ai loro valori numerici. Altrimenti si può specificare un valore in forma di
maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
tab.~\ref{tab:acl_to_text_options}.
\const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
vengono eliminati dalla \const{ACL\_MASK}
viene generato un commento con i permessi
- effettivamente risultanti; il commento è
+ effettivamente risultanti; il commento è
separato con un tabulatore.\\
\const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
effettivi per ciascuna voce che contiene
permessi citati nella \const{ACL\_MASK},
anche quando questi non vengono modificati
- da essa; il commento è separato con un
+ da essa; il commento è separato con un
tabulatore.\\
\const{TEXT\_SMART\_INDENT} & da usare in combinazione con le precedenti
\const{TEXT\_SOME\_EFFECTIVE} e
Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
rappresentazione testuale dell'ACL, di cui la funzione restituisce
-l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
+l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
-questa funzione è una estensione specifica di Linux, e non è presente nella
+questa funzione è una estensione specifica di Linux, e non è presente nella
bozza dello standard POSIX.1e.
Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
-la forma testuale non è la più efficiente per poter memorizzare i dati
+la forma testuale non è la più efficiente per poter memorizzare i dati
relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
-archiviazione. Per questo è stata prevista la possibilità di utilizzare una
+archiviazione. Per questo è stata prevista la possibilità di utilizzare una
rappresentazione delle ACL in una apposita forma binaria contigua e
-persistente. È così possibile copiare il valore di una ACL in un buffer e da
+persistente. È così possibile copiare il valore di una ACL in un buffer e da
questa rappresentazione tornare indietro e generare una ACL.
-Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
-semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
+Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
+semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
la citata rappresentazione binaria, in modo da poter allocare per essa un
-buffer di dimensione sufficiente, il suo prototipo è:
+buffer di dimensione sufficiente, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce in caso di successo la dimensione in byte
della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
- caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
}
\end{functions}
-Prima di effettuare la lettura della rappresentazione binaria è sempre
+Prima di effettuare la lettura della rappresentazione binaria è sempre
necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
-prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
+prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
poi allocare il buffer con una delle funzioni di
sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
-rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
+rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
-La funzione che consente di leggere la rappresentazione binaria di una ACL è
-\funcd{acl\_copy\_ext}, il cui prototipo è:
+La funzione che consente di leggere la rappresentazione binaria di una ACL è
+\funcd{acl\_copy\_ext}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce in caso di successo la dimensione in byte
della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
- caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
- \param{size} è negativo o nullo.
- \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
+ \param{size} è negativo o nullo.
+ \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
dimensione della rappresentazione della ACL.
\end{errlist}
}
\end{functions}
-La funzione salverà la rappresentazione binaria della ACL indicata da
+La funzione salverà la rappresentazione binaria della ACL indicata da
\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
la dimensione della rappresentazione ecceda il valore di \param{size} la
-funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
+funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
effetto sulla ACL indicata da \param{acl}.
Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
-binaria della stessa disponibile in un buffer si potrà usare la funzione
-\funcd{acl\_copy\_int}, il cui prototipo è:
+binaria della stessa disponibile in un buffer si potrà usare la funzione
+\funcd{acl\_copy\_int}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
- \var{errno} assumerà uno dei valori:
+ \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene
una rappresentazione corretta di una ACL.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
\type{acl\_t} per la ACL richiesta.
\end{errlist}
\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
della ACL rappresentata dai dati contenuti nel buffer puntato da
\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
-\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
+\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
utilizzo.
-Una volta che si disponga della ACL desiderata, questa potrà essere impostata
+Una volta che si disponga della ACL desiderata, questa potrà essere impostata
su un file o una directory. Per impostare una ACL sono disponibili due
-funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
-directory, ed il cui prototipo è:
+funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
+directory, ed il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
Imposta una ACL su un file o una directory.
\bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
- valore di \param{type} specifica una ACL il cui tipo non può essere
+ valore di \param{type} specifica una ACL il cui tipo non può essere
assegnato a \param{path}.
- \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
ha in valore non corretto.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
dati aggiuntivi della ACL.
- \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
contenuto in un filesystem che non supporta le ACL.
\end{errlist}
ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
alla directory indicate dal pathname \param{path}, mentre con \param{type} si
indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
si tenga presente che le ACL di default possono essere solo impostate
-qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
-successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
-unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
-ACL di default associata a \func{path}.\footnote{questo però è una estensione
+qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
+successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
+unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
+ACL di default associata a \func{path}.\footnote{questo però è una estensione
della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
prende come unico argomento il pathname della directory di cui si vuole
cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
- manuale.} La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, ed il suo prototipo è:
+ manuale.} La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
Imposta una ACL su un file descriptor.
\bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EBADF}].
- \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
ha in valore non corretto.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
dati aggiuntivi della ACL.
- \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
contenuto in un filesystem che non supporta le ACL.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
}
\end{functions}
-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
esclusivamente sui file identificati tramite un file descriptor. Non dovendo
-avere a che fare con directory (e con la conseguente possibilità di avere una
+avere a che fare con directory (e con la conseguente possibilità di avere una
ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
-che sarà sempre di accesso, e prende come unico argomento, a parte il file
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
descriptor, la ACL da impostare.
Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
-generale è possibile modificare un singolo valore all'interno di una singola
+generale è possibile modificare un singolo valore all'interno di una singola
voce direttamente con le funzioni previste dallo standard POSIX.1e. Queste
-funzioni però sono alquanto macchinose da utilizzare per cui è molto più
-semplice operare direttamente sulla rappresentazione testuale. Questo è il
+funzioni però sono alquanto macchinose da utilizzare per cui è molto più
+semplice operare direttamente sulla rappresentazione testuale. Questo è il
motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
-descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
manuale.
Se si vuole operare direttamente sui contenuti di un oggetto di tipo
opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
-prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
singole voci successive alla prima.
-Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
qualificatore e permessi mentre con le corrispondente funzioni
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
-% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
% dentro chroot SELinux e AppArmor ???
-Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
-\func{chroot} viene usata spesso per restringere le capacità di accesso di un
+Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
+\func{chroot} viene usata spesso per restringere le capacità di accesso di un
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
dal kernel (ed illustrato in sez.~\ref{sec:file_organization}), ha per il
processo il significato specifico di directory rispetto alla quale vengono
risolti i \itindsub{pathname}{assoluto}\textit{pathname}
-assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
\textit{pathname}, il kernel usa sempre questa directory come punto di
partenza.} Il fatto che questo valore sia specificato per ogni processo apre
-allora la possibilità di modificare le modalità di risoluzione dei
+allora la possibilità di modificare le modalità di risoluzione dei
\textit{pathname} assoluti da parte di un processo cambiando questa directory,
-così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi
+così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi
cambiando la directory di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
\itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre
dalla stessa directory, che corrisponde alla radice del sistema.
-In certe situazioni però è utile poter impedire che un processo possa accedere
-a tutto il filesystem; per far questo si può cambiare la sua directory radice
-con la funzione \funcd{chroot}, il cui prototipo è:
+In certe situazioni però è utile poter impedire che un processo possa accedere
+a tutto il filesystem; per far questo si può cambiare la sua directory radice
+con la funzione \funcd{chroot}, il cui prototipo è:
\begin{prototype}{unistd.h}{int chroot(const char *path)}
Cambia la directory radice del processo a quella specificata da
\param{path}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per
- un errore, in caso di errore \var{errno} può assumere i valori:
+ un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero.
+ \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
\errval{EROFS} e \errval{EIO}.}
\end{prototype}
-\noindent in questo modo la directory radice del processo diventerà
+\noindent in questo modo la directory radice del processo diventerà
\param{path} (che ovviamente deve esistere) ed ogni
\itindsub{pathname}{assoluto}\textit{pathname} assoluto usato dalle funzioni
-chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
-accedere alla parte di albero sovrastante. Si ha così quella che viene
-chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
-a file al di fuori della sezione di albero in cui è stato
+chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
+accedere alla parte di albero sovrastante. Si ha così quella che viene
+chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
+a file al di fuori della sezione di albero in cui è stato
\textsl{imprigionato}.
-Solo un processo con i privilegi di amministratore può usare questa funzione,
-e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
-da tutti i suoi processi figli. Si tenga presente però che la funzione non
+Solo un processo con i privilegi di amministratore può usare questa funzione,
+e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
+da tutti i suoi processi figli. Si tenga presente però che la funzione non
cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
jail}.
-Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
+Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
+resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
comunque accedere a tutto il resto del filesystem usando
\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
+dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
filesystem.
-Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
+Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
\func{chroot} su una qualunque directory contenuta nell'attuale directory di
lavoro. Per questo motivo l'uso di questa funzione non ha molto senso quando
un processo necessita dei privilegi di root per le sue normali operazioni.
-Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
+Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
-contiene i file. Si tenga presente però che in questo caso occorrerà
+contiene i file. Si tenga presente però che in questo caso occorrerà
replicare all'interno della \textit{chroot jail} tutti i file (in genere
programmi e librerie) di cui il server potrebbe avere bisogno.
\chapter{L'architettura dei file}
\label{cha:file_intro}
-Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
-cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
+Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
+cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
dispositivi di input/output del computer viene effettuato attraverso
un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
file di dati.
-Questo significa che si può accedere a qualunque periferica del computer,
+Questo significa che si può accedere a qualunque periferica del computer,
dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
cosiddetti \index{file!di~dispositivo} file di dispositivo (i cosiddetti
\textit{device file}). Questi sono dei file speciali agendo sui quali i
In questo capitolo forniremo una descrizione dell'architettura dei file in
Linux, iniziando da una panoramica sulle caratteristiche principali delle
interfacce con cui i processi accedono ai file (che tratteremo in dettaglio
-nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
-delle modalità con cui detto accesso viene realizzato dal sistema.
+nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
+delle modalità con cui detto accesso viene realizzato dal sistema.
Per poter accedere ai file, il kernel deve mettere a disposizione dei
programmi le opportune interfacce che consentano di leggerne il contenuto; il
-sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
+sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
Questo viene fatto strutturando l'informazione sul disco attraverso quello che
si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa
viene chiamata \textit{root directory}) viene montata all'avvio. Un file
viene identificato dall'utente usando quello che viene chiamato
\textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa
- nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
+ nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
un insieme di directory su cui effettuare una ricerca (come quello in cui si
cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e
di componente per il nome del file all'interno della directory. Non
- seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
- ormai così comune che mantenerne l'uso è senz'altro più chiaro
- dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
-al file a partire dalla \textit{root directory}, che è composto da una serie
+ seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
+ ormai così comune che mantenerne l'uso è senz'altro più chiaro
+ dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
+al file a partire dalla \textit{root directory}, che è composto da una serie
di nomi separati da una ``\file{/}''.
All'avvio del sistema, completata la fase di inizializzazione, il kernel
riceve dal bootloader l'indicazione di quale dispositivo contiene il
filesystem da usare come punto di partenza e questo viene montato come radice
-dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
+dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
che possono essere su altri dispositivi dovranno poi essere inseriti
nell'albero montandoli su opportune directory del filesystem montato come
radice.
stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
Una directory, come vedremo in maggior dettaglio in
-sez.~\ref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
-particolare che il kernel riconosce come tale. Il suo scopo è quello di
+sez.~\ref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+particolare che il kernel riconosce come tale. Il suo scopo è quello di
contenere una lista di nomi di file e le informazioni che associano ciascun
nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
un'organizzazione ad albero inserendo nomi di directory in altre directory.
-Un file può essere indicato rispetto alla directory corrente semplicemente
+Un file può essere indicato rispetto alla directory corrente semplicemente
specificandone il nome\footnote{il manuale delle \acr{glibc} chiama i nomi
contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
- components}), noi li chiameremo più semplicemente \textsl{nomi} o
+ components}), noi li chiameremo più semplicemente \textsl{nomi} o
\textsl{voci}.} da essa contenuto. All'interno dello stesso albero si
potranno poi inserire anche tutti gli altri oggetti visti attraverso
l'interfaccia che manipola i file come le fifo, i link, i socket e gli stessi
convenzione, sono inseriti nella directory \file{/dev}).
Il nome completo di un file viene chiamato \textit{pathname} ed il
-procedimento con cui si individua il file a cui esso fa riferimento è chiamato
+procedimento con cui si individua il file a cui esso fa riferimento è chiamato
risoluzione del nome (\textit{filename resolution} o \textit{pathname
resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
sinistra a destra e localizzando ogni nome nella directory indicata dal nome
precedente usando il carattere ``\texttt{/}'' come separatore\footnote{nel
caso di nome vuoto, il costrutto \file{//} viene considerato equivalente a
- \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi
+ \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi
indicati come directory esistano e siano effettivamente directory, inoltre i
permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire
l'accesso all'intero \textit{pathname}.
Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
parte dalla directory radice del processo; questa, a meno di un \func{chroot}
-(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i
+(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i
processi ed equivale alla directory radice dell'albero dei file: in questo
caso si parla di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}.
Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in
-sez.~\ref{sec:file_work_dir}) ed il pathname è detto
+sez.~\ref{sec:file_work_dir}) ed il pathname è detto
\itindsub{pathname}{relativo} \textsl{pathname relativo}.
I nomi ``\file{.}'' e ``\file{..}'' hanno un significato speciale e vengono
inseriti in ogni directory: il primo fa riferimento alla directory corrente e
il secondo alla directory \textsl{genitrice} (o \textit{parent directory})
-cioè la directory che contiene il riferimento alla directory corrente; nel
+cioè la directory che contiene il riferimento alla directory corrente; nel
caso la directory corrente coincida con la directory radice, allora il
-riferimento è a se stessa.
+riferimento è a se stessa.
\itindend{pathname}
sono implementati come oggetti del \textit{Virtual File System} (vedi
sez.~\ref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
-\itindex{Virtual~File~System} \textit{Virtual File System} è riportato in
+\itindex{Virtual~File~System} \textit{Virtual File System} è riportato in
tab.~\ref{tab:file_file_types}.
Si tenga ben presente che questa classificazione non ha nulla a che fare con
la classificazione dei file (che in questo caso sono sempre file di dati) in
base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
-oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
+oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
Alcuni di essi, come le \textit{fifo} (che tratteremo in
sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
-delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
+delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
\index{file!di~dispositivo} \textsl{file di dispositivo} (o \textit{device
file}) che costituiscono una interfaccia diretta per leggere e scrivere sui
dispositivi fisici; essi vengono suddivisi in due grandi categorie, \textsl{a
- blocchi} e \textsl{a caratteri} a seconda delle modalità in cui il
+ blocchi} e \textsl{a caratteri} a seconda delle modalità in cui il
dispositivo sottostante effettua le operazioni di I/O.\footnote{in sostanza i
dispositivi a blocchi (ad esempio i dischi) corrispondono a periferiche per
- le quali è richiesto che l'I/O venga effettuato per blocchi di dati di
+ le quali è richiesto che l'I/O venga effettuato per blocchi di dati di
dimensioni fissate (ad esempio le dimensioni di un settore), mentre nei
dispositivi a caratteri l'I/O viene effettuato senza nessuna particolare
struttura.}
\end{table}
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
+Windows) è che per Unix tutti i file di dati sono identici e contengono un
+flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
sistema file di diverso contenuto o formato (come nel caso di quella fra file
-di testo e binari che c'è in Windows) né c'è una strutturazione a record per
+di testo e binari che c'è in Windows) né c'è una strutturazione a record per
il cosiddetto ``\textsl{accesso diretto}'' come nel caso del
VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
- ed è completamente trasparente all'utente. Inoltre talvolta si parla di
- \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
- fare con tutto ciò, di effettuare, attraverso degli appositi
+ ed è completamente trasparente all'utente. Inoltre talvolta si parla di
+ \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
+ fare con tutto ciò, di effettuare, attraverso degli appositi
\index{file!di~dispositivo} file di dispositivo, operazioni di I/O
direttamente sui dischi senza passare attraverso un filesystem, il
cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ed
in sostanziale disuso.}
-Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è
+Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è
codificata in maniera diversa da Windows o dal vecchio MacOS, in particolare
-il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
+il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
(\verb|\r|) del vecchio MacOS e del \texttt{CR LF} di Windows.\footnote{per
questo esistono in Linux dei programmi come \cmd{unix2dos} e \cmd{dos2unix}
- che effettuano una conversione fra questi due formati di testo.} Questo può
+ che effettuano una conversione fra questi due formati di testo.} Questo può
causare alcuni problemi qualora nei programmi si facciano assunzioni sul
terminatore della riga.
Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
-tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
-estensioni come parte del filesystem.\footnote{non è così ad esempio nel
+tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
+estensioni come parte del filesystem.\footnote{non è così ad esempio nel
filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
che specificano fra l'altro il contenuto ed il programma da usare per
- leggerlo. In realtà per alcuni filesystem esiste la possibilità di
+ leggerlo. In realtà per alcuni filesystem esiste la possibilità di
associare delle risorse ai file con gli \textit{extended attributes} (vedi
- sez.~\ref{sec:file_xattr}), ma è una caratteristica tutt'ora poco
+ sez.~\ref{sec:file_xattr}), ma è una caratteristica tutt'ora poco
utilizzata, dato che non corrisponde al modello classico dei file in un
- sistema Unix.} Ciò nonostante molti programmi adottano delle convenzioni per
+ sistema Unix.} Ciò nonostante molti programmi adottano delle convenzioni per
i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}; un'altra tecnica molto usata è quella di utilizzare i
+l'estensione \file{.c}; un'altra tecnica molto usata è quella di utilizzare i
primi 4 byte del file per memorizzare un \textit{magic number} che classifichi
il contenuto; entrambe queste tecniche, per quanto usate ed accettate in
-maniera diffusa, restano solo delle convenzioni il cui rispetto è demandato
+maniera diffusa, restano solo delle convenzioni il cui rispetto è demandato
alle applicazioni stesse.
\subsection{Le due interfacce ai file}
\label{sec:file_io_api}
-In Linux le modalità di accesso ai file e le relative interfacce di
-programmazione sono due, basate su due diversi meccanismi con cui è possibile
+In Linux le modalità di accesso ai file e le relative interfacce di
+programmazione sono due, basate su due diversi meccanismi con cui è possibile
accedere al loro contenuto.
-La prima è l'interfaccia standard di Unix, quella che il manuale delle
+La prima è l'interfaccia standard di Unix, quella che il manuale delle
\textsl{glibc} chiama interfaccia dei descrittori di file (o \textit{file
- descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce
+ descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce
un accesso non bufferizzato; la tratteremo in dettaglio in
cap.~\ref{cha:file_unix_interface}.
-L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
+L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
-direttamente le system call del kernel (in realtà il kernel effettua al suo
+direttamente le system call del kernel (in realtà il kernel effettua al suo
interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
dispositivi); i \index{file!descriptor} \textit{file descriptor} sono
-rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
-L'interfaccia è definita nell'header \file{unistd.h}.
+rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
+L'interfaccia è definita nell'header \file{unistd.h}.
-La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
-\index{file!stream} \textit{stream}.\footnote{in realtà una interfaccia con lo
- stesso nome è stata introdotta a livello di kernel negli Unix derivati da
+La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
+\index{file!stream} \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
+più evolute e un accesso bufferizzato (controllato dalla implementazione fatta
dalle \acr{glibc}), la tratteremo in dettaglio nel
cap.~\ref{cha:files_std_interface}.
-Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
+Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
anche su tutti i sistemi non Unix. Gli \index{file!stream} \textit{stream}
sono oggetti complessi e sono rappresentati da puntatori ad un opportuna
struttura definita dalle librerie del C; si accede ad essi sempre in maniera
-indiretta utilizzando il tipo \ctyp{FILE *}. L'interfaccia è definita
+indiretta utilizzando il tipo \ctyp{FILE *}. L'interfaccia è definita
nell'header \file{stdio.h}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
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
+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}).
Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
quella dei \textit{file descriptor}, che permette di poter scegliere tra
diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
-è che l'interfaccia per le operazioni di input/output è enormemente più ricca
+è che l'interfaccia per le operazioni di input/output è enormemente più ricca
di quella dei \textit{file descriptor}, che forniscono solo funzioni
elementari per la lettura/scrittura diretta di blocchi di byte. In
particolare gli \index{file!stream} \textit{stream} dispongono di tutte le
dati in forma di linee o singoli caratteri.
In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
-standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
+standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
tempo uno \index{file!stream} \textit{stream} ad un \index{file!descriptor}
\textit{file descriptor}.
-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
+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.
+infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed è pertanto di
+portabilità più limitata.
\label{sec:file_arch_func}
In questa sezione esamineremo come viene implementato l'accesso ai file in
-Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
+Linux, 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
+per poi trattare in maniera un po' più dettagliata il filesystem più usato con
Linux, l'\acr{ext2} (e derivati).
\itindbeg{Virtual~File~System}
-In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è uno
-strato intermedio che il kernel usa per accedere ai più svariati filesystem
+In Linux il concetto di \textit{everything is a file} è stato implementato
+attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è uno
+strato intermedio che il kernel usa per accedere ai più svariati filesystem
mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce
un livello di indirezione che permette di collegare le operazioni di
manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
albero delle directory.
Quando un processo esegue una system call che opera su un file, il kernel
-chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
-manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle
+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
+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}.
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 tutto quello che occorre è chiamare la funzione
+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.
+all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
In questo modo quando viene effettuata la richiesta di montare un nuovo disco
-(o qualunque altro \textit{block device} che può contenere un filesystem), il
-VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
-nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
+(o qualunque altro \textit{block device} che può contenere un filesystem), il
+VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
+nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
il superblock (vedi sez.~\ref{sec:file_ext2}), inizializzare tutte le variabili
interne e restituire uno speciale descrittore dei filesystem montati al VFS;
attraverso quest'ultimo diventa possibile accedere alle funzioni specifiche per
l'uso di quel filesystem.
-Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
+Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
una apposita struttura che contiene vari dati come le informazioni comuni ad
ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
-puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
+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 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
+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
\index{inode} dell'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.
+sui file già aperti.
\subsection{Il funzionamento del \textit{Virtual File System}}
\label{sec:file_vfs_work}
-La funzione più importante implementata dal VFS è la system call \func{open}
+La funzione più importante implementata dal VFS è la 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}
efficiente il \textit{pathname} a una specifica \textit{dentry}.
Una singola \textit{dentry} contiene in genere il puntatore ad un
-\index{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul
+\index{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
+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 \index{inode} \textit{inode} invece
+vengono usate per motivi di velocità, gli \index{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 \index{inode} inode che stanno in memoria
-sono \index{inode} inode del VFS ed è ad essi che puntano le singole
+sono \index{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
+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 \index{inode} l'inode corrispondente in memoria.
processi in user space possono accedere alle operazioni attraverso detti
metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
(su questo torneremo in dettaglio in sez.~\ref{sec:file_fd}). Un elenco delle
-operazioni previste dal kernel è riportato in
+operazioni previste dal kernel è riportato in
tab.~\ref{tab:file_file_operations}.
\begin{table}[htb]
\textsl{\code{mmap}} & Mappa il file in memoria (vedi
sez.~\ref{sec:file_memory_map}).\\
\textsl{\code{release}}& Chiamata quando l'ultimo riferimento a un file
- aperto è chiuso.\\
+ aperto è chiuso.\\
\textsl{\code{fsync}} & Sincronizza il contenuto del file (vedi
sez.~\ref{sec:file_sync}).\\
\textsl{\code{fasync}} & Abilita l'I/O asincrono (vedi
\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
+(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
+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) è
+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.
\itindend{Virtual~File~System}
\subsection{Il funzionamento di un filesystem Unix}
\label{sec:file_filesystem}
-Come già accennato in sez.~\ref{sec:file_organization} Linux (ed ogni sistema
+Come già accennato in sez.~\ref{sec:file_organization} Linux (ed ogni sistema
unix-like) organizza i dati che tiene su disco attraverso l'uso di un
-filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
-quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
-diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
+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 sistema unix-like.
Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. La strutturazione tipica
-dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys};
+partizione può contenere un filesystem. La strutturazione tipica
+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
superblock (ma sulle caratteristiche di \acr{ext2} e derivati torneremo in
-sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+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
\index{inode} inode e lo spazio a disposizione per i dati e le directory.
\end{figure}
Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
-caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
+caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
visto che sono fondamentali per capire il funzionamento delle funzioni che
manipolano i file e le directory che tratteremo nel prossimo capitolo; in
-particolare è opportuno ricordare sempre che:
+particolare è opportuno ricordare sempre che:
\begin{enumerate}
\item L'\textit{inode} \index{inode} contiene tutte le informazioni (i
cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che
- contengono i dati e così via. Le informazioni che la funzione \func{stat}
- fornisce provengono dall'\textit{inode}; dentro una directory si troverà
+ 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 \index{inode} dell'\textit{inode} ad esso
- associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
+ 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}).
-\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
+\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
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
+ 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 \index{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
+ nello stesso filesystem e non ci può essere una directory che contiene
riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem.
Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
file esistente con la funzione \func{link}) al filesystem corrente.
\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
del file non viene spostato fisicamente, viene semplicemente creata una
nuova voce per \index{inode} l'\textit{inode} in questione e rimossa la
- vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
+ 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.
\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
- in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
- possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per
- gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
+ in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
+ possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per
+ gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
creare nuovi file, ma si potranno estendere quelli che ci sono.
\label{fig:file_dirs_link}
\end{figure}
-La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
-è referenziata dalla directory da cui si era partiti (in cui è inserita la
+La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
+è referenziata dalla directory da cui si era partiti (in cui è inserita la
nuova voce che fa riferimento a \texttt{img}) e dalla voce ``\texttt{.}'' che
-è sempre inserita in ogni directory; questo vale sempre per ogni directory che
+è sempre inserita in ogni directory; questo vale sempre per ogni directory che
non contenga a sua volta altre directory. Al contempo, la directory da cui si
-era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà
+era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà
referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}.
\subsection{I filesystem di uso comune}
\label{sec:file_ext2}
-Il filesystem standard più usato con Linux è il cosiddetto \textit{third
+Il filesystem standard più usato con Linux è il cosiddetto \textit{third
extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa
riferimento al momento della stesura di questo paragrafo, l'inizio del
2010.} Esso nasce come evoluzione del precedente \textit{second extended
filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche
di base, per questo motivo parleremo anzitutto di questo, dato che molto di
-quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
+quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore
evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta
iniziando a sostituirlo gradualmente.
Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle
prime versioni del kernel e supporta tutte le caratteristiche di un filesystem
-standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri,
+standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri,
estensibili a 1012) e supporta una dimensione massima dei file fino a 4~Tb. I
successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di questo
filesystem, e sia pure con molti miglioramenti ed estensioni significative ne
di \acr{sgid} impostato (per una descrizione dettagliata del significato di
questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
-\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
- in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
- permettono un accesso più veloce, ma sprecano più spazio disco).
+\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
+ in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
+ permettono un accesso più veloce, ma sprecano più spazio disco).
\item il filesystem implementa link simbolici veloci, in cui il nome del file
- non è salvato su un blocco, ma tenuto all'interno \index{inode} dell'inode
- (evitando letture multiple e spreco di spazio), non tutti i nomi però
- possono essere gestiti così per limiti di spazio (il limite è 60 caratteri).
+ non è salvato su un blocco, ma tenuto all'interno \index{inode} dell'inode
+ (evitando letture multiple e spreco di spazio), non tutti i nomi però
+ possono essere gestiti così per limiti di spazio (il limite è 60 caratteri).
\item vengono supportati i file immutabili (che possono solo essere letti) per
la protezione di file di configurazione sensibili, o file
\textit{append-only} che possono essere aperti in scrittura solo per
log).
\end{itemize}
-La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
-filesystem è composto da un insieme di blocchi, la struttura generale è quella
-riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
+filesystem è composto da un insieme di blocchi, la struttura generale è quella
+riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
in gruppi di blocchi.\footnote{non si confonda questa definizione con
quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
riferimento alla struttura usata in user space per riportare i dati
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
-una maggiore affidabilità e possibilità di recupero in caso di corruzione del
+una maggiore affidabilità e possibilità di recupero in caso di corruzione del
superblock principale. L'utilizzo di raggruppamenti di blocchi ha inoltre
degli effetti positivi nelle prestazioni dato che viene ridotta la distanza
fra i dati e la tabella degli \index{inode} inode.
list} con voci di dimensione variabile. Ciascuna voce della lista contiene
il numero di inode \index{inode}, la sua lunghezza, il nome del file e la sua
lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo
-è possibile implementare nomi per i file anche molto lunghi (fino a 1024
+è possibile implementare nomi per i file anche molto lunghi (fino a 1024
caratteri) senza sprecare spazio disco.
Con l'introduzione del filesystem \textit{ext3} sono state introdotte anche
-alcune modifiche strutturali, la principale di queste è quella che
-\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire
+alcune modifiche strutturali, la principale di queste è quella che
+\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire
una registrazione delle operazioni di scrittura su un giornale (uno speciale
file interno) in modo da poter garantire il ripristino della coerenza dei dati
-del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
+del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
filesystem, non di dati \textsl{nel} filesystem, quello di cui viene
- garantito un veloce ripristino è relativo ai dati della struttura interna
+ garantito un veloce ripristino è relativo ai dati della struttura interna
del filesystem, non di eventuali dati contenuti nei file che potrebbero
essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa
della corrente o di crollo del sistema che abbia causato una interruzione
della scrittura dei dati sul disco.
Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
-sia le prestazioni che la semplicità di gestione del filesystem, in
-particolare per le directory si è passato all'uso di alberi binari con
+sia le prestazioni che la semplicità di gestione del filesystem, in
+particolare per le directory si è passato all'uso di alberi binari con
indicizzazione tramite hash al posto delle \textit{linked list}, ottenendo un
forte guadagno di prestazioni in caso di directory contenenti un gran numero
di file.
Esamineremo in questo capitolo l'interfaccia standard ANSI C per i file,
quella che viene comunemente detta interfaccia degli \textit{stream}. Dopo
una breve sezione introduttiva tratteremo le funzioni base per la gestione
-dell'input/output, mentre tratteremo le caratteristiche più avanzate
+dell'input/output, mentre tratteremo le caratteristiche più avanzate
dell'interfaccia nell'ultima sezione.
sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
direttamente alle system call messe a disposizione dal kernel.
-Questa interfaccia però non provvede le funzionalità previste dallo standard
+Questa interfaccia però non provvede le funzionalità previste dallo standard
ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
queste, insieme alle altre funzioni definite dallo standard, vengono a
costituire il nucleo\footnote{queste funzioni sono state implementate la prima
\index{file!stream|(}
-Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
+Come più volte ribadito, l'interfaccia dei file descriptor è un'interfaccia di
basso livello, che non provvede nessuna forma di formattazione dei dati e
nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
evidenziando come le prestazioni ottimali si ottengano a partire da dimensioni
del buffer dei dati pari a quelle dei blocchi del filesystem (il valore dato
dal campo \var{st\_blksize} di \struct{stat}), che di norma corrispondono alle
-dimensioni dei settori fisici in cui è suddiviso il disco.
+dimensioni dei settori fisici in cui è suddiviso il disco.
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
+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.
Per questo motivo l'interfaccia viene chiamata anche interfaccia dei
-\textit{file stream}, dato che non è più necessario doversi preoccupare
+\textit{file stream}, dato che non è più necessario doversi preoccupare
dei dettagli della comunicazione con il tipo di hardware sottostante
(come nel caso della dimensione dei blocchi del filesystem), ed un file
-può essere sempre considerato come composto da un flusso continuo (da
+può essere sempre considerato come composto da un flusso continuo (da
cui il nome \textit{stream}) di dati.
A parte i dettagli legati alla gestione delle operazioni di lettura e
\label{sec:file_FILE}
-Per ragioni storiche la struttura di dati che rappresenta uno stream è stata
+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
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
+(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}.
definiti nell'header \file{stdio.h} che sono:
\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\var{FILE *stdin}] Lo \textit{standard input} cioè lo stream da
+\item[\var{FILE *stdin}] Lo \textit{standard input} cioè lo stream da
cui il processo riceve ordinariamente i dati in ingresso. Normalmente
- è associato dalla shell all'input del terminale e prende i caratteri
+ è associato dalla shell all'input del terminale e prende i caratteri
dalla tastiera.
-\item[\var{FILE *stdout}] Lo \textit{standard output} cioè lo stream su
- cui il processo invia ordinariamente i dati in uscita. Normalmente è
+\item[\var{FILE *stdout}] Lo \textit{standard output} cioè lo stream su
+ cui il processo invia ordinariamente i dati in uscita. Normalmente è
associato dalla shell all'output del terminale e scrive sullo schermo.
-\item[\var{FILE *stderr}] Lo \textit{standard error} cioè lo stream su
- cui il processo è supposto inviare i messaggi di errore. Normalmente
- anch'esso è associato dalla shell all'output del terminale e scrive
+\item[\var{FILE *stderr}] Lo \textit{standard error} cioè lo stream su
+ cui il processo è supposto inviare i messaggi di errore. Normalmente
+ anch'esso è associato dalla shell all'output del terminale e scrive
sullo schermo.
\end{basedescript}
Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
tre variabili di tipo \type{FILE}\texttt{ *} che possono essere usate come
-tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
+tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
programma con il semplice codice: \includecodesnip{listati/redir_stdout.c} ma
in altri sistemi queste variabili possono essere definite da macro, e se si
-hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
+hanno problemi di portabilità e si vuole essere sicuri, diventa opportuno
usare la funzione \func{freopen}.
-\subsection{Le modalità di bufferizzazione}
+\subsection{Le modalità di bufferizzazione}
\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
+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
+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
viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine
inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in
maniera asincrona rispetto alla scrittura. Un comportamento analogo avviene
-anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
-sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
+anche in lettura (cioè dal file viene letto un blocco di dati, anche se ne
+sono richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza
inferiore, dato che i dati letti sono sempre gli stessi. In caso di scrittura
invece, quando si ha un accesso contemporaneo allo stesso file (ad esempio da
parte di un altro processo) si potranno vedere solo le parti effettivamente
scritte, e non quelle ancora presenti nel buffer.
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
+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
+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
+modalità in cui può essere eseguita la bufferizzazione, delle quali
occorre essere ben consapevoli, specie in caso di lettura e scrittura da
dispositivi interattivi:
\begin{itemize}
-\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
+\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i
caratteri vengono trasmessi direttamente al file non appena possibile
(effettuando immediatamente una \func{write}).
\item \textit{line buffered}: in questo caso i caratteri vengono
\end{itemize}
Lo standard ANSI C specifica inoltre che lo standard output e lo
-standard input siano aperti in modalità \textit{fully buffered} quando
+standard input siano aperti in modalità \textit{fully buffered} quando
non fanno riferimento ad un dispositivo interattivo, e che lo standard
-error non sia mai aperto in modalità \textit{fully buffered}.
+error non sia mai aperto in modalità \textit{fully buffered}.
Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera
-ancora più precisa, e cioè impone che lo standard error sia sempre
-\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
+ancora più precisa, e cioè impone che lo standard error sia sempre
+\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più
rapidamente possibile) e che standard input e standard output siano aperti in
-modalità \textit{line buffered} quando sono associati ad un terminale (od
-altro dispositivo interattivo) ed in modalità \textit{fully buffered}
+modalità \textit{line buffered} quando sono associati ad un terminale (od
+altro dispositivo interattivo) ed in modalità \textit{fully buffered}
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
+automaticamente, e la libreria apre lo 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à
+La modalità \textit{line buffered} è quella che necessita di maggiori
+chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già
accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel
alla ricezione di un carattere di \textsl{a capo} (\textit{newline}); questo
-non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
-dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
+non è vero in tutti i casi, infatti, dato che le dimensioni del buffer usato
+dalle librerie sono fisse, se le si eccedono si può avere uno scarico dei dati
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
+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
+ legge è in modalità \textit{unbuffered}.} viene anche eseguito lo scarico di
tutti i buffer degli 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
+opportune funzioni per controllare le modalità di bufferizzazione e lo scarico
dei dati.
Le funzioni che si possono usare per aprire uno 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
+ \func{freopen} fanno parte dello standard ANSI C, \func{fdopen} è parte
dello standard POSIX.1.} i loro prototipi sono:
\begin{functions}
\headdecl{stdio.h}
Associa uno 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
- specificato da \param{stream}, se questo è già aperto prima lo chiude.
+ specificato da \param{stream}, se questo è già aperto prima lo chiude.
\bodydesc{Le funzioni ritornano un puntatore valido in caso di successo e
- \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il valore
- ricevuto dalla funzione sottostante di cui è fallita l'esecuzione.
+ \val{NULL} in caso di errore, in tal caso \var{errno} assumerà il valore
+ ricevuto dalla funzione sottostante di cui è fallita l'esecuzione.
Gli errori pertanto possono essere quelli di \func{malloc} per tutte
e tre le funzioni, quelli \func{open} per \func{fopen}, quelli di
\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
+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).
-L'uso più comune di \func{freopen} è per redirigere uno dei tre file
+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 stream già aperto viene
preventivamente chiuso.
Infine \func{fdopen} viene usata per associare uno stream ad un file
\hline
\hline
\texttt{r} & Il file viene aperto, l'accesso viene posto in sola
- lettura, lo stream è posizionato all'inizio del file.\\
+ lettura, lo 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 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 è 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 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
\itindex{append~mode} \textit{append mode}, l'accesso viene
posto in lettura e scrittura.\\
\hline
- \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
- \texttt{x} & L'apertura fallisce se il file esiste già. \\
+ \texttt{b} & Specifica che il file è binario, non ha alcun effetto. \\
+ \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
+ \caption{Modalità di apertura di uno stream dello standard ANSI C che
sono sempre presenti in qualunque sistema POSIX.}
\label{tab:file_fopen_mode}
\end{table}
-In realtà lo standard ANSI C prevede un totale di 15 possibili valori
+In realtà lo standard ANSI C prevede un totale di 15 possibili valori
diversi per \param{mode}, ma in tab.~\ref{tab:file_fopen_mode} si sono
-riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
+riportati solo i sei valori effettivi, ad essi può essere aggiunto pure
il carattere \texttt{b} (come ultimo carattere o nel mezzo agli altri per
le stringhe di due caratteri) che in altri sistemi operativi serve a
distinguere i file binari dai file di testo; in un sistema POSIX questa
distinzione non esiste e il valore viene accettato solo per
-compatibilità, ma non ha alcun effetto.
+compatibilità, ma non ha alcun effetto.
Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
indicate dopo aver specificato il \param{mode} con uno dei valori di
tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
-evitare di sovrascrivere un file già esistente (è analoga all'uso
-dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
+evitare di sovrascrivere un file già esistente (è analoga all'uso
+dell'opzione \const{O\_EXCL} in \func{open}), se il file specificato già
esiste e si aggiunge questo carattere a \param{mode} la \func{fopen}
fallisce.
Un'altra estensione serve a supportare la localizzazione, quando si
aggiunge a \param{mode} una stringa della forma \verb|",ccs=STRING"| il
-valore \verb|STRING| è considerato il nome di una codifica dei caratteri
+valore \verb|STRING| è considerato il nome di una codifica dei caratteri
e \func{fopen} marca il file per l'uso dei caratteri estesi e abilita le
opportune funzioni di conversione in lettura e scrittura.
Nel caso si usi \func{fdopen} i valori specificati da \param{mode} devono
-essere compatibili con quelli con cui il file descriptor è stato aperto.
+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.
+file non viene duplicato e verrà chiuso alla chiusura dello stream.
I nuovi file saranno creati secondo quanto visto in
sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
\val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per
il processo (si veda sez.~\ref{sec:file_perm_management}).
-In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
+In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
richiede che ci sia un'operazione di posizionamento fra un'operazione
di output ed una di input o viceversa (eccetto il caso in cui l'input ha
-incontrato la fine del file), altrimenti una lettura può ritornare anche
+incontrato la fine del file), altrimenti una lettura può ritornare anche
il risultato di scritture precedenti l'ultima effettuata.
-Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
+Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad
una scrittura una delle funzioni \func{fflush}, \func{fseek}, \func{fsetpos} o
\func{rewind} prima di eseguire una rilettura; viceversa nel caso in cui si
voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
usare una delle funzioni \func{fseek}, \func{fsetpos} o \func{rewind}. Anche
-un'operazione nominalmente nulla come \code{fseek(file, 0, SEEK\_CUR)} è
+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
+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.
-Uno stream viene chiuso con la funzione \funcd{fclose} il cui prototipo è:
+Uno stream viene chiuso con la funzione \funcd{fclose} il cui prototipo è:
\begin{prototype}{stdio.h}{int fclose(FILE *stream)}
Chiude lo 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
- indicato da \param{stream} non è valido, o uno dei valori specificati
- dalla sottostante funzione che è fallita (\func{close}, \func{write} o
+ indicato da \param{stream} non è valido, o uno dei valori specificati
+ dalla sottostante funzione che è fallita (\func{close}, \func{write} o
\func{fflush}).}
\end{prototype}
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
+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
+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 è:
+\macro{\_GNU\_SOURCE}, il suo prototipo è:
\begin{prototype}{stdio.h}{int fcloseall(void)}
Chiude tutti gli stream.
\bodydesc{Restituisce 0 se non ci sono errori ed \val{EOF} altrimenti.}
\end{prototype}
\noindent la funzione esegue lo scarico dei dati bufferizzati in uscita
-e scarta quelli in ingresso, chiudendo tutti i file. Questa funzione è
-provvista solo per i casi di emergenza, quando si è verificato un errore
+e scarta quelli in ingresso, chiudendo tutti i file. Questa funzione è
+provvista solo per i casi di emergenza, quando si è verificato un errore
ed il programma deve essere abortito, ma si vuole compiere qualche altra
operazione dopo aver chiuso i file e prima di uscire (si ricordi quanto
visto in sez.~\ref{sec:proc_exit}).
\subsection{Lettura e scrittura su uno stream}
\label{sec:file_io}
-Una delle caratteristiche più utili dell'interfaccia degli stream è la
+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:
+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}.
\item\textsl{di linea} in cui si legge/scrive una linea alla volta (terminata
dal carattere di newline \verb|'\n'|), vedi sez.~\ref{sec:file_line_io}.
\end{enumerate*}
-ed inoltre la modalità di input/output formattato.
+ed inoltre la modalità di input/output formattato.
A differenza dell'interfaccia dei file descriptor, con gli stream il
-raggiungimento della fine del file è considerato un errore, e viene
+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
intero (di tipo \ctyp{int}) \val{EOF}\footnote{la costante deve essere
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
+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
valore di ritorno della funzione e controllare il valore di \var{errno}
infatti non basta, dato che quest'ultimo potrebbe essere stato impostato in
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 è
+\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
i relativi flag sono impostati.}
\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
+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.
Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando
-la funzione \funcd{clearerr}, il cui prototipo è:
+la funzione \funcd{clearerr}, il cui prototipo è:
\begin{prototype}{stdio.h}{void clearerr(FILE *stream)}
Cancella i flag di errore ed end-of-file di \param{stream}.
\end{prototype}
\noindent in genere si usa questa funzione una volta che si sia identificata e
-corretta la causa di un errore per evitare di mantenere i flag attivi, così da
+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}).
\subsection{Input/output binario}
\label{sec:file_binary_io}
-La prima modalità di input/output non formattato ricalca quella della
+La prima modalità di input/output non formattato ricalca quella della
interfaccia dei file descriptor, e provvede semplicemente la scrittura e la
-lettura dei dati da un buffer verso un file e viceversa. In generale questa è
-la modalità che si usa quando si ha a che fare con dati non formattati. Le due
+lettura dei dati da un buffer verso un file e viceversa. In generale questa è
+la modalità che si usa quando si ha a che fare con dati non formattati. Le due
funzioni che si usano per l'I/O binario sono \funcd{fread} ed \funcd{fwrite};
i loro prototipi sono:
\begin{functions}
In genere si usano queste funzioni quando si devono trasferire su file
blocchi di dati binari in maniera compatta e veloce; un primo caso di uso
-tipico è quello in cui si salva un vettore (o un certo numero dei suoi
+tipico è quello in cui si salva un vettore (o un certo numero dei suoi
elementi) con una chiamata del tipo:
\includecodesnip{listati/WriteVect.c}
in questo caso devono essere specificate le dimensioni di ciascun
elemento ed il numero di quelli che si vogliono scrivere. Un secondo
-caso è invece quello in cui si vuole trasferire su file una struttura;
-si avrà allora una chiamata tipo:
+caso è invece quello in cui si vuole trasferire su file una struttura;
+si avrà allora una chiamata tipo:
\includecodesnip{listati/WriteStruct.c}
in cui si specifica la dimensione dell'intera struttura ed un solo
elemento.
-In realtà quello che conta nel trasferimento dei dati sono le dimensioni
+In realtà quello che conta nel trasferimento dei dati sono le dimensioni
totali, che sono sempre pari al prodotto \code{size * nelem}; la sola
-differenza è che le funzioni non ritornano il numero di byte scritti,
+differenza è che le funzioni non ritornano il numero di byte scritti,
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).
+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
-scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
+scritti, che sarà inferiore a quello richiesto. Contrariamente a quanto
avviene per i file descriptor, questo segnala una condizione di errore e
-occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
+occorrerà usare \func{feof} e \func{ferror} per stabilire la natura del
problema.
-Benché queste funzioni assicurino la massima efficienza per il
+Benché queste funzioni assicurino la massima efficienza per il
salvataggio dei dati, i dati memorizzati attraverso di esse presentano
lo svantaggio di dipendere strettamente dalla piattaforma di sviluppo
usata ed in genere possono essere riletti senza problemi solo dallo
Infatti diversi compilatori possono eseguire ottimizzazioni diverse delle
strutture dati e alcuni compilatori (come il \cmd{gcc}) possono anche
-scegliere se ottimizzare l'occupazione di spazio, impacchettando più
-strettamente i dati, o la velocità inserendo opportuni \textit{padding} per
+scegliere se ottimizzare l'occupazione di spazio, impacchettando più
+strettamente i dati, o la velocità inserendo opportuni \textit{padding} per
l'allineamento dei medesimi generando quindi output binari diversi. Inoltre
-altre incompatibilità si possono presentare quando entrano in gioco differenze
-di architettura hardware, come la dimensione del bus o la modalità di
+altre incompatibilità si possono presentare quando entrano in gioco differenze
+di architettura hardware, come la dimensione del bus o la modalità di
ordinamento dei bit o il formato delle variabili in floating point.
Per questo motivo quando si usa l'input/output binario occorre sempre prendere
-le opportune precauzioni (in genere usare un formato di più alto livello che
+le opportune precauzioni (in genere usare un formato di più alto livello che
permetta di recuperare l'informazione completa), per assicurarsi che versioni
diverse del programma siano in grado di rileggere i dati tenendo conto delle
eventuali differenze.
\subsection{Input/output a caratteri}
\label{sec:file_char_io}
-La seconda modalità di input/output è quella a caratteri, in cui si
+La seconda modalità di input/output è quella a caratteri, in cui si
trasferisce un carattere alla volta. Le funzioni per la lettura a
caratteri sono tre, \funcd{fgetc}, \funcd{getc} e \funcd{getchar}, i
rispettivi prototipi sono:
\headdecl{stdio.h}
\funcdecl{int getc(FILE *stream)} Legge un byte da \param{stream} e lo
- restituisce come intero. In genere è implementata come una macro.
+ restituisce come intero. In genere è implementata come una macro.
\funcdecl{int fgetc(FILE *stream)} Legge un byte da \param{stream} e lo
- restituisce come intero. È sempre una funzione.
+ restituisce come intero. È sempre una funzione.
\funcdecl{int getchar(void)} Equivalente a \code{getc(stdin)}.
\bodydesc{Tutte queste funzioni leggono un byte alla volta, che viene
restituito come intero; in caso di errore o fine del file il valore
- di ritorno è \val{EOF}.}
+ di ritorno è \val{EOF}.}
\end{functions}
A parte \func{getchar}, che si usa in genere per leggere un carattere da
tastiera, le altre due funzioni sono sostanzialmente equivalenti. La
-differenza è che \func{getc} è ottimizzata al massimo e normalmente
+differenza è che \func{getc} è ottimizzata al massimo e normalmente
viene implementata con una macro, per cui occorre stare attenti a cosa
-le si passa come argomento, infatti \param{stream} può essere valutato
-più volte nell'esecuzione, e non viene passato in copia con il
+le si passa come argomento, infatti \param{stream} può essere valutato
+più volte nell'esecuzione, e non viene passato in copia con il
meccanismo visto in sez.~\ref{sec:proc_var_passing}; per questo motivo se
si passa un'espressione si possono avere effetti indesiderati.
-Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
-la sua esecuzione normalmente è più lenta per via dell'overhead della
-chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
+Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
+la sua esecuzione normalmente è più lenta per via dell'overhead della
+chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
come argomento ad un altra funzione (e non si hanno i problemi accennati in
precedenza nel tipo di argomento).
Le tre funzioni restituiscono tutte un \ctyp{unsigned char} convertito
ad \ctyp{int} (si usa \ctyp{unsigned char} in modo da evitare
-l'espansione del segno). In questo modo il valore di ritorno è sempre
+l'espansione del segno). In questo modo il valore di ritorno è sempre
positivo, tranne in caso di errore o fine del file.
Nelle estensioni GNU che provvedono la localizzazione sono definite tre
funzioni equivalenti alle precedenti, \funcd{getwc}, \funcd{fgetwc} e
\funcd{getwchar}, che invece di un carattere di un byte restituiscono un
-carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
-è:
+carattere in formato esteso (cioè di tipo \ctyp{wint\_t}), il loro prototipo
+è:
\begin{functions}
\headdecl{stdio.h}
\headdecl{wchar.h}
\funcdecl{wint\_t getwc(FILE *stream)} Legge un carattere esteso da
- \param{stream}. In genere è implementata come una macro.
+ \param{stream}. In genere è implementata come una macro.
\funcdecl{wint\_t fgetwc(FILE *stream)} Legge un carattere esteso da
- \param{stream}. È una sempre una funzione.
+ \param{stream}. È una sempre una funzione.
\funcdecl{wint\_t getwchar(void)} Equivalente a \code{getwc(stdin)}.
\bodydesc{Tutte queste funzioni leggono un carattere alla volta, in
- caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
+ caso di errore o fine del file il valore di ritorno è \const{WEOF}.}
\end{functions}
Per scrivere un carattere si possono usare tre funzioni, analoghe alle
\headdecl{stdio.h}
\funcdecl{int putc(int c, FILE *stream)} Scrive il carattere \param{c}
- su \param{stream}. In genere è implementata come una macro.
+ su \param{stream}. In genere è implementata come una macro.
\funcdecl{int fputc(int c, FILE *stream)} Scrive il carattere \param{c} su
- \param{stream}. È una sempre una funzione.
+ \param{stream}. È una sempre una funzione.
\funcdecl{int putchar(int c)} Equivalente a \code{putc(stdout)}.
\bodydesc{Le funzioni scrivono sempre un carattere alla volta, il cui
valore viene restituito in caso di successo; in caso di errore o
- fine del file il valore di ritorno è \val{EOF}.}
+ fine del file il valore di ritorno è \val{EOF}.}
\end{functions}
Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono
come argomento un \ctyp{int} (che pertanto deve essere ottenuto con un cast da
-un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
-caso di errore o fine del file il valore di ritorno è \val{EOF}.
+un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
+caso di errore o fine del file il valore di ritorno è \val{EOF}.
Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \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ò
+un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
+\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
il lock implicito dello stream.
-Per compatibilità con SVID sono inoltre provviste anche due funzioni,
+Per compatibilità con SVID sono inoltre provviste anche due funzioni,
\funcd{getw} e \funcd{putw}, da usare per leggere e scrivere una \textit{word}
-(cioè due byte in una volta); i loro prototipi sono:
+(cioè due byte in una volta); i loro prototipi sono:
\begin{functions}
\headdecl{stdio.h}
\end{functions}
Le funzioni leggono e scrivono una \textit{word} di due byte, usando comunque
-una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
-di \func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
+una variabile di tipo \ctyp{int}; il loro uso è deprecato in favore dell'uso
+di \func{fread} e \func{fwrite}, in quanto non è possibile distinguere il
valore -1 da una condizione di errore che restituisce \val{EOF}.
-Uno degli usi più frequenti dell'input/output a caratteri è nei programmi di
+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
-effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
+effettivamente (la tecnica è detta \textit{peeking ahead}) in modo che il
programma possa regolarsi avendo dato una \textsl{sbirciatina} a quello che
viene dopo.
-Nel nostro caso questo tipo di comportamento può essere realizzato prima
-leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
+Nel nostro caso questo tipo di comportamento può essere realizzato prima
+leggendo il carattere, e poi rimandandolo indietro, cosicché ridiventi
disponibile per una lettura successiva; la funzione che inverte la
-lettura si chiama \funcd{ungetc} ed il suo prototipo è:
+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}.
\bodydesc{La funzione ritorna \param{c} in caso di successo e
\val{EOF} in caso di errore.}
\end{prototype}
-\noindent benché lo standard ANSI C preveda che l'operazione possa
+\noindent benché lo standard ANSI C preveda che l'operazione possa
essere ripetuta per un numero arbitrario di caratteri, alle
-implementazioni è richiesto di garantire solo un livello; questo è
+implementazioni è richiesto di garantire solo un livello; questo è
quello che fa la \acr{glibc}, che richiede che avvenga un'altra
operazione fra due \func{ungetc} successive.
-Non è necessario che il carattere che si manda indietro sia l'ultimo che
-si è letto, e non è necessario neanche avere letto nessun carattere
-prima di usare \func{ungetc}, ma di norma la funzione è intesa per
+Non è necessario che il carattere che si manda indietro sia l'ultimo che
+si è letto, e non è necessario neanche avere letto nessun carattere
+prima di usare \func{ungetc}, ma di norma la funzione è intesa per
essere usata per rimandare indietro l'ultimo carattere letto.
Nel caso \param{c} sia un \val{EOF} la funzione non fa nulla, e
-restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
+restituisce sempre \val{EOF}; così si può usare \func{ungetc} anche
con il risultato di una lettura alla fine del file.
-Se si è alla fine del file si può comunque rimandare indietro un
-carattere, il flag di end-of-file verrà automaticamente cancellato
-perché c'è un nuovo carattere disponibile che potrà essere riletto
+Se si è alla fine del file si può comunque rimandare indietro un
+carattere, il flag di end-of-file verrà automaticamente cancellato
+perché c'è un nuovo carattere disponibile che potrà essere riletto
successivamente.
Infine si tenga presente che \func{ungetc} non altera il contenuto del
\subsection{Input/output di linea}
\label{sec:file_line_io}
-La terza ed ultima modalità di input/output non formattato è quella di linea,
-in cui si legge o si scrive una riga alla volta; questa è una modalità molto
-usata per l'I/O da terminale, ma è anche quella che presenta le
-caratteristiche più controverse.
+La terza ed ultima modalità di input/output non formattato è quella di linea,
+in cui si legge o si scrive una riga alla volta; questa è una modalità molto
+usata per l'I/O da terminale, ma è anche quella che presenta le
+caratteristiche più controverse.
Le funzioni previste dallo standard ANSI C per leggere una linea sono
sostanzialmente due, \funcd{gets} e \funcd{fgets}, i cui rispettivi
carattere \textit{newline}, \verb|'\n'|, quello mappato sul tasto di ritorno a
capo della tastiera), ma \func{gets} sostituisce \verb|'\n'| con uno zero,
mentre \func{fgets} aggiunge uno zero dopo il \textit{newline}, che resta
-dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
+dentro la stringa. Se la lettura incontra la fine del file (o c'è un errore)
viene restituito un \val{NULL}, ed il buffer \param{buf} non viene toccato.
-L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
+L'uso di \func{gets} è deprecato e deve essere assolutamente evitato; la
funzione infatti non controlla il numero di byte letti, per cui nel caso la
-stringa letta superi le dimensioni del buffer, si avrà un
+stringa letta superi le dimensioni del buffer, si avrà un
\itindex{buffer~overflow} \textit{buffer overflow}, con sovrascrittura della
-memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
+memoria del processo adiacente al buffer.\footnote{questa tecnica è spiegata
in dettaglio e con molta efficacia nell'ormai famoso articolo di Aleph1
\cite{StS}.}
-Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
+Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non
autorizzati al sistema (i cosiddetti \textit{exploit}), basta infatti inviare
una stringa sufficientemente lunga ed opportunamente forgiata per
sovrascrivere gli indirizzi di ritorno nello \itindex{stack} \textit{stack}
(supposto che la \func{gets} sia stata chiamata da una subroutine), in modo da
far ripartire l'esecuzione nel codice inviato nella stringa stessa (in genere
-uno \textit{shell code} cioè una sezione di programma che lancia una shell).
+uno \textit{shell code} cioè una sezione di programma che lancia una shell).
La funzione \func{fgets} non ha i precedenti problemi di \func{gets} in quanto
-prende in input la dimensione del buffer \param{size}, che non verrà mai
+prende in input la dimensione del buffer \param{size}, che non verrà mai
ecceduta in lettura. La funzione legge fino ad un massimo di \param{size}
caratteri (newline compreso), ed aggiunge uno zero di terminazione; questo
comporta che la stringa possa essere al massimo di \code{size-1} caratteri. Se
la linea eccede la dimensione del buffer verranno letti solo \code{size-1}
-caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
-finale; sarà possibile leggere i rimanenti caratteri in una chiamata
+caratteri, ma la stringa sarà sempre terminata correttamente con uno zero
+finale; sarà possibile leggere i rimanenti caratteri in una chiamata
successiva.
Per la scrittura di una linea lo standard ANSI C prevede altre due
\end{functions}
Dato che in questo caso si scrivono i dati in uscita \func{puts} non ha i
-problemi di \func{gets} ed è in genere la forma più immediata per scrivere
+problemi di \func{gets} ed è in genere la forma più immediata per scrivere
messaggi sullo standard output; la funzione prende una stringa terminata da
uno zero ed aggiunge automaticamente il ritorno a capo. La differenza con
-\func{fputs} (a parte la possibilità di specificare un file diverso da
-\var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
+\func{fputs} (a parte la possibilità di specificare un file diverso da
+\var{stdout}) è che quest'ultima non aggiunge il newline, che deve essere
previsto esplicitamente.
Come per le analoghe funzioni di input/output a caratteri, anche per l'I/O di
caso di errore o fine del file.}
\end{functions}
-Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
+Il comportamento di queste due funzioni è identico a quello di \func{fgets} e
\func{fputs}, a parte il fatto che tutto (numero di caratteri massimo,
-terminatore della stringa, newline) è espresso in termini di caratteri estesi
-anziché di normali caratteri ASCII.
+terminatore della stringa, newline) è espresso in termini di caratteri estesi
+anziché di normali caratteri ASCII.
Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
\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
+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}.
Come abbiamo visto, le funzioni di lettura per l'input/output di linea
-previste dallo standard ANSI C presentano svariati inconvenienti. Benché
-\func{fgets} non abbia i gravissimi problemi di \func{gets}, può
+previste dallo standard ANSI C presentano svariati inconvenienti. Benché
+\func{fgets} non abbia i gravissimi problemi di \func{gets}, può
comunque dare risultati ambigui se l'input contiene degli zeri; questi
infatti saranno scritti sul buffer di uscita e la stringa in output
-apparirà come più corta dei byte effettivamente letti. Questa è una
-condizione che è sempre possibile controllare (deve essere presente un
+apparirà come più corta dei byte effettivamente letti. Questa è una
+condizione che è sempre possibile controllare (deve essere presente un
newline prima della effettiva conclusione della stringa presente nel
buffer), ma a costo di una complicazione ulteriore della logica del
programma. Lo stesso dicasi quando si deve gestire il caso di stringa
risolvere questi problemi. L'uso di queste funzioni deve essere attivato
definendo la macro \macro{\_GNU\_SOURCE} prima di includere \file{stdio.h}. La
prima delle due, \funcd{getline}, serve per leggere una linea terminata da un
-newline, esattamente allo stesso modo di \func{fgets}, il suo prototipo è:
+newline, esattamente allo stesso modo di \func{fgets}, il suo prototipo è:
\begin{prototype}{stdio.h}
{ssize\_t getline(char **buffer, size\_t *n, FILE *stream)} Legge una linea
dal file \param{stream} copiandola sul buffer indicato da \param{buffer}
eventuale lunghezza eccessiva della stringa da leggere. Essa prende come primo
argomento l'indirizzo del puntatore al buffer su cui si vuole copiare la
linea. Quest'ultimo \emph{deve} essere stato allocato in precedenza con una
-\func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
+\func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
locale); come secondo argomento la funzione vuole l'indirizzo della variabile
contenente le dimensioni del buffer suddetto.
-Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
+Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
dimensione ed il nuovo puntatore vengono restituiti indietro (si noti infatti
come per entrambi gli argomenti si siano usati dei
\itindex{value~result~argument} \textit{value result argument}, passando dei
-puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
+puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
sez.~\ref{sec:proc_var_passing}).
Se si passa alla funzione l'indirizzo di un puntatore impostato a \val{NULL} e
-\var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
+\var{*n} è zero, la funzione provvede da sola all'allocazione della memoria
necessaria a contenere la linea. In tutti i casi si ottiene dalla funzione un
-puntatore all'inizio del testo della linea letta. Un esempio di codice può
+puntatore all'inizio del testo della linea letta. Un esempio di codice può
essere il seguente:
\includecodesnip{listati/getline.c}
e per evitare \itindex{memory~leak} \textit{memory leak} occorre ricordarsi di
dallo 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.
-Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
+Se si è alla fine del file e non si è potuto leggere nulla o c'è stato
un errore la funzione restituisce -1.
-La seconda estensione GNU è una generalizzazione di \func{getline} per
+La seconda estensione GNU è una generalizzazione di \func{getline} per
poter usare come separatore un carattere qualsiasi, la funzione si
-chiama \funcd{getdelim} ed il suo prototipo è:
+chiama \funcd{getdelim} ed il suo prototipo è:
\begin{prototype}{stdio.h}
{ssize\_t getdelim(char **buffer, size\_t *n, int delim, FILE *stream)}
Identica a \func{getline} solo che usa \param{delim} al posto del
carattere di newline come separatore di linea.
\end{prototype}
-Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
-può essere implementata da questa passando \verb|'\n'| come valore di
+Il comportamento di \func{getdelim} è identico a quello di \func{getline} (che
+può essere implementata da questa passando \verb|'\n'| come valore di
\param{delim}).
\subsection{L'input/output formattato}
\label{sec:file_formatted_io}
-L'ultima modalità di input/output è quella formattata, che è una delle
-caratteristiche più utilizzate delle librerie standard del C; in genere questa
-è la modalità in cui si esegue normalmente l'output su terminale poiché
+L'ultima modalità di input/output è quella formattata, che è una delle
+caratteristiche più utilizzate delle librerie standard del C; in genere questa
+è la modalità in cui si esegue normalmente l'output su terminale poiché
permette di stampare in maniera facile e veloce dati, tabelle e messaggi.
L'output formattato viene eseguito con una delle 13 funzioni della famiglia
-\func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
+\func{printf}; le tre più usate sono \funcd{printf}, \funcd{fprintf} e
\funcd{sprintf}, i cui prototipi sono:
\begin{functions}
\headdecl{stdio.h}
\end{functions}
\noindent le prime due servono per stampare su file (lo standard output o
quello specificato) la terza permette di stampare su una stringa, in genere
-l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
+l'uso di \func{sprintf} è sconsigliato in quanto è possibile, se non si ha la
sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere le
dimensioni di \param{str}, con conseguente sovrascrittura di altre variabili e
possibili \itindex{buffer~overflow} \textit{buffer overflow}; per questo
motivo si consiglia l'uso dell'alternativa \funcd{snprintf}, il cui prototipo
-è:
+è:
\begin{prototype}{stdio.h}
{snprintf(char *str, size\_t size, const char *format, ...)}
- Identica a \func{sprintf}, ma non scrive su \param{str} più di
+ Identica a \func{sprintf}, ma non scrive su \param{str} più di
\param{size} caratteri.
\end{prototype}
-La parte più complessa delle funzioni di scrittura formattata è il formato
+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 è specificato in \param{format}).
\begin{table}[htb]
\centering
lettere minuscole e maiuscole.\\
\cmd{\%g},
\cmd{\%G} &\ctyp{double} & Stampano un numero in virgola mobile con la
- notazione più appropriate delle due precedenti,
+ notazione più appropriate delle due precedenti,
rispettivamente con lettere minuscole e
maiuscole.\\
\cmd{\%a},
\label{tab:file_format_spec}
\end{table}
-La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
+La stringa è costituita da caratteri normali (tutti eccetto \texttt{\%}), che
vengono passati invariati all'output, e da direttive di conversione, in cui
devono essere sempre presenti il carattere \texttt{\%}, che introduce la
direttiva, ed uno degli specificatori di conversione (riportati in
\hline
\hline
\val{\#} & Chiede la conversione in forma alternativa. \\
- \val{0} & La conversione è riempita con zeri alla sinistra del valore.\\
+ \val{0} & La conversione è riempita con zeri alla sinistra del valore.\\
\val{-} & La conversione viene allineata a sinistra sul bordo del campo.\\
\val{' '}& Mette uno spazio prima di un numero con segno di valore
positivo.\\
Il formato di una direttiva di conversione prevede una serie di possibili
elementi opzionali oltre al \cmd{\%} e allo specificatore di conversione. In
-generale essa è sempre del tipo:
+generale essa è sempre del tipo:
\begin{center}
\begin{verbatim}
% [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione
\end{center}
in cui tutti i valori tranne il \val{\%} e lo specificatore di conversione
sono opzionali (e per questo sono indicati fra parentesi quadre); si possono
-usare più elementi opzionali, nel qual caso devono essere specificati in
+usare più elementi opzionali, nel qual caso devono essere specificati in
questo ordine:
\begin{itemize*}
\item uno specificatore del parametro da usare (terminato da un \val{\$}),
-\item uno o più flag (i cui valori possibili sono riassunti in
+\item uno o più flag (i cui valori possibili sono riassunti in
tab.~\ref{tab:file_format_flag}) che controllano il formato di stampa della
conversione,
\item uno specificatore di larghezza (un numero decimale), eventualmente
\hline
\hline
\cmd{hh} & Una conversione intera corrisponde a un \ctyp{char} con o senza
- segno, o il puntatore per il numero dei parametri \cmd{n} è di
+ segno, o il puntatore per il numero dei parametri \cmd{n} è di
tipo \ctyp{char}.\\
\cmd{h} & Una conversione intera corrisponde a uno \ctyp{short} con o
senza segno, o il puntatore per il numero dei parametri \cmd{n}
- è di tipo \ctyp{short}.\\
+ è di tipo \ctyp{short}.\\
\cmd{l} & Una conversione intera corrisponde a un \ctyp{long} con o
senza segno, o il puntatore per il numero dei parametri \cmd{n}
- è di tipo \ctyp{long}, o il carattere o la stringa seguenti
+ è di tipo \ctyp{long}, o il carattere o la stringa seguenti
sono in formato esteso.\\
\cmd{ll} & Una conversione intera corrisponde a un \ctyp{long long} con o
senza segno, o il puntatore per il numero dei parametri \cmd{n}
- è di tipo \ctyp{long long}.\\
+ è di tipo \ctyp{long long}.\\
\cmd{L} & Una conversione in virgola mobile corrisponde a un
\ctyp{double}.\\
\cmd{q} & Sinonimo di \cmd{ll}.\\
\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
+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).
+\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
+\code{va\_end(ap)} ma in Linux questo non è necessario).
Come per \func{sprintf} anche per \func{vsprintf} esiste una analoga
\funcd{vsnprintf} che pone un limite sul numero di caratteri che vengono
scritti sulla stringa di destinazione:
\begin{prototype}{stdio.h}
{vsnprintf(char *str, size\_t size, const char *format, va\_list ap)}
- Identica a \func{vsprintf}, ma non scrive su \param{str} più di
+ Identica a \func{vsprintf}, ma non scrive su \param{str} più di
\param{size} caratteri.
\end{prototype}
\noindent in modo da evitare possibili \itindex{buffer~overflow} buffer
\end{functions}
Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
-l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
+l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
proposito dei \itindex{value~result~argument} \textit{value result argument})
l'indirizzo della stringa allocata automaticamente dalle funzioni. Occorre
inoltre ricordarsi di invocare \func{free} per liberare detto puntatore quando
-la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
+la stringa non serve più, onde evitare \itindex{memory~leak} \textit{memory
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}
+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
-famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
+famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf},
\funcd{fscanf} e \funcd{sscanf}, i cui prototipi sono:
\begin{functions}
\headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una
\bodydesc{Le funzioni ritornano il numero di elementi assegnati. Questi
possono essere in numero inferiore a quelli specificati, ed anche zero.
- Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
+ Quest'ultimo valore significa che non si è trovata corrispondenza. In caso
di errore o fine del file viene invece restituito \val{EOF}.}
\end{functions}
\noindent e come per le analoghe funzioni di scrittura esistono le relative
lista di argomenti.
Tutte le funzioni della famiglia delle \func{scanf} vogliono come argomenti i
-puntatori alle variabili che dovranno contenere le conversioni; questo è un
-primo elemento di disagio in quanto è molto facile dimenticarsi di questa
+puntatori alle variabili che dovranno contenere le conversioni; questo è un
+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
+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
interrotta immediatamente e la funzione ritorna lasciando posizionato lo
stream al primo carattere che non corrisponde.
-Data la notevole complessità di uso di queste funzioni, che richiedono molta
+Data la notevole complessità di uso di queste funzioni, che richiedono molta
cura nella definizione delle corrette stringhe di formato e sono facilmente
-soggette ad errori, e considerato anche il fatto che è estremamente macchinoso
+soggette ad errori, e considerato anche il fatto che è estremamente macchinoso
recuperare in caso di fallimento nelle corrispondenze, l'input formattato non
-è molto usato. In genere infatti quando si ha a che fare con un input
+è molto usato. In genere infatti quando si ha a che fare con un input
relativamente semplice si preferisce usare l'input di linea ed effettuare
scansione e conversione di quanto serve direttamente con una delle funzioni di
-conversione delle stringhe; se invece il formato è più complesso diventa più
+conversione delle stringhe; se invece il formato è più complesso diventa più
facile utilizzare uno strumento come \cmd{flex}\footnote{il programma
- \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
- analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
+ \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di
+ analizzatori lessicali. Per i dettagli si può fare riferimento al manuale
\cite{flex}.} per generare un analizzatore lessicale o il
-\cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
+\cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di
parser \cmd{yacc}, maggiori dettagli possono essere trovati nel relativo
manuale \cite{bison}.} per generare un parser.
\subsection{Posizionamento su uno stream}
\label{sec:file_fseek}
-Come per i file descriptor anche per gli stream è possibile spostarsi
+Come per i file descriptor anche per gli 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
+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
- \index{file!di~dispositivo} file di dispositivo, non è scontato che questo
+ \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 è
+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
+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
+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
+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
all'inizio del file.
\end{functions}
-L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
+L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
descriptor, e gli argomenti, a parte il tipo, hanno lo stesso significato; in
-particolare \param{whence} assume gli stessi valori già visti in
+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
flag di errore e fine del file.
Per ottenere la posizione corrente si usa invece la funzione \funcd{ftell}, il
-cui prototipo è:
+cui prototipo è:
\begin{prototype}{stdio.h}{long ftell(FILE *stream)}
Legge la posizione attuale nello 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
- supporta il riposizionamento che al fatto che la posizione non può
+ di fallimento, che può esser dovuto sia al fatto che il file non
+ supporta il riposizionamento che al fatto che la posizione non può
essere espressa con un \ctyp{long int}}
\end{prototype}
\noindent la funzione restituisce la posizione come numero di byte
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
-può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
+può non essere possibile lo standard POSIX ha introdotto le nuove funzioni
\funcd{fgetpos} e \funcd{fsetpos}, che invece usano il nuovo tipo
\type{fpos\_t}, ed i cui prototipi sono:
\begin{functions}
In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni
\func{fseeko} e \func{ftello}, che sono assolutamente identiche alle
precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo
-\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
+\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{long} è nella
gran parte dei casi un intero a 32 bit, questo diventa un problema quando la
posizione sul file viene espressa con un valore a 64 bit come accade nei
-sistemi più moderni.
+sistemi più moderni.
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
+controllarne le modalità di bufferizzazione, gestire direttamente i lock
impliciti per la programmazione \itindex{thread} \textit{multi-thread}.
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
-descriptor, si può usare la funzione \funcd{fileno} per ottenere quest'ultimo,
-il prototipo della funzione è:
+attributi dei file. Però, dato che ogni 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}.
\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
+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ò
+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
+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:
\begin{functions}
\headdecl{stdio\_ext.h}
\end{functions}
\noindent che permettono di ottenere questa informazione.
-La conoscenza dell'ultima operazione effettuata su uno stream aperto è utile
+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}
-servono a tale scopo, il loro prototipo è:
+servono a tale scopo, il loro prototipo è:
\begin{functions}
\headdecl{stdio\_ext.h}
\funcdecl{int \_\_freading(FILE *stream)}
- Restituisce un valore diverso da zero se \param{stream} è aperto in sola
- lettura o se l'ultima operazione è stata di lettura.
+ Restituisce un valore diverso da zero se \param{stream} è aperto in sola
+ lettura o se l'ultima operazione è stata di lettura.
\funcdecl{int \_\_fwriting(FILE *stream)}
- Restituisce un valore diverso da zero se \param{stream} è aperto in sola
- scrittura o se l'ultima operazione è stata di scrittura.
+ Restituisce un valore diverso da zero se \param{stream} è aperto in sola
+ scrittura o se l'ultima operazione è stata di scrittura.
\end{functions}
-Le due funzioni permettono di determinare di che tipo è stata l'ultima
+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
+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.
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
+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
-operazioni su di esso) è possibile intervenire sulle modalità di buffering; la
-funzione che permette di controllare la bufferizzazione è \funcd{setvbuf}, il
-suo prototipo è:
+Però una volta che si sia aperto lo 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à
+ Imposta la bufferizzazione dello stream \param{stream} nella modalità
indicata da \param{mode}, usando \param{buf} come buffer di lunghezza
\param{size}.
\end{prototype}
La funzione permette di controllare tutti gli aspetti della bufferizzazione;
-l'utente può specificare un buffer da usare al posto di quello allocato dal
+l'utente può specificare un buffer da usare al posto di quello allocato dal
sistema passandone alla funzione l'indirizzo in \param{buf} e la dimensione in
\param{size}.
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
-funzione, può anche essere usata una variabile automatica. In \file{stdio.h} è
+chiusura del file; ma fintanto che il file è usato all'interno di una
+funzione, può anche essere usata una 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).
+è 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
+Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
(come delle scritture accidentali sul buffer) e non assicura la scelta delle
-dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
+dimensioni ottimali, è sempre meglio lasciare allocare il buffer alle funzioni
di libreria, che sono in grado di farlo in maniera ottimale e trasparente
all'utente (in quanto la deallocazione avviene automaticamente). Inoltre
siccome alcune implementazioni usano parte del buffer per mantenere delle
-informazioni di controllo, non è detto che le dimensioni dello stesso
+informazioni di controllo, non è detto che le dimensioni dello stesso
coincidano con quelle su cui viene effettuato l'I/O.
\begin{table}[htb]
\footnotesize
\begin{tabular}[c]{|l|l|}
\hline
- \textbf{Valore} & \textbf{Modalità} \\
+ \textbf{Valore} & \textbf{Modalità} \\
\hline
\hline
\const{\_IONBF} & \textit{unbuffered}\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{mode} di \func{setvbuf}
- per l'impostazione delle modalità di bufferizzazione.}
+ per l'impostazione delle modalità di bufferizzazione.}
\label{tab:file_stream_buf_mode}
\end{table}
Per evitare che \func{setvbuf} imposti il buffer basta passare un valore
-\val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
-usando il buffer allocato automaticamente dal sistema. Si potrà comunque
-modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
+\val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
+usando il buffer allocato automaticamente dal sistema. Si potrà comunque
+modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
opportuni valori elencati in tab.~\ref{tab:file_stream_buf_mode}. Qualora si
-specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
+specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
vengono sempre ignorati.
Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
\headdecl{stdio.h}
\funcdecl{void setbuf(FILE *stream, char *buf)} Disabilita la
- bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
- come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
+ bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
+ come buffer di dimensione \const{BUFSIZ} in modalità \textit{fully buffered}.
\funcdecl{void setbuffer(FILE *stream, char *buf, size\_t size)} Disabilita
- la bufferizzazione se \param{buf} è \val{NULL}, altrimenti usa \param{buf}
- come buffer di dimensione \param{size} in modalità \textit{fully buffered}.
+ 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 stream in modalità
\textit{line buffered}.
\end{functions}
\noindent tutte queste funzioni sono realizzate con opportune chiamate a
-\func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
+\func{setvbuf} e sono definite solo per compatibilità con le vecchie librerie
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
+\funcd{\_\_fbufsize} che permettono di leggere le proprietà di bufferizzazione
di uno stream; i cui prototipi sono:
\begin{functions}
\headdecl{stdio\_ext.h}
\funcdecl{int \_\_flbf(FILE *stream)} Restituisce un valore diverso da zero
- se \param{stream} è in modalità \textit{line buffered}.
+ se \param{stream} è in modalità \textit{line buffered}.
\funcdecl{size\_t \_\_fbufsize(FILE *stream)} Restituisce le dimensioni del
buffer di \param{stream}.
\end{functions}
-Come già accennato, indipendentemente dalla modalità di bufferizzazione
-scelta, si può forzare lo scarico dei dati sul file con la funzione
-\funcd{fflush}, il suo prototipo è:
+Come già accennato, indipendentemente dalla modalità di bufferizzazione
+scelta, si può forzare lo scarico dei dati sul file con la funzione
+\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}.
\bodydesc{Restituisce zero in caso di successo, ed \val{EOF} in caso di
- errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
- aperto o non è aperto in scrittura, o ad uno degli errori di
+ errore, impostando \var{errno} a \errval{EBADF} se \param{stream} non è
+ aperto o non è aperto in scrittura, o ad uno degli errori di
\func{write}.}
\end{prototype}
\noindent anche di questa funzione esiste una analoga
\macro{\_SVID\_SOURCE} o \macro{\_GNU\_SOURCE}.} che non effettua il blocco
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
+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;
+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 è:
+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à
+ Forza la scrittura di tutti i dati bufferizzati degli stream in modalità
line buffered.
\end{prototype}
usare \func{sync} o \func{fsync} (si veda~sez.~\ref{sec:file_sync}).
Infine esistono anche circostanze in cui si vuole scartare tutto l'output
-pendente; per questo si può usare \funcd{fpurge}, il cui prototipo è:
+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}.
errore.}
\end{prototype}
-La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
-scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
+La funzione scarta tutti i dati non ancora scritti (se il file è aperto in
+scrittura), e tutto l'input non ancora letto (se è aperto in lettura),
compresi gli eventuali caratteri rimandati indietro con \func{ungetc}.
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
-\textit{thread}, dato che l'implementazione delle librerie è influenzata
+\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
+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.
Ci sono comunque situazioni in cui questo non basta, come quando un
-\textit{thread} necessita di compiere più di una operazione sullo stream
+\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
\headdecl{stdio.h}
\funcdecl{void flockfile(FILE *stream)} Esegue l'acquisizione del lock dello
- stream \param{stream}, bloccandosi se il lock non è disponibile.
+ 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.
+ dello 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
\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 è
+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
+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
+ 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
+\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 è:
+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
+ 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.
valori \const{FSETLOCKING\_INTERNAL} o \const{FSETLOCKING\_BYCALLER}.}
\end{prototype}
-La funzione imposta o legge lo stato della modalità di operazione di uno stream
+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:
+che può essere uno dei seguenti:
\begin{basedescript}{\desclabelwidth{4.0cm}}
-\item[\const{FSETLOCKING\_INTERNAL}] Lo stream userà da ora in poi il blocco
+\item[\const{FSETLOCKING\_INTERNAL}] Lo stream userà da ora in poi il blocco
implicito predefinito.
-\item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
+\item[\const{FSETLOCKING\_BYCALLER}] Al ritorno della funzione sarà l'utente a
dover gestire da solo il locking dello stream.
-\item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
+\item[\const{FSETLOCKING\_QUERY}] Restituisce lo stato corrente della modalità
di blocco dello stream.
\end{basedescript}
% LocalWords: IROTH IWOTH umask fseek fsetpos rewind SEEK CUR EOF EBADF close
% LocalWords: sync fcloseall SOURCE void stdlib of feof ferror clearerr l'I ws
% LocalWords: unlocked fread fwrite size ptr nmemb nelem gcc padding point str
-% LocalWords: lock thread fgetc getc getchar dell'overhead altresì unsigned ap
+% LocalWords: lock thread fgetc getc getchar dell'overhead altresì unsigned ap
% LocalWords: getwc fgetwc getwchar wint wchar WEOF putc fputc putchar dell'I
% LocalWords: SVID getw putw parsing peeking ahead ungetc gets fgets string Di
% LocalWords: overflow Aleph stack fputs puts fgetws fputws getline ssize leak
Esamineremo in questo capitolo la prima delle due interfacce di programmazione
per i file, quella dei \index{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 è
+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 è
costruita anche l'interfaccia definita dallo standard ANSI C che affronteremo
al cap.~\ref{cha:files_std_interface}.
\section{L'architettura di base}
\label{sec:file_base_arch}
-In questa sezione faremo una breve introduzione sull'architettura su cui è
+In questa sezione faremo una breve introduzione sull'architettura su cui è
basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
differenze nella realizzazione pratica, resta sostanzialmente la stessa in
tutte le implementazione di un sistema unix-like.
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
quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si fa aprendo il file
-con la funzione \func{open} che provvederà a localizzare \index{inode} l'inode
+con la funzione \func{open} che provvederà a localizzare \index{inode} l'inode
del file e inizializzare i puntatori che rendono disponibili le funzioni che
il VFS mette a disposizione (riportate in
tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
-file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
+file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
impedendo ogni ulteriore operazione.
All'interno di ogni processo i file aperti sono identificati da un intero non
\textit{process table} ed un elenco dei file aperti nella
\itindex{file~table} \textit{file table}.
-La \itindex{process~table} \textit{process table} è una tabella che contiene
-una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
+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
raccolte tutte le informazioni relative al processo; fra queste informazioni
-c'è anche il puntatore ad una ulteriore struttura di tipo
+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:
\begin{itemize*}
\item una tabella che contiene un puntatore alla relativa voce nella
\itindex{file~table} \textit{file table} per ogni file aperto.
\end{itemize*}
-il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
+il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
quest'ultima tabella.
-La \itindex{file~table} \textit{file table} è una tabella che contiene una
-voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
+La \itindex{file~table} \textit{file table} è una tabella che contiene una
+voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
strutture di tipo \struct{file}; in ciascuna di esse sono tenute varie
informazioni relative al file, fra cui:
\begin{itemize*}
\item lo stato del file (nel campo \var{f\_flags}).
\item il valore della posizione corrente (l'\textit{offset}) nel file (nel
campo \var{f\_pos}).
-\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
- realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
+\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
+ realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
a sua volta \index{inode} all'inode passando per la nuova struttura del
VFS.} del file.
%\item un puntatore alla tabella delle funzioni \footnote{la struttura
% sul file.
\end{itemize*}
-In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
+In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
questa architettura, ed in cui si sono evidenziate le interrelazioni fra le
-varie strutture di dati sulla quale essa è basata.
-Ritorneremo su questo schema più volte, dato che esso è fondamentale per
+varie strutture di dati sulla quale essa è basata.
+Ritorneremo su questo schema più volte, dato che esso è fondamentale per
capire i dettagli del funzionamento dell'interfaccia dei \textit{file
descriptor}.
Come accennato i \textit{file descriptor} non sono altro che un indice nella
tabella dei file aperti di ciascun processo; per questo motivo essi vengono
-assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
+assegnati in successione tutte le volte che si apre un nuovo file (se non ne è
stato chiuso nessuno in precedenza).
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
- 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à.
+ 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à.
-Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
+Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
-secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
-si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
+secondo file è il cosiddetto \textit{standard output}, cioè quello su cui ci
+si aspetta debbano essere inviati i dati in uscita. Il terzo è lo
\textit{standard error}, su cui viene inviata l'uscita relativa agli errori.
Nel caso della shell tutti questi file sono associati al terminale di
controllo, e corrispondono quindi alla lettura della tastiera per l'ingresso e
\label{tab:file_std_files}
\end{table}
-In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
-facendo riferimento ad un programma in cui lo \textit{standard input} è
+In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
+facendo riferimento ad un programma in cui lo \textit{standard input} è
associato ad un file mentre lo \textit{standard output} e lo \textit{standard
error} sono entrambi associati ad un altro file (e quindi utilizzano lo
stesso \index{inode} inode).
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
-più recenti non sussiste più, dato che si è passati da un vettore ad una
+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}).
\section{Le funzioni base}
\label{sec:file_base_func}
-L'interfaccia standard Unix per l'input/output sui file è basata su cinque
+L'interfaccia standard Unix per l'input/output sui file è basata su cinque
funzioni fondamentali: \func{open}, \func{read}, \func{write}, \func{lseek} e
\func{close}, usate rispettivamente per aprire, leggere, scrivere, spostarsi e
chiudere un file. La gran parte delle operazioni sui file si effettua
\subsection{La funzione \func{open}}
\label{sec:file_open}
-La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
+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 \index{file!descriptor} file descriptor, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
\headdecl{fcntl.h}
\funcdecl{int open(const char *pathname, int flags)}
\funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
- Apre il file indicato da \param{pathname} nella modalità indicata da
+ Apre il file indicato da \param{pathname} nella modalità indicata da
\param{flags}, e, nel caso il file sia creato, con gli eventuali permessi
specificati da \param{mode}.
\bodydesc{La funzione ritorna il file descriptor in caso di successo e $-1$
- in caso di errore. In questo caso la variabile \var{errno} assumerà uno
+ in caso di errore. In questo caso la variabile \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
+ \item[\errcode{EEXIST}] \param{pathname} esiste e si è specificato
\const{O\_CREAT} e \const{O\_EXCL}.
- \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
+ \item[\errcode{EISDIR}] \param{pathname} indica una directory e si è tentato
l'accesso in scrittura.
- \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
- \param{pathname} non è una directory.
+ \item[\errcode{ENOTDIR}] si è specificato \const{O\_DIRECTORY} e
+ \param{pathname} non è una directory.
\item[\errcode{ENXIO}] si sono impostati \const{O\_NOBLOCK} o
- \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
- processo o \param{pathname} è un file di dispositivo ma il dispositivo è
+ \const{O\_WRONLY} ed il file è una fifo che non viene letta da nessun
+ processo o \param{pathname} è un file di dispositivo ma il dispositivo è
assente.
\item[\errcode{ENODEV}] \param{pathname} si riferisce a un file di
dispositivo che non esiste.
- \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
+ \item[\errcode{ETXTBSY}] si è cercato di accedere in scrittura all'immagine
di un programma in esecuzione.
\item[\errcode{ELOOP}] si sono incontrati troppi link simbolici nel
- risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
- \param{pathname} è un link simbolico.
+ risolvere il \textit{pathname} o si è indicato \const{O\_NOFOLLOW} e
+ \param{pathname} è un link simbolico.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{EROFS}, \errval{EFAULT}, \errval{ENOSPC}, \errval{ENOMEM},
La funzione apre il file usando il primo file descriptor libero, e crea
-l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
+l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
\textit{file table} del processo. Viene sempre restituito come valore di
-ritorno il file descriptor con il valore più basso disponibile.
+ritorno il file descriptor con il valore più basso disponibile.
\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
- opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
+ opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
\index{file!di lock} \textsl{file di lock} possono incorrere in una
\itindex{race~condition} \textit{race condition}. Si consiglia come
alternativa di usare un file con un nome univoco e la funzione \func{link}
\hline
\textbf{Flag} & \textbf{Descrizione} \\
\hline
- \hline % modalità di accesso al file
+ \hline % modalità di accesso al file
\const{O\_RDONLY} & Apre il file in sola lettura, le \acr{glibc}
definiscono anche \const{O\_READ} come sinonimo. \\
\const{O\_WRONLY} & Apre il file in sola scrittura, le \acr{glibc}
definiscono anche \const{O\_WRITE} come sinonimo. \\
\const{O\_RDWR} & Apre il file sia in lettura che in scrittura. \\
- \hline % modalità di apertura del file
+ \hline % modalità di apertura del file
\hline
- \const{O\_CREAT} & Se il file non esiste verrà creato, con le regole di
- titolarità del file viste in
+ \const{O\_CREAT} & Se il file non esiste verrà creato, con le regole di
+ titolarità del file viste in
sez.~\ref{sec:file_ownership_management}. Con questa
opzione l'argomento \param{mode} deve essere
specificato.\\
- \const{O\_EXCL} & Usato in congiunzione con \const{O\_CREAT} fa sì che
+ \const{O\_EXCL} & Usato in congiunzione con \const{O\_CREAT} fa sì che
la precedente esistenza del file diventi un
errore\protect\footnotemark\ che fa fallire
\func{open} con \errcode{EEXIST}.\\
- \const{O\_NONBLOCK}& Apre il file in modalità non bloccante, e
+ \const{O\_NONBLOCK}& Apre il file in modalità non bloccante, e
comporta che \func{open} ritorni immediatamente anche
quando dovrebbe bloccarsi (l'opzione ha senso solo per
le fifo, vedi sez.~\ref{sec:ipc_named_pipe}).\\
\const{O\_NOCTTY} & Se \param{pathname} si riferisce ad un dispositivo di
- terminale, questo non diventerà il terminale di
+ terminale, questo non diventerà il terminale di
controllo, anche se il processo non ne ha ancora uno
(si veda sez.~\ref{sec:sess_ctrl_term}).\\
\const{O\_SHLOCK} & Apre il file con uno shared lock (vedi
\const{O\_TRUNC} & Se usato su un file di dati aperto in scrittura,
ne tronca la lunghezza a zero; con un terminale o una
fifo viene ignorato, negli altri casi il
- comportamento non è specificato.\\
- \const{O\_NOFOLLOW}& Se \param{pathname} è un link simbolico la chiamata
- fallisce. Questa è un'estensione BSD aggiunta in Linux
+ comportamento non è specificato.\\
+ \const{O\_NOFOLLOW}& Se \param{pathname} è un link simbolico la chiamata
+ fallisce. Questa è un'estensione BSD aggiunta in Linux
dal kernel 2.1.126. Nelle versioni precedenti i link
- simbolici sono sempre seguiti, e questa opzione è
+ simbolici sono sempre seguiti, e questa opzione è
ignorata.\\
- \const{O\_DIRECTORY}&Se \param{pathname} non è una directory la chiamata
- fallisce. Questo flag è specifico di Linux ed è stato
+ \const{O\_DIRECTORY}&Se \param{pathname} non è una directory la chiamata
+ fallisce. Questo flag è specifico di Linux ed è stato
introdotto con il kernel 2.1.126 per evitare dei
\itindex{Denial~of~Service~(DoS)}
\textit{DoS}\protect\footnotemark\ quando
\func{opendir} viene chiamata su una fifo o su un
- dispositivo associato ad una unità a nastri, non deve
+ dispositivo associato ad una unità a nastri, non deve
dispositivo a nastri; non deve essere utilizzato
al di fuori dell'implementazione di \func{opendir}.\\
\const{O\_LARGEFILE}&Nel caso di sistemi a 32 bit che supportano file di
dimensioni non possono essere rappresentate da numeri
a 31 bit.\\
\hline
- \hline % modalità di operazione coi file
+ \hline % modalità di operazione coi file
\const{O\_APPEND} & Il file viene aperto in \itindex{append~mode}
\textit{append mode}. Prima di ciascuna
scrittura la posizione corrente viene sempre impostata
- alla fine del file. Con NFS si può avere una
- corruzione del file se più di un processo scrive allo
+ alla fine del file. Con NFS si può avere una
+ corruzione del file se più di un processo scrive allo
stesso tempo.\footnotemark\\
- \const{O\_NONBLOCK}& Il file viene aperto in modalità non bloccante per
+ \const{O\_NONBLOCK}& Il file viene aperto in modalità non bloccante per
le operazioni di I/O (che tratteremo in
sez.~\ref{sec:file_noblocking}): questo significa il
fallimento di \func{read} in assenza di dati da
leggere e quello di \func{write} in caso di
- impossibilità di scrivere immediatamente. Questa
- modalità ha senso solo per le fifo e per alcuni file
+ impossibilità di scrivere immediatamente. Questa
+ modalità ha senso solo per le fifo e per alcuni file
di dispositivo.\\
- \const{O\_NDELAY} & In Linux\footnotemark\ è sinonimo di
+ \const{O\_NDELAY} & In Linux\footnotemark\ è sinonimo di
\const{O\_NONBLOCK}.\\
- \const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
- sez.~\ref{sec:file_asyncronous_io}). Quando è
+ \const{O\_ASYNC} & Apre il file per l'I/O in modalità asincrona (vedi
+ sez.~\ref{sec:file_asyncronous_io}). Quando è
impostato viene generato il segnale \const{SIGIO}
tutte le volte che sono disponibili dati in input
sul file.\\
\const{O\_SYNC} & Apre il file per l'input/output sincrono: ogni
- \func{write} bloccherà fino al completamento della
+ \func{write} bloccherà fino al completamento della
scrittura di tutti i dati sull'hardware
sottostante.\\
\const{O\_FSYNC} & Sinonimo di \const{O\_SYNC}, usato da BSD.\\
modo.\\
\const{O\_NOATIME} & Blocca l'aggiornamento dei tempi di accesso dei
file (vedi sez.~\ref{sec:file_file_times}). Per molti
- filesystem questa funzionalità non è disponibile per
+ filesystem questa funzionalità non è disponibile per
il singolo file ma come opzione generale da
specificare in fase di montaggio.\\
\const{O\_DIRECT} & Esegue l'I/O direttamente dai buffer in user space
alle dimensioni dei blocchi del filesystem; per il
kernel 2.6 basta che siano allineati a multipli di 512
byte.\\
- \const{O\_CLOEXEC} & Attiva la modalità di \itindex{close-on-exec}
+ \const{O\_CLOEXEC} & Attiva la modalità di \itindex{close-on-exec}
\textit{close-on-exec} (vedi
sez.~\ref{sec:file_sharing} e
\ref{sec:file_fcntl}).\footnotemark\\
\end{table}
\footnotetext[3]{acronimo di \itindex{Denial~of~Service~(DoS)} \textit{Denial
- of Service}, si chiamano così attacchi miranti ad impedire un servizio
+ of Service}, si chiamano così attacchi miranti ad impedire un servizio
causando una qualche forma di carico eccessivo per il sistema, che resta
bloccato nelle risposte all'attacco.}
-\footnotetext[4]{il problema è che NFS non supporta la scrittura in
+\footnotetext[4]{il problema è che NFS non supporta la scrittura in
\itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
- questo comporta la possibilità di una \itindex{race~condition} \textit{race
+ questo comporta la possibilità di una \itindex{race~condition} \textit{race
condition}, vedi sez.~\ref{sec:file_atomic}.}
-\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
+\footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
una \func{read} con un valore nullo e non con un errore, questo introduce
- un'ambiguità, dato che come vedremo in sez.~\ref{sec:file_read} il ritorno di
+ un'ambiguità, dato che come vedremo in sez.~\ref{sec:file_read} il ritorno di
zero da parte di \func{read} ha il significato di una \textit{end-of-file}.}
-\footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
+\footnotetext[6]{l'opzione è stata introdotta dalla SGI in IRIX, e serve
sostanzialmente a permettere ad alcuni programmi (in genere database) la
gestione diretta della bufferizzazione dell'I/O in quanto essi sono in grado
- di ottimizzarla al meglio per le loro prestazioni; l'opzione è presente
- anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
+ di ottimizzarla al meglio per le loro prestazioni; l'opzione è presente
+ anche in FreeBSD, senza limiti di allineamento dei buffer. In Linux è stata
introdotta con il kernel 2.4.10, le versioni precedenti la ignorano.}
\footnotetext[7]{introdotto con il kernel 2.6.23, per evitare una
- \itindex{race~condition} \textit{race condition} che si può verificare con i
+ \itindex{race~condition} \textit{race condition} che si può verificare con i
\itindex{thread} \textit{thread}, fra l'apertura del file e l'impostazione
- della suddetta modalità con \func{fcntl}.}
+ della suddetta modalità con \func{fcntl}.}
%TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte nella
% nello sviluppo del kernel 2.6.33, vedi http://lwn.net/Articles/350219/
-Questa caratteristica permette di prevedere qual è il valore del file
-descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
+Questa caratteristica permette di prevedere qual è il valore del file
+descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
alcune applicazioni per sostituire i file corrispondenti ai file standard
visti in sez.~\ref{sec:file_std_descr}: se ad esempio si chiude lo standard
-input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
-input (avrà cioè il file descriptor 0).
+input e si apre subito dopo un nuovo file questo diventerà il nuovo standard
+input (avrà cioè il file descriptor 0).
-Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
+Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo
sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
-sez.~\ref{sec:file_sharing}) ed è impostato per restare aperto attraverso una
-\func{exec} (come accennato in sez.~\ref{sec:proc_exec}); l'offset è impostato
+sez.~\ref{sec:file_sharing}) ed è impostato per restare aperto attraverso una
+\func{exec} (come accennato in sez.~\ref{sec:proc_exec}); l'offset è impostato
all'inizio del file.
L'argomento \param{mode} indica i permessi con cui il file viene creato; i
-valori possibili sono gli stessi già visti in
+valori possibili sono gli stessi già visti in
sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
filtrati dal valore di \itindex{umask} \textit{umask} (vedi
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
-il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
+il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
di fig.~\ref{fig:file_proc_file}). Essi sono divisi in tre categorie
principali:
\begin{itemize*}
-\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
- si accederà al file: i valori possibili sono lettura, scrittura o
+\item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
+ si accederà al file: i valori possibili sono lettura, scrittura o
lettura/scrittura. Uno di questi bit deve essere sempre specificato quando
si apre un file. Vengono impostati alla chiamata da \func{open}, e possono
essere riletti con \func{fcntl} (fanno parte del \textit{file status flag}),
ma non possono essere modificati.
-\item \textsl{i bit delle modalità di apertura}: permettono di specificare
+\item \textsl{i bit delle modalità di apertura}: permettono di specificare
alcune delle caratteristiche del comportamento di \func{open} quando viene
eseguita. Hanno effetto solo al momento della chiamata della funzione e non
- sono memorizzati né possono essere riletti.
-\item \textsl{i bit delle modalità di operazione}: permettono di specificare
+ sono memorizzati né possono essere riletti.
+\item \textsl{i bit delle modalità di operazione}: permettono di specificare
alcune caratteristiche del comportamento delle future operazioni sul file
(come \func{read} o \func{write}). Anch'essi fan parte del \textit{file
- status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
+ status flag}. Il loro valore è impostato alla chiamata di \func{open}, ma
possono essere riletti e modificati (insieme alle caratteristiche operative
che controllano) con una \func{fcntl}.
\end{itemize*}
In tab.~\ref{tab:file_open_flags} sono riportate, ordinate e divise fra loro
-secondo le tre modalità appena elencate, le costanti mnemoniche associate a
+secondo le tre modalità appena elencate, le costanti mnemoniche associate a
ciascuno di questi bit. Dette costanti possono essere combinate fra loro con
un OR aritmetico per costruire il valore (in forma di maschera binaria)
dell'argomento \param{flags} da passare alla \func{open}. I due flag
usare.
Nelle prime versioni di Unix i valori di \param{flag} specificabili per
-\func{open} erano solo quelli relativi alle modalità di accesso del file. Per
+\func{open} erano solo quelli relativi alle modalità di accesso del file. Per
questo motivo per creare un nuovo file c'era una system call apposita,
-\funcd{creat}, il cui prototipo è:
+\funcd{creat}, il cui prototipo è:
\begin{prototype}{fcntl.h}
{int creat(const char *pathname, mode\_t mode)}
- Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
+ Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
tutto equivalente a \code{open(filedes, O\_CREAT|O\_WRONLY|O\_TRUNC, mode)}.
\end{prototype}
-\noindent adesso questa funzione resta solo per compatibilità con i vecchi
+\noindent adesso questa funzione resta solo per compatibilità con i vecchi
programmi.
\label{sec:file_close}
La funzione \funcd{close} permette di chiudere un file, in questo modo il file
-descriptor ritorna disponibile; il suo prototipo è:
+descriptor ritorna disponibile; il suo prototipo è:
\begin{prototype}{unistd.h}{int close(int fd)}
Chiude il descrittore \param{fd}.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
errore, con \var{errno} che assume i valori:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EBADF}] \param{fd} non è un descrittore valido.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
ed inoltre \errval{EIO}.}
\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
-processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
+\index{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
descriptor era l'ultimo riferimento ad un file su disco quest'ultimo viene
Si ricordi che quando un processo termina anche tutti i suoi file descriptor
vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
esplicitamente \func{close}. In genere comunque chiudere un file senza
-controllarne lo stato di uscita è errore; infatti molti filesystem
+controllarne lo stato di uscita è errore; infatti molti filesystem
implementano la tecnica del \textit{write-behind}, per cui una \func{write}
-può avere successo anche se i dati non sono stati scritti, un eventuale errore
-di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
-questo motivo non effettuare il controllo può portare ad una perdita di dati
-inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
+può avere successo anche se i dati non sono stati scritti, un eventuale errore
+di I/O allora può sfuggire, ma verrà riportato alla chiusura del file: per
+questo motivo non effettuare il controllo può portare ad una perdita di dati
+inavvertita.\footnote{in Linux questo comportamento è stato osservato con NFS
e le quote su disco.}
In ogni caso una \func{close} andata a buon fine non garantisce che i dati
-siano stati effettivamente scritti su disco, perché il kernel può decidere di
+siano stati effettivamente scritti su disco, perché il kernel può decidere di
ottimizzare l'accesso a disco ritardandone la scrittura. L'uso della funzione
\func{sync} (vedi sez.~\ref{sec:file_sync}) effettua esplicitamente il
\emph{flush} dei dati, ma anche in questo caso resta l'incertezza dovuta al
-comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
+comportamento dell'hardware (che a sua volta può introdurre ottimizzazioni
dell'accesso al disco che ritardano la scrittura dei dati, da cui l'abitudine
di ripetere tre volte il comando prima di eseguire lo shutdown).
\subsection{La funzione \func{lseek}}
\label{sec:file_lseek}
-Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
+Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
mantenuto nel campo \var{f\_pos} di \struct{file}) espressa da un numero intero
positivo come numero di byte dall'inizio del file. Tutte le operazioni di
lettura e scrittura avvengono a partire da questa posizione che viene
automaticamente spostata in avanti del numero di byte letti o scritti.
-In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
+In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
\const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
-file. È possibile impostarla ad un valore qualsiasi con la funzione
-\funcd{lseek}, il cui prototipo è:
+file. È possibile impostarla ad un valore qualsiasi con la funzione
+\funcd{lseek}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
Imposta la posizione attuale nel file.
\bodydesc{La funzione ritorna il valore della posizione corrente in caso di
- successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
+ successo e $-1$ in caso di errore nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
- \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
- \item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
+ \item[\errcode{ESPIPE}] \param{fd} è una pipe, un socket o una fifo.
+ \item[\errcode{EINVAL}] \param{whence} non è un valore valido.
+ \item[\errcode{EOVERFLOW}] \param{offset} non può essere rappresentato nel
tipo \type{off\_t}.
\end{errlist}
ed inoltre \errval{EBADF}.}
\end{functions}
-La nuova posizione è impostata usando il valore specificato da \param{offset},
-sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
-seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
+La nuova posizione è impostata usando il valore specificato da \param{offset},
+sommato al riferimento dato da \param{whence}; quest'ultimo può assumere i
+seguenti valori\footnote{per compatibilità con alcune vecchie notazioni
questi valori possono essere rimpiazzati rispettivamente con 0, 1 e 2 o con
\const{L\_SET}, \const{L\_INCR} e \const{L\_XTND}.}:
\begin{basedescript}{\desclabelwidth{2.0cm}}
(sempre positivo) di \param{offset} indica direttamente la nuova posizione
corrente.
\item[\const{SEEK\_CUR}] si fa riferimento alla posizione corrente del file:
- ad essa viene sommato \param{offset} (che può essere negativo e positivo)
+ ad essa viene sommato \param{offset} (che può essere negativo e positivo)
per ottenere la nuova posizione corrente.
\item[\const{SEEK\_END}] si fa riferimento alla fine del file: alle dimensioni
- del file viene sommato \param{offset} (che può essere negativo e positivo)
+ del file viene sommato \param{offset} (che può essere negativo e positivo)
per ottenere la nuova posizione corrente.
\end{basedescript}
Si tenga presente che la chiamata a \func{lseek} non causa nessun accesso al
-file, si limita a modificare la posizione corrente (cioè il valore
+file, si limita a modificare la posizione corrente (cioè il valore
\var{f\_pos} in \param{file}, vedi fig.~\ref{fig:file_proc_file}). Dato che
la funzione ritorna la nuova posizione, usando il valore zero
-per \param{offset} si può riottenere la posizione corrente nel file chiamando
+per \param{offset} si può riottenere la posizione corrente nel file chiamando
la funzione con \code{lseek(fd, 0, SEEK\_CUR)}.
Si tenga presente inoltre che usare \const{SEEK\_END} non assicura affatto che
-la successiva scrittura avvenga alla fine del file, infatti se questo è stato
-aperto anche da un altro processo che vi ha scritto, la fine del file può
+la successiva scrittura avvenga alla fine del file, infatti se questo è stato
+aperto anche da un altro processo che vi ha scritto, la fine del file può
essersi spostata, ma noi scriveremo alla posizione impostata in precedenza
-(questa è una potenziale sorgente di \itindex{race~condition} \textit{race
+(questa è una potenziale sorgente di \itindex{race~condition} \textit{race
condition}, vedi sez.~\ref{sec:file_atomic}).
-Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
+Non tutti i file supportano la capacità di eseguire una \func{lseek}, in
questo caso la funzione ritorna l'errore \errcode{ESPIPE}. Questo, oltre che
per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che
non supportano questa funzione, come ad esempio per i file di
terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
-POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
+POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
indefinito.
\itindbeg{sparse~file}
Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
-con \func{lseek} è possibile impostare una posizione anche oltre la corrente
-fine del file; ed in tal caso alla successiva scrittura il file sarà esteso a
+con \func{lseek} è possibile impostare una posizione anche oltre la corrente
+fine del file; ed in tal caso alla successiva scrittura il file sarà esteso a
partire da detta posizione. In questo caso si ha quella che viene chiamata la
-creazione di un \index{file!\textit{hole}} \textsl{buco} nel file, accade cioè
+creazione di un \index{file!\textit{hole}} \textsl{buco} nel file, accade cioè
che nonostante la dimensione del file sia cresciuta in seguito alla scrittura
effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte
scritta dopo lo spostamento, non corrisponda ad una allocazione effettiva di
-spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
+spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
vuota.
-Questa è una delle caratteristiche spcifiche della gestione dei file di un
+Questa è una delle caratteristiche spcifiche della gestione dei file di un
sistema unix-like, ed in questo caso si ha appunto quello che in gergo si
chiama un \index{file!\textit{hole}} \textit{hole} nel file e si dice che il
-file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
+file in questione è uno \textit{sparse file}. In sostanza, se si ricorda la
struttura di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail},
-quello che accade è che nell'\textit{inode} del file viene segnata
+quello che accade è che nell'\textit{inode} del file viene segnata
l'allocazione di un blocco di dati a partire dalla nuova posizione, ma non
viene allocato nulla per le posizioni intermedie; in caso di lettura
-sequenziale del contenuto del file il kernel si accorgerà della presenza del
-buco, e restituirà degli zeri come contenuto di quella parte del file.
+sequenziale del contenuto del file il kernel si accorgerà della presenza del
+buco, e restituirà degli zeri come contenuto di quella parte del file.
-Questa funzionalità comporta una delle caratteristiche della gestione dei file
-su Unix che spesso genera più confusione in chi non la conosce, per cui
-sommando le dimensioni dei file si può ottenere, se si hanno molti
-\textit{sparse file}, un totale anche maggiore della capacità del proprio
+Questa funzionalità comporta una delle caratteristiche della gestione dei file
+su Unix che spesso genera più confusione in chi non la conosce, per cui
+sommando le dimensioni dei file si può ottenere, se si hanno molti
+\textit{sparse file}, un totale anche maggiore della capacità del proprio
disco e comunque maggiore della dimensione che riporta un comando come
\cmd{du}, che calcola lo spazio disco occupato in base al numero dei blocchi
effettivamente allocati per il file.
-Questo avviene proprio perché in un sistema unix-like la dimensione di un file
-è una caratteristica del tutto indipendente dalla quantità di spazio disco
+Questo avviene proprio perché in un sistema unix-like la dimensione di un file
+è una caratteristica del tutto indipendente dalla quantità di spazio disco
effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
-proprietà del file. La dimensione viene aggiornata automaticamente quando si
+proprietà del file. La dimensione viene aggiornata automaticamente quando si
estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
struttura \struct{stat} quando si effettua chiamata ad una delle funzioni
\texttt{*stat} viste in sez.~\ref{sec:file_stat}.
-Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
-la dimensione di un file sarà più o meno corrispondente alla quantità di
+Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
+la dimensione di un file sarà più o meno corrispondente alla quantità di
spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
sposta in una posizione oltre la fine corrente del file, o come quello
accennato in in sez.~\ref{sec:file_file_size} in cui si estende la dimensione
di un file con una \func{truncate}, in cui in sostanza di modifica il valore
della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
consente di creare inizialmente file di dimensioni anche molto grandi, senza
-dover occupare da subito dello spazio disco che in realtà sarebbe
+dover occupare da subito dello spazio disco che in realtà sarebbe
inutilizzato.
\itindend{sparse~file}
\subsection{Le funzioni \func{read} e \func{pread}}
\label{sec:file_read}
-Una volta che un file è stato aperto (con il permesso in lettura) si possono
+Una volta che un file è stato aperto (con il permesso in lettura) si possono
leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
-prototipo è:
+prototipo è:
\begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
Cerca di leggere \param{count} byte dal file \param{fd} al buffer
\param{buf}.
\bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
aver potuto leggere qualsiasi dato.
\item[\errcode{EAGAIN}] la funzione non aveva nessun dato da restituire e si
- era aperto il file in modalità \const{O\_NONBLOCK}.
+ era aperto il file in modalità \const{O\_NONBLOCK}.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
\errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori dipendenti dalla
\end{prototype}
La funzione tenta di leggere \param{count} byte a partire dalla posizione
-corrente nel file. Dopo la lettura la posizione sul file è spostata
-automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
+corrente nel file. Dopo la lettura la posizione sul file è spostata
+automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
-presente che non è detto che la funzione \func{read} restituisca sempre il
+presente che non è detto che la funzione \func{read} restituisca sempre il
numero di byte richiesto, ci sono infatti varie ragioni per cui la funzione
-può restituire un numero di byte inferiore; questo è un comportamento normale,
+può restituire un numero di byte inferiore; questo è un comportamento normale,
e non un errore, che bisogna sempre tenere presente.
-La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
+La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte
di quanto il file ne contenga. In questo caso il file viene letto fino alla
sua fine, e la funzione ritorna regolarmente il numero di byte letti
effettivamente. Raggiunta la fine del file, alla ripetizione di un'operazione
di lettura, otterremmo il ritorno immediato di \func{read} con uno zero. La
-condizione di raggiungimento della fine del file non è un errore, e viene
+condizione di raggiungimento della fine del file non è un errore, e viene
segnalata appunto da un valore di ritorno di \func{read} nullo. Ripetere
ulteriormente la lettura non avrebbe nessun effetto se non quello di
continuare a ricevere zero come valore di ritorno.
-Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
-un numero di byte letti inferiore a quello richiesto, ma questo non è vero
+Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere
+un numero di byte letti inferiore a quello richiesto, ma questo non è vero
quando si legge da un terminale, da una fifo o da una pipe. In tal caso
infatti, se non ci sono dati in ingresso, la \func{read} si blocca (a meno di
-non aver selezionato la modalità non bloccante, vedi
+non aver selezionato la modalità non bloccante, vedi
sez.~\ref{sec:file_noblocking}) e ritorna solo quando ne arrivano; se il numero
di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma
con un numero di byte inferiore a quelli richiesti.
-Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
+Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket,
come vedremo in sez.~\ref{sec:sock_io_behav}), o per la lettura da certi file
-di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
+di dispositivo, come le unità a nastro, che restituiscono sempre i dati ad un
singolo blocco alla volta, o come le linee seriali, che restituiscono solo i
dati ricevuti fino al momento della lettura.
Infine anche le due condizioni segnalate dagli errori \errcode{EINTR} ed
\errcode{EAGAIN} non sono propriamente degli errori. La prima si verifica
-quando la \func{read} è bloccata in attesa di dati in ingresso e viene
-interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
+quando la \func{read} è bloccata in attesa di dati in ingresso e viene
+interrotta da un segnale; in tal caso l'azione da intraprendere è quella di
rieseguire la funzione. Torneremo in dettaglio sull'argomento in
-sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
-in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
+sez.~\ref{sec:sig_gen_beha}. La seconda si verifica quando il file è aperto
+in modalità non bloccante (vedi sez.~\ref{sec:file_noblocking}) e non ci sono
dati in ingresso: la funzione allora ritorna immediatamente con un errore
\errcode{EAGAIN}\footnote{in BSD si usa per questo errore la costante
- \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
+ \errcode{EWOULDBLOCK}, in Linux, con le \acr{glibc}, questa è sinonima di
\errcode{EAGAIN}.} che indica soltanto che non essendoci al momento dati
disponibili occorre provare a ripetere la lettura in un secondo tempo.
-La funzione \func{read} è una delle system call fondamentali, esistenti fin
+La funzione \func{read} è una delle system call fondamentali, esistenti fin
dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix
Specification}\footnote{questa funzione, e l'analoga \func{pwrite} sono
state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa
- l'emulazione per i vecchi kernel che non hanno la system call, è stato
+ l'emulazione per i vecchi kernel che non hanno la system call, è stato
aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
- delle librerie la funzione non è disponibile.} (quello che viene chiamato
-normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
-definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
+ delle librerie la funzione non è disponibile.} (quello che viene chiamato
+normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la
+definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
\begin{prototype}{unistd.h}
{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
posizione \param{offset}, nel buffer \param{buf}.
\bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
visti per \func{read} e \func{lseek}.}
\end{prototype}
La funzione prende esattamente gli stessi argomenti di \func{read} con lo
stesso significato, a cui si aggiunge l'argomento \func{offset} che indica una
-posizione sul file. Identico è il comportamento ed il valore di ritorno. La
+posizione sul file. Identico è il comportamento ed il valore di ritorno. La
funzione serve quando si vogliono leggere dati dal file senza modificare la
posizione corrente.
-L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
+L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
da una \func{lseek} che riporti al valore precedente la posizione corrente sul
-file, ma permette di eseguire l'operazione atomicamente. Questo può essere
+file, ma permette di eseguire l'operazione atomicamente. Questo può essere
importante quando la posizione sul file viene condivisa da processi diversi
(vedi sez.~\ref{sec:file_sharing}). Il valore di
\param{offset} fa sempre riferimento all'inizio del file.
-La funzione \func{pread} è disponibile anche in Linux, però diventa
+La funzione \func{pread} è disponibile anche in Linux, però diventa
accessibile solo attivando il supporto delle estensioni previste dalle
\textit{Single Unix Specification} con la definizione della macro:
\begin{verbatim}
\subsection{Le funzioni \func{write} e \func{pwrite}}
\label{sec:file_write}
-Una volta che un file è stato aperto (con il permesso in scrittura) si può
-scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
+Una volta che un file è stato aperto (con il permesso in scrittura) si può
+scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
\begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
\bodydesc{La funzione ritorna il numero di byte scritti in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
+ e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
+ \item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
la scrittura.
- \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
+ \item[\errcode{EFBIG}] si è cercato di scrivere oltre la dimensione massima
consentita dal filesystem o il limite per le dimensioni dei file del
processo o su una posizione oltre il massimo consentito.
- \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
+ \item[\errcode{EPIPE}] \param{fd} è connesso ad una pipe il cui altro capo è
chiuso in lettura; in questo caso viene anche generato il segnale
\const{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la
funzione ritorna questo errore.
- \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
+ \item[\errcode{EINTR}] si è stati interrotti da un segnale prima di aver
potuto scrivere qualsiasi dato.
\item[\errcode{EAGAIN}] ci si sarebbe bloccati, ma il file era aperto in
- modalità \const{O\_NONBLOCK}.
+ modalità \const{O\_NONBLOCK}.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EIO}, \errval{EISDIR}, \errval{EBADF},
\errval{ENOSPC}, \errval{EINVAL} e \errval{EFAULT} ed eventuali altri errori
Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
a partire dalla posizione corrente nel file e sposta automaticamente la
-posizione in avanti del numero di byte scritti. Se il file è aperto in
-modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
+posizione in avanti del numero di byte scritti. Se il file è aperto in
+modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
alla fine del file. Lo standard POSIX richiede che i dati scritti siano
immediatamente disponibili ad una \func{read} chiamata dopo che la
-\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
-non è detto che tutti i filesystem supportino questa capacità.
+\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
+non è detto che tutti i filesystem supportino questa capacità.
-Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
-Per i file ordinari il numero di byte scritti è sempre uguale a quello
+Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
+Per i file ordinari il numero di byte scritti è sempre uguale a quello
indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
stesso comportamento di \func{read}.
Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
per scrivere alla posizione indicata senza modificare la posizione corrente
-nel file, il suo prototipo è:
+nel file, il suo prototipo è:
\begin{prototype}{unistd.h}
{ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)}
\param{offset}, \param{count} byte dal buffer \param{buf}.
\bodydesc{La funzione ritorna il numero di byte letti in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà i valori già
visti per \func{write} e \func{lseek}.}
\end{prototype}
\noindent e per essa valgono le stesse considerazioni fatte per \func{pread}.
\section{Caratteristiche avanzate}
\label{sec:file_adv_func}
-In questa sezione approfondiremo alcune delle caratteristiche più sottili
+In questa sezione approfondiremo alcune delle caratteristiche più sottili
della gestione file in un sistema unix-like, esaminando in dettaglio il
comportamento delle funzioni base, inoltre tratteremo le funzioni che
permettono di eseguire alcune operazioni avanzate con i file (il grosso
-dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
+dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
\subsection{La condivisione dei files}
\label{fig:file_mult_acc}
\end{figure}
-Il primo caso è quello in cui due processi diversi aprono lo stesso file su
+Il primo caso è quello in cui due processi diversi aprono lo stesso file su
disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
-processo avrà una sua voce nella \textit{file table} referenziata da un
+processo avrà una sua voce nella \textit{file table} referenziata da un
diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
-nella \itindex{file~table} \textit{file table} faranno però riferimento allo
+nella \itindex{file~table} \textit{file table} faranno però riferimento allo
stesso \index{inode} inode su disco.
-Questo significa che ciascun processo avrà la sua posizione corrente sul file,
-la sua modalità di accesso e versioni proprie di tutte le proprietà che
+Questo significa che ciascun processo avrà la sua posizione corrente sul file,
+la sua modalità di accesso e versioni proprie di tutte le proprietà che
vengono mantenute nella sua voce della \itindex{file~table} \textit{file
table}. Questo ha conseguenze specifiche sugli effetti della possibile
azione simultanea sullo stesso file, in particolare occorre tenere presente
che:
\begin{itemize}
-\item ciascun processo può scrivere indipendentemente; dopo ciascuna
- \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
- scrittura eccede la dimensione corrente del file questo verrà esteso
+\item ciascun processo può scrivere indipendentemente; dopo ciascuna
+ \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
+ scrittura eccede la dimensione corrente del file questo verrà esteso
automaticamente con l'aggiornamento del campo \var{i\_size} \index{inode}
nell'inode.
-\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
+\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
le volte che viene effettuata una scrittura la posizione corrente viene
prima impostata alla dimensione corrente del file letta \index{inode}
dall'inode. Dopo la scrittura il file viene automaticamente esteso.
-\item l'effetto di \func{lseek} è solo quello di cambiare il campo
+\item l'effetto di \func{lseek} è solo quello di cambiare il campo
\var{f\_pos} nella struttura \struct{file} della \itindex{file~table}
- \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
+ \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
si usa per porsi alla fine del file la posizione viene impostata leggendo la
dimensione corrente \index{inode} dall'inode.
\end{itemize}
\label{fig:file_acc_child}
\end{figure}
-Il secondo caso è quello in cui due file descriptor di due processi diversi
+Il secondo caso è quello in cui due file descriptor di due processi diversi
puntino alla stessa voce nella \itindex{file~table} \textit{file table};
-questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
+questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
figlio all'esecuzione di una \func{fork} (si ricordi quanto detto in
-sez.~\ref{sec:proc_fork}). La situazione è illustrata in
+sez.~\ref{sec:proc_fork}). La situazione è illustrata in
fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
-dello spazio di indirizzi del padre, riceverà anche una copia di
+dello spazio di indirizzi del padre, riceverà anche una copia di
\struct{file\_struct} e relativa tabella dei file aperti.
In questo modo padre e figlio avranno gli stessi file descriptor che faranno
-riferimento alla stessa voce nella \textit{file table}, condividendo così la
+riferimento alla stessa voce nella \textit{file table}, condividendo così la
posizione corrente sul file. Questo ha le conseguenze descritte a suo tempo in
sez.~\ref{sec:proc_fork}: in caso di scrittura contemporanea la posizione
-corrente nel file varierà per entrambi i processi (in quanto verrà modificato
-\var{f\_pos} che è lo stesso per entrambi).
+corrente nel file varierà per entrambi i processi (in quanto verrà modificato
+\var{f\_pos} che è lo stesso per entrambi).
Si noti inoltre che anche i flag di stato del file (quelli impostati
dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
\textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
- \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
-associati anche altri flag, dei quali l'unico usato al momento è
+ \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
+associati anche altri flag, dei quali l'unico usato al momento è
\const{FD\_CLOEXEC}, detti \textit{file descriptor flags}. Questi ultimi sono
-tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
+tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
processo e non vengono modificati dalle azioni degli altri anche in caso di
condivisione della stessa voce della \textit{file table}.
\subsection{Operazioni atomiche con i file}
\label{sec:file_atomic}
-Come si è visto in un sistema unix-like è sempre possibile per più processi
+Come si è visto in un sistema unix-like è sempre possibile per più processi
accedere in contemporanea allo stesso file, e che le operazioni di lettura e
scrittura possono essere fatte da ogni processo in maniera autonoma in base
-ad una posizione corrente nel file che è locale a ciascuno di essi.
+ad una posizione corrente nel file che è locale a ciascuno di essi.
Se dal punto di vista della lettura dei dati questo non comporta nessun
-problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
-maniera imprevedibile. Il sistema però fornisce in alcuni casi la possibilità
+problema, quando si andrà a scrivere le operazioni potranno mescolarsi in
+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
+utilizzare meccanismi di sincronizzazione più complessi (come il
\index{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
+Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
vari processi devono scrivere alla fine di un file (ad esempio un file di
log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
-fine del file e poi scrivere può condurre ad una \itindex{race~condition}
-\textit{race condition}: infatti può succedere che un secondo processo scriva
+fine del file e poi scrivere può condurre ad una \itindex{race~condition}
+\textit{race condition}: infatti può succedere che un secondo processo scriva
alla fine del file fra la \func{lseek} e la \func{write}; in questo caso, come
-abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
+abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà
ancora la posizione corrente impostata con la \func{lseek} che non corrisponde
-più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
+più alla fine del file, e la successiva \func{write} sovrascriverà i dati del
secondo processo.
-Il problema è che usare due system call in successione non è un'operazione
-atomica; il problema è stato risolto introducendo la modalità
+Il problema è che usare due system call in successione non è un'operazione
+atomica; il problema è stato risolto introducendo la modalità
\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
-descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
+descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
alla fine del file prima di effettuare la scrittura, e poi estende il file.
Tutto questo avviene all'interno di una singola system call (la \func{write})
che non essendo interrompibile da un altro processo costituisce un'operazione
atomica.
-Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
+Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
creare un \textsl{file di lock} \index{file!di lock}, bloccandosi se il file
esiste. In questo caso la sequenza logica porterebbe a verificare prima
l'esistenza del file con una \func{stat} per poi crearlo con una \func{creat};
-di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
+di nuovo avremmo la possibilità di una \itindex{race~condition} \textit{race
condition} da parte di un altro processo che crea lo stesso file fra il
controllo e la creazione.
asincrona (ad esempio accorpando gli accessi alla stessa zona del disco) in un
secondo tempo rispetto al momento della esecuzione della \func{write}.
-Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
+Per questo motivo, quando è necessaria una sincronizzazione dei dati, il
sistema mette a disposizione delle funzioni che provvedono a forzare lo
-scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
- questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
- l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
- ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
- scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
-prototipo è:
+scarico dei dati dai buffer del kernel.\footnote{come già accennato neanche
+ questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
+ l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
+ ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
+ scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
+prototipo è:
\begin{prototype}{unistd.h}{int sync(void)}
Sincronizza il buffer della cache dei file col disco.
La funzione viene usata dal comando \cmd{sync} quando si vuole forzare
esplicitamente lo scarico dei dati su disco, o dal demone di sistema
\cmd{update} che esegue lo scarico dei dati ad intervalli di tempo fissi: il
-valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
-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
+valore tradizionale, usato da BSD, per l'update dei dati è ogni 30 secondi, ma
+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
-il significato dei valori si può leggere la documentazione allegata al kernel
+può essere controllato attraverso il file \procfile{/proc/sys/vm/bdflush} (per
+il significato dei valori si può leggere la documentazione allegata al kernel
in \file{Documentation/sysctl/vm.txt}).
Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
errore, nel qual caso \var{errno} assume i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+ \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
sincronizzazione.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EROFS} e \errval{EIO}.}
Si tenga presente che questo non comporta la sincronizzazione della
directory che contiene il file (e scrittura della relativa voce su
-disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
+disco) che deve essere effettuata esplicitamente.\footnote{in realtà per
il filesystem \acr{ext2}, quando lo si monta con l'opzione \cmd{sync},
il kernel provvede anche alla sincronizzazione automatica delle voci
delle directory.}
\subsection{Le funzioni \func{dup} e \func{dup2}}
\label{sec:file_dup}
-Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
-condivida gli stessi file descriptor del padre; è possibile però ottenere un
+Abbiamo già visto in sez.~\ref{sec:file_sharing} come un processo figlio
+condivida gli stessi file descriptor del padre; è possibile però ottenere un
comportamento analogo all'interno di uno stesso processo \textit{duplicando}
un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
-prototipo è:
+prototipo è:
\begin{prototype}{unistd.h}{int dup(int oldfd)}
Crea una copia del file descriptor \param{oldfd}.
\bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
- \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
- \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
+ \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
+ \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
descriptor aperti.
\end{errlist}}
\end{prototype}
La funzione ritorna, come \func{open}, il primo file descriptor libero. Il
-file descriptor è una copia esatta del precedente ed entrambi possono essere
+file descriptor è una copia esatta del precedente ed entrambi possono essere
interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
-può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
+può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
semplicemente quello di copiare il valore nella struttura
-\struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
+\struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
-file descriptor è \textsl{duplicato}, da cui il nome della funzione.
+file descriptor è \textsl{duplicato}, da cui il nome della funzione.
\begin{figure}[htb]
\centering \includegraphics[width=14cm]{img/filedup}
Si noti che per quanto illustrato in fig.~\ref{fig:file_dup} i file descriptor
duplicati condivideranno eventuali lock, \textit{file status flag}, e
posizione corrente. Se ad esempio si esegue una \func{lseek} per modificare la
-posizione su uno dei due file descriptor, essa risulterà modificata anche
-sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
+posizione su uno dei due file descriptor, essa risulterà modificata anche
+sull'altro (dato che quello che viene modificato è lo stesso campo nella voce
della \textit{file table} a cui entrambi fanno riferimento). L'unica
-differenza fra due file descriptor duplicati è che ciascuno avrà il suo
+differenza fra due file descriptor duplicati è che ciascuno avrà il suo
\textit{file descriptor flag}; a questo proposito va specificato che nel caso
di \func{dup} il flag di \textit{close-on-exec} \itindex{close-on-exec} (vedi
sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}) viene sempre cancellato
nella copia.
-L'uso principale di questa funzione è per la redirezione dell'input e
+L'uso principale di questa funzione è per la redirezione dell'input e
dell'output fra l'esecuzione di una \func{fork} e la successiva \func{exec};
-diventa così possibile associare un file (o una pipe) allo standard input o
+diventa così possibile associare un file (o una pipe) allo standard input o
allo standard output (torneremo sull'argomento in sez.~\ref{sec:ipc_pipe_use},
quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
-il file che si vuole sostituire, cosicché il suo file descriptor possa esser
+il file che si vuole sostituire, cosicché il suo file descriptor possa esser
restituito alla chiamata di \func{dup}, come primo file descriptor
disponibile.
-Dato che questa è l'operazione più comune, è prevista una diversa versione
+Dato che questa è l'operazione più comune, è prevista una diversa versione
della funzione, \funcd{dup2}, che permette di specificare esplicitamente
-qual è il valore di file descriptor che si vuole avere come duplicato; il suo
-prototipo è:
+qual è il valore di file descriptor che si vuole avere come duplicato; il suo
+prototipo è:
\begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
Rende \param{newfd} una copia del file descriptor \param{oldfd}.
\bodydesc{La funzione ritorna il nuovo file descriptor in caso di successo e
- $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
+ \item[\errcode{EBADF}] \param{oldfd} non è un file aperto o \param{newfd} ha
un valore fuori dall'intervallo consentito per i file descriptor.
- \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
+ \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
descriptor aperti.
\end{errlist}}
\end{prototype}
-\noindent e qualora il file descriptor \param{newfd} sia già aperto (come
+\noindent e qualora il file descriptor \param{newfd} sia già aperto (come
avviene ad esempio nel caso della duplicazione di uno dei file standard) esso
-sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
+sarà prima chiuso e poi duplicato (così che il file duplicato sarà connesso
allo stesso valore per il file descriptor).
-La duplicazione dei file descriptor può essere effettuata anche usando la
+La duplicazione dei file descriptor può essere effettuata anche usando la
funzione di controllo dei file \func{fcntl} (che esamineremo in
sez.~\ref{sec:file_fcntl}) con il parametro \const{F\_DUPFD}. L'operazione ha
la sintassi \code{fcntl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
\param{newfd} diventa equivalente a \func{dup}.
La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
- diversi codici di errore.} è che \func{dup2} chiude il file descriptor
-\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
+ diversi codici di errore.} è che \func{dup2} chiude il file descriptor
+\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
file descriptor libero di valore uguale o maggiore di \param{newfd} (e se
-\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
+\param{newfd} è aperto la duplicazione avverrà su un altro file descriptor).
\subsection{Le funzioni \func{openat}, \func{mkdirat} e affini}
\label{sec:file_openat}
-Un problema che si pone con l'uso della funzione \func{open}, così come per
-molte altre funzioni che accettano come argomenti dei pathname relativi, è
+Un problema che si pone con l'uso della funzione \func{open}, così come per
+molte altre funzioni che accettano come argomenti dei pathname relativi, è
che, quando un pathname relativo non fa riferimento alla directory di lavoro
-corrente, è possibile che alcuni dei suoi componenti vengano modificati in
-parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
+corrente, è possibile che alcuni dei suoi componenti vengano modificati in
+parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
di una \itindex{race~condition} \textit{race condition}.
-Inoltre come già accennato, la directory di lavoro corrente è una proprietà
+Inoltre come già accennato, la directory di lavoro corrente è una proprietà
del singolo processo; questo significa che quando si lavora con i
-\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
+\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
molti casi in cui sarebbe invece utile che ogni singolo \itindex{thread}
\textit{thread} avesse la sua directory di lavoro.
-Per risolvere questi problemi, riprendendo una interfaccia già presente in
+Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
\func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
funzioni, contraddistinte dal suffisso \texttt{at}, che permettono l'apertura
di un file (o le rispettive altre operazioni) usando un pathname relativo ad
-una directory specificata.\footnote{l'introduzione è avvenuta su proposta
+una directory specificata.\footnote{l'introduzione è avvenuta su proposta
dello sviluppatore principale delle \acr{glibc} Urlich Drepper; le
corrispondenti system call sono state inserite nel kernel ufficiale a
partire dalla versione 2.6.16, in precedenza era disponibile una emulazione
che, sia pure con prestazioni inferiori, funzionava facendo ricorso all'uso
del filesystem \textit{proc} con l'apertura del file attraverso il
riferimento a pathname del tipo di
- \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
+ \texttt{/proc/self/fd/dirfd/relative\_path}.} Benché queste funzioni non
siano presenti negli standard tradizionali esse sono state adottate da vari
Unix\footnote{oltre a Linux e Solaris sono presenti in vari BSD.} fino ad
essere incluse nella recente revisione (la POSIX.1-2008) dello standard
-POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
+POSIX.1; con le \acr{glibc} per l'accesso a queste funzioni è necessario
definire la macro \macro{\_ATFILE\_SOURCE}.
L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei pathname relativi che verranno usati in
-seguito, dopo di che si dovrà passare il relativo file descriptor alle varie
+sarà la base della risoluzione dei pathname relativi che verranno usati in
+seguito, dopo di che si dovrà passare il relativo file descriptor alle varie
funzioni che useranno quella directory come punto di partenza per la
risoluzione.\footnote{in questo modo, anche quando si lavora con i
- \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
+ \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
diversa per ciascuno di essi.}
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
della directory di partenza una sola volta (nell'apertura iniziale) e non
tutte le volte che si deve accedere a ciascun file che essa contiene.
-La sintassi generale di queste nuove funzioni è che esse prevedono come primo
+La sintassi generale di queste nuove funzioni è che esse prevedono come primo
argomento il file descriptor della directory da usare come base, mentre gli
argomenti successivi restano identici a quelli della corrispondente funzione
-ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
+ordinaria; ad esempio nel caso di \funcd{openat} avremo che essa è definita
come:
\begin{functions}
\headdecl{fcntl.h}
Apre un file usando come directory di lavoro corrente \param{dirfd}.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{open}, ed in più:
+ errore di \func{open}, ed in più:
\begin{errlist}
- \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
\param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
-Il comportamento delle nuove funzioni è del tutto analogo a quello delle
+Il comportamento delle nuove funzioni è del tutto analogo a quello delle
corrispettive classiche, con la sola eccezione del fatto che se fra i loro
-argomenti si utilizza un pathname relativo questo sarà risolto rispetto alla
+argomenti si utilizza un pathname relativo questo sarà risolto rispetto alla
directory indicata da \param{dirfd}; qualora invece si usi un pathname
-assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
+assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
\param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
- come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
- pertanto se la si vuole usare occorrerà includere comunque questo file,
- anche per le funzioni che non sono definite in esso.} la risoluzione sarà
+ come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
+ pertanto se la si vuole usare occorrerà includere comunque questo file,
+ anche per le funzioni che non sono definite in esso.} la risoluzione sarà
effettuata rispetto alla directory di lavoro corrente del processo.
-Così come il comportamento, anche i valori di ritorno e le condizioni di
+Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
-errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
-particolare si avrà un errore di \errcode{EBADF} se esso non è un file
+errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
+particolare si avrà un errore di \errcode{EBADF} se esso non è un file
descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa riferimento
ad una directory.\footnote{tranne il caso in cui si sia specificato un
pathname assoluto, nel qual caso, come detto, il valore di \param{dirfd}
- sarà completamente ignorato.}
+ sarà completamente ignorato.}
In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte
con questa nuova interfaccia, con a fianco la corrispondente funzione
-classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
+classica.\footnote{in realtà, come visto in sez.~\ref{sec:file_temp_file}, le
funzioni \func{utimes} e \func{lutimes} non sono propriamente le
corrispondenti di \func{utimensat}, dato che questa ha una maggiore
precisione nella indicazione dei tempi dei file.} La gran parte di queste
della corrispondente funzione classica viene anteposto
l'argomento \param{dirfd}.\footnote{non staremo pertanto a riportarle una per
una.} Per una parte di queste, indicate dal contenuto della omonima colonna
-di tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è
+di tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è
prevista anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
\begin{table}[htb]
\label{tab:file_atfunc_corr}
\end{table}
-\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
+\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
utilizzabile solo a partire dal kernel 2.6.18.}
Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
-\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
+\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
un meccanismo con cui modificarne il comportamento nel caso si stia operando
-su un link simbolico, così da poter scegliere se far agire la funzione
+su un link simbolico, così da poter scegliere se far agire la funzione
direttamente sullo stesso o sul file da esso referenziato. Dato che in certi
-casi esso può fornire ulteriori indicazioni per modificare il comportamento
+casi esso può fornire ulteriori indicazioni per modificare il comportamento
delle funzioni, \param{flags} deve comunque essere passato come maschera
binaria, ed impostato usando i valori delle appropriate costanti
\texttt{AT\_*}, definite in \texttt{fcntl.h}.
Come esempio di questo secondo tipo di funzioni possiamo considerare
-\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
-che \func{lchown}; il suo prototipo è:
+\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
+che \func{lchown}; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{fcntl.h}
\funcdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
group, int flags)}
- .Modifica la proprietà di un file.
+ .Modifica la proprietà di un file.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{chown}, ed in più:
+ errore di \func{chown}, ed in più:
\begin{errlist}
- \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
\param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
In questo caso il valore di \param{flags} stabilisce il comportamento della
funzione quando la si applica ad un link simbolico, e l'unico valore
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
+utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
- link simbolici, essendo questo però il comportamento adottato per un valore
+ link simbolici, essendo questo però il comportamento adottato per un valore
nullo di \param{flags} questo valore non viene mai usato.} che se impostato
indica alla funzione di non eseguire la dereferenziazione di un eventuale link
simbolico, facendo comportare \func{fchownat} come \func{lchown} invece che
Come accennato fra tutte quelle marcate in tab.~\ref{tab:file_atfunc_corr}
solo due funzioni possono usare l'argomento \param{flags} con valori diversi
-da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
-il suo prototipo è:
+da \const{AT\_SYMLINK\_NOFOLLOW}, la prima di queste è \funcd{faccessat}, ed
+il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int faccessat(int dirfd, const char *path, int mode, int flags)}
Controlla i permessi di accesso.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
- errore di \func{access}, ed in più:
+ errore di \func{access}, ed in più:
\begin{errlist}
- \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
\param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
La funzione esegue lo stesso controllo di accesso effettuabile con
-\func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
+\func{access}, ma si può utilizzare l'argomento \param{flags} per modificarne
il comportamento rispetto a quello ordinario di \func{access}. In questo caso
-esso può essere specificato come maschera binaria di due valori:
+esso può essere specificato come maschera binaria di due valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
\item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo
dei permessi usando l'\textsl{user-ID effettivo} invece di quello reale (il
permessi direttamente sugli stessi.
\end{basedescript}
-La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
-argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
+La seconda eccezione è \func{unlinkat}, in questo caso l'ulteriore
+argomento \param{flags} viene utilizzato perché tramite esso la funzione possa
comportarsi sia come analogo di \func{unlink} che di \func{rmdir}; il suo
-prototipo è:
+prototipo è:
\begin{functions}
\headdecl{fcntl.h}
\funcdecl{int unlinkat(int dirfd, const char *pathname, int flags)}
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
errore di \func{unlink} o di \func{rmdir} a seconda del valore di
- \param{flags}, ed in più:
+ \param{flags}, ed in più:
\begin{errlist}
- \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
+ \item[\errcode{EBADF}] \param{dirfd} non è un file descriptor valido.
\item[\errcode{EINVAL}] \param{flags} non ha un valore valido.
- \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
+ \item[\errcode{ENOTDIR}] \param{pathname} è un pathname relativo, ma
\param{dirfd} fa riferimento ad un file.
\end{errlist}}
\end{functions}
-Di default il comportamento di \func{unlinkat} è equivalente a quello che
+Di default il comportamento di \func{unlinkat} è equivalente a quello che
avrebbe \func{unlink} applicata a \param{pathname}, fallendo in tutti i casi
-in cui questo è una directory, se però si imposta \param{flags} al valore di
-\const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
- essendo questo l'unico flag disponibile per questa funzione, lo si può
- assegnare direttamente.} essa si comporterà come \func{rmdir}, in tal
-caso \param{pathname} deve essere una directory, che sarà rimossa qualora
+in cui questo è una directory, se però si imposta \param{flags} al valore di
+\const{AT\_REMOVEDIR},\footnote{anche se \param{flags} è una maschera binaria,
+ essendo questo l'unico flag disponibile per questa funzione, lo si può
+ assegnare direttamente.} essa si comporterà come \func{rmdir}, in tal
+caso \param{pathname} deve essere una directory, che sarà rimossa qualora
risulti vuota.
\label{sec:file_fcntl}
Oltre alle operazioni base esaminate in sez.~\ref{sec:file_base_func} esistono
-tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
+tutta una serie di operazioni ausiliarie che è possibile eseguire su un file
descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
-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
+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}
\textit{file locking} (vedi sez.~\ref{sec:file_locking}).}
-Per queste operazioni di manipolazione e di controllo delle varie proprietà e
+Per queste operazioni di manipolazione e di controllo delle varie proprietà e
caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl},
-il cui prototipo è:
+il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{fcntl.h}
sul file \param{fd}.
\bodydesc{La funzione ha valori di ritorno diversi a seconda
- dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
- il codice dell'errore è restituito nella variabile \var{errno}; i codici
- possibili dipendono dal tipo di operazione, l'unico valido in generale è:
+ dell'operazione. In caso di errore il valore di ritorno è sempre $-1$ ed
+ il codice dell'errore è restituito nella variabile \var{errno}; i codici
+ possibili dipendono dal tipo di operazione, l'unico valido in generale è:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un file aperto.
+ \item[\errcode{EBADF}] \param{fd} non è un file aperto.
\end{errlist}}
\end{functions}
-Il primo argomento della funzione è sempre il numero di file descriptor
+Il primo argomento della funzione è sempre il numero di file descriptor
\var{fd} su cui si vuole operare. Il comportamento di questa funzione, il
numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori
sono determinati dal valore dell'argomento \param{cmd} che in sostanza
corrisponde all'esecuzione di un determinato \textsl{comando}; in
sez.~\ref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl}
per la duplicazione dei file descriptor, una lista di tutti i possibili valori
-per \var{cmd} è riportata di seguito:
+per \var{cmd} è riportata di seguito:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore
maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il
nuovo file descriptor in caso di successo e $-1$ in caso di errore. Gli
- errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
- del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
+ errori possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore
+ del massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il
massimo numero di descrittori consentito.
\item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al
- valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
+ valore specificato con \param{arg}. Al momento l'unico bit usato è quello di
\itindex{close-on-exec} \textit{close-on-exec}, identificato dalla costante
\const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella
esecuzione di una \func{exec} (vedi sez.~\ref{sec:proc_exec}). Ritorna un
valore nullo in caso di successo e $-1$ in caso di errore.
\item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di
- \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
+ \param{fd} o $-1$ in caso di errore; se \const{FD\_CLOEXEC} è impostato i
file descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti
(il comportamento predefinito) restano aperti.
\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in
- caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
+ caso di successo o $-1$ in caso di errore; permette cioè di rileggere quei
bit impostati da \func{open} all'apertura del file che vengono memorizzati
(quelli riportati nella prima e terza sezione di
tab.~\ref{tab:file_open_flags}).
\item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da
\param{lock}, sovrascrivendo la struttura da esso puntata con il risultato;
ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Questa
- funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
+ funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}.
\item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto
- specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
+ specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da
qualcun altro ritorna immediatamente restituendo $-1$ e imposta \var{errno} a
\errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore
- nullo. Questa funzionalità è trattata in dettaglio in
+ nullo. Questa funzionalità è trattata in dettaglio in
sez.~\ref{sec:file_posix_lock}.
\item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che
la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se
l'attesa viene interrotta da un segnale la funzione restituisce $-1$ e
imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore
- nullo. Questa funzionalità è trattata in dettaglio in
+ nullo. Questa funzionalità è trattata in dettaglio in
sez.~\ref{sec:file_posix_lock}.
\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o
l'identificatore del \itindex{process~group} \textit{process
group}\footnote{i \itindex{process~group} \textit{process group} sono
(vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel
- controllo di sessione; a ciascuno di essi è associato un identificatore
- (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
+ controllo di sessione; a ciascuno di essi è associato un identificatore
+ (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione
dei segnali \const{SIGIO}\footnote{o qualunque altro segnale alternativo
impostato con \const{F\_FSETSIG}.} per gli eventi associati al file
descriptor \param{fd}\footnote{il segnale viene usato sia per il
caso di errore viene restituito $-1$.
\item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg},
l'identificatore del processo o del \itindex{process~group} \textit{process
- group} che riceverà i segnali \const{SIGIO} e \const{SIGURG} per gli
+ group} che riceverà i segnali \const{SIGIO} e \const{SIGURG} per gli
eventi associati al file descriptor \param{fd}, ritorna un valore nullo in
caso di successo o $-1$ in caso di errore. Come per \const{F\_GETOWN}, per
impostare un \itindex{process~group} \textit{process group} si deve usare
\item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci
sono dati disponibili in ingresso su un file descriptor aperto ed impostato
per l'I/O asincrono (si veda sez.~\ref{sec:file_asyncronous_io}). Il valore 0
- indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
- zero indica il segnale richiesto, (che può essere anche lo stesso
+ indica il valore predefinito (che è \const{SIGIO}), un valore diverso da
+ zero indica il segnale richiesto, (che può essere anche lo stesso
\const{SIGIO}). In caso di errore ritorna $-1$.
\item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa
possibile effettuare I/O sul file descriptor in caso di I/O asincrono,
ritorna un valore nullo in caso di successo o $-1$ in caso di errore. Il
valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
valore diverso da zero (compreso lo stesso \const{SIGIO}) specifica il
- segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
+ segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è
installato il gestore del segnale come \var{sa\_sigaction} usando
\const{SA\_SIGINFO}, (vedi sez.~\ref{sec:sig_sigaction}), di rendere
disponibili al gestore informazioni ulteriori riguardo il file che ha
\const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di
Linux.}
\item[\const{F\_SETLEASE}] imposta o rimuove un \index{file!lease}
- \textit{file lease}\footnote{questa è una nuova funzionalità, specifica di
+ \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
qualora un altro processo cerca di eseguire una \func{open} o una
\func{truncate} su di esso.} sul file descriptor \var{fd} a seconda del
- valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
+ valore del terzo argomento, che in questo caso è un \ctyp{int}, ritorna un
valore nullo in caso di successo o $-1$ in caso di errore. Questa
- funzionalità avanzata è trattata in dettaglio in
+ funzionalità avanzata è trattata in dettaglio in
sez.~\ref{sec:file_asyncronous_lease}.
\item[\const{F\_GETLEASE}] restituisce il tipo di \index{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
+ argomento può essere omesso. Questa funzionalità avanzata è trattata in
dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
\item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene
riportata al processo chiamante, tramite il segnale \const{SIGIO} (o altro
segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o
direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file
in essa contenuti; ritorna un valore nullo in caso di successo o $-1$ in caso
- di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
- 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
+ di errore. Questa funzionalità avanzata, disponibile dai kernel della serie
+ 2.4.x, è trattata in dettaglio in sez.~\ref{sec:file_asyncronous_lease}.
\end{basedescript}
-La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
+La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per
poter essere affrontate in tutti i loro aspetti a questo punto; saranno
-pertanto riprese più avanti quando affronteremo le problematiche ad esse
+pertanto riprese più avanti quando affronteremo le problematiche ad esse
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
-sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
+sez.~\ref{sec:file_locking}). L'uso di questa funzione con i socket verrà
trattato in sez.~\ref{sec:sock_ctrl_func}.
Si tenga presente infine che quando si usa la funzione per determinare le
-modalità di accesso con cui è stato aperto il file (attraverso l'uso del
-comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
-\textit{file status flag} che si è ottenuto. Infatti la definizione corrente
-di quest'ultimo non assegna bit separati alle tre diverse modalità
+modalità di accesso con cui è stato aperto il file (attraverso l'uso del
+comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
+\textit{file status flag} che si è ottenuto. Infatti la definizione corrente
+di quest'ultimo non assegna bit separati alle tre diverse modalità
\const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
-motivo il valore della modalità di accesso corrente si ottiene eseguendo un
+motivo il valore della modalità di accesso corrente si ottiene eseguendo un
AND binario del valore di ritorno di \func{fcntl} con la maschera
\const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
accesso dal \textit{file status flag}.
\subsection{La funzione \func{ioctl}}
\label{sec:file_ioctl}
-Benché il concetto di \textit{everything is a file} si sia dimostrato molto
-valido anche per l'interazione con i dispositivi più vari, fornendo una
+Benché il concetto di \textit{everything is a file} si sia dimostrato molto
+valido anche per l'interazione con i dispositivi più vari, fornendo una
interfaccia che permette di interagire con essi tramite le stesse funzioni
usate per i normali file di dati, esisteranno sempre caratteristiche
-peculiari, specifiche dell'hardware e della funzionalità che ciascun
-dispositivo può provvedere, che non possono venire comprese in questa
-interfaccia astratta (un caso tipico è l'impostazione della velocità di una
+peculiari, specifiche dell'hardware e della funzionalità che ciascun
+dispositivo può provvedere, che non possono venire comprese in questa
+interfaccia astratta (un caso tipico è l'impostazione della velocità di una
porta seriale, o le dimensioni di un framebuffer).
-Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
+Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
specifiche di ogni dispositivo particolare, usando come riferimento il solito
-file descriptor. Il prototipo di questa funzione è:
+file descriptor. Il prototipo di questa funzione è:
\begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
Esegue l'operazione di controllo specificata da \param{request} sul file
descriptor \param{fd}.
\bodydesc{La funzione nella maggior parte dei casi ritorna 0, alcune
- operazioni usano però il valore di ritorno per restituire informazioni. In
- caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
+ operazioni usano però il valore di ritorno per restituire informazioni. In
+ caso di errore viene sempre restituito $-1$ ed \var{errno} assumerà uno dei
valori:
\begin{errlist}
- \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
- dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
+ \item[\errcode{ENOTTY}] il file \param{fd} non è associato con un
+ dispositivo, o la richiesta non è applicabile all'oggetto a cui fa
riferimento \param{fd}.
\item[\errcode{EINVAL}] gli argomenti \param{request} o \param{argp} non sono
validi.
La funzione serve in sostanza come meccanismo generico per fare tutte quelle
operazioni che non rientrano nell'interfaccia ordinaria della gestione dei
-file e che non è possibile effettuare con le funzioni esaminate finora. La
+file e che non è possibile effettuare con le funzioni esaminate finora. La
funzione richiede che si passi come primo argomento un file descriptor
regolarmente aperto, e l'operazione da compiere viene selezionata attraverso
il valore dell'argomento \param{request}. Il terzo argomento dipende
-dall'operazione prescelta; tradizionalmente è specificato come \code{char *
+dall'operazione prescelta; tradizionalmente è specificato come \code{char *
argp}, da intendersi come puntatore ad un area di memoria
generica,\footnote{all'epoca della creazione di questa funzione infatti ancora
- non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
-essere omesso, e per altre è un semplice intero.
+ non era stato introdotto il tipo \ctyp{void}.} ma per certe operazioni può
+essere omesso, e per altre è un semplice intero.
Normalmente la funzione ritorna zero in caso di successo e $-1$ in caso di
errore, ma per alcune operazione il valore di ritorno, che nel caso viene
-impostato ad un valore positivo, può essere utilizzato come parametro di
-uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
+impostato ad un valore positivo, può essere utilizzato come parametro di
+uscita. È più comune comunque restituire i risultati all'indirizzo puntato dal
terzo argomento.
-Data la genericità dell'interfaccia non è possibile classificare in maniera
+Data la genericità dell'interfaccia non è possibile classificare in maniera
sistematica le operazioni che si possono gestire con \func{ioctl}, un breve
-elenco di alcuni esempi di esse è il seguente:
+elenco di alcuni esempi di esse è il seguente:
\begin{itemize*}
\item il cambiamento dei font di un terminale.
\item l'esecuzione di una traccia audio di un CDROM.
\item i comandi di avanti veloce e riavvolgimento di un nastro.
\item il comando di espulsione di un dispositivo rimovibile.
-\item l'impostazione della velocità trasmissione di una linea seriale.
+\item l'impostazione della velocità trasmissione di una linea seriale.
\item l'impostazione della frequenza e della durata dei suoni emessi dallo
speaker.
\item l'impostazione degli attributi dei file su un filesystem
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
definizione delle macro da usare per \param{request}, in modo da essere
sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi
- causi al più un errore. Si veda il capitolo quinto di \cite{LinDevDri} per
- una trattazione dettagliata dell'argomento.} così che la richiesta di
+ causi al più un errore. Si veda il capitolo quinto di \cite{LinDevDri} per
+ una trattazione dettagliata dell'argomento.} così che la richiesta di
operazioni relative ad altri dispositivi usualmente provoca il ritorno della
funzione con una condizione di errore, in alcuni casi, relativi a valori
assegnati prima che questa differenziazione diventasse pratica corrente, si
potrebbero usare valori validi anche per il dispositivo corrente, con effetti
imprevedibili o indesiderati.
-Data la assoluta specificità della funzione, il cui comportamento varia da
-dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
+Data la assoluta specificità della funzione, il cui comportamento varia da
+dispositivo a dispositivo, non è possibile fare altro che dare una descrizione
sommaria delle sue caratteristiche; torneremo ad esaminare in
seguito\footnote{per l'uso di \func{ioctl} con i socket si veda
sez.~\ref{sec:sock_ctrl_func}.} quelle relative ad alcuni casi specifici (ad
-esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
+esempio la gestione dei terminali è effettuata attraverso \func{ioctl} in
quasi tutte le implementazioni di Unix), qui riportiamo solo l'elenco delle
operazioni che sono predefinite per qualunque file,\footnote{in particolare
queste operazioni sono definite nel kernel a livello generale, e vengono
\textit{close-on-exec} sul file, in questo caso, essendo usata come
operazione logica, \func{ioctl} non richiede un terzo argomento, il cui
eventuale valore viene ignorato.
-\item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
+\item[\const{FIOASYNC}] abilita o disabilita la modalità di I/O asincrono sul
file (vedi sez.~\ref{sec:file_asyncronous_operation}); il terzo argomento
- deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
+ deve essere un puntatore ad un intero (cioè di tipo \texttt{const int *})
che contiene un valore logico (un valore nullo disabilita, un valore non
nullo abilita).
-\item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
- bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
+\item[\const{FIONBIO}] abilita o disabilita sul file l'I/O in modalità non
+ bloccante; il terzo argomento deve essere un puntatore ad un intero (cioè di
tipo \texttt{const int *}) che contiene un valore logico (un valore nullo
disabilita, un valore non nullo abilita).
-\item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
+\item[\const{FIOSETOWN}] imposta il processo che riceverà i segnali
\const{SIGURG} e \const{SIGIO} generati sul file; il terzo argomento deve
- essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
+ essere un puntatore ad un intero (cioè di tipo \texttt{const int *}) il cui
valore specifica il PID del processo.
-\item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
+\item[\const{FIOGETOWN}] legge il processo che riceverà i segnali
\const{SIGURG} e \const{SIGIO} generati sul file; il terzo argomento deve
- essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
+ essere un puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà
scritto il PID del processo.
\item[\const{FIONREAD}] legge il numero di byte disponibili in lettura sul
- file descriptor;\footnote{questa operazione è disponibile solo su alcuni
+ file descriptor;\footnote{questa operazione è disponibile solo su alcuni
file descriptor, in particolare sui socket (vedi
sez.~\ref{sec:sock_ioctl_IP}) o sui file descriptor di \textit{epoll}
(vedi sez.~\ref{sec:file_epoll}).} il terzo argomento deve essere un
- puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
+ puntatore ad un intero (cioè di tipo \texttt{int *}) su cui sarà restituito
il valore.
\item[\const{FIOQSIZE}] restituisce la dimensione corrente di un file o di una
directory, mentre se applicata ad un dispositivo fallisce con un errore di
\errcode{ENOTTY}; il terzo argomento deve essere un puntatore ad un intero
- (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
+ (cioè di tipo \texttt{int *}) su cui sarà restituito il valore.
\end{basedescript}
% TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
-Si noti però come la gran parte di queste operazioni specifiche dei file (per
+Si noti però come la gran parte di queste operazioni specifiche dei file (per
essere precisi le prime sei dell'elenco) siano effettuabili in maniera
generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
-molto simili e la presenza di questa sovrapposizione è principalmente dovuta
+molto simili e la presenza di questa sovrapposizione è principalmente dovuta
al fatto che alle origini di Unix i progettisti considerarono che era
necessario trattare diversamente rispetto alle operazione di controllo delle
-modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
+modalità di I/O file e dispositivi usando \func{fcntl} per i primi e
\func{ioctl} per i secondi;\footnote{all'epoca tra l'altro i dispositivi che
usavano \func{ioctl} erano sostanzialmente solo i terminali, il che spiega
- l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
+ l'uso comune di \errcode{ENOTTY} come codice di errore.} oggi non è più così
ma le due funzioni sono rimaste.
% TODO trovare qualche posto per la eventuale documentazione delle seguenti
-% (bassa/bassissima priorità)
+% (bassa/bassissima priorità)
% EXT4_IOC_MOVE_EXT (dal 2.6.31)
\documentclass[a4paper,11pt,twoside]{book}
\usepackage{ae,aecompl}
\usepackage[T1]{fontenc}
-\usepackage[latin1]{inputenc}
+\usepackage[utf8]{inputenc}
%\usepackage[tex4ht, bookmarks=true]{hyperref}
\usepackage[bookmarks=true,plainpages=false,pdfpagelabels,hyperfootnotes=false]{hyperref}
\usepackage{makeidx}
\chapter{L'architettura del sistema}
\label{cha:intro_unix}
-In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
-cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
-potremo fornire una base di comprensione mirata a sottolineare le peculiarità
-del sistema che sono più rilevanti per quello che riguarda la programmazione.
+In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
+cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
+potremo fornire una base di comprensione mirata a sottolineare le peculiarità
+del sistema che sono più rilevanti per quello che riguarda la programmazione.
Dopo un'introduzione sulle caratteristiche principali di un sistema di tipo
Unix passeremo ad illustrare alcuni dei concetti base dell'architettura di
\label{sec:intro_unix_struct}
In questa prima sezione faremo una breve panoramica sull'architettura del
-sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
+sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
saltare questa sezione.
\subsection{Concetti base}
\label{sec:intro_base_concept}
-Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
+Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
alle risorse hardware tramite delle richieste a quest'ultimo.
Fin dall'inizio uno Unix si presenta come un sistema operativo
-\textit{multitasking}, cioè in grado di eseguire contemporaneamente più
-programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
-una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà,
+\textit{multitasking}, cioè in grado di eseguire contemporaneamente più
+programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
+una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà,
almeno per macchine a processore singolo, i programmi vengono eseguiti
singolarmente a rotazione.
%computer (e quindi per un uso personale), sui quali l'hardware (allora
%limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
-I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
+I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
caratteristiche dei processori moderni come la gestione hardware della memoria
-e la modalità protetta. In sostanza con i processori moderni si può
+e la modalità protetta. In sostanza con i processori moderni si può
disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
-zone di memoria fisica. Quello che succede è che il kernel è il solo
-programma ad essere eseguito in modalità privilegiata, con il completo accesso
-all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
+zone di memoria fisica. Quello che succede è che il kernel è il solo
+programma ad essere eseguito in modalità privilegiata, con il completo accesso
+all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
e non possono accedere direttamente alle zone di memoria riservate o alle
porte di input/output.
Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
-priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
+priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
- multitasking}). Questo verrà comunque eseguito in modalità protetta; quando
-necessario il processo potrà accedere alle risorse hardware soltanto
+ multitasking}). Questo verrà comunque eseguito in modalità protetta; quando
+necessario il processo potrà accedere alle risorse hardware soltanto
attraverso delle opportune chiamate al sistema che restituiranno il controllo
al kernel.
La memoria viene sempre gestita dal kernel attraverso il meccanismo della
\index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
-sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
-gestione della memoria, si incaricherà di rimappare automaticamente sulla
+sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
+gestione della memoria, si incaricherà di rimappare automaticamente sulla
memoria disponibile, salvando su disco quando necessario (nella cosiddetta
area di \textit{swap}) le pagine di memoria in eccedenza.
Le periferiche infine vengono viste in genere attraverso un'interfaccia
astratta che permette di trattarle come fossero file, secondo il concetto per
cui \textit{everything is a file}, su cui torneremo in dettaglio in
-cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
+cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
-il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
+il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
\subsection{Il kernel e il sistema}
\label{sec:intro_kern_and_sys}
-Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
+Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
quello della distinzione fra il cosiddetto \textit{user space}, che
contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
-\textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
-programma vede sé stesso come se avesse la piena disponibilità della CPU e
-della memoria ed è, salvo i meccanismi di comunicazione previsti
+\textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
+programma vede sé stesso come se avesse la piena disponibilità della CPU e
+della memoria ed è, salvo i meccanismi di comunicazione previsti
dall'architettura, completamente ignaro del fatto che altri programmi possono
essere messi in esecuzione dal kernel.
-Per questa separazione non è possibile ad un singolo programma disturbare
-l'azione di un altro programma o del sistema e questo è il principale motivo
-della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
+Per questa separazione non è possibile ad un singolo programma disturbare
+l'azione di un altro programma o del sistema e questo è il principale motivo
+della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
i processi non hanno di questi limiti, o che vengono per vari motivi eseguiti
al livello del kernel. Pertanto deve essere chiaro a chi programma in Unix che
-l'accesso diretto all'hardware non può avvenire se non all'interno del kernel;
+l'accesso diretto all'hardware non può avvenire se non all'interno del kernel;
al di fuori dal kernel il programmatore deve usare le opportune interfacce che
quest'ultimo fornisce allo user space.
-Per capire meglio la distinzione fra kernel space e user space si può prendere
+Per capire meglio la distinzione fra kernel space e user space si può prendere
in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
-in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
+in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
stringhe delle scarpe'', per indicare il compito, almeno apparentemente
impossibile, di far eseguire un programma a partire da un computer appena
- acceso che appunto non ne contiene nessuno; non è impossibile perché in
- realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
+ acceso che appunto non ne contiene nessuno; non è impossibile perché in
+ realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
-dopo aver inizializzato le periferiche, farà partire il primo processo,
-\cmd{init}, che è quello che a sua volta farà partire tutti i processi
-successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
+dopo aver inizializzato le periferiche, farà partire il primo processo,
+\cmd{init}, che è quello che a sua volta farà partire tutti i processi
+successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
tastiera e lo schermo della console, e quello che mette a disposizione
dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
inviare i comandi.
-E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
-sistema, non abbia in realtà niente a che fare con il kernel, ma sia
+E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
+sistema, non abbia in realtà niente a che fare con il kernel, ma sia
effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
qualunque programma di scrittura o di disegno, in user space.
-Questo significa, ad esempio, che il sistema di per sé non dispone di
+Questo significa, ad esempio, che il sistema di per sé non dispone di
primitive per tutta una serie di operazioni (come la copia di un file) che
altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona
parte delle operazioni di normale amministrazione di un sistema, come quella
%realizzare un sistema di permessi e controlli che evitano che i programmi
%eseguano accessi non autorizzati.
-Per questo motivo quando ci si riferisce al sistema nella sua interezza è
-corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
-inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
-di tutta una serie di librerie e programmi di utilità (che di norma sono
+Per questo motivo quando ci si riferisce al sistema nella sua interezza è
+corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
+inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
+di tutta una serie di librerie e programmi di utilità (che di norma sono
quelli realizzati dal progetto GNU della Free Software Foundation) che
permettono di eseguire le normali operazioni che ci si aspetta da un sistema
operativo.
Come accennato le interfacce con cui i programmi possono accedere all'hardware
vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system
- call}), si tratta di un insieme di funzioni che un programma può chiamare,
+ call}), si tratta di un insieme di funzioni che un programma può chiamare,
per le quali viene generata un'interruzione del processo passando il controllo
-dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
+dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
di operazioni interne come la gestione del multitasking e l'allocazione della
-memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i
+memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i
risultati al chiamante.
Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste
programmazione di Unix} (quella cui si accede con il comando \cmd{man 2
<nome>}) e Linux non fa eccezione. Queste sono poi state codificate da vari
standard, che esamineremo brevemente in sez.~\ref{sec:intro_standard}. Uno
-schema elementare della struttura del sistema è riportato in
+schema elementare della struttura del sistema è riportato in
fig.~\ref{fig:intro_sys_struct}.
\begin{figure}[htb]
anche tutta la serie delle ulteriori funzioni definite dai vari standard, che
sono comunemente usate nella programmazione.
-Questo è importante da capire perché programmare in Linux significa anzitutto
+Questo è importante da capire perché programmare in Linux significa anzitutto
essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C implementano direttamente
+del C, in quanto né il kernel, né il linguaggio C implementano direttamente
operazioni comuni come l'allocazione dinamica della memoria, l'input/output
bufferizzato sui file o la manipolazione delle stringhe, presenti in qualunque
programma.
dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
- embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
+ embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
togliere le parti non necessarie), e pertanto costituiscono un valido
rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
-sistema (senza la quale niente funzionerebbe) è la \textit{GNU Standard C
+sistema (senza la quale niente funzionerebbe) è la \textit{GNU Standard C
Library} (in breve \acr{glibc}), ovvero la libreria realizzata dalla Free
Software Foundation nella quale sono state implementate tutte le funzioni
essenziali definite negli standard POSIX e ANSI C, utilizzate da qualunque
programma.
Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
-\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
+\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
\cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al sistema del
-kernel; è importante avere presente questa distinzione, fondamentale dal punto
+kernel; è importante avere presente questa distinzione, fondamentale dal punto
di vista dell'implementazione, anche se poi, nella realizzazione di normali
programmi, non si hanno differenze pratiche fra l'uso di una funzione di
libreria e quello di una chiamata al sistema.
Le librerie standard del C consentono comunque, nel caso non sia presente una
specifica funzione di libreria corrispondente, di eseguire una \textit{system
call} generica tramite la funzione \funcd{syscall}, il cui prototipo,
-accessible se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
-sez.~\ref{sec:intro_gcc_glibc_std}) è:
+accessible se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/syscall.h}
da invocare, seguita dagli argomenti da passare alla stessa (che ovviamente
dipendono da quest'ultima), e restituisce il codice di ritorno della
\textit{system call} invocata. In generale un valore nullo indica il successo
-ed un valore negativo è un codice di errore che poi viene memorizzato nella
+ed un valore negativo è un codice di errore che poi viene memorizzato nella
variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
sez.~\ref{sec:sys_errors}).
\label{sec:intro_multiuser}
Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
-multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
+multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
sistemi operativi monoutente, e che occorre tenere presenti.
-Il concetto base è quello di utente (\textit{user}) del sistema, le cui
-capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
-Sono così previsti una serie di meccanismi per identificare i singoli utenti
+Il concetto base è quello di utente (\textit{user}) del sistema, le cui
+capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
+Sono così previsti una serie di meccanismi per identificare i singoli utenti
ed una serie di permessi e protezioni per impedire che utenti diversi possano
danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono
-realizzati dal kernel stesso ed attengono alle operazioni più varie, e
-torneremo su di essi in dettaglio più avanti.
+realizzati dal kernel stesso ed attengono alle operazioni più varie, e
+torneremo su di essi in dettaglio più avanti.
-Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
+Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
(descritta in dettaglio in sez.~\ref{sec:sess_login}). Questa procedura si
-incarica di verificare l'identità dell'utente, in genere attraverso la
+incarica di verificare l'identità dell'utente, in genere attraverso la
richiesta di una parola d'ordine (la \textit{password}), anche se sono
possibili meccanismi diversi.\footnote{ad esempio usando la libreria PAM
- (\textit{Pluggable Autentication Methods}) è possibile astrarre
+ (\textit{Pluggable Autentication Methods}) è possibile astrarre
completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso
delle password con meccanismi di identificazione biometrica.} Eseguita la
procedura di riconoscimento in genere il sistema manda in esecuzione un
-programma di interfaccia (che può essere la \textit{shell} su terminale o
+programma di interfaccia (che può essere la \textit{shell} su terminale o
un'interfaccia grafica) che mette a disposizione dell'utente un meccanismo con
-cui questo può impartire comandi o eseguire altri programmi.
+cui questo può impartire comandi o eseguire altri programmi.
Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
-\textit{default group}), ma può essere associato ad altri gruppi (i
+\textit{default group}), ma può essere associato ad altri gruppi (i
\textit{supplementary group}), questo permette di gestire i permessi di
-accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
+accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
-un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
-\conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
+un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
+\conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
vedremo in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
mantenute, con l'uso del \itindex{Name~Service~Switch} \textit{Name Service
Switch}, su varie tipologie di supporti, compresi server centralizzati
l'utente; torneremo in dettaglio su questo argomento in
sez.~\ref{sec:proc_perms}.
-In questo modo il sistema è in grado di tenere traccia dell'utente a cui
+In questo modo il sistema è in grado di tenere traccia dell'utente a cui
appartiene ciascun processo ed impedire ad altri utenti di interferire con
quest'ultimo. Inoltre con questo sistema viene anche garantita una forma base
di sicurezza interna in quanto anche l'accesso ai file (vedi
-sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
+sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
identificazione.
-Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
-\textit{superuser}, il cui username è di norma \textit{root}, ed il cui
-\acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
+Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
+\textit{superuser}, il cui username è di norma \textit{root}, ed il cui
+\acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
essere in grado di fare qualunque operazione; per l'utente \textit{root}
infatti i meccanismi di controllo descritti in precedenza sono
disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
\subsection{Lo standard ANSI C}
\label{sec:intro_ansiC}
-Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
+Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
Standard Institute} come prima standardizzazione del linguaggio C e per
-questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
+questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
adottato dalla ISO (\textit{International Standard Organisation}) come
-standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
+standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
anche sotto il nome di standard ISO C, o ISO C90.
-Nel 1999 è stata pubblicata una revisione dello standard C89, che viene
-usualmente indicata come C99, anche questa è stata ratificata dalla ISO con la
+Nel 1999 è stata pubblicata una revisione dello standard C89, che viene
+usualmente indicata come C99, anche questa è stata ratificata dalla ISO con la
sigla ISO/IEC 9899:1990, per cui vi si fa riferimento anche come ISO C99.
-Scopo dello standard è quello di garantire la portabilità dei programmi C fra
+Scopo dello standard è quello di garantire la portabilità dei programmi C fra
sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
anche una libreria di funzioni che devono poter essere implementate su
Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
-moderni, provvede la compatibilità con questo standard, fornendo le funzioni
+moderni, provvede la compatibilità con questo standard, fornendo le funzioni
di libreria da esso previste. Queste sono dichiarate in una serie di
\textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
funzioni, usati normalmente da un compilatore C. Per poter accedere alle
\label{tab:intro_posix_header}
\end{table}
-In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
-funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
-standard ANSI C. È possibile ottenere una conformità stretta allo standard
-(scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
+In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
+funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
+standard ANSI C. È possibile ottenere una conformità stretta allo standard
+(scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
\cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
-header file soltanto le funzionalità previste dallo standard ANSI C e a non
+header file soltanto le funzionalità previste dallo standard ANSI C e a non
usare le varie estensioni al linguaggio e al preprocessore da esso supportate.
\subsection{I tipi di dati primitivi}
\label{sec:intro_data_types}
-Uno dei problemi di portabilità del codice più comune è quello dei tipi di
+Uno dei problemi di portabilità del codice più comune è quello dei tipi di
dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
anche da una architettura ad un'altra (ad esempio passando da macchine con
-processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
+processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
\index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
\ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
associati ad alcune variabili nei sistemi Unix, dando per scontata la
-dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
-stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
+dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
+stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
sempre stato associato ad un intero a 16 bit. Storicamente questi erano
definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte
che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi
-tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
-una infinita serie di problemi di portabilità.
+tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
+una infinita serie di problemi di portabilità.
\begin{table}[htb]
\footnotesize
\subsection{Lo standard System V}
\label{sec:intro_sysv}
-Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
+Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
versione supportata ufficialmente venne rilasciata al pubblico con il nome di
Unix System V, e si fa rifermento a questa implementazione con la sigla SysV o
SV.
-Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
+Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
con aggiunte e integrazioni, ed in particolare la \textit{release 2} nel 1985,
a cui si fa riferimento con SVr2 e la \textit{release 3} nel 1986 (denominata
SVr3). Le interfacce di programmazione di queste due versioni vennero
Definition} (o SVID), pertanto nel 1995 venne rilasciata la specifica SVID 1
e nel 1986 la specifica SVID 2.
-Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
+Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
versione di System V che provvedeva un'unificazione delle interfacce
comprendente anche Xenix e BSD, questa venne denominata \textit{release 4} o
SVr4. Anche le relative interfacce vennero descritte in un documento dal
sovrainsieme delle interfacce definite dallo standard POSIX.
Nel 1992 venne rilasciata una seconda versione del sistema, la SVr4.2; l'anno
-successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
-Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
+successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
+Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
al consorzio X/Open. L'ultima versione di System V fu la SVr4.2MP rilasciata
-nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
+nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
acquisito alcuni diritti sul codice di System V, una ulteriore versione delle
\textit{System V Interface Description}, che va sotto la denominazione di SVID
4.
-Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
-specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
-compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
-includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
+Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
+specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
+compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
+includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
presenti neanche in System V) sono state tralasciate.
-Le funzionalità implementate sono principalmente il meccanismo di
+Le funzionalità implementate sono principalmente il meccanismo di
intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
\func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
\subsection{Lo ``\textsl{standard}'' BSD}
\label{sec:intro_bsd}
-Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
-di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
-mondo Unix. L'università di Berkeley proseguì nello sviluppo della base di
+Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
+di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
+mondo Unix. L'università di Berkeley proseguì nello sviluppo della base di
codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
versioni allora disponibili, fino ad arrivare al rilascio di una versione
completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
della AT\&T.
-Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
-dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
+Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
+dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
serie di estensioni e interfacce di grandissima rilevanza, come i link
simbolici, la funzione \code{select} ed i socket di rete. Per questo motivo si
fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni
nelle varie versioni succedutesi negli anni, che vanno sotto il nome di
4.3BSD, per la versione rilasciata nel 1986 e 4.4BSD, per la versione
rilasciata nel 1993, che costituisce l'ultima release ufficiale
-dell'università di Berkeley. Si tenga presente che molte di queste interfacce
+dell'università di Berkeley. Si tenga presente che molte di queste interfacce
sono presenti in derivati commerciali di BSD come SunOS. Il kernel Linux e le
\acr{glibc} forniscono tutte queste estensioni che sono state in gran parte
incorporate negli standard successivi.
\subsection{Gli standard IEEE -- POSIX}
\label{sec:intro_posix}
-Lo standard ufficiale creato da un organismo indipendente più attinente alle
+Lo standard ufficiale creato da un organismo indipendente più attinente alle
interfacce di un sistema unix-like nel suo complesso (e che concerne sia il
-kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
+kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
origine dallo standard ANSI C, che contiene come sottoinsieme, prevedendo
-ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
+ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
nuove.
-In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
+In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
libreria, e in seguito sono stati prodotti anche altri standard per la shell e
i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
\itindex{thread} \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i
-socket (1003.1g) e vari altri. In tab.~\ref{tab:intro_posix_std} è riportata
+socket (1003.1g) e vari altri. In tab.~\ref{tab:intro_posix_std} è riportata
una classificazione sommaria dei principali documenti prodotti, e di come sono
identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
-l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
+l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
parlare di POSIX.4 come di POSIX.1b.
Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
denominazioni usate diventa particolarmente faticoso; una pagina dove si
-possono recuperare varie (e di norma piuttosto intricate) informazioni è
+possono recuperare varie (e di norma piuttosto intricate) informazioni è
\href{http://www.pasc.org/standing/sd11.html}
{\textsf{http://www.pasc.org/standing/sd11.html}}.
\label{tab:intro_posix_std}
\end{table}
-Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
+Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
definiscono comunque un'interfaccia di programmazione generica e non fanno
riferimento ad una implementazione specifica (ad esempio esiste
un'implementazione di POSIX.1 anche sotto Windows NT).
Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
-POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
+POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
funzioni di \textit{pattern matching} e per la manipolazione delle
\textit{regular expression}), che vengono usate dalla shell e dai comandi di
sistema e che sono definite nello standard POSIX.2.
-Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
-ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
+Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
+ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
\itindex{thread} \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo
standard POSIX.1b per quanto riguarda i segnali e lo \itindex{scheduler}
scheduling real-time (sez.~\ref{sec:sig_real_time} e
(sez.~\ref{sec:file_asyncronous_io}).
Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la
-versione più nota, cui gran parte delle implementazioni fanno riferimento, e
-che costituisce una base per molti altri tentativi di standardizzazione, è
+versione più nota, cui gran parte delle implementazioni fanno riferimento, e
+che costituisce una base per molti altri tentativi di standardizzazione, è
stata rilasciata anche come standard internazionale con la sigla
\textsl{ISO/IEC 9945-1:1996} ed include i precedenti POSIX.1b e POSIX.1c. In
genere si fa riferimento ad essa come POSIX.1-1996.
-Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
+Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
SUSv3 (vedi sez.~\ref{sec:intro_xopen}) in un unico documento, redatto sotto
gli auspici del cosiddetto gruppo Austin che va sotto il nome di POSIX.1-2001.
-Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
+Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
presenti solo le interfacce di base, e quello XSI che richiede la presenza di
una serie di estensioni opzionali per lo standard POSIX, riprese da SUSv3.
-Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
+Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
nella definizione delle interfacce.
A questo standard sono stati aggiunti due documenti di correzione e
il TC2 del 2004, e talvolta si fa riferimento agli stessi con le sigle
POSIX.1-2003 e POSIX.1-2004.
-Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che
-dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente
-sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce
+Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che
+dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente
+sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce
opzionali dentro le specifiche di base, oltre che le solite precisazioni ed
-aggiornamenti. Anche in questo caso è prevista la suddivisione in una
-conformità di base, e delle interfacce aggiuntive.
+aggiornamenti. Anche in questo caso è prevista la suddivisione in una
+conformità di base, e delle interfacce aggiuntive.
% vedi anche man standards
Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
Unix per giungere ad un'armonizzazione delle varie implementazioni. Per far
-questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
+questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
nome di \textit{X/Open Portability Guide} a cui di norma si fa riferimento con
l'abbreviazione XPG$n$, con $n$ che indica la versione.
particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
contenente una dettagliata standardizzazione dell'interfaccia di sistema di
Unix, che venne presa come riferimento da vari produttori. Questo standard,
-detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
-POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
+detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
+POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
delle API\footnote{le \textit{Application Programmable Interface}, in sostanze
le interfacce di programmazione.} per l'interfaccia grafica (X11).
Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{X
Transport Interface}) mirante a soppiantare (senza molto successo)
l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
-rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
+rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
interfacce, header e comandi definiti) ma si fa riferimento ad essa anche come
XPG4v2.
-Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
-aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
+Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
+aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
specifiche sotto il nome di \textit{Single UNIX Specification} o SUS, l'ultima
-versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
- Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
+versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
+ Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
\textit{Unix 95}.
Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
-da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
+da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
-raccoglie produttori, utenti industriali, entità accademiche e governative.
-Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
+raccoglie produttori, utenti industriali, entità accademiche e governative.
+Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
il lavoro di standardizzazione delle varie implementazioni, rilasciando
-periodicamente nuove specifiche e strumenti per la verifica della conformità
+periodicamente nuove specifiche e strumenti per la verifica della conformità
alle stesse.
Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
Specification}, nota con la sigla SUSv2, in questa versione le interfacce
specificate salgono a 1434, e addirittura a 3030 se si considerano le stazioni
di lavoro grafiche, per le quali sono inserite pure le interfacce usate da CDE
-che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
+che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. Un
-altro nome alternativo di queste specifiche, date le origini, è XPG5.
+altro nome alternativo di queste specifiche, date le origini, è XPG5.
-Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
+Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
effettuato uno sforzo di sintesi in cui sono state comprese, nella parte di
interfacce estese, anche le interfacce definite nelle \textit{Single UNIX
- Specification}, pertanto si può fare riferimento a detto standard, quando
+ Specification}, pertanto si può fare riferimento a detto standard, quando
comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del
marchio UNIX 03 se conformi ad esso.
-Infine con la prossima revisione dello standard POSIX.1 è previsto che, come
-avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno
-le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova
+Infine con la prossima revisione dello standard POSIX.1 è previsto che, come
+avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno
+le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova
versione delle \textit{Single UNIX Specification} che verranno chiamate SUSv4.
\subsection{Il controllo di aderenza agli standard}
\label{sec:intro_gcc_glibc_std}
-In Linux, grazie alle \acr{glibc}, la conformità agli standard appena
-descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
+In Linux, grazie alle \acr{glibc}, la conformità agli standard appena
+descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
compilatore (il \texttt{gcc}) che definendo delle specifiche costanti prima
dell'inclusione dei file di dichiarazione (gli \textit{header file}) che
definiscono le funzioni di libreria.
Ad esempio se si vuole che i programmi seguano una stretta attinenza allo
-standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
-potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
+standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
+potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
standard ISO per il C. Il \texttt{gcc} possiede inoltre una specifica opzione
-per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
-dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
-(vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
-allo standard C99.\footnote{che non è al momento completa, esistono anche le
- possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
+per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
+dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
+(vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
+allo standard C99.\footnote{che non è al momento completa, esistono anche le
+ possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
l'uso delle estensioni GNU al C89, riprese poi dal C99, o \texttt{gnu89} che
- indica il dialetto GNU del C99, che diventerà il default quando la
- conformità a quest'ultimo sarà completa.}
+ indica il dialetto GNU del C99, che diventerà il default quando la
+ conformità a quest'ultimo sarà completa.}
-Per attivare le varie opzioni di controllo di aderenza agli standard è poi
+Per attivare le varie opzioni di controllo di aderenza agli standard è poi
possibile definire delle macro di preprocessore che controllano le
-funzionalità che le \acr{glibc} possono mettere a disposizione:\footnote{le
- macro sono definite nel file di dichiarazione \file{<features.h>}, ma non è
+funzionalità che le \acr{glibc} possono mettere a disposizione:\footnote{le
+ macro sono definite nel file di dichiarazione \file{<features.h>}, ma non è
necessario includerlo nei propri programmi in quanto viene automaticamente
incluso da tutti gli altri file di dichiarazione che utilizzano le macro in
esso definite; si tenga conto inoltre che il file definisce anche delle
ulteriori macro interne, in genere con un doppio prefisso di \texttt{\_},
- che non devono assolutamente mai essere usate direttamente. } questo può
-essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
+ che non devono assolutamente mai essere usate direttamente. } questo può
+essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
norma farlo inserendo gli opportuni \code{\#define} prima della inclusione dei
propri \textit{header file}.
con le opzione \texttt{-ansi} o \texttt{-std=c99}.
\item[\macro{\_POSIX\_SOURCE}] definendo questa macro (considerata obsoleta)
- si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
- versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
+ si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
+ versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
standard ISO C. Se viene anche definita con un intero positivo la macro
\macro{\_POSIX\_C\_SOURCE} lo stato di questa non viene preso in
considerazione.
\item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
- positivo si controlla quale livello delle funzionalità specificate da POSIX
- viene messa a disposizione; più alto è il valore maggiori sono le
- funzionalità:
+ positivo si controlla quale livello delle funzionalità specificate da POSIX
+ viene messa a disposizione; più alto è il valore maggiori sono le
+ funzionalità:
\begin{itemize}
- \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
+ \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
specificate nella edizione del 1990 (IEEE Standard 1003.1-1990);
\item valori maggiori o uguali a ``\texttt{2}'' rendono disponibili le
- funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
+ funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
1992 (IEEE Standard 1003.2-1992),
\item un valore maggiore o uguale a ``\texttt{199309L}'' rende disponibili
- le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
+ le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
del 1993 (IEEE Standard 1003.1b-1993);
\item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
- le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
+ le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
dello standard POSIX.1c per i \itindex{thread} \textit{thread};
\item a partire dalla versione 2.3.3 delle \acr{glibc} un valore maggiore o
- uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
+ uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
\item in futuro valori superiori potranno abilitare ulteriori estensioni.
\end{itemize}
\item[\macro{\_BSD\_SOURCE}] definendo questa macro si rendono disponibili le
- funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
- ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
- però in conflitto con le corrispondenti definite nello standard POSIX.1, in
- questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
+ funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
+ ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
+ però in conflitto con le corrispondenti definite nello standard POSIX.1, in
+ questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
la precedenza rispetto a POSIX.
A causa della natura dei conflitti con POSIX per ottenere una piena
- compatibilità con BSD4.3 può essere necessario anche usare una libreria di
- compatibilità, dato che alcune funzioni sono definite in modo diverso. In
- questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
+ compatibilità con BSD4.3 può essere necessario anche usare una libreria di
+ compatibilità, dato che alcune funzioni sono definite in modo diverso. In
+ questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
compilatore per indicargli di utilizzare le versioni nella libreria di
- compatibilità prima di quelle normali.
+ compatibilità prima di quelle normali.
Si tenga inoltre presente che la preferenza verso le versioni delle funzioni
usate da BSD viene mantenuta soltanto se nessuna delle ulteriori macro di
specificazione di standard successivi (vale a dire una fra
\macro{\_POSIX\_C\_SOURCE}, \macro{\_POSIX\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o
- \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
- hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
- definito una di queste macro, l'effetto sarà quello di dare la precedenza
+ \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
+ hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
+ definito una di queste macro, l'effetto sarà quello di dare la precedenza
alle funzioni in forma BSD.
\item[\macro{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
- funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
+ funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
precedenza.
\item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
- le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
+ le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
queste sono un sovrainsieme di quelle definite negli standard POSIX.1 e
POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che
\macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse
- anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
+ anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
estensioni a secondo dei seguenti valori:
\begin{itemize}
\item la definizione della macro ad un valore qualunque attiva le
- funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
+ funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
\item un valore di ``\texttt{500}'' o superiore rende disponibili anche le
- funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
+ funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
\item a partire dalla versione 2.2 delle \acr{glibc} un valore uguale a
- ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
- introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
+ ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
+ introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
estensioni XSI.
\end{itemize}
\item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono
- disponibili le ulteriori funzionalità necessarie ad essere conformi al
+ disponibili le ulteriori funzionalità necessarie ad essere conformi al
rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard
Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene
definita implicitamente tutte le volte che si imposta
\macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale a 500.
\item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si rendono disponibili
- le funzionalità previste per la revisione delle librerie standard del C
- introdotte con lo standard ISO C99. La macro è definita a partire dalla
+ le funzionalità previste per la revisione delle librerie standard del C
+ introdotte con lo standard ISO C99. La macro è definita a partire dalla
versione 2.1.3 delle \acr{glibc}.
Le precedenti versioni della serie 2.1.x riconoscevano le stesse estensioni
con la macro \macro{\_ISOC9X\_SOURCE}, dato che lo standard non era stato
- finalizzato, ma le \acr{glibc} avevano già un'implementazione completa che
- poteva essere attivata definendo questa macro. Benché questa sia obsoleta
+ finalizzato, ma le \acr{glibc} avevano già un'implementazione completa che
+ poteva essere attivata definendo questa macro. Benché questa sia obsoleta
viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per
- compatibilità.
+ compatibilità.
\item[\macro{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili
- tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
+ tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
specifiche presenti solo nelle \acr{glibc} ed in Linux. Gli standard coperti
sono: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, SUS.
- L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
+ L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
delle macro: \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}, \macro{\_ISOC99\_SOURCE}, inoltre
\macro{\_POSIX\_C\_SOURCE} con valore ``\texttt{200112L}'' (o
\end{basedescript}
-Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
-comunque delle estensioni e funzionalità specifiche, non presenti in altri
+Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
+comunque delle estensioni e funzionalità specifiche, non presenti in altri
standard e lo stesso vale per le \acr{glibc} stesse, che definiscono anche
-delle ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità
-deve essere evitato se si ha a cuore la portabilità, ma qualora questo non sia
+delle ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità
+deve essere evitato se si ha a cuore la portabilità, ma qualora questo non sia
un requisito esse possono rivelarsi molto utili.
-Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
+Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
essere rese esplicitamente disponibili tramite la definizione di opportune
macro di preprocessore, alcune di queste vengono attivate con la definizione
di \macro{\_GNU\_SOURCE}, mentre altre devono essere attivate esplicitamente,
con le equivalenti a 64 bit, senza dover utilizzare esplicitamente
l'interfaccia alternativa appena illustrata. In questo modo diventa
possibile usare le ordinarie funzioni per effettuare operazioni a 64 bit sui
- file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
+ file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
dopo averla definita, e saranno usate in modo trasparente le funzioni a 64
bit.}
- Se la macro non è definita o è definita con valore \texttt{32} questo
+ Se la macro non è definita o è definita con valore \texttt{32} questo
comportamento viene disabilitato, e sui sistemi a 32 bit verranno usate le
- ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
+ ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
dimensioni. Su sistemi a 64 bit invece, dove il problema non sussiste, la
macro non ha nessun effetto.
sez.~\ref{sec:file_openat}.
\item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente
- \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
+ \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
versioni \index{funzioni!rientranti} rientranti (vedi
sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si
usano i \itindex{thread} \textit{thread}. Alcune di queste funzioni sono
l'inserimento di alcuni controlli per alcune funzioni di allocazione e
manipolazione di memoria e stringhe che consentono di rilevare
automaticamente alcuni errori di \textit{buffer overflow} nell'uso delle
- stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
+ stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
delle \acr{glibc} e richiede anche il supporto da parte del compilatore, che
- è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
+ è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
Le funzioni di libreria che vengono messe sotto controllo quando questa
- funzionalità viene attivata sono, al momento della stesura di queste note,
+ funzionalità viene attivata sono, al momento della stesura di queste note,
le seguenti: \func{memcpy}, \func{mempcpy}, \func{memmove}, \func{memset},
\func{stpcpy}, \func{strcpy}, \func{strncpy}, \func{strcat}, \func{strncat},
\func{sprintf}, \func{snprintf}, \func{vsprintf}, \func{vsnprintf}, e
\end{basedescript}
-Se non è stata specificata esplicitamente nessuna di queste macro il default
-assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
+Se non è stata specificata esplicitamente nessuna di queste macro il default
+assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}, e \macro{\_POSIX\_C\_SOURCE} con valore
``\texttt{200112L}'' (o ``\texttt{199506L}'' per le versioni delle \acr{glibc}
-precedenti la 2.4). Si ricordi infine che perché queste macro abbiano effetto
+precedenti la 2.4). Si ricordi infine che perché queste macro abbiano effetto
devono essere sempre definite prima dell'inclusione dei file di dichiarazione.
\label{cha:IPC}
-Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
+Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
la comunicazione fra processi. In questo capitolo affronteremo solo i
-meccanismi più elementari che permettono di mettere in comunicazione processi
+meccanismi più elementari che permettono di mettere in comunicazione processi
diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
\textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
Tralasceremo invece tutte le problematiche relative alla comunicazione
attraverso la rete (e le relative interfacce) che saranno affrontate in
-dettaglio in un secondo tempo. Non affronteremo neanche meccanismi più
+dettaglio in un secondo tempo. Non affronteremo neanche meccanismi più
complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
(\textit{Common Object Request Brocker Architecture}) che in genere sono
implementati con un ulteriore livello sopra i meccanismi elementari.
\label{sec:ipc_unix}
Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
-è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
+è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
-ne gestiscono l'uso e le varie forme in cui si è evoluto.
+ne gestiscono l'uso e le varie forme in cui si è evoluto.
\subsection{Le \textit{pipe} standard}
\label{sec:ipc_pipes}
Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
-uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
+uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
sostanza di una coppia di file descriptor\footnote{si tenga presente che
le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
-fra di loro in modo che se quanto scrive su di uno si può rileggere
-dall'altro. Si viene così a costituire un canale di comunicazione tramite i
+fra di loro in modo che se quanto scrive su di uno si può rileggere
+dall'altro. Si viene così a costituire un canale di comunicazione tramite i
due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
attraverso cui fluiscono i dati.
La funzione che permette di creare questa speciale coppia di file descriptor
-associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
+associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo prototipo è:
\begin{prototype}{unistd.h}
{int pipe(int filedes[2])}
Crea una coppia di file descriptor associati ad una \textit{pipe}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
+ errore, nel qual caso \var{errno} potrà assumere i valori \errval{EMFILE},
\errval{ENFILE} e \errval{EFAULT}.}
\end{prototype}
La funzione restituisce la coppia di file descriptor nel vettore
-\param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
-accennato concetto di funzionamento di una pipe è semplice: quello che si
+\param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
+accennato concetto di funzionamento di una pipe è semplice: quello che si
scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
nel file descriptor aperto in lettura. I file descriptor infatti non sono
connessi a nessun file reale, ma, come accennato in
sez.~\ref{sec:file_sendfile_splice}, ad un buffer nel kernel, la cui
-dimensione è specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
-sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
+dimensione è specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
+sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
illustrato in fig.~\ref{fig:ipc_pipe_singular}, in cui sono illustrati i due
capi della pipe, associati a ciascun file descriptor, con le frecce che
indicano la direzione del flusso dei dati.
\end{figure}
Chiaramente creare una pipe all'interno di un singolo processo non serve a
-niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
-riguardo al comportamento dei file descriptor nei processi figli, è immediato
+niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
+riguardo al comportamento dei file descriptor nei processi figli, è immediato
capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
processo figlio infatti condivide gli stessi file descriptor del padre,
compresi quelli associati ad una pipe (secondo la situazione illustrata in
fig.~\ref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
-capo della pipe, l'altro può leggere.
+capo della pipe, l'altro può leggere.
\begin{figure}[htb]
\centering
\label{fig:ipc_pipe_fork}
\end{figure}
-Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
-comunicazione fra processi attraverso una pipe, utilizzando le proprietà
-ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
- in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
- unidirezionale, ma in realtà questo è un limite facilmente superabile usando
- una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
+Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
+comunicazione fra processi attraverso una pipe, utilizzando le proprietà
+ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
+ in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
+ unidirezionale, ma in realtà questo è un limite facilmente superabile usando
+ una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
processi possano condividere i file descriptor della pipe, e per questo essi
-devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
-o derivare da uno stesso processo padre in cui è avvenuta la creazione della
-pipe, o, più comunemente, essere nella relazione padre/figlio.
+devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
+o derivare da uno stesso processo padre in cui è avvenuta la creazione della
+pipe, o, più comunemente, essere nella relazione padre/figlio.
-A differenza di quanto avviene con i file normali, la lettura da una pipe può
+A differenza di quanto avviene con i file normali, la lettura da una pipe può
essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
-pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
-(vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
-si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
-processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
-restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
+pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
+(vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
+si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
+processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
+restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
segnale sia ignorato o bloccato).
-La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
+La dimensione del buffer della pipe (\const{PIPE\_BUF}) ci dà inoltre un'altra
importante informazione riguardo il comportamento delle operazioni di lettura
e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
-quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
-si effettui una scrittura di una quantità di dati superiore l'operazione verrà
-effettuata in più riprese, consentendo l'intromissione di scritture effettuate
+quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
+si effettui una scrittura di una quantità di dati superiore l'operazione verrà
+effettuata in più riprese, consentendo l'intromissione di scritture effettuate
da altri processi.
\label{sec:ipc_pipe_use}
Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
-è il loro uso più comune, analogo a quello effettuato della shell, e che
+è il loro uso più comune, analogo a quello effettuato della shell, e che
consiste nell'inviare l'output di un processo (lo standard output) sull'input
di un altro. Realizzeremo il programma di esempio nella forma di un
-\textit{CGI}\footnote{un CGI (\textit{Common Gateway Interface}) è un
+\textit{CGI}\footnote{un CGI (\textit{Common Gateway Interface}) è un
programma che permette la creazione dinamica di un oggetto da inserire
all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG
di un codice a barre, specificato come argomento in ingresso.
ed il risultato dell'elaborazione deve essere presentato (con una intestazione
che ne descrive il mime-type) sullo standard output, in modo che il web-server
possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
-è in grado di visualizzarlo opportunamente.
+è in grado di visualizzarlo opportunamente.
Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
-\cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
+\cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
serve per poter effettuare la conversione della stessa immagine in formato
JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
-direzione del flusso dei dati è data dalle frecce continue.
+direzione del flusso dei dati è data dalle frecce continue.
\begin{figure}[htb]
\centering
\label{fig:ipc_pipe_use}
\end{figure}
-Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
-intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
-\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
+Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
+intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
+\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
evidente \itindex{race~condition} \textit{race condition} in caso di accesso
simultaneo a detto file.\footnote{il problema potrebbe essere superato
determinando in anticipo un nome appropriato per il file temporaneo, che
verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della
- loro esecuzione; ma a questo punto le cose non sarebbero più tanto
+ loro esecuzione; ma a questo punto le cose non sarebbero più tanto
semplici.} L'uso di una pipe invece permette di risolvere il problema in
-maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che
+maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che
non si deve scrivere su disco.
-Il programma ci servirà anche come esempio dell'uso delle funzioni di
+Il programma ci servirà anche come esempio dell'uso delle funzioni di
duplicazione dei file descriptor che abbiamo trattato in
-sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
-funzioni infatti che è possibile dirottare gli stream standard dei processi
+sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
+funzioni infatti che è possibile dirottare gli stream standard dei processi
(che abbiamo visto in sez.~\ref{sec:file_std_descr} e
sez.~\ref{sec:file_std_stream}) sulla pipe. In
fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma,
-il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
+il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
trova nella directory dei sorgenti.
\begin{figure}[!htb]
\label{fig:ipc_barcodepage_code}
\end{figure}
-La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
+La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
per produrre il codice a barre; si ha cura di controllare la riuscita della
chiamata, inviando in caso di errore un messaggio invece dell'immagine
-richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
+richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
\textit{mime type}, e formattando il messaggio in HTML, in modo che
quest'ultimo possa essere visualizzato correttamente da un browser.}
-Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
-primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
+Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
+primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
\cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
caratteri, la converte nell'immagine PostScript del codice a barre ad essa
corrispondente, e poi scrive il risultato direttamente sullo standard output.
In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
-leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
-padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
+leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
+padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
(\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
-così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
-l'uso della prima pipe da parte del padre è finito ed essa può essere
+così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
+l'uso della prima pipe da parte del padre è finito ed essa può essere
definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
29}) che l'esecuzione di \cmd{barcode} sia completata.
-Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
+Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
PostScript del codice a barre sul capo in scrittura della seconda pipe; a
-questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
+questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
-processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
+processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
per convertirla in JPEG.
-Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
+Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
lettura allo standard input. Per poter formattare l'output del programma in
maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
scrittura dell'apposita stringa di identificazione del mime-type in testa allo
-standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
+standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
provvedendo gli appositi switch che consentono di leggere il file da
convertire dallo standard input e di inviare la conversione sullo standard
output.
Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
capo in scrittura della seconda pipe, e attende la conclusione del figlio
-(\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
-conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
+(\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
+conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
-in ingresso (l'unico modo che un programma ha per sapere che l'input è
-terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
+in ingresso (l'unico modo che un programma ha per sapere che l'input è
+terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
non ritornerebbe.
\subsection{Le funzioni \func{popen} e \func{pclose}}
\label{sec:ipc_popen}
-Come si è visto la modalità più comune di utilizzo di una pipe è quella di
+Come si è visto la modalità più comune di utilizzo di una pipe è quella di
utilizzarla per fare da tramite fra output ed input di due programmi invocati
in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
che permettono di sintetizzare queste operazioni. La prima di esse si chiama
-\funcd{popen} ed il suo prototipo è:
+\funcd{popen} ed il suo prototipo è:
\begin{prototype}{stdio.h}
{FILE *popen(const char *command, const char *type)}
\bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
- potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
- e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
+ potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
+ e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
\end{prototype}
La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
\param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
-\verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
+\verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
input o allo standard output del comando invocato.
La funzione restituisce il puntatore allo stream associato alla pipe creata,
-che sarà aperto in sola lettura (e quindi associato allo standard output del
+che sarà aperto in sola lettura (e quindi associato allo standard output del
programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
quindi associato allo standard input) in caso di \code{"w"}.
-Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
-una pipe e non ad un file, e viene sempre aperto in modalità
+Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
+stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
+una pipe e non ad un file, e viene sempre aperto in modalità
\textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
-differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
-due nuove funzioni, \funcd{pclose}, il cui prototipo è:
+differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
+due nuove funzioni, \funcd{pclose}, il cui prototipo è:
\begin{prototype}{stdio.h}
{int pclose(FILE *stream)}
Per illustrare l'uso di queste due funzioni riprendiamo il problema
precedente: il programma mostrato in fig.~\ref{fig:ipc_barcodepage_code} per
-quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
-inoltre nella pratica sconta un problema di \cmd{gs} che non è in
+quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
+inoltre nella pratica sconta un problema di \cmd{gs} che non è in
grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
il PostScript e tutte le volte viene generata una pagina intera, invece che
una immagine delle dimensioni corrispondenti al codice a barre.
Se si vuole generare una immagine di dimensioni appropriate si deve usare un
-approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
-programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
+approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
+programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
originarie del codice a barre e produce un JPEG di dimensioni corrette.
-Questo approccio però non funziona, per via di una delle caratteristiche
-principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
+Questo approccio però non funziona, per via di una delle caratteristiche
+principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
necessario, per la struttura del formato, potersi spostare (con \func{lseek})
all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
-su un file regolare non ci sono problemi, una pipe però è rigidamente
+su un file regolare non ci sono problemi, una pipe però è rigidamente
sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
di \errcode{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che
-in generale la concatenazione di vari programmi funzionerà soltanto quando
+in generale la concatenazione di vari programmi funzionerà soltanto quando
tutti prevedono una lettura sequenziale del loro input.
-Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
+Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
-intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
- formato usato spesso come formato intermedio per effettuare conversioni, è
+intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
+ formato usato spesso come formato intermedio per effettuare conversioni, è
infatti molto facile da manipolare, dato che usa caratteri ASCII per
- memorizzare le immagini, anche se per questo è estremamente inefficiente.}
-dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
-vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
+ memorizzare le immagini, anche se per questo è estremamente inefficiente.}
+dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
+vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
essere infine trasformata in PNG (con \cmd{pnm2png}).
-In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
+In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
inviando l'output di ciascuno all'input del successivo, per poi ottenere il
risultato finale sullo standard output: un caso classico di utilizzazione
delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
semplificare notevolmente la stesura del codice.
Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
-standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
-scrittura. Il codice del nuovo programma è riportato in
-fig.~\ref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione
-dei programmi è l'inverso di quello in cui ci si aspetta che vengano
+standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
+scrittura. Il codice del nuovo programma è riportato in
+fig.~\ref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione
+dei programmi è l'inverso di quello in cui ci si aspetta che vengano
effettivamente eseguiti. Questo non comporta nessun problema dato che la
-lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
-per primo, si bloccherà in attesa di ricevere sullo standard input il
-risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
+lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
+per primo, si bloccherà in attesa di ricevere sullo standard input il
+risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
dopo.
\begin{figure}[!htb]
\label{fig:ipc_barcode_code}
\end{figure}
-Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
-sullo standard output; a questo punto il processo padre non necessita più di
-eseguire ulteriori operazioni sullo standard output e può tranquillamente
+Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
+sullo standard output; a questo punto il processo padre non necessita più di
+eseguire ulteriori operazioni sullo standard output e può tranquillamente
provvedere alla redirezione.
-Dato che i vari programmi devono essere lanciati in successione, si è
+Dato che i vari programmi devono essere lanciati in successione, si è
approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
il programma con \func{popen}, in modo che essa sia collegata allo standard
input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
-In questo modo il primo processo ad essere invocato (che è l'ultimo della
-catena) scriverà ancora sullo standard output del processo padre, ma i
+In questo modo il primo processo ad essere invocato (che è l'ultimo della
+catena) scriverà ancora sullo standard output del processo padre, ma i
successivi, a causa di questa redirezione, scriveranno sulla pipe associata
allo standard input del processo invocato nel ciclo precedente.
-Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
-primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
-(\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
-al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
+Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
+primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
+(\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
+al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
create, tutte le pipe create con \func{pclose}.
\subsection{Le \textit{pipe} con nome, o \textit{fifo}}
\label{sec:ipc_named_pipe}
-Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
+Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
che esse possono essere utilizzate solo da processi con un progenitore comune
o nella relazione padre/figlio; per superare questo problema lo standard
POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
caratteristiche delle pipe, ma che invece di essere strutture interne del
kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un \index{inode} inode che risiede sul filesystem, così che i
+attraverso un \index{inode} inode che risiede sul filesystem, così che i
processi le possono usare senza dovere per forza essere in una relazione di
\textsl{parentela}.
attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
punto di riferimento per i processi, che permetta loro di accedere alla stessa
-fifo; il comportamento delle funzioni di lettura e scrittura è identico a
+fifo; il comportamento delle funzioni di lettura e scrittura è identico a
quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
-Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
+Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
\func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
-processo non avrà che da aprire il relativo file speciale o in lettura o
-scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
-leggere, nel secondo al capo di ingresso, e dovrà scrivere.
+processo non avrà che da aprire il relativo file speciale o in lettura o
+scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
+leggere, nel secondo al capo di ingresso, e dovrà scrivere.
-Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
-essere acceduta contemporaneamente da più processi, sia in lettura che in
+Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
+essere acceduta contemporaneamente da più processi, sia in lettura che in
scrittura. Dato che per funzionare deve essere aperta in entrambe le
direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
-eseguita quando l'altro capo non è aperto.
+eseguita quando l'altro capo non è aperto.
-Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
-nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
-l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
-l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
+Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
+nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
+l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
+l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
-In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
+In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
standard POSIX lascia indefinito il comportamento in questo caso.}
-operazione che avrà sempre successo immediato qualunque sia la modalità di
-apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
+operazione che avrà sempre successo immediato qualunque sia la modalità di
+apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
comunque una fifo in scrittura anche se non ci sono ancora processi il
-lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
-qual caso però occorre stare molto attenti alla possibili situazioni di
+lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
+qual caso però occorre stare molto attenti alla possibili situazioni di
stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
- avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
- blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
+ avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
+ blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
-Per la loro caratteristica di essere accessibili attraverso il filesystem, è
+Per la loro caratteristica di essere accessibili attraverso il filesystem, è
piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
-situazioni un processo deve ricevere informazioni da altri. In questo caso è
+situazioni un processo deve ricevere informazioni da altri. In questo caso è
fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
-sempre tenere presente che questo è vero soltanto fintanto che non si supera
+sempre tenere presente che questo è vero soltanto fintanto che non si supera
il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
sez.~\ref{sec:ipc_pipes}).
-A parte il caso precedente, che resta probabilmente il più comune, Stevens
+A parte il caso precedente, che resta probabilmente il più comune, Stevens
riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
\begin{itemize}
\item Da parte dei comandi di shell, per evitare la creazione di file
sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
\item Come canale di comunicazione fra client ed server (il modello
- \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
+ \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
\end{itemize}
-Nel primo caso quello che si fa è creare tante fifo, da usare come standard
+Nel primo caso quello che si fa è creare tante fifo, da usare come standard
input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
-potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
+potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
con il comando \cmd{tee}, sulle varie fifo.
-Il secondo caso è relativamente semplice qualora si debba comunicare con un
+Il secondo caso è relativamente semplice qualora si debba comunicare con un
processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
-una per scrivere), le cose diventano invece molto più complesse quando si
+una per scrivere), le cose diventano invece molto più complesse quando si
vuole effettuare una comunicazione fra il server ed un numero imprecisato di
-client; se il primo infatti può ricevere le richieste attraverso una fifo
-``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
+client; se il primo infatti può ricevere le richieste attraverso una fifo
+``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
leggerli, quando i dati inviati sono destinati a loro.
-Per risolvere questo problema, si può usare un'architettura come quella
+Per risolvere questo problema, si può usare un'architettura come quella
illustrata in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client inviano le
richieste al server su una fifo nota mentre le risposte vengono reinviate dal
server a ciascuno di essi su una fifo temporanea creata per l'occasione.
un server di \textit{fortunes}, che restituisce, alle richieste di un client,
un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
-da riga di comando. Il corpo principale del server è riportato in
-fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
+da riga di comando. Il corpo principale del server è riportato in
+fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
gestione delle opzioni a riga di comando, che effettua il settaggio delle
variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
-diverso da quelli preimpostati. Il codice completo è nel file
+diverso da quelli preimpostati. Il codice completo è nel file
\file{FortuneServer.c}.
\begin{figure}[!htb]
dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
\var{fortune} avviene solo quando questa dimensione viene specificata, la
presenza di un valore nullo provoca l'uscita dal programma attraverso la
-funzione (non riportata) che ne stampa le modalità d'uso. Dopo di che
+funzione (non riportata) che ne stampa le modalità d'uso. Dopo di che
installa (\texttt{\small 13--15}) la funzione che gestisce i segnali di
-interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
+interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
che si limita a rimuovere dal filesystem la fifo usata dal server per
comunicare.
funzione \code{FortuneParse} che legge dal file specificato in
\var{fortunefilename} le prime \var{n} frasi e le memorizza (allocando
dinamicamente la memoria necessaria) nel vettore di puntatori \var{fortune}.
-Anche il codice della funzione non è riportato, in quanto non direttamente
+Anche il codice della funzione non è riportato, in quanto non direttamente
attinente allo scopo dell'esempio.
-Il passo successivo (\texttt{\small 17--22}) è quello di creare con
-\func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
-qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
+Il passo successivo (\texttt{\small 17--22}) è quello di creare con
+\func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
+qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
fifo).
-Una volta che si è certi che la fifo di ascolto esiste la procedura di
-inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
+Una volta che si è certi che la fifo di ascolto esiste la procedura di
+inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
23}) la funzione \func{daemon} per far proseguire l'esecuzione del programma
-in background come demone. Si può quindi procedere (\texttt{\small 24--33})
+in background come demone. Si può quindi procedere (\texttt{\small 24--33})
alla apertura della fifo: si noti che questo viene fatto due volte, prima in
lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo
-principale il caso in cui il server è in ascolto ma non ci sono client che
-effettuano richieste. Si ricordi infatti che quando una fifo è aperta solo
+principale il caso in cui il server è in ascolto ma non ci sono client che
+effettuano richieste. Si ricordi infatti che quando una fifo è aperta solo
dal capo in lettura, l'esecuzione di \func{read} ritorna con zero byte (si ha
-cioè una condizione di end-of-file).
+cioè una condizione di end-of-file).
-Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
+Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
client non apre a sua volta la fifo nota in scrittura per effettuare la sua
-richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
-ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
+richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
+ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
A questo punto il server resta (se non ci sono altri client che stanno
effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
-stato la funzione \func{read} non si bloccherà in attesa di input, ma
-ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
- questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
+stato la funzione \func{read} non si bloccherà in attesa di input, ma
+ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
+ questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
- che non si può scrivere per errore sul capo aperto in sola lettura.}
+ che non si può scrivere per errore sul capo aperto in sola lettura.}
Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
24--28}),\footnote{di solito si effettua l'apertura del capo in lettura di
- una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
- infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
- dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
+ una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
+ infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
+ dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
necessario potersi bloccare in lettura in attesa di una richiesta.} si
esegue una seconda apertura in scrittura (\texttt{\small 29--32}), scartando
-il relativo file descriptor, che non sarà mai usato, in questo modo però la
-fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
+il relativo file descriptor, che non sarà mai usato, in questo modo però la
+fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
a \func{read} possono bloccarsi.
-A questo punto si può entrare nel ciclo principale del programma che fornisce
+A questo punto si può entrare nel ciclo principale del programma che fornisce
le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
modo da passare attraverso la funzione di chiusura che cancella la fifo).
-Il server è progettato per accettare come richieste dai client delle stringhe
+Il server è progettato per accettare come richieste dai client delle stringhe
che contengono il nome della fifo sulla quale deve essere inviata la risposta.
Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
-richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
+richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
non ci sono richieste). Dopo di che, una volta terminata la stringa
(\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
-ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
+ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
-sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
-non serve più.
+sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
+non serve più.
-Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
-anche in questo caso si è omessa la gestione delle opzioni e la funzione che
+Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
+anche in questo caso si è omessa la gestione delle opzioni e la funzione che
stampa a video le informazioni di utilizzo ed esce, riportando solo la sezione
principale del programma e le definizioni delle variabili. Il codice completo
-è nel file \file{FortuneClient.c} dei sorgenti allegati.
+è nel file \file{FortuneClient.c} dei sorgenti allegati.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:ipc_fifo_client}
\end{figure}
-La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
+La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
essere utilizzata per ricevere la risposta dal server. Si usa il \acr{pid}
del processo per essere sicuri di avere un nome univoco; dopo di che
(\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
-in caso di errore (a meno che il file non sia già presente sul filesystem).
+in caso di errore (a meno che il file non sia già presente sul filesystem).
-A questo punto il client può effettuare l'interrogazione del server, per
+A questo punto il client può effettuare l'interrogazione del server, per
questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
(\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
della fifo da utilizzare per la risposta. Infine si richiude la fifo del
-server che a questo punto non serve più (\texttt{\small 25}).
+server che a questo punto non serve più (\texttt{\small 25}).
-Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
+Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
-nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
+nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
-tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
+tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
(\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
fifo e si cancella (\texttt{\small 34}) il relativo file.
Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
-la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
+la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
scrittura e l'apertura si sarebbe bloccata indefinitamente.
Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
-occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
+occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
in modo che il linker dinamico possa accedervi.
In generale questa variabile indica il \itindex{pathname} \textit{pathname}
della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
verificata) che si facciano le prove direttamente nella directory dei sorgenti
(dove di norma vengono creati sia i programmi che la libreria), il comando da
-dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
+dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
il server, facendogli leggere una decina di frasi, con:
\begin{Verbatim}
[piccardi@gont sources]$ ./fortuned -n10
%$
Avendo usato \func{daemon} per eseguire il server in background il comando
-ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
+ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
programma resta un esecuzione in background, e senza avere associato un
terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
\begin{Verbatim}
piccardi 27492 3.0 0.1 2492 764 pts/2 R 01:08 0:00 ps aux
\end{Verbatim}
%$
-e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
+e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
-il programma client; otterremo così:
+il programma client; otterremo così:
\begin{Verbatim}
[piccardi@gont sources]$ ./fortune
Linux ext2fs has been stable for a long time, now it's time to break it
- -- Linuxkongreß '95 in Berlin
+ -- Linuxkongreß '95 in Berlin
[piccardi@gont sources]$ ./fortune
Let's call it an accidental feature.
--Larry Wall
-- William E. Roadcap
[piccardi@gont sources]$ ./fortune
Linux ext2fs has been stable for a long time, now it's time to break it
- -- Linuxkongreß '95 in Berlin
+ -- Linuxkongreß '95 in Berlin
\end{Verbatim}
%$
e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
frasi tenute in memoria dal server.
-Infine per chiudere il server basterà inviare un segnale di terminazione con
+Infine per chiudere il server basterà inviare un segnale di terminazione con
\code{killall fortuned} e potremo verificare che il gestore del segnale ha
anche correttamente cancellato la fifo di ascolto da \file{/tmp}.
-Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
+Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
che esamina questa architettura in \cite{APUE}, nota come sia impossibile
- per il server sapere se un client è andato in crash, con la possibilità di
+ per il server sapere se un client è andato in crash, con la possibilità di
far restare le fifo temporanee sul filesystem, di come sia necessario
- intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
+ intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
- nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
-fifo non è adatta a risolvere questo tipo di problemi, che possono essere
-affrontati in maniera più semplice ed efficace o usando i socket (che
+ nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
+fifo non è adatta a risolvere questo tipo di problemi, che possono essere
+affrontati in maniera più semplice ed efficace o usando i socket (che
tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo
a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
\label{sec:ipc_socketpair}
Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
-problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
+problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
\textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di
oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
per la programmazione di rete; e vedremo anche
(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
-(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
-attraverso quella medesima interfaccia; vale però la pena esaminare qui una
-modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
- stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
+(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
+attraverso quella medesima interfaccia; vale però la pena esaminare qui una
+modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
+ stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
identici ad una pipe bidirezionale.
descriptor connessi fra di loro (tramite un socket, appunto), senza dover
ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
-differenza è che in questo caso il flusso dei dati può essere effettuato in
-entrambe le direzioni. Il prototipo della funzione è:
+differenza è che in questo caso il flusso dei dati può essere effettuato in
+entrambe le direzioni. Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
Crea una coppia di socket connessi fra loro.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EAFNOSUPPORT}] i socket locali non sono supportati.
- \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
+ \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
\item[\errcode{EOPNOTSUPP}] il protocollo specificato non supporta la
creazione di coppie di socket.
\end{errlist}
\end{functions}
La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
-loro: quello che si scrive su uno di essi sarà ripresentato in input
+loro: quello che si scrive su uno di essi sarà ripresentato in input
sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
\param{protocol} derivano dall'interfaccia dei socket (vedi
-sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
+sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
connettere i due descrittori, ma in questo caso i soli valori validi che
possono essere specificati sono rispettivamente \const{AF\_UNIX},
\const{SOCK\_STREAM} e \val{0}.
-L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
-può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
+L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
+può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
locali in generale) permette di trasmettere attraverso le linea non solo dei
-dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
+dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
altro un file descriptor, con una sorta di duplicazione dello stesso non
all'interno di uno stesso processo, ma fra processi distinti (torneremo su
-questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
+questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
\section{Il sistema di comunicazione fra processi di System V}
\label{sec:ipc_sysv}
-Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
-limite fondamentale che il meccanismo di comunicazione che forniscono è
+Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
+limite fondamentale che il meccanismo di comunicazione che forniscono è
rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
-molti altri devono poter leggere non può essere implementata con una pipe.
+molti altri devono poter leggere non può essere implementata con una pipe.
Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
oggetti per la comunicazione fra processi ed una nuova interfaccia di
-programmazione, che fossero in grado di garantire una maggiore flessibilità.
+programmazione, che fossero in grado di garantire una maggiore flessibilità.
In questa sezione esamineremo come Linux supporta quello che viene chiamato il
\textsl{Sistema di comunicazione fra processi} di System V, cui da qui in
-avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
+avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
\textit{Inter-Process Comunication}).
\subsection{Considerazioni generali}
\label{sec:ipc_sysv_generic}
-La principale caratteristica del \textit{SysV IPC} è quella di essere basato
+La principale caratteristica del \textit{SysV IPC} è quella di essere basato
su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
-non vengono cancellati dal sistema una volta che non sono più in uso.
+non vengono cancellati dal sistema una volta che non sono più in uso.
-Questo comporta due problemi: il primo è che, al contrario di quanto avviene
+Questo comporta due problemi: il primo è che, al contrario di quanto avviene
per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
-automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
+automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
essere cancellati esplicitamente, se non si vuole che restino attivi fino al
-riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
+riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
essi possono essere cancellati anche se ci sono dei processi che li stanno
utilizzando, con tutte le conseguenze (negative) del caso.
-Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
+Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
IPC} vengono creati direttamente dal kernel, e sono accessibili solo
-specificando il relativo \textsl{identificatore}. Questo è un numero
+specificando il relativo \textsl{identificatore}. Questo è un numero
progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
-dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
+dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
-non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
-si pone perciò il problema di come processi diversi possono accedere allo
+non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
+si pone perciò il problema di come processi diversi possono accedere allo
stesso oggetto.
Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
associa a ciascun oggetto, viene mantenuto anche un campo apposito che
contiene anche una \textsl{chiave}, identificata da una variabile del tipo
primitivo \type{key\_t}, da specificare in fase di creazione dell'oggetto, e
-tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
+tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
si sposta il problema dell'accesso dalla classificazione in base
all'identificatore alla classificazione in base alla chiave, una delle tante
complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
-struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
-mantiene varie proprietà ed informazioni associate all'oggetto.
+struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
+mantiene varie proprietà ed informazioni associate all'oggetto.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Usando la stessa chiave due processi diversi possono ricavare l'identificatore
-associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
+associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
-sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
-infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
-nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
-disponibile in tutti i figli, e potrà essere passato come argomento attraverso
+sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
+infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
+nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
+disponibile in tutti i figli, e potrà essere passato come argomento attraverso
una \func{exec}.
-Però quando i processi non sono \textsl{imparentati} (come capita tutte le
-volte che si ha a che fare con un sistema client-server) tutto questo non è
+Però quando i processi non sono \textsl{imparentati} (come capita tutte le
+volte che si ha a che fare con un sistema client-server) tutto questo non è
possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
-alternativa più efficace è quella che i programmi usino un valore comune per
-la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
-sempre il rischio che questa chiave possa essere stata già utilizzata da
+alternativa più efficace è quella che i programmi usino un valore comune per
+la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
+sempre il rischio che questa chiave possa essere stata già utilizzata da
qualcun altro. Dato che non esiste una convenzione su come assegnare queste
chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
-nome di un file ed un numero di versione; il suo prototipo è:
+nome di un file ed un numero di versione; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
\bodydesc{La funzione restituisce la chiave in caso di successo e -1
- altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
+ altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
errore di \func{stat}.}
\end{functions}
effettivamente esistente e di un numero di progetto \param{proj\_id)}, che di
norma viene specificato come carattere, dato che ne vengono utilizzati solo
gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
- SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le
+ SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le
\acr{glibc} usano il prototipo specificato da XPG4, ma vengono lo stesso
utilizzati gli 8 bit meno significativi.}
-Il problema è che anche così non c'è la sicurezza che il valore della chiave
-sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
+Il problema è che anche così non c'è la sicurezza che il valore della chiave
+sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
con i 16 bit meno significativi \index{inode} dell'inode del file
\param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
-su cui è il file. Diventa perciò relativamente facile ottenere delle
+su cui è il file. Diventa perciò relativamente facile ottenere delle
collisioni, specie se i file sono su dispositivi con lo stesso
\itindex{minor~number} \textit{minor number}, come \file{/dev/hda1} e
\file{/dev/sda1}.
-In genere quello che si fa è utilizzare un file comune usato dai programmi che
+In genere quello che si fa è utilizzare un file comune usato dai programmi che
devono comunicare (ad esempio un header comune, o uno dei programmi che devono
usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
-creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
+creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
bene in fase di creazione, le cose possono complicarsi per i programmi che
devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
-attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
+attributi di \struct{ipc\_perm}, non esiste una modalità semplice per essere
sicuri che l'oggetto associato ad una certa chiave sia stato effettivamente
creato da chi ci si aspetta.
-Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
+Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
contatore di riferimenti per la cancellazione automatica, il principale
-problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
+problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
-file, e tutta l'interfaccia è inutilmente complessa. Per questo ne è stata
+file, e tutta l'interfaccia è inutilmente complessa. Per questo ne è stata
effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
sez.~\ref{sec:ipc_posix}.
\struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
(nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
\var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
-questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
+questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
simile a quello che si ha per i file (vedi sez.~\ref{sec:file_perm_overview}).
-Benché questo controllo di accesso sia molto simile a quello dei file, restano
-delle importanti differenze. La prima è che il permesso di esecuzione non
-esiste (e se specificato viene ignorato), per cui si può parlare solo di
-permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
+Benché questo controllo di accesso sia molto simile a quello dei file, restano
+delle importanti differenze. La prima è che il permesso di esecuzione non
+esiste (e se specificato viene ignorato), per cui si può parlare solo di
+permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
ed hanno lo stesso significato di quelli riportati in
-tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
- simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
+tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
+ simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
\const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
- per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
+ per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
costanti non sono definite.} e come per i file definiscono gli accessi per
il proprietario, il suo gruppo e tutti gli altri.
che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
-Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
+Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
funzioni che richiedono l'identificatore di un oggetto data la chiave. Queste
specificano tutte un argomento \param{flag}, in tal caso quando viene
effettuata la ricerca di una chiave, qualora \param{flag} specifichi dei
permessi, questi vengono controllati e l'identificatore viene restituito solo
se corrispondono a quelli dell'oggetto. Se ci sono dei permessi non presenti
-in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
-indicativa, dato che è sempre possibile specificare per \param{flag} un valore
-nullo, nel qual caso l'identificatore sarà restituito comunque.
+in \var{mode} l'accesso sarà negato. Questo controllo però è di utilità
+indicativa, dato che è sempre possibile specificare per \param{flag} un valore
+nullo, nel qual caso l'identificatore sarà restituito comunque.
-Il secondo livello di controllo è quello delle varie funzioni che accedono
+Il secondo livello di controllo è quello delle varie funzioni che accedono
direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
-controlli è simile a quello dei file, ed avviene secondo questa sequenza:
+controlli è simile a quello dei file, ed avviene secondo questa sequenza:
\begin{itemize*}
-\item se il processo ha i privilegi di amministratore l'accesso è sempre
+\item se il processo ha i privilegi di amministratore l'accesso è sempre
consentito.
\item se l'user-ID effettivo del processo corrisponde o al valore del campo
\var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
- in \var{mode} è appropriato\footnote{per appropriato si intende che è
+ in \var{mode} è appropriato\footnote{per appropriato si intende che è
impostato il permesso di scrittura per le operazioni di scrittura e quello
- di lettura per le operazioni di lettura.} l'accesso è consentito.
+ di lettura per le operazioni di lettura.} l'accesso è consentito.
\item se il group-ID effettivo del processo corrisponde o al
valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
- per il gruppo in \var{mode} è appropriato l'accesso è consentito.
-\item se il permesso per gli altri è appropriato l'accesso è consentito.
+ per il gruppo in \var{mode} è appropriato l'accesso è consentito.
+\item se il permesso per gli altri è appropriato l'accesso è consentito.
\end{itemize*}
-solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
+solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
a differenza di quanto avviene per i permessi dei file, fallire in uno dei
passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
-differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
+differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in
sez.~\ref{sec:file_perm_management}) non ha alcun significato.
\subsection{Gli identificatori ed il loro utilizzo}
\label{sec:ipc_sysv_id_use}
-L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
-\var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
-``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
-strettamente attinente alle modalità con cui il kernel assegna gli
+L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
+\var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
+``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
+strettamente attinente alle modalità con cui il kernel assegna gli
identificatori degli oggetti del sistema di IPC.
Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
Questo va benissimo nel caso dei file descriptor, che sono locali ad un
processo, ma qui il comportamento varrebbe per tutto il sistema, e per
-processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
+processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
come quella in cui un server esce e cancella le sue code di messaggi, ed il
relativo identificatore viene immediatamente assegnato a quelle di un altro
-server partito subito dopo, con la possibilità che i client del primo non
+server partito subito dopo, con la possibilità che i client del primo non
facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
con gli oggetti del secondo, con conseguenze imprevedibili.
Proprio per evitare questo tipo di situazioni il sistema usa il valore di
\var{seq} per provvedere un meccanismo che porti gli identificatori ad
-assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
-un identificatore può venire riutilizzato.
+assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
+un identificatore può venire riutilizzato.
Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
\const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
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
+ 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}
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
-l'oggetto viene creato usando uno spazio che era già stato utilizzato in
+l'oggetto viene creato usando uno spazio che era già stato utilizzato in
precedenza per restituire l'identificatore al numero di oggetti presenti viene
sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
- serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
+ serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
- valore è 32768.} si evita così il riutilizzo degli stessi numeri, e si fa
-sì che l'identificatore assuma tutti i valori possibili.
+ valore è 32768.} si evita così il riutilizzo degli stessi numeri, e si fa
+sì che l'identificatore assuma tutti i valori possibili.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:ipc_sysv_idtest}
\end{figure}
-In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
+In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
programma di test che si limita a creare un oggetto (specificato a riga di
comando), stamparne il numero di identificatore e cancellarlo per un numero
-specificato di volte. Al solito non si è riportato il codice della gestione
+specificato di volte. Al solito non si è riportato il codice della gestione
delle opzioni a riga di comando, che permette di specificare quante volte
effettuare il ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
\var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
stampa, cancellazione. I valori di default sono per l'uso delle code di
-messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
+messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
del tipo:
\begin{Verbatim}
piccardi@gont sources]$ ./ipctestid
Identifier Value 294912
\end{Verbatim}
%$
-che ci mostra come il valore di \var{seq} sia in effetti una quantità
+che ci mostra come il valore di \var{seq} sia in effetti una quantità
mantenuta staticamente all'interno del sistema.
\subsection{Code di messaggi}
\label{sec:ipc_sysv_mq}
-Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
+Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
messaggi. Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
-anche se la loro struttura è diversa, ed il loro scopo principale è appunto
+anche se la loro struttura è diversa, ed il loro scopo principale è appunto
quello di permettere a processi diversi di scambiarsi dei dati.
La funzione che permette di richiedere al sistema l'identificatore di una coda
-di messaggi esistente (o di crearne una se questa non esiste) è
-\funcd{msgget}; il suo prototipo è:
+di messaggi esistente (o di crearne una se questa non esiste) è
+\funcd{msgget}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Restituisce l'identificatore di una coda di messaggi.
\bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
- in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] il processo chiamante non ha i privilegi per accedere
alla coda richiesta.
- \item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
+ \item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}.
- \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
- \item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
+ \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
+ \item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
non era specificato.
- \item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
+ \item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
stato superato il limite massimo di code (\const{MSGMNI}).
\end{errlist}
ed inoltre \errval{ENOMEM}.
Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
-nuova. L'argomento \param{key} specifica la chiave che è associata
+nuova. L'argomento \param{key} specifica la chiave che è associata
all'oggetto, eccetto il caso in cui si specifichi il valore
-\const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
+\const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
farvi riferimento solo attraverso l'identificatore.
Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
Linux questo significa un valore diverso da zero.} l'effetto della funzione
-dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
+dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
validi.
-Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
+Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
essere nullo e deve essere fornito come maschera binaria, impostando il bit
corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
significativi di \param{flag} saranno usati come permessi per il nuovo
oggetto, secondo quanto illustrato in sez.~\ref{sec:ipc_sysv_access_control}.
-Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
-successo solo se l'oggetto non esiste già, fallendo con un errore di
+Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
+successo solo se l'oggetto non esiste già, fallendo con un errore di
\errcode{EEXIST} altrimenti.
Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
negli header e corrispondenti alle prime tre costanti riportate in
-tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
+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
\end{figure}
-Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
- list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
+Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
+ list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
struttura di dati, organizzati in una lista in cui ciascun elemento contiene
- un puntatore al successivo. In questo modo la struttura è veloce
- nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
+ un puntatore al successivo. In questo modo la struttura è veloce
+ nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e
relativamente veloce da attraversare in ordine sequenziale (seguendo i
- puntatori), è invece relativamente lenta nell'accesso casuale e nella
+ puntatori), è invece relativamente lenta nell'accesso casuale e nella
ricerca.} i nuovi messaggi vengono inseriti in coda alla lista e vengono
-letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
+letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
- illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
+ illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
di quello usato effettivamente fino ai kernel della serie 2.2.x, nei kernel
- della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
+ della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
effettuata in maniera diversa; abbiamo mantenuto lo schema precedente in
- quanto illustra comunque in maniera più che adeguata i principi di
+ quanto illustra comunque in maniera più che adeguata i principi di
funzionamento delle code di messaggi.}
\begin{figure}[!htb]
\label{fig:ipc_msqid_ds}
\end{figure}
-A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
+A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
+definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
kernel mantiene le principali informazioni riguardo lo stato corrente della
coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
- essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
- quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
+ essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
+ quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
sia una differenza con i campi mostrati nello schema di
fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
\file{linux/msg.h}, e fanno riferimento alla definizione della omonima
rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
un messaggio sulla coda, sono inizializzati a 0.
\item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
- rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
+ rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
messaggio sulla coda, sono inizializzati a 0.
\item il campo \var{msg\_ctime}, che esprime il tempo di creazione della coda,
viene inizializzato al tempo corrente.
del sistema (\const{MSGMNB}).
\item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
primo e ultimo messaggio sono inizializzati a \val{NULL} e
- \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
+ \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
e non devono essere utilizzati da programmi in user space).
\end{itemize*}
Una volta creata una coda di messaggi le operazioni di controllo vengono
effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
-e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
-prototipo è:
+e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
\bodydesc{La funzione restituisce 0 in caso di successo o $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
+ \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
chiamante non ha i privilegi di lettura sulla coda.
- \item[\errcode{EIDRM}] la coda richiesta è stata cancellata.
- \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
- il processo non ha i privilegi, o si è richiesto di aumentare il valore di
+ \item[\errcode{EIDRM}] la coda richiesta è stata cancellata.
+ \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID} ma
+ il processo non ha i privilegi, o si è richiesto di aumentare il valore di
\var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
amministratore.
\end{errlist}
effetto immediato. Tutti i processi che cercheranno di accedere alla coda
riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
- il medesimo errore. Questo comando può essere eseguito solo da un processo
+ il medesimo errore. Questo comando può essere eseguito solo da un processo
con user-ID effettivo corrispondente al creatore o al proprietario della
coda, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
struttura \struct{msqid\_ds} puntata da \param{buf}. Per modificare i valori
di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
essere il proprietario o il creatore della coda, oppure l'amministratore; lo
- stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
+ stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
incrementarne il valore a limiti superiori a \const{MSGMNB}.
\end{basedescript}
Una volta che si abbia a disposizione l'identificatore, per inviare un
messaggio su una coda si utilizza la funzione \funcd{msgsnd}; il suo prototipo
-è:
+è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Invia un messaggio sulla coda \param{msqid}.
\bodydesc{La funzione restituisce 0, e $-1$ in caso di errore, nel qual caso
- \var{errno} assumerà uno dei valori:
+ \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
- \item[\errcode{EIDRM}] la coda è stata cancellata.
- \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è
+ \item[\errcode{EIDRM}] la coda è stata cancellata.
+ \item[\errcode{EAGAIN}] il messaggio non può essere inviato perché si è
superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
- sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
- \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
+ sulla coda, e si è richiesto \const{IPC\_NOWAIT} in \param{flag}.
+ \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
valore non positivo per \param{mtype}, o un valore di \param{msgsz}
maggiore di \const{MSGMAX}.
\end{errlist}
\end{functions}
La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
-messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
+messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
l'argomento \param{msgp}. Quest'ultimo deve venire passato sempre come
puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
-fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
-messaggio. La dimensione massima per il testo di un messaggio non può
+fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
+messaggio. La dimensione massima per il testo di un messaggio non può
comunque superare il limite \const{MSGMAX}.
-La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
+La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
-campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
-La sola cosa che conta è che la struttura abbia come primo membro un campo
+campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
+La sola cosa che conta è che la struttura abbia come primo membro un campo
\var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
messaggio e deve essere sempre specificato come intero positivo di tipo
-\ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
+\ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
dimensione, e serve a contenere il testo del messaggio.
In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
ridefinire una struttura simile a quella di fig.~\ref{fig:ipc_msbuf}, adattando
alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
-corpo del messaggio, anche con più campi o con strutture più complesse) avendo
-però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
+corpo del messaggio, anche con più campi o con strutture più complesse) avendo
+però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
indica il tipo.
Si tenga presente che la lunghezza che deve essere indicata in questo
-argomento è solo quella del messaggio, non quella di tutta la struttura, se
-cioè \var{message} è una propria struttura che si passa alla funzione,
-\param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
+argomento è solo quella del messaggio, non quella di tutta la struttura, se
+cioè \var{message} è una propria struttura che si passa alla funzione,
+\param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
consideriamo il caso dell'esempio in fig.~\ref{fig:ipc_msbuf}, \param{msgsz}
-dovrà essere pari a \const{LENGTH}).
+dovrà essere pari a \const{LENGTH}).
\begin{figure}[!htb]
\footnotesize \centering
Per capire meglio il funzionamento della funzione riprendiamo in
considerazione la struttura della coda illustrata in
fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
-sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
-il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
+sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
+il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
il puntatore al messaggio successivo per quello che era il precedente ultimo
-messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
-valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
+messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
+valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
all'indirizzo specificato da \var{msg\_spot}.
Il valore dell'argomento \param{flag} permette di specificare il comportamento
\var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
caso si blocca mandando il processo in stato di \textit{sleep}. Se si
specifica per \param{flag} il valore \const{IPC\_NOWAIT} la funzione opera in
-modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
+modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
di \errcode{EAGAIN}.
-Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
+Se non si specifica \const{IPC\_NOWAIT} la funzione resterà bloccata fintanto
che non si liberano risorse sufficienti per poter inserire nella coda il
-messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
+messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
una condizione di errore anche in due altri casi: quando la coda viene rimossa
(nel qual caso si ha un errore di \errcode{EIDRM}) o quando la funzione viene
interrotta da un segnale (nel qual caso si ha un errore di \errcode{EINTR}).
\item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
\end{itemize*}
-La funzione che viene utilizzata per estrarre un messaggio da una coda è
-\funcd{msgrcv}; il suo prototipo è:
+La funzione che viene utilizzata per estrarre un messaggio da una coda è
+\funcd{msgrcv}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Legge un messaggio dalla coda \param{msqid}.
\bodydesc{La funzione restituisce il numero di byte letti in caso di
- successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
+ successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
- \item[\errcode{EIDRM}] la coda è stata cancellata.
- \item[\errcode{E2BIG}] il testo del messaggio è più lungo di \param{msgsz} e
- non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale mentre
+ \item[\errcode{EIDRM}] la coda è stata cancellata.
+ \item[\errcode{E2BIG}] il testo del messaggio è più lungo di \param{msgsz} e
+ non si è specificato \const{MSG\_NOERROR} in \param{msgflg}.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale mentre
era in attesa di ricevere un messaggio.
- \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido o un
+ \item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido o un
valore di \param{msgsz} negativo.
\end{errlist}
ed inoltre \errval{EFAULT}.
\end{functions}
La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
-struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
-di fig.~\ref{fig:ipc_msbuf}. Una volta estratto, il messaggio sarà rimosso
+struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
+di fig.~\ref{fig:ipc_msbuf}. Una volta estratto, il messaggio sarà rimosso
dalla coda. L'argomento \param{msgsz} indica la lunghezza massima del testo
del messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio
di fig.~\ref{fig:ipc_msbuf}).
Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
-rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
+rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
\const{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
un errore di \errcode{E2BIG}.
L'argomento \param{msgtyp} permette di restringere la ricerca ad un
-sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
+sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
una scansione della struttura mostrata in fig.~\ref{fig:ipc_mq_schema},
restituendo il primo messaggio incontrato che corrisponde ai criteri
specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
-coda, è quello meno recente); in particolare:
+coda, è quello meno recente); in particolare:
\begin{itemize}
-\item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
- quello fra i presenti che è stato inserito per primo.
-\item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
+\item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
+ quello fra i presenti che è stato inserito per primo.
+\item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
tipo (il valore del campo \var{mtype}) corrisponde al valore di
\param{msgtyp}.
-\item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
- il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
+\item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
+ il valore più basso del tipo, fra tutti quelli il cui tipo ha un valore
inferiore al valore assoluto di \param{msgtyp}.
\end{itemize}
Il valore di \param{msgflg} permette di controllare il comportamento della
-funzione, esso può essere nullo o una maschera binaria composta da uno o più
+funzione, esso può essere nullo o una maschera binaria composta da uno o più
valori. Oltre al precedente \const{MSG\_NOERROR}, sono possibili altri due
-valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
+valori: \const{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
\const{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
ci sono messaggi sulla coda.
Il comportamento usuale della funzione infatti, se non ci sono messaggi
-disponibili per la lettura, è di bloccare il processo in stato di
-\textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
+disponibili per la lettura, è di bloccare il processo in stato di
+\textit{sleep}. Nel caso però si sia specificato \const{IPC\_NOWAIT} la
funzione ritorna immediatamente con un errore \errcode{ENOMSG}. Altrimenti la
funzione ritorna normalmente non appena viene inserito un messaggio del tipo
desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
Le code di messaggi presentano il solito problema di tutti gli oggetti del
SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
-anche quando un processo è terminato, al contrario delle pipe per le quali
+anche quando un processo è terminato, al contrario delle pipe per le quali
tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
-utilizzava termina. Questo comporta che in caso di errori si può saturare il
+utilizzava termina. Questo comporta che in caso di errori si può saturare il
sistema, e che devono comunque essere esplicitamente previste delle funzioni
di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
fig.~\ref{fig:ipc_mq_fortune_server}).
-L'altro problema è non facendo uso di file descriptor le tecniche di
+L'altro problema è non facendo uso di file descriptor le tecniche di
\textit{I/O multiplexing} descritte in sez.~\ref{sec:file_multiplexing} non
possono essere utilizzate, e non si ha a disposizione niente di analogo alle
-funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
-una di queste strutture alla volta; ad esempio non si può scrivere un server
-che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
+funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
+una di queste strutture alla volta; ad esempio non si può scrivere un server
+che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
di \itindex{polling} \textit{polling} che esegua un ciclo di attesa su
ciascuna di esse.
\label{fig:ipc_mq_fortune_server}
\end{figure}
-In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
-principali del codice del nuovo server (il codice completo è nel file
-\file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
+In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
+principali del codice del nuovo server (il codice completo è nel file
+\file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
per permettere una comunicazione indipendente fra il server ed i vari client,
-usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
-in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
+usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
+in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
base del loro tipo.
\var{msgbuf\_read} (\texttt{\small 8--11}) vengono passate le richieste mentre
con \var{msgbuf\_write} (\texttt{\small 12--15}) vengono restituite le frasi.
-La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
+La gestione delle opzioni si è al solito omessa, essa si curerà di impostare
in \var{n} il numero di frasi da leggere specificato a linea di comando ed in
\var{fortunefilename} il file da cui leggerle; dopo aver installato
(\texttt{\small 19--21}) i gestori dei segnali per trattare l'uscita dal
server, viene prima controllato (\texttt{\small 22}) il numero di frasi
-richieste abbia senso (cioè sia maggiore di zero), le quali poi
+richieste abbia senso (cioè sia maggiore di zero), le quali poi
(\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
funzione \code{FortuneParse} usata anche per il server basato sulle fifo.
il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small
34}) con il porsi in attesa di un messaggio di richiesta da parte di un
client; si noti infatti come \func{msgrcv} richieda un messaggio con
-\var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
-corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
-del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
+\var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
+corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
+del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del
client).
-Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
+Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
ritornando soltanto in corrispondenza dell'arrivo sulla coda di un messaggio
di richiesta da parte di un client, in tal caso il ciclo prosegue
(\texttt{\small 35}) selezionando una frase a caso, copiandola (\texttt{\small
Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
-L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
-messaggio di risposta. Si tenga conto che se la coda è piena anche questa
-funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
+L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
+messaggio di risposta. Si tenga conto che se la coda è piena anche questa
+funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
-Si noti che il programma può terminare solo grazie ad una interruzione da
-parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
+Si noti che il programma può terminare solo grazie ad una interruzione da
+parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
(\texttt{\small 46}) ed ad uscire (\texttt{\small 47}).
\label{fig:ipc_mq_fortune_client}
\end{figure}
-In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
-del programma client. Al solito il codice completo è con i sorgenti allegati,
+In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
+del programma client. Al solito il codice completo è con i sorgenti allegati,
nel file \file{MQFortuneClient.c}. Come sempre si sono rimosse le parti
relative alla gestione delle opzioni, ed in questo caso, anche la
dichiarazione delle variabili, che, per la parte relative alle strutture usate
per la comunicazione tramite le code, sono le stesse viste in
fig.~\ref{fig:ipc_mq_fortune_server}.
-Il client in questo caso è molto semplice; la prima parte del programma
-(\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
+Il client in questo caso è molto semplice; la prima parte del programma
+(\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
identica a quanto visto per il server, solo che in questo caso \func{msgget}
non viene chiamata con il flag di creazione in quanto la coda deve essere
-preesistente. In caso di errore (ad esempio se il server non è stato avviato)
+preesistente. In caso di errore (ad esempio se il server non è stato avviato)
il programma termina immediatamente.
Una volta acquisito l'identificatore della coda il client compone il
A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
-passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
+passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
messaggio ricevuto.
Proviamo allora il nostro nuovo sistema, al solito occorre definire
[piccardi@gont sources]$ ./mqfortuned -n10
\end{verbatim}%$
come nel caso precedente, avendo eseguito il server in background, il comando
-ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
-programma è effettivamente in esecuzione, e che ha creato una coda di
+ritornerà immediatamente; potremo però verificare con \cmd{ps} che il
+programma è effettivamente in esecuzione, e che ha creato una coda di
messaggi:
\begin{verbatim}
[piccardi@gont sources]$ ipcs
\begin{verbatim}
[piccardi@gont sources]$ ./mqfortune
Linux ext2fs has been stable for a long time, now it's time to break it
- -- Linuxkongreß '95 in Berlin
+ -- Linuxkongreß '95 in Berlin
[piccardi@gont sources]$ ./mqfortune
Let's call it an accidental feature.
--Larry Wall
il server inviando il segnale di terminazione con il comando \code{killall
mqfortuned} verificando che effettivamente la coda di messaggi viene rimossa.
-Benché funzionante questa architettura risente dello stesso inconveniente
+Benché funzionante questa architettura risente dello stesso inconveniente
visto anche nel caso del precedente server basato sulle fifo; se il client
viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
-della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
-il problema delle fifo che restavano nel filesystem). In questo caso però il
-problemi sono maggiori, sia perché è molto più facile esaurire la memoria
+della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
+il problema delle fifo che restavano nel filesystem). In questo caso però il
+problemi sono maggiori, sia perché è molto più facile esaurire la memoria
dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
-sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
+sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
eseguito in un momento successivo potrebbe ricevere un messaggio non
indirizzato a lui.
di protezione per le \index{sezione~critica} \textsl{sezioni critiche} del
codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).
-Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
+Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
-di un programma. In questo modo l'accesso ad una risorsa condivisa da più
-processi può essere controllato, associando ad essa un semaforo che consente
-di assicurare che non più di un processo alla volta possa usarla.
-
-Il concetto di semaforo è uno dei concetti base nella programmazione ed è
-assolutamente generico, così come del tutto generali sono modalità con cui lo
-si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
-controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
-indicando che si è consumato una unità della risorsa, ed il processo potrà
+di un programma. In questo modo l'accesso ad una risorsa condivisa da più
+processi può essere controllato, associando ad essa un semaforo che consente
+di assicurare che non più di un processo alla volta possa usarla.
+
+Il concetto di semaforo è uno dei concetti base nella programmazione ed è
+assolutamente generico, così come del tutto generali sono modalità con cui lo
+si utilizza. Un processo che deve accedere ad una risorsa eseguirà un
+controllo del semaforo: se questo è positivo il suo valore sarà decrementato,
+indicando che si è consumato una unità della risorsa, ed il processo potrà
proseguire nell'utilizzo di quest'ultima, provvedendo a rilasciarla, una volta
completate le operazioni volute, reincrementando il semaforo.
-Se al momento del controllo il valore del semaforo è nullo, siamo invece in
-una situazione in cui la risorsa non è disponibile, ed il processo si
-bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
-rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
-positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
-e si potrà operare come nel caso precedente (decremento del semaforo, accesso
+Se al momento del controllo il valore del semaforo è nullo, siamo invece in
+una situazione in cui la risorsa non è disponibile, ed il processo si
+bloccherà in stato di \textit{sleep} fin quando chi la sta utilizzando non la
+rilascerà, incrementando il valore del semaforo. Non appena il semaforo torna
+positivo, indicando che la risorsa è disponibile, il processo sarà svegliato,
+e si potrà operare come nel caso precedente (decremento del semaforo, accesso
alla risorsa, incremento del semaforo).
Per poter implementare questo tipo di logica le operazioni di controllo e
decremento del contatore associato al semaforo devono essere atomiche,
-pertanto una realizzazione di un oggetto di questo tipo è necessariamente
-demandata al kernel. La forma più semplice di semaforo è quella del
+pertanto una realizzazione di un oggetto di questo tipo è necessariamente
+demandata al kernel. La forma più semplice di semaforo è quella del
\textsl{semaforo binario}, o \textit{mutex}, in cui un valore diverso da zero
-(normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
-della risorsa. In generale però si possono usare semafori con valori interi,
+(normalmente 1) indica la libertà di accesso, e un valore nullo l'occupazione
+della risorsa. In generale però si possono usare semafori con valori interi,
utilizzando il valore del contatore come indicatore del ``numero di risorse''
ancora disponibili.
Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
-permette di creare o ottenere l'identificatore di un insieme di semafori è
-\funcd{semget}, ed il suo prototipo è:
+permette di creare o ottenere l'identificatore di un insieme di semafori è
+\funcd{semget}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Restituisce l'identificatore di un insieme di semafori.
\bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
- in caso di errore, nel qual caso \var{errno} assumerà i valori:
+ in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOSPC}] si è cercato di creare una insieme di semafori
- quando è stato superato o il limite per il numero totale di semafori
+ \item[\errcode{ENOSPC}] si è cercato di creare una insieme di semafori
+ quando è stato superato o il limite per il numero totale di semafori
(\const{SEMMNS}) o quello per il numero totale degli insiemi
(\const{SEMMNI}) nel sistema.
- \item[\errcode{EINVAL}] l'argomento \param{nsems} è minore di zero o
+ \item[\errcode{EINVAL}] l'argomento \param{nsems} è minore di zero o
maggiore del limite sul numero di semafori per ciascun insieme
- (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
+ (\const{SEMMSL}), o se l'insieme già esiste, maggiore del numero di
semafori che contiene.
\item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
contenere le strutture per un nuovo insieme di semafori.
\errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
\end{functions}
-La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
-restituisce l'identificatore di un insieme di semafori, in particolare è
+La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
+restituisce l'identificatore di un insieme di semafori, in particolare è
identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
\param{nsems} permette di specificare quanti semafori deve contenere l'insieme
quando se ne richieda la creazione, e deve essere nullo quando si effettua una
-richiesta dell'identificatore di un insieme già esistente.
+richiesta dell'identificatore di un insieme già esistente.
Purtroppo questa implementazione complica inutilmente lo schema elementare che
-abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
-se ne deve creare per forza un insieme. Ma questa in definitiva è solo una
-complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
-soffrono di altri due, ben più gravi, difetti.
+abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
+se ne deve creare per forza un insieme. Ma questa in definitiva è solo una
+complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
+soffrono di altri due, ben più gravi, difetti.
-Il primo difetto è che non esiste una funzione che permetta di creare ed
+Il primo difetto è che non esiste una funzione che permetta di creare ed
inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
-perde così ogni possibilità di eseguire l'operazione atomicamente.
+perde così ogni possibilità di eseguire l'operazione atomicamente.
Il secondo difetto deriva dalla caratteristica generale degli oggetti del
\textit{SysV IPC} di essere risorse globali di sistema, che non vengono
-cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
+cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
esplicitamente il caso in cui un processo termina per un qualche errore,
-lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
-del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
+lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
+del sistema. Come vedremo esistono delle modalità per evitare tutto ciò, ma
diventa necessario indicare esplicitamente che si vuole il ripristino del
semaforo all'uscita del processo.
\label{fig:ipc_semid_ds}
\end{figure}
-A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
+A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
riportata in fig.~\ref{fig:ipc_semid_ds}.\footnote{non si sono riportati i
campi ad uso interno del kernel, che vedremo in
fig.~\ref{fig:ipc_sem_schema}, che dipendono dall'implementazione.} Come nel
\func{semget} questa struttura viene inizializzata, in particolare il campo
\var{sem\_perm} viene inizializzato come illustrato in
sez.~\ref{sec:ipc_sysv_access_control} (si ricordi che in questo caso il
-permesso di scrittura è in realtà permesso di alterare il semaforo), per
+permesso di scrittura è in realtà permesso di alterare il semaforo), per
quanto riguarda gli altri campi invece:
\begin{itemize*}
\item il campo \var{sem\_nsems}, che esprime il numero di semafori
effettuata, viene inizializzato a zero.
\end{itemize*}
-Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
+Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
\struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
- è riportata la definizione originaria del kernel 1.0, che contiene la prima
- realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
- ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
- dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
+ è riportata la definizione originaria del kernel 1.0, che contiene la prima
+ realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
+ ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
+ dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
- citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
-Questa struttura, non è accessibile in user space, ma i valori in essa
+ citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
+Questa struttura, non è accessibile in user space, ma i valori in essa
specificati possono essere letti in maniera indiretta, attraverso l'uso delle
funzioni di controllo.
direttamente nel file \procfile{/proc/sys/kernel/sem}.
La funzione che permette di effettuare le varie operazioni di controllo sui
-semafori (fra le quali, come accennato, è impropriamente compresa anche la
-loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
+semafori (fra le quali, come accennato, è impropriamente compresa anche la
+loro inizializzazione) è \funcd{semctl}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\bodydesc{La funzione restituisce in caso di successo un valore positivo
quanto usata con tre argomenti ed un valore nullo quando usata con
- quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
+ quattro. In caso di errore restituisce -1, ed \var{errno} assumerà uno dei
valori:
\begin{errlist}
\item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
l'operazione richiesta.
- \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
- \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
+ \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
+ \item[\errcode{EPERM}] si è richiesto \const{IPC\_SET} o \const{IPC\_RMID}
ma il processo non ha privilegi sufficienti ad eseguire l'operazione.
- \item[\errcode{ERANGE}] si è richiesto \const{SETALL} \const{SETVAL} ma il
- valore a cui si vuole impostare il semaforo è minore di zero o maggiore
+ \item[\errcode{ERANGE}] si è richiesto \const{SETALL} \const{SETVAL} ma il
+ valore a cui si vuole impostare il semaforo è minore di zero o maggiore
di \const{SEMVMX}.
\end{errlist}
ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
\end{functions}
-La funzione può avere tre o quattro argomenti, a seconda dell'operazione
+La funzione può avere tre o quattro argomenti, a seconda dell'operazione
specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
\param{semid} o sul singolo semaforo di un insieme, specificato da
\param{semnum}.
\label{fig:ipc_semun}
\end{figure}
-Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
-generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
+Qualora la funzione operi con quattro argomenti \param{arg} è un argomento
+generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
-definizione, con i possibili valori che può assumere, è riportata in
+definizione, con i possibili valori che può assumere, è riportata in
fig.~\ref{fig:ipc_semun}.
-Come già accennato sia il comportamento della funzione che il numero di
+Come già accennato sia il comportamento della funzione che il numero di
argomenti con cui deve essere invocata dipendono dal valore dell'argomento
\param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
-cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
+cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\const{IPC\_STAT}] Legge i dati dell'insieme di semafori, copiando il
Il valore di ritorno della funzione in caso di successo dipende
dall'operazione richiesta; per tutte le operazioni che richiedono quattro
-argomenti esso è sempre nullo, per le altre operazioni, elencate in
+argomenti esso è sempre nullo, per le altre operazioni, elencate in
tab.~\ref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
corrispondente al campo della struttura \struct{sem} indicato nella seconda
colonna della tabella.
Le operazioni ordinarie sui semafori, come l'acquisizione o il rilascio degli
stessi (in sostanza tutte quelle non comprese nell'uso di \func{semctl})
-vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
+vengono effettuate con la funzione \funcd{semop}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Esegue le operazioni ordinarie su un semaforo o un insieme di semafori.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] il processo non ha i privilegi per eseguire
l'operazione richiesta.
- \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
- \item[\errcode{ENOMEM}] si è richiesto un \const{SEM\_UNDO} ma il sistema
+ \item[\errcode{EIDRM}] l'insieme di semafori è stato cancellato.
+ \item[\errcode{ENOMEM}] si è richiesto un \const{SEM\_UNDO} ma il sistema
non ha le risorse per allocare la struttura di ripristino.
\item[\errcode{EAGAIN}] un'operazione comporterebbe il blocco del processo,
- ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
+ ma si è specificato \const{IPC\_NOWAIT} in \var{sem\_flg}.
\item[\errcode{EINTR}] la funzione, bloccata in attesa dell'esecuzione
dell'operazione, viene interrotta da un segnale.
- \item[\errcode{E2BIG}] l'argomento \param{nsops} è maggiore del numero
+ \item[\errcode{E2BIG}] l'argomento \param{nsops} è maggiore del numero
massimo di operazioni \const{SEMOPM}.
\item[\errcode{ERANGE}] per alcune operazioni il valore risultante del
semaforo viene a superare il limite massimo \const{SEMVMX}.
effettuare viene specificato con l'argomento \param{nsop}, mentre il loro
contenuto viene passato con un puntatore ad un vettore di strutture
\struct{sembuf} nell'argomento \param{sops}. Le operazioni richieste vengono
-effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
+effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Il contenuto di ciascuna operazione deve essere specificato attraverso una
-opportuna struttura \struct{sembuf} (la cui definizione è riportata in
+opportuna struttura \struct{sembuf} (la cui definizione è riportata in
fig.~\ref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
allocare in un opportuno vettore. La struttura permette di indicare il
semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
vettore, per cui il primo semaforo corrisponde ad un valore nullo di
\var{sem\_num}.
-Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
+Il campo \var{sem\_flg} è un flag, mantenuto come maschera binaria, per il
quale possono essere impostati i due valori \const{IPC\_NOWAIT} e
\const{SEM\_UNDO}. Impostando \const{IPC\_NOWAIT} si fa si che, invece di
bloccarsi (in tutti quei casi in cui l'esecuzione di una operazione richiede
si richiede invece che l'operazione venga registrata in modo che il valore del
semaforo possa essere ripristinato all'uscita del processo.
-Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
+Infine \var{sem\_op} è il campo che controlla l'operazione che viene eseguita
e determina il comportamento della chiamata a \func{semop}; tre sono i casi
possibili:
\begin{basedescript}{\desclabelwidth{2.0cm}}
immediatamente (con un errore di \errcode{ERANGE} qualora si sia superato il
limite \const{SEMVMX}) ed il processo non viene bloccato in nessun caso.
Specificando \const{SEM\_UNDO} si aggiorna il contatore per il ripristino
- del valore del semaforo. Al processo chiamante è richiesto il privilegio di
+ del valore del semaforo. Al processo chiamante è richiesto il privilegio di
alterazione (scrittura) sull'insieme di semafori.
\item[\var{sem\_op}$=0$] Nel caso \var{semval} sia zero l'esecuzione procede
- immediatamente. Se \var{semval} è diverso da zero il comportamento è
- controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
+ immediatamente. Se \var{semval} è diverso da zero il comportamento è
+ controllato da \var{sem\_flg}, se è stato impostato \const{IPC\_NOWAIT} la
funzione ritorna con un errore di \errcode{EAGAIN}, altrimenti viene
incrementato \var{semzcnt} di uno ed il processo resta in stato di
\textit{sleep} fintanto che non si ha una delle condizioni seguenti:
viene decrementato di uno e \func{semop} ritorna un errore di
\errcode{EINTR}.
\end{itemize*}
- Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
+ Al processo chiamante è richiesto il privilegio di lettura dell'insieme dei
semafori.
-\item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
- valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
+\item[\var{sem\_op}$<0$] Nel caso in cui \var{semval} è maggiore o uguale del
+ valore assoluto di \var{sem\_op} (se cioè la somma dei due valori resta
positiva o nulla) i valori vengono sommati e la funzione ritorna
immediatamente; qualora si sia impostato \const{SEM\_UNDO} viene anche
aggiornato il contatore per il ripristino del valore del semaforo. In caso
- contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
- negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
+ contrario (quando cioè la somma darebbe luogo ad un valore di \var{semval}
+ negativo) se si è impostato \const{IPC\_NOWAIT} la funzione ritorna con un
errore di \errcode{EAGAIN}, altrimenti viene incrementato di uno
\var{semncnt} ed il processo resta in stato di \textit{sleep} fintanto che
non si ha una delle condizioni seguenti:
viene decrementato di uno e \func{semop} ritorna un errore di
\errcode{EINTR}.
\end{itemize*}
- Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
+ Al processo chiamante è richiesto il privilegio di alterazione (scrittura)
sull'insieme di semafori.
\end{basedescript}
inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
\var{sem\_ctime}.
-Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
+Dato che, come già accennato in precedenza, in caso di uscita inaspettata i
semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
attivare un meccanismo di ripristino attraverso l'uso del flag
-\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
+\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
\struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
strutture disallocate. Per mantenere coerente il comportamento queste
avrebbe un doppio ripristino), mentre passano inalterate nell'esecuzione di
una \func{exec} (altrimenti non si avrebbe ripristino).
-Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
-occorre fare riferimento all'implementazione usata in Linux, che è riportata
-in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}. Si è
-presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
+Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
+occorre fare riferimento all'implementazione usata in Linux, che è riportata
+in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}. Si è
+presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
-struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
-a queste strutture restano per compatibilità.\footnote{in particolare con le
+struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
+a queste strutture restano per compatibilità.\footnote{in particolare con le
vecchie versioni delle librerie del C, come le libc5.}
\begin{figure}[htb]
di \struct{semid\_ds}.}.
Nella struttura viene memorizzato il riferimento alle operazioni richieste
-(nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
+(nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo
stato di attesa e viene invocato lo \itindex{scheduler} scheduler per passare
all'esecuzione di un altro processo.
Se invece tutte le operazioni possono avere successo queste vengono eseguite
immediatamente, dopo di che il kernel esegue una scansione della coda di
attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
-operazioni sospese in precedenza può essere eseguita, nel qual caso la
+operazioni sospese in precedenza può essere eseguita, nel qual caso la
struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
-viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
+viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
svuotata la coda. Per gestire il meccanismo del ripristino tutte le volte che
-per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
+per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
contiene (nel vettore puntato dal campo \var{semadj}) un valore di
aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
Queste strutture sono mantenute in due liste,\footnote{rispettivamente
attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
-strutture se questo viene cancellato o per azzerarle se si è eseguita una
+strutture se questo viene cancellato o per azzerarle se si è eseguita una
operazione con \func{semctl}; l'altra associata al processo che ha eseguito
l'operazione;\footnote{attraverso il campo \var{semundo} di
\struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
processo termina, la lista ad esso associata viene scandita e le operazioni
-applicate al semaforo. Siccome un processo può accumulare delle richieste di
+applicate al semaforo. Siccome un processo può accumulare delle richieste di
ripristino per semafori differenti chiamate attraverso diverse chiamate a
\func{semop}, si pone il problema di come eseguire il ripristino dei semafori
-all'uscita del processo, ed in particolare se questo può essere fatto
+all'uscita del processo, ed in particolare se questo può essere fatto
atomicamente.
-Il punto è cosa succede quando una delle operazioni previste per il ripristino
-non può essere eseguita immediatamente perché ad esempio il semaforo è
+Il punto è cosa succede quando una delle operazioni previste per il ripristino
+non può essere eseguita immediatamente perché ad esempio il semaforo è
occupato; in tal caso infatti, se si pone il processo in stato di
-\textit{sleep} aspettando la disponibilità del semaforo (come faceva
-l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
-fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
+\textit{sleep} aspettando la disponibilità del semaforo (come faceva
+l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
+fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
prevedono un blocco del processo e di ignorare silenziosamente le altre;
-questo però comporta il fatto che il ripristino non è comunque garantito in
+questo però comporta il fatto che il ripristino non è comunque garantito in
tutte le occasioni.
Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
-con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
-in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
+con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
+in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
riportato in fig.~\ref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
creare un insieme contenente un singolo semaforo, per il quale poi useremo un
-valore unitario per segnalare la disponibilità della risorsa, ed un valore
-nullo per segnalarne l'indisponibilità.
+valore unitario per segnalare la disponibilità della risorsa, ed un valore
+nullo per segnalarne l'indisponibilità.
\begin{figure}[!bht]
\footnotesize \centering
\label{fig:ipc_mutex_create}
\end{figure}
-La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
+La prima funzione (\texttt{\small 2--15}) è \func{MutexCreate} che data una
chiave crea il semaforo usato per il mutex e lo inizializza, restituendone
-l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
+l'identificatore. Il primo passo (\texttt{\small 6}) è chiamare \func{semget}
con \const{IPC\_CREATE} per creare il semaforo qualora non esista,
assegnandogli i privilegi di lettura e scrittura per tutti. In caso di errore
(\texttt{\small 7--9}) si ritorna subito il risultato di \func{semget},
altrimenti (\texttt{\small 10}) si inizializza il semaforo chiamando
\func{semctl} con il comando \const{SETVAL}, utilizzando l'unione
\struct{semunion} dichiarata ed avvalorata in precedenza (\texttt{\small 4})
-ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
+ad 1 per significare che risorsa è libera. In caso di errore (\texttt{\small
11--13}) si restituisce il valore di ritorno di \func{semctl}, altrimenti
(\texttt{\small 14}) si ritorna l'identificatore del semaforo.
-La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
+La seconda funzione (\texttt{\small 17--20}) è \func{MutexFind}, che, data una
chiave, restituisce l'identificatore del semaforo ad essa associato. La
-comprensione del suo funzionamento è immediata in quanto essa è soltanto un
-\textit{wrapper}\footnote{si chiama così una funzione usata per fare da
+comprensione del suo funzionamento è immediata in quanto essa è soltanto un
+\textit{wrapper}\footnote{si chiama così una funzione usata per fare da
\textsl{involucro} alla chiamata di un altra, usata in genere per
semplificare un'interfaccia (come in questo caso) o per utilizzare con la
stessa funzione diversi substrati (librerie, ecc.) che possono fornire le
- stesse funzionalità.} di una chiamata a \func{semget} per cercare
+ stesse funzionalità.} di una chiamata a \func{semget} per cercare
l'identificatore associato alla chiave, il valore di ritorno di quest'ultima
viene passato all'indietro al chiamante.
-La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
+La terza funzione (\texttt{\small 22--25}) è \func{MutexRead} che, dato un
identificatore, restituisce il valore del semaforo associato al mutex. Anche
-in questo caso la funzione è un \textit{wrapper} per una chiamata a
+in questo caso la funzione è un \textit{wrapper} per una chiamata a
\func{semctl} con il comando \const{GETVAL}, che permette di restituire il
valore del semaforo.
dell'opzione \const{SEM\_UNDO} per evitare che il semaforo resti bloccato in
caso di terminazione imprevista del processo.
-L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
+L'ultima funzione (\texttt{\small 46--49}) della serie, è \func{MutexRemove},
che rimuove il mutex. Anche in questo caso si ha un wrapper per una chiamata a
\func{semctl} con il comando \const{IPC\_RMID}, che permette di cancellare il
semaforo; il valore di ritorno di quest'ultima viene passato all'indietro.
-Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
-libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
-chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
-rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
+Chiamare \func{MutexLock} decrementa il valore del semaforo: se questo è
+libero (ha già valore 1) sarà bloccato (valore nullo), se è bloccato la
+chiamata a \func{semop} si bloccherà fintanto che la risorsa non venga
+rilasciata. Chiamando \func{MutexUnlock} il valore del semaforo sarà
incrementato di uno, sbloccandolo qualora fosse bloccato.
Si noti che occorre eseguire sempre prima \func{MutexLock} e poi
-\func{MutexUnlock}, perché se per un qualche errore si esegue più volte
+\func{MutexUnlock}, perché se per un qualche errore si esegue più volte
quest'ultima il valore del semaforo crescerebbe oltre 1, e \func{MutexLock}
-non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
+non avrebbe più l'effetto aspettato (bloccare la risorsa quando questa è
considerata libera). Infine si tenga presente che usare \func{MutexRead} per
controllare il valore dei mutex prima di proseguire in una operazione di
sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
\subsection{Memoria condivisa}
\label{sec:ipc_sysv_shm}
-Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
-memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
-ed il suo prototipo è:
+Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
+memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
+ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
Restituisce l'identificatore di una memoria condivisa.
\bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
- in caso di errore, nel qual caso \var{errno} assumerà i valori:
+ in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOSPC}] si è superato il limite (\const{SHMMNI}) sul numero
+ \item[\errcode{ENOSPC}] si è superato il limite (\const{SHMMNI}) sul numero
di segmenti di memoria nel sistema, o cercato di allocare un segmento le
cui dimensioni fanno superare il limite di sistema (\const{SHMALL}) per
la memoria ad essi riservata.
- \item[\errcode{EINVAL}] si è richiesta una dimensione per un nuovo segmento
+ \item[\errcode{EINVAL}] si è richiesta una dimensione per un nuovo segmento
maggiore di \const{SHMMAX} o minore di \const{SHMMIN}, o se il segmento
- già esiste \param{size} è maggiore delle sue dimensioni.
+ già esiste \param{size} è maggiore delle sue dimensioni.
\item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter
contenere le strutture per un nuovo segmento di memoria condivisa.
\end{errlist}
\errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.}
\end{functions}
-La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
-identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
+La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
+identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
\param{size} specifica invece la dimensione, in byte, del segmento, che viene
comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
-La memoria condivisa è la forma più veloce di comunicazione fra due processi,
+La memoria condivisa è la forma più veloce di comunicazione fra due processi,
in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
-stessa sezione di memoria. Pertanto non è necessaria nessuna operazione di
-copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
+stessa sezione di memoria. Pertanto non è necessaria nessuna operazione di
+copia per trasmettere i dati da un processo all'altro, in quanto ciascuno può
accedervi direttamente con le normali operazioni di lettura e scrittura dei
dati in memoria.
Ovviamente tutto questo ha un prezzo, ed il problema fondamentale della
-memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
+memoria condivisa è la sincronizzazione degli accessi. È evidente infatti che
se un processo deve scambiare dei dati con un altro, si deve essere sicuri che
quest'ultimo non acceda al segmento di memoria condivisa prima che il primo
non abbia completato le operazioni di scrittura, inoltre nel corso di una
\label{fig:ipc_shmid_ds}
\end{figure}
-A ciascun segmento di memoria condivisa è associata una struttura
+A ciascun segmento di memoria condivisa è associata una struttura
\struct{shmid\_ds}, riportata in fig.~\ref{fig:ipc_shmid_ds}. Come nel caso
delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
con \func{shmget} questa struttura viene inizializzata, in particolare il
\item il campo \var{shm\_ctime}, che esprime il tempo di creazione del
segmento, viene inizializzato al tempo corrente.
\item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
- rispettivamente il tempo dell'ultima volta che il segmento è stato
+ rispettivamente il tempo dell'ultima volta che il segmento è stato
agganciato o sganciato da un processo, vengono inizializzati a zero.
\item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
eseguito l'ultima operazione, viene inizializzato a zero.
\end{table}
Al solito la funzione che permette di effettuare le operazioni di controllo su
-un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
+un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
\begin{functions}
\headdecl{sys/ipc.h}
\headdecl{sys/shm.h}
Esegue le operazioni di controllo su un segmento di memoria condivisa.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
+ \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
consentono l'accesso in lettura al segmento.
- \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
- \param{cmd} non è un comando valido.
+ \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
+ \param{cmd} non è un comando valido.
\item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un
- segmento che è stato cancellato.
- \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
+ segmento che è stato cancellato.
+ \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
\const{IPC\_RMID} senza i permessi necessari.
- \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
- valore del group-ID o dell'user-ID è troppo grande per essere
+ \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
+ valore del group-ID o dell'user-ID è troppo grande per essere
memorizzato nella struttura puntata da \param{buf}.
- \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
+ \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
valido.
\end{errlist}
}
\end{functions}
Il comando specificato attraverso l'argomento \param{cmd} determina i diversi
-effetti della funzione; i possibili valori che esso può assumere, ed il
+effetti della funzione; i possibili valori che esso può assumere, ed il
corrispondente comportamento della funzione, sono i seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
condivisa nella struttura \struct{shmid\_ds} puntata da \param{buf}. Occorre
che il processo chiamante abbia il permesso di lettura sulla segmento.
\item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
- rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
- processo ad esso agganciato si sarà staccato. Questo comando può essere
+ rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
+ processo ad esso agganciato si sarà staccato. Questo comando può essere
eseguito solo da un processo con user-ID effettivo corrispondente o al
creatore del segmento, o al proprietario del segmento, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
aggiorna anche il valore del campo \var{shm\_ctime}.
\item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
- locking}\footnote{impedisce cioè che la memoria usata per il segmento
+ locking}\footnote{impedisce cioè che la memoria usata per il segmento
venga salvata su disco dal meccanismo della \index{memoria~virtuale}
memoria virtuale; si ricordi quanto trattato in
sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
- l'amministratore può utilizzare questo comando.
+ l'amministratore può utilizzare questo comando.
\item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking}
\textit{memory locking} sul segmento di memoria condivisa. Solo
- l'amministratore può utilizzare questo comando.
+ l'amministratore può utilizzare questo comando.
\end{basedescript}
-i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
+i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
previste da Linux, che permettono di abilitare e disabilitare il meccanismo
della \index{memoria~virtuale} memoria virtuale per il segmento.
L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT}
-e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
+e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
\struct{shmid\_ds} precedentemente allocata, in cui nel primo caso saranno
scritti i dati del segmento di memoria restituiti dalla funzione e da cui, nel
secondo caso, verranno letti i dati da impostare sul segmento.
-Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
+Una volta che lo si è creato, per utilizzare un segmento di memoria condivisa
l'interfaccia prevede due funzioni, \funcd{shmat} e \func{shmdt}. La prima di
queste serve ad agganciare un segmento al processo chiamante, in modo che
quest'ultimo possa inserirlo nel suo spazio di indirizzi per potervi accedere;
-il suo prototipo è:
+il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/shm.h}
Aggancia al processo un segmento di memoria condivisa.
\bodydesc{La funzione restituisce l'indirizzo del segmento in caso di
- successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
+ successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
valori:
\begin{errlist}
\item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
- segmento nella modalità richiesta.
- \item[\errcode{EINVAL}] si è specificato un identificatore invalido per
+ segmento nella modalità richiesta.
+ \item[\errcode{EINVAL}] si è specificato un identificatore invalido per
\param{shmid}, o un indirizzo non allineato sul confine di una pagina
per \param{shmaddr}.
\end{errlist}
La funzione inserisce un segmento di memoria condivisa all'interno dello
spazio di indirizzi del processo, in modo che questo possa accedervi
-direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
+direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
particolare l'indirizzo finale del segmento dati (quello impostato da
\func{brk}, vedi sez.~\ref{sec:proc_mem_alloc}) non viene influenzato.
-Si tenga presente infine che la funzione ha successo anche se il segmento è
+Si tenga presente infine che la funzione ha successo anche se il segmento è
stato marcato per la cancellazione.
\begin{figure}[htb]
\centering
\includegraphics[height=10cm]{img/sh_memory_layout}
- \caption{Disposizione dei segmenti di memoria di un processo quando si è
+ \caption{Disposizione dei segmenti di memoria di un processo quando si è
agganciato un segmento di memoria condivisa.}
\label{fig:ipc_shmem_layout}
\end{figure}
L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
- SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
- come il valore di ritorno della funzione; in Linux è stato così con le
+ SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
+ come il valore di ritorno della funzione; in Linux è stato così con le
\acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
- \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
+ \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
-specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
-memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
+specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
+memoria libera (questo è il modo più portabile e sicuro di usare la funzione).
Altrimenti il kernel aggancia il segmento all'indirizzo specificato da
-\param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
-limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
-\const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}.
+\param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il
+limite di una pagina, cioè se è un multiplo esatto del parametro di sistema
+\const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}.
-Si tenga presente però che quando si usa \val{NULL} come valore di
-\param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
+Si tenga presente però che quando si usa \val{NULL} come valore di
+\param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da
processo a processo; pertanto se nell'area di memoria condivisa si salvano
anche degli indirizzi, si deve avere cura di usare valori relativi (in genere
riferiti all'indirizzo di partenza del segmento).
solo due e sono identificati dalle costanti \const{SHM\_RND} e
\const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico. Specificando
\const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando
-\param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
-un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
-agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
+\param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare
+un valore qualunque per \param{shmaddr}, e il segmento verrà comunque
+agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della
costante sta infatti per \textit{rounded}, e serve per specificare un
-indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
+indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}).
L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
-caso un tentativo di scrivere sul segmento comporterà una
+caso un tentativo di scrivere sul segmento comporterà una
\itindex{segment~violation} violazione di accesso con l'emissione di un
-segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
+segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo
-deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
+deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
di agganciare un segmento in sola scrittura.
In caso di successo la funzione aggiorna anche i seguenti campi di
automaticamente sganciati. Lo stesso avviene all'uscita del processo
attraverso una \func{exit}.
-Una volta che un segmento di memoria condivisa non serve più, si può
+Una volta che un segmento di memoria condivisa non serve più, si può
sganciarlo esplicitamente dal processo usando l'altra funzione
-dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
+dell'interfaccia, \funcd{shmdt}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/shm.h}
Sgancia dal processo un segmento di memoria condivisa.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore, la funzione fallisce solo quando non c'è un segmento agganciato
+ errore, la funzione fallisce solo quando non c'è un segmento agganciato
all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore
\errval{EINVAL}.}
\end{functions}
Come esempio di uso di queste funzioni vediamo come implementare una serie di
funzioni di libreria che ne semplifichino l'uso, automatizzando le operazioni
-più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
+più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
fig.~\ref{fig:ipc_sysv_shm_func}.
-La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
+La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
chiave, crea il segmento di memoria condivisa restituendo il puntatore allo
stesso. La funzione comincia (\texttt{\small 6}) con il chiamare
\func{shmget}, usando il flag \const{IPC\_CREATE} per creare il segmento
segmento al valore costante specificato dall'argomento \var{fill}, e poi si
ritorna il puntatore al segmento stesso.
-La seconda funzione (\texttt{\small 17--31}) è \func{ShmFind}, che, data una
+La seconda funzione (\texttt{\small 17--31}) è \func{ShmFind}, che, data una
chiave, restituisce l'indirizzo del segmento ad essa associato. Anzitutto
(\texttt{\small 22}) si richiede l'identificatore del segmento con
\func{shmget}, ritornando (\texttt{\small 23--25}) un puntatore nullo in caso
puntatore nullo in caso di errore, se invece non ci sono errori si restituisce
il puntatore ottenuto da \func{shmat}.
-La terza funzione (\texttt{\small 32--51}) è \func{ShmRemove} che, data la
+La terza funzione (\texttt{\small 32--51}) è \func{ShmRemove} che, data la
chiave ed il puntatore associati al segmento di memoria condivisa, prima lo
-sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
+sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
la chiamata a \func{shmdt} per sganciare il segmento, restituendo
(\texttt{\small 38--39}) un valore -1 in caso di errore. Il passo successivo
-(\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
+(\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
associato al segmento data la chiave \var{key}. Al solito si restituisce un
valore di -1 (\texttt{\small 42--45}) in caso di errore, mentre se tutto va
bene si conclude restituendo un valore nullo.
-Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
-fra processi più veloce, essa non è sempre il più appropriato, dato che, come
-abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
-accessi. Per questo motivo, quando la comunicazione fra processi è
+Benché la memoria condivisa costituisca il meccanismo di intercomunicazione
+fra processi più veloce, essa non è sempre il più appropriato, dato che, come
+abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
+accessi. Per questo motivo, quando la comunicazione fra processi è
sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
-l'unico meccanismo possibile quando la comunicazione non è
+l'unico meccanismo possibile quando la comunicazione non è
sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
comunicazione non sequenziale si possono usare le code di messaggi,
- attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
- effettuata in forma di messaggio.} o quando non può avvenire secondo una
-modalità predefinita.
+ attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
+ effettuata in forma di messaggio.} o quando non può avvenire secondo una
+modalità predefinita.
-Un esempio classico di uso della memoria condivisa è quello del
+Un esempio classico di uso della memoria condivisa è quello del
``\textit{monitor}'', in cui viene per scambiare informazioni fra un processo
server, che vi scrive dei dati di interesse generale che ha ottenuto, e i
-processi client interessati agli stessi dati che così possono leggerli in
+processi client interessati agli stessi dati che così possono leggerli in
maniera completamente asincrona. Con questo schema di funzionamento da una
parte si evita che ciascun processo client debba compiere l'operazione,
potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
client).
Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un
-processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
+processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
una directory (il numero dei file contenuti, la dimensione totale, quante
directory, link simbolici, file normali, ecc.) che saranno salvati in un
segmento di memoria condivisa cui altri processi potranno accedere per
ricavare la parte di informazione che interessa.
-In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
+In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
corpo del programma server, insieme alle definizioni delle altre funzioni
usate nel programma e delle variabili globali, omettendo tutto quello che
riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
\end{figure}
Il programma usa delle variabili globali (\texttt{\small 2--14}) per mantenere
-i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
+i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
-relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
+relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
l'accesso da parte dei client.
Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
riga di comando (che si limitano alla eventuale stampa di un messaggio di
aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
-ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
+ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
20--23}) che sia stato specificato l'argomento necessario contenente il nome
della directory da tenere sotto controllo, senza il quale esce immediatamente
con un messaggio di errore.
immediatamente in caso di errore. Questa funzione serve anche per impostare
la directory di lavoro del programma nella directory da tenere sotto
controllo, in vista del successivo uso della funzione
-\func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
+\func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
particolare scopo del programma, che necessita comunque di restare
all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
programma che deve essere eseguito come server, sono il solo strumento
disponibile per concluderne l'esecuzione.
-Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di
+Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di
intercomunicazione necessari. Si inizia costruendo (\texttt{\small 30}) la
-chiave da usare come riferimento con il nome del programma,\footnote{si è
+chiave da usare come riferimento con il nome del programma,\footnote{si è
usato un riferimento relativo alla home dell'utente, supposto che i sorgenti
di GaPiL siano stati installati direttamente in essa. Qualora si effettui
- una installazione diversa si dovrà correggere il programma.} dopo di che si
+ una installazione diversa si dovrà correggere il programma.} dopo di che si
richiede (\texttt{\small 31}) la creazione di un segmento di memoria condivisa
con usando la funzione \func{ShmCreate} illustrata in precedenza (una pagina
-di memoria è sufficiente per i dati che useremo), uscendo (\texttt{\small
+di memoria è sufficiente per i dati che useremo), uscendo (\texttt{\small
32--35}) qualora la creazione ed il successivo agganciamento al processo non
-abbia successo. Con l'indirizzo \var{shmptr} così ottenuto potremo poi
+abbia successo. Con l'indirizzo \var{shmptr} così ottenuto potremo poi
accedere alla memoria condivisa, che, per come abbiamo lo abbiamo definito,
-sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
+sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
36--39}) utilizzando sempre la stessa chiave, si crea, tramite le funzioni
-di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
+di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
che utilizzeremo per regolare l'accesso alla memoria condivisa.
\begin{figure}[!htb]
Completata l'inizializzazione e la creazione degli oggetti di
intercomunicazione il programma entra nel ciclo principale (\texttt{\small
- 40--49}) dove vengono eseguite indefinitamente le attività di monitoraggio.
-Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
+ 40--49}) dove vengono eseguite indefinitamente le attività di monitoraggio.
+Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
con l'esecuzione in background come si conviene ad un programma demone; si
-noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-directory di lavoro corrente. Una volta che il programma è andato in
+noti che si è mantenuta, usando un valore non nullo del primo argomento, la
+directory di lavoro corrente. Una volta che il programma è andato in
background l'esecuzione prosegue (\texttt{\small 42--48}) all'interno di un
ciclo infinito: si inizia (\texttt{\small 43}) bloccando il mutex con
\func{MutexLock} per poter accedere alla memoria condivisa (la funzione si
-bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
+bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
44}) si cancellano i valori precedentemente immagazzinati nella memoria
condivisa con \func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo
degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
l'opzione \code{-p} con una \func{sleep}.
Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
-sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
+sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
effettuare la scansione delle voci della directory, chiamando per ciascuna di
esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
-Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
-Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
+Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
+Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
a chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
contatori nella memoria condivisa, cui accede grazie alla variabile globale
\var{shmptr}.
-Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
-principale del programma, con un mutex acquisito, perciò non è necessario
-effettuare nessun controllo e si può accedere direttamente alla memoria
+Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
+principale del programma, con un mutex acquisito, perciò non è necessario
+effettuare nessun controllo e si può accedere direttamente alla memoria
condivisa usando \var{shmptr} per riempire i campi della struttura
-\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
+\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
dei file ed il loro numero, poi, utilizzando le macro di
tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
ne sono per ciascun tipo.
-In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
+In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
(\texttt{\small 17--23}) del gestore dei segnali di terminazione, usato per
chiudere il programma. Esso, oltre a provocare l'uscita del programma, si
-incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
+incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
necessari. Per questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
\func{MutexLock}, per evitare di operare mentre un client sta ancora leggendo
i dati, dopo di che (\texttt{\small 20}) distacca e rimuove il segmento di
\includecodesample{listati/ReadMonitor.c}
\end{minipage}
\normalsize
- \caption{Codice del programma client del monitor delle proprietà di una
+ \caption{Codice del programma client del monitor delle proprietà di una
directory, \file{ReadMonitor.c}.}
\label{fig:ipc_dirmonitor_client}
\end{figure}
Il codice del client usato per leggere le informazioni mantenute nella memoria
-condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
+condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
omessa la sezione di gestione delle opzioni e la funzione che stampa a video
-le istruzioni; il codice completo è nei sorgenti allegati, nel file
+le istruzioni; il codice completo è nei sorgenti allegati, nel file
\file{ReadMonitor.c}.
Una volta conclusa la gestione delle opzioni a riga di comando il programma
di intercomunicazione necessari viene eseguito il corpo principale del
programma (\texttt{\small 21--33}); si comincia (\texttt{\small 22})
acquisendo il mutex con \func{MutexLock}; qui avviene il blocco del processo
-se la memoria condivisa non è disponibile. Poi (\texttt{\small 23--31}) si
+se la memoria condivisa non è disponibile. Poi (\texttt{\small 23--31}) si
stampano i vari valori mantenuti nella memoria condivisa attraverso l'uso di
\var{shmptr}. Infine (\texttt{\small 41}) con \func{MutexUnlock} si rilascia
il mutex, prima di uscire.
Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando
le funzioni di libreria occorre definire opportunamente
-\code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
+\code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con:
\begin{Verbatim}
[piccardi@gont sources]$ ./dirmonitor ./
\end{Verbatim}
%$
-ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
-che il server è in esecuzione, possiamo passare ad invocare il client per
+ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta
+che il server è in esecuzione, possiamo passare ad invocare il client per
verificarne i risultati, in tal caso otterremo:
\begin{Verbatim}
[piccardi@gont sources]$ ./readmon
\end{Verbatim}
%$
ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci
-permette di verificare che il totale dei file è giusto. Un controllo con
+permette di verificare che il totale dei file è giusto. Un controllo con
\cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di
memoria condivisa e di un semaforo:
\begin{Verbatim}
%% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
%% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
-%% condivisa; uno schema semplificato della struttura è illustrato in
+%% condivisa; uno schema semplificato della struttura è illustrato in
%% fig.~\ref{fig:ipc_shm_struct}.
%% \begin{figure}[htb]
descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
capitolo 14.} Stevens ne effettua una accurata analisi (alcuni dei concetti
-sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
+sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
alternative, che vogliamo riprendere in questa sezione.
Le code di messaggi sono probabilmente il meno usato degli oggetti del
\textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
-disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
-utilizzando una coppia di pipe, si può ottenere questo risultato senza
+disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
+utilizzando una coppia di pipe, si può ottenere questo risultato senza
incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
-In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
+In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
hanno delle caratteristiche ulteriori, consentendo una classificazione dei
messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A
-queste esigenze però si può comunque ovviare in maniera diversa con un uso
+queste esigenze però si può comunque ovviare in maniera diversa con un uso
combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
-cui alla fine l'uso delle code di messaggi classiche è relativamente poco
+cui alla fine l'uso delle code di messaggi classiche è relativamente poco
diffuso.
\subsection{I \textsl{file di lock}}
presentano una interfaccia inutilmente complessa e con alcuni difetti
strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
per la quale basterebbe un semaforo binario (quello che abbiamo definito come
-\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
-necessità di un contatore come i semafori, si possono utilizzare metodi
+\textit{mutex}), per indicare la disponibilità o meno di una risorsa, senza la
+necessità di un contatore come i semafori, si possono utilizzare metodi
alternativi.
-La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
+La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
\file{/var/lock}, nel filesystem standard). Per questo si usa la
caratteristica della funzione \func{open} (illustrata in
-sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
- standard POSIX.1, ciò non toglie che in alcune implementazioni questa
+sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
+ standard POSIX.1, ciò non toglie che in alcune implementazioni questa
tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
- è comunque soggetti alla possibilità di una \itindex{race~condition}
+ è comunque soggetti alla possibilità di una \itindex{race~condition}
\textit{race condition}.} che essa ritorni un errore quando usata con i
flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di un
-\textsl{file di lock} può essere eseguita atomicamente, il processo che crea
-il file con successo si può considerare come titolare del lock (e della
-risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
+\textsl{file di lock} può essere eseguita atomicamente, il processo che crea
+il file con successo si può considerare come titolare del lock (e della
+risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
ad \func{unlink}.
-Un esempio dell'uso di questa funzione è mostrato dalle funzioni
+Un esempio dell'uso di questa funzione è mostrato dalle funzioni
\func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock}
(sono contenute in \file{LockFile.c}, un altro dei sorgenti allegati alla
guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
- lock}. Come si può notare entrambe le funzioni sono elementari; la prima
+ lock}. Come si può notare entrambe le funzioni sono elementari; la prima
(\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
- 9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
+ 9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
cancella con \func{unlink}.
\begin{figure}[!htb]
\label{fig:ipc_file_lock}
\end{figure}
-Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
-sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
-funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
-dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
-caso si può adottare una tecnica alternativa che prevede l'uso della
+Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
+sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
+funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
+dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
+caso si può adottare una tecnica alternativa che prevede l'uso della
\func{link} per creare come \textsl{file di lock} un hard link ad un file
-esistente; se il link esiste già e la funzione fallisce, significa che la
-risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
-altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
+esistente; se il link esiste già e la funzione fallisce, significa che la
+risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
+altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro
-difetto è che è quello di poterla usare solo se si opera all'interno di uno
+difetto è che è quello di poterla usare solo se si opera all'interno di uno
stesso filesystem.
In generale comunque l'uso di un \textsl{file di lock} presenta parecchi
problemi che non lo rendono una alternativa praticabile per la
sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
-sempre cancellata esplicitamente. Inoltre il controllo della disponibilità
-può essere eseguito solo con una tecnica di \itindex{polling}
-\textit{polling}, ed è quindi molto inefficiente.
+sempre cancellata esplicitamente. Inoltre il controllo della disponibilità
+può essere eseguito solo con una tecnica di \itindex{polling}
+\textit{polling}, ed è quindi molto inefficiente.
-La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
-con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
-risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
+La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
+con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
+risorsa, senza necessità di attendere che questa si liberi; ad esempio la si
usa spesso per evitare interferenze sull'uso delle porte seriali da parte di
-più programmi: qualora si trovi un file di lock il programma che cerca di
-accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
+più programmi: qualora si trovi un file di lock il programma che cerca di
+accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
\index{file!di lock|)}
\label{sec:ipc_lock_file}
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}
+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
-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
-attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
-determinare la disponibilità della risorsa, e al rilascio della stessa da
-parte del processo che la occupava si otterrà il nuovo lock atomicamente.
+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
+attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per
+determinare la disponibilità della risorsa, e al rilascio della stessa da
+parte del processo che la occupava si otterrà il nuovo lock atomicamente.
Questo approccio presenta il notevole vantaggio che alla terminazione di un
processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
chiusura dei relativi file) e non ci si deve preoccupare di niente; inoltre
-non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
-dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
-leggermente più lento.
+non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
+dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
+leggermente più lento.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Il codice delle varie funzioni usate per implementare un mutex utilizzando il
-\textit{file locking} \index{file!locking} è riportato in
-fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
+\textit{file locking} \index{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
riguarda la rimozione del mutex.
-La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
-creare il mutex; la funzione è estremamente semplice, e si limita
+La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
+creare il mutex; la funzione è estremamente semplice, e si limita
(\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il
-file che sarà usato per il successivo \textit{file locking}, assicurandosi che
-non esista già (nel qual caso segnala un errore); poi restituisce il file
-descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
+file che sarà usato per il successivo \textit{file locking}, assicurandosi che
+non esista già (nel qual caso segnala un errore); poi restituisce il file
+descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
mutex.
-La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
-precedente, è stata definita per mantenere una analogia con la corrispondente
+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},
solo che in questo caso le opzioni di \func{open} sono tali che il file in
-questione deve esistere di già.
+questione deve esistere di già.
-La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
+La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza
(\texttt{\small 16--19}) la struttura \var{lock} da usare per acquisire un
write lock sul file, che poi (\texttt{\small 21}) viene richiesto con
-\func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
+\func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
libero il lock viene acquisito e la funzione ritorna immediatamente;
-altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
+altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
\const{F\_SETLKW}) fino al rilascio del lock.
-La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
-rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
+La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
+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
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.
+eseguito il lock può sbloccare il mutex.
-La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
-cancellare il mutex. Anche questa funzione è stata definita per mantenere una
+La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
+cancellare il mutex. Anche questa funzione è stata definita per mantenere una
analogia con le funzioni basate sui semafori, e si limita a cancellare
(\texttt{\small 38}) il file con una chiamata ad \func{unlink}. Si noti che in
-questo caso la funzione non ha effetto sui mutex già ottenuti con precedenti
+questo caso la funzione non ha effetto sui mutex già ottenuti con precedenti
chiamate a \func{FindMutex} o \func{CreateMutex}, che continueranno ad essere
disponibili fintanto che i relativi file descriptor restano aperti. Pertanto
-per rilasciare un mutex occorrerà prima chiamare \func{UnlockMutex} oppure
+per rilasciare un mutex occorrerà prima chiamare \func{UnlockMutex} oppure
chiudere il file usato per il lock.
-La sesta funzione (\texttt{\small 41--55}) è \func{ReadMutex} e serve a
+La sesta funzione (\texttt{\small 41--55}) è \func{ReadMutex} e serve a
leggere lo stato del mutex. In questo caso si prepara (\texttt{\small 46--49})
la solita struttura \var{lock} come l'acquisizione del lock, ma si effettua
(\texttt{\small 51}) la chiamata a \func{fcntl} usando il comando
\const{F\_GETLK} per ottenere lo stato del lock, e si restituisce
(\texttt{\small 52}) il valore di ritorno in caso di errore, ed il valore del
campo \var{l\_type} (che descrive lo stato del lock) altrimenti
-(\texttt{\small 54}). Per questo motivo la funzione restituirà -1 in caso di
+(\texttt{\small 54}). Per questo motivo la funzione restituirà -1 in caso di
errore e uno dei due valori \const{F\_UNLCK} o \const{F\_WRLCK}\footnote{non
si dovrebbe mai avere il terzo valore possibile, \const{F\_RDLCK}, dato che
- la nostra interfaccia usa solo i write lock. Però è sempre possibile che
+ la nostra interfaccia usa solo i write lock. Però è sempre possibile che
siano richiesti altri lock sul file al di fuori dell'interfaccia, nel qual
caso si potranno avere, ovviamente, interferenze indesiderate.} in caso di
-successo, ad indicare che il mutex è, rispettivamente, libero o occupato.
+successo, ad indicare che il mutex è, rispettivamente, libero o occupato.
Basandosi sulla semantica dei file lock POSIX valgono tutte le considerazioni
relative al comportamento di questi ultimi fatte in
sez.~\ref{sec:file_posix_lock}; questo significa ad esempio che, al contrario
di quanto avveniva con l'interfaccia basata sui semafori, chiamate multiple a
-\func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
+\func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
nessun inconveniente.
\label{sec:ipc_mmap_anonymous}
\itindbeg{memory~mapping}
-Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
- cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
-una valida alternativa alle code di messaggi; nella stessa situazione si può
+Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
+ cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
+una valida alternativa alle code di messaggi; nella stessa situazione si può
evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
\textit{memory mapping} anonimo.
contenuto di un file nella memoria di un processo, e che, quando viene usato
il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
-tecnica per creare una memoria condivisa fra processi diversi è estremamente
-inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
+tecnica per creare una memoria condivisa fra processi diversi è estremamente
+inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo
visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS}
la regione mappata non viene associata a nessun file, anche se quanto scritto
-rimane in memoria e può essere riletto; allora, dato che un processo figlio
-mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
-anche in grado di accedere a quanto in esse è contenuto.
+rimane in memoria e può essere riletto; allora, dato che un processo figlio
+mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà
+anche in grado di accedere a quanto in esse è contenuto.
In questo modo diventa possibile creare una memoria condivisa fra processi
-diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
+diversi, purché questi abbiano almeno un progenitore comune che ha effettuato
il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
- funzionalità simile a questa viene implementata mappando il file speciale
+ funzionalità simile a questa viene implementata mappando il file speciale
\file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
vengono ignorati (come accade qualora si scriva direttamente sul file), ma
- restano in memoria e possono essere riletti secondo le stesse modalità usate
+ restano in memoria e possono essere riletti secondo le stesse modalità usate
nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
-più avanti, quando realizzeremo una nuova versione del monitor visto in
+più avanti, quando realizzeremo una nuova versione del monitor visto in
sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
\itindend{memory~mapping}
\label{sec:ipc_posix_generic}
Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
-ma a lungo non è stato così; la memoria condivisa è presente a partire dal
+ma a lungo non è stato così; la memoria condivisa è presente a partire dal
kernel 2.4.x, i semafori sono forniti dalle \acr{glibc} nella sezione che
implementa i \itindex{thread} \textit{thread} POSIX di nuova generazione che
richiedono il kernel 2.6, le code di messaggi sono supportate a partire dal
kernel 2.6.6.
-La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
+La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
\itindex{POSIX~IPC~names} \textit{POSIX IPC names}, che sono sostanzialmente
equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
POSIX prendono come primo argomento una stringa che indica uno di questi nomi;
-lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
-possono avere o meno una corrispondenza sul filesystem; tutto quello che è
-richiesto è che:
+lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
+possono avere o meno una corrispondenza sul filesystem; tutto quello che è
+richiesto è che:
\begin{itemize*}
\item i nomi devono essere conformi alle regole che caratterizzano i
- \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
+ \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
\const{PATH\_MAX} byte e terminati da un carattere nullo.
\item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
dall'implementazione.
\end{itemize*}
-Data la assoluta genericità delle specifiche, il comportamento delle funzioni
-è subordinato in maniera quasi completa alla relativa
+Data la assoluta genericità delle specifiche, il comportamento delle funzioni
+è subordinato in maniera quasi completa alla relativa
implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso
come un esempio della maniera standard usata dallo standard POSIX per
consentire implementazioni non standardizzabili.} Nel caso di Linux, sia per
\itindsub{pathname}{assoluto} \textit{pathname} assoluto (comprendente
eventuali sottodirectory) rispetto a queste radici.
-Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
+Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
nell'albero dei file, e possono essere maneggiati con le usuali funzioni e
-comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa
- una implementazione che lo consente, non è detto che altrettanto valga per
- altri kernel; in particolare, come si può facilmente verificare con uno
+comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa
+ una implementazione che lo consente, non è detto che altrettanto valga per
+ altri kernel; in particolare, come si può facilmente verificare con uno
\cmd{strace}, sia per la memoria condivisa che per le code di messaggi le
system call utilizzate da Linux sono le stesse di quelle dei file, essendo
detti oggetti realizzati come tali in appositi filesystem.} che funzionano
sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
-secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
+secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
del processo che esegue la creazione.
\label{sec:ipc_posix_mq}
Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
-2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
+2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
Krzysztof Benedyczak, e le relative informazioni si possono trovare su
\href{http://www.geocities.com/wronski12/posix_ipc/index.html}
{\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
-usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
-che in casi più complessi la comunicazione può essere gestita direttamente con
-mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
+usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
+che in casi più complessi la comunicazione può essere gestita direttamente con
+mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel
superiore al 2.6.6 (o precedente, se sono stati opportunamente applicati i
relativi patch) occorre utilizzare la libreria \file{libmqueue}\footnote{i
- programmi che usano le code di messaggi cioè devono essere compilati
+ programmi che usano le code di messaggi cioè devono essere compilati
aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}; in
corrispondenza all'inclusione del supporto nel kernel ufficiale anche
- \file{libmqueue} è stata inserita nelle \acr{glibc}, a partire dalla
+ \file{libmqueue} è stata inserita nelle \acr{glibc}, a partire dalla
versione 2.3.4 delle medesime.} che contiene le funzioni dell'interfaccia
-POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
+POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
opportune chiamate ad \func{ioctl} sui file del filesystem speciale su cui
vengono mantenuti questi oggetti di IPC.}
La libreria inoltre richiede la presenza dell'apposito filesystem di tipo
-\texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
+\texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
aggiungendo ad \conffile{/etc/fstab} una riga come:
\begin{verbatim}
mqueue /dev/mqueue mqueue defaults 0 0
\end{verbatim}
-ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle
+ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle
code di messaggi che iniziano con una ``\texttt{/}''. Le opzioni di mount
accettate sono \texttt{uid}, \texttt{gid} e \texttt{mode} che permettono
rispettivamente di impostare l'utente, il gruppo ed i permessi associati al
La funzione che permette di aprire (e crearla se non esiste ancora) una coda
-di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
+di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
\begin{functions}
\headdecl{mqueue.h}
Apre una coda di messaggi POSIX impostandone le caratteristiche.
\bodydesc{La funzione restituisce il descrittore associato alla coda in caso
- di successo e -1 per un errore; nel quel caso \var{errno} assumerà i
+ di successo e -1 per un errore; nel quel caso \var{errno} assumerà i
valori:
\begin{errlist}
\item[\errcode{EACCES}] il processo non ha i privilegi per accedere al
alla memoria secondo quanto specificato da \param{oflag}.
- \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e
- \const{O\_EXCL} ma la coda già esiste.
- \item[\errcode{EINVAL}] il file non supporta la funzione, o si è
+ \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e
+ \const{O\_EXCL} ma la coda già esiste.
+ \item[\errcode{EINVAL}] il file non supporta la funzione, o si è
specificato \const{O\_CREAT} con una valore non nullo di \param{attr} e
valori non validi di \var{mq\_maxmsg} e \var{mq\_msgsize}.
- \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda
+ \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda
non esiste.
\end{errlist}
ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT},
restituendo il descrittore ad essa associato, del tutto analogo ad un file
descriptor, con l'unica differenza che lo standard prevede un apposito tipo
\type{mqd\_t}.\footnote{nel caso di Linux si tratta in effetti proprio di un
- normale file descriptor; pertanto, anche se questo comportamento non è
- portabile, lo si può tenere sotto osservazione con le funzioni dell'I/O
+ normale file descriptor; pertanto, anche se questo comportamento non è
+ portabile, lo si può tenere sotto osservazione con le funzioni dell'I/O
multiplexing (vedi sez.~\ref{sec:file_multiplexing}) come possibile
alternativa all'uso dell'interfaccia di notifica di \func{mq\_notify} (che
- vedremo a breve).} Se la coda esiste già il descrittore farà riferimento
-allo stesso oggetto, consentendo così la comunicazione fra due processi
+ vedremo a breve).} Se la coda esiste già il descrittore farà riferimento
+allo stesso oggetto, consentendo così la comunicazione fra due processi
diversi.
-La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
+La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
possono essere specificati per \param{oflag}, che deve essere specificato come
maschera binaria; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
+tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
- processo potrà usare il descrittore con \func{mq\_receive} ma non con
+ processo potrà usare il descrittore con \func{mq\_receive} ma non con
\func{mq\_send}.
\item[\const{O\_WRONLY}] Apre la coda solo per la trasmissione di messaggi. Il
- processo potrà usare il descrittore con \func{mq\_send} ma non con
+ processo potrà usare il descrittore con \func{mq\_send} ma non con
\func{mq\_receive}.
\item[\const{O\_RDWR}] Apre la coda solo sia per la trasmissione che per la
ricezione.
presenza di questo bit richiede la presenza degli ulteriori argomenti
\param{mode} e \param{attr}.
\item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
- chiamata se la coda esiste già, altrimenti esegue la creazione atomicamente.
-\item[\const{O\_NONBLOCK}] Imposta la coda in modalità non bloccante, le
+ chiamata se la coda esiste già, altrimenti esegue la creazione atomicamente.
+\item[\const{O\_NONBLOCK}] Imposta la coda in modalità non bloccante, le
funzioni di ricezione e trasmissione non si bloccano quando non ci sono le
risorse richieste, ma ritornano immediatamente con un errore di
\errcode{EAGAIN}.
\end{basedescript}
-I primi tre bit specificano la modalità di apertura della coda, e sono fra
-loro esclusivi. Ma qualunque sia la modalità in cui si è aperta una coda,
-questa potrà essere riaperta più volte in una modalità diversa, e vi si potrà
-sempre accedere attraverso descrittori diversi, esattamente come si può fare
+I primi tre bit specificano la modalità di apertura della coda, e sono fra
+loro esclusivi. Ma qualunque sia la modalità in cui si è aperta una coda,
+questa potrà essere riaperta più volte in una modalità diversa, e vi si potrà
+sempre accedere attraverso descrittori diversi, esattamente come si può fare
per i file normali.
Se la coda non esiste e la si vuole creare si deve specificare
\func{open}, anche se per le code di messaggi han senso solo i permessi di
lettura e scrittura. Oltre ai permessi di creazione possono essere specificati
anche gli attributi specifici della coda tramite l'argomento \param{attr};
-quest'ultimo è un puntatore ad una apposita struttura \struct{mq\_attr}, la
-cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}.
+quest'ultimo è un puntatore ad una apposita struttura \struct{mq\_attr}, la
+cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}.
\begin{figure}[!htb]
\footnotesize \centering
Per la creazione della coda i campi della struttura che devono essere
specificati sono \var{mq\_maxmsg} e \var{mq\_msgsize}, che indicano
-rispettivamente il numero massimo di messaggi che può contenere e la
-dimensione massima di un messaggio. Il valore dovrà essere positivo e minore
+rispettivamente il numero massimo di messaggi che può contenere e la
+dimensione massima di un messaggio. Il valore dovrà essere positivo e minore
dei rispettivi limiti di sistema \const{MQ\_MAXMSG} e \const{MQ\_MSGSIZE},
-altrimenti la funzione fallirà con un errore di \errcode{EINVAL}.
-Se \param{attr} è un puntatore nullo gli attributi della coda saranno
+altrimenti la funzione fallirà con un errore di \errcode{EINVAL}.
+Se \param{attr} è un puntatore nullo gli attributi della coda saranno
impostati ai valori predefiniti.
-Quando l'accesso alla coda non è più necessario si può chiudere il relativo
-descrittore con la funzione \funcd{mq\_close}, il cui prototipo è:
+Quando l'accesso alla coda non è più necessario si può chiudere il relativo
+descrittore con la funzione \funcd{mq\_close}, il cui prototipo è:
\begin{prototype}{mqueue.h}
{int mq\_close(mqd\_t mqdes)}
Chiude la coda \param{mqdes}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore;
- nel quel caso \var{errno} assumerà i valori \errval{EBADF} o
+ nel quel caso \var{errno} assumerà i valori \errval{EBADF} o
\errval{EINTR}.}
\end{prototype}
-La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono
- implementate come file su un filesystem dedicato, è esattamente la stessa
- funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare
-il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema
-e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di
-un processo tutte le code aperte, così come i file, vengono chiuse
+La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono
+ implementate come file su un filesystem dedicato, è esattamente la stessa
+ funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare
+il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema
+e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di
+un processo tutte le code aperte, così come i file, vengono chiuse
automaticamente. Inoltre se il processo aveva agganciato una richiesta di
-notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà
+notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà
essere richiesta da qualche altro processo.
Quando si vuole effettivamente rimuovere una coda dal sistema occorre usare la
-funzione \funcd{mq\_unlink}, il cui prototipo è:
+funzione \funcd{mq\_unlink}, il cui prototipo è:
\begin{prototype}{mqueue.h}
{int mq\_unlink(const char *name)}
Rimuove una coda di messaggi.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
+ errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
\func{unlink}.}
\end{prototype}
-Anche in questo caso il comportamento della funzione è analogo a quello di
+Anche in questo caso il comportamento della funzione è analogo a quello di
\func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa
- direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
+ direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
che una successiva chiamata a \func{mq\_open} fallisce o crea una coda
diversa.
Come per i file ogni coda di messaggi ha un contatore di riferimenti, per cui
la coda non viene effettivamente rimossa dal sistema fin quando questo non si
annulla. Pertanto anche dopo aver eseguito con successo \func{mq\_unlink} la
-coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
+coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
di essa. Allo stesso modo una coda ed i suoi contenuti resteranno disponibili
-all'interno del sistema anche quando quest'ultima non è aperta da nessun
-processo (questa è una delle differenze più rilevanti nei confronti di pipe e
-fifo). La sola differenza fra code di messaggi POSIX e file normali è che,
+all'interno del sistema anche quando quest'ultima non è aperta da nessun
+processo (questa è una delle differenze più rilevanti nei confronti di pipe e
+fifo). La sola differenza fra code di messaggi POSIX e file normali è che,
essendo il filesystem delle code di messaggi virtuale e basato su oggetti
interni al kernel, il suo contenuto viene perduto con il riavvio del sistema.
-Come accennato ad ogni coda di messaggi è associata una struttura
-\struct{mq\_attr}, che può essere letta e modificata attraverso le due
+Come accennato ad ogni coda di messaggi è associata una struttura
+\struct{mq\_attr}, che può essere letta e modificata attraverso le due
funzioni \funcd{mq\_getattr} e \funcd{mq\_setattr}, i cui prototipi sono:
\begin{functions}
\headdecl{mqueue.h}
Modifica gli attributi di una coda di messaggi POSIX.
\bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
- caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF}
+ caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF}
o \errval{EINVAL}.}
\end{functions}
La funzione \func{mq\_getattr} legge i valori correnti degli attributi della
coda nella struttura puntata da \param{mqstat}; di questi l'unico relativo
-allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di
+allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di
messaggi da essa contenuti, gli altri indicano le caratteristiche generali
della stessa.
La funzione \func{mq\_setattr} permette di modificare gli attributi di una
coda tramite i valori contenuti nella struttura puntata da \param{mqstat}, ma
-può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono
+può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono
ignorati. In particolare i valori di \var{mq\_maxmsg} e \var{mq\_msgsize}
possono essere specificati solo in fase ci creazione della coda. Inoltre i
soli valori possibili per \var{mq\_flags} sono 0 e \const{O\_NONBLOCK}, per
-cui alla fine la funzione può essere utilizzata solo per abilitare o
-disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene
+cui alla fine la funzione può essere utilizzata solo per abilitare o
+disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene
usato, quando diverso da \val{NULL}, per specificare l'indirizzo di una
struttura su cui salvare i valori degli attributi precedenti alla chiamata
della funzione.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ per un
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
- coda è piena.
+ \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
+ coda è piena.
\item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len}
eccede il limite impostato per la coda.
- \item[\errcode{EINVAL}] si è specificato un valore nullo per
+ \item[\errcode{EINVAL}] si è specificato un valore nullo per
\param{msg\_len}, o un valore di \param{msg\_prio} fuori dai limiti, o
un valore non valido per \param{abs\_timeout}.
- \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato
+ \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato
effettuato entro il tempo stabilito.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{ENOMEM} ed \errval{EINTR}.}
Se quest'ultima eccede la dimensione massima specificata da \var{mq\_msgsize}
le funzioni ritornano immediatamente con un errore di \errcode{EMSGSIZE}.
-L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di
-priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e
-quindi saranno riletti per primi). A parità del valore della priorità il
-messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il
-valore della priorità non può eccedere il limite di sistema
-\const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
+L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di
+priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e
+quindi saranno riletti per primi). A parità del valore della priorità il
+messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il
+valore della priorità non può eccedere il limite di sistema
+\const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
Qualora la coda sia piena, entrambe le funzioni si bloccano, a meno che non
-sia stata selezionata in fase di apertura la modalità non
+sia stata selezionata in fase di apertura la modalità non
bloccante,\footnote{o si sia impostato il flag \const{O\_NONBLOCK} sul file
descriptor della coda.} nel qual caso entrambe ritornano \errcode{EAGAIN}.
-La sola differenza fra le due funzioni è che la seconda, passato il tempo
+La sola differenza fra le due funzioni è che la seconda, passato il tempo
massimo impostato con l'argomento \param{abs\_timeout},\footnote{deve essere
specificato un tempo assoluto tramite una struttura \struct{timespec} (vedi
fig.~\ref{fig:sys_timespec_struct}) indicato in numero di secondi e
nanosecondi a partire dal 1 gennaio 1970.} ritorna comunque con un errore di
-\errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
-chiamata e la coda è vuota la funzione ritorna immediatamente.
+\errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
+chiamata e la coda è vuota la funzione ritorna immediatamente.
Come per l'inserimento, anche per l'estrazione dei messaggi da una coda sono
previste due funzioni, \funcd{mq\_receive} e \funcd{mq\_timedreceive}, i cui
\param{abs\_timeout}.
\bodydesc{Le funzioni restituiscono il numero di byte del messaggio in caso
- di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
+ di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
- coda è vuota.
+ \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la
+ coda è vuota.
\item[\errcode{EMSGSIZE}] la lunghezza del messaggio sulla coda eccede il
valore \param{msg\_len} specificato per la ricezione.
- \item[\errcode{EINVAL}] si è specificato un valore nullo per
+ \item[\errcode{EINVAL}] si è specificato un valore nullo per
\param{msg\_ptr}, o un valore non valido per \param{abs\_timeout}.
- \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata
+ \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata
effettuata entro il tempo stabilito.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EINTR}, \errval{ENOMEM}, o
\errval{EINVAL}.}
\end{functions}
-La funzione estrae dalla coda il messaggio a priorità più alta, o il più
-vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
+La funzione estrae dalla coda il messaggio a priorità più alta, o il più
+vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
viene tolto dalla coda e la sua dimensione viene restituita come valore di
-ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la
- condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
- notare che questo è uno dei casi in cui vale ciò che lo standard
+ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la
+ condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
+ notare che questo è uno dei casi in cui vale ciò che lo standard
\textsl{non} dice, una dimensione nulla infatti, pur non essendo citata, non
viene proibita.}
-Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
+Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
-il messaggio. È pertanto opportuno eseguire sempre una chiamata a
+il messaggio. È pertanto opportuno eseguire sempre una chiamata a
\func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
dimensione massima dei messaggi sulla coda, per poter essere in grado di
allocare dei buffer sufficientemente ampi per la lettura.
Se si specifica un puntatore per l'argomento \param{msg\_prio} il valore della
-priorità del messaggio viene memorizzato all'indirizzo da esso indicato.
-Qualora non interessi usare la priorità dei messaggi si può specificare
-\var{NULL}, ed usare un valore nullo della priorità nelle chiamate a
+priorità del messaggio viene memorizzato all'indirizzo da esso indicato.
+Qualora non interessi usare la priorità dei messaggi si può specificare
+\var{NULL}, ed usare un valore nullo della priorità nelle chiamate a
\func{mq\_send}.
-Si noti che con le code di messaggi POSIX non si ha la possibilità di
-selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
+Si noti che con le code di messaggi POSIX non si ha la possibilità di
+selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
differenza di quanto avveniva con le code di messaggi di SysV che permettono
invece la selezione in base al valore del campo \var{mtype}.
% TODO inserire i dati di /proc/sys/fs/mqueue
Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
-sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
+sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
immediatamente con l'errore \errcode{EAGAIN}. Anche in questo caso la sola
-differenza fra le due funzioni è che la seconda non attende indefinitamente e
+differenza fra le due funzioni è che la seconda non attende indefinitamente e
passato il tempo massimo \param{abs\_timeout} ritorna comunque con un errore
di \errcode{ETIMEDOUT}.
Uno dei problemi sottolineati da Stevens in \cite{UNP2}, comuni ad entrambe le
-tipologie di code messaggi, è che non è possibile per chi riceve identificare
-chi è che ha inviato il messaggio, in particolare non è possibile sapere da
+tipologie di code messaggi, è che non è possibile per chi riceve identificare
+chi è che ha inviato il messaggio, in particolare non è possibile sapere da
quale utente esso provenga. Infatti, in mancanza di un meccanismo interno al
kernel, anche se si possono inserire delle informazioni nel messaggio, queste
non possono essere credute, essendo completamente dipendenti da chi lo invia.
-Vedremo però come, attraverso l'uso del meccanismo di notifica, sia possibile
+Vedremo però come, attraverso l'uso del meccanismo di notifica, sia possibile
superare in parte questo problema.
-Una caratteristica specifica delle code di messaggi POSIX è la possibilità di
-usufruire di un meccanismo di notifica asincrono; questo può essere attivato
-usando la funzione \funcd{mq\_notify}, il cui prototipo è:
+Una caratteristica specifica delle code di messaggi POSIX è la possibilità di
+usufruire di un meccanismo di notifica asincrono; questo può essere attivato
+usando la funzione \funcd{mq\_notify}, il cui prototipo è:
\begin{prototype}{mqueue.h}
{int mq\_notify(mqd\_t mqdes, const struct sigevent *notification)}
Attiva il meccanismo di notifica per la coda \param{mqdes}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica.
+ \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica.
\item[\errcode{EBADF}] il descrittore non fa riferimento ad una coda di
messaggi.
\end{errlist}}
\end{prototype}
Il meccanismo di notifica permette di segnalare in maniera asincrona ad un
-processo la presenza di dati sulla coda, in modo da evitare la necessità di
+processo la presenza di dati sulla coda, in modo da evitare la necessità di
bloccarsi nell'attesa. Per far questo un processo deve registrarsi con la
-funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo
+funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo
processo alla volta per ciascuna coda.
Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento
-\param{notification}, che è un puntatore ad una apposita struttura
+\param{notification}, che è un puntatore ad una apposita struttura
\struct{sigevent}, (definita in fig.~\ref{fig:struct_sigevent}) introdotta
dallo standard POSIX.1b per gestire la notifica di eventi; per altri dettagli
-si può vedere quanto detto in sez.~\ref{sec:sig_timer_adv} a proposito
+si può vedere quanto detto in sez.~\ref{sec:sig_timer_adv} a proposito
dell'uso della stessa struttura per la notifica delle scadenze dei
\textit{timer}.
-Attraverso questa struttura si possono impostare le modalità con cui viene
-effettuata la notifica nel campo \var{sigev\_notify}, che può assumere i
+Attraverso questa struttura si possono impostare le modalità con cui viene
+effettuata la notifica nel campo \var{sigev\_notify}, che può assumere i
valori di tab.~\ref{tab:sigevent_sigev_notify}.\footnote{la pagina di manuale
riporta soltanto i primi tre (inizialmente era possibile solo
- \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
+ \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
\const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
-segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
+segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
un puntatore ad una struttura \struct{sigval\_t} (definita in
fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale
un valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
La funzione registra il processo chiamante per la notifica se
\param{notification} punta ad una struttura \struct{sigevent} opportunamente
-inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato
-che un solo processo alla volta può essere registrato, la funzione fallisce
-con \errcode{EBUSY} se c'è un altro processo già registrato.\footnote{questo
+inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato
+che un solo processo alla volta può essere registrato, la funzione fallisce
+con \errcode{EBUSY} se c'è un altro processo già registrato.\footnote{questo
significa anche che se si registra una notifica con \const{SIGEV\_NONE} il
- processo non la riceverà, ma impedirà anche che altri possano registrarsi
+ processo non la riceverà, ma impedirà anche che altri possano registrarsi
per poterlo fare.} Si tenga presente inoltre che alla chiusura del
descrittore associato alla coda (e quindi anche all'uscita del processo) ogni
eventuale registrazione di notifica presente viene cancellata.
La notifica del segnale avviene all'arrivo di un messaggio in una coda vuota
-(cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
+(cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
bloccato in una chiamata a \func{mq\_receive}, in questo caso infatti il
processo bloccato ha la precedenza ed il messaggio gli viene immediatamente
inviato, mentre per il meccanismo di notifica tutto funziona come se la coda
che se si vuole mantenere il meccanismo di notifica occorre ripetere la
registrazione chiamando nuovamente \func{mq\_notify} all'interno del gestore
del segnale di notifica. A differenza della situazione simile che si aveva con
-i segnali non affidabili,\footnote{l'argomento è stato affrontato in
+i segnali non affidabili,\footnote{l'argomento è stato affrontato in
\ref{sec:sig_semantics}.} questa caratteristica non configura una
-\itindex{race~condition} \textit{race condition} perché l'invio di un segnale
-avviene solo se la coda è vuota; pertanto se si vuole evitare di correre il
+\itindex{race~condition} \textit{race condition} perché l'invio di un segnale
+avviene solo se la coda è vuota; pertanto se si vuole evitare di correre il
rischio di perdere eventuali ulteriori segnali inviati nel lasso di tempo che
occorre per ripetere la richiesta di notifica basta avere cura di eseguire
questa operazione prima di estrarre i messaggi presenti dalla coda.
valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid}
all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
-esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
+esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
sul processo che ha inserito un messaggio usando un gestore per il segnale in
forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al
proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.}
\subsection{Memoria condivisa}
\label{sec:ipc_posix_shm}
-La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel
-kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso
+La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel
+kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso
il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene tutti i
suoi contenuti in memoria, che viene attivato abilitando l'opzione
\texttt{CONFIG\_TMPFS} in fase di compilazione del kernel.
Per potere utilizzare l'interfaccia POSIX per la memoria condivisa le
\acr{glibc}\footnote{le funzioni sono state introdotte con le glibc-2.2.}
-richiedono di compilare i programmi con l'opzione \code{-lrt}; inoltre è
+richiedono di compilare i programmi con l'opzione \code{-lrt}; inoltre è
necessario che in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs};
questo di norma viene fatto aggiungendo una riga del tipo di:
\begin{verbatim}
tmpfs /dev/shm tmpfs defaults 0 0
\end{verbatim}
-ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
+ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
dove si vuole, per usarlo come RAM disk, con un comando del tipo:
\begin{verbatim}
mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs
Il filesystem riconosce, oltre quelle mostrate, le opzioni \texttt{uid} e
\texttt{gid} che identificano rispettivamente utente e gruppo cui assegnarne
-la titolarità, e \texttt{nr\_blocks} che permette di specificarne la
-dimensione in blocchi, cioè in multipli di \const{PAGECACHE\_SIZE} che in
-questo caso è l'unità di allocazione elementare.
+la titolarità, e \texttt{nr\_blocks} che permette di specificarne la
+dimensione in blocchi, cioè in multipli di \const{PAGECACHE\_SIZE} che in
+questo caso è l'unità di allocazione elementare.
La funzione che permette di aprire un segmento di memoria condivisa POSIX, ed
-eventualmente di crearlo se non esiste ancora, è \funcd{shm\_open}; il suo
-prototipo è:
+eventualmente di crearlo se non esiste ancora, è \funcd{shm\_open}; il suo
+prototipo è:
\begin{functions}
\headdecl{sys/mman.h}
\headdecl{sys/stat.h}
Apre un segmento di memoria condivisa.
\bodydesc{La funzione restituisce un file descriptor positivo in caso di
- successo e -1 in caso di errore; nel quel caso \var{errno} assumerà gli
+ successo e -1 in caso di errore; nel quel caso \var{errno} assumerà gli
stessi valori riportati da \func{open}.}
\end{functions}
La funzione apre un segmento di memoria condivisa identificato dal nome
-\param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo
-nome può essere specificato in forma standard solo facendolo iniziare per
+\param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo
+nome può essere specificato in forma standard solo facendolo iniziare per
``\file{/}'' e senza ulteriori ``\file{/}''. Linux supporta comunque nomi
generici, che verranno interpretati prendendo come radice
\file{/dev/shm}.\footnote{occorre pertanto evitare di specificare qualcosa del
- tipo \file{/dev/shm/nome} all'interno di \param{name}, perché questo
+ tipo \file{/dev/shm/nome} all'interno di \param{name}, perché questo
comporta, da parte delle funzioni di libreria, il tentativo di accedere a
\file{/dev/shm/dev/shm/nome}.}
-La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
+La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
possono essere specificati per \param{oflag}, che deve essere specificato come
maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
\const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
+tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
i seguenti:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
\item[\const{O\_CREAT}] Necessario qualora si debba creare il segmento di
memoria condivisa se esso non esiste; in questo caso viene usato il valore
di \param{mode} per impostare i permessi, che devono essere compatibili con
- le modalità con cui si è aperto il file.
+ le modalità con cui si è aperto il file.
\item[\const{O\_EXCL}] Se usato insieme a \const{O\_CREAT} fa fallire la
- chiamata a \func{shm\_open} se il segmento esiste già, altrimenti esegue la
+ chiamata a \func{shm\_open} se il segmento esiste già, altrimenti esegue la
creazione atomicamente.
-\item[\const{O\_TRUNC}] Se il segmento di memoria condivisa esiste già, ne
+\item[\const{O\_TRUNC}] Se il segmento di memoria condivisa esiste già, ne
tronca le dimensioni a 0 byte.
\end{basedescript}
In caso di successo la funzione restituisce un file descriptor associato al
-segmento di memoria condiviso con le stesse modalità di
-\func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
+segmento di memoria condiviso con le stesse modalità di
+\func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
effetto.} viste in sez.~\ref{sec:file_open}; in particolare viene impostato
il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi processi usando
lo stesso nome, restituiranno file descriptor associati allo stesso segmento
-(così come, nel caso di file di dati, essi sono associati allo stesso
-\index{inode} inode). In questo modo è possibile effettuare una chiamata ad
+(così come, nel caso di file di dati, essi sono associati allo stesso
+\index{inode} inode). In questo modo è possibile effettuare una chiamata ad
\func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
vedranno lo stesso segmento di memoria condivisa.
-Quando il nome non esiste il segmento può essere creato specificando
-\const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
-lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
+Quando il nome non esiste il segmento può essere creato specificando
+\const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
+lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
per impostarne la dimensione si deve usare \func{ftruncate} (vedi
sez.~\ref{sec:file_file_size}), prima di mapparlo in memoria con \func{mmap}.
-Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
+Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
descriptor (con \func{close}), senza che la mappatura ne risenta.
Come per i file, quando si vuole effettivamente rimuovere segmento di memoria
-condivisa, occorre usare la funzione \funcd{shm\_unlink}, il cui prototipo è:
+condivisa, occorre usare la funzione \funcd{shm\_unlink}, il cui prototipo è:
\begin{prototype}{sys/mman.h}
{int shm\_unlink(const char *name)}
Rimuove un segmento di memoria condivisa.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
+ errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da
\func{unlink}.}
\end{prototype}
-La funzione è del tutto analoga ad \func{unlink}, e si limita a cancellare il
-nome del segmento da \file{/dev/shm}, senza nessun effetto né sui file
-descriptor precedentemente aperti con \func{shm\_open}, né sui segmenti già
+La funzione è del tutto analoga ad \func{unlink}, e si limita a cancellare il
+nome del segmento da \file{/dev/shm}, senza nessun effetto né sui file
+descriptor precedentemente aperti con \func{shm\_open}, né sui segmenti già
mappati in memoria; questi verranno cancellati automaticamente dal sistema
solo con le rispettive chiamate a \func{close} e \func{munmap}. Una volta
-eseguita questa funzione però, qualora si richieda l'apertura di un segmento
-con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
-usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
+eseguita questa funzione però, qualora si richieda l'apertura di un segmento
+con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
+usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
\begin{figure}[!htb]
\label{fig:ipc_posix_shmmem}
\end{figure}
-Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
+Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
una interfaccia semplificata analoga a quella vista in
fig.~\ref{fig:ipc_sysv_shm_func} per la memoria condivisa in stile SysV. Il
-codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
+codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
file \file{SharedMem.c} dei sorgenti allegati.
-La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
+La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
nell'argomento \var{name} crea un nuovo segmento di memoria condivisa,
accessibile in lettura e scrittura, e ne restituisce l'indirizzo. Anzitutto si
definiscono (\texttt{\small 8}) i flag per la successiva (\texttt{\small 9})
\func{ftruncate}. Di nuovo (\texttt{\small 15--16}) si esce immediatamente
restituendo un puntatore nullo in caso di errore. Poi si passa (\texttt{\small
18}) a mappare in memoria il segmento con \func{mmap} specificando dei
-diritti di accesso corrispondenti alla modalità di apertura. Di nuovo si
+diritti di accesso corrispondenti alla modalità di apertura. Di nuovo si
restituisce (\texttt{\small 19--21}) un puntatore nullo in caso di errore,
altrimenti si inizializza (\texttt{\small 22}) il contenuto del segmento al
valore specificato dall'argomento \var{fill} con \func{memset}, e se ne
restituisce (\texttt{\small 23}) l'indirizzo.
-La seconda funzione (\texttt{\small 25--40}) è \func{FindShm} che trova un
-segmento di memoria condiviso già esistente, restituendone l'indirizzo. In
+La seconda funzione (\texttt{\small 25--40}) è \func{FindShm} che trova un
+segmento di memoria condiviso già esistente, restituendone l'indirizzo. In
questo caso si apre (\texttt{\small 31}) il segmento con \func{shm\_open}
-richiedendo che il segmento sia già esistente, in caso di errore
+richiedendo che il segmento sia già esistente, in caso di errore
(\texttt{\small 31--33}) si ritorna immediatamente un puntatore nullo.
Ottenuto il file descriptor del segmento lo si mappa (\texttt{\small 35}) in
memoria con \func{mmap}, restituendo (\texttt{\small 36--38}) un puntatore
nullo in caso di errore, o l'indirizzo (\texttt{\small 39}) dello stesso in
caso di successo.
-La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
+La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
cancellare un segmento di memoria condivisa. Dato che al contrario di quanto
avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono
-rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
-fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
+rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
+fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
restituendo al chiamante il valore di ritorno.
estensioni \textit{real-time} delle \acr{glibc}.\footnote{quelle che si
accedono collegandosi alla libreria \texttt{librt}.} Esisteva inoltre una
libreria che realizzava (parzialmente) l'interfaccia POSIX usando le funzioni
-dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
+dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
sez.~\ref{sec:ipc_sysv_sem}).
-A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
+A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
sincronizzazione completamente nuovo, basato sui cosiddetti
\textit{futex},\footnote{la sigla sta per \textit{fast user mode mutex}.} con
-il quale è stato possibile implementare una versione nativa dei semafori
+il quale è stato possibile implementare una versione nativa dei semafori
POSIX. Grazie a questo con i kernel della serie 2.6 e le nuove versioni delle
\acr{glibc} che usano questa nuova infrastruttura per quella che viene quella
che viene chiamata \textit{New Posix Thread Library}, sono state implementate
anche tutte le funzioni dell'interfaccia dei semafori POSIX.
-Anche in questo caso è necessario appoggiarsi alla libreria per le estensioni
+Anche in questo caso è necessario appoggiarsi alla libreria per le estensioni
\textit{real-time} \texttt{librt}, questo significa che se si vuole utilizzare
questa interfaccia, oltre ad utilizzare gli opportuni file di definizione,
-occorrerà compilare i programmi con l'opzione \texttt{-lrt}.
+occorrerà compilare i programmi con l'opzione \texttt{-lrt}.
La funzione che permette di creare un nuovo semaforo POSIX, creando il
-relativo file, o di accedere ad uno esistente, è \funcd{sem\_open}, questa
+relativo file, o di accedere ad uno esistente, è \funcd{sem\_open}, questa
prevede due forme diverse a seconda che sia utilizzata per aprire un semaforo
esistente o per crearne uno nuovi, i relativi prototipi sono:
\begin{functions}
\bodydesc{La funzione restituisce l'indirizzo del semaforo in caso di
successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
- \var{errno} assumerà i valori:
+ \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EACCESS}] il semaforo esiste ma non si hanno permessi
sufficienti per accedervi.
\const{O\_EXCL} ma il semaforo esiste.
\item[\errcode{EINVAL}] il valore di \param{value} eccede
\const{SEM\_VALUE\_MAX}.
- \item[\errcode{ENAMETOOLONG}] si è utilizzato un nome troppo lungo.
- \item[\errcode{ENOENT}] non si è usato \const{O\_CREAT} ed il nome
+ \item[\errcode{ENAMETOOLONG}] si è utilizzato un nome troppo lungo.
+ \item[\errcode{ENOENT}] non si è usato \const{O\_CREAT} ed il nome
specificato non esiste.
\end{errlist}
ed inoltre \errval{ENFILE} ed \errval{ENOMEM}.}
\end{functions}
L'argomento \param{name} definisce il nome del semaforo che si vuole
-utilizzare, ed è quello che permette a processi diversi di accedere allo
+utilizzare, ed è quello che permette a processi diversi di accedere allo
stesso semaforo. Questo deve essere specificato con un pathname nella forma
\texttt{/qualchenome}, che non ha una corrispondenza diretta con un pathname
reale; con Linux infatti i file associati ai semafori sono mantenuti nel
filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato automaticamente
-un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
+un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
creazione tramite \func{sem\_open}, su \texttt{/dev/shm/sem.qualchenome}.}
-L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
-funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
+L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
+funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
utilizzati per l'analogo argomento di \func{open}, anche se dei possibili
valori visti in sez.~\ref{sec:file_open} sono utilizzati soltanto
\const{O\_CREAT} e \const{O\_EXCL}.
Se si usa \const{O\_CREAT} si richiede la creazione del semaforo qualora
questo non esista, ed in tal caso occorre utilizzare la seconda forma della
funzione, in cui si devono specificare sia un valore iniziale con l'argomento
-\param{value},\footnote{e si noti come così diventa possibile, differenza di
+\param{value},\footnote{e si noti come così diventa possibile, differenza di
quanto avviene per i semafori del \textit{SysV IPC}, effettuare in maniera
atomica creazione ed inizializzazione di un semaforo usando una unica
funzione.} che una maschera dei permessi con l'argomento
\param{mode};\footnote{anche questo argomento prende gli stessi valori
utilizzati per l'analogo di \func{open}, che si sono illustrati in dettaglio
sez.~\ref{sec:file_perm_overview}.} questi verranno assegnati al semaforo
-appena creato. Se il semaforo esiste già i suddetti valori saranno invece
+appena creato. Se il semaforo esiste già i suddetti valori saranno invece
ignorati. Usando il flag \const{O\_EXCL} si richiede invece la verifica che il
semaforo non esiste, usandolo insieme ad \const{O\_CREAT} la funzione fallisce
-qualora un semaforo con lo stesso nome sia già presente.
+qualora un semaforo con lo stesso nome sia già presente.
La funzione restituisce in caso di successo un puntatore all'indirizzo del
-semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
+semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
essere passato alle altre funzioni per operare sul semaforo stesso. Si tenga
presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori
usano la semantica standard dei file per quanto riguarda i controlli di
Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
group-ID effettivo del processo chiamante, e che i permessi indicati con
\param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
-del processo. Inoltre per poter aprire un semaforo è necessario avere su di
+del processo. Inoltre per poter aprire un semaforo è necessario avere su di
esso sia il permesso di lettura che quello di scrittura.
-Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
+Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
utilizzarlo; se si ricorda quanto detto all'inizio di
sez.~\ref{sec:ipc_sysv_sem}, dove si sono introdotti i concetti generali
relativi ai semafori, le operazioni principali sono due, quella che richiede
l'uso di una risorsa bloccando il semaforo e quella che rilascia la risorsa
-liberando il semaforo. La prima operazione è effettuata dalla funzione
-\funcd{sem\_wait}, il cui prototipo è:
+liberando il semaforo. La prima operazione è effettuata dalla funzione
+\funcd{sem\_wait}, il cui prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Blocca il semaforo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
\end{errlist}
}
La funzione cerca di decrementare il valore del semaforo indicato dal
puntatore \param{sem}, se questo ha un valore positivo, cosa che significa che
-la risorsa è disponibile, la funzione ha successo, il valore del semaforo
-viene diminuito di 1 ed essa ritorna immediatamente; se il valore è nullo la
+la risorsa è disponibile, la funzione ha successo, il valore del semaforo
+viene diminuito di 1 ed essa ritorna immediatamente; se il valore è nullo la
funzione si blocca fintanto che il valore del semaforo non torni
positivo\footnote{ovviamente per opera di altro processo che lo rilascia
- chiamando \func{sem\_post}.} così che poi essa possa decrementarlo con
+ chiamando \func{sem\_post}.} così che poi essa possa decrementarlo con
successo e proseguire.
-Si tenga presente che la funzione può sempre essere interrotta da un segnale
-(nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà
-comunque, anche se si è richiesta la semantica BSD installando il relativo
+Si tenga presente che la funzione può sempre essere interrotta da un segnale
+(nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà
+comunque, anche se si è richiesta la semantica BSD installando il relativo
gestore con \const{SA\_RESTART} (vedi sez.~\ref{sec:sig_sigaction}) per
riavviare le system call interrotte.
Della funzione \func{sem\_wait} esistono due varianti che consentono di
-gestire diversamente le modalità di attesa in caso di risorsa occupata, la
-prima di queste è \funcd{sem\_trywait}, che serve ad effettuare un tentativo
-di acquisizione senza bloccarsi; il suo prototipo è:
+gestire diversamente le modalità di attesa in caso di risorsa occupata, la
+prima di queste è \funcd{sem\_trywait}, che serve ad effettuare un tentativo
+di acquisizione senza bloccarsi; il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Tenta di bloccare il semaforo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà gli stessi valori:
+ errore; nel quel caso \var{errno} assumerà gli stessi valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] il semaforo non può essere acquisito senza
+ \item[\errcode{EAGAIN}] il semaforo non può essere acquisito senza
bloccarsi.
\item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
\end{errlist}
}
\end{functions}
-La funzione è identica a \func{sem\_wait} ed se la risorsa è libera ha lo
+La funzione è identica a \func{sem\_wait} ed se la risorsa è libera ha lo
stesso effetto, vale a dire che in caso di semaforo diverso da zero la
-funzione lo decrementa e ritorna immediatamente; la differenza è che nel caso
-in cui il semaforo è occupato essa non si blocca e di nuovo ritorna
-immediatamente, restituendo però un errore di \errval{EAGAIN}, così che il
+funzione lo decrementa e ritorna immediatamente; la differenza è che nel caso
+in cui il semaforo è occupato essa non si blocca e di nuovo ritorna
+immediatamente, restituendo però un errore di \errval{EAGAIN}, così che il
programma possa proseguire.
-La seconda variante di \func{sem\_wait} è una estensione specifica che può
+La seconda variante di \func{sem\_wait} è una estensione specifica che può
essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
-ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
-\func{sem\_timedwait}, ed il suo prototipo è:
+ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
+\func{sem\_timedwait}, ed il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Blocca il semaforo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà gli stessi valori:
+ errore; nel quel caso \var{errno} assumerà gli stessi valori:
\begin{errlist}
- \item[\errcode{ETIMEDOUT}] è scaduto il tempo massimo di attesa.
+ \item[\errcode{ETIMEDOUT}] è scaduto il tempo massimo di attesa.
\item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
}
\end{functions}
-Anche in questo caso il comportamento della funzione è identico a quello di
+Anche in questo caso il comportamento della funzione è identico a quello di
\func{sem\_wait}, la sola differenza consiste nel fatto che con questa
-funzione è possibile impostare tramite l'argomento \param{abs\_timeout} un
+funzione è possibile impostare tramite l'argomento \param{abs\_timeout} un
tempo limite per l'attesa, scaduto il quale la funzione ritorna comunque,
-anche se non è possibile acquisire il semaforo. In tal caso la funzione
-fallirà, riportando un errore di \errval{ETIMEDOUT}.
+anche se non è possibile acquisire il semaforo. In tal caso la funzione
+fallirà, riportando un errore di \errval{ETIMEDOUT}.
-La seconda funzione principale utilizzata per l'uso dei semafori è
+La seconda funzione principale utilizzata per l'uso dei semafori è
\funcd{sem\_post}, che viene usata per rilasciare un semaforo occupato o, in
-generale, per aumentare di una unità il valore dello stesso anche qualora non
+generale, per aumentare di una unità il valore dello stesso anche qualora non
fosse occupato;\footnote{si ricordi che in generale un semaforo viene usato
- come indicatore di un numero di risorse disponibili.} il suo prototipo è:
+ come indicatore di un numero di risorse disponibili.} il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Rilascia il semaforo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
\end{errlist}
\end{functions}
La funzione incrementa di uno il valore corrente del semaforo indicato
-dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
-sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
-eventualmente bloccato in una \func{sem\_wait} sul semaforo potrà essere
-svegliato e rimesso in esecuzione. Si tenga presente che la funzione è sicura
+dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
+sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
+eventualmente bloccato in una \func{sem\_wait} sul semaforo potrà essere
+svegliato e rimesso in esecuzione. Si tenga presente che la funzione è sicura
\index{funzioni!sicure} per l'uso all'interno di un gestore di segnali (si
ricordi quanto detto in sez.~\ref{sec:sig_signal_handler}).
Se invece di operare su un semaforo se ne vuole solamente leggere il valore,
-si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
+si può usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Richiede il valore del semaforo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
\end{errlist}
La funzione legge il valore del semaforo indicato dall'argomento \param{sem} e
lo restituisce nella variabile intera puntata dall'argomento
-\param{sval}. Qualora ci siano uno o più processi bloccati in attesa sul
+\param{sval}. Qualora ci siano uno o più processi bloccati in attesa sul
semaforo lo standard prevede che la funzione possa restituire un valore nullo
oppure il numero di processi bloccati in una \func{sem\_wait} sul suddetto
semaforo; nel caso di Linux vale la prima opzione.
-Questa funzione può essere utilizzata per avere un suggerimento sullo stato di
-un semaforo, ovviamente non si può prendere il risultato riportato in
+Questa funzione può essere utilizzata per avere un suggerimento sullo stato di
+un semaforo, ovviamente non si può prendere il risultato riportato in
\param{sval} che come indicazione, il valore del semaforo infatti potrebbe
-essere già stato modificato al ritorno della funzione.
+essere già stato modificato al ritorno della funzione.
% TODO verificare comportamento sem_getvalue
-Una volta che non ci sia più la necessità di operare su un semaforo se ne può
-terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo è:
+Una volta che non ci sia più la necessità di operare su un semaforo se ne può
+terminare l'uso con la funzione \funcd{sem\_close}, il cui prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Chiude il semaforo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] il semaforo \param{sem} non esiste.
\end{errlist}
\end{functions}
La funzione chiude il semaforo indicato dall'argomento \param{sem}; questo
-comporta che tutte le risorse che il sistema può avere assegnato al processo
+comporta che tutte le risorse che il sistema può avere assegnato al processo
nell'uso dello stesso vengono rilasciate. Questo significa che un altro
processo bloccato sul semaforo a causa della acquisizione da parte del
-processo che chiama \func{sem\_close} potrà essere riavviato.
+processo che chiama \func{sem\_close} potrà essere riavviato.
Si tenga presente poi che come per i file all'uscita di un processo tutti i
semafori che questo aveva aperto vengono automaticamente chiusi; questo
comportamento risolve il problema che si aveva con i semafori del \textit{SysV
- IPC} (di cui si è parlato in sez.~\ref{sec:ipc_sysv_sem}) per i quali le
+ IPC} (di cui si è parlato in sez.~\ref{sec:ipc_sysv_sem}) per i quali le
risorse possono restare bloccate. Si tenga poi presente che, a differenza di
quanto avviene per i file, in caso di una chiamata ad \func{execve} tutti i
semafori vengono chiusi automaticamente.
Come per i semafori del \textit{SysV IPC} anche quelli POSIX hanno una
-persistenza di sistema; questo significa che una volta che si è creato un
-semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
+persistenza di sistema; questo significa che una volta che si è creato un
+semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
kernel resta attivo (vale a dire fino ad un successivo riavvio) a meno che non
-lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
-\funcd{sem\_unlink}, il cui prototipo è:
+lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
+\funcd{sem\_unlink}, il cui prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Rimuove il semaforo \param{name}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EACCESS}] non si hanno i permessi necessari a cancellare il
semaforo.
- \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
+ \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
\item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
\end{errlist}
}
prende un valore identico a quello usato per creare il semaforo stesso con
\func{sem\_open}. Il semaforo viene rimosso dal filesystem immediatamente; ma
il semaforo viene effettivamente cancellato dal sistema soltanto quando tutti
-i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
+i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
semantica usata con \func{unlink} per i file, trattata in dettaglio in
sez.~\ref{sec:file_link}.
-Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
-anche essere utilizzati anche in forma anonima, senza necessità di fare
+Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
+anche essere utilizzati anche in forma anonima, senza necessità di fare
ricorso ad un nome sul filesystem o ad altri indicativi. In questo caso si
-dovrà porre la variabile che contiene l'indirizzo del semaforo in un tratto di
+dovrà porre la variabile che contiene l'indirizzo del semaforo in un tratto di
memoria che sia accessibile a tutti i processi in gioco. La funzione che
-consente di inizializzare un semaforo anonimo è \funcd{sem\_init}, il cui
-prototipo è:
+consente di inizializzare un semaforo anonimo è \funcd{sem\_init}, il cui
+prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Inizializza il semaforo anonimo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{value} eccede
\const{SEM\_VALUE\_MAX}.
- \item[\errcode{ENOSYS}] il valore di \param{pshared} non è nullo ed il
+ \item[\errcode{ENOSYS}] il valore di \param{pshared} non è nullo ed il
sistema non supporta i semafori per i processi.
\end{errlist}
}
Qualora il semaforo debba essere condiviso dai \itindex{thread}
\textit{thread} di uno stesso processo (nel qual caso si parla di
-\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
+\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
-dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
+dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
nello \itindex{heap} \textit{heap}.
-Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
+Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
parla di \textit{process-shared semaphore}) la sola scelta possibile per
-renderlo visibile a tutti è di porlo in un tratto di memoria condivisa. Questo
-potrà essere ottenuto direttamente sia con \func{shmget} (vedi
+renderlo visibile a tutti è di porlo in un tratto di memoria condivisa. Questo
+potrà essere ottenuto direttamente sia con \func{shmget} (vedi
sez.~\ref{sec:ipc_sysv_shm}) che con \func{shm\_open} (vedi
sez.~\ref{sec:ipc_posix_shm}), oppure, nel caso che tutti i processi in gioco
abbiano un genitore comune, con una mappatura anonima con \func{mmap} (vedi
condivisa vengono mantenuti nei processi figli attraverso la funzione
\func{fork}.} a cui essi poi potranno accedere.
-Una volta inizializzato il semaforo anonimo con \func{sem\_init} lo si potrà
+Una volta inizializzato il semaforo anonimo con \func{sem\_init} lo si potrà
utilizzare nello stesso modo dei semafori normali con \func{sem\_wait} e
-\func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
-semaforo può dar luogo ad un comportamento indefinito.
+\func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
+semaforo può dar luogo ad un comportamento indefinito.
-Una volta che non si intenda più utilizzare un semaforo anonimo questo può
+Una volta che non si intenda più utilizzare un semaforo anonimo questo può
essere eliminato dal sistema; per far questo di deve utilizzare una apposita
-funzione, \funcd{sem\_destroy}, il cui prototipo è:
+funzione, \funcd{sem\_destroy}, il cui prototipo è:
\begin{functions}
\headdecl{semaphore.h}
Elimina il semaforo anonimo \param{sem}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore; nel quel caso \var{errno} assumerà i valori:
+ errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{value} eccede
\const{SEM\_VALUE\_MAX}.
applicata a semafori creati con \func{sem\_open}. Inoltre si deve essere
sicuri che il semaforo sia effettivamente inutilizzato, la distruzione di un
semaforo su cui sono presenti processi (o \itindex{thread} \textit{thread}) in
-attesa (cioè bloccati in una \func{sem\_wait}) provoca un comportamento
+attesa (cioè bloccati in una \func{sem\_wait}) provoca un comportamento
indefinito.
-Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
-\func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti. Nel
+Si tenga presente infine che utilizzare un semaforo che è stato distrutto con
+\func{sem\_destroy} di nuovo può dare esito a comportamenti indefiniti. Nel
caso ci si trovi in una tale evenienza occorre reinizializzare il semaforo una
seconda volta con \func{sem\_init}.
Come esempio di uso sia della memoria condivisa che dei semafori POSIX si sono
-scritti due semplici programmi con i quali è possibile rispettivamente
+scritti due semplici programmi con i quali è possibile rispettivamente
monitorare il contenuto di un segmento di memoria condivisa e modificarne il
contenuto.
\label{fig:ipc_posix_sem_shm_message_server}
\end{figure}
-Il corpo principale del primo dei due, il cui codice completo è nel file
-\file{message\_getter.c} dei sorgenti allegati, è riportato in
-fig.~\ref{fig:ipc_posix_sem_shm_message_server}; si è tralasciata la parte che
+Il corpo principale del primo dei due, il cui codice completo è nel file
+\file{message\_getter.c} dei sorgenti allegati, è riportato in
+fig.~\ref{fig:ipc_posix_sem_shm_message_server}; si è tralasciata la parte che
tratta la gestione delle opzioni a riga di comando (che consentono di
impostare un nome diverso per il semaforo e il segmento di memoria condivisa)
ed il controllo che al programma venga fornito almeno un argomento, contenente
la stringa iniziale da inserire nel segmento di memoria condivisa.
-Lo scopo del programma è quello di creare un segmento di memoria condivisa su
+Lo scopo del programma è quello di creare un segmento di memoria condivisa su
cui registrare una stringa, e tenerlo sotto osservazione stampando la stessa
-una volta al secondo. Si utilizzerà un semaforo per proteggere l'accesso in
+una volta al secondo. Si utilizzerà un semaforo per proteggere l'accesso in
lettura alla stringa, in modo che questa non possa essere modificata
dall'altro programma prima di averla finita di stampare.
La parte iniziale del programma contiene le definizioni (\texttt{\small 1--8})
del gestore del segnale usato per liberare le risorse utilizzate, delle
variabili globali contenenti i nomi di default del segmento di memoria
-condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
+condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
altre variabili utilizzate dal programma.
-Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
-gestore di segnale che consentirà di effettuare le operazioni di pulizia
+Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
+gestore di segnale che consentirà di effettuare le operazioni di pulizia
(usando la funzione \func{Signal} illustrata in
-fig.~\ref{fig:sig_Signal_code}), dopo di che (\texttt{\small 10--16}) si è
+fig.~\ref{fig:sig_Signal_code}), dopo di che (\texttt{\small 10--16}) si è
creato il segmento di memoria condivisa con la funzione \func{CreateShm} che
abbiamo appena trattato in sez.~\ref{sec:ipc_posix_shm}, uscendo con un
messaggio in caso di errore.
Si tenga presente che la funzione \func{CreateShm} richiede che il segmento
-non sia già presente e fallirà qualora un'altra istanza, o un altro programma
-abbia già allocato un segmento con quello stesso nome. Per semplicità di
-gestione si è usata una dimensione fissa pari a 256 byte, definita tramite la
+non sia già presente e fallirà qualora un'altra istanza, o un altro programma
+abbia già allocato un segmento con quello stesso nome. Per semplicità di
+gestione si è usata una dimensione fissa pari a 256 byte, definita tramite la
costante \texttt{MSGMAXSIZE}.
-Il passo successivo (\texttt{\small 17--21}) è quello della creazione del
+Il passo successivo (\texttt{\small 17--21}) è quello della creazione del
semaforo che regola l'accesso al segmento di memoria condivisa con
\func{sem\_open}; anche in questo caso si gestisce l'uscita con stampa di un
messaggio in caso di errore. Anche per il semaforo, avendo specificato la
combinazione di flag \code{O\_CREAT|O\_EXCL} come secondo argomento, si esce
-qualora fosse già esistente; altrimenti esso verrà creato con gli opportuni
+qualora fosse già esistente; altrimenti esso verrà creato con gli opportuni
permessi specificati dal terzo argomento, (indicante lettura e scrittura in
-notazione ottale). Infine il semaforo verrà inizializzato ad un valore nullo
+notazione ottale). Infine il semaforo verrà inizializzato ad un valore nullo
(il quarto argomento), corrispondete allo stato in cui risulta bloccato.
-A questo punto (\texttt{\small 23}) si potrà inizializzare il messaggio posto
+A questo punto (\texttt{\small 23}) si potrà inizializzare il messaggio posto
nel segmento di memoria condivisa usando la stringa passata come argomento al
-programma. Essendo il semaforo stato creato già bloccato non ci si dovrà
+programma. Essendo il semaforo stato creato già bloccato non ci si dovrà
preoccupare di eventuali \itindex{race~condition} \textit{race condition}
qualora il programma di modifica del messaggio venisse lanciato proprio in
-questo momento. Una volta inizializzato il messaggio occorrerà però
+questo momento. Una volta inizializzato il messaggio occorrerà però
rilasciare il semaforo (\texttt{\small 25--28}) per consentirne l'uso; in
-tutte queste operazioni si provvederà ad uscire dal programma con un opportuno
+tutte queste operazioni si provvederà ad uscire dal programma con un opportuno
messaggio in caso di errore.
Una volta completate le inizializzazioni il ciclo principale del programma
(\texttt{\small 29--47}) viene ripetuto indefinitamente (\texttt{\small 29})
per stampare sia il contenuto del messaggio che una serie di informazioni di
-controllo. Il primo passo (\texttt{\small 30--34}) è quello di acquisire (con
+controllo. Il primo passo (\texttt{\small 30--34}) è quello di acquisire (con
\func{sem\_getvalue}, con uscita in caso di errore) e stampare il valore del
semaforo ad inizio del ciclo; seguito (\texttt{\small 35--36}) dal tempo
corrente.
Prima della stampa del messaggio invece si deve acquisire il semaforo
(\texttt{\small 31--34}) per evitare accessi concorrenti alla stringa da parte
del programma di modifica. Una volta eseguita la stampa (\texttt{\small 41})
-il semaforo dovrà essere rilasciato (\texttt{\small 42--45}). Il passo finale
-(\texttt{\small 46}) è attendere per un secondo prima di eseguire da capo il
+il semaforo dovrà essere rilasciato (\texttt{\small 42--45}). Il passo finale
+(\texttt{\small 46}) è attendere per un secondo prima di eseguire da capo il
ciclo.
-Per uscire in maniera corretta dal programma sarà necessario interromperlo con
+Per uscire in maniera corretta dal programma sarà necessario interromperlo con
il break da tastiera (\texttt{C-c}), che corrisponde all'invio del segnale
-\const{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
+\const{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
opportuna funzione di gestione, riportata in
-fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
+fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
semplice e richiama le funzioni di rimozione sia per il segmento di memoria
-condivisa che per il semaforo, garantendo così che possa essere riaperto
+condivisa che per il semaforo, garantendo così che possa essere riaperto
ex-novo senza errori in un futuro riutilizzo del comando.
\begin{figure}[!h]
\label{fig:ipc_posix_sem_shm_message_setter}
\end{figure}
-Il secondo programma di esempio è \file{message\_setter.c}, di cui si è
+Il secondo programma di esempio è \file{message\_setter.c}, di cui si è
riportato il corpo principale in
fig.~\ref{fig:ipc_posix_sem_shm_message_setter},\footnote{al solito il codice
- completo è nel file dei sorgenti allegati.} dove si è tralasciata, non
+ completo è nel file dei sorgenti allegati.} dove si è tralasciata, non
essendo significativa per quanto si sta trattando, la parte relativa alla
gestione delle opzioni a riga di comando e degli argomenti, che sono identici
a quelli usati da \file{message\_getter}, con l'unica aggiunta di un'opzione
essere presente uno solo, contenente la nuova stringa da usare come
messaggio), il programma procede (\texttt{\small 10--14}) con l'acquisizione
del segmento di memoria condivisa usando la funzione \func{FindShm} (trattata
-in sez.~\ref{sec:ipc_posix_shm}) che stavolta deve già esistere. Il passo
-successivo (\texttt{\small 16--19}) è quello di aprire il semaforo, e a
+in sez.~\ref{sec:ipc_posix_shm}) che stavolta deve già esistere. Il passo
+successivo (\texttt{\small 16--19}) è quello di aprire il semaforo, e a
differenza di \file{message\_getter}, in questo caso si richiede a
\func{sem\_open} che questo esista, passando uno zero come secondo ed unico
argomento.
Una volta completate con successo le precedenti inizializzazioni, il passo
-seguente (\texttt{\small 21--24}) è quello di acquisire il semaforo, dopo di
-che sarà possibile eseguire la sostituzione del messaggio (\texttt{\small 25})
+seguente (\texttt{\small 21--24}) è quello di acquisire il semaforo, dopo di
+che sarà possibile eseguire la sostituzione del messaggio (\texttt{\small 25})
senza incorrere in possibili \itindex{race~condition} \textit{race condition}
con la stampa dello stesso da parte di \file{message\_getter}.
Una volta effettuata la modifica viene stampato (\texttt{\small 26}) il tempo
di attesa impostato con l'opzione ``\texttt{-t}'' dopo di che (\texttt{\small
- 27}) viene eseguita la stessa, senza rilasciare il semaforo che resterà
+ 27}) viene eseguita la stessa, senza rilasciare il semaforo che resterà
quindi bloccato (causando a questo punto una interruzione delle stampe
-eseguite da \file{message\_getter}). Terminato il tempo di attesa si rilascerà
+eseguite da \file{message\_getter}). Terminato il tempo di attesa si rilascerà
(\texttt{\small 29--32}) il semaforo per poi uscire.
-Per verificare il funzionamento dei programmi occorrerà lanciare per primo
-\file{message\_getter}\footnote{lanciare per primo \file{message\_setter} darà
+Per verificare il funzionamento dei programmi occorrerà lanciare per primo
+\file{message\_getter}\footnote{lanciare per primo \file{message\_setter} darà
luogo ad un errore, non essendo stati creati il semaforo ed il segmento di
- memoria condivisa.} che inizierà a stampare una volta al secondo il
+ memoria condivisa.} che inizierà a stampare una volta al secondo il
contenuto del messaggio ed i suoi dati, con qualcosa del tipo:
\begin{Verbatim}
piccardi@hain:~/gapil/sources$ ./message_getter messaggio
%$
proseguendo indefinitamente fintanto che non si prema \texttt{C-c} per farlo
uscire. Si noti come il valore del semaforo risulti sempre pari ad 1 (in
-quanto al momento esso sarà sempre libero).
+quanto al momento esso sarà sempre libero).
-A questo punto si potrà lanciare \file{message\_setter} per cambiare il
+A questo punto si potrà lanciare \file{message\_setter} per cambiare il
messaggio, nel nostro caso per rendere evidente il funzionamento del blocco
richiederemo anche una attesa di 3 secondi, ed otterremo qualcosa del tipo:
\begin{Verbatim}
Sleeping for 3 seconds
\end{Verbatim}
%$
-dove il programma si fermerà per 3 secondi prima di rilasciare il semaforo e
+dove il programma si fermerà per 3 secondi prima di rilasciare il semaforo e
terminare.
-L'effetto di questo programma si potrà però apprezzare meglio nell'uscita di
-\file{message\_getter}, che verrà interrotta per questo stesso tempo, prima di
+L'effetto di questo programma si potrà però apprezzare meglio nell'uscita di
+\file{message\_getter}, che verrà interrotta per questo stesso tempo, prima di
ricominciare con il nuovo testo:
\begin{Verbatim}
...
\end{Verbatim}
%$
-E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
+E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
stampe di \file{message\_getter} si bloccheranno, come corretto, dopo aver
-registrato un valore nullo per il semaforo. Il programma infatti resterà
+registrato un valore nullo per il semaforo. Il programma infatti resterà
bloccato nella \func{sem\_wait} (quella di riga (\texttt{\small 37}) in
fig.~\ref{fig:ipc_posix_sem_shm_message_server}) fino alla scadenza
dell'attesa di \file{message\_setter} (con l'esecuzione della \func{sem\_post}
possa essere necessario per capirne meglio il funzionamento dal punto di vista
della programmazione.
-Data la loro prevalenza il capitolo sarà sostanzialmente incentrato sui due
+Data la loro prevalenza il capitolo sarà sostanzialmente incentrato sui due
protocolli principali esistenti su questo livello: il protocollo IP, sigla che
-sta per \textit{Internet Protocol}, (ma che più propriamente si dovrebbe
+sta per \textit{Internet Protocol}, (ma che più propriamente si dovrebbe
chiamare IPv4) ed la nuova versione di questo stesso protocollo, denominata
IPv6. Tratteremo comunque anche il protocollo ICMP e la sua versione
-modificata per IPv6 (cioè ICMPv6).
+modificata per IPv6 (cioè ICMPv6).
\section{Il protocollo IP}
dall'\href{http://www.ietf.org/rfc/rfc791.txt}{RFC~791}; esso nasce per
disaccoppiare le applicazioni della struttura hardware delle reti di
trasmissione, e creare una interfaccia di trasmissione dei dati indipendente
-dal sottostante substrato di rete, che può essere realizzato con le tecnologie
-più disparate (Ethernet, Token Ring, FDDI, ecc.).
+dal sottostante substrato di rete, che può essere realizzato con le tecnologie
+più disparate (Ethernet, Token Ring, FDDI, ecc.).
\subsection{Introduzione}
\label{sec:IP_intro}
-Il compito principale di IP è quello di trasmettere i pacchetti da un computer
+Il compito principale di IP è quello di trasmettere i pacchetti da un computer
all'altro della rete; le caratteristiche essenziali con cui questo viene
realizzato in IPv4 sono due:
\begin{itemize}
\item \textit{Universal addressing} la comunicazione avviene fra due host
- identificati univocamente con un indirizzo a 32 bit che può appartenere ad
+ identificati univocamente con un indirizzo a 32 bit che può appartenere ad
una sola interfaccia di rete.
\item \textit{Best effort} viene assicurato il massimo impegno nella
- trasmissione, ma non c'è nessuna garanzia per i livelli superiori né
- sulla percentuale di successo né sul tempo di consegna dei pacchetti di
- dati, né sull'ordine in cui vengono consegnati.
+ trasmissione, ma non c'è nessuna garanzia per i livelli superiori né
+ sulla percentuale di successo né sul tempo di consegna dei pacchetti di
+ dati, né sull'ordine in cui vengono consegnati.
\end{itemize}
Per effettuare la comunicazione e l'instradamento dei pacchetti fra le varie
-reti di cui è composta Internet IPv4 organizza gli indirizzi in una
+reti di cui è composta Internet IPv4 organizza gli indirizzi in una
gerarchia a due livelli, in cui una parte dei 32 bit dell'indirizzo indica il
numero di rete, e un'altra l'host al suo interno. Il numero di rete serve
ai router per stabilire a quale rete il pacchetto deve essere inviato, il
numero di host indica la macchina di destinazione finale all'interno di detta
rete.
-Per garantire l'unicità dell'indirizzo Internet esiste un'autorità centrale
+Per garantire l'unicità dell'indirizzo Internet esiste un'autorità centrale
(la IANA, \textit{Internet Assigned Number Authority}) che assegna i numeri di
-rete alle organizzazioni che ne fanno richiesta; è poi compito di quest'ultime
+rete alle organizzazioni che ne fanno richiesta; è poi compito di quest'ultime
assegnare i numeri dei singoli host all'interno della propria rete.
Per venire incontro alle richieste dei vari enti e organizzazioni che volevano
\end{table}
Le classi di indirizzi usate per il dispiegamento delle reti su quella che
-comunemente viene chiamata \textit{Internet} sono le prime tre; la classe D è
-destinata al \itindex{multicast} \textit{multicast} mentre la classe E è
+comunemente viene chiamata \textit{Internet} sono le prime tre; la classe D è
+destinata al \itindex{multicast} \textit{multicast} mentre la classe E è
riservata per usi sperimentali e non viene impiegata.
-Come si può notare però la suddivisione riportata in
-tab.~\ref{tab:IP_ipv4class} è largamente inefficiente in quanto se ad un
-utente necessita anche solo un indirizzo in più dei 256 disponibili con una
+Come si può notare però la suddivisione riportata in
+tab.~\ref{tab:IP_ipv4class} è largamente inefficiente in quanto se ad un
+utente necessita anche solo un indirizzo in più dei 256 disponibili con una
classe A occorre passare a una classe B, che ne prevede 65536,\footnote{in
- realtà i valori esatti sarebbero 254 e 65536, una rete con a disposizione
+ realtà i valori esatti sarebbero 254 e 65536, una rete con a disposizione
$N$ bit dell'indirizzo IP, ha disponibili per le singole macchine soltanto
$@^N-2$ numeri, dato che uno deve essere utilizzato come indirizzo di rete e
uno per l'indirizzo di \itindex{broadcast} \textit{broadcast}.} con un
\label{tab:IP_ipv4cidr}
\end{table}
-Per questo nel 1992 è stato introdotto un indirizzamento senza classi (il
+Per questo nel 1992 è stato introdotto un indirizzamento senza classi (il
CIDR, \textit{Classless Inter-Domain Routing}) in cui il limite fra i bit
destinati a indicare il numero di rete e quello destinati a indicare l'host
-finale può essere piazzato in qualunque punto (vedi
-tab.~\ref{tab:IP_ipv4cidr}), permettendo di accorpare più classi A su un'unica
+finale può essere piazzato in qualunque punto (vedi
+tab.~\ref{tab:IP_ipv4cidr}), permettendo di accorpare più classi A su un'unica
rete o suddividere una classe B e diminuendo al contempo il numero di
indirizzi di rete da inserire nelle tabelle di instradamento dei router.
in sez.~\ref{sec:net_tcpip_overview} riguardo al funzionamento generale del
TCP/IP), per eseguire il suo compito il protocollo IP inserisce (come
praticamente ogni protocollo di rete) una opportuna intestazione in cima ai
-dati che deve trasmettere, la cui schematizzazione è riportata in
+dati che deve trasmettere, la cui schematizzazione è riportata in
fig.~\ref{fig:IP_ipv4_head}.
\begin{figure}[htb]
\end{figure}
Ciascuno dei campi illustrati in fig.~\ref{fig:IP_ipv4_head} ha un suo preciso
-scopo e significato, che si è riportato brevemente in
+scopo e significato, che si è riportato brevemente in
tab.~\ref{tab:IP_ipv4field}; si noti come l'intestazione riporti sempre due
-indirizzi IP, quello \textsl{sorgente}, che indica l'IP da cui è partito il
-pacchetto (cioè l'indirizzo assegnato alla macchina che lo spedisce) e quello
+indirizzi IP, quello \textsl{sorgente}, che indica l'IP da cui è partito il
+pacchetto (cioè l'indirizzo assegnato alla macchina che lo spedisce) e quello
\textsl{destinazione} che indica l'indirizzo a cui deve essere inviato il
-pacchetto (cioè l'indirizzo assegnato alla macchina che lo riceverà).
+pacchetto (cioè l'indirizzo assegnato alla macchina che lo riceverà).
\begin{table}[!hbt]
\footnotesize
specifico vale sempre 4.\\
\textit{head length} & 4& Lunghezza dell'intestazione,
in multipli di 32 bit.\\
- \textit{type of service}&8& Il ``\textsl{tipo di servizio}'', è suddiviso
+ \textit{type of service}&8& Il ``\textsl{tipo di servizio}'', è suddiviso
in: 3 bit di precedenza, che nelle attuali
implementazioni del protocollo non vengono
comunque utilizzati; un bit riservato che
deve essere mantenuto a 0; 4 bit che
identificano il tipo di servizio
- richiesto, uno solo dei quali può essere
+ richiesto, uno solo dei quali può essere
attivo.\\
\textit{total length} &16& La \textsl{lunghezza totale}, indica
la dimensione del carico di dati del
pacchetto IP in byte.\\
\textit{identification}&16& L'\textsl{identificazione}, assegnato alla
- creazione, è aumentato di uno all'origine
+ creazione, è aumentato di uno all'origine
della trasmissione di ciascun pacchetto, ma
resta lo stesso per i pacchetti
- frammentati, consentendo così di
+ frammentati, consentendo così di
identificare quelli che derivano dallo
stesso pacchetto originario.\\
\textit{flag} & 3& I \textsl{flag} di controllo nell'ordine: il
- primo è riservato e sempre nullo, il secondo
- indica se il pacchetto non può essere
+ primo è riservato e sempre nullo, il secondo
+ indica se il pacchetto non può essere
frammentato, il terzo se ci sono ulteriori
frammenti.\\
\textit{fragmentation offset}&13& L'\textsl{offset di frammento}, indica
la posizione del frammento rispetto al
pacchetto originale.\\
- \textit{time to live} &16& Il \textsl{tempo di vita}, è decrementato di
+ \textit{time to live} &16& Il \textsl{tempo di vita}, è decrementato di
uno ogni volta che un router ritrasmette il
pacchetto, se arriva a zero il pacchetto
viene scartato.\\
Il campo TOS definisce il cosiddetto \textit{Type of Service}; questo permette
-di definire il tipo di traffico contenuto nei pacchetti, e può essere
-utilizzato dai router per dare diverse priorità in base al valore assunto da
-questo campo. Abbiamo già visto come il valore di questo campo può essere
+di definire il tipo di traffico contenuto nei pacchetti, e può essere
+utilizzato dai router per dare diverse priorità in base al valore assunto da
+questo campo. Abbiamo già visto come il valore di questo campo può essere
impostato sul singolo socket con l'opzione \const{IP\_TOS} (vedi
-sez.~\ref{sec:sock_ipv4_options}), esso inoltre può essere manipolato sia dal
+sez.~\ref{sec:sock_ipv4_options}), esso inoltre può essere manipolato sia dal
sistema del \textit{netfilter} di Linux con il comando \texttt{iptables} che
dal sistema del routing avanzato del comando \texttt{ip route} per consentire
-un controllo più dettagliato dell'instradamento dei pacchetti e l'uso di
-priorità e politiche di distribuzione degli stessi.
+un controllo più dettagliato dell'instradamento dei pacchetti e l'uso di
+priorità e politiche di distribuzione degli stessi.
\begin{table}[!htb]
\centering
\hline
\hline
\const{IPTOS\_LOWDELAY} &\texttt{0x10}& Minimizza i ritardi
- per rendere più veloce
+ per rendere più veloce
possibile la ritrasmissione
dei pacchetti (usato per
traffico interattivo di
controllo come SSH).\\
\const{IPTOS\_THROUGHPUT} &\texttt{0x8} & Ottimizza la trasmissione
- per rendere il più elevato
+ per rendere il più elevato
possibile il flusso netto di
dati (usato su traffico dati,
come quello di FTP).\\
o DHCP).\\
\const{IPTOS\_MINCOST} &\texttt{0x2} & Indica i dati di riempimento,
dove non interessa se si ha
- una bassa velocità di
+ una bassa velocità di
trasmissione, da utilizzare
per i collegamenti con minor
costo (usato per i protocolli
Il campo TTL, acromino di \textit{Time To Live}, viene utilizzato per
stabilire una sorta di tempo di vita massimo dei pacchetti sulla rete. In
-realtà più che di un tempo, il campo serve a limitare il numero massimo di
-salti (i cosiddetti \textit{hop}) che un pacchetto IP può compiere nel passare
+realtà più che di un tempo, il campo serve a limitare il numero massimo di
+salti (i cosiddetti \textit{hop}) che un pacchetto IP può compiere nel passare
da un router ad un altro nel suo attraversamento della rete verso la
destinazione.
\textit{ttl-zero-during-reassembly} se questo avviene alla destinazione finale
(vedi sez.~\ref{sec:ICMP_protocol}).
-In sostanza grazie all'uso di questo accorgimento un pacchetto non può
+In sostanza grazie all'uso di questo accorgimento un pacchetto non può
continuare a vagare indefinitamente sulla rete, e viene comunque scartato dopo
un certo tempo, o meglio, dopo che ha attraversato in certo numero di
-router. Nel caso di Linux il valore iniziale utilizzato normalmente è 64 (vedi
+router. Nel caso di Linux il valore iniziale utilizzato normalmente è 64 (vedi
sez.~\ref{sec:sock_ipv4_sysctl}).
\label{sec:ipv6_protocol}
Negli anni '90 con la crescita del numero di macchine connesse su Internet si
-arrivò a temere l'esaurimento dello spazio degli indirizzi disponibili, specie
+arrivò a temere l'esaurimento dello spazio degli indirizzi disponibili, specie
in vista di una prospettiva (per ora rivelatasi prematura) in cui ogni
apparecchio elettronico sarebbe stato inserito all'interno della rete.
-Per questo motivo si iniziò a progettare una nuova versione del protocollo
+Per questo motivo si iniziò a progettare una nuova versione del protocollo
L'attuale Internet Protocol (IPv4) viene standardizzato nel 1981
dall'\href{http://www.ietf.org/rfc/rfc719.txt}{RFC~719}; esso nasce per
disaccoppiare le applicazioni della struttura hardware delle reti di
trasmissione, e creare una interfaccia di trasmissione dei dati indipendente
-dal sottostante substrato di rete, che può essere realizzato con le tecnologie
-più disparate (Ethernet, Token Ring, FDDI, ecc.).
+dal sottostante substrato di rete, che può essere realizzato con le tecnologie
+più disparate (Ethernet, Token Ring, FDDI, ecc.).
\subsection{I motivi della transizione}
Negli ultimi anni la crescita vertiginosa del numero di macchine connesse a
internet ha iniziato a far emergere i vari limiti di IPv4; in particolare si
-è iniziata a delineare la possibilità di arrivare a una carenza di
+è iniziata a delineare la possibilità di arrivare a una carenza di
indirizzi disponibili.
-In realtà il problema non è propriamente legato al numero di indirizzi
-disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi,
-numeri diversi possibili, che sono molti di più dei computer attualmente
+In realtà il problema non è propriamente legato al numero di indirizzi
+disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi,
+numeri diversi possibili, che sono molti di più dei computer attualmente
esistenti.
-Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
+Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
l'utilizzo delle classi di indirizzamento mostrate in precedenza, ha
comportato che, nella sua evoluzione storica, il dispiegamento delle reti e
l'allocazione degli indirizzi siano stati inefficienti; neanche l'uso del CIDR
livelli e la riassegnazione di tutti gli indirizzi dei computer di ogni
sottorete.
-Diventava perciò necessario progettare un nuovo protocollo che permettesse
-di risolvere questi problemi, e garantisse flessibilità sufficiente per
+Diventava perciò necessario progettare un nuovo protocollo che permettesse
+di risolvere questi problemi, e garantisse flessibilità sufficiente per
poter continuare a funzionare a lungo termine; in particolare necessitava un
nuovo schema di indirizzamento che potesse rispondere alle seguenti
-necessità:
+necessità:
\begin{itemize}
\item un maggior numero di numeri disponibili che consentisse di non restare
- più a corto di indirizzi
-\item un'organizzazione gerarchica più flessibile dell'attuale
+ più a corto di indirizzi
+\item un'organizzazione gerarchica più flessibile dell'attuale
\item uno schema di assegnazione degli indirizzi in grado di minimizzare le
dimensioni delle tabelle di instradamento
\item uno spazio di indirizzi che consentisse un passaggio automatico dalle
Per rispondere alle esigenze descritte in sez.~\ref{sec:IP_whyipv6} IPv6 nasce
come evoluzione di IPv4, mantenendone inalterate le funzioni che si sono
dimostrate valide, eliminando quelle inutili e aggiungendone poche altre
-ponendo al contempo una grande attenzione a mantenere il protocollo il più
+ponendo al contempo una grande attenzione a mantenere il protocollo il più
snello e veloce possibile.
I cambiamenti apportati sono comunque notevoli e possono essere riassunti a
grandi linee nei seguenti punti:
\begin{itemize}
-\item l'espansione delle capacità di indirizzamento e instradamento, per
- supportare una gerarchia con più livelli di indirizzamento, un numero di
+\item l'espansione delle capacità di indirizzamento e instradamento, per
+ supportare una gerarchia con più livelli di indirizzamento, un numero di
nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
si aggiungono agli usuali \textit{unicast} e \itindex{multicast}
\textit{multicast}
\item la semplificazione del formato dell'intestazione, eliminando o rendendo
- opzionali alcuni dei campi di IPv4, per eliminare la necessità di
+ opzionali alcuni dei campi di IPv4, per eliminare la necessità di
riprocessare la stessa da parte dei router e contenere l'aumento di
dimensione dovuto ai nuovi indirizzi
\item un supporto per le opzioni migliorato, per garantire una trasmissione
- più efficiente del traffico normale, limiti meno stringenti sulle
- dimensioni delle opzioni, e la flessibilità necessaria per introdurne di
+ più efficiente del traffico normale, limiti meno stringenti sulle
+ dimensioni delle opzioni, e la flessibilità necessaria per introdurne di
nuove in futuro
-\item il supporto per delle capacità di qualità di servizio (QoS) che
- permetta di identificare gruppi di dati per i quali si può provvedere un
+\item il supporto per delle capacità di qualità di servizio (QoS) che
+ permetta di identificare gruppi di dati per i quali si può provvedere un
trattamento speciale (in vista dell'uso di internet per applicazioni
multimediali e/o ``real-time'')
\end{itemize}
Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
protocollo per gestire la trasmissione dei pacchetti; in
-fig.~\ref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+fig.~\ref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
confrontare con quella di IPv4 in fig.~\ref{fig:IP_ipv4_head}. La spiegazione
-del significato dei vari campi delle due intestazioni è riportato
+del significato dei vari campi delle due intestazioni è riportato
rispettivamente in tab.~\ref{tab:IP_ipv6field} e tab.~\ref{tab:IP_ipv4field})
% \begin{table}[htb]
\end{figure}
-Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
+Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
IPv4; un semplice raddoppio nonostante lo spazio destinato agli indirizzi sia
quadruplicato, questo grazie a una notevole semplificazione che ha ridotto il
\hline
\textit{version} & 4& La \textsl{versione}, nel caso specifico vale
sempre 6.\\
- \textit{priority} & 4& La \textsl{priorità}, vedi
+ \textit{priority} & 4& La \textsl{priorità}, vedi
sez.~\ref{sec:IPv6_prio}.\\
\textit{flow label} &24& L'\textsl{etichetta di flusso}, vedi
sez.~\ref{sec:IP_ipv6_flow}.\\
- \textit{payload length}&16& La \textsl{lunghezza del carico}, cioè del
+ \textit{payload length}&16& La \textsl{lunghezza del carico}, cioè del
corpo dei dati che segue l'intestazione, in
byte. \\
\textit{next header} & 8& L'\textsl{intestazione successiva},
\end{center}
\end{table}
-Abbiamo già anticipato in sez.~\ref{sec:IP_ipv6over} uno dei criteri
-principali nella progettazione di IPv6 è stato quello di ridurre al minimo il
+Abbiamo già anticipato in sez.~\ref{sec:IP_ipv6over} uno dei criteri
+principali nella progettazione di IPv6 è stato quello di ridurre al minimo il
tempo di elaborazione dei pacchetti da parte dei router, un confronto con
l'intestazione di IPv4 (vedi fig.~\ref{fig:IP_ipv4_head}) mostra le seguenti
differenze:
\begin{itemize}
-\item è stato eliminato il campo \textit{header length} in quanto le opzioni
- sono state tolte dall'intestazione che ha così dimensione fissa; ci possono
- essere più intestazioni opzionali (\textsl{intestazioni di estensione}, vedi
- sez.~\ref{sec:IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
+\item è stato eliminato il campo \textit{header length} in quanto le opzioni
+ sono state tolte dall'intestazione che ha così dimensione fissa; ci possono
+ essere più intestazioni opzionali (\textsl{intestazioni di estensione}, vedi
+ sez.~\ref{sec:IP_ipv6_extens}), ciascuna delle quali avrà un suo campo di
lunghezza all'interno.
-\item l'intestazione e gli indirizzi sono allineati a 64 bit, questo rende più
+\item l'intestazione e gli indirizzi sono allineati a 64 bit, questo rende più
veloce il processo da parte di computer con processori a 64 bit.
\item i campi per gestire la frammentazione (\textit{identification},
\textit{flag} e \textit{fragment offset}) sono stati eliminati; questo
- perché la frammentazione è un'eccezione che non deve rallentare
+ perché la frammentazione è un'eccezione che non deve rallentare
l'elaborazione dei pacchetti nel caso normale.
-\item è stato eliminato il campo \textit{checksum} in quanto tutti i
+\item è stato eliminato il campo \textit{checksum} in quanto tutti i
protocolli di livello superiore (TCP, UDP e ICMPv6) hanno un campo di
checksum che include, oltre alla loro intestazione e ai dati, pure i campi
\textit{payload length}, \textit{next header}, e gli indirizzi di origine e
di destinazione; una checksum esiste anche per la gran parte protocolli di
livello inferiore (anche se quelli che non lo hanno, come SLIP, non possono
- essere usati con grande affidabilità); con questa scelta si è ridotto di
- molto il tempo di elaborazione dato che i router non hanno più la necessità
+ essere usati con grande affidabilità); con questa scelta si è ridotto di
+ molto il tempo di elaborazione dato che i router non hanno più la necessità
di ricalcolare la checksum ad ogni passaggio di un pacchetto per il
cambiamento del campo \textit{hop limit}.
-\item è stato eliminato il campo \textit{type of service}, che praticamente
- non è mai stato utilizzato; una parte delle funzionalità ad esso delegate
+\item è stato eliminato il campo \textit{type of service}, che praticamente
+ non è mai stato utilizzato; una parte delle funzionalità ad esso delegate
sono state reimplementate (vedi il campo \textit{priority} al prossimo
punto) con altri metodi.
-\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
+\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
insieme al campo \textit{priority} (che recupera i bit di precedenza del
campo \textit{type of service}) per implementare la gestione di una
- ``\textsl{qualità di servizio}'' (vedi sez.~\ref{sec:IP_ipv6_qos}) che
+ ``\textsl{qualità di servizio}'' (vedi sez.~\ref{sec:IP_ipv6_qos}) che
permette di identificare i pacchetti appartenenti a un ``\textsl{flusso}''
- di dati per i quali si può provvedere un trattamento speciale.
+ di dati per i quali si può provvedere un trattamento speciale.
\end{itemize}
Oltre alle differenze precedenti, relative ai singoli campi nell'intestazione,
quello di IPv6 sono le seguenti:
\begin{itemize}
-\item il \itindex{broadcast} \textit{broadcasting} non è previsto in IPv6, le
+\item il \itindex{broadcast} \textit{broadcasting} non è previsto in IPv6, le
applicazioni che lo usano dovono essere reimplementate usando il
\itindex{multicast} \textit{multicasting} (vedi
sez.~\ref{sec:IP_ipv6_multicast}), che da opzionale diventa obbligatorio.
-\item è stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}.
-\item i router non possono più frammentare i pacchetti lungo il cammino, la
- frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
+\item è stato introdotto un nuovo tipo di indirizzi, gli \textit{anycast}.
+\item i router non possono più frammentare i pacchetti lungo il cammino, la
+ frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
capi della comunicazione (usando un'apposita estensione vedi
sez.~\ref{sec:IP_ipv6_extens}).
\item IPv6 richiede il supporto per il \itindex{Maximum~Transfer~Unit}
- \textit{path MTU discovery} (cioè il protocollo per la selezione della
+ \textit{path MTU discovery} (cioè il protocollo per la selezione della
massima lunghezza del pacchetto); seppure questo sia in teoria opzionale,
- senza di esso non sarà possibile inviare pacchetti più larghi della
+ senza di esso non sarà possibile inviare pacchetti più larghi della
dimensione minima (576 byte).
\end{itemize}
\subsection{Gli indirizzi di IPv6}
\label{sec:IP_ipv6_addr}
-Come già abbondantemente anticipato la principale novità di IPv6 è
+Come già abbondantemente anticipato la principale novità di IPv6 è
costituita dall'ampliamento dello spazio degli indirizzi, che consente di avere
indirizzi disponibili in un numero dell'ordine di quello degli atomi che
costituiscono la terra.
-In realtà l'allocazione di questi indirizzi deve tenere conto della
-necessità di costruire delle gerarchie che consentano un instradamento
-rapido ed efficiente dei pacchetti, e flessibilità nel dispiegamento delle
+In realtà l'allocazione di questi indirizzi deve tenere conto della
+necessità di costruire delle gerarchie che consentano un instradamento
+rapido ed efficiente dei pacchetti, e flessibilità nel dispiegamento delle
reti, il che comporta una riduzione drastica dei numeri utilizzabili; uno
studio sull'efficienza dei vari sistemi di allocazione usati in altre
-architetture (come i sistemi telefonici) è comunque giunto alla conclusione
+architetture (come i sistemi telefonici) è comunque giunto alla conclusione
che anche nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di
-fornire più di un migliaio di indirizzi per ogni metro quadro della
+fornire più di un migliaio di indirizzi per ogni metro quadro della
superficie terrestre.
\subsection{La notazione}
\label{sec:IP_ipv6_notation}
-Con un numero di bit quadruplicato non è più possibile usare la notazione
+Con un numero di bit quadruplicato non è più possibile usare la notazione
coi numeri decimali di IPv4 per rappresentare un numero IP. Per questo gli
indirizzi di IPv6 sono in genere scritti come sequenze di otto numeri
-esadecimali di 4 cifre (cioè a gruppi di 16 bit) usando i due punti come
-separatore; cioè qualcosa del tipo
+esadecimali di 4 cifre (cioè a gruppi di 16 bit) usando i due punti come
+separatore; cioè qualcosa del tipo
\texttt{5f1b:df00:ce3e:e200:0020:0800:2078:e3e3}.
Visto che la notazione resta comunque piuttosto pesante esistono alcune
-abbreviazioni; si può evitare di scrivere gli zeri iniziali per cui si
-può scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero è
-zero si può omettere del tutto, così come un insieme di zeri (ma questo
-solo una volta per non generare ambiguità) per cui il precedente indirizzo
-si può scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}.
+abbreviazioni; si può evitare di scrivere gli zeri iniziali per cui si
+può scrivere \texttt{1080:0:0:0:8:800:ba98:2078:e3e3}; se poi un intero è
+zero si può omettere del tutto, così come un insieme di zeri (ma questo
+solo una volta per non generare ambiguità) per cui il precedente indirizzo
+si può scrivere anche come \texttt{1080::8:800:ba98:2078:e3e3}.
Infine per scrivere un indirizzo IPv4 all'interno di un indirizzo IPv6 si
-può usare la vecchia notazione con i punti, per esempio
+può usare la vecchia notazione con i punti, per esempio
\texttt{::192.84.145.138}.
\begin{table}[htb]
\textit{multicast} & \texttt{1111 1111} & 1/256 \\
\hline
\end{tabular}
- \caption{Classificazione degli indirizzi IPv6 a seconda dei bit più
+ \caption{Classificazione degli indirizzi IPv6 a seconda dei bit più
significativi}
\label{tab:IP_ipv6addr}
\end{table}
\textit{multicast} e \textit{anycast}) di interfacce di rete.
Gli indirizzi sono sempre assegnati all'interfaccia, non al nodo che la
-ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo può
+ospita; dato che ogni interfaccia appartiene ad un nodo quest'ultimo può
essere identificato attraverso uno qualunque degli indirizzi unicast delle sue
-interfacce. A una interfaccia possono essere associati anche più indirizzi.
+interfacce. A una interfaccia possono essere associati anche più indirizzi.
IPv6 presenta tre tipi diversi di indirizzi: due di questi, gli indirizzi
\textit{unicast} e \itindex{multicast} \textit{multicast} hanno le stesse
-caratteristiche che in IPv4, un terzo tipo, gli indirizzi \textit{anycast} è
-completamente nuovo. In IPv6 non esistono più gli indirizzi
+caratteristiche che in IPv4, un terzo tipo, gli indirizzi \textit{anycast} è
+completamente nuovo. In IPv6 non esistono più gli indirizzi
\itindex{broadcast} \textit{broadcast}, la funzione di questi ultimi deve
essere reimplementata con gli indirizzi \itindex{multicast}
\textit{multicast}.
Gli indirizzi \textit{unicast} identificano una singola interfaccia: i
pacchetti mandati ad un tale indirizzo verranno inviati a quella interfaccia,
gli indirizzi \textit{anycast} identificano un gruppo di interfacce tale che
-un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina
+un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina
(nel senso di distanza di routing) delle interfacce del gruppo, gli indirizzi
\itindex{multicast} \textit{multicast} identificano un gruppo di interfacce
tale che un pacchetto mandato a uno di questi indirizzi viene inviato a tutte
le interfacce del gruppo.
-In IPv6 non ci sono più le classi ma i bit più significativi indicano il tipo
+In IPv6 non ci sono più le classi ma i bit più significativi indicano il tipo
di indirizzo; in tab.~\ref{tab:IP_ipv6addr} sono riportati i valori di detti
-bit e il tipo di indirizzo che loro corrispondente. I bit più significativi
-costituiscono quello che viene chiamato il \textit{format prefix} ed è sulla
+bit e il tipo di indirizzo che loro corrispondente. I bit più significativi
+costituiscono quello che viene chiamato il \textit{format prefix} ed è sulla
base di questo che i vari tipi di indirizzi vengono identificati. Come si
vede questa architettura di allocazione supporta l'allocazione di indirizzi
per i provider, per uso locale e per il \itindex{multicast}
-\textit{multicast}; inoltre è stato riservato lo spazio per indirizzi NSAP,
-IPX e per le connessioni; gran parte dello spazio (più del 70\%) è riservato
+\textit{multicast}; inoltre è stato riservato lo spazio per indirizzi NSAP,
+IPX e per le connessioni; gran parte dello spazio (più del 70\%) è riservato
per usi futuri.
Si noti infine che gli indirizzi \textit{anycast} non sono riportati in
nell'\href{http://www.ietf.org/rfc/rfc2073.txt}{RFC~2073} e sono gli
equivalenti degli attuali indirizzi delle classi da A a C.
-L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per
+L'autorità che presiede all'allocazione di questi indirizzi è la IANA; per
evitare i problemi di crescita delle tabelle di instradamento e una procedura
-efficiente di allocazione la struttura di questi indirizzi è organizzata fin
-dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi è
+efficiente di allocazione la struttura di questi indirizzi è organizzata fin
+dall'inizio in maniera gerarchica; pertanto lo spazio di questi indirizzi è
stato suddiviso in una serie di campi secondo lo schema riportato in
tab.~\ref{tab:IP_ipv6_unicast}.
\label{tab:IP_ipv6_unicast}
\end{table}
-Al livello più alto la IANA può delegare l'allocazione a delle autorità
+Al livello più alto la IANA può delegare l'allocazione a delle autorità
regionali (i Regional Register) assegnando ad esse dei blocchi di indirizzi; a
-queste autorità regionali è assegnato un Registry Id che deve seguire
+queste autorità regionali è assegnato un Registry Id che deve seguire
immediatamente il prefisso di formato. Al momento sono definite tre registri
-regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si è riservata la
-possibilità di allocare indirizzi su base regionale; pertanto sono previsti
+regionali (INTERNIC, RIPE NCC e APNIC), inoltre la IANA si è riservata la
+possibilità di allocare indirizzi su base regionale; pertanto sono previsti
i seguenti possibili valori per il \textsl{Registry Id};
gli altri valori restano riservati per la IANA.
\begin{table}[htb]
singoli registri regionali. Questi ultimi dovranno definire come dividere lo
spazio di indirizzi assegnato a questi due campi (che ammonta a un totale di
56~bit), definendo lo spazio da assegnare al \textit{Provider Id} e
-al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei
-numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata
-l'autorità di allocare i \textit{Subscriber Id} al loro interno.
+al \textit{Subscriber Id}, ad essi spetterà inoltre anche l'allocazione dei
+numeri di \textit{Provider Id} ai singoli fornitori, ai quali sarà delegata
+l'autorità di allocare i \textit{Subscriber Id} al loro interno.
-L'ultimo livello è quello \textit{Intra-subscriber} che è lasciato alla
+L'ultimo livello è quello \textit{Intra-subscriber} che è lasciato alla
gestione dei singoli fruitori finali, gli indirizzi \textit{provider-based}
lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la
-modalità più immediata è quella di usare uno schema del tipo mostrato in
-tab.~\ref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal
+modalità più immediata è quella di usare uno schema del tipo mostrato in
+tab.~\ref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal
MAC-address a 48~bit dello standard Ethernet, scritto in genere nell'hardware
delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete.
\label{tab:IP_ipv6_uninterf}
\end{table}
-Qualora si dovesse avere a che fare con una necessità di un numero più
+Qualora si dovesse avere a che fare con una necessità di un numero più
elevato di sotto-reti, il precedente schema andrebbe modificato, per evitare
l'enorme spreco dovuto all'uso dei MAC-address, a questo scopo si possono
-usare le capacità di auto-configurazione di IPv6 per assegnare indirizzi
+usare le capacità di auto-configurazione di IPv6 per assegnare indirizzi
generici con ulteriori gerarchie per sfruttare efficacemente tutto lo spazio
di indirizzi.
-Un registro regionale può introdurre un ulteriore livello nella gerarchia
-degli indirizzi, allocando dei blocchi per i quali delegare l'autorità a dei
+Un registro regionale può introdurre un ulteriore livello nella gerarchia
+degli indirizzi, allocando dei blocchi per i quali delegare l'autorità a dei
registri nazionali, quest'ultimi poi avranno il compito di gestire la
attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
-paese coperto dal registro nazionale con le modalità viste in precedenza.
-Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
+paese coperto dal registro nazionale con le modalità viste in precedenza.
+Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
mostrato in tab.~\ref{tab:IP_ipv6_uninaz}.
\begin{table}[htb]
Gli indirizzi ad uso locale sono indirizzi unicast che sono instradabili solo
localmente (all'interno di un sito o di una sottorete), e possono avere una
-unicità locale o globale.
+unicità locale o globale.
Questi indirizzi sono pensati per l'uso all'interno di un sito per mettere su
una comunicazione locale immediata, o durante le fasi di auto-configurazione
\end{table}
Ci sono due tipi di indirizzi, \textit{link-local} e \textit{site-local}. Il
-primo è usato per un singolo link; la struttura è mostrata in
+primo è usato per un singolo link; la struttura è mostrata in
tab.~\ref{tab:IP_ipv6_linklocal}, questi indirizzi iniziano sempre con un
valore nell'intervallo \texttt{FE80}--\texttt{FEBF} e vengono in genere usati
per la configurazione automatica dell'indirizzo al bootstrap e per la ricerca
dei vicini (vedi \ref{sec:IP_ipv6_autoconf}); un pacchetto che abbia tale
indirizzo come sorgente o destinazione non deve venire ritrasmesso dai router.
-Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
+Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
all'interno di un sito che non necessita di un prefisso globale; la struttura
-è mostrata in tab.~\ref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano
+è mostrata in tab.~\ref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano
sempre con un valore nell'intervallo \texttt{FEC0}--\texttt{FEFF} e non devono
venire ritrasmessi dai router all'esterno del sito stesso; sono in sostanza
gli equivalenti degli indirizzi riservati per reti private definiti su IPv4.
-Per entrambi gli indirizzi il campo \textit{Interface Id} è un identificatore
+Per entrambi gli indirizzi il campo \textit{Interface Id} è un identificatore
che deve essere unico nel dominio in cui viene usato, un modo immediato per
-costruirlo è quello di usare il MAC-address delle schede di rete.
+costruirlo è quello di usare il MAC-address delle schede di rete.
\begin{table}[!h]
\centering
\label{tab:IP_ipv6_sitelocal}
\end{table}
-Gli indirizzi di uso locale consentono ad una organizzazione che non è
+Gli indirizzi di uso locale consentono ad una organizzazione che non è
(ancora) connessa ad Internet di operare senza richiedere un prefisso globale,
una volta che in seguito l'organizzazione venisse connessa a Internet
potrebbe continuare a usare la stessa suddivisione effettuata con gli
\label{sec:IP_ipv6_reserved}
Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi
-di compatibilità.
+di compatibilità.
Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
tab.~\ref{tab:IP_ipv6_map}), questo sono indirizzi unicast che vengono usati
\label{tab:IP_ipv6_map}
\end{table}
-Un secondo tipo di indirizzi di compatibilità sono gli \textsl{IPv4
+Un secondo tipo di indirizzi di compatibilità sono gli \textsl{IPv4
compatibili IPv6} (vedi tab.~\ref{tab:IP_ipv6_comp}) usati nella transizione
da IPv4 a IPv6: quando un nodo che supporta sia IPv6 che IPv4 non ha un router
IPv6 deve usare nel DNS un indirizzo di questo tipo, ogni pacchetto IPv6
-inviato a un tale indirizzo verrà automaticamente incapsulato in IPv4.
+inviato a un tale indirizzo verrà automaticamente incapsulato in IPv4.
\begin{table}[htb]
\centering
\end{table}
Altri indirizzi speciali sono il \textit{loopback address}, costituito da 127
-zeri ed un uno (cioè \texttt{::1}) e l'\textsl{indirizzo generico}
-costituito da tutti zeri (scritto come \texttt{0::0} o ancora più
+zeri ed un uno (cioè \texttt{::1}) e l'\textsl{indirizzo generico}
+costituito da tutti zeri (scritto come \texttt{0::0} o ancora più
semplicemente come \texttt{:}) usato in genere quando si vuole indicare
l'accettazione di una connessione da qualunque host.
Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un
gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di
\textit{multicast} e il pacchetto viene inviato a tutte le interfacce di detto
-gruppo. Un'interfaccia può appartenere ad un numero qualunque numero di
-gruppi di \textit{multicast}. Il formato degli indirizzi \textit{multicast} è
+gruppo. Un'interfaccia può appartenere ad un numero qualunque numero di
+gruppi di \textit{multicast}. Il formato degli indirizzi \textit{multicast} è
riportato in tab.~\ref{tab:IP_ipv6_multicast}:
\begin{table}[htb]
\label{tab:IP_ipv6_multicast}
\end{table}
-Il prefisso di formato per tutti gli indirizzi \textit{multicast} è
-\texttt{FF}, ad esso seguono i due campi il cui significato è il seguente:
+Il prefisso di formato per tutti gli indirizzi \textit{multicast} è
+\texttt{FF}, ad esso seguono i due campi il cui significato è il seguente:
\begin{itemize}
\item \textsl{flag}: un insieme di 4 bit, di cui i primi tre sono riservati e
- posti a zero, l'ultimo è zero se l'indirizzo è permanente (cioè un
- indirizzo noto, assegnato dalla IANA), ed è uno se invece l'indirizzo è
+ posti a zero, l'ultimo è zero se l'indirizzo è permanente (cioè un
+ indirizzo noto, assegnato dalla IANA), ed è uno se invece l'indirizzo è
transitorio.
-\item \textsl{scop} è un numero di quattro bit che indica il raggio di
- validità dell'indirizzo, i valori assegnati per ora sono riportati in
+\item \textsl{scop} è un numero di quattro bit che indica il raggio di
+ validità dell'indirizzo, i valori assegnati per ora sono riportati in
tab.~\ref{tab:IP_ipv6_multiscope}.
\end{itemize}
\end{table}
Infine l'ultimo campo identifica il gruppo di \textit{multicast}, sia
-permanente che transitorio, all'interno del raggio di validità del medesimo.
+permanente che transitorio, all'interno del raggio di validità del medesimo.
Alcuni indirizzi \textit{multicast}, riportati in tab.~\ref{tab:multiadd} sono
-già riservati per il funzionamento della rete.
+già riservati per il funzionamento della rete.
\begin{table}[!htb]
\centering
\end{table}
L'utilizzo del campo di \textit{scope} e di questi indirizzi predefiniti serve
-a recuperare le funzionalità del \itindex{broadcast} \textit{broadcasting} (ad
+a recuperare le funzionalità del \itindex{broadcast} \textit{broadcasting} (ad
esempio inviando un pacchetto all'indirizzo \texttt{FF02:0:0:0:0:0:0:1} si
raggiungono tutti i nodi locali).
Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un
gruppo di interfacce: un pacchetto indirizzato a questo tipo di indirizzo
-viene inviato al componente del gruppo più ``\textsl{vicino}'' secondo la
+viene inviato al componente del gruppo più ``\textsl{vicino}'' secondo la
distanza di instradamento calcolata dai router.
Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast,
usando uno dei formati disponibili, e per questo, sono da essi assolutamente
-indistinguibili. Quando un indirizzo unicast viene assegnato a più interfacce
-(trasformandolo in un anycast) il computer su cui è l'interfaccia deve essere
+indistinguibili. Quando un indirizzo unicast viene assegnato a più interfacce
+(trasformandolo in un anycast) il computer su cui è l'interfaccia deve essere
configurato per tener conto del fatto.
Gli indirizzi anycast consentono a un nodo sorgente di inviare pacchetti a una
destinazione su un gruppo di possibili interfacce selezionate. La sorgente non
-deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca al
+deve curarsi di come scegliere l'interfaccia più vicina, compito che tocca al
sistema di instradamento (in sostanza la sorgente non ha nessun controllo
sulla selezione).
una particolare sottorete, o che forniscono l'accesso a un certo sotto
dominio.
-L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per
-poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta
+L'idea alla base degli indirizzi anycast è perciò quella di utilizzarli per
+poter raggiungere il fornitore di servizio più vicino; ma restano aperte tutta
una serie di problematiche, visto che una connessione con uno di questi
-indirizzi non è possibile, dato che per una variazione delle distanze di
-routing non è detto che due pacchetti successivi finiscano alla stessa
+indirizzi non è possibile, dato che per una variazione delle distanze di
+routing non è detto che due pacchetti successivi finiscano alla stessa
interfaccia.
-La materia è pertanto ancora controversa e in via di definizione.
+La materia è pertanto ancora controversa e in via di definizione.
\subsection{Le estensioni}
\label{sec:IP_ipv6_extens}
-Come già detto in precedenza IPv6 ha completamente cambiato il trattamento
+Come già detto in precedenza IPv6 ha completamente cambiato il trattamento
delle opzioni; queste ultime infatti sono state tolte dall'intestazione del
pacchetto, e poste in apposite \textsl{intestazioni di estensione} (o
\textit{extension header}) poste fra l'intestazione di IPv6 e l'intestazione
del protocollo di trasporto.
-Per aumentare la velocità di elaborazione, sia dei dati del livello seguente
+Per aumentare la velocità di elaborazione, sia dei dati del livello seguente
che di ulteriori opzioni, ciascuna estensione deve avere una lunghezza
multipla di 8 byte per mantenere l'allineamento a 64~bit di tutti le
intestazioni seguenti.
prestazioni rispetto a IPv4 dove la presenza di un'opzione comportava l'esame
di tutte quante.
-Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di
+Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di
lunghezza arbitraria e non limitate a 40 byte; questo, insieme al modo in cui
vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la
sicurezza, improponibili con IPv4.
\begin{itemize}
\item \textbf{Hop by hop} devono seguire immediatamente l'intestazione
principale; indicano le opzioni che devono venire processate ad ogni
- passaggio da un router, fra di esse è da menzionare la \textit{jumbo
+ passaggio da un router, fra di esse è da menzionare la \textit{jumbo
payload} che segnala la presenza di un pacchetto di dati di dimensione
superiore a 65535 byte.
\item \textbf{Destination options} opzioni che devono venire esaminate al nodo
- di ricevimento, nessuna di esse è tuttora definita.
+ di ricevimento, nessuna di esse è tuttora definita.
\item \textbf{Routing} definisce una \textit{source route} (come la analoga
- opzione di IPv4) cioè una lista di indirizzi IP di nodi per i quali il
+ opzione di IPv4) cioè una lista di indirizzi IP di nodi per i quali il
pacchetto deve passare.
\item \textbf{Fragmentation} viene generato automaticamente quando un host
- vuole frammentare un pacchetto, ed è riprocessato automaticamente alla
+ vuole frammentare un pacchetto, ed è riprocessato automaticamente alla
destinazione che riassembla i frammenti.
\item \textbf{Authentication} gestisce l'autenticazione e il controllo di
- integrità dei pacchetti; è documentato
+ integrità dei pacchetti; è documentato
dall'\href{http://www.ietf.org/rfc/rfc1826.txt}{RFC~1826}.
\item \textbf{Encapsulation} serve a gestire la segretezza del contenuto
- trasmesso; è documentato
+ trasmesso; è documentato
dall'\href{http://www.ietf.org/rfc/rfc1827.txt}{RFC~1827}.
\end{itemize}
-La presenza di opzioni è rilevata dal valore del campo \textit{next header}
-che indica qual è l'intestazione successiva a quella di IPv6; in assenza di
-opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
-superiore, per cui il campo assumerà lo stesso valore del campo
-\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
+La presenza di opzioni è rilevata dal valore del campo \textit{next header}
+che indica qual è l'intestazione successiva a quella di IPv6; in assenza di
+opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
+superiore, per cui il campo assumerà lo stesso valore del campo
+\textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
presente; i valori possibili sono riportati in
tab.~\ref{tab:IP_ipv6_nexthead}.
\end{center}
\end{table}
-Questo meccanismo permette la presenza di più opzioni in successione prima
+Questo meccanismo permette la presenza di più opzioni in successione prima
del pacchetto del protocollo di trasporto; l'ordine raccomandato per le
-estensioni è quello riportato nell'elenco precedente con la sola differenza
+estensioni è quello riportato nell'elenco precedente con la sola differenza
che le opzioni di destinazione sono inserite nella posizione ivi indicata solo
se, come per il tunnelling, devono essere esaminate dai router, quelle che
devono essere esaminate solo alla destinazione finale vanno in coda.
-\subsection{Qualità di servizio}
+\subsection{Qualità di servizio}
\label{sec:IP_ipv6_qos}
-Una delle caratteristiche innovative di IPv6 è quella di avere introdotto un
-supporto per la qualità di servizio che è importante per applicazioni come
+Una delle caratteristiche innovative di IPv6 è quella di avere introdotto un
+supporto per la qualità di servizio che è importante per applicazioni come
quelle multimediali o ``real-time'' che richiedono un qualche grado di
-controllo sulla stabilità della banda di trasmissione, sui ritardi o la
+controllo sulla stabilità della banda di trasmissione, sui ritardi o la
dispersione dei temporale del flusso dei pacchetti.
\subsection{Etichette di flusso}
\label{sec:IP_ipv6_flow}
-L'introduzione del campo \textit{flow label} può essere usata dall'origine
+L'introduzione del campo \textit{flow label} può essere usata dall'origine
della comunicazione per etichettare quei pacchetti per i quali si vuole un
trattamento speciale da parte dei router come un una garanzia di banda minima
assicurata o un tempo minimo di instradamento/trasmissione garantito.
-Questo aspetto di IPv6 è ancora sperimentale per cui i router che non
+Questo aspetto di IPv6 è ancora sperimentale per cui i router che non
supportino queste funzioni devono porre a zero il \textit{flow label} per i
pacchetti da loro originanti e lasciare invariato il campo per quelli in
transito.
-Un flusso è una sequenza di pacchetti da una particolare origine a una
+Un flusso è una sequenza di pacchetti da una particolare origine a una
particolare destinazione per il quale l'origine desidera un trattamento
speciale da parte dei router che lo manipolano; la natura di questo
-trattamento può essere comunicata ai router in vari modi (come un protocollo
+trattamento può essere comunicata ai router in vari modi (come un protocollo
di controllo o con opzioni del tipo \textit{hop-by-hop}).
-Ci possono essere più flussi attivi fra un'origine e una destinazione, come
+Ci possono essere più flussi attivi fra un'origine e una destinazione, come
del traffico non assegnato a nessun flusso, un flusso viene identificato
univocamente dagli indirizzi di origine e destinazione e da una etichetta di
flusso diversa da zero, il traffico normale deve avere l'etichetta di flusso
posta a zero.
-L'etichetta di flusso è assegnata dal nodo di origine, i valori devono
+L'etichetta di flusso è assegnata dal nodo di origine, i valori devono
essere scelti in maniera (pseudo)casuale nel range fra 1 e FFFFFF in modo da
rendere utilizzabile un qualunque sottoinsieme dei bit come chiavi di hash per
i router.
-\subsection{Priorità}
+\subsection{Priorità}
\label{sec:IPv6_prio}
-Il campo di priorità consente di indicare il livello di priorità dei
+Il campo di priorità consente di indicare il livello di priorità dei
pacchetti relativamente agli altri pacchetti provenienti dalla stessa
sorgente. I valori sono divisi in due intervalli, i valori da 0 a 7 sono usati
-per specificare la priorità del traffico per il quale la sorgente provvede
-un controllo di congestione cioè per il traffico che può essere ``tirato
+per specificare la priorità del traffico per il quale la sorgente provvede
+un controllo di congestione cioè per il traffico che può essere ``tirato
indietro'' in caso di congestione come quello di TCP, i valori da 8 a 15 sono
usati per i pacchetti che non hanno questa caratteristica, come i pacchetti
``real-time'' inviati a ritmo costante.
Per il traffico con controllo di congestione sono raccomandati i seguenti
-valori di priorità a seconda del tipo di applicazione:
+valori di priorità a seconda del tipo di applicazione:
\begin{table}[htb]
\centering
\label{tab:priority}
\end{table}
-Per il traffico senza controllo di congestione la priorità più bassa
+Per il traffico senza controllo di congestione la priorità più bassa
dovrebbe essere usata per quei pacchetti che si preferisce siano scartati
-più facilmente in caso di congestione.
+più facilmente in caso di congestione.
\subsection{Sicurezza a livello IP}
La attuale implementazione di Internet presenta numerosi problemi di
sicurezza, in particolare i dati presenti nelle intestazioni dei vari
-protocolli sono assunti essere corretti, il che da adito alla possibilità di
+protocolli sono assunti essere corretti, il che da adito alla possibilità di
varie tipologie di attacco forgiando pacchetti false, inoltre tutti questi
dati passano in chiaro sulla rete e sono esposti all'osservazione di chiunque
si trovi in mezzo.
-Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
+Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
riservatezza a un livello inferiore al primo (quello di applicazione), con
-IPv6 è stato progettata la possibilità di intervenire al livello di rete (il
+IPv6 è stato progettata la possibilità di intervenire al livello di rete (il
terzo) prevedendo due apposite estensioni che possono essere usate per fornire
livelli di sicurezza a seconda degli utenti. La codifica generale di questa
-architettura è riportata
+architettura è riportata
nell'\href{http://www.ietf.org/rfc/rfc2401.txt}{RFC~2401}.
Il meccanismo in sostanza si basa su due estensioni:
\begin{itemize}
\item una intestazione di sicurezza (\textit{authentication header}) che
- garantisce al destinatario l'autenticità del pacchetto
+ garantisce al destinatario l'autenticità del pacchetto
\item un carico di sicurezza (\textit{Encrypted Security Payload}) che
- assicura che solo il legittimo ricevente può leggere il pacchetto.
+ assicura che solo il legittimo ricevente può leggere il pacchetto.
\end{itemize}
-Perché tutto questo funzioni le stazioni sorgente e destinazione devono
+Perché tutto questo funzioni le stazioni sorgente e destinazione devono
usare una stessa chiave crittografica e gli stessi algoritmi, l'insieme degli
accordi fra le due stazioni per concordare chiavi e algoritmi usati va sotto
il nome di associazione di sicurezza.
I pacchetti autenticati e crittografati portano un indice dei parametri di
sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima
-di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di
-\textit{multicast} dovrà essere lo stesso per tutte le stazioni del gruppo.
+di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di
+\textit{multicast} dovrà essere lo stesso per tutte le stazioni del gruppo.
\subsection{Autenticazione}
\label{sec:auth}
-Il primo meccanismo di sicurezza è quello dell'intestazione di autenticazione
+Il primo meccanismo di sicurezza è quello dell'intestazione di autenticazione
(\textit{authentication header}) che fornisce l'autenticazione e il controllo
-di integrità (ma senza riservatezza) dei pacchetti IP.
+di integrità (ma senza riservatezza) dei pacchetti IP.
L'intestazione di autenticazione ha il formato descritto in
fig.~\ref{fig:autent_estens}: il campo \textit{Next Header} indica
stazione sorgente deve incrementare di pacchetto in pacchetto.
Completano l'intestazione i dati di autenticazione che contengono un valore di
-controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere
-di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
+controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere
+di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
per allineare l'intestazione a 64 bit. Tutti gli algoritmi di autenticazione
-devono provvedere questa capacità.
+devono provvedere questa capacità.
\begin{figure}[!htb]
\centering
\label{fig:autent_estens}
\end{figure}
-L'intestazione di autenticazione può essere impiegata in due modi diverse
-modalità: modalità trasporto e modalità tunnel.
+L'intestazione di autenticazione può essere impiegata in due modi diverse
+modalità: modalità trasporto e modalità tunnel.
-La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni
+La modalità trasporto è utilizzabile solo per comunicazioni fra stazioni
singole che supportino l'autenticazione. In questo caso l'intestazione di
-autenticazione è inserita dopo tutte le altre intestazioni di estensione
-eccezion fatta per la \textit{Destination Option} che può comparire sia
+autenticazione è inserita dopo tutte le altre intestazioni di estensione
+eccezion fatta per la \textit{Destination Option} che può comparire sia
prima che dopo.
\begin{figure}[!htb]
\label{fig:AH_autent_head}
\end{figure}
-La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni
-singole che con un gateway di sicurezza; in questa modalità ...
+La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni
+singole che con un gateway di sicurezza; in questa modalità ...
-L'intestazione di autenticazione è una intestazione di estensione inserita
+L'intestazione di autenticazione è una intestazione di estensione inserita
dopo l'intestazione principale e prima del carico dei dati. La sua presenza
-non ha perciò alcuna influenza sui livelli superiori dei protocolli di
+non ha perciò alcuna influenza sui livelli superiori dei protocolli di
trasmissione come il TCP.
-La procedura di autenticazione cerca di garantire l'autenticità del pacchetto
+La procedura di autenticazione cerca di garantire l'autenticità del pacchetto
nella massima estensione possibile, ma dato che alcuni campi dell'intestazione
di IP possono variare in maniera impredicibile alla sorgente, il loro valore
-non può essere protetto dall'autenticazione.
+non può essere protetto dall'autenticazione.
Il calcolo dei dati di autenticazione viene effettuato alla sorgente su una
versione speciale del pacchetto in cui il numero di salti nell'intestazione
-principale è impostato a zero, così come le opzioni che possono essere
-modificate nella trasmissione, e l'intestazione di routing (se usata) è posta
+principale è impostato a zero, così come le opzioni che possono essere
+modificate nella trasmissione, e l'intestazione di routing (se usata) è posta
ai valori che deve avere all'arrivo.
-L'estensione è indipendente dall'algoritmo particolare, e il protocollo è
-ancora in fase di definizione; attualmente è stato suggerito l'uso di una
+L'estensione è indipendente dall'algoritmo particolare, e il protocollo è
+ancora in fase di definizione; attualmente è stato suggerito l'uso di una
modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche
una chiave che viene inserita all'inizio e alla fine degli altri campi.
\subsection{Riservatezza}
\label{sec:ecry}
-Per garantire una trasmissione riservata dei dati, è stata previsto la
-possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
+Per garantire una trasmissione riservata dei dati, è stata previsto la
+possibilità di trasmettere pacchetti con i dati criptati: il cosiddetto ESP,
\textit{Encripted Security Payload}. Questo viene realizzato usando con una
apposita opzione che deve essere sempre l'ultima delle intestazioni di
estensione; ad essa segue il carico del pacchetto che viene criptato.
Un pacchetto crittografato pertanto viene ad avere una struttura del tipo di
quella mostrata in fig.~\ref{fig:ESP_criptopack}, tutti i campi sono in chiaro
-fino al vettore di inizializzazione, il resto è crittografato.
+fino al vettore di inizializzazione, il resto è crittografato.
\subsection{Auto-configurazione}
\label{sec:IP_ipv6_autoconf}
-Una delle caratteristiche salienti di IPv6 è quella dell'auto-configurazione,
-il protocollo infatti fornisce la possibilità ad un nodo di scoprire
+Una delle caratteristiche salienti di IPv6 è quella dell'auto-configurazione,
+il protocollo infatti fornisce la possibilità ad un nodo di scoprire
automaticamente il suo indirizzo acquisendo i parametri necessari per potersi
connettere a internet.
L'auto-configurazione sfrutta gli indirizzi link-local; qualora sul nodo sia
presente una scheda di rete che supporta lo standard IEEE802 (ethernet) questo
garantisce la presenza di un indirizzo fisico a 48 bit unico; pertanto il nodo
-può assumere automaticamente senza pericoli di collisione l'indirizzo
-link-local \texttt{FE80::xxxx:xxxx:xxxx} dove \texttt{xxxx:xxxx:xxxx} è
+può assumere automaticamente senza pericoli di collisione l'indirizzo
+link-local \texttt{FE80::xxxx:xxxx:xxxx} dove \texttt{xxxx:xxxx:xxxx} è
l'indirizzo hardware della scheda di rete.
Nel caso in cui non sia presente una scheda che supporta lo standard IEEE802
-allora il nodo assumerà ugualmente un indirizzo link-local della forma
-precedente, ma il valore di \texttt{xxxx:xxxx:xxxx} sarà generato
-casualmente; in questo caso la probabilità di collisione è di 1 su 300
-milioni. In ogni caso per prevenire questo rischio il nodo invierà un
+allora il nodo assumerà ugualmente un indirizzo link-local della forma
+precedente, ma il valore di \texttt{xxxx:xxxx:xxxx} sarà generato
+casualmente; in questo caso la probabilità di collisione è di 1 su 300
+milioni. In ogni caso per prevenire questo rischio il nodo invierà un
messaggio ICMP \textit{Solicitation} all'indirizzo scelto attendendo un certo
-lasso di tempo; in caso di risposta l'indirizzo è duplicato e il
-procedimento dovrà essere ripetuto con un nuovo indirizzo (o interrotto
+lasso di tempo; in caso di risposta l'indirizzo è duplicato e il
+procedimento dovrà essere ripetuto con un nuovo indirizzo (o interrotto
richiedendo assistenza).
Una volta ottenuto un indirizzo locale valido diventa possibile per il nodo
-comunicare con la rete locale; sono pertanto previste due modalità di
+comunicare con la rete locale; sono pertanto previste due modalità di
auto-configurazione, descritte nelle seguenti sezioni. In ogni caso
l'indirizzo link-local resta valido.
\subsection{Auto-configurazione stateless}
\label{sec:stateless}
-Questa è la forma più semplice di auto-configurazione, possibile quando
-l'indirizzo globale può essere ricavato dall'indirizzo link-local cambiando
+Questa è la forma più semplice di auto-configurazione, possibile quando
+l'indirizzo globale può essere ricavato dall'indirizzo link-local cambiando
semplicemente il prefisso a quello assegnato dal provider per ottenere un
indirizzo globale.
-La procedura di configurazione è la seguente: all'avvio tutti i nodi IPv6
+La procedura di configurazione è la seguente: all'avvio tutti i nodi IPv6
iniziano si devono aggregare al gruppo di \itindex{multicast}
\textit{multicast} \textit{all-nodes} programmando la propria interfaccia per
ricevere i messaggi dall'indirizzo \textit{multicast} \texttt{FF02::1} (vedi
\itindex{multicast} \textit{multicast} \texttt{FF02::2} usando come sorgente
il proprio indirizzo link-local.
-Il router risponderà con un messaggio ICMP \textit{Router Advertisement} che
-fornisce il prefisso e la validità nel tempo del medesimo, questo tipo di
-messaggio può essere trasmesso anche a intervalli regolari. Il messaggio
+Il router risponderà con un messaggio ICMP \textit{Router Advertisement} che
+fornisce il prefisso e la validità nel tempo del medesimo, questo tipo di
+messaggio può essere trasmesso anche a intervalli regolari. Il messaggio
contiene anche l'informazione che autorizza un nodo a autocostruire
l'indirizzo, nel qual caso, se il prefisso unito all'indirizzo link-local non
supera i 128 bit, la stazione ottiene automaticamente il suo indirizzo
\subsection{Auto-configurazione stateful}
\label{sec:stateful}
-Benché estremamente semplice l'auto-configurazione stateless presenta alcuni
-problemi; il primo è che l'uso degli indirizzi delle schede di rete è
+Benché estremamente semplice l'auto-configurazione stateless presenta alcuni
+problemi; il primo è che l'uso degli indirizzi delle schede di rete è
molto inefficiente; nel caso in cui ci siano esigenze di creare una gerarchia
strutturata su parecchi livelli possono non restare 48~bit per l'indirizzo
-della singola stazione; il secondo problema è di sicurezza, dato che basta
+della singola stazione; il secondo problema è di sicurezza, dato che basta
introdurre in una rete una stazione autoconfigurante per ottenere un accesso
legale.
-Per questi motivi è previsto anche un protocollo stateful basato su un server
+Per questi motivi è previsto anche un protocollo stateful basato su un server
che offra una versione IPv6 del DHCP; un apposito gruppo di \textit{multicast}
-\texttt{FF02::1:0} è stato riservato per questi server; in questo caso il nodo
-interrogherà il server su questo indirizzo di \textit{multicast} con
-l'indirizzo link-local e riceverà un indirizzo unicast globale.
+\texttt{FF02::1:0} è stato riservato per questi server; in questo caso il nodo
+interrogherà il server su questo indirizzo di \textit{multicast} con
+l'indirizzo link-local e riceverà un indirizzo unicast globale.
\section{Il protocollo ICMP}
\label{sec:ICMP_protocol}
-Come già accennato nelle sezioni precedenti, l'\textit{Internet Control
- Message Protocol} è un protocollo di servizio fondamentale per il
+Come già accennato nelle sezioni precedenti, l'\textit{Internet Control
+ Message Protocol} è un protocollo di servizio fondamentale per il
funzionamento del livello di rete. Il protocollo ICMP viene trasportato
direttamente su IP, ma proprio per questa sua caratteristica di protocollo di
-servizio è da considerarsi a tutti gli effetti appartenente al livello di
+servizio è da considerarsi a tutti gli effetti appartenente al livello di
rete.
\subsection{L'intestazione di ICMP}
\label{sec:ICMP_header}
-Il protocollo ICMP è estremamente semplice, ed il suo unico scopo è quello di
-inviare messaggi di controllo; in fig.~\ref{fig:ICMP_header} si è riportata la
+Il protocollo ICMP è estremamente semplice, ed il suo unico scopo è quello di
+inviare messaggi di controllo; in fig.~\ref{fig:ICMP_header} si è riportata la
struttura dell'intestazione di un pacchetto ICMP generico.
\begin{figure}[htb]
\label{fig:ICMP_header}
\end{figure}
-Ciascun pacchetto ICMP è contraddistinto dal valore del primo campo, il tipo,
+Ciascun pacchetto ICMP è contraddistinto dal valore del primo campo, il tipo,
che indica appunto che tipo di messaggio di controllo viene veicolato dal
pacchetto in questione; i valori possibili per questo campo, insieme al
relativo significato, sono riportati in tab.~\ref{tab:ICMP_type}.
irraggiungibile, viene
inviato all'IP sorgente di un
pacchetto quando un router realizza
- che questo non può essere inviato a
+ che questo non può essere inviato a
destinazione.\\
\textit{source-quench} &4& Inviato in caso di congestione della
rete per indicare all'IP sorgente di
utilizzano un valore per questo campo sono quelli di tipo
\textit{destination-unreachable}, \textit{redirect}, \textit{time-exceeded} e
\textit{parameter-problem}. I possibili valori del codice relativi a ciascuno
-di essi sono stati riportati nelle quattro sezioni in cui si è suddivisa
+di essi sono stati riportati nelle quattro sezioni in cui si è suddivisa
tab.~\ref{tab:ICMP_code}, rispettivamente nell'ordine con cui sono appena
elencati i tipi a cui essi fanno riferimento.
\chapter{Introduzione alla programmazione di rete}
\label{cha:network}
-In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
+In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
come prerequisiti per capire la programmazione di rete, non tratteremo quindi
-aspetti specifici ma faremo una breve introduzione al modello più comune usato
+aspetti specifici ma faremo una breve introduzione al modello più comune usato
nella programmazione di rete, per poi passare ad un esame a grandi linee dei
protocolli di rete e di come questi sono organizzati e interagiscono.
In particolare, avendo assunto l'ottica di un'introduzione mirata alla
-programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
+programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
quello che sta alla base di internet, avendo cura di sottolineare i concetti
-più importanti da conoscere per la scrittura dei programmi.
+più importanti da conoscere per la scrittura dei programmi.
\label{sec:net_prog_model}
-La differenza principale fra un'applicazione di rete e un programma normale è
+La differenza principale fra un'applicazione di rete e un programma normale è
che quest'ultima per definizione concerne la comunicazione fra processi
-diversi, che in generale non girano neanche sulla stessa macchina. Questo già
+diversi, che in generale non girano neanche sulla stessa macchina. Questo già
prefigura un cambiamento completo rispetto all'ottica del programma monolitico
all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente
-presuppone un sistema operativo multitasking in grado di eseguire più processi
+presuppone un sistema operativo multitasking in grado di eseguire più processi
contemporaneamente.
In questa prima sezione esamineremo brevemente i principali modelli di
\label{sec:net_cliserv}
L'architettura fondamentale su cui si basa gran parte della programmazione di
-rete sotto Linux (e sotto Unix in generale) è il modello
+rete sotto Linux (e sotto Unix in generale) è il modello
\textit{client-server} caratterizzato dalla presenza di due categorie di
soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
richieste e forniscono le risposte, ed i programmi di utilizzo, detti
\textit{client}.
-In generale un server può (di norma deve) essere in grado di rispondere a più
-di un client, per cui è possibile che molti programmi possano interagire
-contemporaneamente, quello che contraddistingue il modello però è che
-l'architettura dell'interazione è sempre nei termini di molti verso uno, il
+In generale un server può (di norma deve) essere in grado di rispondere a più
+di un client, per cui è possibile che molti programmi possano interagire
+contemporaneamente, quello che contraddistingue il modello però è che
+l'architettura dell'interazione è sempre nei termini di molti verso uno, il
server, che viene ad assumere un ruolo privilegiato.
Seguono questo modello tutti i servizi fondamentali di internet, come le
pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
-modello è utilizzato in generale anche per programmi che, come gli esempi che
+modello è utilizzato in generale anche per programmi che, come gli esempi che
abbiamo usato in cap.~\ref{cha:IPC} a proposito della comunicazione fra
processi nello stesso sistema, non fanno necessariamente uso della rete.
Un \textsl{server concorrente} al momento di trattare la richiesta crea un
processo figlio (o un \itindex{thread} \textit{thread}) incaricato di fornire
i servizi richiesti, per porsi immediatamente in attesa di ulteriori
-richieste. In questo modo, con sistemi multitasking, più richieste possono
+richieste. In questo modo, con sistemi multitasking, più richieste possono
essere soddisfatte contemporaneamente. Una volta che il processo figlio ha
concluso il suo lavoro esso di norma viene terminato, mentre il server
originale resta sempre attivo.
\label{sec:net_peertopeer}
Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
-è quello della preminenza del server rispetto ai client, le architetture
-\textit{peer-to-peer} si basano su un approccio completamente opposto che è
+è quello della preminenza del server rispetto ai client, le architetture
+\textit{peer-to-peer} si basano su un approccio completamente opposto che è
quello di non avere nessun programma che svolga un ruolo preminente.
Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
-ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
+ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
la separazione netta dei compiti che si ritrova nelle architetture
\textit{client-server}.
tramite il demone che gestisce il routing, richiede ed invia informazioni ad
altri nodi.
-In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
-non è detto che la struttura sia totalmente paritetica e ci sono parecchi
+In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
+non è detto che la struttura sia totalmente paritetica e ci sono parecchi
esempi in cui alcuni servizi vengono centralizzati o distribuiti
gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
effettuate su un server centrale.
\subsection{Il modello \textit{three-tier}}
\label{sec:net_three_tier}
-Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
+Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
una estensione del modello \textit{client-server}. Con il crescere della
-quantità dei servizi forniti in rete (in particolare su internet) ed al numero
-di accessi richiesto. Si è così assistito anche ad una notevole crescita di
-complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
+quantità dei servizi forniti in rete (in particolare su internet) ed al numero
+di accessi richiesto. Si è così assistito anche ad una notevole crescita di
+complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
-In particolare sempre più spesso si assiste ad una integrazione di servizi di
+In particolare sempre più spesso si assiste ad una integrazione di servizi di
database con servizi di web, in cui le pagine vengono costruite dinamicamente
sulla base dei dati contenuti nel database. In tutti questi casi il problema
-fondamentale di una architettura \textit{client-server} è che la richiesta di
+fondamentale di una architettura \textit{client-server} è che la richiesta di
un servizio da parte di un gran numero di client si scontra con il collo di
bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
-scalabilità.
+scalabilità.
-Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
-talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
-carico delle richieste su più server identici, mantenendo quindi
+Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
+talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
+carico delle richieste su più server identici, mantenendo quindi
sostanzialmente inalterata l'architettura \textit{client-server} originale.
-Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
+Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
-inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
+inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
esempio per i database che non possono essere replicati e sincronizzati
-facilmente, e che sono molto onerosi, la loro replicazione è costosa e
+facilmente, e che sono molto onerosi, la loro replicazione è costosa e
complessa.
-È a partire da queste problematiche che nasce il modello \textit{three-tier},
+È a partire da queste problematiche che nasce il modello \textit{three-tier},
che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
parte server viene suddivisa in due livelli, introducendo un
\textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
-richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
+richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
che si limita a fornire i dati dinamici che verranno usati dalla logica
implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
client.
-In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
-che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
+In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
+che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
-questo modo si può distribuire il carico ed accedere in maniera efficiente i
+questo modo si può distribuire il carico ed accedere in maniera efficiente i
dati.
Parlando di reti di computer si parla in genere di un insieme molto vasto ed
eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
ottica, alle comunicazioni via satellite o via radio; per rendere possibile la
-comunicazione attraverso un così variegato insieme di mezzi sono stati
-adottati una serie di protocolli, il più famoso dei quali, quello alla base
-del funzionamento di internet, è il protocollo TCP/IP.
+comunicazione attraverso un così variegato insieme di mezzi sono stati
+adottati una serie di protocolli, il più famoso dei quali, quello alla base
+del funzionamento di internet, è il protocollo TCP/IP.
\subsection{Il modello ISO/OSI}
\label{sec:net_iso_osi}
-Una caratteristica comune dei protocolli di rete è il loro essere strutturati
+Una caratteristica comune dei protocolli di rete è il loro essere strutturati
in livelli sovrapposti; in questo modo ogni protocollo di un certo livello
-realizza le sue funzionalità basandosi su un protocollo del livello
-sottostante. Questo modello di funzionamento è stato standardizzato dalla
+realizza le sue funzionalità basandosi su un protocollo del livello
+sottostante. Questo modello di funzionamento è stato standardizzato dalla
\textit{International Standards Organization} (ISO) che ha preparato fin dal
1984 il Modello di Riferimento \textit{Open Systems Interconnection} (OSI),
strutturato in sette livelli, secondo quanto riportato in
\label{tab:net_osilayers}
\end{table}
-Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
-serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
+Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della
+serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un
modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli
- è stata creata la frase \textit{All people seem to need data processing}, in
+ è stata creata la frase \textit{All people seem to need data processing}, in
cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che
usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in
fig.~\ref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda
solo le applicazioni, che viene realizzato in user space, ed un \textit{lower
- layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
+ layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità
fornite dall'hardware.
Il modello ISO/OSI mira ad effettuare una classificazione completamente
-generale di ogni tipo di protocollo di rete; nel frattempo però era stato
-sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
-su cui è basata internet, che è diventato uno standard de facto. Questo
+generale di ogni tipo di protocollo di rete; nel frattempo però era stato
+sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello
+su cui è basata internet, che è diventato uno standard de facto. Questo
modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per
\textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per
il Dipartimento della Difesa Americano.
\label{fig:net_osi_tcpip_comp}
\end{figure}
-La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
-personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
-generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
+La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti
+personali. Come caratteristiche generali il modello ISO/OSI è più teorico e
+generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino
alla separazione concreta dei vari strati del sistema operativo; useremo
-pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
- semplicità ha un costo quando si fa riferimento agli strati più bassi, che
+pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa
+ semplicità ha un costo quando si fa riferimento agli strati più bassi, che
sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte
dei protocolli di trasmissione hardware sono appunto strutturati sui due
livelli di \textit{Data Link} e \textit{Connection}.}
\subsection{Il modello TCP/IP (o DoD)}
\label{sec:net_tcpip_overview}
-Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
-(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
+Così come ISO/OSI anche il modello del TCP/IP è stato strutturato in livelli
+(riassunti in tab.~\ref{tab:net_layers}); un confronto fra i due è riportato
in fig.~\ref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la
-corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
+corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su
come essi vanno ad inserirsi all'interno del sistema rispetto alla divisione
fra user space e kernel space spiegata in
-sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
+sez.~\ref{sec:intro_unix_struct}.\footnote{in realtà è sempre possibile
accedere dallo user space, attraverso una opportuna interfaccia (come
vedremo in sez.~\ref{sec:sock_sa_packet}), ai livelli inferiori del
protocollo.}
\label{tab:net_layers}
\end{table}
-Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
-ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
+Come si può notare come il modello TCP/IP è più semplice del modello ISO/OSI
+ed è strutturato in soli quattro livelli. Il suo nome deriva dai due
principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
-\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
+\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
rete, in genere questi vengono realizzati secondo il modello client-server
(vedi sez.~\ref{sec:net_cliserv}), realizzando una comunicazione secondo un
- protocollo che è specifico di ciascuna applicazione.
+ protocollo che è specifico di ciascuna applicazione.
\item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
terminali su cui girano gli applicativi, regola il flusso delle
- informazioni, può fornire un trasporto affidabile, cioè con recupero degli
+ informazioni, può fornire un trasporto affidabile, cioè con recupero degli
errori o inaffidabile. I protocolli principali di questo livello sono il TCP
e l'UDP.
\item[\textbf{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
rete complessa e interconnessa, a questo stesso livello operano i protocolli
per il reperimento delle informazioni necessarie allo smistamento, per lo
scambio di messaggi di controllo e per il monitoraggio della rete. Il
- protocollo su cui si basa questo livello è IP (sia nella attuale versione,
+ protocollo su cui si basa questo livello è IP (sia nella attuale versione,
IPv4, che nella nuova versione, IPv6).
-\item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
+\item[\textbf{Collegamento}] È responsabile per l'interfacciamento al
dispositivo elettronico che effettua la comunicazione fisica, gestendo
l'invio e la ricezione dei pacchetti da e verso l'hardware.
\end{basedescript}
-La comunicazione fra due stazioni remote avviene secondo le modalità
-illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
+La comunicazione fra due stazioni remote avviene secondo le modalità
+illustrate in fig.~\ref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
dei dati reali e i protocolli usati per lo scambio di informazione su ciascun
-livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
-se in realtà i protocolli di trasmissione usati possono essere molti altri.
+livello. Si è genericamente indicato \textit{ethernet} per il livello 1, anche
+se in realtà i protocolli di trasmissione usati possono essere molti altri.
\begin{figure}[!htb]
\centering \includegraphics[width=13cm]{img/tcp_data_flux}
Per chiarire meglio la struttura della comunicazione attraverso i vari
protocolli mostrata in fig.~\ref{fig:net_tcpip_data_flux}, conviene prendere in
esame i singoli passaggi fatti per passare da un livello al sottostante,
-la procedura si può riassumere nei seguenti passi:
+la procedura si può riassumere nei seguenti passi:
\begin{itemize}
\item Le singole applicazioni comunicano scambiandosi i dati ciascuna secondo
un suo specifico formato. Per applicazioni generiche, come la posta o le
pagine web, viene di solito definito ed implementato quello che viene
chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
- SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
+ SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
solito attraverso un RFC\footnote{l'acronimo RFC sta per \textit{Request For
- Comment} ed è la procedura attraverso la quale vengono proposti gli
+ Comment} ed è la procedura attraverso la quale vengono proposti gli
standard per Internet.}).
\item I dati delle applicazioni vengono inviati al livello di trasporto usando
un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
processo viene svolto direttamente nel kernel, ad esempio dallo stack TCP,
nel caso il protocollo di trasporto usato sia questo.
\item Una volta composto il pacchetto nel formato adatto al protocollo di
- trasporto usato questo sarà passato al successivo livello, quello di rete,
+ trasporto usato questo sarà passato al successivo livello, quello di rete,
che si occupa di inserire le opportune informazioni per poter effettuare
l'instradamento nella rete ed il recapito alla destinazione finale. In
- genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
+ genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
i numeri IP che identificano i computer su internet.
-\item L'ultimo passo è il trasferimento del pacchetto al driver della
+\item L'ultimo passo è il trasferimento del pacchetto al driver della
interfaccia di trasmissione, che si incarica di incapsularlo nel relativo
- protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
+ protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
nel caso di ethernet, in cui i pacchetti vengono inviati sulla linea
attraverso le schede di rete, che in maniera indiretta con protocolli come
PPP o SLIP, che vengono usati come interfaccia per far passare i dati su
\subsection{Criteri generali dell'architettura del TCP/IP}
\label{sec:net_tcpip_design}
-La filosofia architetturale del TCP/IP è semplice: costruire una rete che
+La filosofia architetturale del TCP/IP è semplice: costruire una rete che
possa sopportare il carico in transito, ma permettere ai singoli nodi di
-scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
+scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
errati o non recapitabili.
L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
-di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
-inaffidabile, in quanto non è assicurata né una percentuale di successo né un
+di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
+inaffidabile, in quanto non è assicurata né una percentuale di successo né un
limite sui tempi di consegna dei pacchetti.
-È il livello di trasporto che si deve occupare (qualora necessiti) del
-controllo del flusso dei dati e del recupero degli errori; questo è realizzato
-dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
+È il livello di trasporto che si deve occupare (qualora necessiti) del
+controllo del flusso dei dati e del recupero degli errori; questo è realizzato
+dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
pertanto al livello di trasporto o ai livelli superiori.
Infine le singole stazioni collegate alla rete non fungono soltanto da punti
terminali di comunicazione, ma possono anche assumere il ruolo di
\textit{router} (\textsl{instradatori}), per l'interscambio di pacchetti da
-una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
+una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
in grado di adattarsi ai mutamenti delle interconnessioni.
-La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
+La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
nel formato del livello successivo, fino al livello del collegamento fisico.
In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
-di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
+di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
sorgente. Questo rende facile il progettare il software facendo riferimento
unicamente a quanto necessario ad un singolo livello, con la confidenza che
-questo poi sarà trattato uniformemente da tutti i nodi della rete.
+questo poi sarà trattato uniformemente da tutti i nodi della rete.
\section{Il protocollo TCP/IP}
\label{sec:net_tpcip}
-Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un
+Come accennato in sez.~\ref{sec:net_protocols} il protocollo TCP/IP è un
insieme di protocolli diversi, che operano su 4 livelli diversi. Per gli
-interessi della programmazione di rete però sono importanti principalmente i
+interessi della programmazione di rete però sono importanti principalmente i
due livelli centrali, e soprattutto quello di trasporto.
La principale interfaccia usata nella programmazione di rete, quella dei
-socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
-confronti di quest'ultimo. Questo avviene perché al di sopra del livello di
+socket (vedi sez.~\ref{cha:socket_intro}), è infatti un'interfaccia nei
+confronti di quest'ultimo. Questo avviene perché al di sopra del livello di
trasporto i programmi hanno a che fare solo con dettagli specifici delle
applicazioni, mentre al di sotto vengono curati tutti i dettagli relativi alla
-comunicazione. È pertanto naturale definire una interfaccia di programmazione
-su questo confine, tanto più che è proprio lì (come evidenziato in
+comunicazione. È pertanto naturale definire una interfaccia di programmazione
+su questo confine, tanto più che è proprio lì (come evidenziato in
fig.~\ref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
inserita la divisione fra kernel space e user space.
-In realtà in un sistema Unix è possibile accedere anche agli altri livelli
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli
inferiori (e non solo a quello di trasporto) con opportune interfacce di
programmazione (vedi sez.~\ref{sec:sock_sa_packet}), ma queste vengono usate
solo quando si debbano fare applicazioni di sistema per il controllo della
\subsection{Il quadro generale}
\label{sec:net_tcpip_general}
-Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
-molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
+Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
+molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema
che mostra un panorama sui principali protocolli della famiglia, e delle loro
relazioni reciproche e con alcune dalle principali applicazioni che li usano.
I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
seguenti:
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
-\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
- comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
- cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
+\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
+ comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
+ cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
informazioni di instradamento e controllo per la trasmissione dei pacchetti
sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
quelli specifici di IPv6) vengono trasmessi attraverso di esso.
-\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
- a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
- ampliato 128 bit che consente più gerarchie di indirizzi,
+\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
+ a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
+ ampliato 128 bit che consente più gerarchie di indirizzi,
l'auto-configurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
vuole essere un sostituto.
-\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
+\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
orientato alla connessione che provvede un trasporto affidabile per un
flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
- ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
-\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
+ ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
+\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
- protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
+ protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
la loro destinazione, si perdano, vengano duplicati, o abbiano un
particolare ordine di arrivo.
-\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
+\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
protocollo usato a livello 2 per gestire gli errori e trasportare le
- informazioni di controllo fra stazioni remote e instradatori (cioè fra
+ informazioni di controllo fra stazioni remote e instradatori (cioè fra
\textit{host} e \textit{router}). I messaggi sono normalmente generati dal
- software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
+ software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
-\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
+\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
protocollo di livello 2 usato per il \itindex{multicast}
\textit{multicast} (vedi sez.~\ref{sec:xxx_multicast}). Permette
alle stazioni remote di notificare ai router che supportano questa
comunicazione a quale gruppo esse appartengono. Come ICMP viene
implementato direttamente sopra IP.
-\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
- mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
+\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
+ mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
reti di tipo \itindex{broadcast} \textit{broadcast} come Ethernet, Token
Ring o FDDI che hanno associato un indirizzo fisico (il \textit{MAC
address}) alla interfaccia, ma non serve in connessioni punto-punto.
-\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
+\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
durante l'avvio per assegnare un indirizzo IP ad una macchina.
\item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
- Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
-\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
+ Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
+\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
routing usato per comunicare lo stato fra gateway vicini a livello di
\textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
- systems} i raggruppamenti al livello più alto della rete.}, con
+ systems} i raggruppamenti al livello più alto della rete.}, con
meccanismi che permettono di identificare i vicini, controllarne la
- raggiungibilità e scambiare informazioni sullo stato della rete. Viene
+ raggiungibilità e scambiare informazioni sullo stato della rete. Viene
implementato direttamente sopra IP.
-\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
+\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
routing per router su reti interne, che permette a questi ultimi di
scambiarsi informazioni sullo stato delle connessioni e dei legami che
ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
-\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
+\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
generico di incapsulamento che permette di incapsulare un qualunque altro
protocollo all'interno di IP.
\item[\textsl{AH}] \textit{Authentication Header}. Provvede l'autenticazione
- dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
- e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
+ dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
+ e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP.
\item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
- cifratura insieme all'autenticazione dell'integrità e dell'origine di un
- pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
- protocollo a sé su IPv4.
-\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
+ cifratura insieme all'autenticazione dell'integrità e dell'origine di un
+ pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
+ protocollo a sé su IPv4.
+\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
livello 1 progettato per lo scambio di pacchetti su connessioni punto punto.
Viene usato per configurare i collegamenti, definire i protocolli di rete
- usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
+ usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
varie componenti.
-\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
+\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
1 che permette di trasmettere un pacchetto IP attraverso una linea seriale.
\end{basedescript}
Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
scopi particolari si rifanno direttamente ad IP (ed i suoi correlati ICMP e
-IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
-questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
+IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
+questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
a parte applicazioni particolari si preferisce sempre usare i servizi messi a
disposizione dai due protocolli precedenti. Per questo, motivo a parte alcuni
brevi accenni su IP in questa sezione, ci concentreremo sul livello di
\label{sec:net_ip}
Quando si parla di IP ci si riferisce in genere alla versione attualmente in
-uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
+uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
venne standardizzata nel 1981
dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
Internet Protocol nasce per disaccoppiare le applicazioni della struttura
hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
-dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
-Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
+dei dati indipendente dal sottostante substrato di rete, che può essere
+realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
+Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
all'altro della rete; le caratteristiche essenziali con cui questo viene
realizzato in IPv4 sono due:
\begin{itemize}
\item \textit{Universal addressing} la comunicazione avviene fra due stazioni
- remote identificate univocamente con un indirizzo a 32 bit che può
+ remote identificate univocamente con un indirizzo a 32 bit che può
appartenere ad una sola interfaccia di rete.
\item \textit{Best effort} viene assicurato il massimo impegno nella
- trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
- percentuale di successo né sul tempo di consegna dei pacchetti di dati.
+ trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
+ percentuale di successo né sul tempo di consegna dei pacchetti di dati.
\end{itemize}
Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
-problemi si è perciò definita una nuova versione del protocollo, che (saltando
-un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
+problemi si è perciò definita una nuova versione del protocollo, che (saltando
+un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
IPv4, mantenendone inalterate le funzioni che si sono dimostrate valide,
eliminando quelle inutili e aggiungendone poche altre per mantenere il
-protocollo il più snello e veloce possibile.
+protocollo il più snello e veloce possibile.
I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
grandi linee nei seguenti punti:
\begin{itemize}
-\item l'espansione delle capacità di indirizzamento e instradamento, per
- supportare una gerarchia con più livelli di indirizzamento, un numero di
+\item l'espansione delle capacità di indirizzamento e instradamento, per
+ supportare una gerarchia con più livelli di indirizzamento, un numero di
nodi indirizzabili molto maggiore e una auto-configurazione degli indirizzi.
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
si aggiunge agli usuali \textit{unicast} e \itindex{multicast}
\textit{multicast}.
\item la semplificazione del formato dell'intestazione (\textit{header}) dei
pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
- eliminare la necessità di rielaborazione della stessa da parte dei router e
+ eliminare la necessità di rielaborazione della stessa da parte dei router e
contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi.
\item un supporto per le opzioni migliorato, per garantire una trasmissione
- più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
- delle opzioni, e la flessibilità necessaria per introdurne di nuove in
+ più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
+ delle opzioni, e la flessibilità necessaria per introdurne di nuove in
futuro.
-\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
- permettano di identificare gruppi di dati per i quali si può provvedere un
+\item il supporto per delle capacità di \textsl{qualità di servizio} (QoS) che
+ permettano di identificare gruppi di dati per i quali si può provvedere un
trattamento speciale (in vista dell'uso di internet per applicazioni
multimediali e/o ``real-time'').
\end{itemize}
\subsection{User Datagram Protocol (UDP)}
\label{sec:net_udp}
-UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
+UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
-sostanza esso è una semplice interfaccia al protocollo IP dal livello di
+sostanza esso è una semplice interfaccia al protocollo IP dal livello di
trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto di dati (il
cosiddetto \textit{datagram} che da il nome al protocollo) su un socket, al
-pacchetto viene aggiunto un header molto semplice (per una descrizione più
+pacchetto viene aggiunto un header molto semplice (per una descrizione più
accurata vedi sez.~\ref{sec:udp_protocol}), e poi viene passato al livello
superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione. Dato
-che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
-pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
+che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
+pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
ordine in cui sono stati spediti.
-Pertanto il problema principale che si affronta quando si usa UDP è la
-mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
-destinazione occorrerà provvedere con l'applicazione, all'interno della quale
-si dovrà inserire tutto quanto necessario a gestire la notifica di
+Pertanto il problema principale che si affronta quando si usa UDP è la
+mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
+destinazione occorrerà provvedere con l'applicazione, all'interno della quale
+si dovrà inserire tutto quanto necessario a gestire la notifica di
ricevimento, la ritrasmissione, il timeout.
Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
-stesso ordine in cui sono stati trasmessi, e può anche accadere che i
+stesso ordine in cui sono stati trasmessi, e può anche accadere che i
pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
questo di nuovo deve tenere conto l'applicazione.
-Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
+Un altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
destinazione esso viene passato all'applicazione ricevente in tutta la sua
-lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
+lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
viene anche essa trasmessa all'applicazione all'atto del ricevimento.
-Infine UDP è un protocollo che opera senza connessione
-(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
-relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
-in cui un client può scrivere su uno stesso socket pacchetti destinati a
+Infine UDP è un protocollo che opera senza connessione
+(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
+relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
+in cui un client può scrivere su uno stesso socket pacchetti destinati a
server diversi, o un server ricevere su un socket pacchetti provenienti da
-client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
-quello della radio, in cui si può \textsl{trasmettere} e \textsl{ricevere} da
-più stazioni usando la stessa frequenza.
+client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
+quello della radio, in cui si può \textsl{trasmettere} e \textsl{ricevere} da
+più stazioni usando la stessa frequenza.
-Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
-grande pregio della velocità, che in certi casi è essenziale; inoltre si
-presta bene per le applicazioni in cui la connessione non è necessaria, e
+Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
+grande pregio della velocità, che in certi casi è essenziale; inoltre si
+presta bene per le applicazioni in cui la connessione non è necessaria, e
costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
-pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
+pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
quelle che usano il \itindex{multicast} \textit{multicast}.
\subsection{Transport Control Protocol (TCP)}
\label{sec:net_tcp}
-Il TCP è un protocollo molto complesso, definito
+Il TCP è un protocollo molto complesso, definito
nell'\href{http://www.ietf.org/rfc/rfc0739.txt}{RFC~739} e completamente
diverso da UDP; alla base della sua progettazione infatti non stanno
-semplicità e velocità, ma la ricerca della massima affidabilità possibile
+semplicità e velocità, ma la ricerca della massima affidabilità possibile
nella trasmissione dei dati.
-La prima differenza con UDP è che TCP provvede sempre una connessione diretta
+La prima differenza con UDP è che TCP provvede sempre una connessione diretta
fra un client e un server, attraverso la quale essi possono comunicare; per
-questo il paragone più appropriato per questo protocollo è quello del
+questo il paragone più appropriato per questo protocollo è quello del
collegamento telefonico, in quanto prima viene stabilita una connessione fra
due i due capi della comunicazione su cui poi effettuare quest'ultima.
-Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
+Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
-di tempo crescente, fino a che sarà considerata fallita o caduta la
-connessione (e sarà generato un errore di \textit{timeout}); il periodo di
-tempo dipende dall'implementazione e può variare far i quattro e i dieci
+di tempo crescente, fino a che sarà considerata fallita o caduta la
+connessione (e sarà generato un errore di \textit{timeout}); il periodo di
+tempo dipende dall'implementazione e può variare far i quattro e i dieci
minuti.
-Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
+Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
del tempo di andata e ritorno dei pacchetti fra un client e un server (il
cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
rende in grado di adattarsi alle condizioni della rete per non generare
inutili ritrasmissioni o cadere facilmente in timeout.
-Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
+Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
-segmenti (le unità di dati passate da TCP a IP vengono chiamate
-\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza
+segmenti (le unità di dati passate da TCP a IP vengono chiamate
+\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza
$1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se i
segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
-più volte a causa di ritrasmissioni dovute alla perdita degli
-\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
+più volte a causa di ritrasmissioni dovute alla perdita degli
+\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
scartare i duplicati.
Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
-cioè specifica sempre all'altro capo della trasmissione quanti dati può
+cioè specifica sempre all'altro capo della trasmissione quanti dati può
ricevere tramite una \itindex{advertised~window} \textit{advertised window}
(letteralmente ``\textsl{finestra annunciata}''), che indica lo spazio
-disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
-inviati più dati di quelli che possono essere ricevuti.
+disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
+inviati più dati di quelli che possono essere ricevuti.
Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
socket ed aumentando con la lettura di quest'ultimo da parte
-dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
+dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
-ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
-ricevente non può sostenere.
+ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
+ricevente non può sostenere.
-Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
-dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
+Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
+dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
-del controllo di flusso e della gestione della sequenzialità dei dati viene
+del controllo di flusso e della gestione della sequenzialità dei dati viene
effettuato per entrambe le direzioni di comunicazione.
-% TODO mettere riferimento alla appendice su TCP quando ci sarà
-%% Una descrizione più accurata del protocollo è fornita in appendice
+% TODO mettere riferimento alla appendice su TCP quando ci sarà
+%% Una descrizione più accurata del protocollo è fornita in appendice
%% sez.~\ref{sec:tcp_protocol}.
\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
\label{sec:net_lim_dim}
Un aspetto di cui bisogna tenere conto nella programmazione di rete, e che
-ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
+ritornerà in seguito, quando tratteremo gli aspetti più avanzati, è che ci sono
una serie di limiti a cui la trasmissione dei dati attraverso i vari livelli
-del protocollo deve sottostare; limiti che è opportuno tenere presente perché
+del protocollo deve sottostare; limiti che è opportuno tenere presente perché
in certi casi si possono avere delle conseguenze sul comportamento delle
applicazioni.
Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
-alle eventuali implicazioni che possono avere, è il seguente:
+alle eventuali implicazioni che possono avere, è il seguente:
\begin{itemize}
-\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
- l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
- campo apposito nell'header di IP che è lungo 16 bit (vedi
+\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
+ l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
+ campo apposito nell'header di IP che è lungo 16 bit (vedi
fig.~\ref{fig:IP_ipv4_head}).
-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;
- il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
- dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
- suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte;
+ il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
+ dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
+ suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
un pacchetto usando la \textit{jumbo payload option}.
\item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit}
(\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
- al livello di connessione fisica. Il più comune è quello di ethernet che è
+ al livello di connessione fisica. Il più comune è quello di ethernet che è
pari a 1500 byte, una serie di altri valori possibili sono riportati in
tab.~\ref{tab:net_mtu_values}.
\end{itemize}
\itindbeg{Maximum~Transfer~Unit}
Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
dimensioni eccedono la MTU viene eseguita la cosiddetta
-\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
+\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
- gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
- opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
+ gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
+ opportuna opzione, si veda sez.~\ref{sec:ipv6_protocol}.}) in blocchi più
piccoli che possono essere trasmessi attraverso l'interfaccia.
\begin{table}[!htb]
\label{tab:net_mtu_values}
\end{table}
-La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
- MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
+La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
+ MTU}, che dice qual è la lunghezza massima oltre la quale un pacchetto
inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
-conto che non è affatto detto che la \textit{path MTU} sia la stessa in
-entrambe le direzioni, perché l'instradamento può essere diverso nei due
+conto che non è affatto detto che la \textit{path MTU} sia la stessa in
+entrambe le direzioni, perché l'instradamento può essere diverso nei due
sensi, con diverse tipologie di rete coinvolte.
-Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
+Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
pacchetti che generano loro stessi), al contrario di quanto fanno i router
IPv4. In ogni caso una volta frammentati i pacchetti possono essere
riassemblati solo alla destinazione.
-Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
+Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
pacchetto non deve essere frammentato; un router che riceva un pacchetto le
-cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
+cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
fragmentation needed but DF bit set}. Dato che i router IPv6 non possono
effettuare la frammentazione la ricezione di un pacchetto di dimensione
-eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
+eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
di tipo \textit{packet too big}.
Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
opportune serie di pacchetti (per i dettagli vedere
l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che
-non si hanno più errori.
+non si hanno più errori.
-Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
+Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
opzionale, mentre diventa obbligatorio per IPv6. Per IPv6 infatti, non
-potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
+potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
conoscere da subito il \textit{path MTU}.
Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
capo della connessione la dimensione massima dimensione del segmento di dati
-che può essere ricevuto, così da evitare la frammentazione. Di norma viene
+che può essere ricevuto, così da evitare la frammentazione. Di norma viene
impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
-\const{TCP\_MSS} è 512.
+\const{TCP\_MSS} è 512.
\itindend{Maximum~Transfer~Unit}
\label{cha:other_socket}
Dopo aver trattato in cap.~\ref{cha:TCP_socket} i socket TCP, che
-costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
+costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
questo capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
-\textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
+\textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
\section{I socket UDP}
\label{sec:UDP_socket}
-Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
+Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i
socket UDP: protocolli diffusi come NFS o il DNS usano principalmente questo
tipo di socket. Tratteremo in questa sezione le loro caratteristiche
-principali e le modalità per il loro utilizzo.
+principali e le modalità per il loro utilizzo.
\subsection{Le caratteristiche di un socket UDP}
\label{sec:UDP_characteristics}
-Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che
-non supporta le connessioni e non è affidabile: esso si appoggia direttamente
+Come illustrato in sez.\ref{sec:net_udp} UDP è un protocollo molto semplice che
+non supporta le connessioni e non è affidabile: esso si appoggia direttamente
sopra IP (per i dettagli sul protocollo si veda sez.~\ref{sec:udp_protocol}).
-I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
-effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
-vantaggio del protocollo è la velocità, non è necessario trasmettere le
-informazioni di controllo ed il risultato è una trasmissione di dati più
+I dati vengono inviati in forma di pacchetti, e non ne è assicurata né la
+effettiva ricezione né l'arrivo nell'ordine in cui vengono inviati. Il
+vantaggio del protocollo è la velocità, non è necessario trasmettere le
+informazioni di controllo ed il risultato è una trasmissione di dati più
veloce ed immediata.
Questo significa che a differenza dei socket TCP i socket UDP non supportano
una comunicazione di tipo \textit{stream} in cui si ha a disposizione un
-flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
+flusso continuo di dati che può essere letto un po' alla volta, ma piuttosto
una comunicazione di tipo \textit{datagram}, in cui i dati arrivano in singoli
blocchi che devono essere letti integralmente.
illustrato a suo tempo in tab.~\ref{tab:sock_sock_valid_combinations})
utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
-Questa differenza comporta ovviamente che anche le modalità con cui si usano i
+Questa differenza comporta ovviamente che anche le modalità con cui si usano i
socket UDP sono completamente diverse rispetto ai socket TCP, ed in
particolare non esistendo il concetto di connessione non esiste il meccanismo
-del \itindex{three~way~handshake} \textit{three way handshake} né quello degli
-stati del protocollo. In realtà tutto quello che avviene nella comunicazione
-attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un
+del \itindex{three~way~handshake} \textit{three way handshake} né quello degli
+stati del protocollo. In realtà tutto quello che avviene nella comunicazione
+attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un
server o viceversa, secondo lo schema illustrato in
fig.~\ref{fig:UDP_packet-exchange}.
Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
-per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
+per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
TCP: non essendovi il concetto di connessione le funzioni \func{listen} ed
\func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
-eventuale risposta sarà inviata con la funzione \func{sendto}.
+eventuale risposta sarà inviata con la funzione \func{sendto}.
-Da parte del client invece, una volta creato il socket non sarà necessario
+Da parte del client invece, una volta creato il socket non sarà necessario
connettersi con \func{connect} (anche se, come vedremo in
-sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un
-significato comunque diverso) ma si potrà effettuare direttamente una
-richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
+sez.~\ref{sec:UDP_connect}, è possibile usare questa funzione, con un
+significato comunque diverso) ma si potrà effettuare direttamente una
+richiesta inviando un pacchetto con la funzione \func{sendto} e si potrà
leggere una eventuale risposta con la funzione \func{recvfrom}.
-Anche se UDP è completamente diverso rispetto a TCP resta identica la
-possibilità di gestire più canali di comunicazione fra due macchine
-utilizzando le porte. In questo caso il server dovrà usare comunque la
+Anche se UDP è completamente diverso rispetto a TCP resta identica la
+possibilità di gestire più canali di comunicazione fra due macchine
+utilizzando le porte. In questo caso il server dovrà usare comunque la
funzione \func{bind} per scegliere la porta su cui ricevere i dati, e come nel
-caso dei socket TCP si potrà usare il comando \cmd{netstat} per
+caso dei socket TCP si potrà usare il comando \cmd{netstat} per
verificare quali socket sono in ascolto:
\begin{verbatim}
[piccardi@gont gapil]# netstat -anu
connessione di controllo del server \cmd{named}) ed un server DHCP (sulla
porta 67).
-Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
+Si noti però come in questo caso la colonna che indica lo stato sia vuota. I
socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico
-non si avranno indicazioni delle connessioni attive, proprio perché questo
+non si avranno indicazioni delle connessioni attive, proprio perché questo
concetto non esiste per i socket UDP, il kernel si limita infatti a ricevere i
pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono
destinati, oppure a scartarli inviando un messaggio \textit{ICMP port
Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni
principali usate per la trasmissione di dati attraverso i socket UDP sono
-\func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è
+\func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è
dovuta al fatto che non esistendo con UDP il concetto di connessione, non si
ha neanche a disposizione un \textsl{socket connesso} su cui sia possibile
-usare direttamente \func{read} e \func{write} avendo già stabilito (grazie
+usare direttamente \func{read} e \func{write} avendo già stabilito (grazie
alla chiamata ad \func{accept} che lo associa ad una connessione) quali sono
sorgente e destinazione dei dati.
Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
funzioni, che sono comunque utilizzabili in generale per la trasmissione di
dati attraverso qualunque tipo di socket. Esse hanno la caratteristica di
-prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
+prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
-prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
- prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
+prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
+ prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
\textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
\texttt{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
usato un \texttt{unsigned int}; l'argomento \param{len} era \texttt{int} nei
vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine
l'argomento \param{tolen} era \texttt{int} nei vari BSD4.* nelle \acr{libc4}
- e nelle \acr{libc5}.} è:
+ e nelle \acr{libc5}.} è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
successo e -1 per un errore; nel qual caso \var{errno} viene impostata al
rispettivo codice di errore:
\begin{errlist}
- \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
+ \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
l'operazione richiede che la funzione si blocchi.
\item[\errcode{ECONNRESET}] l'altro capo della comunicazione ha resettato la
connessione.
- \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
+ \item[\errcode{EDESTADDRREQ}] il socket non è di tipo connesso, e non si è
specificato un indirizzo di destinazione.
- \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
+ \item[\errcode{EISCONN}] il socket è già connesso, ma si è specificato un
destinatario.
\item[\errcode{EMSGSIZE}] il tipo di socket richiede l'invio dei dati in un
blocco unico, ma la dimensione del messaggio lo rende impossibile.
- \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
+ \item[\errcode{ENOBUFS}] la coda di uscita dell'interfaccia è già piena (di
norma Linux non usa questo messaggio ma scarta silenziosamente i
pacchetti).
- \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
+ \item[\errcode{ENOTCONN}] il socket non è connesso e non si è specificata
una destinazione.
- \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
+ \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
il tipo di socket usato.
- \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
- riceverà anche un segnale di \const{SIGPIPE}, a meno di non aver impostato
+ \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
+ riceverà anche un segnale di \const{SIGPIPE}, a meno di non aver impostato
\const{MSG\_NOSIGNAL} in \param{flags}.
\end{errlist}
ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
- \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
+ \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
ai protocolli utilizzati.}
\end{functions}
specificano il socket \param{sockfd} a cui si fa riferimento, il buffer
\param{buf} che contiene i dati da inviare e la relativa lunghezza
\param{len}. Come per \func{write} la funzione ritorna il numero di byte
-inviati; nel caso di UDP però questo deve sempre corrispondere alla dimensione
+inviati; nel caso di UDP però questo deve sempre corrispondere alla dimensione
totale specificata da \param{len} in quanto i dati vengono sempre inviati in
forma di pacchetto e non possono essere spezzati in invii successivi. Qualora
non ci sia spazio nel buffer di uscita la funzione si blocca (a meno di non
-avere aperto il socket in modalità non bloccante), se invece non è possibile
-inviare il messaggio all'interno di un unico pacchetto (ad esempio perché
+avere aperto il socket in modalità non bloccante), se invece non è possibile
+inviare il messaggio all'interno di un unico pacchetto (ad esempio perché
eccede le dimensioni massime del protocollo sottostante utilizzato) essa
fallisce con l'errore di \errcode{EMSGSIZE}.
destinazione del messaggio da inviare, e indicano rispettivamente la struttura
contenente l'indirizzo di quest'ultima e la sua dimensione; questi argomenti
vanno specificati stessa forma in cui li si sarebbero usati con
-\func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura
+\func{connect}. Nel nostro caso \param{to} dovrà puntare alla struttura
contenente l'indirizzo IP e la porta di destinazione verso cui si vogliono
-inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando
+inviare i dati (questo è indifferente rispetto all'uso di TCP o UDP, usando
socket diversi si sarebbero dovute utilizzare le rispettive strutture degli
indirizzi).
-Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
-TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
-caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
+Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
+TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
+caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono
essi dovranno essere inizializzati rispettivamente a \const{NULL} e 0;
normalmente quando si opera su un socket connesso essi vengono ignorati, ma
-qualora si sia specificato un indirizzo è possibile ricevere un errore di
+qualora si sia specificato un indirizzo è possibile ricevere un errore di
\errcode{EISCONN}.
-Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
-come maschera binaria che permette di impostare una serie di modalità di
+Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
+come maschera binaria che permette di impostare una serie di modalità di
funzionamento della comunicazione attraverso il socket (come
\const{MSG\_NOSIGNAL} che impedisce l'invio del segnale \const{SIGPIPE} quando
-si è già chiuso il capo locale della connessione). Torneremo con maggiori
+si è già chiuso il capo locale della connessione). Torneremo con maggiori
dettagli sul significato di questo argomento in sez.~\ref{sec:net_sendmsg},
-dove tratteremo le funzioni avanzate dei socket, per il momento ci si può
+dove tratteremo le funzioni avanzate dei socket, per il momento ci si può
limitare ad usare sempre un valore nullo.
-La seconda funzione utilizzata nella comunicazione fra socket UDP è
+La seconda funzione utilizzata nella comunicazione fra socket UDP è
\funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
-suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
+suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
\textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le
\acr{libc5} usano un \texttt{int} come valore di ritorno; per gli argomenti
\param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
- infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le
- \acr{libc4} e le \acr{libc5}.} è:
+ infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le
+ \acr{libc4} e le \acr{libc5}.} è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
Riceve un messaggio ad un socket.
\bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
- successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
+ successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
valore:
\begin{errlist}
- \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
- l'operazione richiede che la funzione si blocchi, oppure si è impostato un
- timeout in ricezione e questo è scaduto.
+ \item[\errcode{EAGAIN}] il socket è in modalità non bloccante, ma
+ l'operazione richiede che la funzione si blocchi, oppure si è impostato un
+ timeout in ricezione e questo è scaduto.
\item[\errcode{ECONNREFUSED}] l'altro capo della comunicazione ha rifiutato
- la connessione (in genere perché il relativo servizio non è disponibile).
- \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
+ la connessione (in genere perché il relativo servizio non è disponibile).
+ \item[\errcode{ENOTCONN}] il socket è di tipo connesso, ma non si è eseguita
la connessione.
\end{errlist}
ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
- \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
+ \errval{ENOMEM}, \errval{ENOTSOCK} più gli eventuali altri errori relativi
ai protocolli utilizzati.}
\end{functions}
o di tipo \textit{stream}) i byte in eccesso che non sono stati letti possono
rispettivamente andare persi o restare disponibili per una lettura successiva.
Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto
-il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
+il socket in modalità non bloccante, nel qual caso si avrà il solito errore di
\errcode{EAGAIN}. Qualora \param{len} ecceda la dimensione del pacchetto la
-funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
+funzione legge comunque i dati disponibili, ed il suo valore di ritorno è
comunque il numero di byte letti.
I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere
-l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
+l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere
opportunamente inizializzati; il primo deve contenere il puntatore alla
-struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
+struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il
puntatore alla variabile con la dimensione di detta struttura. Si tenga
presente che mentre il contenuto della struttura \ctyp{sockaddr} cui punta
-\param{from} può essere qualunque, la variabile puntata da \param{fromlen}
+\param{from} può essere qualunque, la variabile puntata da \param{fromlen}
deve essere opportunamente inizializzata a \code{sizeof(sockaddr)},
assicurandosi che la dimensione sia sufficiente a contenere tutti i dati
-dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
+dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
serve ad indicare la struttura corrispondente allo specifico tipo di
indirizzo richiesto, il valore di \param{fromlen} pone un limite alla
- quantità di dati che verranno scritti sulla struttura puntata da
- \param{from} e se è insufficiente l'indirizzo risulterà corrotto.} Al
+ quantità di dati che verranno scritti sulla struttura puntata da
+ \param{from} e se è insufficiente l'indirizzo risulterà corrotto.} Al
ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
-lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
-\itindex{value~result~argument} \textit{value result argument}). Se non si è
+lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
+\itindex{value~result~argument} \textit{value result argument}). Se non si è
interessati a questa informazione, entrambi gli argomenti devono essere
inizializzati al valore \const{NULL}.
Una differenza fondamentale del comportamento di queste funzioni rispetto alle
-usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
-questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
-vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
-specificando un valore nullo per \param{len}. Allo stesso modo è possibile
+usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
+questo caso è perfettamente legale inviare con \func{sendto} un pacchetto
+vuoto (che nel caso conterrà solo le intestazioni di IP e di UDP),
+specificando un valore nullo per \param{len}. Allo stesso modo è possibile
ricevere con \func{recvfrom} un valore di ritorno di 0 byte, senza che questo
possa configurarsi come una chiusura della connessione\footnote{dato che la
connessione non esiste, non ha senso parlare di chiusura della connessione,
- questo significa anche che con i socket UDP non è necessario usare
+ questo significa anche che con i socket UDP non è necessario usare
\func{close} o \func{shutdown} per terminare la comunicazione.} o come una
cessazione delle comunicazioni.
Vediamo allora come implementare un primo client elementare con dei socket
UDP. Ricalcando quanto fatto nel caso dei socket TCP prenderemo come primo
esempio l'uso del servizio \textit{daytime}, utilizzando questa volta UDP. Il
-servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
+servizio è definito nell'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~867},
che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
-UDP al server (di contenuto non specificato), il quale risponderà a inviando a
+UDP al server (di contenuto non specificato), il quale risponderà a inviando a
sua volta un pacchetto UDP contenente la data.
\begin{figure}[!htb]
\label{fig:UDP_daytime_client}
\end{figure}
-In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
+In fig.~\ref{fig:UDP_daytime_client} è riportato la sezione principale del
codice del nostro client, il sorgente completo si trova nel file
\file{UDP\_daytime.c} distribuito con gli esempi allegati alla guida; al
-solito si è tralasciato di riportare in figura la sezione relativa alla
+solito si è tralasciato di riportare in figura la sezione relativa alla
gestione delle opzioni a riga di comando (nel caso praticamente assenti).
Il programma inizia (\texttt{\small 9--12}) con la creazione del socket, al
valore \const{SOCK\_DGRAM}, pur mantenendosi nella stessa famiglia data da
\const{AF\_INET}.
-Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
+Il passo successivo (\texttt{\small 13--21}) è l'inizializzazione della
struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
Si noti come questa sezione sia identica a quella del client TCP di
fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
-di UDP al posto di TCP è stata effettuata quando si è creato il socket.
+di UDP al posto di TCP è stata effettuata quando si è creato il socket.
Una volta completate le inizializzazioni inizia il corpo principale del
-programma, il primo passo è inviare, come richiesto dal protocollo, un
+programma, il primo passo è inviare, come richiesto dal protocollo, un
pacchetto al server. Questo lo si fa (\texttt{\small 16}) inviando un
pacchetto vuoto (si ricordi quanto detto in
sez.~\ref{sec:UDP_sendto_recvfrom}) con \func{sendto}, avendo cura di passare
un valore nullo per il puntatore al buffer e la lunghezza del messaggio. In
-realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
-server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
+realtà il protocollo non richiede che il pacchetto sia vuoto, ma dato che il
+server comunque ne ignorerà il contenuto, è inutile inviare dei dati.
Verificato (\texttt{\small 24--27}) che non ci siano stati errori nell'invio
si provvede (\texttt{\small 28}) ad invocare \func{recvfrom} per ricevere la
risposta del server. Si controlla poi (\texttt{\small 29--32}) che non vi
siano stati errori in ricezione (uscendo con un messaggio in caso contrario);
-se è tutto a posto la variabile \var{nread} conterrà la dimensione del
-messaggio di risposta inviato dal server che è stato memorizzato su
-\var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
-provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
+se è tutto a posto la variabile \var{nread} conterrà la dimensione del
+messaggio di risposta inviato dal server che è stato memorizzato su
+\var{buffer}, se (\texttt{\small 34}) pertanto il valore è positivo si
+provvederà (\texttt{\small 35}) a terminare la stringa contenuta nel buffer di
lettura\footnote{si ricordi che, come illustrato in
sez.~\ref{sec:TCP_daytime_client}, il server invia in risposta una stringa
contenente la data, terminata dai due caratteri CR e LF, che pertanto prima
questo caso (\texttt{\small 36--38}) l'esito dell'operazione, ed uscendo con
un messaggio in caso di errore.
-Se pertanto si è avuto cura di attivare il server del servizio
-\textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
+Se pertanto si è avuto cura di attivare il server del servizio
+\textit{daytime}\footnote{di norma questo è un servizio standard fornito dal
\textsl{superdemone} \cmd{inetd}, per cui basta abilitarlo nel file di
configurazione di quest'ultimo, avendo cura di predisporre il servizio su
UDP.} potremo verificare il funzionamento del nostro client interrogando
23:41:21.645710 localhost.daytime > localhost.32780: udp 26 (DF)
\end{verbatim}
-Una differenza fondamentale del nostro client è che in questo caso, non
-disponendo di una connessione, è per lui impossibile riconoscere errori di
+Una differenza fondamentale del nostro client è che in questo caso, non
+disponendo di una connessione, è per lui impossibile riconoscere errori di
invio relativi alla rete. La funzione \func{sendto} infatti riporta solo
errori locali, i dati vengono comunque scritti e la funzione ritorna senza
-errori anche se il server non è raggiungibile o non esiste un server in
+errori anche se il server non è raggiungibile o non esiste un server in
ascolto sull'indirizzo di destinazione. Questo comporta ad esempio che se si
-usa il nostro programma interrogando un server inesistente questo resterà
+usa il nostro programma interrogando un server inesistente questo resterà
perennemente bloccato nella chiamata a \func{recvfrom}, fin quando non lo
-interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
+interromperemo. Vedremo in sez.~\ref{sec:UDP_connect} come si può porre rimedio
a questa problematica.
Nella sezione precedente abbiamo visto come scrivere un client elementare per
servizio \textit{daytime}, vediamo in questa come deve essere scritto un
-server. Si ricordi che il compito di quest'ultimo è quello di ricevere un
+server. Si ricordi che il compito di quest'ultimo è quello di ricevere un
pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
stringa con la data corrente.
\label{fig:UDP_daytime_server}
\end{figure}
-In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
+In fig.~\ref{fig:UDP_daytime_server} è riportato la sezione principale del
codice del nostro client, il sorgente completo si trova nel file
\file{UDP\_daytimed.c} distribuito con gli esempi allegati alla guida; anche
-in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
-riga di comando (la sola presente è \texttt{-v} che permette di stampare a
+in questo caso si è omessa la sezione relativa alla gestione delle opzioni a
+riga di comando (la sola presente è \texttt{-v} che permette di stampare a
video l'indirizzo associato ad ogni richiesta).
-Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
+Anche in questo caso la prima parte del server (\texttt{\small 9--23}) è
sostanzialmente identica a quella dell'analogo server per TCP illustrato in
fig.~\ref{fig:TCP_daytime_cunc_server_code}; si inizia (\texttt{\small 10})
con il creare il socket, uscendo con un messaggio in caso di errore
(\texttt{\small 10--13}), e di nuovo la sola differenza con il caso precedente
-è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
-si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
+è il diverso tipo di socket utilizzato. Dopo di che (\texttt{\small 14--18})
+si inizializza la struttura degli indirizzi che poi (\texttt{\small 20}) verrà
usata da \func{bind}; si cancella (\texttt{\small 15}) preventivamente il
contenuto, si imposta (\texttt{\small 16}) la famiglia dell'indirizzo, la
porta (\texttt{\small 17}) e l'indirizzo (\texttt{\small 18}) su cui si
riceveranno i pacchetti. Si noti come in quest'ultimo sia l'indirizzo
generico \const{INADDR\_ANY}; questo significa (si ricordi quanto illustrato
-in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
+in sez.~\ref{sec:TCP_func_bind}) che il server accetterà pacchetti su uno
qualunque degli indirizzi presenti sulle interfacce di rete della macchina.
-Completata l'inizializzazione tutto quello che resta da fare è eseguire
+Completata l'inizializzazione tutto quello che resta da fare è eseguire
(\texttt{\small 20--23}) la chiamata a \func{bind}, controllando la presenza
di eventuali errori, ed uscendo con un avviso qualora questo fosse il caso.
-Nel caso di socket UDP questo è tutto quello che serve per consentire al
-server di ricevere i pacchetti a lui indirizzati, e non è più necessario
+Nel caso di socket UDP questo è tutto quello che serve per consentire al
+server di ricevere i pacchetti a lui indirizzati, e non è più necessario
chiamare successivamente \func{listen}. In questo caso infatti non esiste il
concetto di connessione, e quindi non deve essere predisposta una coda delle
connessioni entranti. Nel caso di UDP i pacchetti arrivano al kernel con un
certo indirizzo ed una certa porta di destinazione, il kernel controlla se
-corrispondono ad un socket che è stato \textsl{legato} ad essi con
-\func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
-socket, così che il programma possa leggerlo, altrimenti risponderà alla
+corrispondono ad un socket che è stato \textsl{legato} ad essi con
+\func{bind}, qualora questo sia il caso scriverà il contenuto all'interno del
+socket, così che il programma possa leggerlo, altrimenti risponderà alla
macchina che ha inviato il pacchetto con un messaggio ICMP di tipo
\textit{port unreachable}.
Una volta completata la fase di inizializzazione inizia il corpo principale
(\texttt{\small 24--44}) del server, mantenuto all'interno di un ciclo
infinito in cui si trattano le richieste. Il ciclo inizia (\texttt{\small 26})
-con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
-inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
+con una chiamata a \func{recvfrom}, che si bloccherà in attesa di pacchetti
+inviati dai client. Lo scopo della funzione è quello di ritornare tutte le
volte che un pacchetto viene inviato al server, in modo da poter ricavare da
esso l'indirizzo del client a cui inviare la risposta in \var{addr}. Per
questo motivo in questo caso (al contrario di quanto fatto in
-fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
+fig.~\ref{fig:UDP_daytime_client}) si è avuto cura di passare gli argomenti
\var{addr} e \var{len} alla funzione. Dopo aver controllato (\texttt{\small
27--30}) la presenza di eventuali errori (uscendo con un messaggio di errore
-qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
+qualora ve ne siano) si verifica (\texttt{\small 31}) se è stata attivata
l'opzione \texttt{-v} (che imposta la variabile \var{verbose}) stampando nel
-caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
-richiesta (questa sezione è identica a quella del server TCP illustrato in
+caso (\texttt{\small 32--35}) l'indirizzo da cui si è appena ricevuto una
+richiesta (questa sezione è identica a quella del server TCP illustrato in
fig.~\ref{fig:TCP_daytime_cunc_server_code}).
Una volta ricevuta la richiesta resta solo da ottenere il tempo corrente
(\texttt{\small 36}) e costruire (\texttt{\small 37}) la stringa di risposta,
-che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
+che poi verrà inviata (\texttt{\small 38}) al client usando \func{sendto},
avendo al solito cura di controllare (\texttt{\small 40--42}) lo stato di
uscita della funzione e trattando opportunamente la condizione di errore.
-Si noti come per le peculiarità del protocollo si sia utilizzato un server
+Si noti come per le peculiarità del protocollo si sia utilizzato un server
iterativo, che processa le richieste una alla volta via via che gli arrivano.
-Questa è una caratteristica comune dei server UDP, conseguenza diretta del
-fatto che non esiste il concetto di connessione, per cui non c'è la necessità
-di trattare separatamente le singole connessioni. Questo significa anche che è
-il kernel a gestire la possibilità di richieste multiple in contemporanea;
-quello che succede è semplicemente che il kernel accumula in un buffer in
+Questa è una caratteristica comune dei server UDP, conseguenza diretta del
+fatto che non esiste il concetto di connessione, per cui non c'è la necessità
+di trattare separatamente le singole connessioni. Questo significa anche che è
+il kernel a gestire la possibilità di richieste multiple in contemporanea;
+quello che succede è semplicemente che il kernel accumula in un buffer in
ingresso i pacchetti UDP che arrivano e li restituisce al processo uno alla
-volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
+volta per ciascuna chiamata di \func{recvfrom}; nel nostro caso sarà poi
compito del server distribuire le risposte sulla base dell'indirizzo da cui
provengono le richieste.
\label{sec:UDP_problems}
L'esempio del servizio \textit{daytime} illustrato nelle precedenti sezioni
-è in realtà piuttosto particolare, e non evidenzia quali possono essere i
-problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
+è in realtà piuttosto particolare, e non evidenzia quali possono essere i
+problemi collegati alla mancanza di affidabilità e all'assenza del concetto di
connessione che sono tipiche dei socket UDP. In tal caso infatti il protocollo
-è estremamente semplice, dato che la comunicazione consiste sempre in una
+è estremamente semplice, dato che la comunicazione consiste sempre in una
richiesta seguita da una risposta, per uno scambio di dati effettuabile con un
-singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
+singolo pacchetto, per cui tutti gli eventuali problemi sarebbero assai più
complessi da rilevare.
-Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
-la risposta del server si perdono, il client resterà permanentemente bloccato
+Anche qui però possiamo notare che se il pacchetto di richiesta del client, o
+la risposta del server si perdono, il client resterà permanentemente bloccato
nella chiamata a \func{recvfrom}. Per evidenziare meglio quali problemi si
-possono avere proviamo allora con un servizio leggermente più complesso come
+possono avere proviamo allora con un servizio leggermente più complesso come
\textit{echo}.
\begin{figure}[!htb]
\label{fig:UDP_echo_client}
\end{figure}
-In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
+In fig.~\ref{fig:UDP_echo_client} è riportato un estratto del corpo principale
del nostro client elementare per il servizio \textit{echo} (al solito il
-codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
+codice completo è con i sorgenti allegati). Le uniche differenze con l'analogo
client visto in fig.~\ref{fig:TCP_echo_client_1} sono che al solito si crea
-(\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
+(\texttt{\small 14}) un socket di tipo \const{SOCK\_DGRAM}, e che non è
presente nessuna chiamata a \func{connect}. Per il resto il funzionamento del
-programma è identico, e tutto il lavoro viene effettuato attraverso la
+programma è identico, e tutto il lavoro viene effettuato attraverso la
chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
-però prende un argomento in più, che è l'indirizzo del socket.
+però prende un argomento in più, che è l'indirizzo del socket.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:UDP_echo_client_echo}
\end{figure}
-Ovviamente in questo caso il funzionamento della funzione, il cui codice è
-riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
+Ovviamente in questo caso il funzionamento della funzione, il cui codice è
+riportato in fig.~\ref{fig:UDP_echo_client_echo}, è completamente diverso
rispetto alla analoga del server TCP, e dato che non esiste una connessione
-questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
+questa necessita anche di un terzo argomento, che è l'indirizzo del server cui
inviare i pacchetti.
-Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
-più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
+Data l'assenza di una connessione come nel caso di TCP il meccanismo è molto
+più semplice da gestire. Al solito si esegue un ciclo infinito (\texttt{\small
6--30}) che parte dalla lettura (\texttt{\small 7}) sul buffer di invio
-\var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
-(\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
+\var{sendbuff} di una stringa dallo standard input, se la stringa è vuota
+(\texttt{\small 7--9}), indicando che l'input è terminato, si ritorna
immediatamente causando anche la susseguente terminazione del programma.
Altrimenti si procede (\texttt{\small 10--11}) all'invio della stringa al
destinatario invocando \func{sendto}, utilizzando, oltre alla stringa appena
letta, gli argomenti passati nella chiamata a \func{ClientEcho}, ed in
-particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
-(\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
+particolare l'indirizzo del server che si è posto in \var{serv\_addr}; qualora
+(\texttt{\small 12}) si riscontrasse un errore si provvederà al solito
(\texttt{\small 13--14}) ad uscire con un messaggio di errore.
-Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
+Il passo immediatamente seguente (\texttt{\small 17}) l'invio è quello di
leggere l'eventuale risposta del server con \func{recvfrom}; si noti come in
questo caso si sia scelto di ignorare l'indirizzo dell'eventuale pacchetto di
risposta, controllando (\texttt{\small 18--21}) soltanto la presenza di un
nullo, dato che, nel caso di socket UDP, questo non significa la terminazione
della comunicazione.
-L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
+L'ultimo passo (\texttt{\small 17}) è quello di terminare opportunamente la
stringa di risposta nel relativo buffer per poi provvedere alla sua stampa
sullo standard output, eseguendo il solito controllo (ed eventuale uscita con
adeguato messaggio informativo) in caso di errore.
-In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
-problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
+In genere fintanto che si esegue il nostro client in locale non sorgerà nessun
+problema, se però si proverà ad eseguirlo attraverso un collegamento remoto
(nel caso dell'esempio seguente su una VPN, attraverso una ADSL abbastanza
-congestionata) e in modalità non interattiva, la probabilità di perdere
+congestionata) e in modalità non interattiva, la probabilità di perdere
qualche pacchetto aumenta, ed infatti, eseguendo il comando come:
\begin{verbatim}
[piccardi@gont sources]$ cat UDP_echo.c | ./echo 192.168.1.120
* Include needed headers
\end{verbatim}%$
-si otterrà che, dopo aver correttamente stampato alcune righe, il programma si
-blocca completamente senza stampare più niente. Se al contempo si fosse tenuto
+si otterrà che, dopo aver correttamente stampato alcune righe, il programma si
+blocca completamente senza stampare più niente. Se al contempo si fosse tenuto
sotto controllo il traffico UDP diretto o proveniente dal servizio
\textit{echo} con \cmd{tcpdump} si sarebbe ottenuto:
\begin{verbatim}
18:48:17.965408 gont.earthsea.ea.32788 > 192.168.1.120.echo: udp 4 (DF)
\end{verbatim}
che come si vede il traffico fra client e server si interrompe dopo l'invio di
-un pacchetto UDP per il quale non si è ricevuto risposta.
-
-Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
-una richiesta non arriva a destinazione, il nostro programma si bloccherà
-nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
-in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
-pacchetti, il risultato è diverso, se si lancia al solito il programma e si
-prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
-se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
+un pacchetto UDP per il quale non si è ricevuto risposta.
+
+Il problema è che in tutti i casi in cui un pacchetto di risposta si perde, o
+una richiesta non arriva a destinazione, il nostro programma si bloccherà
+nell'esecuzione di \func{recvfrom}. Lo stesso avviene anche se il server non è
+in ascolto, in questo caso però, almeno dal punto di vista dello scambio di
+pacchetti, il risultato è diverso, se si lancia al solito il programma e si
+prova a scrivere qualcosa si avrà ugualmente un blocco su \func{recvfrom} ma
+se si osserva il traffico con \cmd{tcpdump} si vedrà qualcosa del tipo:
\begin{verbatim}
[root@gont gapil]# tcpdump \( dst 192.168.0.2 and src 192.168.1.120 \) \
or \( src 192.168.0.2 and dst 192.168.1.120 \)
00:43:27.990560 192.168.1.120 > gont.earthsea.ea: icmp: 192.168.1.120 udp port
echo unreachable [tos 0xc0]
\end{verbatim}
-cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
+cioè in questo caso si avrà in risposta un pacchetto ICMP di destinazione
irraggiungibile che ci segnala che la porta in questione non risponde.
-Ci si può chiedere allora perché, benché la situazione di errore sia
-rilevabile, questa non venga segnalata. Il luogo più naturale in cui
-riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
-di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
-questo punto però è impossibile, dato che l'interfaccia di programmazione
+Ci si può chiedere allora perché, benché la situazione di errore sia
+rilevabile, questa non venga segnalata. Il luogo più naturale in cui
+riportarla sarebbe la chiamata di \func{sendto}, in quanto è a causa dell'uso
+di un indirizzo sbagliato che il pacchetto non può essere inviato; farlo in
+questo punto però è impossibile, dato che l'interfaccia di programmazione
richiede che la funzione ritorni non appena il kernel invia il
-pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
- una situazione cioè in cui la condizione di errore viene rilevata in maniera
- asincrona rispetto all'operazione che l'ha causata, una eventualità
+pacchetto,\footnote{questo è il classico caso di \textsl{errore asincrono},
+ una situazione cioè in cui la condizione di errore viene rilevata in maniera
+ asincrona rispetto all'operazione che l'ha causata, una eventualità
piuttosto comune quando si ha a che fare con la rete, tutti i pacchetti ICMP
- che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
+ che segnalano errori rientrano in questa tipologia.} e non può bloccarsi in
una attesa di una risposta che potrebbe essere molto lunga (si noti infatti
-che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
+che il pacchetto ICMP arriva qualche decimo di secondo più tardi) o non
esserci affatto.
-Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
-comunque bloccata in attesa di una risposta che nel caso non arriverà mai. La
-ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
+Si potrebbe allora pensare di riportare l'errore nella \func{recvfrom} che è
+comunque bloccata in attesa di una risposta che nel caso non arriverà mai. La
+ragione per cui non viene fatto è piuttosto sottile e viene spiegata da
Stevens in \cite{UNP2} con il seguente esempio: si consideri un client che
invia tre pacchetti a tre diverse macchine, due dei quali vengono regolarmente
ricevuti, mentre al terzo, non essendo presente un server sulla relativa
macchina, viene risposto con un messaggio ICMP come il precedente. Detto
-messaggio conterrà anche le informazioni relative ad indirizzo e porta del
-pacchetto che ha fallito, però tutto quello che il kernel può restituire al
-programma è un codice di errore in \var{errno}, con il quale è impossibile di
-distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
+messaggio conterrà anche le informazioni relative ad indirizzo e porta del
+pacchetto che ha fallito, però tutto quello che il kernel può restituire al
+programma è un codice di errore in \var{errno}, con il quale è impossibile di
+distinguere per quale dei pacchetti inviati si è avuto l'errore; per questo è
stata fatta la scelta di non riportare un errore su un socket UDP, a meno che,
come vedremo in sez.~\ref{sec:UDP_connect}, questo non sia connesso.
\label{sec:UDP_connect}
Come illustrato in sez.~\ref{sec:UDP_characteristics} essendo i socket UDP
-privi di connessione non è necessario per i client usare \func{connect} prima
-di iniziare una comunicazione con un server. Ciò non di meno abbiamo accennato
+privi di connessione non è necessario per i client usare \func{connect} prima
+di iniziare una comunicazione con un server. Ciò non di meno abbiamo accennato
come questa possa essere utilizzata per gestire la presenza di errori
asincroni.
-Quando si chiama \func{connect} su di un socket UDP tutto quello che succede è
+Quando si chiama \func{connect} su di un socket UDP tutto quello che succede è
che l'indirizzo passato alla funzione viene registrato come indirizzo di
destinazione del socket. A differenza di quanto avviene con TCP non viene
-scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
-qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
-più necessario usare l'argomento \param{to} di \func{sendto} per specificare
+scambiato nessun pacchetto, tutto quello che succede è che da quel momento in
+qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
+più necessario usare l'argomento \param{to} di \func{sendto} per specificare
la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
-le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
+le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
anche continuare ad usare la funzione \func{sendto}, ma in tal caso
l'argomento \param{to} deve essere inizializzato a \const{NULL}, e
\param{tolen} deve essere inizializzato a zero, pena un errore.}
-Una volta che il socket è connesso cambia però anche il comportamento in
+Una volta che il socket è connesso cambia però anche il comportamento in
ricezione; prima infatti il kernel avrebbe restituito al socket qualunque
pacchetto ricevuto con un indirizzo di destinazione corrispondente a quello
del socket, senza nessun controllo sulla sorgente; una volta che il socket
viene connesso saranno riportati su di esso solo i pacchetti con un indirizzo
-sorgente corrispondente a quello a cui ci si è connessi.
+sorgente corrispondente a quello a cui ci si è connessi.
-Infine quando si usa un socket connesso, venendo meno l'ambiguità segnalata
+Infine quando si usa un socket connesso, venendo meno l'ambiguità segnalata
alla fine di sez.~\ref{sec:UDP_problems}, tutti gli eventuali errori asincroni
vengono riportati alle funzioni che operano su di esso; pertanto potremo
riscrivere il nostro client per il servizio \textit{echo} con le modifiche
\label{fig:UDP_echo_conn_cli}
\end{figure}
-Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
+Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
-chiamata alla funzione di gestione del protocollo, che a sua volta è stata
+chiamata alla funzione di gestione del protocollo, che a sua volta è stata
modificata eliminando l'indirizzo passato come argomento e sostituendo le
chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
\func{write} come illustrato dal nuovo codice riportato in
\label{fig:UDP_echo_conn_echo_client}
\end{figure}
-Utilizzando questa nuova versione del client si può verificare che quando ci
-si rivolge verso un indirizzo inesistente o su cui non è in ascolto un server
-si è in grado rilevare l'errore, se infatti eseguiamo il nuovo programma
+Utilizzando questa nuova versione del client si può verificare che quando ci
+si rivolge verso un indirizzo inesistente o su cui non è in ascolto un server
+si è in grado rilevare l'errore, se infatti eseguiamo il nuovo programma
otterremo un qualcosa del tipo:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.1
\end{verbatim}%$
Ma si noti che a differenza di quanto avveniva con il client TCP qui l'errore
-viene rilevato soltanto dopo che si è tentato di inviare qualcosa, ed in
-corrispondenza al tentativo di lettura della risposta. Questo avviene perché
+viene rilevato soltanto dopo che si è tentato di inviare qualcosa, ed in
+corrispondenza al tentativo di lettura della risposta. Questo avviene perché
con UDP non esiste una connessione, e fintanto che non si invia un pacchetto
-non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
+non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
ricezione del pacchetto ICMP \textit{destination unreachable} emesso dalla
-macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
-il kernel potrà riportare detto errore in user space in maniera non ambigua,
-ed esso apparirà alla successiva lettura sul socket.
+macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
+il kernel potrà riportare detto errore in user space in maniera non ambigua,
+ed esso apparirà alla successiva lettura sul socket.
Si tenga presente infine che l'uso dei socket connessi non risolve l'altro
-problema del client, e cioè il fatto che in caso di perdita di un pacchetto
-questo resterà bloccato permanentemente in attesa di una risposta. Per
+problema del client, e cioè il fatto che in caso di perdita di un pacchetto
+questo resterà bloccato permanentemente in attesa di una risposta. Per
risolvere questo problema l'unico modo sarebbe quello di impostare un
\textit{timeout} o riscrivere il client in modo da usare l'I/O non bloccante.
\section{I socket \textit{Unix domain}}
\label{sec:unix_socket}
-Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
+Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
girano sulla stessa macchina, non siano strettamente attinenti alla rete, li
-tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
+tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella
dei socket.
\chapter{Un preambolo}
\label{cha:preamble}
-Questa guida nasce dalla mia profonda convinzione che le istanze di libertà e
+Questa guida nasce dalla mia profonda convinzione che le istanze di libertà e
di condivisione della conoscenza che hanno dato vita a quello straordinario
movimento di persone ed intelligenza che va sotto il nome di \textsl{software
libero} hanno la stessa rilevanza anche quando applicate alla produzione
culturale in genere.
-L'ambito più comune in cui questa filosofia viene applicata è quello della
-documentazione perché il software, per quanto possa essere libero, se non
+L'ambito più comune in cui questa filosofia viene applicata è quello della
+documentazione perché il software, per quanto possa essere libero, se non
accompagnato da una buona documentazione che aiuti a comprenderne il
funzionamento, rischia di essere fortemente deficitario riguardo ad una delle
-libertà fondamentali, quella di essere studiato e migliorato.
+libertà fondamentali, quella di essere studiato e migliorato.
Ritengo inoltre che in campo tecnico ed educativo sia importante poter
disporre di testi didattici (come manuali, enciclopedie, dizionari, ecc.) in
ampliati, o anche ridotti per usi specifici, nello stesso modo in cui si fa
per il software libero.
-Questa guida è il mio tentativo di restituire indietro, nei limiti di quelle
-che sono le mie capacità, un po' della conoscenza che ho ricevuto, mettendo a
+Questa guida è il mio tentativo di restituire indietro, nei limiti di quelle
+che sono le mie capacità, un po' della conoscenza che ho ricevuto, mettendo a
disposizione un testo che possa fare da riferimento a chi si avvicina alla
programmazione su Linux, nella speranza anche di trasmettergli non solo delle
-conoscenze tecniche, ma anche un po' di quella passione per la libertà e la
+conoscenze tecniche, ma anche un po' di quella passione per la libertà e la
condivisione della conoscenza che sono la ricchezza maggiore che ho ricevuto.
-E, come per il software libero, anche in questo caso è importante la
-possibilità di accedere ai sorgenti (e non solo al risultato finale, sia
-questo una stampa o un file formattato) e la libertà di modificarli per
+E, come per il software libero, anche in questo caso è importante la
+possibilità di accedere ai sorgenti (e non solo al risultato finale, sia
+questo una stampa o un file formattato) e la libertà di modificarli per
apportarvi migliorie, aggiornamenti, ecc.
Per questo motivo la Free Software Foundation ha creato una apposita licenza
che potesse giocare lo stesso ruolo fondamentale che la GPL ha avuto per il
-software libero nel garantire la permanenza delle libertà date, ma potesse
+software libero nel garantire la permanenza delle libertà date, ma potesse
anche tenere conto delle differenze che comunque ci sono fra un testo ed un
programma.
-Una di queste differenze è che in un testo, come in questa sezione, possono
+Una di queste differenze è che in un testo, come in questa sezione, possono
venire espresse quelle che sono le idee ed i punti di vista dell'autore, e
mentre trovo che sia necessario permettere cambiamenti nei contenuti tecnici,
che devono essere aggiornati e corretti, non vale lo stesso per l'espressione
delle mie idee contenuta in questa sezione, che ho richiesto resti invariata.
Il progetto pertanto prevede il rilascio della guida con licenza GNU FDL, ed
-una modalità di realizzazione aperta che permetta di accogliere i contributi
+una modalità di realizzazione aperta che permetta di accogliere i contributi
di chiunque sia interessato. Tutti i programmi di esempio sono rilasciati con
licenza GNU GPL.
\chapter{Prefazione}
\label{cha:preface}
-Questo progetto mira alla stesura di un testo il più completo e chiaro
+Questo progetto mira alla stesura di un testo il più completo e chiaro
possibile sulla programmazione di sistema su un kernel Linux. Essendo i
concetti in gran parte gli stessi, il testo dovrebbe restare valido anche per
la programmazione in ambito di sistemi Unix generici, ma resta una attenzione
specifica alle caratteristiche peculiari del kernel Linux e delle versioni
-delle librerie del C in uso con esso; in particolare si darà ampio spazio alla
+delle librerie del C in uso con esso; in particolare si darà ampio spazio alla
versione realizzata dal progetto GNU, le cosiddette \textit{GNU C Library} o
\textsl{glibc}, che ormai sono usate nella stragrande maggioranza dei casi,
-senza tralasciare, là dove note, le differenze con altre implementazioni come
+senza tralasciare, là dove note, le differenze con altre implementazioni come
le \textsl{libc5} o le \textsl{uclib}.
-L'obiettivo finale di questo progetto è quello di riuscire a ottenere un testo
+L'obiettivo finale di questo progetto è quello di riuscire a ottenere un testo
utilizzabile per apprendere i concetti fondamentali della programmazione di
-sistema della stessa qualità dei libri del compianto R. W. Stevens (è un
+sistema della stessa qualità dei libri del compianto R. W. Stevens (è un
progetto molto ambizioso ...).
-Infatti benché le pagine di manuale del sistema (quelle che si accedono con il
+Infatti benché le pagine di manuale del sistema (quelle che si accedono con il
comando \cmd{man}) e il manuale delle librerie del C GNU siano una fonte
-inesauribile di informazioni (da cui si è costantemente attinto nella stesura
+inesauribile di informazioni (da cui si è costantemente attinto nella stesura
di tutto il testo) la loro struttura li rende totalmente inadatti ad una
trattazione che vada oltre la descrizione delle caratteristiche particolari
dello specifico argomento in esame (ed in particolare lo \textit{GNU C Library
Reference Manual} non brilla per chiarezza espositiva).
-Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
+Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
R. W. Stevens (in particolare \cite{APUE} e \cite{UNP1}) per rendere la
-trattazione dei vari argomenti in una sequenza logica il più esplicativa
+trattazione dei vari argomenti in una sequenza logica il più esplicativa
possibile, corredando il tutto, quando possibile, con programmi di esempio.
Dato che sia il kernel che tutte le librerie fondamentali di GNU/Linux sono
-scritte in C, questo sarà il linguaggio di riferimento del testo. In
+scritte in C, questo sarà il linguaggio di riferimento del testo. In
particolare il compilatore usato per provare tutti i programmi e gli esempi
-descritti nel testo è lo GNU GCC. Il testo presuppone una conoscenza media del
+descritti nel testo è lo GNU GCC. Il testo presuppone una conoscenza media del
linguaggio, e di quanto necessario per scrivere, compilare ed eseguire un
programma.
-Infine, dato che lo scopo del progetto è la produzione di un libro, si è
+Infine, dato che lo scopo del progetto è la produzione di un libro, si è
scelto di usare \LaTeX\ come "ambiente di sviluppo" del medesimo, sia per
-l'impareggiabile qualità tipografica ottenibile, che per la congruenza dello
+l'impareggiabile qualità tipografica ottenibile, che per la congruenza dello
strumento con il fine, tanto sul piano pratico, quanto su quello filosofico.
-Il testo sarà, almeno inizialmente, in italiano. Per il momento lo si è
+Il testo sarà, almeno inizialmente, in italiano. Per il momento lo si è
suddiviso in due parti, la prima sulla programmazione di sistema, in cui si
-trattano le varie funzionalità disponibili per i programmi che devono essere
+trattano le varie funzionalità disponibili per i programmi che devono essere
eseguiti su una singola macchina, la seconda sulla programmazione di rete, in
-cui si trattano le funzionalità per eseguire programmi che mettono in
+cui si trattano le funzionalità per eseguire programmi che mettono in
comunicazione macchine diverse.
\chapter{L'interfaccia base con i processi}
\label{cha:process_interface}
-Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
+Come accennato nell'introduzione il \textsl{processo} è l'unità di base con
cui un sistema unix-like alloca ed utilizza le risorse. Questo capitolo
-tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
-gli argomenti, come viene gestita e allocata la memoria, come un processo può
+tratterà l'interfaccia base fra il sistema e i processi, come vengono passati
+gli argomenti, come viene gestita e allocata la memoria, come un processo può
richiedere servizi al sistema e cosa deve fare quando ha finito la sua
esecuzione. Nella sezione finale accenneremo ad alcune problematiche generiche
di programmazione.
\section{Esecuzione e conclusione di un programma}
-Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
-programma: si possono avere più processi che eseguono lo stesso programma ma
-ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
-tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
-variabili proprie e sarà eseguito in maniera completamente indipendente da
-tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
+Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo
+programma: si possono avere più processi che eseguono lo stesso programma ma
+ciascun processo vedrà la sua copia del codice (in realtà il kernel fa sì che
+tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
+variabili proprie e sarà eseguito in maniera completamente indipendente da
+tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
\textit{multi-thread}, ma la gestione dei \itindex{thread} \textit{thread}
- in Linux sarà trattata a parte in cap.~\ref{cha:threads}.}
+ in Linux sarà trattata a parte in cap.~\ref{cha:threads}.}
\subsection{La funzione \func{main}}
dinamico del codice e alla fine lo esegue. Infatti, a meno di non aver
specificato il flag \texttt{-static} durante la compilazione, tutti i
programmi in Linux sono incompleti e necessitano di essere \textsl{collegati}
-alle librerie condivise quando vengono avviati. La procedura è controllata da
+alle librerie condivise quando vengono avviati. La procedura è controllata da
alcune variabili di ambiente e dal contenuto di \conffile{/etc/ld.so.conf}. I
dettagli sono riportati nella pagina di manuale di \cmd{ld.so}.
Il sistema fa partire qualunque programma chiamando la funzione \func{main};
-sta al programmatore chiamare così la funzione principale del programma da cui
+sta al programmatore chiamare così la funzione principale del programma da cui
si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
-\textit{linker} (si chiama così il programma che effettua i collegamenti di
+\textit{linker} (si chiama così il programma che effettua i collegamenti di
cui sopra) darebbe luogo ad errori. Lo standard ISO C specifica che la
-funzione \func{main} può non avere argomenti o prendere due argomenti che
+funzione \func{main} può non avere argomenti o prendere due argomenti che
rappresentano gli argomenti passati da linea di comando, in sostanza un
-prototipo che va sempre bene è il seguente:
+prototipo che va sempre bene è il seguente:
\includecodesnip{listati/main_def.c}
-In realtà nei sistemi Unix esiste un altro modo per definire la funzione
+In realtà nei sistemi Unix esiste un altro modo per definire la funzione
\func{main}, che prevede la presenza di un terzo argomento, \code{char
*envp[]}, che fornisce (vedi sez.~\ref{sec:proc_environ})
-l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
-standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio
+l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
+standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio
evitarla.
\label{sec:proc_conclusion}
Normalmente un programma finisce quando la funzione \func{main} ritorna, una
-modalità equivalente di chiudere il programma è quella di chiamare
+modalità equivalente di chiudere il programma è quella di chiamare
direttamente la funzione \func{exit} (che viene comunque chiamata
-automaticamente quando \func{main} ritorna). Una forma alternativa è quella
+automaticamente quando \func{main} ritorna). Una forma alternativa è quella
di chiamare direttamente la system call \func{\_exit}, che restituisce il
controllo direttamente alla funzione di conclusione dei processi del kernel.
-Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
+Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
segnale (tratteremo i segnali in cap.~\ref{cha:signals}) o della chiamata alla
funzione \func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
\textit{exit status}) e passato al processo che aveva lanciato il programma
(in genere la shell). In generale si usa questo valore per fornire
-informazioni sulla riuscita o il fallimento del programma; l'informazione è
+informazioni sulla riuscita o il fallimento del programma; l'informazione è
necessariamente generica, ed il valore deve essere compreso fra 0 e 255.
-La convenzione in uso pressoché universale è quella di restituire 0 in caso di
-successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
+La convenzione in uso pressoché universale è quella di restituire 0 in caso di
+successo e 1 in caso di fallimento; l'unica eccezione è per i programmi che
effettuano dei confronti (come \cmd{diff}), che usano 0 per indicare la
corrispondenza, 1 per indicare la non corrispondenza e 2 per indicare
-l'incapacità di effettuare il confronto. È opportuno adottare una di queste
+l'incapacità di effettuare il confronto. È opportuno adottare una di queste
convenzioni a seconda dei casi. Si tenga presente che se si raggiunge la fine
della funzione \func{main} senza ritornare esplicitamente si ha un valore di
-uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
+uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
esplicita detta funzione.
Un'altra convenzione riserva i valori da 128 a 256 per usi speciali: ad
-esempio 128 viene usato per indicare l'incapacità di eseguire un altro
-programma in un sottoprocesso. Benché questa convenzione non sia
-universalmente seguita è una buona idea tenerne conto.
+esempio 128 viene usato per indicare l'incapacità di eseguire un altro
+programma in un sottoprocesso. Benché questa convenzione non sia
+universalmente seguita è una buona idea tenerne conto.
-Si tenga presente inoltre che non è una buona idea usare il codice di errore
+Si tenga presente inoltre che non è una buona idea usare il codice di errore
restituito dalla variabile \var{errno} (per i dettagli si veda
sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
-non si cura del valore se non per vedere se è diverso da zero; inoltre il
-valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
+non si cura del valore se non per vedere se è diverso da zero; inoltre il
+valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
uno stato di uscita uguale a zero, che verrebbe interpretato come un successo.
\label{sec:proc_exit}
Come accennato le funzioni usate per effettuare un'uscita ``\textit{normale}''
-da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
-dallo standard ANSI C ed il cui prototipo è:
+da un programma sono due, la prima è la funzione \funcd{exit}, che è definita
+dallo standard ANSI C ed il cui prototipo è:
\begin{prototype}{stdlib.h}{void exit(int status)}
Causa la conclusione ordinaria del programma.
\bodydesc{La funzione non ritorna. Il processo viene terminato.}
\end{prototype}
-La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
+La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
programma che usi le librerie standard del C; essa esegue tutte le funzioni
che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
concludendo immediatamente il processo; i dati sospesi nei buffer degli stream
non vengono salvati e le eventuali funzioni registrate con \func{atexit} e
-\func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
+\func{on\_exit} non vengono eseguite. Il prototipo della funzione è:
\begin{prototype}{unistd.h}{void \_exit(int status)}
Causa la conclusione immediata del programma.
La funzione chiude tutti i file descriptor appartenenti al processo; si tenga
presente che questo non comporta il salvataggio dei dati bufferizzati degli
stream, (torneremo sulle due interfacce dei file a partire da
-cap.~\ref{cha:file_intro}), fa sì che ogni figlio del processo sia adottato da
+cap.~\ref{cha:file_intro}), fa sì che ogni figlio del processo sia adottato da
\cmd{init} (vedi cap.~\ref{cha:process_handling}), manda un segnale
\const{SIGCHLD} al processo padre (vedi sez.~\ref{sec:sig_job_control}) ed
-infine ritorna lo stato di uscita specificato in \param{status} che può essere
+infine ritorna lo stato di uscita specificato in \param{status} che può essere
raccolto usando la funzione \func{wait} (vedi sez.~\ref{sec:proc_wait}).
\subsection{Le funzioni \func{atexit} e \func{on\_exit}}
\label{sec:proc_atexit}
-Un'esigenza comune che si incontra nella programmazione è quella di dover
+Un'esigenza comune che si incontra nella programmazione è quella di dover
effettuare una serie di operazioni di pulizia (ad esempio salvare dei dati,
ripristinare delle impostazioni, eliminare dei file temporanei, ecc.) prima
della conclusione di un programma. In genere queste operazioni vengono fatte
diventa antipatico dover richiedere una chiamata esplicita ad una funzione di
pulizia al programmatore che la utilizza.
-È invece molto meno soggetto ad errori, e completamente trasparente
-all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
+È invece molto meno soggetto ad errori, e completamente trasparente
+all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
una funzione che effettui tali operazioni all'uscita dal programma. A questo
-scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
+scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
di funzioni che verranno eseguite all'uscita dal programma (sia per la
chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
-che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
+che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
\begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
Registra la funzione \param{function} per la chiamata all'uscita dal
programma.
\end{prototype}
\noindent la funzione richiede come argomento l'indirizzo di una opportuna
funzione di pulizia da chiamare all'uscita del programma, che non deve
-prendere argomenti e non deve ritornare niente (deve essere cioè definita come
+prendere argomenti e non deve ritornare niente (deve essere cioè definita come
\code{void function(void)}).
-Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
-\acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
-definita su altri sistemi; il suo prototipo è:
+Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
+\acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
+definita su altri sistemi; il suo prototipo è:
\begin{prototype}{stdlib.h}
{void on\_exit(void (*function)(int , void *), void *arg)}
Registra la funzione \param{function} per la chiamata all'uscita dal
\end{prototype}
In questo caso la funzione da chiamare all'uscita prende i due argomenti
-specificati nel prototipo, dovrà cioè essere definita come \code{void
- function(int status, void *argp)}. Il primo argomento sarà inizializzato
-allo stato di uscita con cui è stata chiamata \func{exit} ed il secondo al
-puntatore \param{arg} passato come secondo argomento di \func{on\_exit}. Così
+specificati nel prototipo, dovrà cioè essere definita come \code{void
+ function(int status, void *argp)}. Il primo argomento sarà inizializzato
+allo stato di uscita con cui è stata chiamata \func{exit} ed il secondo al
+puntatore \param{arg} passato come secondo argomento di \func{on\_exit}. Così
diventa possibile passare dei dati alla funzione di chiusura.
Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
ordine inverso rispetto a quello di registrazione (ed una stessa funzione
-registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
-stream aperti, infine verrà chiamata \func{\_exit}.
+registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
+stream aperti, infine verrà chiamata \func{\_exit}.
\subsection{Conclusioni}
\label{sec:proc_term_conclusion}
-Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
-in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
-kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
+Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
+in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
+kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
una delle funzioni della famiglia \func{exec} che vedremo in
sez.~\ref{sec:proc_exec}).
-Allo stesso modo l'unico modo in cui un programma può concludere
-volontariamente la sua esecuzione è attraverso una chiamata alla system call
+Allo stesso modo l'unico modo in cui un programma può concludere
+volontariamente la sua esecuzione è attraverso una chiamata alla system call
\func{\_exit}, o esplicitamente, o in maniera indiretta attraverso l'uso di
\func{exit} o il ritorno di \func{main}.
-Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
-normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
+Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
+normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
\begin{figure}[htb]
\centering
\label{fig:proc_prog_start_stop}
\end{figure}
-Si ricordi infine che un programma può anche essere interrotto dall'esterno
-attraverso l'uso di un segnale (modalità di conclusione non mostrata in
+Si ricordi infine che un programma può anche essere interrotto dall'esterno
+attraverso l'uso di un segnale (modalità di conclusione non mostrata in
fig.~\ref{fig:proc_prog_start_stop}); tratteremo nei dettagli i segnali e la
loro gestione nel capitolo \ref{cha:signals}.
\section{I processi e l'uso della memoria}
\label{sec:proc_memory}
-Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
-la gestione della memoria è appunto uno degli aspetti più complessi di un
+Una delle risorse base che ciascun processo ha a disposizione è la memoria, e
+la gestione della memoria è appunto uno degli aspetti più complessi di un
sistema unix-like. In questa sezione, dopo una breve introduzione ai concetti
base, esamineremo come la memoria viene vista da parte di un programma in
esecuzione, e le varie funzioni utilizzabili per la sua gestione.
Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i
dettagli di basso livello dipendono spesso in maniera diretta
-dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
-unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
+dall'architettura dell'hardware, ma quello più tipico, usato dai sistemi
+unix-like come Linux è la cosiddetta \index{memoria~virtuale} \textsl{memoria
virtuale} che consiste nell'assegnare ad ogni processo uno spazio virtuale
di indirizzamento lineare, in cui gli indirizzi vanno da zero ad un qualche
valore massimo.\footnote{nel caso di Linux fino al kernel 2.2 detto massimo
era, per macchine a 32bit, di 2Gb. Con il kernel 2.4 ed il supporto per la
- \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
+ \textit{high-memory} il limite è stato esteso anche per macchine a 32 bit.}
-Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
+Come accennato in cap.~\ref{cha:intro_unix} questo spazio di indirizzi è
virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del
-computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
+computer; in genere detto spazio non è neppure continuo (cioè non tutti gli
indirizzi possibili sono utilizzabili, e quelli usabili non sono
necessariamente adiacenti).
Per la gestione da parte del kernel la memoria viene divisa in pagine di
dimensione fissa,\footnote{inizialmente questi erano di 4kb sulle macchine a
- 32 bit e di 8kb sulle alpha, con le versioni più recenti del kernel è
+ 32 bit e di 8kb sulle alpha, con le versioni più recenti del kernel è
possibile anche utilizzare pagine di dimensioni maggiori (4Mb), per sistemi
con grandi quantitativi di memoria in cui l'uso di pagine troppo piccole
comporta una perdita di prestazioni.} e ciascuna pagina nello spazio di
-indirizzi virtuale è associata ad un supporto che può essere una pagina di
+indirizzi virtuale è associata ad un supporto che può essere una pagina di
memoria reale o ad un dispositivo di stoccaggio secondario (come lo spazio
disco riservato alla swap, o i file che contengono il codice). Per ciascun
processo il kernel si cura di mantenere un mappa di queste corrispondenze
-nella cosiddetta \itindex{page~table} \textit{page table}.\footnote{questa è
- una semplificazione brutale, il meccanismo è molto più complesso; una buona
+nella cosiddetta \itindex{page~table} \textit{page table}.\footnote{questa è
+ una semplificazione brutale, il meccanismo è molto più complesso; una buona
trattazione di come Linux gestisce la memoria virtuale si trova su
\cite{LinVM}.}
-Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
+Una stessa pagina di memoria reale può fare da supporto a diverse pagine di
memoria virtuale appartenenti a processi diversi (come accade in genere per le
pagine che contengono il codice delle librerie condivise). Ad esempio il
-codice della funzione \func{printf} starà su una sola pagina di memoria reale
-che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi
+codice della funzione \func{printf} starà su una sola pagina di memoria reale
+che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi
che hanno detta funzione nel loro codice.
La corrispondenza fra le pagine della \index{memoria~virtuale} memoria
virtuale di un processo e quelle della memoria fisica della macchina viene
gestita in maniera trasparente dal kernel.\footnote{in genere con l'ausilio
dell'hardware di gestione della memoria (la \textit{Memory Management Unit}
- del processore), con i kernel della serie 2.6 è comunque diventato possibile
+ del processore), con i kernel della serie 2.6 è comunque diventato possibile
utilizzare Linux anche su architetture che non dispongono di una MMU.}
-Poiché in genere la memoria fisica è solo una piccola frazione della memoria
-virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
+Poiché in genere la memoria fisica è solo una piccola frazione della memoria
+virtuale, è necessario un meccanismo che permetta di trasferire le pagine che
servono dal supporto su cui si trovano in memoria, eliminando quelle che non
-servono. Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
-(o \textit{paging}), ed è uno dei compiti principali del kernel.
+servono. Questo meccanismo è detto \index{paginazione} \textsl{paginazione}
+(o \textit{paging}), ed è uno dei compiti principali del kernel.
-Quando un processo cerca di accedere ad una pagina che non è nella memoria
+Quando un processo cerca di accedere ad una pagina che non è nella memoria
reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
fault}; la gestione della memoria genera un'interruzione e passa il
controllo al kernel il quale sospende il processo e si incarica di mettere in
RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
reperire lo spazio necessario), per poi restituire il controllo al processo.
-Dal punto di vista di un processo questo meccanismo è completamente
+Dal punto di vista di un processo questo meccanismo è completamente
trasparente, e tutto avviene come se tutte le pagine fossero sempre
-disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
+disponibili in memoria. L'unica differenza avvertibile è quella dei tempi di
esecuzione, che passano dai pochi nanosecondi necessari per l'accesso in RAM,
-a tempi molto più lunghi, dovuti all'intervento del kernel.
+a tempi molto più lunghi, dovuti all'intervento del kernel.
-Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
-in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
-esigenze specifiche di prestazioni è possibile usare delle funzioni che
+Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
+in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
+esigenze specifiche di prestazioni è possibile usare delle funzioni che
permettono di bloccare il meccanismo della \index{paginazione} paginazione e
mantenere fisse delle pagine in memoria (vedi sez.~\ref{sec:proc_mem_lock}).
Inoltre per certe applicazioni gli algoritmi di gestione della memoria
\subsection{La struttura della memoria di un processo}
\label{sec:proc_mem_layout}
-Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
-una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
-tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
-commette quando si è manipolato male un puntatore e genera quella che viene
+Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
+una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
+tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
+commette quando si è manipolato male un puntatore e genera quella che viene
chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
-tenta cioè di leggere o scrivere da un indirizzo per il quale non esiste
+tenta cioè di leggere o scrivere da un indirizzo per il quale non esiste
un'associazione della pagina virtuale, il kernel risponde al relativo
\itindex{page~fault} \textit{page fault} mandando un segnale \const{SIGSEGV}
al processo, che normalmente ne causa la terminazione immediata.
-È pertanto importante capire come viene strutturata \index{memoria~virtuale}
+È pertanto importante capire come viene strutturata \index{memoria~virtuale}
\textsl{la memoria virtuale} di un processo. Essa viene divisa in
-\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
-processo può accedere. Solitamente un programma C viene suddiviso nei
+\textsl{segmenti}, cioè un insieme contiguo di indirizzi virtuali ai quali il
+processo può accedere. Solitamente un programma C viene suddiviso nei
seguenti segmenti:
\begin{enumerate}
per tutto il tempo dell'esecuzione.
\item Il \index{segmento!dati} segmento dei dati o \textit{data segment}.
- Contiene le variabili globali (cioè quelle definite al di fuori di tutte le
- funzioni che compongono il programma) e le variabili statiche (cioè quelle
- dichiarate con l'attributo \ctyp{static}). Di norma è diviso in due parti.
+ Contiene le variabili globali (cioè quelle definite al di fuori di tutte le
+ funzioni che compongono il programma) e le variabili statiche (cioè quelle
+ dichiarate con l'attributo \ctyp{static}). Di norma è diviso in due parti.
- La prima parte è il segmento dei dati inizializzati, che contiene le
- variabili il cui valore è stato assegnato esplicitamente. Ad esempio
+ La prima parte è il segmento dei dati inizializzati, che contiene le
+ variabili il cui valore è stato assegnato esplicitamente. Ad esempio
se si definisce:
\includecodesnip{listati/pi.c}
- questo valore sarà immagazzinato in questo segmento. La memoria di questo
+ questo valore sarà immagazzinato in questo segmento. La memoria di questo
segmento viene preallocata all'avvio del programma e inizializzata ai valori
specificati.
- La seconda parte è il segmento dei dati non inizializzati, che contiene le
- variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
+ La seconda parte è il segmento dei dati non inizializzati, che contiene le
+ variabili il cui valore non è stato assegnato esplicitamente. Ad esempio se
si definisce:
\includecodesnip{listati/vect.c}
- questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
+ questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
- variabili che vanno nel segmento dati, e non è affatto vero in generale.}
+ variabili che vanno nel segmento dati, e non è affatto vero in generale.}
Storicamente questa seconda parte del segmento dati viene chiamata BSS (da
- \textit{Block Started by Symbol}). La sua dimensione è fissa.
+ \textit{Block Started by Symbol}). La sua dimensione è fissa.
-\item Lo \itindex{heap} \textit{heap}. Tecnicamente lo si può considerare
- l'estensione del segmento dati, a cui di solito è posto giusto di seguito. È
- qui che avviene l'allocazione dinamica della memoria; può essere
+\item Lo \itindex{heap} \textit{heap}. Tecnicamente lo si può considerare
+ l'estensione del segmento dati, a cui di solito è posto giusto di seguito. È
+ qui che avviene l'allocazione dinamica della memoria; può essere
ridimensionato allocando e disallocando la memoria dinamica con le apposite
funzioni (vedi sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore
(quello adiacente al segmento dati) ha una posizione fissa.
\item Il segmento di \itindex{stack} \textit{stack}, che contiene quello che
viene chiamato \textit{stack} del programma. Tutte le volte che si effettua
- una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
+ una chiamata ad una funzione è qui che viene salvato l'indirizzo di ritorno
e le informazioni dello stato del chiamante (tipo il contenuto di alcuni
registri della CPU), poi la funzione chiamata alloca qui lo spazio per le
sue variabili locali. Tutti questi dati vengono \textit{impilati} (da questo
viene il nome \itindex{stack} \textit{stack}) in sequenza uno sull'altro; in
questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
- della funzione lo spazio è automaticamente rilasciato e
+ della funzione lo spazio è automaticamente rilasciato e
``\textsl{ripulito}''.\footnote{il compilatore si incarica di generare
automaticamente il codice necessario, seguendo quella che viene chiamata
una \textit{calling convention}; quella standard usata con il C ed il C++
- è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
+ è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
\textit{stack} dal chiamante da destra a sinistra, e che si il chiamante
stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
- funzione, se ne possono però utilizzare di alternative (ad esempio nel
- pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
+ funzione, se ne possono però utilizzare di alternative (ad esempio nel
+ pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
di questo fintanto che non si mescolano funzioni scritte con linguaggi
diversi.}
\end{figure}
Una disposizione tipica dei vari segmenti (testo, \itindex{heap}
-\textit{heap}, \itindex{stack} \textit{stack}, ecc.) è riportata in
+\textit{heap}, \itindex{stack} \textit{stack}, ecc.) è riportata in
fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma
-se ne può stampare le dimensioni dei segmenti di testo e di dati
-(inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul
+se ne può stampare le dimensioni dei segmenti di testo e di dati
+(inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul
file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al
caricamento del programma.
\label{sec:proc_mem_alloc}
Il C supporta direttamente, come linguaggio di programmazione, soltanto due
-modalità di allocazione della memoria: l'\textsl{allocazione statica} e
+modalità di allocazione della memoria: l'\textsl{allocazione statica} e
l'\textsl{allocazione automatica}.
-L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
-globali e le variabili statiche, cioè le variabili il cui valore deve essere
+L'\textsl{allocazione statica} è quella con cui sono memorizzate le variabili
+globali e le variabili statiche, cioè le variabili il cui valore deve essere
mantenuto per tutta la durata del programma. Come accennato queste variabili
vengono allocate nel \index{segmento!dati} segmento dei dati all'avvio del
programma (come parte delle operazioni svolte da \func{exec}) e lo spazio da
loro occupato non viene liberato fino alla sua conclusione.
-L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
+L'\textsl{allocazione automatica} è quella che avviene per gli argomenti di
una funzione e per le sue variabili locali (le cosiddette \textsl{variabili
automatiche}), che esistono solo per la durata della funzione. Lo spazio
per queste variabili viene allocato nello \itindex{stack} \textit{stack} quando
viene eseguita la funzione e liberato quando si esce dalla medesima.
-Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
-della memoria, che non è prevista direttamente all'interno del linguaggio C,
-ma che è necessaria quando il quantitativo di memoria che serve è
+Esiste però un terzo tipo di allocazione, l'\textsl{allocazione dinamica}
+della memoria, che non è prevista direttamente all'interno del linguaggio C,
+ma che è necessaria quando il quantitativo di memoria che serve è
determinabile solo durante il corso dell'esecuzione del programma.
-Il C non consente di usare variabili allocate dinamicamente, non è possibile
-cioè definire in fase di programmazione una variabile le cui dimensioni
+Il C non consente di usare variabili allocate dinamicamente, non è possibile
+cioè definire in fase di programmazione una variabile le cui dimensioni
possano essere modificate durante l'esecuzione del programma. Per questo le
librerie del C forniscono una serie opportuna di funzioni per eseguire
l'allocazione dinamica di memoria (in genere nello \itindex{heap}
\textit{heap}).
-Le variabili il cui contenuto è allocato in questo modo non potranno essere
+Le variabili il cui contenuto è allocato in questo modo non potranno essere
usate direttamente come le altre (quelle nello \itindex{stack}
-\textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
+\textit{stack}), ma l'accesso sarà possibile solo in maniera indiretta,
attraverso i puntatori alla memoria loro riservata che si sono ottenuti dalle
funzioni di allocazione.
La funzione restituisce il puntatore alla zona di memoria allocata in caso
di successo e \val{NULL} in caso di fallimento, nel qual caso
- \var{errno} assumerà il valore \errval{ENOMEM}.
+ \var{errno} assumerà il valore \errval{ENOMEM}.
\funcdecl{void *malloc(size\_t size)}
Alloca \param{size} byte nello \textit{heap}. La memoria non viene
inizializzata.
La funzione restituisce il puntatore alla zona di memoria allocata in caso
di successo e \val{NULL} in caso di fallimento, nel qual caso
- \var{errno} assumerà il valore \errval{ENOMEM}.
+ \var{errno} assumerà il valore \errval{ENOMEM}.
\funcdecl{void *realloc(void *ptr, size\_t size)}
Cambia la dimensione del blocco allocato all'indirizzo \param{ptr}
portandola a \param{size}.
La funzione restituisce il puntatore alla zona di memoria allocata in caso
di successo e \val{NULL} in caso di fallimento, nel qual caso
- \var{errno} assumerà il valore \errval{ENOMEM}.
+ \var{errno} assumerà il valore \errval{ENOMEM}.
\funcdecl{void free(void *ptr)}
Disalloca lo spazio di memoria puntato da \param{ptr}.
La funzione non ritorna nulla e non riporta errori.
\end{functions}
-Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
+Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre
allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a
-32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
+32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
multipli di 8 byte.
In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare
-dinamicamente la quantità di memoria necessaria al programma indicata da
+dinamicamente la quantità di memoria necessaria al programma indicata da
\param{size},\footnote{queste funzioni presentano un comportamento diverso fra
- le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
- Nel primo caso viene comunque restituito un puntatore valido, anche se non è
+ le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
+ Nel primo caso viene comunque restituito un puntatore valido, anche se non è
chiaro a cosa esso possa fare riferimento, nel secondo caso viene restituito
- \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
-siccome i puntatori ritornati sono di tipo generico non è necessario
+ \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
+siccome i puntatori ritornati sono di tipo generico non è necessario
effettuare un cast per assegnarli a puntatori al tipo di variabile per la
quale si effettua l'allocazione.
La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
\func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
- definita per compatibilità con SunOS, che è deprecata.} una volta che non
-sia più necessaria. Questa funzione vuole come argomento un puntatore
+ definita per compatibilità con SunOS, che è deprecata.} una volta che non
+sia più necessaria. Questa funzione vuole come argomento un puntatore
restituito da una precedente chiamata a una qualunque delle funzioni di
-allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
-in caso contrario il comportamento della funzione è indefinito.
+allocazione che non sia già stato liberato da un'altra chiamata a \func{free},
+in caso contrario il comportamento della funzione è indefinito.
La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
dimensione di un'area di memoria precedentemente allocata, la funzione vuole
in ingresso il puntatore restituito dalla precedente chiamata ad una
-\func{malloc} (se è passato un valore \val{NULL} allora la funzione si
-comporta come \func{malloc})\footnote{questo è vero per Linux e
- l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
+\func{malloc} (se è passato un valore \val{NULL} allora la funzione si
+comporta come \func{malloc})\footnote{questo è vero per Linux e
+ l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
vecchie implementazioni, inoltre alcune versioni delle librerie del C
consentivano di usare \func{realloc} anche per un puntatore liberato con
- \func{free} purché non ci fossero state nel frattempo altre chiamate a
- funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
+ \func{free} purché non ci fossero state nel frattempo altre chiamate a
+ funzioni di allocazione, questa funzionalità è totalmente deprecata e non è
consentita sotto Linux.} ad esempio quando si deve far crescere la
-dimensione di un vettore. In questo caso se è disponibile dello spazio
+dimensione di un vettore. In questo caso se è disponibile dello spazio
adiacente al precedente la funzione lo utilizza, altrimenti rialloca altrove
un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
spazio aggiunto non viene inizializzato.
Si deve sempre avere ben presente il fatto che il blocco di memoria restituito
-da \func{realloc} può non essere un'estensione di quello che gli si è passato
-in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
+da \func{realloc} può non essere un'estensione di quello che gli si è passato
+in ingresso; per questo si dovrà \emph{sempre} eseguire la riassegnazione di
\param{ptr} al valore di ritorno della funzione, e reinizializzare o provvedere
ad un adeguato aggiornamento di tutti gli altri puntatori all'interno del
blocco di dati ridimensionato.
Un errore abbastanza frequente (specie se si ha a che fare con vettori di
-puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
-puntatore; per evitare questo problema una soluzione di ripiego è quella di
+puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
+puntatore; per evitare questo problema una soluzione di ripiego è quella di
assegnare sempre a \val{NULL} ogni puntatore liberato con \func{free}, dato
-che, quando l'argomento è un puntatore nullo, \func{free} non esegue nessuna
+che, quando l'argomento è un puntatore nullo, \func{free} non esegue nessuna
operazione.
-Le \acr{glibc} hanno un'implementazione delle funzioni di allocazione che è
+Le \acr{glibc} hanno un'implementazione delle funzioni di allocazione che è
controllabile dall'utente attraverso alcune variabili di ambiente (vedi
sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
questo tipo di errori usando la variabile di ambiente \val{MALLOC\_CHECK\_}
che quando viene definita mette in uso una versione meno efficiente delle
-funzioni suddette, che però è più tollerante nei confronti di piccoli errori
+funzioni suddette, che però è più tollerante nei confronti di piccoli errori
come quello di chiamate doppie a \func{free}. In particolare:
\begin{itemize}
-\item se la variabile è posta a zero gli errori vengono ignorati;
-\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
+\item se la variabile è posta a zero gli errori vengono ignorati;
+\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
(vedi sez.~\ref{sec:file_std_stream});
-\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
+\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
l'immediata conclusione del programma.
\end{itemize}
-Il problema più comune e più difficile da risolvere che si incontra con le
-funzioni di allocazione è quando non viene opportunamente liberata la memoria
-non più utilizzata, quello che in inglese viene chiamato \itindex{memory~leak}
-\textit{memory leak}, cioè una \textsl{perdita di memoria}.
+Il problema più comune e più difficile da risolvere che si incontra con le
+funzioni di allocazione è quando non viene opportunamente liberata la memoria
+non più utilizzata, quello che in inglese viene chiamato \itindex{memory~leak}
+\textit{memory leak}, cioè una \textsl{perdita di memoria}.
-Un caso tipico che illustra il problema è quello in cui in una subroutine si
+Un caso tipico che illustra il problema è quello in cui in una subroutine si
alloca della memoria per uso locale senza liberarla prima di uscire. La
-memoria resta così allocata fino alla terminazione del processo. Chiamate
+memoria resta così allocata fino alla terminazione del processo. Chiamate
ripetute alla stessa subroutine continueranno ad effettuare altre allocazioni,
causando a lungo andare un esaurimento della memoria disponibile (e la
-probabile impossibilità di proseguire l'esecuzione del programma).
+probabile impossibilità di proseguire l'esecuzione del programma).
-Il problema è che l'esaurimento della memoria può avvenire in qualunque
-momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
+Il problema è che l'esaurimento della memoria può avvenire in qualunque
+momento, in corrispondenza ad una qualunque chiamata di \func{malloc} che può
essere in una sezione del codice che non ha alcuna relazione con la subroutine
-che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
+che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
\itindex{memory~leak} \textit{memory leak}.
-In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
+In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
programmazione ad oggetti, il problema dei \itindex{memory~leak}
-\textit{memory leak} è notevolmente ridimensionato attraverso l'uso accurato
-di appositi oggetti come gli \textit{smartpointers}. Questo però in genere va
+\textit{memory leak} è notevolmente ridimensionato attraverso l'uso accurato
+di appositi oggetti come gli \textit{smartpointers}. Questo però in genere va
a scapito delle prestazioni dell'applicazione in esecuzione.
% TODO decidere cosa fare di questo che segue
% In altri linguaggi come il java e recentemente il C\# il problema non si pone
-% nemmeno perché la gestione della memoria viene fatta totalmente in maniera
+% nemmeno perché la gestione della memoria viene fatta totalmente in maniera
% automatica, ovvero il programmatore non deve minimamente preoccuparsi di
-% liberare la memoria allocata precedentemente quando non serve più, poiché
+% liberare la memoria allocata precedentemente quando non serve più, poiché
% l'infrastruttura del linguaggio gestisce automaticamente la cosiddetta
% \index{\textit{garbage~collection}} \textit{garbage collection}. In tal caso,
% attraverso meccanismi simili a quelli del \textit{reference counting}, quando
-% una zona di memoria precedentemente allocata non è più riferita da nessuna
-% parte del codice in esecuzione, può essere deallocata automaticamente in
+% una zona di memoria precedentemente allocata non è più riferita da nessuna
+% parte del codice in esecuzione, può essere deallocata automaticamente in
% qualunque momento dall'infrastruttura.
% Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
% (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
-% eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
+% eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
% la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
-% di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
-% compilate direttamente). Questo comporta però il problema della non
-% predicibilità del momento in cui viene deallocata la memoria precedentemente
+% di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
+% compilate direttamente). Questo comporta però il problema della non
+% predicibilità del momento in cui viene deallocata la memoria precedentemente
% allocata da un oggetto.
Per limitare l'impatto di questi problemi, e semplificare la ricerca di
eventuali errori, l'implementazione delle funzioni di allocazione delle
-\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
+\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
-funzioni di libreria una propria versione (che può essere più o meno
+funzioni di libreria una propria versione (che può essere più o meno
specializzata per il debugging). Esistono varie librerie che forniscono dei
sostituti opportuni delle funzioni di allocazione in grado, senza neanche
ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
\href{http://dmalloc.com/}{\textsf{http://dmalloc.com/}} di Gray Watson ed
\textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche
molto complesse riguardo l'allocazione della memoria. Vedremo alcune delle
-funzionalità di ausilio presenti nelle \acr{glibc} in
+funzionalità di ausilio presenti nelle \acr{glibc} in
sez.~\ref{sec:proc_memory_adv_management}.
Una possibile alternativa all'uso di \func{malloc}, per evitare di soffrire
dei problemi di \itindex{memory~leak} \textit{memory leak} descritti in
-precedenza, è di allocare la memoria nel segmento di \itindex{stack}
+precedenza, è di allocare la memoria nel segmento di \itindex{stack}
\textit{stack} della funzione corrente invece che nello \itindex{heap}
-\textit{heap}, per farlo si può usare la funzione \funcd{alloca}, la cui
-sintassi è identica a quella di \func{malloc}; il suo prototipo è:
+\textit{heap}, per farlo si può usare la funzione \funcd{alloca}, la cui
+sintassi è identica a quella di \func{malloc}; il suo prototipo è:
\begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
Alloca \param{size} byte nello \textit{stack}.
allocata.}
\end{prototype}
-La funzione alloca la quantità di memoria (non inizializzata) richiesta
+La funzione alloca la quantità di memoria (non inizializzata) richiesta
dall'argomento \param{size} nel segmento di \itindex{stack} \textit{stack}
-della funzione chiamante. Con questa funzione non è più necessario liberare
+della funzione chiamante. Con questa funzione non è più necessario liberare
la memoria allocata (e quindi non esiste un analogo della \func{free}) in
quanto essa viene rilasciata automaticamente al ritorno della funzione.
-Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
+Come è evidente questa funzione ha molti vantaggi, anzitutto permette di
evitare alla radice i problemi di \itindex{memory~leak} \textit{memory leak},
-dato che non serve più la deallocazione esplicita; inoltre la deallocazione
+dato che non serve più la deallocazione esplicita; inoltre la deallocazione
automatica funziona anche quando si usa \func{longjmp} per uscire da una
subroutine con un salto non locale da una funzione (vedi
sez.~\ref{sec:proc_longjmp}).
-Un altro vantaggio è che in Linux la funzione è molto più veloce di
-\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
-pool di memoria da riservare e si evitano così anche i problemi di
+Un altro vantaggio è che in Linux la funzione è molto più veloce di
+\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
+pool di memoria da riservare e si evitano così anche i problemi di
frammentazione di quest'ultimo, che comportano inefficienze sia
nell'allocazione della memoria che nell'esecuzione dell'allocazione.
-Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
-non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
-suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
-non può essere usata nella lista degli argomenti di una funzione, perché lo
+Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e
+non è inserita né nello standard POSIX né in SUSv3 (ma è presente in BSD), il
+suo utilizzo quindi limita la portabilità dei programmi. Inoltre la funzione
+non può essere usata nella lista degli argomenti di una funzione, perché lo
spazio verrebbe allocato nel mezzo degli stessi.
-Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
+Inoltre non è chiaramente possibile usare \func{alloca} per allocare memoria
che deve poi essere usata anche al di fuori della funzione in cui essa viene
chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
-Questo è lo stesso problema che si può avere con le variabili automatiche, su
+Questo è lo stesso problema che si può avere con le variabili automatiche, su
cui torneremo in sez.~\ref{sec:proc_auto_var}.
Infine non esiste un modo di sapere se l'allocazione ha avuto successo, la
funzione infatti viene realizzata inserendo del codice \textit{inline} nel
-programma\footnote{questo comporta anche il fatto che non è possibile
+programma\footnote{questo comporta anche il fatto che non è possibile
sostituirla con una propria versione o modificarne il comportamento
collegando il proprio programma con un'altra libreria.} che si limita a
-modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
+modificare il puntatore nello \itindex{stack} \textit{stack} e non c'è modo di
sapere se se ne sono superate le dimensioni, per cui in caso di fallimento
-nell'allocazione il comportamento del programma può risultare indefinito,
+nell'allocazione il comportamento del programma può risultare indefinito,
dando luogo ad una \itindex{segment~violation} \textit{segment violation} la
-prima volta che cercherà di accedere alla memoria non effettivamente
+prima volta che cercherà di accedere alla memoria non effettivamente
disponibile.
Le due funzioni seguenti\footnote{le due funzioni sono state definite con BSD
4.3, sono marcate obsolete in SUSv2 e non fanno parte delle librerie
standard del C e mentre sono state esplicitamente rimosse dallo standard
- POSIX/1-2001.} vengono utilizzate soltanto quando è necessario effettuare
+ POSIX/1-2001.} vengono utilizzate soltanto quando è necessario effettuare
direttamente la gestione della memoria associata allo spazio dati di un
processo, ad esempio qualora si debba implementare la propria versione delle
-funzioni di allocazione della memoria. Per poterle utilizzare è necessario
-definire una della macro di funzionalità (vedi
+funzioni di allocazione della memoria. Per poterle utilizzare è necessario
+definire una della macro di funzionalità (vedi
sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
\macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
-ugiale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
+ugiale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
\begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
Sposta la fine del segmento dei dati.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
+ fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
\end{prototype}
-La funzione è un'interfaccia all'omonima system call ed imposta l'indirizzo
+La funzione è un'interfaccia all'omonima system call ed imposta l'indirizzo
finale del \index{segmento!dati} segmento dati di un processo all'indirizzo
specificato da \param{end\_data\_segment}. Quest'ultimo deve essere un valore
ragionevole, ed inoltre la dimensione totale del segmento non deve comunque
imposto sulle dimensioni massime dello spazio dati del processo.
Il valore di ritorno della funzione fa riferimento alla versione fornita dalle
-\acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
+\acr{glibc}, in realtà in Linux la \textit{system call} corrispondente
restituisce come valore di ritorno il nuovo valore della fine del
\index{segmento!dati} segmento dati in caso di successo e quello corrente in
-caso di fallimento, è la funzione di interfaccia usata dalle \acr{glibc} che
-fornisce i valori di ritorno appena descritti, questo può non accadere se si
+caso di fallimento, è la funzione di interfaccia usata dalle \acr{glibc} che
+fornisce i valori di ritorno appena descritti, questo può non accadere se si
usano librerie diverse.
Una seconda funzione per la manipolazione diretta delle dimensioni
\index{segmento!dati} del segmento dati\footnote{in questo caso si tratta
- soltanto di una funzione di libreria, e non di una system call.} è
-\funcd{sbrk}, ed il suo prototipo è:
+ soltanto di una funzione di libreria, e non di una system call.} è
+\funcd{sbrk}, ed il suo prototipo è:
\begin{prototype}{unistd.h}{void *sbrk(ptrdiff\_t increment)}
Incrementa la dimensione dello spazio dati.
\bodydesc{La funzione restituisce il puntatore all'inizio della nuova zona
di memoria allocata in caso di successo e \val{NULL} in caso di
- fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
+ fallimento, nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
\end{prototype}
\noindent la funzione incrementa la dimensione lo spazio dati di un programma
di \param{increment} byte, restituendo il nuovo indirizzo finale dello stesso.
\index{segmento!dati} segmento dati.
Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
-per i programmi normali è sempre opportuno usare le funzioni di allocazione
+per i programmi normali è sempre opportuno usare le funzioni di allocazione
standard descritte in precedenza, che sono costruite su di esse.
dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
parte dei vari processi.
-Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
+Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il
meccanismo della \index{paginazione} paginazione riporta in RAM, ed in maniera
-trasparente, tutte le pagine che gli occorrono; esistono però esigenze
+trasparente, tutte le pagine che gli occorrono; esistono però esigenze
particolari in cui non si vuole che questo meccanismo si attivi. In generale i
-motivi per cui si possono avere di queste necessità sono due:
+motivi per cui si possono avere di queste necessità sono due:
\begin{itemize}
-\item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
- è trasparente solo se il programma in esecuzione non è sensibile al tempo
+\item \textsl{La velocità}. Il processo della \index{paginazione} paginazione
+ è trasparente solo se il programma in esecuzione non è sensibile al tempo
che occorre a riportare la pagina in memoria; per questo motivo processi
critici che hanno esigenze di tempo reale o tolleranze critiche nelle
risposte (ad esempio processi che trattano campionamenti sonori) possono non
- essere in grado di sopportare le variazioni della velocità di accesso dovuta
+ essere in grado di sopportare le variazioni della velocità di accesso dovuta
alla paginazione.
- In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
+ In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
allocazione delle pagine le esigenze specifiche del suo programma e decidere
- quali pagine di memoria è opportuno che restino in memoria per un aumento
+ quali pagine di memoria è opportuno che restino in memoria per un aumento
delle prestazioni. In genere queste sono esigenze particolari e richiedono
- anche un aumento delle priorità in esecuzione del processo (vedi
+ anche un aumento delle priorità in esecuzione del processo (vedi
sez.~\ref{sec:proc_real_time}).
\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
in memoria queste possono essere portate su disco dal meccanismo della
- \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
- in cui detti segreti sono presenti in chiaro e più complessa la loro
- cancellazione (un processo può cancellare la memoria su cui scrive le sue
- variabili, ma non può toccare lo spazio disco su cui una pagina di memoria
- può essere stata salvata). Per questo motivo di solito i programmi di
+ \index{paginazione} paginazione. Questo rende più lungo il periodo di tempo
+ in cui detti segreti sono presenti in chiaro e più complessa la loro
+ cancellazione (un processo può cancellare la memoria su cui scrive le sue
+ variabili, ma non può toccare lo spazio disco su cui una pagina di memoria
+ può essere stata salvata). Per questo motivo di solito i programmi di
crittografia richiedono il blocco di alcune pagine di memoria.
\end{itemize}
-Per ottenere informazioni sulle modalità in cui un programma sta usando la
-memoria virtuale è disponibile una apposita funzione, \funcd{mincore}, che
-però non è standardizzata da POSIX e pertanto non è disponibile su tutte le
+Per ottenere informazioni sulle modalità in cui un programma sta usando la
+memoria virtuale è disponibile una apposita funzione, \funcd{mincore}, che
+però non è standardizzata da POSIX e pertanto non è disponibile su tutte le
versioni di kernel unix-like;\footnote{nel caso di Linux devono essere
comunque definite le macro \macro{\_BSD\_SOURCE} e \macro{\_SVID\_SOURCE}.}
-il suo prototipo è:
+il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
Ritorna lo stato delle pagine di memoria occupate da un processo.
\bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori seguenti:
+ errore, nel qual caso \var{errno} assumerà uno dei valori seguenti:
\begin{errlist}
\item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione
della memoria usata dal processo o l'intervallo di indirizzi specificato
- non è mappato.
- \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
+ non è mappato.
+ \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
una pagina.
\item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
- \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
+ \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
una risposta.
\end{errlist}
}
esaminare con l'indirizzo iniziale (indicato con l'argomento \param{addr}) e
la lunghezza (indicata con l'argomento \param{length}). L'indirizzo iniziale
deve essere un multiplo delle dimensioni di una pagina, mentre la lunghezza
-può essere qualunque, fintanto che si resta nello spazio di indirizzi del
-processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
+può essere qualunque, fintanto che si resta nello spazio di indirizzi del
+processo,\footnote{in caso contrario si avrà un errore di \errcode{ENOMEM};
fino al kernel 2.6.11 in questo caso veniva invece restituito
- \errcode{EINVAL}, in considerazione che il caso più comune in cui si
- verifica questo errore è quando si usa per sbaglio un valore negativo
+ \errcode{EINVAL}, in considerazione che il caso più comune in cui si
+ verifica questo errore è quando si usa per sbaglio un valore negativo
di \param{length}, che nel caso verrebbe interpretato come un intero
- positivo di grandi dimensioni.} ma il risultato verrà comunque fornito per
+ positivo di grandi dimensioni.} ma il risultato verrà comunque fornito per
l'intervallo compreso fino al multiplo successivo.
I risultati della funzione vengono forniti nel vettore puntato da \param{vec},
che deve essere allocato preventivamente e deve essere di dimensione
sufficiente a contenere tanti byte quante sono le pagine contenute
-nell'intervallo di indirizzi specificato.\footnote{la dimensione cioè deve
+nell'intervallo di indirizzi specificato.\footnote{la dimensione cioè deve
essere almeno pari a \code{(length+PAGE\_SIZE-1)/PAGE\_SIZE}. } Al ritorno
-della funzione il bit meno significativo di ciascun byte del vettore sarà
-acceso se la pagina di memoria corrispondente è al momento residente in
-memoria, o cancellato altrimenti. Il comportamento sugli altri bit è
+della funzione il bit meno significativo di ciascun byte del vettore sarà
+acceso se la pagina di memoria corrispondente è al momento residente in
+memoria, o cancellato altrimenti. Il comportamento sugli altri bit è
indefinito, essendo questi al momento riservati per usi futuri. Per questo
-motivo in genere è comunque opportuno inizializzare a zero il contenuto del
-vettore, così che le pagine attualmente residenti in memoria saranno indicata
+motivo in genere è comunque opportuno inizializzare a zero il contenuto del
+vettore, così che le pagine attualmente residenti in memoria saranno indicata
da un valore non nullo del byte corrispondente.
-Dato che lo stato della memoria di un processo può cambiare continuamente, il
-risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
-pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
+Dato che lo stato della memoria di un processo può cambiare continuamente, il
+risultato di \func{mincore} è assolutamente provvisorio e lo stato delle
+pagine potrebbe essere già cambiato al ritorno stesso della funzione, a meno
che, come vedremo ora, non si sia attivato il meccanismo che forza il
mantenimento di una pagina sulla memoria.
\itindbeg{memory~locking}
Il meccanismo che previene la \index{paginazione} paginazione di parte della
-memoria virtuale di un processo è chiamato \textit{memory locking} (o
-\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
+memoria virtuale di un processo è chiamato \textit{memory locking} (o
+\textsl{blocco della memoria}). Il blocco è sempre associato alle pagine della
memoria virtuale del processo, e non al segmento reale di RAM su cui essa
-viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
+viene mantenuta. La regola è che se un segmento di RAM fa da supporto ad
almeno una pagina bloccata allora esso viene escluso dal meccanismo della
\index{paginazione} paginazione. I blocchi non si accumulano, se si blocca due
-volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
+volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è
bloccata oppure no.
Il \textit{memory lock} persiste fintanto che il processo che detiene la
\itindex{copy~on~write} \textit{copy on write} (vedi
sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti
sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non
- scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
+ scrive su un segmento, può usufruire del \textit{memory lock} del padre.} e
vengono automaticamente rimossi se si pone in esecuzione un altro programma
con \func{exec} (vedi sez.~\ref{sec:proc_exec}).
tutti gli altri processi, per cui fino al kernel 2.6.9 solo un processo con i
privilegi opportuni (la \itindex{capabilities} \textit{capability}
\const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
-capacità di bloccare una pagina.
+capacità di bloccare una pagina.
-Il sistema pone dei limiti all'ammontare di memoria di un processo che può
-essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
+Il sistema pone dei limiti all'ammontare di memoria di un processo che può
+essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
standard POSIX.1 richiede che sia definita in \file{unistd.h} la macro
-\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
-\textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
+\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
+\textit{memory locking}. Inoltre in alcuni sistemi è definita la costante
\const{PAGE\_SIZE} in \file{limits.h} per indicare la dimensione di una pagina
in byte.\footnote{con Linux questo non avviene e si deve ricorrere alla
funzione \func{getpagesize}, vedi sez.~\ref{sec:sys_memory_res}.}
-A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
-memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
+A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
+memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
dare privilegi eccessivi a programmi di crittografia, che necessitano di
- questa funzionalità, ma che devono essere usati da utenti normali.} ma
-mentre un processo privilegiato non ha limiti sulla quantità di memoria che
-può bloccare, un processo normale è soggetto al limite della risorsa
+ questa funzionalità, ma che devono essere usati da utenti normali.} ma
+mentre un processo privilegiato non ha limiti sulla quantità di memoria che
+può bloccare, un processo normale è soggetto al limite della risorsa
\const{RLIMIT\_MEMLOCK} (vedi sez.~\ref{sec:sys_resource_limit}). In generale
-poi ogni processo può sbloccare le pagine relative alla propria memoria, se
-però diversi processi bloccano la stessa pagina questa resterà bloccata
-fintanto che ci sarà almeno un processo che la blocca.
+poi ogni processo può sbloccare le pagine relative alla propria memoria, se
+però diversi processi bloccano la stessa pagina questa resterà bloccata
+fintanto che ci sarà almeno un processo che la blocca.
Le funzioni per bloccare e sbloccare la \index{paginazione} paginazione di
singole sezioni di memoria sono \funcd{mlock} e \funcd{munlock}; i loro
Rimuove il blocco della paginazione su un intervallo di memoria.
\bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
- caso di errore, nel qual caso \var{errno} assumerà uno dei
+ caso di errore, nel qual caso \var{errno} assumerà uno dei
valori seguenti:
\begin{errlist}
\item[\errcode{ENOMEM}] alcuni indirizzi dell'intervallo specificato non
- corrispondono allo spazio di indirizzi del processo o si è ecceduto
+ corrispondono allo spazio di indirizzi del processo o si è ecceduto
il numero massimo consentito di pagine bloccate.
- \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
- \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
+ \item[\errcode{EINVAL}] \param{len} non è un valore positivo.
+ \item[\errcode{EPERM}] con un kernel successivo al 2.6.9 il processo non è
privilegiato e si un limite nullo per \const{RLIMIT\_MEMLOCK}.
\end{errlist}
e, per \func{mlock}, anche \errval{EPERM} quando il processo non ha i
argomenti, che ne indicano nell'ordine l'indirizzo iniziale e la lunghezza.
Tutte le pagine che contengono una parte dell'intervallo bloccato sono
mantenute in RAM per tutta la durata del blocco.\footnote{con altri kernel si
- può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
+ può ottenere un errore di \errcode{EINVAL} se \param{addr} non è un multiplo
della dimensione delle pagine di memoria.}
Altre due funzioni, \funcd{mlockall} e \funcd{munlockall}, consentono di
\end{functions}
L'argomento \param{flags} di \func{mlockall} permette di controllarne il
-comportamento; esso può essere specificato come l'OR aritmetico delle due
+comportamento; esso può essere specificato come l'OR aritmetico delle due
costanti:
\begin{basedescript}{\desclabelwidth{2.5cm}}
\item[\const{MCL\_CURRENT}] blocca tutte le pagine correntemente mappate nello
sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
\itindex{page~fault} \textit{page fault} causato dal meccanismo di
\itindex{copy~on~write} \textit{copy on write}. Infatti se nella
-\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
+\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
\textit{page fault} durante l'esecuzione della stessa, con conseguente
rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
In genere si ovvia a questa problematica chiamando una funzione che ha
-allocato una quantità sufficientemente ampia di variabili automatiche, in modo
+allocato una quantità sufficientemente ampia di variabili automatiche, in modo
che esse vengano mappate in RAM dallo \itindex{stack} \textit{stack}, dopo di
che, per essere sicuri che esse siano state effettivamente portate in memoria,
ci si scrive sopra.
\label{sec:proc_memory_adv_management}
La trattazione delle funzioni di allocazione di sez.~\ref{sec:proc_mem_alloc}
-si è limitata a coprire le esigenze generiche di un programma, in cui non si
-hanno dei requisiti specifici e si lascia il controllo delle modalità di
+si è limitata a coprire le esigenze generiche di un programma, in cui non si
+hanno dei requisiti specifici e si lascia il controllo delle modalità di
allocazione alle funzioni di libreria. Tuttavia esistono una serie di casi in
-cui può essere necessario avere un controllo più dettagliato delle modalità
+cui può essere necessario avere un controllo più dettagliato delle modalità
con cui la memoria viene allocata; nel qual caso potranno venire in aiuto le
funzioni trattate in questa sezione.
dimensione. Questo tipo di esigenza emerge usualmente quando si devono
allocare dei buffer da utilizzare per eseguire dell'I/O diretto su dispositivi
a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per
-blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
+blocchi di dimensione fissa, ed è richiesto che l'indirizzo di partenza del
buffer sia un multiplo intero di questa dimensione, usualmente 512 byte. In
-tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
+tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
funzione specifica.
Tradizionalmente per rispondere a questa esigenza sono state crate due
\bodydesc{Entrambe le funzioni ritornano un puntatore al blocco di memoria
allocato in caso di successo e \val{NULL} in caso di errore, nel qual
- caso \var{errno} assumerà uno dei valori seguenti:
+ caso \var{errno} assumerà uno dei valori seguenti:
\begin{errlist}
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
- \item[\errcode{EINVAL}] \param{boundary} non è multiplo di due.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione.
+ \item[\errcode{EINVAL}] \param{boundary} non è multiplo di due.
\end{errlist}
}
\end{functions}
Le funzioni restituiscono il puntatore al buffer di memoria allocata, che per
-\func{memalign} sarà un multiplo di \param{boundary} mentre per \func{valloc}
+\func{memalign} sarà un multiplo di \param{boundary} mentre per \func{valloc}
un multiplo della dimensione di una pagina di memoria. Nel caso della versione
fornita dalle \acr{glibc} la memoria allocata con queste funzioni deve essere
-liberata con \func{free}, cosa che non è detto accada con altre
+liberata con \func{free}, cosa che non è detto accada con altre
implementazioni.
Nessuna delle due funzioni ha una chiara standardizzazione (nessuna delle due
compare in POSIX.1), ed inoltre ci sono indicazioni discordi sui file che ne
-contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
+contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
\texttt{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4} e
\acr{lic5} la dichiarano in \texttt{malloc.h}, lo stesso vale per
- \func{memalign} che in alcuni sistemi è dichiarata in \texttt{stdlib.h}.}
-per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
-nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
-prototipo è:
+ \func{memalign} che in alcuni sistemi è dichiarata in \texttt{stdlib.h}.}
+per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
+nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
+prototipo è:
\begin{prototype}{stdlib.h}{posix\_memalign(void **memptr, size\_t alignment,
size\_t size) }
Alloca un buffer di memoria allineato ad un multiplo di \param{alignment}.
La funzione restituisce il puntatore al buffer allocato all'indirizzo indicato
da \param{memptr}. La funzione fallisce nelle stesse condizioni delle due
funzioni precedenti, ma a differenza di \func{memalign} restituisce un codice
-di errore \errcode{EINVAL} anche se \param{alignment} non è un multiplo della
+di errore \errcode{EINVAL} anche se \param{alignment} non è un multiplo della
la dimensione di \code{sizeof(void *)}. Come per le precedenti la memoria
-allocata con \func{posix\_memalign} può essere disallocata con
-\func{free}.\footnote{che in questo caso è quanto richiesto dallo standard.}
+allocata con \func{posix\_memalign} può essere disallocata con
+\func{free}.\footnote{che in questo caso è quanto richiesto dallo standard.}
Un secondo caso in cui risulta estremamente utile poter avere un maggior
-controllo delle modalità di allocazione della memoria è quello in cui cercano
+controllo delle modalità di allocazione della memoria è quello in cui cercano
errori di programmazione. Esempi di questi errori sono chiamate doppie alla
funzione \func{free} con lo stesso puntatore, o i cosiddetti
-\itindex{buffer~overrun} \textit{buffer overrun}, cioè le scritture su un buffer
+\itindex{buffer~overrun} \textit{buffer overrun}, cioè le scritture su un buffer
oltre le dimensioni della sua allocazione,\footnote{entrambe queste operazioni
causano in genere la corruzione dei dati di controllo delle funzioni di
allocazione, che vengono anch'essi mantenuti nello \itindex{heap}
\textit{heap} per tenere traccia delle zone di memoria allocata.} o i
classici \itindex{memory~leak} \textit{memory leak}.
-Una prima funzionalità di ausilio nella ricerca di questi errori viene fornita
+Una prima funzionalità di ausilio nella ricerca di questi errori viene fornita
dalla \acr{glibc} tramite l'uso della variabile di ambiente
\var{MALLOC\_CHECK\_}. Quando questa viene definita al posto della versione
ordinaria delle funzioni di allocazione (\func{malloc}, \func{calloc},
\func{realloc}, e \func{free}) viene usata una versione meno efficiente ma in
-grado di rilevare (e tollerare) alcuni degli errori più semplici, come le
+grado di rilevare (e tollerare) alcuni degli errori più semplici, come le
doppie chiamate a \func{free} o i \itindex{buffer~overrun} \textit{buffer
- overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
+ overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
esempio dalla scrittura di una stringa di dimensione pari a quella del
buffer, in cui ci si dimentica dello zero di terminazione finale.}
In questo caso a seconda del valore assegnato a \var{MALLOC\_CHECK\_} si
-avranno diversi comportamenti: con 0 l'errore sarà ignorato, con 1 verrà
+avranno diversi comportamenti: con 0 l'errore sarà ignorato, con 1 verrà
stampato un messaggio sullo \textit{standard error} (vedi
-sez.~\ref{sec:file_std_stream}), con 2 verrà invocata la funzione \func{abort}
+sez.~\ref{sec:file_std_stream}), con 2 verrà invocata la funzione \func{abort}
(vedi sez.~\ref{sec:sig_alarm_abort}) che termina il programma, con 3 viene
-sia stampato il messaggio d'errore che abortito il programma. In genere è
+sia stampato il messaggio d'errore che abortito il programma. In genere è
opportuno definire la variabile ad un valore diverso da zero che consente di
rilevare un errore nel momento in cui avviene.
-Una modalità alternativa per effettuare dei controlli di consistenza sullo
+Una modalità alternativa per effettuare dei controlli di consistenza sullo
stato delle allocazioni di memoria eseguite con \func{malloc}, anche questa
-fornita come estensione specifica (e non standard) delle \acr{glibc}, è quella
+fornita come estensione specifica (e non standard) delle \acr{glibc}, è quella
di utilizzare la funzione \funcd{mcheck}, che deve essere chiamata prima di
-eseguire qualunque allocazione con \func{malloc}; il suo prototipo è:
+eseguire qualunque allocazione con \func{malloc}; il suo prototipo è:
\begin{prototype}{mcheck.h}{mcheck(void (*abortfn) (enum mcheck\_status
status))}
Attiva i controlli di consistenza delle allocazioni eseguite da \func{malloc}.
\end{prototype}
La funzione consente di registrare una funzione di emergenza, da passare come
-argomento, che verrà eseguita tutte le volte che, in una successiva esecuzione
+argomento, che verrà eseguita tutte le volte che, in una successiva esecuzione
di \func{malloc}, venissero trovate delle inconsistenze, come delle operazioni
di scrittura oltre i limiti dei buffer allocati. Per questo motivo la funzione
deve essere chiamata prima di qualunque allocazione di memoria, altrimenti
-fallirà con un valore di ritorno pari a $-1$.
+fallirà con un valore di ritorno pari a $-1$.
-Se come argomento di \func{mcheck} si passa \var{NULL} verrà utilizzata una
+Se come argomento di \func{mcheck} si passa \var{NULL} verrà utilizzata una
funzione predefinita che stampa un messaggio di errore ed invoca la funzione
-\func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si dovrà create
-una funzione personalizzata che verrà eseguita ricevendo un unico argomento di
+\func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}), altrimenti si dovrà create
+una funzione personalizzata che verrà eseguita ricevendo un unico argomento di
tipo \type{mcheck\_status},\footnote{trattasi in sostanza di un codice di
- errore che la funzione di emergenza potrà utilizzare per prendere le
- opportune azioni.} un tipo enumerato che può assumere soltanto i valori di
+ errore che la funzione di emergenza potrà utilizzare per prendere le
+ opportune azioni.} un tipo enumerato che può assumere soltanto i valori di
tab.~\ref{tab:mcheck_status_value}.
\begin{table}[htb]
\hline
\hline
\macro{MCHECK\_OK} & riportato (a \func{mprobe}) se nessuna
- inconsistenza è presente.\\
- \macro{MCHECK\_DISABLED}& riportato (a \func{mprobe}) se si è chiamata
- \func{mcheck} dopo aver già usato
+ inconsistenza è presente.\\
+ \macro{MCHECK\_DISABLED}& riportato (a \func{mprobe}) se si è chiamata
+ \func{mcheck} dopo aver già usato
\func{malloc}.\\
\macro{MCHECK\_HEAD} & i dati immediatamente precedenti il buffer sono
stati modificati, avviene in genere quando si
\macro{MCHECK\_TAIL} & i dati immediatamente seguenti il buffer sono
stati modificati, succede quando si va scrivere
oltre la dimensione correttta del buffer.\\
- \macro{MCHECK\_FREE} & il buffer è già stato disallocato.\\
+ \macro{MCHECK\_FREE} & il buffer è già stato disallocato.\\
\hline
\end{tabular}
\caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
\label{tab:mcheck_status_value}
\end{table}
-Una volta che si sia chiamata \func{mcheck} con successo si può anche
+Una volta che si sia chiamata \func{mcheck} con successo si può anche
controllare esplicitamente lo stato delle allocazioni (senza aspettare un
errore nelle relative funzioni) utilizzando la funzione \funcd{mprobe}, il cui
-prototipo è:
+prototipo è:
\begin{prototype}{mcheck.h}{enum mcheck\_status mprobe(ptr)}
Esegue un controllo di consistenza delle allocazioni.
memoria precedentemente allocato con \func{malloc} o \func{realloc}, e
restituisce lo stesso codice di errore che si avrebbe per la funzione di
emergenza ad una successiva chiamata di una funzione di allocazione, e poi i
-primi due codici che indicano rispettivamente quando tutto è a posto o il
-controllo non è possibile per non aver chiamato \func{mcheck} in tempo.
+primi due codici che indicano rispettivamente quando tutto è a posto o il
+controllo non è possibile per non aver chiamato \func{mcheck} in tempo.
-% TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
-% mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
+% TODO: trattare le altre funzionalità avanzate di \func{malloc}, mallopt,
+% mtrace, muntrace, mallinfo e gli hook con le glibc 2.10 c'è pure malloc_info
% a sostituire mallinfo, vedi http://udrepper.livejournal.com/20948.html
-\section{Argomenti, ambiente ed altre proprietà di un processo}
+\section{Argomenti, ambiente ed altre proprietà di un processo}
\label{sec:proc_options}
In questa sezione esamineremo le funzioni che permettono di gestire gli
argomenti e le opzioni, e quelle che consentono di manipolare ed utilizzare le
-variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
+variabili di ambiente. Accenneremo infine alle modalità con cui si può gestire
la localizzazione di un programma modificandone il comportamento a seconda
della lingua o del paese a cui si vuole faccia riferimento nelle sue
operazioni.
\subsection{Il formato degli argomenti}
\label{sec:proc_par_format}
-Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
-vengono lanciati. Il passaggio degli argomenti e delle opzioni è effettuato
+Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
+vengono lanciati. Il passaggio degli argomenti e delle opzioni è effettuato
attraverso gli argomenti \param{argc} e \param{argv} della funzione
\func{main}, che vengono passati al programma dalla shell (o dal processo che
-esegue la \func{exec}, secondo le modalità che vedremo in
+esegue la \func{exec}, secondo le modalità che vedremo in
sez.~\ref{sec:proc_exec}) quando questo viene messo in esecuzione.
In genere il passaggio di argomenti ed opzioni ad un programma viene
effettuato dalla shell, che si incarica di leggere la linea di comando e di
effettuarne la scansione (il cosiddetto \textit{parsing}) per individuare le
-parole che la compongono, ciascuna delle quali potrà essere considerata un
+parole che la compongono, ciascuna delle quali potrà essere considerata un
argomento o un'opzione. Di norma per individuare le parole che andranno a
costituire la lista degli argomenti viene usato come carattere di separazione
-lo spazio o il tabulatore, ma la cosa dipende ovviamente dalle modalità con
+lo spazio o il tabulatore, ma la cosa dipende ovviamente dalle modalità con
cui si effettua la scansione.
\begin{figure}[htb]
inserire in successione i puntatori alle stringhe costituenti i vari argomenti
ed opzioni, e della variabile \param{argc} che deve essere inizializzata al
numero di stringhe passate. Nel caso della shell questo comporta che il primo
-argomento sia sempre il nome del programma; un esempio di questo meccanismo è
+argomento sia sempre il nome del programma; un esempio di questo meccanismo è
mostrato in fig.~\ref{fig:proc_argv_argc}.
che non sia un singolo \texttt{'-'} o un \texttt{'-{}-'} viene considerato
un'opzione. In genere le opzioni sono costituite da una lettera singola
(preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
-associato; un comando tipico può essere quello mostrato in
+associato; un comando tipico può essere quello mostrato in
fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
-e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
+e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
argomento del programma, non un parametro di \cmd{-m}).
Per gestire le opzioni all'interno dei argomenti a linea di comando passati in
riconoscendo le possibili opzioni segnalate con \param{optstring}.
\bodydesc{Ritorna il carattere che segue l'opzione, \cmd{':'} se manca un
- parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e $-1$ se non
+ parametro all'opzione, \cmd{'?'} se l'opzione è sconosciuta, e $-1$ se non
esistono altre opzioni.}
\end{prototype}
ricercando ogni stringa che comincia con \cmd{-} e ritorna ogni volta che
trova un'opzione valida.
-La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
+La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
costituita da tutti i caratteri usati per identificare le singole opzioni, se
l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
-La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
+La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
funzione all'interno di un ciclo, fintanto che essa non ritorna il valore $-1$
-che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
+che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
dichiarata in \param{optstring} viene ritornato il carattere \texttt{'?'}
-mentre se un'opzione che lo richiede non è seguita da un parametro viene
+mentre se un'opzione che lo richiede non è seguita da un parametro viene
ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
\texttt{'-{}-'} la scansione viene considerata conclusa, anche se vi sono altri
elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
\item \var{char *optarg} contiene il puntatore alla stringa parametro
dell'opzione.
\item \var{int optind} alla fine della scansione restituisce l'indice del
- primo elemento di \param{argv} che non è un'opzione.
+ primo elemento di \param{argv} che non è un'opzione.
\item \var{int opterr} previene, se posto a zero, la stampa di un messaggio
di errore in caso di riconoscimento di opzioni non definite.
\item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
\end{itemize*}
-In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
+In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
\file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
comando.
-Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
+Si può notare che si è anzitutto (\texttt{\small 1}) disabilitata la stampa di
messaggi di errore per opzioni non riconosciute, per poi passare al ciclo per
la verifica delle opzioni (\texttt{\small 2-27}); per ciascuna delle opzioni
-possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
-opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
-(il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
+possibili si è poi provveduto ad un'azione opportuna, ad esempio per le tre
+opzioni che prevedono un parametro si è effettuata la decodifica del medesimo
+(il cui indirizzo è contenuto nella variabile \var{optarg}) avvalorando la
relativa variabile (\texttt{\small 12-14}, \texttt{\small 15-17} e
\texttt{\small 18-20}). Completato il ciclo troveremo in \var{optind} l'indice
in \code{argv[]} del primo degli argomenti rimanenti nella linea di comando.
Normalmente \func{getopt} compie una permutazione degli elementi di
-\param{argv} cosicché alla fine della scansione gli elementi che non sono
+\param{argv} cosicché alla fine della scansione gli elementi che non sono
opzioni sono spostati in coda al vettore. Oltre a questa esistono altre due
-modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
-con il carattere \texttt{'+'} (o è impostata la variabile di ambiente
+modalità di gestire gli elementi di \param{argv}; se \param{optstring} inizia
+con il carattere \texttt{'+'} (o è impostata la variabile di ambiente
\macro{POSIXLY\_CORRECT}) la scansione viene fermata non appena si incontra un
-elemento che non è un'opzione.
+elemento che non è un'opzione.
-L'ultima modalità, usata quando un programma può gestire la mescolanza fra
+L'ultima modalità, usata quando un programma può gestire la mescolanza fra
opzioni e argomenti, ma se li aspetta in un ordine definito, si attiva
quando \param{optstring} inizia con il carattere \texttt{'-'}. In questo caso
-ogni elemento che non è un'opzione viene considerato comunque un'opzione e
+ogni elemento che non è un'opzione viene considerato comunque un'opzione e
associato ad un valore di ritorno pari ad 1, questo permette di identificare
gli elementi che non sono opzioni, ma non effettua il riordinamento del
vettore \param{argv}.
\subsection{Le variabili di ambiente}
\label{sec:proc_environ}
-Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
+Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
permette di trasferire ad un processo delle informazioni in modo da
modificarne il comportamento. Ogni processo infatti riceve dal sistema, oltre
alle variabili \param{argv} e \param{argc} anche un \textsl{ambiente} (in
Anche in questo caso la lista delle \textsl{variabili di ambiente} deve essere
costruita ed utilizzata nella chiamata alla funzione \func{exec} (torneremo su
questo in sez.~\ref{sec:proc_exec}) quando questo viene lanciato. Come per la
-lista degli argomenti anche questa lista è un vettore di puntatori a
+lista degli argomenti anche questa lista è un vettore di puntatori a
caratteri, ciascuno dei quali punta ad una stringa, terminata da un
\val{NULL}. A differenza di \code{argv[]} in questo caso non si ha una
-lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
+lunghezza del vettore data da un equivalente di \param{argc}, ma la lista è
terminata da un puntatore nullo.
-L'indirizzo della lista delle variabili di ambiente è passato attraverso la
+L'indirizzo della lista delle variabili di ambiente è passato attraverso la
variabile globale \var{environ}, che viene definita automaticamente per
-cisascun processo, e a cui si può accedere attraverso una semplice
+cisascun processo, e a cui si può accedere attraverso una semplice
dichiarazione del tipo:
\includecodesnip{listati/env_ptr.c}
un esempio della struttura di questa lista, contenente alcune delle variabili
-più comuni che normalmente sono definite dal sistema, è riportato in
+più comuni che normalmente sono definite dal sistema, è riportato in
fig.~\ref{fig:proc_envirno_list}.
\begin{figure}[htb]
\centering
manualemente un ambiente si abbia cura di rispettare questa convenzione.
Inoltre alcune variabili, come quelle elencate in
fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
-da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
+da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
usare nomi espressi in caratteri maiuscoli.\footnote{ma si tratta solo di una
convenzione, niente vieta di usare caratteri minuscoli.}
-Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
+Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
costituiscono un modo comodo per definire un comportamento specifico senza
dover ricorrere all'uso di opzioni a linea di comando o di file di
-configurazione. É di norma cura della shell, quando esegue un comando, passare
+configurazione. É di norma cura della shell, quando esegue un comando, passare
queste variabili al programma messo in esecuzione attraverso un uso opportuno
delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
per indicare la lista delle directory in cui effettuare la ricerca dei comandi
o \texttt{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
\texttt{HOME}, \texttt{USER}, ecc. sono invece definite al login (per i
-dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
+dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
distribuzione definire le opportune variabili di ambiente in uno script di
avvio. Alcune servono poi come riferimento generico per molti programmi, come
\texttt{EDITOR} che indica l'editor preferito da invocare in caso di
-necessità. Una in particolare, \texttt{LANG}, serve a controllare la
+necessità. Una in particolare, \texttt{LANG}, serve a controllare la
localizzazione del programma (su cui torneremo in
sez.~\ref{sec:proc_localization}) per adattarlo alla lingua ed alle convezioni
dei vari paesi.
-Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
+Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
tutte e ne definisce anche altre, in particolare poi alcune funzioni di
libreria prevedono la presenza di specifiche variabili di ambiente che ne
modificano il comportamento, come quelle usate per indicare una localizzazione
-e quelle per indicare un fuso orario; una lista più completa che comprende
-queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
+e quelle per indicare un fuso orario; una lista più completa che comprende
+queste ed ulteriori variabili si può ottenere con il comando \cmd{man 7
environ}.
\begin{table}[htb]
temporanei\\
\hline
\end{tabular}
- \caption{Esempi delle variabili di ambiente più comuni definite da vari
+ \caption{Esempi delle variabili di ambiente più comuni definite da vari
standard.}
\label{tab:proc_env_var}
\end{table}
Lo standard ANSI C prevede l'esistenza di un ambiente, e pur non entrando
nelle specifiche di come sono strutturati i contenuti, definisce la funzione
\funcd{getenv} che permette di ottenere i valori delle variabili di ambiente;
-il suo prototipo è:
+il suo prototipo è:
\begin{prototype}{stdlib.h}{char *getenv(const char *name)}
Esamina l'ambiente del processo cercando una stringa che corrisponda a
quella specificata da \param{name}.
\cmd{NOME=valore}).}
\end{prototype}
-Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
+Oltre a questa funzione di lettura, che è l'unica definita dallo standard ANSI
C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
-delle funzioni previste nei vari standard e disponibili in Linux è riportato
+delle funzioni previste nei vari standard e disponibili in Linux è riportato
in tab.~\ref{tab:proc_env_func}.
\begin{table}[htb]
\label{tab:proc_env_func}
\end{table}
-In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
- quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
+In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
+ quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
\func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
\funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
all'ambiente.
\bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ per un
- errore, che è sempre \errval{ENOMEM}.}
+ errore, che è sempre \errval{ENOMEM}.}
\end{functions}
La terza funzione della lista, \funcd{unsetenv}, serve a cancellare una
-variabile dall'ambiente, il suo prototipo è:
+variabile dall'ambiente, il suo prototipo è:
\begin{functions}
\headdecl{stdlib.h}
\end{functions}
\noindent la funzione elimina ogni occorrenza della variabile specificata; se la
-variabile non esiste non succede nulla. Non è prevista (dato che la funzione è
+variabile non esiste non succede nulla. Non è prevista (dato che la funzione è
\ctyp{void}) nessuna segnalazione di errore.
Per modificare o aggiungere una variabile di ambiente si possono usare sia
\func{setenv} che \func{putenv}. La prima permette di specificare
separatamente nome e valore della variabile di ambiente, inoltre il valore di
\param{overwrite} specifica il comportamento della funzione nel caso la
-variabile esista già, sovrascrivendola se diverso da zero, lasciandola
+variabile esista già, sovrascrivendola se diverso da zero, lasciandola
immutata se uguale a zero.
La seconda funzione prende come argomento una stringa analoga a quella
restituita da \func{getenv}, e sempre nella forma \code{NOME=valore}. Se la
-variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
-invece esiste il suo valore sarà impostato a quello specificato da
+variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
+invece esiste il suo valore sarà impostato a quello specificato da
\param{string}.
Si tenga presente che, seguendo lo standard SUSv2, le \acr{glibc} successive
alla versione 2.1.2 aggiungono \param{string} alla lista delle variabili di
-ambiente;\footnote{il comportamento è lo stesso delle vecchie \acr{libc4} e
+ambiente;\footnote{il comportamento è lo stesso delle vecchie \acr{libc4} e
\acr{libc5}; nelle \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece
- fatta una copia, seguendo il comportamento di BSD4.4; dato che questo può
+ fatta una copia, seguendo il comportamento di BSD4.4; dato che questo può
dar luogo a perdite di memoria e non rispetta lo standard. Il comportamento
- è stato modificato a partire dalle 2.1.2, eliminando anche, sempre in
- conformità a SUSv2, l'attributo \direct{const} dal prototipo.} pertanto ogni
+ è stato modificato a partire dalle 2.1.2, eliminando anche, sempre in
+ conformità a SUSv2, l'attributo \direct{const} dal prototipo.} pertanto ogni
cambiamento alla stringa in questione si riflette automaticamente
sull'ambiente, e quindi si deve evitare di passare a questa funzione una
variabile automatica (per evitare i problemi esposti in
sez.~\ref{sec:proc_auto_var}). Si tenga infine presente che se si passa a
-\func{putenv} solo il nome di una variabile (cioè \param{string} è nella forma
+\func{putenv} solo il nome di una variabile (cioè \param{string} è nella forma
\texttt{NAME} e non contiene un carattere \texttt{'='}) allora questa viene
cancellata dall'ambiente.
-Infine quando chiamata a \func{putenv} comporta la necessità di creare una
-nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
-ma la versione corrente sarà deallocata solo se anch'essa è risultante da
+Infine quando chiamata a \func{putenv} comporta la necessità di creare una
+nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
+ma la versione corrente sarà deallocata solo se anch'essa è risultante da
un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
-perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
-ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
+perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
+ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
sopra dello \itindex{stack} stack, (vedi fig.~\ref{fig:proc_mem_layout}) e non
-nello \itindex{heap} \textit{heap} e quindi non può essere deallocato.
+nello \itindex{heap} \textit{heap} e quindi non può essere deallocato.
Inoltre la memoria associata alle variabili di ambiente eliminate non viene
liberata.
-L'ultima funzione per la gestione dell'ambiente è \funcd{clearenv}, che viene
-usata per cancellare completamente tutto l'ambiente; il suo prototipo è:
+L'ultima funzione per la gestione dell'ambiente è \funcd{clearenv}, che viene
+usata per cancellare completamente tutto l'ambiente; il suo prototipo è:
\begin{functions}
\headdecl{stdlib.h}
In genere si usa questa funzione in maniera precauzionale per evitare i
problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
-ambiente che può contenere dei dati non controllati. In tal caso si provvede
+ambiente che può contenere dei dati non controllati. In tal caso si provvede
alla cancellazione di tutto l'ambiente per costruirne una versione
``\textsl{sicura}'' da zero.
Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
\texttt{LANG} sia usata per indicare ai processi il valore della cosiddetta
-\textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
+\textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
di sistema\footnote{prenderemo in esame soltanto il caso delle \acr{glibc}.}
che consente di gestire in maniera automatica sia la lingua in cui vengono
stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
alfabetici, le espressioni della valute, ecc.
-La localizzazione di un programma si può selezionare con la
+La localizzazione di un programma si può selezionare con la
-In realtà perché un programma sia effettivamente localizzato non è sufficiente
+In realtà perché un programma sia effettivamente localizzato non è sufficiente
-% TODO trattare, quando ci sarà tempo, setlocale ed il resto
+% TODO trattare, quando ci sarà tempo, setlocale ed il resto
%\subsection{Opzioni in formato esteso}
%\label{sec:proc_opt_extended}
-%Oltre alla modalità ordinaria di gestione delle opzioni trattata in
-%sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
+%Oltre alla modalità ordinaria di gestione delle opzioni trattata in
+%sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
%alternativa costituita dalle cosiddette \textit{long-options}, che consente di
-%esprimere le opzioni in una forma più descrittiva che nel caso più generale è
+%esprimere le opzioni in una forma più descrittiva che nel caso più generale è
%qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
-%(NdA: questa parte verrà inserita in seguito).
+%(NdA: questa parte verrà inserita in seguito).
% TODO opzioni in formato esteso
\section{Problematiche di programmazione generica}
\label{sec:proc_gen_prog}
-Benché questo non sia un libro di C, è opportuno affrontare alcune delle
+Benché questo non sia un libro di C, è opportuno affrontare alcune delle
problematiche generali che possono emergere nella programmazione e di quali
precauzioni o accorgimenti occorre prendere per risolverle. Queste
problematiche non sono specifiche di sistemi unix-like o multitasking, ma
avendo trattato in questo capitolo il comportamento dei processi visti come
-entità a sé stanti, le riportiamo qui.
+entità a sé stanti, le riportiamo qui.
\subsection{Il passaggio delle variabili e dei valori di ritorno}
\label{sec:proc_var_passing}
-Una delle caratteristiche standard del C è che le variabili vengono passate
+Una delle caratteristiche standard del C è che le variabili vengono passate
alle subroutine attraverso un meccanismo che viene chiamato \textit{by value}
(diverso ad esempio da quanto avviene con il Fortran, dove le variabili sono
-passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
-del passaggio può essere controllata con l'operatore \cmd{\&}).
+passate, come suol dirsi, \textit{by reference}, o dal C++ dove la modalità
+del passaggio può essere controllata con l'operatore \cmd{\&}).
-Il passaggio di una variabile \textit{by value} significa che in realtà quello
-che viene passato alla subroutine è una copia del valore attuale di quella
-variabile, copia che la subroutine potrà modificare a piacere, senza che il
+Il passaggio di una variabile \textit{by value} significa che in realtà quello
+che viene passato alla subroutine è una copia del valore attuale di quella
+variabile, copia che la subroutine potrà modificare a piacere, senza che il
valore originale nella funzione chiamante venga toccato. In questo modo non
occorre preoccuparsi di eventuali effetti delle operazioni della subroutine
sulla variabile passata come argomento.
-Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
-vale per qualunque variabile, puntatori compresi; quando però in una
+Questo però va inteso nella maniera corretta. Il passaggio \textit{by value}
+vale per qualunque variabile, puntatori compresi; quando però in una
subroutine si usano dei puntatori (ad esempio per scrivere in un buffer) in
-realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
+realtà si va a modificare la zona di memoria a cui essi puntano, per cui anche
se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e
le eventuali modifiche avranno effetto e saranno visibili anche nella funzione
chiamante.
vengono usati per scambiare dati (attraverso buffer o strutture) e le
variabili semplici vengono usate per specificare argomenti; in genere le
informazioni a riguardo dei risultati vengono passate alla funzione chiamante
-attraverso il valore di ritorno. È buona norma seguire questa pratica anche
+attraverso il valore di ritorno. È buona norma seguire questa pratica anche
nella programmazione normale.
-Talvolta però è necessario che la funzione possa restituire indietro alla
+Talvolta però è necessario che la funzione possa restituire indietro alla
funzione chiamante un valore relativo ad uno dei suoi argomenti. Per far
questo si usa il cosiddetto \itindex{value~result~argument} \textit{value
- result argument}, si passa cioè, invece di una normale variabile, un
-puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
+ result argument}, si passa cioè, invece di una normale variabile, un
+puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni
che gestiscono i socket (in sez.~\ref{sec:TCP_functions}), in cui, per
permettere al kernel di restituire informazioni sulle dimensioni delle
strutture degli indirizzi utilizzate, viene usato questo meccanismo.
\subsection{Il passaggio di un numero variabile di argomenti}
\label{sec:proc_variadic}
-Come vedremo nei capitoli successivi, non sempre è possibile specificare un
+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}
+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{\textellipsis}'', che viene chiamato \textit{ellipsis}.
-Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
+Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
realizzato a livello delle librerie standard del C che provvedono gli
strumenti adeguati. L'uso di una \textit{variadic function} prevede quindi
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 header file \file{stdarg.h}; un esempio di
-dichiarazione è il prototipo della funzione \func{execl} che vedremo in
+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
richiede inoltre che l'ultimo degli argomenti fissi sia di tipo
\textit{self-promoting}\footnote{il linguaggio C prevede che quando si
mescolano vari tipi di dati, alcuni di essi possano essere \textsl{promossi}
- per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
+ per compatibilità; ad esempio i tipi \ctyp{float} vengono convertiti
automaticamente a \ctyp{double} ed i \ctyp{char} e gli \ctyp{short} ad
- \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
- a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
+ \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
+ a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
\ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
-alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
+alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
\direct{register}.
-Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
+Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
quelli variabili vengono indicati in maniera generica dalla \textit{ellipsis}.
-L'unica modalità in cui essi possono essere recuperati è pertanto quella
+L'unica modalità in cui essi possono essere recuperati è pertanto quella
sequenziale; essi verranno estratti dallo \itindex{stack} \textit{stack}
secondo l'ordine in cui sono stati scritti. Per fare questo in \file{stdarg.h}
-sono definite delle apposite macro; la procedura da seguire è la seguente:
+sono definite delle apposite macro; la procedura da seguire è la seguente:
\begin{enumerate*}
\item Inizializzare un puntatore alla lista degli argomenti di tipo
\macro{va\_list} attraverso la macro \macro{va\_start}.
\item Accedere ai vari argomenti opzionali con chiamate successive alla macro
- \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
- il secondo e così via.
+ \macro{va\_arg}, la prima chiamata restituirà il primo argomento, la seconda
+ il secondo e così via.
\item Dichiarare la conclusione dell'estrazione degli argomenti invocando la
macro \macro{va\_end}.
\end{enumerate*}
-In generale è perfettamente legittimo richiedere meno argomenti di quelli che
+In generale è perfettamente legittimo richiedere meno argomenti di quelli che
potrebbero essere stati effettivamente forniti, e nella esecuzione delle
-\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
-saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
+\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
+saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
otterranno dei valori indefiniti. Nel caso del \cmd{gcc} l'uso della macro
-\macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
-compatibilità.
+\macro{va\_end} è inutile, ma si consiglia di usarlo ugualmente per
+compatibilità.
Le definizioni delle tre macro sono le seguenti:
\begin{functions}
\funcdecl{void va\_end(va\_list ap)} Conclude l'uso di \param{ap}.
\end{functions}
-In generale si possono avere più puntatori alla lista degli argomenti,
-ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
-e ciascuno potrà scandire la lista degli argomenti per conto suo.
+In generale si possono avere più puntatori alla lista degli argomenti,
+ciascuno andrà inizializzato con \macro{va\_start} e letto con \macro{va\_arg}
+e ciascuno potrà scandire la lista degli argomenti per conto suo.
Dopo l'uso di \macro{va\_end} la variabile \param{ap} diventa indefinita e
successive chiamate a \macro{va\_arg} non funzioneranno. Si avranno risultati
indefiniti anche chiamando \macro{va\_arg} specificando un tipo che non
corrisponde a quello dell'argomento.
-Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
-corpo principale della funzione, il passo 2) invece può essere eseguito anche
+Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel
+corpo principale della funzione, il passo 2) invece può essere eseguito anche
in una subroutine passandole il puntatore alla lista di argomenti; in questo
-caso però si richiede che al ritorno della funzione il puntatore non venga più
+caso però si richiede che al ritorno della funzione il puntatore non venga più
usato (lo standard richiederebbe la chiamata esplicita di \macro{va\_end}),
dato che il valore di \param{ap} risulterebbe indefinito.
-Esistono dei casi in cui è necessario eseguire più volte la scansione degli
-argomenti e poter memorizzare una posizione durante la stessa. La cosa più
+Esistono dei casi in cui è necessario eseguire più volte la scansione degli
+argomenti e poter memorizzare una posizione durante la stessa. La cosa più
naturale in questo caso sembrerebbe quella di copiarsi il puntatore alla lista
degli argomenti con una semplice assegnazione. Dato che una delle
-realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
+realizzazioni più comuni di \macro{va\_list} è quella di un puntatore nello
\itindex{stack} \textit{stack} all'indirizzo dove sono stati salvati gli
-argomenti, è assolutamente normale pensare di poter effettuare questa
+argomenti, è assolutamente normale pensare di poter effettuare questa
operazione.
-In generale però possono esistere anche realizzazioni diverse, per questo
-motivo \macro{va\_list} è definito come \index{tipo!opaco} \textsl{tipo opaco}
-e non può essere assegnato direttamente ad un'altra variabile dello stesso
+In generale però possono esistere anche realizzazioni diverse, per questo
+motivo \macro{va\_list} è definito come \index{tipo!opaco} \textsl{tipo opaco}
+e non può essere assegnato direttamente ad un'altra variabile dello stesso
tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
sistemi che non hanno questa macro provvedono al suo posto
\macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
su \param{dest}.
\end{prototype}
-\noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
+\noindent anche in questo caso è buona norma chiudere ogni esecuzione di una
\macro{va\_copy} con una corrispondente \macro{va\_end} sul nuovo puntatore
alla lista degli argomenti.
La chiamata di una funzione con un numero variabile di argomenti, posto che la
si sia dichiarata e definita come tale, non prevede nulla di particolare;
-l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
-quelli opzionali, separati da virgole. Quello che però è necessario tenere
-presente è come verranno convertiti gli argomenti variabili.
+l'invocazione è identica alle altre, con gli argomenti, sia quelli fissi che
+quelli opzionali, separati da virgole. Quello che però è necessario tenere
+presente è come verranno convertiti gli argomenti variabili.
In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia
che siano fissi sia che siano opzionali (alcuni sistemi trattano diversamente
-gli opzionali), ma dato che il prototipo non può specificare il tipo degli
+gli opzionali), ma dato che il prototipo non può specificare il tipo degli
argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
-dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
+dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
\macro{va\_arg} come \ctyp{int}).
Uno dei problemi che si devono affrontare con le funzioni con un numero
-variabile di argomenti è che non esiste un modo generico che permetta di
+variabile di argomenti è che non esiste un modo generico che permetta di
stabilire quanti sono gli argomenti passati effettivamente in una chiamata.
-Esistono varie modalità per affrontare questo problema; una delle più
-immediate è quella di specificare il numero degli argomenti opzionali come uno
-degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
+Esistono varie modalità per affrontare questo problema; una delle più
+immediate è quella di specificare il numero degli argomenti opzionali come uno
+degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
per specificare anche il tipo degli argomenti (come fa la stringa di formato
per \func{printf}).
-Una modalità diversa, che può essere applicata solo quando il tipo degli
-argomenti lo rende possibile, è quella che prevede di usare un valore speciale
+Una modalità diversa, che può essere applicata solo quando il tipo degli
+argomenti lo rende possibile, è quella che prevede di usare un valore speciale
come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
\val{NULL} per indicare la fine della lista degli argomenti).
\subsection{Potenziali problemi con le variabili automatiche}
\label{sec:proc_auto_var}
-Uno dei possibili problemi che si possono avere con le subroutine è quello di
+Uno dei possibili problemi che si possono avere con le subroutine è quello di
restituire alla funzione chiamante dei dati che sono contenuti in una
variabile automatica. Ovviamente quando la subroutine ritorna la sezione
dello \itindex{stack} \textit{stack} che conteneva la variabile automatica
-potrà essere riutilizzata da una nuova funzione, con le immaginabili
+potrà essere riutilizzata da una nuova funzione, con le immaginabili
conseguenze di sovrapposizione e sovrascrittura dei dati.
-Per questo una delle regole fondamentali della programmazione in C è che
+Per questo una delle regole fondamentali della programmazione in C è che
all'uscita di una funzione non deve restare nessun riferimento alle variabili
locali; qualora sia necessario utilizzare variabili che possano essere viste
anche dalla funzione chiamante queste devono essere allocate esplicitamente, o
\label{sec:proc_longjmp}
Il controllo del flusso di un programma in genere viene effettuato con le
-varie istruzioni del linguaggio C; fra queste la più bistrattata è il
+varie istruzioni del linguaggio C; fra queste la più bistrattata è il
\code{goto}, che viene deprecato in favore dei costrutti della programmazione
-strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
-caso in cui l'uso di questa istruzione porta all'implementazione più
-efficiente e più chiara anche dal punto di vista della struttura del
+strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
+caso in cui l'uso di questa istruzione porta all'implementazione più
+efficiente e più chiara anche dal punto di vista della struttura del
programma: quello dell'uscita in caso di errore.
\index{salto~non-locale|(}
-Il C però non consente di effettuare un salto ad una etichetta definita in
+Il C però non consente di effettuare un salto ad una etichetta definita in
un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
-gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
-\textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
-citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
+gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
+\textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
+citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
cui corpo principale vengono letti dei dati in ingresso sui quali viene
eseguita, tramite una serie di funzioni di analisi, una scansione dei
contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
operazioni.
-Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
-in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
+Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
+in fasi diverse, la rilevazione di un errore nei dati in ingresso può accadere
all'interno di funzioni profondamente annidate l'una nell'altra. In questo
caso si dovrebbe gestire, per ciascuna fase, tutta la casistica del passaggio
all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
-successive. Questo comporterebbe una notevole complessità, mentre sarebbe
-molto più comodo poter tornare direttamente al ciclo di lettura principale,
+successive. Questo comporterebbe una notevole complessità, mentre sarebbe
+molto più comodo poter tornare direttamente al ciclo di lettura principale,
scartando l'input come errato.\footnote{a meno che, come precisa \cite{glibc},
alla chiusura di ciascuna fase non siano associate operazioni di pulizia
specifiche (come deallocazioni, chiusure di file, ecc.), che non potrebbero
essere eseguite con un salto non-locale.}
-Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
+Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
norma viene realizzato salvando il contesto dello \itindex{stack}
\textit{stack} nel punto in cui si vuole tornare in caso di errore, e
ripristinandolo, in modo da tornare nella funzione da cui si era partiti,
quando serve. La funzione che permette di salvare il contesto dello
-\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
+\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
\begin{functions}
\headdecl{setjmp.h}
\funcdecl{int setjmp(jmp\_buf env)}
Salva il contesto dello stack.
- \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
+ \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
che usa il contesto salvato in precedenza.}
\end{functions}
Quando si esegue la funzione il contesto corrente dello \itindex{stack}
\textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
-\type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
- \index{tipo!opaco} \textsl{tipo opaco}. Si definiscono così strutture ed
+\type{jmp\_buf}\footnote{questo è un classico esempio di variabile di
+ \index{tipo!opaco} \textsl{tipo opaco}. Si definiscono così strutture ed
altri oggetti usati da una libreria, la cui struttura interna non deve
essere vista dal programma chiamante (da cui il nome) che li devono
utilizzare solo attraverso dalle opportune funzioni di gestione.} che deve
essere viste in tutte le funzioni del programma.
Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
-diverso da zero viene restituito solo quando il ritorno è dovuto ad una
+diverso da zero viene restituito solo quando il ritorno è dovuto ad una
chiamata di \func{longjmp} in un'altra parte del programma che ripristina lo
\itindex{stack} \textit{stack} effettuando il salto non-locale. Si tenga conto
che il contesto salvato in \param{env} viene invalidato se la funzione che ha
chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
-\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
+\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
per il processo.
Come accennato per effettuare un salto non-locale ad
un punto precedentemente stabilito con \func{setjmp} si usa la funzione
-\funcd{longjmp}; il suo prototipo è:
+\funcd{longjmp}; il suo prototipo è:
\begin{functions}
\headdecl{setjmp.h}
\funcdecl{void longjmp(jmp\_buf env, int val)}
La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
l'esecuzione della funzione il programma prosegue nel codice successivo al
-ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
+ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
il valore
\param{val} invece di zero. Il valore di \param{val} specificato nella
-chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
+chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
restituito 1 al suo posto.
-In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
+In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
di ritornare alla riga successiva della funzione chiamante, il programma
-ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
-il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
+ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
+il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
annidate.
L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
interagiscono direttamente con la gestione dello \itindex{stack}
\textit{stack} ed il funzionamento del compilatore stesso. In particolare
-\func{setjmp} è implementata con una macro, pertanto non si può cercare di
+\func{setjmp} è implementata con una macro, pertanto non si può cercare di
ottenerne l'indirizzo, ed inoltre delle chiamate a questa funzione sono sicure
solo in uno dei seguenti casi:
\begin{itemize}
iterazione;
\item come operando per l'operatore di negazione (\code{!}) in una espressione
di controllo di un comando condizionale, di selezione o di iterazione;
-\item come espressione a sé stante.
+\item come espressione a sé stante.
\end{itemize}
In generale, dato che l'unica differenza fra la chiamata diretta e quella
-ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
-\func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
+ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
+\func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
-Uno dei punti critici dei salti non-locali è quello del valore delle
+Uno dei punti critici dei salti non-locali è quello del valore delle
variabili, ed in particolare quello delle variabili automatiche della funzione
a cui si ritorna. In generale le variabili globali e statiche mantengono i
valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
delle variabili automatiche (o di quelle dichiarate
\direct{register}\footnote{la direttiva \direct{register} del compilatore
chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
- possibile, all'interno di un registro del processore. Questa direttiva è
+ possibile, all'interno di un registro del processore. Questa direttiva è
originaria dell'epoca dai primi compilatori, quando stava al programmatore
- scrivere codice ottimizzato, riservando esplicitamente alle variabili più
- usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
+ scrivere codice ottimizzato, riservando esplicitamente alle variabili più
+ usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
dato che tutti i compilatori sono normalmente in grado di valutare con
maggior efficacia degli stessi programmatori quando sia il caso di eseguire
questa ottimizzazione.}) sono in genere indeterminati.
-Quello che succede infatti è che i valori delle variabili che sono tenute in
+Quello che succede infatti è che i valori delle variabili che sono tenute in
memoria manterranno il valore avuto al momento della chiamata di
\func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
chiamata ad un'altra funzione vengono salvati nel contesto nello
\itindex{stack} \textit{stack}) torneranno al valore avuto al momento della
chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento
-coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
+coerente si può bloccare l'ottimizzazione che porta le variabili nei registri
dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
- \direct{volatile} informa il compilatore che la variabile che è dichiarata
- può essere modificata, durante l'esecuzione del nostro, da altri programmi.
+ \direct{volatile} informa il compilatore che la variabile che è dichiarata
+ può essere modificata, durante l'esecuzione del nostro, da altri programmi.
Per questo motivo occorre dire al compilatore che non deve essere mai
utilizzata l'ottimizzazione per cui quanto opportuno essa viene mantenuta in
- un registro, poiché in questo modo si perderebbero le eventuali modifiche
+ un registro, poiché in questo modo si perderebbero le eventuali modifiche
fatte dagli altri programmi (che avvengono solo in una copia posta in
memoria).}
Come accennato nell'introduzione in un sistema Unix tutte le operazioni
vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
-a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
+a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
-unità a se stante, in questo esamineremo il funzionamento dei processi
-all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
+unità a se stante, in questo esamineremo il funzionamento dei processi
+all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
della terminazione dei processi, della gestione dei loro attributi e
privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
finale introdurremo alcune problematiche generiche della programmazione in
\label{sec:proc_hierarchy}
A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
-generazione di nuovi processi è un'operazione privilegiata) una delle
-caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
-qualunque processo può a sua volta generarne altri, detti processi figli
-(\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
+generazione di nuovi processi è un'operazione privilegiata) una delle
+caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
+qualunque processo può a sua volta generarne altri, detti processi figli
+(\textit{child process}). Ogni processo è identificato presso il sistema da un
+numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
\acr{pid}, assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid})
quando il processo viene creato.
-Una seconda caratteristica di un sistema Unix è che la generazione di un
-processo è un'operazione separata rispetto al lancio di un programma. In
-genere la sequenza è sempre quella di creare un nuovo processo, il quale
-eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
+Una seconda caratteristica di un sistema Unix è che la generazione di un
+processo è un'operazione separata rispetto al lancio di un programma. In
+genere la sequenza è sempre quella di creare un nuovo processo, il quale
+eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
quello che fa la shell quando mette in esecuzione il programma che gli
indichiamo nella linea di comando.
-Una terza caratteristica è che ogni processo è sempre stato generato da un
+Una terza caratteristica è che ogni processo è sempre stato generato da un
altro, che viene chiamato processo padre (\textit{parent process}). Questo
vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
-punto di partenza esiste un processo speciale (che normalmente è
+punto di partenza esiste un processo speciale (che normalmente è
\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
-\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
-Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
+Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
partire tutti gli altri processi necessari al funzionamento del sistema,
-inoltre \cmd{init} è essenziale per svolgere una serie di compiti
+inoltre \cmd{init} è essenziale per svolgere una serie di compiti
amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
-essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
+essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
struttura del sistema comunque consente di lanciare al posto di \cmd{init}
qualunque altro programma, e in casi di emergenza (ad esempio se il file di
-\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
+\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
\begin{figure}[!htb]
|-snort
`-wwwoffled
\end{verbatim} %$
- \caption{L'albero dei processi, così come riportato dal comando
+ \caption{L'albero dei processi, così come riportato dal comando
\cmd{pstree}.}
\label{fig:proc_tree}
\end{figure}
Dato che tutti i processi attivi nel sistema sono comunque generati da
-\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
+\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
vero, in Linux ci sono alcuni processi speciali che pur comparendo come
- figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
+ figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
possono classificare i processi con la relazione padre/figlio in
un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
organizzati in un albero di directory (si veda
-sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
+sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
+struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
processi.
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header
file \file{linux/sched.h}, ed uno schema semplificato, che riporta la
struttura delle principali informazioni contenute nella \struct{task\_struct}
-(che in seguito incontreremo a più riprese), è mostrato in
+(che in seguito incontreremo a più riprese), è mostrato in
fig.~\ref{fig:proc_task_struct}.
\begin{figure}[htb]
\label{fig:proc_task_struct}
\end{figure}
-% TODO la task_struct è cambiata per qualche dettaglio vedi anche
+% TODO la task_struct è cambiata per qualche dettaglio vedi anche
% http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
% TODO completare la parte su quando viene chiamato lo scheduler.
-Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
+Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
- di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
+eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
+ di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
di sistema provvede comunque a che esso sia invocato periodicamente; generando
un interrupt periodico secondo la frequenza specificata dalla costante
\const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
- tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
- portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
+ tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
+ portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
compilazione del kernel, con un default di 250 e valori possibili di 100,
- 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
+ 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
refresh della televisione); occorre fare attenzione a non confondere questo
valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
+valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
- detto \textit{tickless}, in cui non c'è più una interruzione periodica con
+ detto \textit{tickless}, in cui non c'è più una interruzione periodica con
frequenza prefissata, ma ad ogni chiamata del timer viene programmata
l'interruzione successiva sulla base di una stima; in questo modo si evita
di dover eseguire un migliaio di interruzioni al secondo anche su macchine
che non stanno facendo nulla, con un forte risparmio nell'uso dell'energia
- da parte del processore che può essere messo in stato di sospensione anche
+ da parte del processore che può essere messo in stato di sospensione anche
per lunghi periodi di tempo.}
Ogni volta che viene eseguito, lo \itindex{scheduler} \textit{scheduler}
-effettua il calcolo delle priorità dei vari processi attivi (torneremo su
+effettua il calcolo delle priorità dei vari processi attivi (torneremo su
questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
essere posto in esecuzione fino alla successiva invocazione.
Tradizionalmente in un sistema unix-like i processi vengono sempre creati da
altri processi tramite la funzione \func{fork}; il nuovo processo (che viene
-chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
+chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
processo processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e
viene eseguito in maniera indipendente (le differenze fra padre e figlio sono
affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
abbastanza limitata sulle cause della terminazione del processo figlio.
Quando un processo ha concluso il suo compito o ha incontrato un errore non
-risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
+risolvibile esso può essere terminato con la funzione \func{exit} (si veda
+quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
termina completamente solo quando la notifica della sua conclusione viene
ricevuta dal processo padre, a quel punto tutte le risorse allocate nel
sistema ad esso associate vengono rilasciate.
-Avere due processi che eseguono esattamente lo stesso codice non è molto
+Avere due processi che eseguono esattamente lo stesso codice non è molto
utile, normalmente si genera un secondo processo per affidargli l'esecuzione
-di un compito specifico (ad esempio gestire una connessione dopo che questa è
+di un compito specifico (ad esempio gestire una connessione dopo che questa è
stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
-coi processi che è la \func{exec}.
+coi processi che è la \func{exec}.
Il programma che un processo sta eseguendo si chiama immagine del processo (o
\textit{process image}), le funzioni della famiglia \func{exec} permettono di
caricare un altro programma da disco sostituendo quest'ultimo all'immagine
-corrente; questo fa sì che l'immagine precedente venga completamente
+corrente; questo fa sì che l'immagine precedente venga completamente
cancellata. Questo significa che quando il nuovo programma termina, anche il
-processo termina, e non si può tornare alla precedente immagine.
+processo termina, e non si può tornare alla precedente immagine.
Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
Come accennato nell'introduzione, ogni processo viene identificato dal sistema
da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
-quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
-intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
+quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
+intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
\ctyp{int}).
Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
assegnato il numero successivo a quello usato per l'ultimo processo creato,
- a meno che questo numero non sia già utilizzato per un altro \acr{pid},
+ a meno che questo numero non sia già utilizzato per un altro \acr{pid},
\acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} ogni volta
che un nuovo processo viene creato, fino ad un limite che, essendo il
\acr{pid} un numero positivo memorizzato in un intero a 16 bit, arriva ad un
-massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
+massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
al kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in
\file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
nuova interfaccia per i \itindex{thread} \textit{thread} creata da Ingo
- Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
- il valore massimo è impostabile attraverso il file
+ Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
+ il valore massimo è impostabile attraverso il file
\procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
+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.
Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
candidato per generare ulteriori indicatori associati al processo di cui
-diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
+diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa funzione.
+non potrà essere replicato da un altro processo che usi la stessa funzione.
Tutti i processi figli dello stesso processo padre sono detti
-\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
+\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
processo vengono associati degli altri identificatori che vengono usati per il
-controllo di accesso. Questi servono per determinare se un processo può
+controllo di accesso. Questi servono per determinare se un processo può
eseguire o meno le operazioni richieste, a seconda dei privilegi e
-dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
+dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
\label{sec:proc_fork}
-La funzione \funcd{fork} è la funzione fondamentale della gestione dei
-processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
-processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
- system call usata più comunemente da Linux per creare nuovi processi è
- \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
- \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
+La funzione \funcd{fork} è la funzione fondamentale della gestione dei
+processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
+processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
+ system call usata più comunemente da Linux per creare nuovi processi è
+ \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
+ \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
\func{fork} viene implementata tramite \func{clone}, cosa che consente una
migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
centrale tutte le volte che si devono scrivere programmi che usano il
multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
- \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
+ \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
ma \func{fork} resta comunque la funzione principale per la creazione di
- processi.} Il prototipo della funzione è:
+ processi.} Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
\bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
- errore; \var{errno} può assumere i valori:
+ errore; \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
processo (per allocare la tabella delle pagine e le strutture del task) o
- si è esaurito il numero di processi disponibili.
- \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
+ si è esaurito il numero di processi disponibili.
+ \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
strutture necessarie al kernel per creare il nuovo processo.
\end{errlist}}
\end{functions}
Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
il processo figlio continuano ad essere eseguiti normalmente a partire
-dall'istruzione successiva alla \func{fork}; il processo figlio è però una
+dall'istruzione successiva alla \func{fork}; il processo figlio è però una
copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
testo, \itindex{stack} \textit{stack} e \index{segmento!dati} dati (vedi
sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre. Si tenga presente però che la memoria è copiata, non condivisa,
+padre. Si tenga presente però che la memoria è copiata, non condivisa,
pertanto padre e figlio vedono variabili diverse.
Per quanto riguarda la gestione della memoria, in generale il
-\index{segmento!testo} segmento di testo, che è identico per i due processi, è
+\index{segmento!testo} segmento di testo, che è identico per i due processi, è
condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
write}; questa tecnica comporta che una pagina di memoria viene
effettivamente copiata per il nuovo processo solo quando ci viene effettuata
sopra una scrittura (e si ha quindi una reale differenza fra padre e figlio).
-In questo modo si rende molto più efficiente il meccanismo della creazione di
-un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
+In questo modo si rende molto più efficiente il meccanismo della creazione di
+un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
state modificate, e solo al momento della modifica stessa.
-La differenza che si ha nei due processi è che nel processo padre il valore di
-ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
-nel figlio è zero; in questo modo il programma può identificare se viene
+La differenza che si ha nei due processi è che nel processo padre il valore di
+ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
+nel figlio è zero; in questo modo il programma può identificare se viene
eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
\textbf{due} volte: una nel padre e una nel figlio.
-La scelta di questi valori di ritorno non è casuale, un processo infatti può
-avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
+La scelta di questi valori di ritorno non è casuale, un processo infatti può
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
permette di identificare quello appena creato; al contrario un figlio ha
-sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
+sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
\func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
-che non è il \acr{pid} di nessun processo.
+che non è il \acr{pid} di nessun processo.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:proc_fork_code}
\end{figure}
-Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
-sono già troppi processi nel sistema (il che di solito è sintomo che
-qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
+Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
+sono già troppi processi nel sistema (il che di solito è sintomo che
+qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
sul numero totale di processi permessi all'utente (vedi
sez.~\ref{sec:sys_resource_limit}, ed in particolare
tab.~\ref{tab:sys_rlimit_values}).
-L'uso di \func{fork} avviene secondo due modalità principali; la prima è
+L'uso di \func{fork} avviene secondo due modalità principali; la prima è
quella in cui all'interno di un programma si creano processi figli cui viene
affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
-ne esegue un'altra. È il caso tipico dei programmi server (il modello
-\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
+ne esegue un'altra. È il caso tipico dei programmi server (il modello
+\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
padre riceve ed accetta le richieste da parte dei programmi client, per
-ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
+ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
il servizio.
-La seconda modalità è quella in cui il processo vuole eseguire un altro
-programma; questo è ad esempio il caso della shell. In questo caso il processo
-crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
+La seconda modalità è quella in cui il processo vuole eseguire un altro
+programma; questo è ad esempio il caso della shell. In questo caso il processo
+crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
-seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
-operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
-scelto di mantenere questa separazione, dato che, come per la prima modalità
-d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
+seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
+operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
+scelto di mantenere questa separazione, dato che, come per la prima modalità
+d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
-seconda modalità d'uso, avere le due funzioni separate permette al figlio di
+seconda modalità d'uso, avere le due funzioni separate permette al figlio di
cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, identificatori) prima della \func{exec}, rendendo così
-relativamente facile intervenire sulle le modalità di esecuzione del nuovo
+dell'output, identificatori) prima della \func{exec}, rendendo così
+relativamente facile intervenire sulle le modalità di esecuzione del nuovo
programma.
-In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
+In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
dell'uso della funzione \func{fork}. Il programma crea un numero di figli
specificato da linea di comando, e prende anche alcune opzioni per indicare
degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
descrizione delle opzioni); il codice completo, compresa la parte che gestisce
-le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
+le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
distribuito insieme agli altri sorgenti degli esempi su
\href{http://gapil.truelite.it/gapil_source.tgz}
{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
specificato e scrivere un messaggio prima di uscire. Il processo padre invece
(\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
-alla conclusione del ciclo, prima di uscire, può essere specificato un altro
+alla conclusione del ciclo, prima di uscire, può essere specificato un altro
periodo di attesa.
-Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
+Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
-senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
+senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
valori predefiniti specificano di non attendere), otterremo come output sul
terminale:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
\end{Verbatim}
%$
-Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
-si può dire quale processo fra il padre ed il figlio venga eseguito per primo
-dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
+Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
+si può dire quale processo fra il padre ed il figlio venga eseguito per primo
+dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
primi due cicli sia stato eseguito per primo il padre (con la stampa del
\acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio
(completata con i due avvisi di esecuzione ed uscita), e tornare
all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
-mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
+mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
e poi il padre.
-In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
+In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
\itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione
in cui si trova la macchina al momento della chiamata, risultando del tutto
-impredicibile. Eseguendo più volte il programma di prova e producendo un
+impredicibile. Eseguendo più volte il programma di prova e producendo un
numero diverso di figli, si sono ottenute situazioni completamente diverse,
-compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
+compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
prima che uno dei figli venisse messo in esecuzione.
-Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
-istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
-essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
-occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
+Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
+istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
+essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
+occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}).
-In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
+In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
\textit{scheduler} di Ingo Molnar esegue sempre per primo il
figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
- della serie 2.4.} questa è una ottimizzazione che serve a evitare che il
+ della serie 2.4.} questa è una ottimizzazione che serve a evitare che il
padre, effettuando per primo una operazione di scrittura in memoria, attivi il
meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
operazione infatti potrebbe risultare del tutto inutile qualora il figlio
% prima il padre per questioni di caching nella CPU
Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
-avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
+avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
+allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
opportuno non fare affidamento su questo comportamento, che non si riscontra
in altri Unix e nelle versioni del kernel precedenti a quella indicata.
alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
in eventuali altri processi figli che eseguano lo stesso codice).
-Un secondo aspetto molto importante nella creazione dei processi figli è
+Un secondo aspetto molto importante nella creazione dei processi figli è
quello dell'interazione dei vari processi con i file; per illustrarlo meglio
proviamo a redirigere su un file l'output del nostro programma di test, quello
-che otterremo è:
+che otterremo è:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
[piccardi@selidor sources]$ ./forktest 3 > output
[piccardi@selidor sources]$ cat output
Spawned 3 child, pid 1970
Go to next child
\end{Verbatim}
-che come si vede è completamente diverso da quanto ottenevamo sul terminale.
+che come si vede è completamente diverso da quanto ottenevamo sul terminale.
-Il comportamento delle varie funzioni di interfaccia con i file è analizzato
+Il comportamento delle varie funzioni di interfaccia con i file è analizzato
in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
funzioni standard della libreria del C che prevedono l'output bufferizzato; e
Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
-non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
-ogni figlio riceve una copia della memoria del padre, esso riceverà anche
-quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
-padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
+non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
+ogni figlio riceve una copia della memoria del padre, esso riceverà anche
+quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
+padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
figlio, troveremo nel file anche tutto quello che il processo padre aveva
scritto prima della sua creazione. E alla fine del file (dato che in questo
caso il padre esce per ultimo) troveremo anche l'output completo del padre.
L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
-valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
+valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
solo processi diversi possono scrivere in contemporanea sullo stesso file
-(l'argomento della condivisione dei file è trattato in dettaglio in
+(l'argomento della condivisione dei file è trattato in dettaglio in
sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
+le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
i processi figli.
-Quello che succede è che quando lo standard output del padre viene rediretto
-come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
+Quello che succede è che quando lo standard output del padre viene rediretto
+come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
funzione \func{fork} infatti ha la caratteristica di duplicare nei processi
figli tutti i file descriptor aperti nel processo padre (allo stesso modo in
cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il che
comporta che padre e figli condividono le stesse voci della
\itindex{file~table} \textit{file table} (per la spiegazione di questi termini
-si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
+si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
nel file.
-In questo modo se un processo scrive sul file aggiornerà la posizione corrente
+In questo modo se un processo scrive sul file aggiornerà la posizione corrente
sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
cui diversi processi scrivono sullo stesso file, che l'output successivo di un
-processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
+processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
-Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
+Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
crea un figlio e attende la sua conclusione per proseguire, ed entrambi
-scrivono sullo stesso file; un caso tipico è la shell quando lancia un
+scrivono sullo stesso file; un caso tipico è la shell quando lancia un
programma, il cui output va sullo standard output. In questo modo, anche se
-l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
-a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
+l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
+a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
questo comportamento sarebbe estremamente complesso necessitando di una
qualche forma di comunicazione fra i due processi per far riprendere al padre
la scrittura al punto giusto.
-In generale comunque non è buona norma far scrivere più processi sullo stesso
+In generale comunque non è buona norma far scrivere più processi sullo stesso
file senza una qualche forma di sincronizzazione in quanto, come visto anche
con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
-una sequenza impredicibile. Per questo le modalità con cui in genere si usano
+una sequenza impredicibile. Per questo le modalità con cui in genere si usano
i file dopo una \func{fork} sono sostanzialmente due:
\begin{enumerate*}
\item Il processo padre aspetta la conclusione del figlio. In questo caso non
- è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
+ è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
della posizione corrente dopo eventuali operazioni di lettura e scrittura
- effettuate dal figlio è automatica.
+ effettuate dal figlio è automatica.
\item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
ciascuno dei due processi deve chiudere i file che non gli servono una volta
- che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
+ che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
\end{enumerate*}
Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
-proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
-comune dopo l'esecuzione di una \func{fork} è la seguente:
+proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
+comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
\textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
\item i segmenti di memoria condivisa agganciati al processo (vedi
sez.~\ref{sec:ipc_sysv_shm});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
-\item il valori di \textit{nice}, le priorità real-time e le affinità di
+\item il valori di \textit{nice}, le priorità real-time e le affinità di
processore (vedi sez.~\ref{sec:proc_sched_stand},
sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
\end{itemize*}
Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
- parte le ultime quattro, relative a funzionalità specifiche di Linux, le
+ parte le ultime quattro, relative a funzionalità specifiche di Linux, le
altre sono esplicitamente menzionate dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:prctl_xxx}) che
notifica al figlio la terminazione del padre viene cancellata;
-\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
+\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
\end{itemize*}
-Una seconda funzione storica usata per la creazione di un nuovo processo è
-\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
-semantica e gli stessi errori; la sola differenza è che non viene creata la
-tabella delle pagine né la struttura dei task per il nuovo processo. Il
-processo padre è posto in attesa fintanto che il figlio non ha eseguito una
-\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
+Una seconda funzione storica usata per la creazione di un nuovo processo è
+\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
+semantica e gli stessi errori; la sola differenza è che non viene creata la
+tabella delle pagine né la struttura dei task per il nuovo processo. Il
+processo padre è posto in attesa fintanto che il figlio non ha eseguito una
+\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
-Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
+Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
\func{fork} comportava anche la copia completa del segmento dati del processo
padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
\func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
venne introdotta in BSD per migliorare le prestazioni.
Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
-perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
+perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
funzione, che resta un caso speciale della system call \func{clone} (che
-tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
+tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
questo eviteremo di trattarla ulteriormente.
\subsection{La conclusione di un processo}
\label{sec:proc_termination}
-In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
+In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
con un sistema multitasking resta da affrontare l'argomento dal punto di vista
di come il sistema gestisce la conclusione dei processi.
-Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
+Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
programma viene terminato in maniera normale: la chiamata di \func{exit} (che
esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
terminazione del processo da parte del kernel).
Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
-modalità di conclusione anomala; queste sono in sostanza due: il programma può
+modalità di conclusione anomala; queste sono in sostanza due: il programma può
chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
terminato da un segnale (torneremo sui segnali in cap.~\ref{cha:signals}). In
-realtà anche la prima modalità si riconduce alla seconda, dato che
+realtà anche la prima modalità si riconduce alla seconda, dato che
\func{abort} si limita a generare il segnale \const{SIGABRT}.
-Qualunque sia la modalità di conclusione di un processo, il kernel esegue
+Qualunque sia la modalità di conclusione di un processo, il kernel esegue
comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
-memoria che stava usando, e così via; l'elenco completo delle operazioni
-eseguite alla chiusura di un processo è il seguente:
+memoria che stava usando, e così via; l'elenco completo delle operazioni
+eseguite alla chiusura di un processo è il seguente:
\begin{itemize*}
\item tutti i file descriptor sono chiusi;
\item viene memorizzato lo stato di terminazione del processo;
\cmd{init});
\item viene inviato il segnale \const{SIGCHLD} al processo padre (vedi
sez.~\ref{sec:sig_sigchld});
-\item se il processo è un leader di sessione ed il suo terminale di controllo
- è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
+\item se il processo è un leader di sessione ed il suo terminale di controllo
+ è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
processi del gruppo di \textit{foreground} e il terminale di controllo viene
disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
\item se la conclusione di un processo rende orfano un \textit{process
(vedi ancora sez.~\ref{sec:sess_ctrl_term}).
\end{itemize*}
-Oltre queste operazioni è però necessario poter disporre di un meccanismo
-ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
+Oltre queste operazioni è però necessario poter disporre di un meccanismo
+ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
scelto consiste nel riportare lo stato di terminazione (il cosiddetto
\textit{termination status}) al processo padre.
Nel caso di conclusione normale, abbiamo visto in
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
-caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
+caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala
-il programma non può specificare nessun \textit{exit status}, ed è il kernel
+il programma non può specificare nessun \textit{exit status}, ed è il kernel
che deve generare autonomamente il \textit{termination status} per indicare le
ragioni della conclusione anomala.
Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
quello che contraddistingue lo stato di chiusura del processo e viene
riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
-sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
+sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
secondo.
La scelta di riportare al padre lo stato di terminazione dei figli, pur
essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
-alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre potrebbe essere già
-terminato; si potrebbe avere cioè quello che si chiama un processo
+alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
+che sia così alla sua conclusione, dato che il padre potrebbe essere già
+terminato; si potrebbe avere cioè quello che si chiama un processo
\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
-termina, il kernel controlla se è il padre di altri processi in esecuzione: in
+venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
+termina, il kernel controlla se è il padre di altri processi in esecuzione: in
caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
-con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
-avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
+con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
+avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
cui riportare il suo stato di terminazione. Come verifica di questo
comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
-ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
+ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
[piccardi@selidor sources]$ ./forktest -c2 3
Process 1972: forking 3 child
Child 2, parent 1, exiting
Child 1, parent 1, exiting
\end{Verbatim}
-come si può notare in questo caso il processo padre si conclude prima dei
+come si può notare in questo caso il processo padre si conclude prima dei
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
-terminano, e come si può notare in questo caso, al contrario di quanto visto
+terminano, e come si può notare in questo caso, al contrario di quanto visto
in precedenza, essi riportano 1 come \acr{ppid}.
-Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
-perché non è detto che il padre possa ricevere immediatamente lo stato di
-terminazione, quindi il kernel deve comunque conservare una certa quantità di
+Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
+perché non è detto che il padre possa ricevere immediatamente lo stato di
+terminazione, quindi il kernel deve comunque conservare una certa quantità di
informazioni riguardo ai processi che sta terminando.
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
-processi che sono terminati, ma il cui stato di terminazione non è stato
+processi che sono terminati, ma il cui stato di terminazione non è stato
ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
restano presenti nella tabella dei processi ed in genere possono essere
identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
-il padre effettuerà la lettura dello stato di uscita anche questa
-informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
+il padre effettuerà la lettura dello stato di uscita anche questa
+informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
completamente conclusa.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
572 pts/0 R 0:00 ps T
\end{Verbatim}
%$
-e come si vede, dato che non si è fatto nulla per riceverne lo
+e come si vede, dato che non si è fatto nulla per riceverne lo
stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
sono stati terminati.
-La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
tenuta sempre presente quando si scrive un programma che deve essere mantenuto
in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
+sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
\index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
occupano comunque una voce nella tabella dei processi, che a lungo andare
potrebbe esaurirsi.
Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
-di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
-processi cui fa da padre, completandone la terminazione. Questo è quanto
+diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
+di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
+processi cui fa da padre, completandone la terminazione. Questo è quanto
avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
-\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
+\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
completarne la terminazione.
Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
-processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
-l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
terminare il processo che li ha generati, in modo che \cmd{init} possa
adottarli e provvedere a concluderne la terminazione.
di uscita}
\label{sec:proc_wait}
-Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
+Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
consiste nella creazione di programmi di tipo server, in cui un processo
principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli. Si è già sottolineato al paragrafo precedente come in questo
+processi figli. Si è già sottolineato al paragrafo precedente come in questo
caso diventi necessario gestire esplicitamente la conclusione dei figli onde
evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
le funzioni deputate a questo compito sono principalmente due, \funcd{wait} e
-\func{waitpid}. La prima, il cui prototipo è:
+\func{waitpid}. La prima, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\funcdecl{pid\_t wait(int *status)}
-Sospende il processo corrente finché un figlio non è uscito, o finché un
+Sospende il processo corrente finché un figlio non è uscito, o finché un
segnale termina il processo o chiama una funzione di gestione.
\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
- e -1 in caso di errore; \var{errno} può assumere i valori:
+ e -1 in caso di errore; \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}}
\end{functions}
\noindent
-è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
-processo figlio termina. Se un figlio è già terminato la funzione ritorna
-immediatamente, se più di un figlio è terminato occorre chiamare la funzione
-più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
+è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
+processo figlio termina. Se un figlio è già terminato la funzione ritorna
+immediatamente, se più di un figlio è terminato occorre chiamare la funzione
+più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato
nella variabile puntata da \param{status} e tutte le risorse del kernel
relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.
-Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
-figlio) permette di identificare qual è quello che è uscito.
+Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
+figlio) permette di identificare qual è quello che è uscito.
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
-all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
+all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
necessario attendere la conclusione di un processo specifico occorrerebbe
-predisporre un meccanismo che tenga conto dei processi già terminati, e
+predisporre un meccanismo che tenga conto dei processi già terminati, e
provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
sia ancora attivo.
Per questo motivo lo standard POSIX.1 ha introdotto la funzione
\funcd{waitpid} che effettua lo stesso servizio, ma dispone di una serie di
-funzionalità più ampie, legate anche al controllo di sessione (si veda
-sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
+funzionalità più ampie, legate anche al controllo di sessione (si veda
+sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
comportamento di \func{wait}\footnote{in effetti il codice
- \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
+ \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
\&status, 0)}.} si consiglia di utilizzare sempre questa funzione, il cui
-prototipo è:
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
Attende la conclusione di un processo figlio.
-\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
- è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
- -1 per un errore, nel qual caso \var{errno} assumerà i valori:
+\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
+ è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
+ -1 per un errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
- la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
- non è figlio del processo chiamante.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ non è figlio del processo chiamante.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
\end{functions}
-La prima differenza fra le due funzioni è che con \func{waitpid} si può
+La prima differenza fra le due funzioni è che con \func{waitpid} si può
specificare in maniera flessibile quale processo attendere, sulla base del
-valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
+valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
sono riportate anche le costanti definite per indicare alcuni di essi.
\hline
$<-1$& -- & Attende per un figlio il cui
\itindex{process~group} \textit{process group}
- (vedi sez.~\ref{sec:sess_proc_group}) è uguale
+ (vedi sez.~\ref{sec:sess_proc_group}) è uguale
al valore assoluto di \param{pid}. \\
$-1$&\const{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
questa maniera senza specificare nessuna opzione
- è equivalente a \func{wait}.\\
+ è equivalente a \func{wait}.\\
$ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui
\itindex{process~group} \textit{process group}
- (vedi sez.~\ref{sec:sess_proc_group}) è
+ (vedi sez.~\ref{sec:sess_proc_group}) è
uguale a quello del processo chiamante. \\
- $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
+ $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
al valore di \param{pid}.\\
\hline
\end{tabular}
\label{tab:proc_waidpid_pid}
\end{table}
-Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
+Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
funzione delle opportune opzioni tramite l'argomento \param{options}; questo
deve essere specificato come maschera binaria dei flag riportati nella prima
parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati fra
loro con un OR aritmetico. Nella seconda parte della stessa tabella si sono
riportati anche alcuni valori non standard specifici di Linux, che consentono
-un controllo più dettagliato per i processi creati con la system call generica
+un controllo più dettagliato per i processi creati con la system call generica
\func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente per la
gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
sez.~\ref{sec:thread_xxx}).
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
+ \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
terminato nessun processo figlio. \\
- \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
+ \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
\const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
fermato ha ripreso l'esecuzione.\footnotemark \\
\hline
L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
funzione qualora nessun figlio sia uscito (o non si siano verificate le altre
-condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
-valore nullo anziché positivo.\footnote{anche in questo caso un valore
- positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
+condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
+valore nullo anziché positivo.\footnote{anche in questo caso un valore
+ positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
ed un valore negativo un errore.}
Le altre due opzioni \const{WUNTRACED} e \const{WCONTINUED} consentono
Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
quando un processo figlio entra nello stato \textit{stopped}\footnote{in
- realtà viene notificato soltanto il caso in cui il processo è stato fermato
+ realtà viene notificato soltanto il caso in cui il processo è stato fermato
da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
- cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
+ cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
sez.~\ref{sec:xxx_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), mentre
con \const{WCONTINUED} la funzione ritorna quando un processo in stato
\textit{stopped} riprende l'esecuzione per la ricezione del segnale
-\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
+\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
dettagliato in sez.~\ref{sec:sess_ctrl_term}).
-La terminazione di un processo figlio (così come gli altri eventi osservabili
-con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
-di un programma e può avvenire in un qualunque momento. Per questo motivo,
+La terminazione di un processo figlio (così come gli altri eventi osservabili
+con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
+di un programma e può avvenire in un qualunque momento. Per questo motivo,
come accennato nella sezione precedente, una delle azioni prese dal kernel
-alla conclusione di un processo è quella di mandare un segnale di
+alla conclusione di un processo è quella di mandare un segnale di
\const{SIGCHLD} al padre. L'azione predefinita (si veda
-sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
+sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
generazione costituisce il meccanismo di comunicazione asincrona con cui il
-kernel avverte il processo padre che uno dei suoi figli è terminato.
+kernel avverte il processo padre che uno dei suoi figli è terminato.
-Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
-al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
+Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
+al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1
che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.}
e come da esso richiesto se \const{SIGCHLD} viene ignorato, o se si imposta il
sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano
\textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che
tutti i processi figli non sono terminati, dopo di che falliscono con un
-errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
+errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto
qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale
\const{SIGCHLD}.}
\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
+ 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
+ \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
in maniera anomala a causa di un segnale che non
- è stato catturato (vedi
+ è 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
+ 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
+ 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
+ \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
+ 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 è
+ \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
stato riavviato da un
\const{SIGCONT}.\footnotemark \\
\hline
\label{tab:proc_status_macro}
\end{table}
-\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
+\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
presente come estensione sia in Linux che in altri Unix, deve essere
- pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
+ pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
-\footnotetext{è presente solo a partire dal kernel 2.6.10.}
+\footnotetext{è presente solo a partire dal kernel 2.6.10.}
In generale in un programma non si vuole essere forzati ad attendere la
conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
la presenza di \index{zombie} \textit{zombie}).
-Per questo la modalità più comune di chiamare queste funzioni è quella di
+Per questo la modalità più comune di chiamare queste funzioni è quella di
utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
come gestire \const{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
-questo caso infatti, dato che il segnale è generato dalla terminazione di un
-figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
+questo caso infatti, dato che il segnale è generato dalla terminazione di un
+figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
terminazione del processo tramite il puntatore \param{status} (se non
-interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
+interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
restituito da entrambe le funzioni dipende dall'implementazione, ma
tradizionalmente alcuni bit (in genere 8) sono riservati per memorizzare lo
stato di uscita, e altri per indicare il segnale che ha causato la
-terminazione (in caso di conclusione anomala), uno per indicare se è stato
+terminazione (in caso di conclusione anomala), uno per indicare se è stato
generato un \itindex{core~dump} \textit{core dump}, ecc.\footnote{le
definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
questo file non deve mai essere usato direttamente, esso viene incluso
da \func{wait} o \func{waitpid}.
Si tenga conto che nel caso di conclusione anomala il valore restituito da
-\val{WTERMSIG} può essere confrontato con le costanti che identificano i
+\val{WTERMSIG} può essere confrontato con le costanti che identificano i
segnali definite in \file{signal.h} ed elencate in
tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
trattate in sez.~\ref{sec:sig_strsignal}.
-A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
+A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
stata introdotta una nuova funzione di attesa che consente di avere un
-controllo molto più preciso sui possibili cambiamenti di stato dei processi
-figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
-suo prototipo è:
+controllo molto più preciso sui possibili cambiamenti di stato dei processi
+figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
+suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
Attende la conclusione di un processo figlio.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
- nel qual caso \var{errno} assumerà i valori:
+ nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
- la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
- non è figlio del processo chiamante.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ non è figlio del processo chiamante.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
\end{functions}
Come per \func{waitpid} anche il comportamento di \func{waitid} viene
controllato dall'argomento \param{options}, da specificare come maschera
-binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
+binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
alcuni di questi siano identici come significato ed effetto ai precedenti di
tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
-in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
+in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
-\const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
+\const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
-processo in attesa di ricezione, così che una successiva chiamata possa di
+processo in attesa di ricezione, così che una successiva chiamata possa di
nuovo riceverne lo stato.
\begin{table}[!htb]
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
- \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
+ \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
+ \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
notificare.\\
- \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
+ \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
\const{WCONTINUED}& Ritorna quando un processo figlio che era stato
fermato ha ripreso l'esecuzione.\\
- \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
+ \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
che una successiva chiamata possa di nuovo riceverne
lo stato.\\
\hline
\end{table}
La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
-$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
-specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
+$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
+specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
ritorno della funzione occorre analizzare le informazioni che essa
restituisce; queste, al contrario delle precedenti \func{wait} e
\item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
\const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
\const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
- significato è, nell'ordine: uscita normale, terminazione da segnale,
+ significato è, nell'ordine: uscita normale, terminazione da segnale,
processo fermato, processo riavviato, processo terminato in \textit{core
dump}.
\end{basedescript}
Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
la lettura dello stato di terminazione di un processo, analoghe alle
precedenti ma che prevedono un ulteriore argomento attraverso il quale il
-kernel può restituire al padre informazioni sulle risorse (vedi
+kernel può restituire al padre informazioni sulle risorse (vedi
sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
\funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
*rusage)}
- È identica a \func{waitpid} sia per comportamento che per i valori degli
+ È identica a \func{waitpid} sia per comportamento che per i valori degli
argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
dal processo.
\funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
- Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
+ Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
ormai deprecata in favore di \func{wait4}.
\end{functions}
\noindent
-la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
+la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
utilizzata anche dalla funzione \func{getrusage} (vedi
sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
-processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
+processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
\label{sec:proc_exec}
-Abbiamo già detto che una delle modalità principali con cui si utilizzano i
-processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
+Abbiamo già detto che una delle modalità principali con cui si utilizzano i
+processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
processo chiama una di queste funzioni esso viene completamente sostituito dal
nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
\index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
corrente con un nuovo programma letto da disco.
-Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
-famiglia di funzioni) che possono essere usate per questo compito, in realtà
+Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
+famiglia di funzioni) che possono essere usate per questo compito, in realtà
(come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
-\funcd{execve}. Il prototipo di quest'ultima è:
+\funcd{execve}. Il prototipo di quest'ultima è:
\begin{prototype}{unistd.h}
{int execve(const char *filename, char *const argv[], char *const envp[])}
Esegue il programma contenuto nel file \param{filename}.
\bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
- qual caso \var{errno} può assumere i valori:
+ qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
- montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
+ \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
+ montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
\item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
- tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
- \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
+ \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
+ tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
+ \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
riconosciuto come tale, o compilato per un'altra architettura.
\item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
necessari per eseguirlo non esistono.
- \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
+ \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
processi.
- \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
- \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
+ \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
+ \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
interprete.
- \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
+ \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
riconoscibile.
- \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
+ \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
\errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
liste devono essere terminate da un puntatore nullo. I vettori degli
argomenti e dell'ambiente possono essere acceduti dal nuovo programma
-quando la sua funzione \func{main} è dichiarata nella forma
+quando la sua funzione \func{main} è dichiarata nella forma
\code{main(int argc, char *argv[], char *envp[])}.
Le altre funzioni della famiglia servono per fornire all'utente una serie di
linea di comando e l'ambiente ricevuti dal nuovo processo.
\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
- nel qual caso \var{errno} assumerà i valori visti in precedenza per
+ nel qual caso \var{errno} assumerà i valori visti in precedenza per
\func{execve}.}
\end{functions}
-Per capire meglio le differenze fra le funzioni della famiglia si può fare
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
-prima differenza riguarda le modalità di passaggio dei valori che poi andranno
-a costituire gli argomenti a linea di comando (cioè i valori di
+prima differenza riguarda le modalità di passaggio dei valori che poi andranno
+a costituire gli argomenti a linea di comando (cioè i valori di
\param{argv} e \param{argc} visti dalla funzione \func{main} del programma
chiamato).
-Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
+Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
\includecodesnip{listati/char_list.c}
che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
-per indicare il nome del file che contiene il programma che verrà eseguito.
+per indicare il nome del file che contiene il programma che verrà eseguito.
\begin{table}[!htb]
\footnotesize
\label{tab:proc_exec_scheme}
\end{table}
-La seconda differenza fra le funzioni riguarda le modalità con cui si
+La seconda differenza fra le funzioni riguarda le modalità con cui si
specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
indicano le due funzioni che replicano il comportamento della shell nello
specificare il comando da eseguire; quando l'argomento \param{file} non
contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
e viene eseguita automaticamente una ricerca fra i file presenti nella lista
di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
-viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
-relativo a permessi di accesso insufficienti (cioè l'esecuzione della
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
+relativo a permessi di accesso insufficienti (cioè l'esecuzione della
sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
non viene trovato nessun altro file viene finalmente restituito
\label{fig:proc_exec_relat}
\end{figure}
-La terza differenza è come viene passata la lista delle variabili di ambiente.
+La terza differenza è come viene passata la lista delle variabili di ambiente.
Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
di un vettore di parametri \var{envp[]} analogo a quello usato per gli
argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
l'ambiente.
Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
-\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
-lista delle più significative è la seguente:
+\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
+lista delle più significative è la seguente:
\begin{itemize*}
\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
(\acr{ppid});
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
\var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
% TODO ===========Importante=============
-% TODO questo sotto è incerto, verificare
+% TODO questo sotto è incerto, verificare
% TODO ===========Importante=============
\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
\end{itemize*}
-Una serie di proprietà del processo originale, che non avrebbe senso mantenere
+Una serie di proprietà del processo originale, che non avrebbe senso mantenere
in un programma che esegue un codice completamente diverso in uno spazio di
indirizzi totalmente indipendente e ricreato da zero, vengono perse con
l'esecuzione di \func{exec}; lo standard POSIX.1-2001 prevede che le seguenti
-proprietà non vengano preservate:
+proprietà non vengano preservate:
\begin{itemize*}
\item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
viene cancellato;
I segnali che sono stati impostati per essere ignorati nel processo chiamante
mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri
-segnali, ed in particolare quelli per i quali è stato installato un gestore
+segnali, ed in particolare quelli per i quali è stato installato un gestore
vengono impostati alla loro azione predefinita (vedi
-sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
+sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
\const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard
POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola
- implementazione, quella di Linux è di non modificare l'impostazione
+ implementazione, quella di Linux è di non modificare l'impostazione
precedente.}
Oltre alle precedenti che sono completamente generali e disponibili anche su
-altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
+altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
caratteristiche specifiche di Linux, che non vengono preservate
nell'esecuzione della funzione \func{exec}, queste sono:
\begin{itemize*}
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
\textit{close-on-exec} (vedi anche sez.~\ref{sec:file_fcntl}) per ciascun file
-descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
-restano aperti. Questo significa che il comportamento predefinito è che i file
+descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
+restano aperti. Questo significa che il comportamento predefinito è che i file
restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
\func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
-questo è fatto dalla funzione \func{opendir} (vedi
+questo è fatto dalla funzione \func{opendir} (vedi
sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
\itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
maniera trasparente all'utente.
Il comportamento della funzione in relazione agli identificatori relativi al
-controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
-qui è sufficiente anticipare (si faccia riferimento a
+controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
+qui è sufficiente anticipare (si faccia riferimento a
sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
file appartiene.
-Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
del programma per caricare le librerie necessarie ed effettuare il link
-dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
+dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
molto probabile che non il relativo supporto non sia disponibile.} Se il
-programma è in formato ELF per caricare le librerie dinamiche viene usato
+programma è in formato ELF per caricare le librerie dinamiche viene usato
l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
-stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
+stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
collegati con le \acr{glibc}.
Infine nel caso il file sia uno script esso deve iniziare con una linea nella
forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato
-deve essere un programma valido (binario, non un altro script) che verrà
+deve essere un programma valido (binario, non un altro script) che verrà
chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
filename}.\footnote{si tenga presente che con Linux quanto viene scritto
come \texttt{argomenti} viene passato all'interprete come un unico argomento
con una unica stringa di lunghezza massima di 127 caratteri e se questa
dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
- esegue la scansione della riga e la divide nei vari argomenti e se è troppo
+ esegue la scansione della riga e la divide nei vari argomenti e se è troppo
lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
vari comportamenti si trova su
\href{http://www.in-ulm.de/~mascheck/various/shebang/}
{\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
-Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
+Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
\func{wait} si effettua e verifica la conclusione dei processi. Tutte le
\label{sec:proc_access_id}
Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
- realtà già esistono estensioni di questo modello base, che lo rendono più
+ realtà già esistono estensioni di questo modello base, che lo rendono più
flessibile e controllabile, come le \itindex{capabilities}
\textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
per i file (vedi sez.~\ref{sec:file_ACL}) o il
\itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
- SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+ SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
\textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
a livello del kernel per modularizzare tutti i possibili controlli di
- accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
+ accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root},
-detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
+detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
il resto degli utenti, per i quali invece vengono effettuati i vari controlli
di accesso.
-Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
+Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
identificare uno specifico utente o un gruppo di utenti, per poi poter
controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
kernel nella gestione dei permessi di accesso.
-Dato che tutte le operazioni del sistema vengono compiute dai processi, è
+Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
-anche poter identificare chi è che ha lanciato un certo programma, e pertanto
-anche a ciascun processo dovrà essere associato un utente e un gruppo.
+anche poter identificare chi è che ha lanciato un certo programma, e pertanto
+anche a ciascun processo dovrà essere associato un utente e un gruppo.
Un semplice controllo di una corrispondenza fra identificativi non garantisce
-però sufficiente flessibilità per tutti quei casi in cui è necessario poter
+però sufficiente flessibilità per tutti quei casi in cui è necessario poter
disporre di privilegi diversi, o dover impersonare un altro utente per un
limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
-rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
+rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
\textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
\textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
filesystem}), secondo la situazione illustrata in
& Indicano gli ulteriori gruppi cui l'utente appartiene.\\
\hline
-- & \textit{saved} & \textsl{user-ID salvato}
- & È una copia dell'\acr{euid} iniziale.\\
+ & È una copia dell'\acr{euid} iniziale.\\
-- & '' & \textsl{group-ID salvato}
- & È una copia dell'\acr{egid} iniziale.\\
+ & È una copia dell'\acr{egid} iniziale.\\
\hline
\acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
& Indica l'utente effettivo per l'accesso al filesystem. \\
reale}: questi vengono impostati al login ai valori corrispondenti
all'utente con cui si accede al sistema (e relativo gruppo principale).
Servono per l'identificazione dell'utente e normalmente non vengono mai
-cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
+cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
-questa possibilità è usata proprio dal programma \cmd{login} che, una volta
+questa possibilità è usata proprio dal programma \cmd{login} che, una volta
completata la procedura di autenticazione, lancia una shell per la quale
imposta questi identificatori ai valori corrispondenti all'utente che entra
nel sistema.
Questi identificatori normalmente sono identici ai corrispondenti del gruppo
\textit{real} tranne nel caso in cui, come accennato in
-sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
+sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
-(il significato di questi bit è affrontato in dettaglio in
+(il significato di questi bit è affrontato in dettaglio in
sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
all'utente e al gruppo proprietari del file. Questo consente, per programmi in
-cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
+cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
di un altro (o dell'amministratore).
Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
\bodydesc{Queste funzioni non riportano condizioni di errore.}
\end{functions}
-In generale l'uso di privilegi superiori deve essere limitato il più
+In generale l'uso di privilegi superiori deve essere limitato il più
possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
un meccanismo che consenta ad un programma di rilasciare gli eventuali
maggiori privilegi necessari, una volta che si siano effettuate le operazioni
servano di nuovo.
Questo in Linux viene fatto usando altri due gruppi di identificatori, il
-\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
-SVr4, e previsto dallo standard POSIX quando è definita la costante
-\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
- del programma su altri Unix è buona norma controllare sempre la
- disponibilità di queste funzioni controllando se questa costante è
- definita.} il secondo gruppo è specifico di Linux e viene usato per
+\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
+SVr4, e previsto dallo standard POSIX quando è definita la costante
+\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
+ del programma su altri Unix è buona norma controllare sempre la
+ disponibilità di queste funzioni controllando se questa costante è
+ definita.} il secondo gruppo è specifico di Linux e viene usato per
migliorare la sicurezza con NFS.
L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
all'inizio dell'esecuzione di un nuovo programma.
L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
-un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
+un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
(torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
quali si sostituiscono per tutte le operazioni di verifica dei permessi
relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
cambiamento effettuato sugli identificatori effettivi viene automaticamente
-riportato su di essi, per cui in condizioni normali si può tranquillamente
+riportato su di essi, per cui in condizioni normali si può tranquillamente
ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
\subsection{Le funzioni di gestione degli identificatori dei processi}
\label{sec:proc_setuid}
-Le due funzioni più comuni che vengono usate per cambiare identità (cioè
+Le due funzioni più comuni che vengono usate per cambiare identità (cioè
utente e gruppo di appartenenza) ad un processo sono rispettivamente
\funcd{setuid} e \funcd{setgid}; come accennato in
sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
corrente.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
\end{functions}
-Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
+Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima; la seconda si comporta esattamente allo stesso modo facendo
riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
eventuali \textsl{group-ID supplementari} non vengono modificati.
-L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
+L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
+l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
\textit{saved}) vengono impostati al valore specificato da \param{uid},
altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
\errcode{EPERM}).
-Come accennato l'uso principale di queste funzioni è quello di poter
+Come accennato l'uso principale di queste funzioni è quello di poter
consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
viene gestito l'accesso al file \sysfile{/var/log/utmp}. In questo file viene
-registrato chi sta usando il sistema al momento corrente; chiaramente non può
+registrato chi sta usando il sistema al momento corrente; chiaramente non può
essere lasciato aperto in scrittura a qualunque utente, che potrebbe
falsificare la registrazione. Per questo motivo questo file (e l'analogo
\sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
il bit \acr{sgid} impostato.
Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
-situazione degli identificatori è la seguente:
+situazione degli identificatori è la seguente:
\begin{eqnarray*}
\label{eq:1}
\textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
-in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
-programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
-A questo punto il programma può eseguire una \code{setgid(getgid())} per
+in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
+programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
+A questo punto il programma può eseguire una \code{setgid(getgid())} per
impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
-\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
-non sarà possibile lanciare dal terminale programmi che modificano detto file,
+\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
+non sarà possibile lanciare dal terminale programmi che modificano detto file,
in tal caso infatti la situazione degli identificatori sarebbe:
\begin{eqnarray*}
\label{eq:2}
\end{eqnarray*}
e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
-aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
-\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
+\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
\acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
-funzione avrà successo e riporterà la situazione a:
+funzione avrà successo e riporterà la situazione a:
\begin{eqnarray*}
\label{eq:3}
\textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
\end{eqnarray*}
consentendo l'accesso a \sysfile{/var/log/utmp}.
-Occorre però tenere conto che tutto questo non è possibile con un processo con
+Occorre però tenere conto che tutto questo non è possibile con un processo con
i privilegi di amministratore, in tal caso infatti l'esecuzione di una
\func{setuid} comporta il cambiamento di tutti gli identificatori associati al
processo, rendendo impossibile riguadagnare i privilegi di amministratore.
-Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
+Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
ricorrere ad altre funzioni.
specificati da \param{rgid} e \param{egid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
\end{functions}
-La due funzioni sono analoghe ed il loro comportamento è identico; quanto
+La due funzioni sono analoghe ed il loro comportamento è identico; quanto
detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda
per il group-ID. I processi non privilegiati possono impostare solo i valori
del loro user-ID effettivo o reale; valori diversi comportano il fallimento
-della chiamata; l'amministratore invece può specificare un valore qualunque.
-Specificando un argomento di valore -1 l'identificatore corrispondente verrà
+della chiamata; l'amministratore invece può specificare un valore qualunque.
+Specificando un argomento di valore -1 l'identificatore corrispondente verrà
lasciato inalterato.
Con queste funzioni si possono scambiare fra loro gli user-ID reale e
-effettivo, e pertanto è possibile implementare un comportamento simile a
+effettivo, e pertanto è possibile implementare un comportamento simile a
quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
scambio.
-In questo caso però occorre porre molta attenzione quando si creano nuovi
+In questo caso però occorre porre molta attenzione quando si creano nuovi
processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
+questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
essere esplicitamente eliminato prima di porre in esecuzione un nuovo
-programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
+programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in
caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
e riottenere privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che
-non ne prevede la presenza, e quindi non è possibile usarla per correggere la
+non ne prevede la presenza, e quindi non è possibile usarla per correggere la
situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
che si imposta un qualunque valore diverso da quello dall'user-ID reale
corrente, l'user-ID salvato viene automaticamente uniformato al valore
corrente a \param{gid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore è \errval{EPERM}.}
+ di fallimento: l'unico errore è \errval{EPERM}.}
\end{functions}
Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
-valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
+valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
specificare qualunque valore. Queste funzioni sono usate per permettere
all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
\param{sgid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore è \errval{EPERM}.}
+ di fallimento: l'unico errore è \errval{EPERM}.}
\end{functions}
Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
si applica alla seconda per i group-ID. I processi non privilegiati possono
cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
-può specificare i valori che vuole; un valore di -1 per un qualunque argomento
+può specificare i valori che vuole; un valore di -1 per un qualunque argomento
lascia inalterato l'identificatore corrispondente.
Per queste funzioni esistono anche due controparti che permettono di leggere
corrente.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
- fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
+ fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
variabili di ritorno non sono validi.}
\end{functions}
Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
nessun privilegio. I valori sono restituiti negli argomenti, che vanno
-specificati come puntatori (è un altro esempio di
+specificati come puntatori (è un altro esempio di
\itindex{value~result~argument} \textit{value result argument}). Si noti che
queste funzioni sono le uniche in grado di leggere gli identificatori del
gruppo \textit{saved}.
Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
-controllo dell'accesso ai file. Come già accennato in
+controllo dell'accesso ai file. Come già accennato in
sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
identificatori, che in circostanze normali sono assolutamente equivalenti a
quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
ultimi viene immediatamente riportato su di essi.
-C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
-identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
+identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
ovviare ad un problema di sicurezza che si presenta quando si deve
implementare un server NFS.
Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
-file per assumere l'identità del singolo utente remoto, ma se questo viene
+file per assumere l'identità del singolo utente remoto, ma se questo viene
fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla
ricezione di eventuali segnali ostili da parte dell'utente di cui ha
-temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
+temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
ottengono i privilegi necessari per accedere ai file, mantenendo quelli
-originari per quanto riguarda tutti gli altri controlli di accesso, così che
+originari per quanto riguarda tutti gli altri controlli di accesso, così che
l'utente non possa inviare segnali al server NFS.
Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
processo corrente a \param{fsgid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
\end{functions}
\noindent queste funzioni hanno successo solo se il processo chiamante ha i
privilegi di amministratore o, per gli altri utenti, se il valore specificato
\label{sec:proc_setgroups}
Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
-gruppi supplementari cui un utente può appartenere. Ogni processo può avere
+gruppi supplementari cui un utente può appartenere. Ogni processo può avere
almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
- gruppi secondari può essere ottenuto con \func{sysconf} (vedi
+ gruppi secondari può essere ottenuto con \func{sysconf} (vedi
sez.~\ref{sec:sys_sysconf}), leggendo il parametro
\texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
ereditati dal processo padre e possono essere cambiati con queste funzioni.
La funzione che permette di leggere i gruppi supplementari associati ad un
-processo è \funcd{getgroups}; questa funzione è definita nello standard
-POSIX.1, ed il suo prototipo è:
+processo è \funcd{getgroups}; questa funzione è definita nello standard
+POSIX.1, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
Legge gli identificatori dei gruppi supplementari.
\bodydesc{La funzione restituisce il numero di gruppi letti in caso di
- successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
+ successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
i valori:
\begin{errlist}
\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
- \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
+ \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
minore del numero di gruppi supplementari del processo.
\end{errlist}}
\end{functions}
La funzione legge gli identificatori dei gruppi supplementari del processo sul
-vettore \param{list} di dimensione \param{size}. Non è specificato se la
+vettore \param{list} di dimensione \param{size}. Non è specificato se la
funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
specifica un valore di \param{size} uguale a 0 \param{list} non viene
modificato, ma si ottiene il numero di gruppi supplementari.
-Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
-ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
+Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
+ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
La funzione legge i gruppi supplementari dell'utente specificato da
\param{user}, eseguendo una scansione del database dei gruppi (si veda
sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di
-quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
-puntatore perché, qualora il valore specificato sia troppo piccolo, la
+quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
+puntatore perché, qualora il valore specificato sia troppo piccolo, la
funzione ritorna -1, passando indietro il numero dei gruppi trovati.
Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
possono essere usate solo se si hanno i privilegi di amministratore. La prima
-delle due è \funcd{setgroups}, ed il suo prototipo è:
+delle due è \funcd{setgroups}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
Imposta i gruppi supplementari del processo.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà i valori:
+ fallimento, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
+ \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
massimo consentito.
\end{errlist}}
\end{functions}
La funzione imposta i gruppi supplementari del processo corrente ai valori
specificati nel vettore passato con l'argomento \param{list}, di dimensioni
-date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
-un parametro di sistema, che può essere ricavato con le modalità spiegate in
+date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
+un parametro di sistema, che può essere ricavato con le modalità spiegate in
sez.~\ref{sec:sys_characteristics}.
Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
-un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
+un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
Inizializza la lista dei gruppi supplementari.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
- \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
+ fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
+ \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
per allocare lo spazio per informazioni dei gruppi.}
\end{functions}
La funzione esegue la scansione del database dei gruppi (usualmente
-\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
+\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
\param{group}, infine imposta questa lista per il processo corrente usando
\func{setgroups}. Si tenga presente che sia \func{setgroups} che
\func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
-è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
-compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
+è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
+compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
scrivere codice portabile.
-\section{La gestione della priorità dei processi}
+\section{La gestione della priorità dei processi}
\label{sec:proc_priority}
-In questa sezione tratteremo più approfonditamente i meccanismi con il quale
+In questa sezione tratteremo più approfonditamente i meccanismi con il quale
lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
-gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
-per l'accesso a disco) divenute disponibili con i kernel più recenti.
+gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
+per l'accesso a disco) divenute disponibili con i kernel più recenti.
\subsection{I meccanismi di \textit{scheduling}}
\itindbeg{scheduler}
La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
-il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
+il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
ed oggetto di numerose ricerche; in generale essa dipende in maniera
essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
cui non esiste un meccanismo che sia valido per tutti gli usi.
-La caratteristica specifica di un sistema multitasking come Linux è quella del
+La caratteristica specifica di un sistema multitasking come Linux è quella del
cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
multitasking}: questo significa che al contrario di altri sistemi (che usano
invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
quando la CPU deve essere passata ad un altro processo. Come accennato in
sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
-apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
+apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
distribuire al meglio il tempo di CPU fra i vari processi.
-La cosa è resa ancora più complicata dal fatto che con le architetture
-multi-processore si deve anche scegliere quale sia la CPU più opportuna da
-utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
+La cosa è resa ancora più complicata dal fatto che con le architetture
+multi-processore si deve anche scegliere quale sia la CPU più opportuna da
+utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
- un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
+ un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
banale.} Tutto questo comunque appartiene alle sottigliezze
dell'implementazione del kernel; dal punto di vista dei programmi che girano
-in user space, anche quando si hanno più processori (e dei processi che sono
+in user space, anche quando si hanno più processori (e dei processi che sono
eseguiti davvero in contemporanea), le politiche di scheduling riguardano
semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
-assegnazione sarà governata dai meccanismi di scelta delle priorità che
+assegnazione sarà governata dai meccanismi di scelta delle priorità che
restano gli stessi indipendentemente dal numero di processori.
Si tenga conto poi che i processi non devono solo eseguire del codice: ad
esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
-tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
+tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
kernel provvedere a mettere in esecuzione un altro processo.
-Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
-processo, in Linux un processo può trovarsi in uno degli stati riportati in
+Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
+processo, in Linux un processo può trovarsi in uno degli stati riportati in
tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
\textbf{Runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
-sia la sua priorità, un processo non potrà mai essere messo in esecuzione
+sia la sua priorità, un processo non potrà mai essere messo in esecuzione
fintanto che esso si trova in uno qualunque degli altri stati.
\begin{table}[htb]
\textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
\hline
\hline
- \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
- essere eseguito (cioè è in attesa che gli
+ \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+ essere eseguito (cioè è in attesa che gli
venga assegnata la CPU).\\
- \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
- risposta dal sistema, ma può essere
+ \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
+ risposta dal sistema, ma può essere
interrotto da un segnale.\\
- \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
+ \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
attesa di un risposta dal sistema (in
- genere per I/O), e non può essere
+ genere per I/O), e non può essere
interrotto in nessuna circostanza.\\
- \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
- \const{SIGSTOP}, o è tracciato.\\
- \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
- suo stato di terminazione non è ancora
+ \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
+ \const{SIGSTOP}, o è tracciato.\\
+ \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+ suo stato di terminazione non è ancora
stato letto dal padre.\\
\textbf{Killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2.6.25, sostanzialmente identico
all'\textbf{Uninterrutible Sleep} con la
- sola differenza che il processo può
+ sola differenza che il processo può
terminato con \const{SIGKILL} (usato per
- lo più per NFS).\\
+ lo più per NFS).\\
\hline
\end{tabular}
\caption{Elenco dei possibili stati di un processo in Linux, nella colonna
- \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
+ \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
\cmd{ps} nell'omonimo campo.}
\label{tab:proc_proc_states}
\end{table}
-Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
+Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
risorse che sono necessarie per l'esecuzione di un programma, e a seconda
-dello scopo del programma non è detto neanche che sia la più importante (molti
-programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
-non è affatto detto che dare ad un programma la massima priorità di esecuzione
+dello scopo del programma non è detto neanche che sia la più importante (molti
+programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
+non è affatto detto che dare ad un programma la massima priorità di esecuzione
abbia risultati significativi in termini di prestazioni.
Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
-sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
-\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
+sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
+\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando
-un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
-alla fine, anche un processo con priorità iniziale molto bassa, finisce per
-avere una priorità sufficiente per essere eseguito.
+un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
+alla fine, anche un processo con priorità iniziale molto bassa, finisce per
+avere una priorità sufficiente per essere eseguito.
-Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
- assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
-alla normale priorità dinamica), per tenere conto dei sistemi
+Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
+ assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
+alla normale priorità dinamica), per tenere conto dei sistemi
real-time,\footnote{per sistema real-time si intende un sistema in grado di
eseguire operazioni in un tempo ben determinato; in genere si tende a
- distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
+ distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
esecuzione di un programma siano determinabili con certezza assoluta (come
nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
- occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
+ occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
processi che devono essere eseguiti in un determinato momento non debbano
-aspettare la conclusione di altri che non hanno questa necessità.
+aspettare la conclusione di altri che non hanno questa necessità.
-Il concetto di priorità assoluta dice che quando due processi si contendono
-l'esecuzione, vince sempre quello con la priorità assoluta più alta.
+Il concetto di priorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta.
Ovviamente questo avviene solo per i processi che sono pronti per essere
-eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
-genere indicata con un numero intero, ed un valore più alto comporta una
-priorità maggiore. Su questa politica di scheduling torneremo in
+eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
+genere indicata con un numero intero, ed un valore più alto comporta una
+priorità maggiore. Su questa politica di scheduling torneremo in
sez.~\ref{sec:proc_real_time}.
-In generale quello che succede in tutti gli Unix moderni è che ai processi
-normali viene sempre data una priorità assoluta pari a zero, e la decisione di
-assegnazione della CPU è fatta solo con il meccanismo tradizionale della
-priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
-assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
-priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
+In generale quello che succede in tutti gli Unix moderni è che ai processi
+normali viene sempre data una priorità assoluta pari a zero, e la decisione di
+assegnazione della CPU è fatta solo con il meccanismo tradizionale della
+priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
+assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
+priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
bisogno della CPU.
A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
sono state introdotte delle varianti specifiche.} l'unico meccanismo di
-scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
-solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
+scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
+solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
nella programmazione. Come accennato in Linux i processi ordinari hanno tutti
-una priorità assoluta nulla; quello che determina quale, fra tutti i processi
-in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
-\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
- \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
+una priorità assoluta nulla; quello che determina quale, fra tutti i processi
+in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
+\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
+ \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
varia nel corso dell'esecuzione di un processo.
-Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
+Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
dipende strettamente dalla versione di kernel; in particolare a partire
- dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
+ dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
- ed è stata anche introdotta la possibilità di usare diversi algoritmi,
- selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
- all'avvio (addirittura è stato ideato un sistema modulare che permette di
- cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
-ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
+ ed è stata anche introdotta la possibilità di usare diversi algoritmi,
+ selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
+ all'avvio (addirittura è stato ideato un sistema modulare che permette di
+ cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
+ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
-viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
+viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
calcolata dallo scheduler a partire da un valore iniziale che viene
-\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
-ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
+\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
+ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
dinamica e la conseguente scelta di quale processo mettere in esecuzione
- avviene con un algoritmo molto più complicato, che tiene conto anche della
- \textsl{interattività} del processo, utilizzando diversi fattori, questa è
+ avviene con un algoritmo molto più complicato, che tiene conto anche della
+ \textsl{interattività} del processo, utilizzando diversi fattori, questa è
una brutale semplificazione per rendere l'idea del funzionamento, per una
- trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
+ trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
funzionamento dello scheduler si legga il quarto capitolo di
\cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
tutti i processi in stato \textbf{Runnable}, quello che ha il valore di
-priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
- del valore numerico ad esse associato è infatti invertito, un valore più
- basso significa una priorità maggiore.} Il fatto che questo valore venga
+priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
+ del valore numerico ad esse associato è infatti invertito, un valore più
+ basso significa una priorità maggiore.} Il fatto che questo valore venga
diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
-significa che la priorità dei processi che non ottengono l'uso del processore
-viene progressivamente incrementata, così che anche questi alla fine hanno la
-possibilità di essere eseguiti.
+significa che la priorità dei processi che non ottengono l'uso del processore
+viene progressivamente incrementata, così che anche questi alla fine hanno la
+possibilità di essere eseguiti.
Sia la dimensione della \textit{time-slice} che il valore di partenza della
-priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
-\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
+priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
+\textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
che ciascun processo si porta dietro, essa viene ereditata dai processi
figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
- \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
+ \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
questo parametro sta nel fatto che generalmente questo viene usato per
-\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
+\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
confronti degli altri. I processi infatti vengono creati dal sistema con un
-valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
-specificando un valore positivo si avrà una \textit{time-slice} più breve ed
-un valore di priorità dinamica iniziale più alto, mentre un valore negativo
-darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
-iniziale più basso.
+valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
+specificando un valore positivo si avrà una \textit{time-slice} più breve ed
+un valore di priorità dinamica iniziale più alto, mentre un valore negativo
+darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
+iniziale più basso.
Esistono diverse funzioni che consentono di modificare la \textit{niceness} di
-un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
-corrente, il suo prototipo è:
+un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
+corrente, il suo prototipo è:
\begin{prototype}{unistd.h}
{int nice(int inc)}
Aumenta il valore di \var{nice} per il processo corrente.
\bodydesc{La funzione ritorna zero o il nuovo valore di \var{nice} in caso
- di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
+ di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
i valori:
\begin{errlist}
\item[\errcode{EPERM}] non si ha il permesso di specificare un valore
\end{prototype}
L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
-di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
+di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
\const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
-$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
- kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
- anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
-un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
+$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
+ kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
+ anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
+un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
il risultato nell'intervallo consentito. Valori positivi comportano maggiore
-\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
-comportano invece un aumento della priorità. Con i kernel precedenti il
+\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
+comportano invece un aumento della priorità. Con i kernel precedenti il
2.6.12 solo l'amministratore\footnote{o un processo con la
\itindex{capabilities} \textit{capability} \const{CAP\_SYS\_NICE}, vedi
- sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
-di \param{inc} che permettono di aumentare la priorità di un processo, a
-partire da questa versione è consentito anche agli utenti normali alzare
-(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
+ sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
+di \param{inc} che permettono di aumentare la priorità di un processo, a
+partire da questa versione è consentito anche agli utenti normali alzare
+(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
di \var{nice} del processo; tuttavia la system call di Linux non segue questa
convenzione e restituisce sempre 0 in caso di successo e $-1$ in caso di
-errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
+errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
comporta una confusione con una eventuale condizione di errore. La system call
originaria inoltre non consente, se non dotati di adeguati privilegi, di
diminuire un valore di \var{nice} precedentemente innalzato.
Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
risultato dalla system call, violando lo standard, per cui per ottenere il
nuovo valore occorreva una successiva chiamata alla funzione
-\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
-reimplementata e non viene più chiamata la omonima system call, con questa
+\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
+reimplementata e non viene più chiamata la omonima system call, con questa
versione viene restituito come valore di ritorno il valore di \var{nice}, come
richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno
\func{setpriority}, che tratteremo a breve.} In questo caso l'unico modo
-per rilevare in maniera affidabile una condizione di errore è quello di
+per rilevare in maniera affidabile una condizione di errore è quello di
azzerare \var{errno} prima della chiamata della funzione e verificarne il
valore quando \func{nice} restituisce $-1$.
Per leggere il valore di \textit{nice} di un processo occorre usare la
-funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
+funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
\begin{prototype}{sys/resource.h}
{int getpriority(int which, int who)}
Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
- \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori:
+ \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
\param{which} e \param{who}.
- \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
+ \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
\end{errlist}}
\end{prototype}
-\noindent nelle vecchie versioni può essere necessario includere anche
-\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
-librerie, ma è comunque utile per portabilità.
+\noindent nelle vecchie versioni può essere necessario includere anche
+\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
+librerie, ma è comunque utile per portabilità.
La funzione permette, a seconda del valore di \param{which}, di leggere la
-priorità di un processo, di un gruppo di processi (vedi
+priorità di un processo, di un gruppo di processi (vedi
sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente
valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority};
un valore nullo di quest'ultimo indica il processo, il gruppo di processi o
\label{tab:proc_getpriority}
\end{table}
-La funzione restituisce la priorità più alta (cioè il valore più basso) fra
-quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
-possibile, per poter rilevare una condizione di errore è necessario cancellare
+La funzione restituisce la priorità più alta (cioè il valore più basso) fra
+quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
+possibile, per poter rilevare una condizione di errore è necessario cancellare
sempre \var{errno} prima della chiamata alla funzione per verificare che essa
resti uguale a zero.
-Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
-impostare la priorità di uno o più processi; il suo prototipo è:
+Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
+impostare la priorità di uno o più processi; il suo prototipo è:
\begin{prototype}{sys/resource.h}
{int setpriority(int which, int who, int prio)}
- Imposta la priorità per l'insieme dei processi specificati.
+ Imposta la priorità per l'insieme dei processi specificati.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
\param{which} e \param{who}.
- \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
- \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
+ \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
+ \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
sufficienti privilegi.
\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
- cercato di modificare la priorità di un processo di un altro utente.
+ cercato di modificare la priorità di un processo di un altro utente.
\end{errlist}}
\end{prototype}
-La funzione imposta la priorità al valore specificato da \param{prio} per
+La funzione imposta la priorità al valore specificato da \param{prio} per
tutti i processi indicati dagli argomenti \param{which} e \param{who}. In
questo caso come valore di \param{prio} deve essere specificato il valore di
\textit{nice} da assegnare, e non un incremento (positivo o negativo) come nel
\var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
\textit{nice} valido.
-Si tenga presente che solo l'amministratore\footnote{o più precisamente un
+Si tenga presente che solo l'amministratore\footnote{o più precisamente un
processo con la \itindex{capabilities} \textit{capability}
\const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
-possibilità di modificare arbitrariamente le priorità di qualunque
-processo. Un utente normale infatti può modificare solo la priorità dei suoi
+possibilità di modificare arbitrariamente le priorità di qualunque
+processo. Un utente normale infatti può modificare solo la priorità dei suoi
processi ed in genere soltanto diminuirla. Fino alla versione di kernel
2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
sistemi derivati da SysV veniva richiesto che l'user-ID reale o quello
effettivo del processo chiamante corrispondessero all'user-ID reale (e solo a
-quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
-versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
-da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
+quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
+versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
+da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
l'user-ID effettivo.
-Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
-ordinari poter aumentare la priorità dei propri processi specificando un
-valore di \param{prio} negativo. Questa operazione non è possibile però in
-maniera indiscriminata, ed in particolare può essere effettuata solo
+Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
+ordinari poter aumentare la priorità dei propri processi specificando un
+valore di \param{prio} negativo. Questa operazione non è possibile però in
+maniera indiscriminata, ed in particolare può essere effettuata solo
nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
(torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
\label{sec:proc_real_time}
Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
-le priorità assolute per permettere la gestione di processi real-time. In
-realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
+le priorità assolute per permettere la gestione di processi real-time. In
+realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
-processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
- siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
+processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
+ siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
- direttamente qualora ci sia la necessità di avere un processo con priorità
- più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
+ direttamente qualora ci sia la necessità di avere un processo con priorità
+ più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
\itindex{page~fault} \textit{page fault} si possono avere ritardi non
-previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
+previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
funzioni di controllo della memoria virtuale (vedi
-sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
+sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
Nonostante questo, ed in particolare con una serie di miglioramenti che sono
stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
- che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
+ che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
\textit{real-time} estendendo il concetto di \textit{preemption} alle
- operazioni dello stesso kernel; esistono vari livelli a cui questo può
+ operazioni dello stesso kernel; esistono vari livelli a cui questo può
essere fatto, ottenibili attivando in fase di compilazione una fra le
opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
- e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
-approssimazione di sistema real-time usando le priorità assolute; occorre
-farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
-e questo finisce in un loop infinito, nessun altro processo potrà essere
-eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
-tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
-sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
-che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
-massima priorità assoluta, in modo da poter essere comunque in grado di
+ e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
+approssimazione di sistema real-time usando le priorità assolute; occorre
+farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
+e questo finisce in un loop infinito, nessun altro processo potrà essere
+eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
+tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
+sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
+che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
+massima priorità assoluta, in modo da poter essere comunque in grado di
rientrare nel sistema.
-Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
-esecuzione prima di ogni processo normale. In caso di più processi sarà
-eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
-processi con la stessa priorità assoluta questi vengono tenuti in una coda e
+Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
+esecuzione prima di ogni processo normale. In caso di più processi sarà
+eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
+processi con la stessa priorità assoluta questi vengono tenuti in una coda e
tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
-vengono gestiti questi processi dipende dalla politica di scheduling che si è
+vengono gestiti questi processi dipende dalla politica di scheduling che si è
scelta; lo standard ne prevede due:
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
\item[\textsf{FIFO}] \textit{First In First Out}. Il processo viene eseguito
fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si
- blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
- processo viene interrotto da uno a priorità più alta esso resterà in cima
- alla lista e sarà il primo ad essere eseguito quando i processi a priorità
- più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
- posto in coda alla lista (ed altri processi con la stessa priorità potranno
+ blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
+ processo viene interrotto da uno a priorità più alta esso resterà in cima
+ alla lista e sarà il primo ad essere eseguito quando i processi a priorità
+ più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
+ posto in coda alla lista (ed altri processi con la stessa priorità potranno
essere eseguiti).
-\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
+\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
a quello precedente, con la sola differenza che ciascun processo viene
eseguito al massimo per un certo periodo di tempo (la cosiddetta
\textit{time-slice}) dopo di che viene automaticamente posto in fondo alla
- coda dei processi con la stessa priorità. In questo modo si ha comunque una
+ coda dei processi con la stessa priorità. In questo modo si ha comunque una
esecuzione a turno di tutti i processi, da cui il nome della politica. Solo
- i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
+ i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
\textsl{girotondo}.
\end{basedescript}
Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
le politiche di scheduling, passando da real-time a ordinarie o viceversa, che
-di specificare, in caso di politiche real-time, la eventuale priorità statica;
-la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
+di specificare, in caso di politiche real-time, la eventuale priorità statica;
+la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
- Imposta priorità e politica di scheduling.
+ Imposta priorità e politica di scheduling.
\bodydesc{La funzione ritorna 0 in caso di successo e $-$1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori:
+ errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
- relativo valore di \param{p} non è valido.
+ relativo valore di \param{p} non è valido.
\item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
politica richiesta.
\end{errlist}}
La funzione esegue l'impostazione per il processo specificato dall'argomento
\param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
-processo corrente. La politica di scheduling è specificata
+processo corrente. La politica di scheduling è specificata
dall'argomento \param{policy} i cui possibili valori sono riportati in
tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
politiche real-time, quella bassa le politiche ordinarie. Un valore negativo
\const{SCHED\_OTHER}& Scheduling ordinario.\\
\const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di
lavoro \textit{CPU intensive}.\footnotemark\\
- \const{SCHED\_IDLE} & Scheduling di priorità estremamente
+ \const{SCHED\_IDLE} & Scheduling di priorità estremamente
bassa.\footnotemark\\
\hline
\end{tabular}
\footnotetext[44]{introdotto con il kernel 2.6.16.}
\footnotetext{introdotto con il kernel 2.6.23.}
-Con le versioni più recenti del kernel sono state introdotte anche delle
+Con le versioni più recenti del kernel sono state introdotte anche delle
varianti sulla politica di scheduling tradizionale per alcuni carichi di
lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
devono essere usate se si vogliono scrivere programmi portabili.
-La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
+La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
-delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
-interattività che mira a favorire i processi che si svegliano dallo stato di
+delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
+interattività che mira a favorire i processi che si svegliano dallo stato di
\textbf{Sleep}.\footnote{cosa che accade con grande frequenza per i processi
interattivi, dato che essi sono per la maggior parte del tempo in attesa di
dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di
\textit{nice}.
-La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
-si desidera siano eseguiti con la più bassa priorità possibile, ancora più
+La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
+si desidera siano eseguiti con la più bassa priorità possibile, ancora più
bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
-può utilizzare per processi che devono essere eseguiti se non c'è niente altro
+può utilizzare per processi che devono essere eseguiti se non c'è niente altro
da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
-avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
+avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
percentuale molto bassa.
-Qualora si sia richiesta una politica real-time il valore della priorità
+Qualora si sia richiesta una politica real-time il valore della priorità
statica viene impostato attraverso la struttura \struct{sched\_param},
riportata in fig.~\ref{fig:sig_sched_param}, il cui solo campo attualmente
-definito è \var{sched\_priority}. Il campo deve contenere il valore della
-priorità statica da assegnare al processo; lo standard prevede che questo
+definito è \var{sched\_priority}. Il campo deve contenere il valore della
+priorità statica da assegnare al processo; lo standard prevede che questo
debba essere assegnato all'interno di un intervallo fra un massimo ed un
minimo che nel caso di Linux sono rispettivamente 1 e 99.
\end{figure}
I processi con politica di scheduling ordinaria devono sempre specificare un
-valore nullo di \var{sched\_priority} altrimenti si avrà un errore
+valore nullo di \var{sched\_priority} altrimenti si avrà un errore
\errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la
-priorità dinamica determinata dal valore di \textit{nice}, che deve essere
+priorità dinamica determinata dal valore di \textit{nice}, che deve essere
impostato con le funzioni viste in precedenza.
Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
-priorità statica possano essere ottenuti, per ciascuna delle politiche di
+priorità statica possano essere ottenuti, per ciascuna delle politiche di
scheduling \textit{real-time}, tramite le due funzioni
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
\headdecl{sched.h}
\funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
- massimo della priorità statica per la politica di scheduling \param{policy}.
+ massimo della priorità statica per la politica di scheduling \param{policy}.
\funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
- della priorità statica per la politica di scheduling \param{policy}.
+ della priorità statica per la politica di scheduling \param{policy}.
- \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
+ \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
+ e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
+ \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
\end{errlist}}
\end{functions}
Si tenga presente che quando si imposta una politica di scheduling real-time
-per un processo o se ne cambia la priorità statica questo viene messo in cima
-alla lista dei processi con la stessa priorità; questo comporta che verrà
-eseguito subito, interrompendo eventuali altri processi con la stessa priorità
+per un processo o se ne cambia la priorità statica questo viene messo in cima
+alla lista dei processi con la stessa priorità; questo comporta che verrà
+eseguito subito, interrompendo eventuali altri processi con la stessa priorità
in quel momento in esecuzione.
-Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
+Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
esegue sempre il primo della lista, mentre un nuovo processo che torna in
stato \textbf{Runnable} viene sempre inserito in coda alla lista. Se la
-politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
+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}
-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.
+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.
-Solo un processo con i privilegi di amministratore\footnote{più precisamente
- con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
- sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
+Solo un processo con i privilegi di amministratore\footnote{più precisamente
+ con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
+ sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
-\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
-processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
+\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
+processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
processo chiamante corrisponda all'user-ID reale o effettivo del processo
indicato con \param{pid}.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
-real-time o modificare la eventuale priorità statica di un loro processo. A
-partire da questa versione è divenuto possibile anche per gli utenti normali
-usare politiche real-time fintanto che la priorità assoluta che si vuole
-impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
+real-time o modificare la eventuale priorità statica di un loro processo. A
+partire da questa versione è divenuto possibile anche per gli utenti normali
+usare politiche real-time fintanto che la priorità assoluta che si vuole
+impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. Unica eccezione a questa
-possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
+possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
politica di scheduling indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
-politica real-time, un utente può sempre, indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
+\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
+politica real-time, un utente può sempre, indipendentemente dal valore di
+\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
ordinaria.
-Se si intende operare solo sulla priorità statica di un processo si possono
+Se si intende operare solo sulla priorità statica di un processo si possono
usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che
consentono rispettivamente di impostarne e leggerne il valore, i loro
prototipi sono:
\headdecl{sched.h}
\funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
- Imposta la priorità statica del processo \param{pid}.
+ Imposta la priorità statica del processo \param{pid}.
\funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
- Legge la priorità statica del processo \param{pid}.
+ Legge la priorità statica del processo \param{pid}.
\bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
- caso di errore, nel qual caso \var{errno} può assumere i valori:
+ caso di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
\end{functions}
L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
-applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
+applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
argomento \param{policy} uguale a -1. Come per \func{sched\_setscheduler}
specificando 0 come valore dell'argomento \param{pid} si opera sul processo
-corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
+corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
politica ordinaria essa ha senso soltanto per quelli real-time, dato che per i
-primi la priorità statica può essere soltanto nulla. La disponibilità di
-entrambe le funzioni può essere verificata controllando la macro
-\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
+primi la priorità statica può essere soltanto nulla. La disponibilità di
+entrambe le funzioni può essere verificata controllando la macro
+\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
\file{sched.h}.
-Se invece si vuole sapere quale è politica di scheduling di un processo si può
-usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
+Se invece si vuole sapere quale è politica di scheduling di un processo si può
+usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
\begin{prototype}{sched.h}
{int sched\_getscheduler(pid\_t pid)}
Legge la politica di scheduling per il processo \param{pid}.
\bodydesc{La funzione ritorna la politica di scheduling in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
+ e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
La funzione restituisce il valore, secondo quanto elencato in
tab.~\ref{tab:proc_sched_policy}, della politica di scheduling per il processo
-specificato; se l'argomento \param{pid} è nullo viene restituito il valore
+specificato; se l'argomento \param{pid} è nullo viene restituito il valore
relativo al processo chiamante.
L'ultima funzione che permette di leggere le informazioni relative ai processi
-real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
+real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
lunghezza della \textit{time-slice} usata dalla politica \textit{round robin};
-il suo prototipo è:
+il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
\param{tp} la durata della \textit{time-slice} per il processo \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{ENOSYS}] la system call non è stata implementata.
+ \item[\errcode{ENOSYS}] la system call non è stata implementata.
\end{errlist}}
\end{prototype}
La funzione restituisce il valore dell'intervallo di tempo usato per la
politica \textit{round robin} in una struttura \struct{timespec}, (la cui
-definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
-dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
+definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
+dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
specificare il PID di un processo reale.
-Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
+Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
consentire agli altri processi di essere eseguiti; la funzione che consente di
-fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
+fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
\begin{prototype}{sched.h}
{int sched\_yield(void)}
\end{prototype}
Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling
-real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
-da essere rimesso in coda alla lista dei processi con la stessa priorità per
-permettere ad un altro di essere eseguito; se però il processo è l'unico ad
-essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
+real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
+da essere rimesso in coda alla lista dei processi con la stessa priorità per
+permettere ad un altro di essere eseguito; se però il processo è l'unico ad
+essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere
-l'esecuzione degli altri processi con pari priorità quando la sezione più
-urgente è finita.
+l'esecuzione degli altri processi con pari priorità quando la sezione più
+urgente è finita.
-La funzione può essere utilizzata anche con processi che usano lo scheduling
-ordinario, ma in questo caso il comportamento non è ben definito, e dipende
+La funzione può essere utilizzata anche con processi che usano lo scheduling
+ordinario, ma in questo caso il comportamento non è ben definito, e dipende
dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi
-venissero messi in fondo alla coda di quelli attivi, con la possibilità di
+venissero messi in fondo alla coda di quelli attivi, con la possibilità di
essere rimessi in esecuzione entro breve tempo, con l'introduzione del
-\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
+\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
processo che chiama la funzione viene inserito nella lista dei processi
-inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
+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}.}
\label{sec:proc_sched_multiprocess}
Infine con il supporto dei sistemi multiprocessore sono state introdotte delle
-funzioni che permettono di controllare in maniera più dettagliata la scelta di
+funzioni che permettono di controllare in maniera più dettagliata la scelta di
quale processore utilizzare per eseguire un certo programma. Uno dei problemi
-che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
-\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
+che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
+\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
scheduler, quando riavvia un processo precedentemente interrotto scegliendo il
primo processore disponibile, lo faccia eseguire da un processore diverso
rispetto a quello su cui era stato eseguito in precedenza. Se il processo
di frequente con i kernel della seria 2.4.x) si ha l'\textsl{effetto
ping-pong}.
-Questo tipo di comportamento può generare dei seri problemi di prestazioni;
+Questo tipo di comportamento può generare dei seri problemi di prestazioni;
infatti tutti i processori moderni utilizzano una memoria interna (la
-\textit{cache}) contenente i dati più usati, che permette di evitare di
-eseguire un accesso (molto più lento) alla memoria principale sulla scheda
-madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
-del processore, ma è ovvio che questo può essere vero solo per un processore
-alla volta, perché in presenza di più copie degli stessi dati su più
+\textit{cache}) contenente i dati più usati, che permette di evitare di
+eseguire un accesso (molto più lento) alla memoria principale sulla scheda
+madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
+del processore, ma è ovvio che questo può essere vero solo per un processore
+alla volta, perché in presenza di più copie degli stessi dati su più
processori, non si potrebbe determinare quale di questi ha la versione dei
dati aggiornata rispetto alla memoria principale.
Questo comporta che quando un processore inserisce un dato nella sua cache,
tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
-questa operazione è molto costosa in termini di prestazioni. Il problema
+questa operazione è molto costosa in termini di prestazioni. Il problema
diventa serio quando si verifica l'\textsl{effetto ping-pong}, in tal caso
infatti un processo \textsl{rimbalza} continuamente da un processore all'altro
e si ha una continua invalidazione della cache, che non diventa mai
\itindbeg{CPU~affinity}
-Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
- di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
+Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
+ di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
un processo possa essere assegnato per l'esecuzione sempre allo stesso
processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa
\textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong era
-comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
-risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
+comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
+risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
stesso processore.
-In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
+In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
sempre eseguito dallo stesso processore,\footnote{quella che viene detta
\textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
non un requisito assoluto.} e per poter risolvere questo tipo di
problematiche nei nuovi kernel\footnote{le due system call per la gestione
della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, e le
- funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
+ funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
l'opportuna infrastruttura ed una nuova system call che permette di impostare
su quali processori far eseguire un determinato processo attraverso una
-\textsl{maschera di affinità}. La corrispondente funzione di libreria è
-\funcd{sched\_setaffinity} ed il suo prototipo è:
+\textsl{maschera di affinità}. La corrispondente funzione di libreria è
+\funcd{sched\_setaffinity} ed il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
cpu\_set\_t *cpuset)}
- Imposta la maschera di affinità del processo \param{pid}.
+ Imposta la maschera di affinità del processo \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{cpuset} contiene riferimenti a
maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
assunsero invece il prototipo appena mostrato. A complicare la cosa si
aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
-\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
-versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
+\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
+versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
- trovare indicazioni diverse, il prototipo illustrato è quello riportato
+ trovare indicazioni diverse, il prototipo illustrato è quello riportato
nella versione corrente (maggio 2008) delle pagine di manuale e
corrispondente alla definizione presente in \file{sched.h}.}
processo identificato tramite il valore passato in \param{pid}. Come in
precedenza il valore nullo di \param{pid} indica il processo corrente. Per
poter utilizzare questa funzione sono richiesti i privilegi di amministratore
-(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
-un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
+(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
+un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
questa viene ereditata attraverso una \func{fork}, in questo modo diventa
possibile legare automaticamente un gruppo di processi ad un singolo
processore.
Nell'uso comune, almeno con i kernel della serie 2.6.x, l'uso di questa
-funzione non è necessario, in quanto è lo scheduler stesso che provvede a
-mantenere al meglio l'affinità di processore. Esistono però esigenze
-particolari, ad esempio quando un processo (o un gruppo di processi) è
+funzione non è necessario, in quanto è lo scheduler stesso che provvede a
+mantenere al meglio l'affinità di processore. Esistono però esigenze
+particolari, ad esempio quando un processo (o un gruppo di processi) è
utilizzato per un compito importante (ad esempio per applicazioni real-time o
-la cui risposta è critica) e si vuole la massima velocità, con questa
+la cui risposta è critica) e si vuole la massima velocità, con questa
interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
maniera esclusiva. Lo stesso dicasi quando l'accesso a certe risorse (memoria
-o periferiche) può avere un costo diverso a seconda del processore, come
+o periferiche) può avere un costo diverso a seconda del processore, come
avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).
Infine se un gruppo di processi accede alle stesse risorse condivise (ad
-esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
+esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
senso usare lo stesso processore in modo da sfruttare meglio l'uso della sua
cache; questo ovviamente riduce i benefici di un sistema multiprocessore
nell'esecuzione contemporanea dei \itindex{thread} \textit{thread}, ma in
certi casi (quando i \itindex{thread} \textit{thread} sono inerentemente
serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi
-nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
+nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
di processore.
Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
-introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
+introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
estensione specifica delle \acr{glibc}, da attivare definendo la macro
\macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
questo tipo di interfaccia e POSIX al momento non prevede nulla al
- riguardo.} che permette di identificare un insieme di processori. Il dato è
-una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
+ riguardo.} che permette di identificare un insieme di processori. Il dato è
+una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
corrisponde ad un processore, ma dato che per architetture particolari il
-numero di bit di un intero può non essere sufficiente, è stata creata questa
-che è una interfaccia generica che permette di usare a basso livello un tipo
+numero di bit di un intero può non essere sufficiente, è stata creata questa
+che è una interfaccia generica che permette di usare a basso livello un tipo
di dato qualunque rendendosi indipendenti dal numero di bit e dalla loro
disposizione.
Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede
anche una serie di macro di preprocessore per la manipolazione dello stesso,
che consentono di svuotare un insieme, aggiungere o togliere un processore da
-esso o verificare se vi è già presente:
+esso o verificare se vi è già presente:
\begin{functions}
\headdecl{sched.h}
\funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
Rimuove il processore \param{cpu} nell'insieme.
\funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
- Controlla se il processore \param{cpu} è nell'insieme.
+ Controlla se il processore \param{cpu} è nell'insieme.
\end{functions}
Oltre a queste macro, simili alle analoghe usate per gli insiemi di file
-descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
+descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
\const{CPU\_SETSIZE} che indica il numero massimo di processori che possono
far parte dell'insieme, e che costituisce un limite massimo al valore
dell'argomento \param{cpu}.
-In generale la maschera di affinità è preimpostata in modo che un processo
-possa essere eseguito su qualunque processore, se può comunque leggere il
+In generale la maschera di affinità è preimpostata in modo che un processo
+possa essere eseguito su qualunque processore, se può comunque leggere il
valore per un processo specifico usando la funzione
-\funcd{sched\_getaffinity}, il suo prototipo è:
+\funcd{sched\_getaffinity}, il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize,
const cpu\_set\_t *cpuset)}
- Legge la maschera di affinità del processo \param{pid}.
+ Legge la maschera di affinità del processo \param{pid}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
+ \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
valido.
\end{errlist} }
\end{prototype}
-La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
-della maschera di affinità del processo, così da poterla riutilizzare per una
+La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
+della maschera di affinità del processo, così da poterla riutilizzare per una
successiva reimpostazione. In questo caso non sono necessari privilegi
particolari.
-È chiaro che queste funzioni per la gestione dell'affinità hanno significato
+È chiaro che queste funzioni per la gestione dell'affinità hanno significato
soltanto su un sistema multiprocessore, esse possono comunque essere
-utilizzate anche in un sistema con un processore singolo, nel qual caso però
+utilizzate anche in un sistema con un processore singolo, nel qual caso però
non avranno alcun risultato effettivo.
\itindend{scheduler}
\itindend{CPU~affinity}
-\subsection{Le priorità per le operazioni di I/O}
+\subsection{Le priorità per le operazioni di I/O}
\label{sec:io_priority}
-A lungo l'unica priorità usata per i processi è stata quella relativa
-all'assegnazione dell'uso del processore. Ma il processore non è l'unica
+A lungo l'unica priorità usata per i processi è stata quella relativa
+all'assegnazione dell'uso del processore. Ma il processore non è l'unica
risorsa che i processi devono contendersi, un'altra, altrettanto importante
-per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
+per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
possibile soltanto differenziare le politiche generali di gestione, scegliendo
di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con
-l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
+l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
divenuto possibile, qualora si usi questo scheduler, impostare anche delle
-diverse priorità di accesso per i singoli processi.\footnote{al momento
- (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
+diverse priorità di accesso per i singoli processi.\footnote{al momento
+ (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
scheduler.}
-La scelta dello scheduler di I/O si può fare in maniera generica a livello di
+La scelta dello scheduler di I/O si può fare in maniera generica a livello di
avvio del kernel assegnando il nome dello stesso al parametro
-\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
+\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler}
-(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
+(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
scheduler disponibili sono mostrati dal contenuto dello stesso file che
riporta fra parentesi quadre quello attivo, il default in tutti i kernel
-recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
- scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
+recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
+ scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
dettagli sulle caratteristiche specifiche degli altri scheduler, la cui
discussione attiene a problematiche di ambito sistemistico, si consulti la
documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
kernel.
Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system
-call, specifiche di Linux, che consentono di leggere ed impostare le priorità
+call, specifiche di Linux, che consentono di leggere ed impostare le priorità
di I/O.\footnote{se usate in corrispondenza ad uno scheduler diverso il loro
- utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
-diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
+ utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
+diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
la funzione \func{syscall} (come illustrato in
sez.~\ref{sec:intro_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
\funcd{ioprio\_set}; i rispettivi prototipi sono:
\funcdecl{int ioprio\_get(int which, int who)}
\funcdecl{int ioprio\_set(int which, int who, int ioprio)}
- Rileva o imposta la priorità di I/O di un processo.
+ Rileva o imposta la priorità di I/O di un processo.
\bodydesc{Le funzioni ritornano rispettivamente un intero positivo
- (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
+ (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
+ nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] non esiste il processo indicato.
\item[\errcode{EINVAL}] i valori di \param{which} e \param{who} non sono
\end{errlist} }
\end{functions}
-Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
+Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
-già visto per gli omonimi argomenti di \func{getpriority} e
+già visto per gli omonimi argomenti di \func{getpriority} e
\func{setpriority}. Anche in questo caso si deve specificare il valore
di \param{which} tramite le opportune costanti riportate in
tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
\end{table}
In caso di successo \func{ioprio\_get} restituisce un intero positivo che
-esprime il valore della priorità di I/O, questo valore è una maschera binaria
+esprime il valore della priorità di I/O, questo valore è una maschera binaria
composta da due parti, una che esprime la \textsl{classe} di scheduling di I/O
del processo, l'altra che esprime, quando la classe di scheduling lo prevede,
-la priorità del processo all'interno della classe stessa. Questo stesso
-formato viene utilizzato per indicare il valore della priorità da impostare
+la priorità del processo all'interno della classe stessa. Questo stesso
+formato viene utilizzato per indicare il valore della priorità da impostare
con l'argomento \param{ioprio} di \func{ioprio\_set}.
-Per la gestione dei valori che esprimono le priorità di I/O sono state
+Per la gestione dei valori che esprimono le priorità di I/O sono state
definite delle opportune macro di preprocessore, riportate in
-tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
+tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
impostano usando queste macro. Le prime due si usano con il valore restituito
da \func{ioprio\_get} e per ottenere rispettivamente la classe di
scheduling\footnote{restituita dalla macro con i valori di
- tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
-macro viene invece usata per creare un valore di priorità da usare come
+ tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
+macro viene invece usata per creare un valore di priorità da usare come
argomento di \func{ioprio\_set} per eseguire una impostazione.
\begin{table}[htb]
\hline
\hline
\macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della classe.\\
\macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
- valore della priorità.\\
+ valore della priorità.\\
\macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
- & dato un valore di priorità ed una classe
+ & dato un valore di priorità ed una classe
ottiene il valore numerico da passare a
\func{ioprio\_set}.\\
\hline
\end{table}
Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre
-diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
-anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
+diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
+anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
identificata tramite una opportuna costante, secondo quanto riportato in
tab.~\ref{tab:IOsched_class}.
-La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
+La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
questa classe riescono ad accedere a disco soltanto quando nessun altro
processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
-perché un processo in questa classe può venire completamente bloccato quando
+perché un processo in questa classe può venire completamente bloccato quando
ci sono altri processi in una qualunque delle altre due classi che stanno
accedendo al disco. Quando si usa questa classe non ha senso indicare un
-valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
-priorità è identica, la minima possibile, per tutti i processi.
+valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
+priorità è identica, la minima possibile, per tutti i processi.
\begin{table}[htb]
\centering
\hline
\const{IOPRIO\_CLASS\_RT} & Scheduling di I/O \textit{real time}.\\
\const{IOPRIO\_CLASS\_BE} & Scheduling di I/O ordinario.\\
- \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
+ \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
\hline
\end{tabular}
\caption{Costanti che identificano le classi di scheduling di I/O.}
\label{tab:IOsched_class}
\end{table}
-La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
-per \textit{best-effort}) che è quella usata ordinariamente da tutti
-processi. In questo caso esistono priorità diverse che consentono di
+La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
+per \textit{best-effort}) che è quella usata ordinariamente da tutti
+processi. In questo caso esistono priorità diverse che consentono di
assegnazione di una maggiore banda passante nell'accesso a disco ad un
processo rispetto agli altri, con meccanismo simile a quello dei valori di
-\textit{nice} in cui si evita che un processo a priorità più alta possa
-bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
-diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
-e come per \textit{nice} anche in questo caso un valore più basso indica una
-priorità maggiore.
+\textit{nice} in cui si evita che un processo a priorità più alta possa
+bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
+diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
+e come per \textit{nice} anche in questo caso un valore più basso indica una
+priorità maggiore.
-Infine la classe di priorità di I/O \textit{real-time}
-\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
+Infine la classe di priorità di I/O \textit{real-time}
+\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
processo in questa classe ha sempre la precedenza nell'accesso a disco
rispetto a tutti i processi delle altre classi e di un processo nella stessa
-classe ma con priorità inferiore, ed è pertanto in grado di bloccare
-completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
-con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
+classe ma con priorità inferiore, ed è pertanto in grado di bloccare
+completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
+con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
bassi.
-In generale nel funzionamento ordinario la priorità di I/O di un processo
+In generale nel funzionamento ordinario la priorità di I/O di un processo
viene impostata in maniera automatica nella classe \const{IOPRIO\_CLASS\_BE}
con un valore ottenuto a partire dal corrispondente valore di \textit{nice}
tramite la formula: $\mathtt{\mathit{prio}}=(\mathtt{\mathit{nice}}+20)/5$. Un
-utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
-dei processi che gli appartengono,\footnote{per la modifica delle priorità di
+utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
+dei processi che gli appartengono,\footnote{per la modifica delle priorità di
altri processi occorrono privilegi amministrativi, ed in particolare la
- capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
-cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
-chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
-l'amministratore\footnote{o un processo con la capacità
- \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
-impostare un processo ad una priorità di I/O nella classe
+ capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
+cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
+chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
+l'amministratore\footnote{o un processo con la capacità
+ \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
+impostare un processo ad una priorità di I/O nella classe
\const{IOPRIO\_CLASS\_RT} o \const{IOPRIO\_CLASS\_IDLE}.
%TODO verificare http://lwn.net/Articles/355987/
-%TODO trattare le funzionalità per il NUMA
+%TODO trattare le funzionalità per il NUMA
% vedi man numa e le pagine di manuale relative
% vedere anche dove metterle...
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
-Benché i processi siano strutturati in modo da apparire il più possibile come
+Benché i processi siano strutturati in modo da apparire il più possibile come
indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
occorre tenere conto di una serie di problematiche che normalmente non
esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
programma alla volta.
-Pur essendo questo argomento di carattere generale, ci è parso opportuno
-introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
+Pur essendo questo argomento di carattere generale, ci è parso opportuno
+introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
in capitoli successivi, in questa sezione conclusiva del capitolo in cui
abbiamo affrontato la gestione dei processi.
\label{sec:proc_atom_oper}
La nozione di \textsl{operazione atomica} deriva dal significato greco della
-parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
+parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
-che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
+che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
di interruzione in una fase intermedia.
-In un ambiente multitasking il concetto è essenziale, dato che un processo può
+In un ambiente multitasking il concetto è essenziale, dato che un processo può
essere interrotto in qualunque momento dal kernel che mette in esecuzione un
altro processo o dalla ricezione di un segnale; occorre pertanto essere
accorti nei confronti delle possibili \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}) derivanti da operazioni
interrotte in una fase in cui non erano ancora state completate.
-Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
-occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
+Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
+occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
-funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le system call con cui esse sono realizzate
+funzioni di libreria per compiere le operazioni necessarie è garanzia
+sufficiente di atomicità in quanto le system call con cui esse sono realizzate
non possono essere interrotte (o subire interferenze pericolose) da altri
processi.
-Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
+Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
stesso processo, e pure alcune system call, possono essere interrotti in
qualunque momento, e le operazioni di un eventuale \textit{signal handler}
sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
-il solo accesso o l'assegnazione di una variabile possono non essere più
+il solo accesso o l'assegnazione di una variabile possono non essere più
operazioni atomiche (torneremo su questi aspetti in
sez.~\ref{sec:sig_adv_control}).
In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
-il cui accesso è assicurato essere atomico. In pratica comunque si può
-assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
+il cui accesso è assicurato essere atomico. In pratica comunque si può
+assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
\ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
-atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
-maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
-le strutture. In tutti questi casi è anche opportuno marcare come
+atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
+maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
+le strutture. In tutti questi casi è anche opportuno marcare come
\direct{volatile} le variabili che possono essere interessate ad accesso
condiviso, onde evitare problemi con le ottimizzazioni del codice.
Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
diversi operano su una risorsa comune, ed in cui il risultato viene a
dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
-tipico è quello di un'operazione che viene eseguita da un processo in più
-passi, e può essere compromessa dall'intervento di un altro processo che
+tipico è quello di un'operazione che viene eseguita da un processo in più
+passi, e può essere compromessa dall'intervento di un altro processo che
accede alla stessa risorsa quando ancora non tutti i passi sono stati
completati.
-Dato che in un sistema multitasking ogni processo può essere interrotto in
-qualunque momento per farne subentrare un altro in esecuzione, niente può
+Dato che in un sistema multitasking ogni processo può essere interrotto in
+qualunque momento per farne subentrare un altro in esecuzione, niente può
assicurare un preciso ordine di esecuzione fra processi diversi o che una
sezione di un programma possa essere eseguita senza interruzioni da parte di
altri. Queste situazioni comportano pertanto errori estremamente subdoli e
difficili da tracciare, in quanto nella maggior parte dei casi tutto
-funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
+funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
-che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
-gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
+che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
+gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
\textit{race condition} si hanno quando diversi processi accedono allo stesso
file, o nell'accesso a meccanismi di intercomunicazione come la memoria
-condivisa. In questi casi, se non si dispone della possibilità di eseguire
+condivisa. In questi casi, se non si dispone della possibilità di eseguire
atomicamente le operazioni necessarie, occorre che quelle parti di codice in
cui si compiono le operazioni sulle risorse condivise (le cosiddette
\index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
Un caso particolare di \textit{race condition} sono poi i cosiddetti
\textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
completo di un servizio, e non il fallimento di una singola operazione. Per
-definizione un \textit{deadlock} è una situazione in cui due o più processi
-non sono più in grado di proseguire perché ciascuno aspetta il risultato di
+definizione un \textit{deadlock} è una situazione in cui due o più processi
+non sono più in grado di proseguire perché ciascuno aspetta il risultato di
una operazione che dovrebbe essere eseguita dall'altro.
-L'esempio tipico di una situazione che può condurre ad un
-\textit{deadlock} è quello in cui un flag di
+L'esempio tipico di una situazione che può condurre ad un
+\textit{deadlock} è quello in cui un flag di
``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
-segnale o un altro processo) fra il momento in cui lo si è controllato
+segnale o un altro processo) fra il momento in cui lo si è controllato
(trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
-questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
+questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
-diventerà perpetua (da cui il nome di \textit{deadlock}).
+diventerà perpetua (da cui il nome di \textit{deadlock}).
-In tutti questi casi è di fondamentale importanza il concetto di atomicità
+In tutti questi casi è di fondamentale importanza il concetto di atomicità
visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
eseguire in maniera atomica le operazioni necessarie.
\index{funzioni!rientranti|(}
-Si dice \textsl{rientrante} una funzione che può essere interrotta in
+Si dice \textsl{rientrante} una funzione che può essere interrotta in
qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
un altro \itindex{thread} \textit{thread} di esecuzione senza che questo
-comporti nessun problema nell'esecuzione della stessa. La problematica è
+comporti nessun problema nell'esecuzione della stessa. La problematica è
comune nella programmazione \itindex{thread} \textit{multi-thread}, ma si
hanno gli stessi problemi quando si vogliono chiamare delle funzioni
all'interno dei gestori dei segnali.
-Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
+Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
queste infatti vengono allocate nello \itindex{stack} \textit{stack}, ed
un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
-può non essere rientrante quando opera su memoria che non è nello
-\itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
+può non essere rientrante quando opera su memoria che non è nello
+\itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
se usa una variabile globale o statica.
Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
-cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
-ogni volta e ritornato indietro la funzione può essere rientrante, se invece
+cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
+ogni volta e ritornato indietro la funzione può essere rientrante, se invece
esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
-Allo stesso modo una funzione può non essere rientrante se usa e modifica un
+Allo stesso modo una funzione può non essere rientrante se usa e modifica un
oggetto che le viene fornito dal chiamante: due chiamate possono interferire
se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
+esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
disposizione due macro di compilatore,\footnote{si ricordi quanto illustrato
in sez.~\ref{sec:intro_gcc_glibc_std}.} \macro{\_REENTRANT} e
\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
\chapter{Ringraziamenti}
\label{cha:ringraziamenti}
-Desidero ringraziare tutti coloro che a vario titolo e a più riprese mi hanno
-aiutato ed han contribuito a migliorare in molteplici aspetti la qualità di
+Desidero ringraziare tutti coloro che a vario titolo e a più riprese mi hanno
+aiutato ed han contribuito a migliorare in molteplici aspetti la qualità di
GaPiL. In ordine rigorosamente alfabetico desidero citare:
\begin{description}
\item[\textbf{Alessio Frusciante}] per l'apprezzamento, le innumerevoli
- correzioni ed i suggerimenti per rendere più chiara l'esposizione.
+ correzioni ed i suggerimenti per rendere più chiara l'esposizione.
\item[\textbf{Daniele Masini}] per la rilettura puntuale, le innumerevoli
correzioni, i consigli sull'esposizione ed i contributi relativi alle
calling convention dei linguaggi e al confronto delle diverse tecniche di
pregio di fare parte, che ha messo a disposizione il repository CVS su cui era
presente la prima versione della Guida, ed il relativo spazio web, e Truelite
Srl, l'azienda che ho fondato e di cui sono responsabile tecnico, che fornisce
-il nuovo repository SVN, tutto quanto è necessario alla pubblicazione della
+il nuovo repository SVN, tutto quanto è necessario alla pubblicazione della
guida ed il sistema di tracciamento dei sorgenti su
\href{http://gapil.truelite.it/sources}
{\textsf{http://gapil.truelite.it/sources}}.
Nella prima parte del capitolo esamineremo i concetti base del sistema delle
sessioni di lavoro, vale a dire il metodo con cui il kernel permette ad un
-utente di gestire le capacità multitasking del sistema, permettendo di
-eseguire più programmi in contemporanea. Nella seconda parte del capitolo
+utente di gestire le capacità multitasking del sistema, permettendo di
+eseguire più programmi in contemporanea. Nella seconda parte del capitolo
tratteremo poi il funzionamento dell'I/O su terminale, e delle varie
-peculiarità che esso viene ad assumere a causa del suo stretto legame con il
+peculiarità che esso viene ad assumere a causa del suo stretto legame con il
suo uso come interfaccia di accesso al sistema da parte degli utenti.
\section{Il \textit{job control}}
\label{sec:sess_job_control}
-Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
-il cui scopo è quello di permettere ad un utente di poter sfruttare le
-capacità multitasking di un sistema Unix per eseguire in contemporanea più
+Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
+il cui scopo è quello di permettere ad un utente di poter sfruttare le
+capacità multitasking di un sistema Unix per eseguire in contemporanea più
processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
- \textit{X Window} e con i terminali virtuali tutto questo non è più vero,
- dato che si può accedere a molti terminali in contemporanea da una singola
- postazione di lavoro, ma il sistema è nato prima dell'esistenza di tutto
- ciò.} avendo cioè un solo punto in cui si può avere accesso all'input ed
+ \textit{X Window} e con i terminali virtuali tutto questo non è più vero,
+ dato che si può accedere a molti terminali in contemporanea da una singola
+ postazione di lavoro, ma il sistema è nato prima dell'esistenza di tutto
+ ciò.} avendo cioè un solo punto in cui si può avere accesso all'input ed
all'output degli stessi.
\subsection{Una panoramica introduttiva}
\label{sec:sess_job_control_overview}
-Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
+Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
negli anni '80, e successivamente standardizzata da POSIX.1; la sua
-disponibilità nel sistema è verificabile attraverso il controllo della macro
+disponibilità nel sistema è verificabile attraverso il controllo della macro
\macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
supporto sia da parte della shell (quasi tutte ormai lo hanno), che da parte
del kernel; in particolare il kernel deve assicurare sia la presenza di un
relativi segnali illustrati in sez.~\ref{sec:sig_job_control}.
In un sistema che supporta il \textit{job control}, una volta completato il
-login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
-potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
+login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
+potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
(vedi sez.~\ref{sec:sess_proc_group}) tutti i processi eseguiti all'interno
dello stesso login (esamineremo tutto il processo in dettaglio in
sez.~\ref{sec:sess_login}).
-Siccome la shell è collegata ad un solo terminale, che viene usualmente
+Siccome la shell è collegata ad un solo terminale, che viene usualmente
chiamato \textsl{terminale di controllo}, (vedi sez.~\ref{sec:sess_ctrl_term})
un solo comando alla volta (quello che viene detto in \textit{foreground} o in
-\textsl{primo piano}), potrà scrivere e leggere dal terminale. La shell però
-può eseguire, aggiungendo una \cmd{\&} alla fine del comando, più programmi in
+\textsl{primo piano}), potrà scrivere e leggere dal terminale. La shell però
+può eseguire, aggiungendo una \cmd{\&} alla fine del comando, più programmi in
contemporanea, mandandoli in \textit{background} (o \textsl{sullo sfondo}),
nel qual caso essi saranno eseguiti senza essere collegati al terminale.
Si noti come si sia parlato di comandi e non di programmi o processi; fra le
-funzionalità della shell infatti c'è anche quella di consentire di concatenare
-più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
-eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
-questo potrà sempre lanciare sotto-processi per eseguire dei compiti specifici.
-
-Per questo l'esecuzione di un comando può originare più di un processo; quindi
-nella gestione del job control non si può far riferimento ai singoli processi.
-Per questo il kernel prevede la possibilità di raggruppare più processi in un
+funzionalità della shell infatti c'è anche quella di consentire di concatenare
+più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
+eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
+questo potrà sempre lanciare sotto-processi per eseguire dei compiti specifici.
+
+Per questo l'esecuzione di un comando può originare più di un processo; quindi
+nella gestione del job control non si può far riferimento ai singoli processi.
+Per questo il kernel prevede la possibilità di raggruppare più processi in un
\itindex{process~group} \textit{process group} (detto anche
\textsl{raggruppamento di processi}, vedi sez.~\ref{sec:sess_proc_group}) e la
-shell farà sì che tutti i processi che originano da una riga di comando
+shell farà sì che tutti i processi che originano da una riga di comando
appartengano allo stesso raggruppamento, in modo che le varie funzioni di
controllo, ed i segnali inviati dal terminale, possano fare riferimento ad
esso.
-In generale allora all'interno di una sessione avremo un eventuale (può non
+In generale allora all'interno di una sessione avremo un eventuale (può non
esserci) \itindex{process~group} \textit{process group} in
\textit{foreground}, che riunisce i processi che possono accedere al
-terminale, e più \itindex{process~group} \textit{process group} in
+terminale, e più \itindex{process~group} \textit{process group} in
\textit{background}, che non possono accedervi. Il job control prevede che
quando un processo appartenente ad un raggruppamento in \textit{background}
cerca di accedere al terminale, venga inviato un segnale a tutti i processi
Un comportamento analogo si ha anche per i segnali generati dai comandi di
tastiera inviati dal terminale che vengono inviati a tutti i processi del
raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
-l'esecuzione del comando, che può poi essere mandato in \textit{background}
+l'esecuzione del comando, che può poi essere mandato in \textit{background}
con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
sono parole chiave che indicano comandi interni alla shell, e nel caso non
comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
lanciato in \textit{background}.
Di norma la shell si cura anche di notificare all'utente (di solito prima
-della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
+della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
l'opzione \const{WUNTRACED}, secondo quanto illustrato in
\type{pid\_t}. I valori di questi identificatori possono essere visualizzati
dal comando \cmd{ps} usando l'opzione \cmd{-j}.
-Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
-stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
-le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è
- definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
+Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
+stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
+le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è
+ definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
i cui prototipi sono:
\begin{functions}
\headdecl{unistd.h}
La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
-restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
+restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
equivalente a \code{getpgid(0)}.
-In maniera analoga l'identificatore della sessione può essere letto dalla
-funzione \funcd{getsid}, che però nelle \acr{glibc}\footnote{la system call è
+In maniera analoga l'identificatore della sessione può essere letto dalla
+funzione \funcd{getsid}, che però nelle \acr{glibc}\footnote{la system call è
stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
- librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
+ librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
da POSIX.1, che parla solo di processi leader di sessione, e non di
- identificatori di sessione.} è accessibile solo definendo
+ identificatori di sessione.} è accessibile solo definendo
\macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
-è:
+è:
\begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
Legge l'identificatore di sessione del processo \param{pid}.
\bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
- caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
+ caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo selezionato non esiste.
Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
processo con lo stesso valore che hanno nel processo padre, per cui un
processo appena creato appartiene sempre allo stesso raggruppamento e alla
-stessa sessione del padre. Vedremo poi come sia possibile creare più
+stessa sessione del padre. Vedremo poi come sia possibile creare più
\textit{process group} all'interno della stessa sessione, e spostare i
processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
+cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
identificato dall'avere un \acr{pgid} uguale al suo \acr{pid}, in genere
-questo è il primo processo del raggruppamento, che si incarica di lanciare
+questo è il primo processo del raggruppamento, che si incarica di lanciare
tutti gli altri. Un nuovo raggruppamento si crea con la funzione
-\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
- una funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
+\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
+ una funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
\acr{glibc} viene sempre usata sempre questa definizione, a meno di non
- richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
- la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
+ richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
+ la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
\begin{prototype}{unistd.h}{int setpgrp(void)}
Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
corrente, rende questo \itindex{process~group~leader} \textit{group leader} di
un nuovo raggruppamento, tutti i successivi processi da esso creati
apparterranno (a meno di non cambiare di nuovo il \acr{pgid}) al nuovo
-raggruppamento. È possibile invece spostare un processo da un raggruppamento
-ad un altro con la funzione \funcd{setpgid}, il cui prototipo è:
+raggruppamento. È possibile invece spostare un processo da un raggruppamento
+ad un altro con la funzione \funcd{setpgid}, il cui prototipo è:
\begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
\bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
- -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
+ -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo selezionato non esiste.
- \item[\errcode{EPERM}] il cambiamento non è consentito.
- \item[\errcode{EACCES}] il processo ha già eseguito una \func{exec}.
- \item[\errcode{EINVAL}] il valore di \param{pgid} è negativo.
+ \item[\errcode{EPERM}] il cambiamento non è consentito.
+ \item[\errcode{EACCES}] il processo ha già eseguito una \func{exec}.
+ \item[\errcode{EINVAL}] il valore di \param{pgid} è negativo.
\end{errlist}
}
\end{prototype}
La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
-cambiamento può essere effettuato solo se \param{pgid} indica un
-\textit{process group} che è nella stessa sessione del processo chiamante.
-Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
+cambiamento può essere effettuato solo se \param{pgid} indica un
+\textit{process group} che è nella stessa sessione del processo chiamante.
+Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
-ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
+ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
\struct{task\_struct}.} Specificando un valore nullo per \param{pid} si
indica il processo corrente, mentre specificando un valore nullo per
\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
-processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
+processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
0)}.
Di norma questa funzione viene usata dalla shell quando si usano delle
pipeline, per mettere nello stesso \textit{process group} tutti i programmi
lanciati su ogni linea di comando; essa viene chiamata dopo una \func{fork}
sia dal processo padre, per impostare il valore nel figlio, che da
-quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
- group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
+quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
+ group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
ma non potendo determinare quale dei due processi viene eseguito per primo,
occorre eseguirle comunque entrambe per evitare di esporsi ad una
\itindex{race~condition} \textit{race condition}.
Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
processo da una sessione ad un altra; infatti l'unico modo di far cambiare
-sessione ad un processo è quello di crearne una nuova con l'uso di
-\funcd{setsid}; il suo prototipo è:
+sessione ad un processo è quello di crearne una nuova con l'uso di
+\funcd{setsid}; il suo prototipo è:
\begin{prototype}{unistd.h}{pid\_t setsid(void)}
Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
\acr{pgid}.
\bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
- errore, il solo errore possibile è \errval{EPERM}, che si ha quando il
+ errore, il solo errore possibile è \errval{EPERM}, che si ha quando il
\acr{pgid} e \acr{pid} del processo coincidono.}
\end{prototype}
La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
-valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
+valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
\textit{process group} di cui esso diventa leader (come per i \textit{process
- group} un processo si dice leader di sessione\footnote{in Linux la proprietà
- è mantenuta in maniera indipendente con un apposito campo \var{leader} in
- \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed
+ group} un processo si dice leader di sessione\footnote{in Linux la proprietà
+ è mantenuta in maniera indipendente con un apposito campo \var{leader} in
+ \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed
unico componente. Inoltre la funzione distacca il processo da ogni terminale
di controllo (torneremo sull'argomento in sez.~\ref{sec:sess_ctrl_term}) cui
fosse in precedenza associato.
-La funzione ha successo soltanto se il processo non è già
+La funzione ha successo soltanto se il processo non è già
\itindex{process~group~leader} leader di un \textit{process group}, per cui
per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare
\func{setsid} nel processo figlio, in modo che, avendo questo lo stesso
-\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di
+\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di
errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori
dei \acr{pid} fatto nella creazione dei nuovi processi (vedi
sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
Come accennato in sez.~\ref{sec:sess_job_control_overview}, nel sistema del
\textit{job control} i processi all'interno di una sessione fanno riferimento
-ad un terminale di controllo (ad esempio quello su cui si è effettuato il
+ad un terminale di controllo (ad esempio quello su cui si è effettuato il
login), sul quale effettuano le operazioni di lettura e
-scrittura,\footnote{nel caso di login grafico la cosa può essere più
- complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
+scrittura,\footnote{nel caso di login grafico la cosa può essere più
+ complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
per i programmi, anche grafici, lanciati da un qualunque emulatore di
- terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
+ terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
dal quale ricevono gli eventuali segnali da tastiera.
A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
associato un terminale di controllo; in Linux questo viene realizzato
-mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
+mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
di controllo.\footnote{lo standard POSIX.1 non specifica nulla riguardo
l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
\struct{task\_struct}, nel campo \var{tty}.} In generale ogni processo
controllo.
Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
-il precedente terminale di controllo viene cancellata, ed il processo che è
-divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
- è necessario, cosa che, come vedremo in sez.~\ref{sec:sess_daemon}, non è
+il precedente terminale di controllo viene cancellata, ed il processo che è
+divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
+ è necessario, cosa che, come vedremo in sez.~\ref{sec:sess_daemon}, non è
sempre vera.}, un terminale di controllo. In generale questo viene fatto
automaticamente dal sistema\footnote{a meno di non avere richiesto
esplicitamente che questo non diventi un terminale di controllo con il flag
\const{O\_NOCTTY} (vedi sez.~\ref{sec:file_open}). In questo Linux segue la
semantica di SVr4; BSD invece richiede che il terminale venga allocato
esplicitamente con una \func{ioctl} con il comando \const{TIOCSCTTY}.}
-quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
+quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
\file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
mentre il processo diventa il \textsl{processo di controllo} di quella
sessione.
-In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
+In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
associato ai file standard (di input, output ed error) dei processi nella
sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
\textit{foreground}, possono leggere e scrivere in certo istante. Per
impostare il raggruppamento di \textit{foreground} di un terminale si usa la
-funzione \funcd{tcsetpgrp}, il cui prototipo è:
+funzione \funcd{tcsetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
file descriptor \param{fd}.
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ENOTTY}] il file \param{fd} non corrisponde al terminale di
controllo del processo chiamante.
\item[\errcode{ENOSYS}] il sistema non supporta il job control.
- \item[\errcode{EPERM}] il \textit{process group} specificato non è nella
+ \item[\errcode{EPERM}] il \textit{process group} specificato non è nella
stessa sessione del processo chiamante.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{EINVAL}.
}
\end{functions}
-\noindent la funzione può essere eseguita con successo solo da
+\noindent la funzione può essere eseguita con successo solo da
un processo nella stessa sessione e con lo stesso terminale di controllo.
Come accennato in sez.~\ref{sec:sess_job_control_overview}, tutti i processi
(e relativi raggruppamenti) che non fanno parte del gruppo di
\textit{foreground} sono detti in \textit{background}; se uno si essi cerca di
-accedere al terminale di controllo provocherà l'invio da parte del kernel di
+accedere al terminale di controllo provocherà l'invio da parte del kernel di
uno dei due segnali \const{SIGTTIN} o \const{SIGTTOU} (a seconda che l'accesso
sia stato in lettura o scrittura) a tutto il suo \itindex{process~group}
\textit{process group}; dato che il comportamento di default di questi segnali
-(si riveda quanto esposto in sez.~\ref{sec:sig_job_control}) è di fermare il
+(si riveda quanto esposto in sez.~\ref{sec:sig_job_control}) è di fermare il
processo, di norma questo comporta che tutti i membri del gruppo verranno
fermati, ma non si avranno condizioni di errore.\footnote{la shell in genere
notifica comunque un avvertimento, avvertendo la presenza di processi
- bloccati grazie all'uso di \func{waitpid}.} Se però si bloccano o ignorano i
+ bloccati grazie all'uso di \func{waitpid}.} Se però si bloccano o ignorano i
due segnali citati, le funzioni di lettura e scrittura falliranno con un
errore di \errcode{EIO}.
-Un processo può controllare qual è il gruppo di \textit{foreground} associato
-ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
+Un processo può controllare qual è il gruppo di \textit{foreground} associato
+ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
\textit{foreground} del terminale associato al file descriptor \param{fd}.
\bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del
gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
- \var{errno} assumerà i valori:
+ \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ENOTTY}] non c'è un terminale di controllo o \param{fd} non
+ \item[\errcode{ENOTTY}] non c'è un terminale di controllo o \param{fd} non
corrisponde al terminale di controllo del processo chiamante.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{ENOSYS}.
descriptor, il risultato comunque non dipende dal file descriptor che si usa
ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
processo di accedere direttamente al suo terminale di controllo attraverso il
-file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
+file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
proprio terminale di controllo. Questo consente anche a processi che possono
aver rediretto l'output di accedere al terminale di controllo, pur non
-disponendo più del file descriptor originario; un caso tipico è il programma
+disponendo più del file descriptor originario; un caso tipico è il programma
\cmd{crypt} che accetta la redirezione sullo standard input di un file da
decifrare, ma deve poi leggere la password dal terminale.
-Un'altra caratteristica del terminale di controllo usata nel job control è che
+Un'altra caratteristica del terminale di controllo usata nel job control è che
utilizzando su di esso le combinazioni di tasti speciali (\texttt{C-z},
-\texttt{C-c}, \texttt{C-y} e \texttt{C-|}) si farà sì che il kernel invii i
+\texttt{C-c}, \texttt{C-y} e \texttt{C-|}) si farà sì che il kernel invii i
corrispondenti segnali (rispettivamente \const{SIGTSTP}, \const{SIGINT},
\const{SIGQUIT} e \const{SIGTERM}, trattati in sez.~\ref{sec:sig_job_control})
a tutti i processi del raggruppamento di \textit{foreground}; in questo modo
-la shell può gestire il blocco e l'interruzione dei vari comandi.
+la shell può gestire il blocco e l'interruzione dei vari comandi.
Per completare la trattazione delle caratteristiche del job control legate al
inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
-va giù la rete o più semplicemente si chiude forzatamente la finestra di
-terminale su cui si stava lavorando, il kernel provvederà ad inviare il
+va giù la rete o più semplicemente si chiude forzatamente la finestra di
+terminale su cui si stava lavorando, il kernel provvederà ad inviare il
segnale di \const{SIGHUP} al processo di controllo. L'azione preimpostata in
-questo caso è la terminazione del processo, il problema che si pone è cosa
-accade agli altri processi nella sessione, che non han più un processo di
+questo caso è la terminazione del processo, il problema che si pone è cosa
+accade agli altri processi nella sessione, che non han più un processo di
controllo che possa gestire l'accesso al terminale, che potrebbe essere
riutilizzato per qualche altra sessione.
Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
-ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
+ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
segnale di \const{SIGHUP} ai processi del raggruppamento di foreground. In
-questo modo essi potranno essere avvisati che non esiste più un processo in
-grado di gestire il terminale (di norma tutto ciò comporta la terminazione
+questo modo essi potranno essere avvisati che non esiste più un processo in
+grado di gestire il terminale (di norma tutto ciò comporta la terminazione
anche di questi ultimi).
-Restano però gli eventuali processi in background, che non ricevono il
-segnale; in effetti se il terminale non dovesse più servire essi potrebbero
+Restano però gli eventuali processi in background, che non ricevono il
+segnale; in effetti se il terminale non dovesse più servire essi potrebbero
proseguire fino al completamento della loro esecuzione; ma si pone il problema
di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
terminale, in assenza di un processo che sia in grado di effettuare il
controllo dello stesso.
-Questa è la situazione in cui si ha quello che viene chiamato un
+Questa è la situazione in cui si ha quello che viene chiamato un
\itindex{process~group~orphaned} \textit{orphaned process group}. Lo standard
POSIX.1 lo definisce come un \itindex{process~group} \textit{process group} i
cui processi hanno come padri esclusivamente o altri processi nel
raggruppamento, o processi fuori della sessione. Lo standard prevede inoltre
-che se la terminazione di un processo fa sì che un raggruppamento di processi
+che se la terminazione di un processo fa sì che un raggruppamento di processi
diventi orfano e se i suoi membri sono bloccati, ad essi vengano inviati in
sequenza i segnali di \const{SIGHUP} e \const{SIGCONT}.
-La definizione può sembrare complicata, e a prima vista non è chiaro cosa
-tutto ciò abbia a che fare con il problema della terminazione del processo di
+La definizione può sembrare complicata, e a prima vista non è chiaro cosa
+tutto ciò abbia a che fare con il problema della terminazione del processo di
controllo. Consideriamo allora cosa avviene di norma nel \textit{job
control}: una sessione viene creata con \func{setsid} che crea anche un
nuovo \itindex{process~group} \textit{process group}: per definizione
-quest'ultimo è sempre \itindex{process~group~orphaned} \textsl{orfano}, dato
-che il padre del leader di sessione è fuori dalla stessa e il nuovo
+quest'ultimo è sempre \itindex{process~group~orphaned} \textsl{orfano}, dato
+che il padre del leader di sessione è fuori dalla stessa e il nuovo
\textit{process group} \itindex{process~group} contiene solo il leader di
-sessione. Questo è un caso limite, e non viene emesso nessun segnale perché
+sessione. Questo è un caso limite, e non viene emesso nessun segnale perché
quanto previsto dallo standard riguarda solo i raggruppamenti che diventano
orfani in seguito alla terminazione di un processo.\footnote{l'emissione dei
segnali infatti avviene solo nella fase di uscita del processo, come una
delle operazioni legate all'esecuzione di \func{\_exit}, secondo quanto
illustrato in sez.~\ref{sec:proc_termination}.}
-Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
+Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
punto non sono orfani in quanto esso resta padre per almeno uno dei processi
del gruppo (gli altri possono derivare dal primo). Alla terminazione del
-leader di sessione però avremo che, come visto in
+leader di sessione però avremo che, come visto in
sez.~\ref{sec:proc_termination}, tutti i suoi figli vengono adottati da
-\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
+\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
group creati direttamente dal leader di sessione (a meno di non aver spostato
con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
-\const{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
-frattempo inviato anche \const{SIGHUP}, se non c'è un gestore per
+\const{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
+frattempo inviato anche \const{SIGHUP}, se non c'è un gestore per
quest'ultimo, i processi bloccati verranno automaticamente terminati.
\subsection{Dal login alla shell}
\label{sec:sess_login}
-L'organizzazione del sistema del job control è strettamente connessa alle
-modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
+L'organizzazione del sistema del job control è strettamente connessa alle
+modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
esso con un terminale, che sia questo realmente tale, come un VT100 collegato
ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
i file standard (vedi sez.~\ref{sec:file_std_descr}) per l'I/O, tratteremo
solo il caso classico del terminale.
-Abbiamo già brevemente illustrato in sez.~\ref{sec:intro_kern_and_sys} le
-modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
-vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
-dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
+Abbiamo già brevemente illustrato in sez.~\ref{sec:intro_kern_and_sys} le
+modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
+vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
+dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
shell che gli permette di lanciare i suoi comandi su un terminale.
Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
altre distribuzioni dedicate a compiti limitati e specifici.} viene usata
la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
file di configurazione \conffile{/etc/inittab} quali programmi devono essere
-lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
+lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
anch'esso definito nello stesso file.
Tralasciando la descrizione del sistema dei run level, (per il quale si
rimanda alla lettura delle pagine di manuale di \cmd{init} e di
-\file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
+\file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
-di massima della procedura è riportato in fig.~\ref{fig:sess_term_login}.
+di massima della procedura è riportato in fig.~\ref{fig:sess_term_login}.
\begin{figure}[htb]
\centering
Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
delle sue varianti), che permette di mettersi in ascolto su uno di questi
dispositivi. Alla radice della catena che porta ad una shell per i comandi
-perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
+perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
\func{exec} per lanciare una istanza di questo programma su un terminale, il
tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
un certo numero di essi, nel caso delle console virtuali), secondo quanto
amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
\func{setsid} per creare una nuova sessione ed un nuovo
\itindex{process~group} \textit{process group}, e di aprire il terminale (che
-così diventa il terminale di controllo della sessione) in lettura sullo
+così diventa il terminale di controllo della sessione) in lettura sullo
standard input ed in scrittura sullo standard output e sullo standard error;
-inoltre effettuerà, qualora servano, ulteriori impostazioni.\footnote{ad
- esempio, come qualcuno si sarà accorto scrivendo un nome di login in
- maiuscolo, può effettuare la conversione automatica dell'input in minuscolo,
- ponendosi in una modalità speciale che non distingue fra i due tipi di
+inoltre effettuerà, qualora servano, ulteriori impostazioni.\footnote{ad
+ esempio, come qualcuno si sarà accorto scrivendo un nome di login in
+ maiuscolo, può effettuare la conversione automatica dell'input in minuscolo,
+ ponendosi in una modalità speciale che non distingue fra i due tipi di
caratteri (a beneficio di alcuni vecchi terminali che non supportavano le
- minuscole).} Alla fine il programma stamperà un messaggio di benvenuto per
+ minuscole).} Alla fine il programma stamperà un messaggio di benvenuto per
poi porsi in attesa dell'immissione del nome di un utente.
Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
dal database degli utenti.} e richiede una password. Se l'utente non esiste
o se la password non corrisponde\footnote{il confronto non viene effettuato
con un valore in chiaro; quanto immesso da terminale viene invece a sua
- volta criptato, ed è il risultato che viene confrontato con il valore che
+ volta criptato, ed è il risultato che viene confrontato con il valore che
viene mantenuto nel database degli utenti.} la richiesta viene ripetuta un
certo numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
rilanciare un'altra istanza di \cmd{getty}.
Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
la \textit{home directory} dell'utente, cambia i diritti di accesso al
-terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
+terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
Infine attraverso l'uso di \func{setuid}, \func{setgid} e \func{initgroups}
-verrà cambiata l'identità del proprietario del processo, infatti, come
+verrà cambiata l'identità del proprietario del processo, infatti, come
spiegato in sez.~\ref{sec:proc_setuid}, avendo invocato tali funzioni con i
privilegi di amministratore, tutti gli user-ID ed i group-ID (reali, effettivi
e salvati) saranno impostati a quelli dell'utente.
-A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
+A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
-ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
-già pronto con i file standard di sez.~\ref{sec:file_std_descr} impostati sul
+ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
+già pronto con i file standard di sez.~\ref{sec:file_std_descr} impostati sul
terminale, e pronta, nel ruolo di leader di sessione e di processo di
controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
in sez.~\ref{sec:sess_job_control_overview}.
-Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
+Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
provvedere, ricevendo un \const{SIGCHLD} all'uscita della shell quando la
-sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
+sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
ripetere da capo tutto il procedimento.
della posta, ed in generale tutti i programmi di servizio) che non hanno
niente a che fare con la gestione diretta dei comandi dell'utente.
-Questi programmi, che devono essere eseguiti in modalità non interattiva e
+Questi programmi, che devono essere eseguiti in modalità non interattiva e
senza nessun intervento dell'utente, sono normalmente chiamati
\textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli
della mitologia greca che svolgevano compiti che gli dei trovavano noiosi, di
%TODO ricontrollare, i miei ricordi di filosofia sono piuttosto datati.
-Se però si lancia un programma demone dalla riga di comando in un sistema che
-supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
+Se però si lancia un programma demone dalla riga di comando in un sistema che
+supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
un terminale di controllo e mantenuto all'interno di una sessione, e anche se
-può essere mandato in background e non eseguire più nessun I/O su terminale,
+può essere mandato in background e non eseguire più nessun I/O su terminale,
si avranno comunque tutte le conseguenze che abbiamo appena visto in
sez.~\ref{sec:sess_ctrl_term} (in particolare l'invio dei segnali in
corrispondenza dell'uscita del leader di sessione).
identiche.} da seguire quando si scrive un demone.
Pertanto, quando si lancia un programma che deve essere eseguito come demone
-occorrerà predisporlo in modo che esso compia le seguenti azioni:
+occorrerà predisporlo in modo che esso compia le seguenti azioni:
\begin{enumerate}
\item Eseguire una \func{fork} e terminare immediatamente il processo padre
proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che
- il figlio non è un \itindex{process~group~leader} \textit{process group
- leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può
- chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
+ il figlio non è un \itindex{process~group~leader} \textit{process group
+ leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può
+ chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
il comando all'uscita del padre.
\item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
raggruppamento di cui il processo diventa automaticamente il leader, che
- però non ha associato nessun terminale di controllo.
+ però non ha associato nessun terminale di controllo.
\item Assicurarsi che al processo non venga associato in seguito nessun nuovo
- terminale di controllo; questo può essere fatto sia avendo cura di usare
+ terminale di controllo; questo può essere fatto sia avendo cura di usare
sempre l'opzione \const{O\_NOCTTY} nell'aprire i file di terminale, che
eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
- figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
- non potrà ottenere automaticamente un terminale di controllo.
+ figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
+ non potrà ottenere automaticamente un terminale di controllo.
\item Eseguire una \func{chdir} per impostare la directory di lavoro del
processo (su \file{/} o su una directory che contenga dei file necessari per
- il programma), per evitare che la directory da cui si è lanciato il processo
+ il programma), per evitare che la directory da cui si è lanciato il processo
resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
contiene.
\item Impostare la \itindex{umask} maschera dei permessi (di solito con
\code{umask(0)}) in modo da non essere dipendenti dal valore ereditato da
chi ha lanciato originariamente il processo.
-\item Chiudere tutti i file aperti che non servono più (in generale tutti); in
+\item Chiudere tutti i file aperti che non servono più (in generale tutti); in
particolare vanno chiusi i file standard che di norma sono ancora associati
- al terminale (un'altra opzione è quella di redirigerli verso
+ al terminale (un'altra opzione è quella di redirigerli verso
\file{/dev/null}).
\end{enumerate}
In Linux buona parte di queste azioni possono venire eseguite invocando la
funzione \funcd{daemon}, introdotta per la prima volta in BSD4.4; il suo
-prototipo è:
+prototipo è:
\begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)}
Esegue le operazioni che distaccano il processo dal terminale di controllo e
lo fanno girare come demone.
\bodydesc{La funzione restituisce (nel nuovo processo) 0 in caso di
- successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
+ successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
\end{prototype}
La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit}, nel
padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
\func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
-precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
-directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
+precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
+directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
di valori non nulli non viene eseguita nessuna altra azione.
-Dato che un programma demone non può più accedere al terminale, si pone il
-problema di come fare per la notifica di eventuali errori, non potendosi più
-utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
-le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
-e delle funzionalità che sono previste; ma gli errori devono normalmente
+Dato che un programma demone non può più accedere al terminale, si pone il
+problema di come fare per la notifica di eventuali errori, non potendosi più
+utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
+le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
+e delle funzionalità che sono previste; ma gli errori devono normalmente
essere notificati all'amministratore del sistema.
-Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
+Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
-grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
+grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
Per questo in BSD4.2 venne introdotto un servizio di sistema, il
\textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
in un sistema unix-like, viene gestito attraverso un apposito programma,
-\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
+\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
errore vengono raccolti dal file speciale \file{/dev/log}, un socket locale
(vedi sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con
un socket UDP, o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
Il servizio permette poi di trattare i vari messaggi classificandoli
attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
-da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
+da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
(kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
\textit{priority}, identifica l'importanza dei vari messaggi, e permette di
-classificarli e differenziare le modalità di notifica degli stessi.
+classificarli e differenziare le modalità di notifica degli stessi.
Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
riportare i messaggi all'amministratore attraverso una serie differenti
\item inviare ad un altro demone (anche via rete).
\item scartare.
\end{itemize*}
-secondo le modalità che questo preferisce e che possono essere impostate
+secondo le modalità che questo preferisce e che possono essere impostate
attraverso il file di configurazione \conffile{/etc/syslog.conf} (maggiori
dettagli si possono trovare sulle pagine di manuale per questo file e per
\cmd{syslogd}).
Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
-può accedere in maniera generica al servizio di \textit{syslog}, che però
+può accedere in maniera generica al servizio di \textit{syslog}, che però
funzionano solo localmente; se si vogliono inviare i messaggi ad un altro
sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
-capacità di reinvio del servizio.
+capacità di reinvio del servizio.
-La prima funzione definita dall'interfaccia è \funcd{openlog}, che apre una
-connessione al servizio di \textit{syslog}; essa in generale non è necessaria
+La prima funzione definita dall'interfaccia è \funcd{openlog}, che apre una
+connessione al servizio di \textit{syslog}; essa in generale non è necessaria
per l'uso del servizio, ma permette di impostare alcuni valori che controllano
-gli effetti delle chiamate successive; il suo prototipo è:
+gli effetti delle chiamate successive; il suo prototipo è:
\begin{prototype}{syslog.h}{void openlog(const char *ident, int option,
int facility)}
\bodydesc{La funzione non restituisce nulla.}
\end{prototype}
-La funzione permette di specificare, tramite \param{ident}, l'identità di chi
+La funzione permette di specificare, tramite \param{ident}, l'identità di chi
ha inviato il messaggio (di norma si passa il nome del programma, come
-specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
+specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
messaggio. Si tenga presente che il valore di \param{ident} che si passa alla
-funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
+funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
nei successivi messaggi, e se viene cancellata i risultati potranno essere
-impredicibili, per questo è sempre opportuno usare una stringa costante.
+impredicibili, per questo è sempre opportuno usare una stringa costante.
L'argomento \param{facility} permette invece di preimpostare per le successive
chiamate l'omonimo indice che classifica la categoria del messaggio.
-L'argomento è interpretato come una maschera binaria, e pertanto è possibile
-inviare i messaggi su più categorie alla volta; i valori delle costanti che
+L'argomento è interpretato come una maschera binaria, e pertanto è possibile
+inviare i messaggi su più categorie alla volta; i valori delle costanti che
identificano ciascuna categoria sono riportati in
tab.~\ref{tab:sess_syslog_facility}, il valore di \param{facility} deve essere
specificato con un OR aritmetico.
\hline
\hline
\const{LOG\_AUTH} & Messaggi relativi ad autenticazione e sicurezza,
- obsoleto, è sostituito da \const{LOG\_AUTHPRIV}.\\
+ obsoleto, è sostituito da \const{LOG\_AUTHPRIV}.\\
\const{LOG\_AUTHPRIV} & Sostituisce \const{LOG\_AUTH}.\\
\const{LOG\_CRON} & Messaggi dei demoni di gestione dei comandi
programmati (\cmd{cron} e \cmd{at}).\\
\end{table}
L'argomento \param{option} serve invece per controllare il comportamento della
-funzione \func{openlog} e delle modalità con cui le successive chiamate
+funzione \func{openlog} e delle modalità con cui le successive chiamate
scriveranno i messaggi, esso viene specificato come maschera binaria composta
con un OR aritmetico di una qualunque delle costanti riportate in
tab.~\ref{tab:sess_openlog_option}.
\label{tab:sess_openlog_option}
\end{table}
-La funzione che si usa per generare un messaggio è \funcd{syslog}, dato che
-l'uso di \func{openlog} è opzionale, sarà quest'ultima a provvede a chiamare la
-prima qualora ciò non sia stato fatto (nel qual caso il valore di
-\param{ident} è nullo). Il suo prototipo è:
+La funzione che si usa per generare un messaggio è \funcd{syslog}, dato che
+l'uso di \func{openlog} è opzionale, sarà quest'ultima a provvede a chiamare la
+prima qualora ciò non sia stato fatto (nel qual caso il valore di
+\param{ident} è nullo). Il suo prototipo è:
\begin{prototype}{syslog.h}
{void syslog(int priority, const char *format, ...)}
-Genera un messaggio di priorità \param{priority}.
+Genera un messaggio di priorità \param{priority}.
\bodydesc{La funzione non restituisce nulla.}
\end{prototype}
-Il comportamento della funzione è analogo quello di \func{printf}, e il valore
-dell'argomento \param{format} è identico a quello descritto nella pagina di
-manuale di quest'ultima (per i valori principali si può vedere la trattazione
-sommaria che se ne è fatto in sez.~\ref{sec:file_formatted_io}); l'unica
-differenza è che la sequenza \val{\%m} viene rimpiazzata dalla stringa
+Il comportamento della funzione è analogo quello di \func{printf}, e il valore
+dell'argomento \param{format} è identico a quello descritto nella pagina di
+manuale di quest'ultima (per i valori principali si può vedere la trattazione
+sommaria che se ne è fatto in sez.~\ref{sec:file_formatted_io}); l'unica
+differenza è che la sequenza \val{\%m} viene rimpiazzata dalla stringa
restituita da \code{strerror(errno)}. Gli argomenti seguenti i primi due
devono essere forniti secondo quanto richiesto da \param{format}.
L'argomento \param{priority} permette di impostare sia la \textit{facility}
-che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
+che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
per specificare solo quest'ultima in quanto la prima viene di norma
-preimpostata con \func{openlog}. La priorità è indicata con un valore
+preimpostata con \func{openlog}. La priorità è indicata con un valore
numerico\footnote{le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto
- diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
+ diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
questo comporta che i tre bit meno significativi dell'argomento
- \param{priority} sono occupati da questo valore, mentre i restanti bit più
+ \param{priority} sono occupati da questo valore, mentre i restanti bit più
significativi vengono usati per specificare la \textit{facility}.}
specificabile attraverso le costanti riportate in
tab.~\ref{tab:sess_syslog_priority}. Nel caso si voglia specificare anche la
-\textit{facility} basta eseguire un OR aritmetico del valore della priorità
+\textit{facility} basta eseguire un OR aritmetico del valore della priorità
con la maschera binaria delle costanti di tab.~\ref{tab:sess_syslog_facility}.
\begin{table}[htb]
\textbf{Valore}& \textbf{Significato}\\
\hline
\hline
- \const{LOG\_EMERG} & Il sistema è inutilizzabile.\\
- \const{LOG\_ALERT} & C'è una emergenza che richiede intervento
+ \const{LOG\_EMERG} & Il sistema è inutilizzabile.\\
+ \const{LOG\_ALERT} & C'è una emergenza che richiede intervento
immediato.\\
- \const{LOG\_CRIT} & Si è in una condizione critica.\\
- \const{LOG\_ERR} & Si è in una condizione di errore.\\
+ \const{LOG\_CRIT} & Si è in una condizione critica.\\
+ \const{LOG\_ERR} & Si è in una condizione di errore.\\
\const{LOG\_WARNING} & Messaggio di avvertimento.\\
\const{LOG\_NOTICE} & Notizia significativa relativa al comportamento.\\
\const{LOG\_INFO} & Messaggio informativo.\\
\end{table}
Una ulteriore funzione, \funcd{setlogmask}, permette di filtrare
-preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
+preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
\begin{prototype}{syslog.h}{int setlogmask(int mask)}
Imposta la maschera dei log al valore specificato.
\end{prototype}
Le funzioni di gestione mantengono per ogni processo una maschera che determina
-quale delle chiamate effettuate a \func{syslog} verrà effettivamente
-registrata. La registrazione viene disabilitata per tutte quelle priorità che
+quale delle chiamate effettuate a \func{syslog} verrà effettivamente
+registrata. La registrazione viene disabilitata per tutte quelle priorità che
non rientrano nella maschera; questa viene impostata 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\_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 ad un certo valore.
+priorità fino ad un certo valore.
\section{L'I/O su terminale}
\label{sec:sess_terminal_io}
-Benché come ogni altro dispositivo i terminali siano accessibili come file,
+Benché come ogni altro dispositivo i terminali siano accessibili come file,
essi hanno assunto storicamente (essendo stati a lungo l'unico modo di
-accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
+accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
di incontrare nella precedente sezione.
-Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
+Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
loro particolare natura presenta delle differenze rispetto ai normali file su
disco e agli altri dispositivi.
I terminali sono una classe speciale di dispositivi a caratteri (si ricordi la
classificazione di sez.~\ref{sec:file_file_types}); un terminale ha infatti una
caratteristica che lo contraddistingue da un qualunque altro dispositivo, e
-cioè che è destinato a gestire l'interazione con un utente (deve essere cioè
+cioè che è destinato a gestire l'interazione con un utente (deve essere cioè
in grado di fare da terminale di controllo per una sessione), che comporta la
-presenza di ulteriori capacità.
+presenza di ulteriori capacità.
-L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
+L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
stratificata dagli inizi dei sistemi Unix fino ad oggi. Questo comporta una
-grande quantità di opzioni e controlli relativi ad un insieme di
-caratteristiche (come ad esempio la velocità della linea) necessarie per
+grande quantità di opzioni e controlli relativi ad un insieme di
+caratteristiche (come ad esempio la velocità della linea) necessarie per
dispositivi, come i terminali seriali, che al giorno d'oggi sono praticamente
in disuso.
Storicamente i primi terminali erano appunto terminali di telescriventi
(\textit{teletype}), da cui deriva sia il nome dell'interfaccia, \textit{TTY},
che quello dei relativi file di dispositivo, che sono sempre della forma
-\texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
- essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
+\texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
+ essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
\file{/dev/pty[p-za-e][0-9a-f]} ed un corrispondente \textit{slave} con nome
\file{/dev/tty[p-za-e][0-9a-f]}.} Oggi essi includono le porte seriali, le
console virtuali dello schermo, i terminali virtuali che vengono creati come
connessioni di rete (ad esempio per trattare i dati inviati con \cmd{telnet} o
\cmd{ssh}).
-L'I/O sui terminali si effettua con le stesse modalità dei file normali: si
+L'I/O sui terminali si effettua con le stesse modalità dei file normali: si
apre il relativo file di dispositivo, e si leggono e scrivono i dati con le
-usuali funzioni di lettura e scrittura, così se apriamo una console virtuale
-avremo che \func{read} leggerà quanto immesso dalla tastiera, mentre
-\func{write} scriverà sullo schermo. In realtà questo è vero solo a grandi
-linee, perché non tiene conto delle caratteristiche specifiche dei terminali;
-una delle principali infatti è che essi prevedono due modalità di operazione,
+usuali funzioni di lettura e scrittura, così se apriamo una console virtuale
+avremo che \func{read} leggerà quanto immesso dalla tastiera, mentre
+\func{write} scriverà sullo schermo. In realtà questo è vero solo a grandi
+linee, perché non tiene conto delle caratteristiche specifiche dei terminali;
+una delle principali infatti è che essi prevedono due modalità di operazione,
dette rispettivamente \textsl{modo canonico} e \textsl{modo non canonico}, che
comportano dei comportamenti nettamente diversi.
-La modalità preimpostata all'apertura del terminale è quella canonica, in cui
+La modalità preimpostata all'apertura del terminale è quella canonica, in cui
le operazioni di lettura vengono sempre effettuate assemblando i dati in una
linea;\footnote{per cui eseguendo una \func{read} su un terminale in modo
- canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
+ canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
fintanto che non si preme il tasto di ritorno a capo: a questo punto la
- linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
+ linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
vengono interpretati per compiere operazioni (come la generazione dei segnali
-illustrati in sez.~\ref{sec:sig_job_control}), questa di norma è la modalità in
+illustrati in sez.~\ref{sec:sig_job_control}), questa di norma è la modalità in
cui funziona la shell.
Un terminale in modo non canonico invece non effettua nessun accorpamento dei
-dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
+dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
editor ad esempio) che necessitano di poter leggere un carattere alla volta e
che gestiscono al loro interno i vari comandi.
Per capire le caratteristiche dell'I/O sui terminali, occorre esaminare le
-modalità con cui esso viene effettuato; l'accesso, come per tutti i
-dispositivi, viene gestito da un driver apposito, la cui struttura generica è
+modalità con cui esso viene effettuato; l'accesso, come per tutti i
+dispositivi, viene gestito da un driver apposito, la cui struttura generica è
mostrata in fig.~\ref{fig:term_struct}. Ad un terminale sono sempre associate
due code per gestire l'input e l'output, che ne implementano una
bufferizzazione\footnote{completamente indipendente dalla eventuale ulteriore
\end{figure}
La coda di ingresso mantiene i caratteri che sono stati letti dal terminale ma
-non ancora letti da un processo, la sua dimensione è definita dal parametro di
+non ancora letti da un processo, la sua dimensione è definita dal parametro di
sistema \const{MAX\_INPUT} (si veda sez.~\ref{sec:sys_file_limits}), che ne
-specifica il limite minimo, in realtà la coda può essere più grande e cambiare
-dimensione dinamicamente. Se è stato abilitato il controllo di flusso in
+specifica il limite minimo, in realtà la coda può essere più grande e cambiare
+dimensione dinamicamente. Se è stato abilitato il controllo di flusso in
ingresso il driver emette i caratteri di STOP e START per bloccare e sbloccare
l'ingresso dei dati; altrimenti i caratteri immessi oltre le dimensioni
massime vengono persi; in alcuni casi il driver provvede ad inviare
automaticamente un avviso (un carattere di BELL, che provoca un beep)
-sull'output quando si eccedono le dimensioni della coda. Se è abilitato il
+sull'output quando si eccedono le dimensioni della coda. Se è abilitato il
modo canonico i caratteri in ingresso restano nella coda fintanto che non
viene ricevuto un a capo; un altro parametro del sistema, \const{MAX\_CANON},
specifica la dimensione massima di una riga in modo canonico.
-La coda di uscita è analoga a quella di ingresso e contiene i caratteri
-scritti dai processi ma non ancora inviati al terminale. Se è abilitato il
+La coda di uscita è analoga a quella di ingresso e contiene i caratteri
+scritti dai processi ma non ancora inviati al terminale. Se è abilitato il
controllo di flusso in uscita il driver risponde ai caratteri di START e STOP
inviati dal terminale. Le dimensioni della coda non sono specificate, ma non
hanno molta importanza, in quanto qualora esse vengano eccedute il driver
\subsection{La gestione delle caratteristiche di un terminale}
\label{sec:term_attr}
-Data le loro peculiarità, fin dall'inizio si è posto il problema di come
+Data le loro peculiarità, fin dall'inizio si è posto il problema di come
gestire le caratteristiche specifiche dei terminali; storicamente i vari
-dialetti di Unix hanno utilizzato diverse funzioni, alla fine con POSIX.1, è
+dialetti di Unix hanno utilizzato diverse funzioni, alla fine con POSIX.1, è
stata effettuata una standardizzazione, unificando le differenze fra BSD e
-System V in una unica interfaccia, che è quella usata dal Linux.
+System V in una unica interfaccia, che è quella usata dal Linux.
Alcune di queste funzioni prendono come argomento un file descriptor (in
origine molte operazioni venivano effettuate con \func{ioctl}), ma ovviamente
possono essere usate solo con file che corrispondano effettivamente ad un
-terminale (altrimenti si otterrà un errore di \errcode{ENOTTY}); questo può
-essere evitato utilizzando la funzione \funcd{isatty}, il cui prototipo è:
+terminale (altrimenti si otterrà un errore di \errcode{ENOTTY}); questo può
+essere evitato utilizzando la funzione \funcd{isatty}, il cui prototipo è:
\begin{prototype}{unistd.h}{int isatty(int desc)}
- Controlla se il file descriptor \param{desc} è un terminale.
+ Controlla se il file descriptor \param{desc} è un terminale.
-\bodydesc{La funzione restituisce 1 se \param{desc} è connesso ad un
+\bodydesc{La funzione restituisce 1 se \param{desc} è connesso ad un
terminale, 0 altrimenti.}
\end{prototype}
-Un'altra funzione che fornisce informazioni su un terminale è \funcd{ttyname},
+Un'altra funzione che fornisce informazioni su un terminale è \funcd{ttyname},
che permette di ottenere il nome del terminale associato ad un file
-descriptor; il suo prototipo è:
+descriptor; il suo prototipo è:
\begin{prototype}{unistd.h}{char *ttyname(int desc)}
Restituisce il nome del terminale associato al file \param{desc}.
Si tenga presente che la funzione restituisce un indirizzo di dati statici,
che pertanto possono essere sovrascritti da successive chiamate. Una funzione
-funzione analoga, anch'essa prevista da POSIX.1, è \funcd{ctermid}, il cui
-prototipo è:
+funzione analoga, anch'essa prevista da POSIX.1, è \funcd{ctermid}, il cui
+prototipo è:
\begin{prototype}{stdio.h}{char *ctermid(char *s)}
Restituisce il nome del terminale di controllo del processo.
controllo del processo chiamante nella stringa posta all'indirizzo specificato
dall'argomento \param{s}. La memoria per contenere la stringa deve essere
stata allocata in precedenza ed essere lunga almeno
-\const{L\_ctermid}\footnote{\const{L\_ctermid} è una delle varie costanti del
+\const{L\_ctermid}\footnote{\const{L\_ctermid} è una delle varie costanti del
sistema, non trattata esplicitamente in sez.~\ref{sec:sys_characteristics}
che indica la dimensione che deve avere una stringa per poter contenere il
nome di un terminale.} caratteri.
Esiste infine una versione \index{funzioni!rientranti} rientrante
\funcd{ttyname\_r} della funzione \func{ttyname}, che non presenta il problema
-dell'uso di una zona di memoria statica; il suo prototipo è:
+dell'uso di una zona di memoria statica; il suo prototipo è:
\begin{prototype}{unistd.h}{int ttyname\_r(int desc, char *buff, size\_t len)}
Restituisce il nome del terminale associato al file \param{desc}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ERANGE}] la lunghezza del buffer, \param{len}, non è
+ \item[\errcode{ERANGE}] la lunghezza del buffer, \param{len}, non è
sufficiente per contenere la stringa restituita.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{ENOSYS}.
\end{prototype}
La funzione prende due argomenti, il puntatore alla zona di memoria
-\param{buff}, in cui l'utente vuole che il risultato venga scritto (dovrà
+\param{buff}, in cui l'utente vuole che il risultato venga scritto (dovrà
ovviamente essere stata allocata in precedenza), e la relativa dimensione,
\param{len}; se la stringa che deve essere restituita eccede questa dimensione
-si avrà una condizione di errore.
+si avrà una condizione di errore.
Se si passa come argomento \val{NULL} la funzione restituisce il puntatore ad
-una stringa statica che può essere sovrascritta da chiamate successive. Si
+una stringa statica che può essere sovrascritta da chiamate successive. Si
tenga presente che il \itindex{pathname} \textit{pathname} restituito
potrebbe non identificare univocamente il terminale (ad esempio potrebbe
-essere \file{/dev/tty}), inoltre non è detto che il processo possa
+essere \file{/dev/tty}), inoltre non è detto che il processo possa
effettivamente aprire il terminale.
I vari attributi vengono mantenuti per ciascun terminale in una struttura
-\struct{termios}, (la cui definizione è riportata in
+\struct{termios}, (la cui definizione è riportata in
fig.~\ref{fig:term_termios}), usata dalle varie funzioni dell'interfaccia. In
fig.~\ref{fig:term_termios} si sono riportati tutti i campi della definizione
usata in Linux; di questi solo i primi cinque sono previsti dallo standard
ulteriori informazioni.\footnote{la definizione della struttura si trova in
\file{bits/termios.h}, da non includere mai direttamente, Linux, seguendo
l'esempio di BSD, aggiunge i due campi \var{c\_ispeed} e \var{c\_ospeed} per
- mantenere le velocità delle linee seriali, ed un campo ulteriore,
+ mantenere le velocità delle linee seriali, ed un campo ulteriore,
\var{c\_line} per ... (NdT, trovare a che serve).}
% TODO trovare a che serve
\includestruct{listati/termios.h}
\end{minipage}
\normalsize
- \caption{La struttura \structd{termios}, che identifica le proprietà di un
+ \caption{La struttura \structd{termios}, che identifica le proprietà di un
terminale.}
\label{fig:term_termios}
\end{figure}
I primi quattro campi sono quattro flag che controllano il comportamento del
terminale; essi sono realizzati come maschera binaria, pertanto il tipo
-\type{tcflag\_t} è di norma realizzato con un intero senza segno di lunghezza
+\type{tcflag\_t} è di norma realizzato con un intero senza segno di lunghezza
opportuna. I valori devono essere specificati bit per bit, avendo cura di non
modificare i bit su cui non si interviene.
\textbf{Valore}& \textbf{Significato}\\
\hline
\hline
- \const{INPCK} & Abilita il controllo di parità in ingresso. Se non viene
+ \const{INPCK} & Abilita il controllo di parità in ingresso. Se non viene
impostato non viene fatto nessun controllo ed i caratteri
vengono passati in input direttamente.\\
- \const{IGNPAR} & Ignora gli errori di parità, il carattere viene passato
- come ricevuto. Ha senso solo se si è impostato
+ \const{IGNPAR} & Ignora gli errori di parità, il carattere viene passato
+ come ricevuto. Ha senso solo se si è impostato
\const{INPCK}.\\
- \const{PARMRK} & Controlla come vengono riportati gli errori di parità. Ha
- senso solo se \const{INPCK} è impostato e \const{IGNPAR}
+ \const{PARMRK} & Controlla come vengono riportati gli errori di parità. Ha
+ senso solo se \const{INPCK} è impostato e \const{IGNPAR}
no. Se impostato inserisce una sequenza \texttt{0xFF
0x00} prima di ogni carattere che presenta errori di
- parità, se non impostato un carattere con errori di
- parità viene letto come uno \texttt{0x00}. Se un
+ parità, se non impostato un carattere con errori di
+ parità viene letto come uno \texttt{0x00}. Se un
carattere ha il valore \texttt{0xFF} e \const{ISTRIP}
- non è impostato, per evitare ambiguità esso viene sempre
+ non è impostato, per evitare ambiguità esso viene sempre
riportato come \texttt{0xFF 0xFF}.\\
\const{ISTRIP} & Se impostato i caratteri in input sono tagliati a sette
- bit mettendo a zero il bit più significativo, altrimenti
+ bit mettendo a zero il bit più significativo, altrimenti
vengono passati tutti gli otto bit.\\
\const{IGNBRK} & Ignora le condizioni di BREAK sull'input. Una
- \textit{condizione di BREAK} è definita nel contesto di
+ \textit{condizione di BREAK} è definita nel contesto di
una trasmissione seriale asincrona come una sequenza di
- bit nulli più lunga di un byte.\\
+ bit nulli più lunga di un byte.\\
\const{BRKINT} & Controlla la reazione ad un BREAK quando
- \const{IGNBRK} non è impostato. Se \const{BRKINT} è
+ \const{IGNBRK} non è impostato. Se \const{BRKINT} è
impostato il BREAK causa lo scarico delle code,
- e se il terminale è il terminale di controllo per un
+ e se il terminale è il terminale di controllo per un
gruppo in foreground anche l'invio di \const{SIGINT} ai
- processi di quest'ultimo. Se invece \const{BRKINT} non è
+ processi di quest'ultimo. Se invece \const{BRKINT} non è
impostato un BREAK viene letto come un carattere
NUL, a meno che non sia impostato \const{PARMRK}
nel qual caso viene letto come la sequenza di caratteri
\texttt{0xFF 0x00 0x00}.\\
\const{IGNCR} & Se impostato il carattere di ritorno carrello
(\textit{carriage return}, \verb|'\r'|) viene scartato
- dall'input. Può essere utile per i terminali che inviano
+ dall'input. Può essere utile per i terminali che inviano
entrambi i caratteri di ritorno carrello e a capo
(\textit{newline}, \verb|'\n'|).\\
\const{ICRNL} & Se impostato un carattere di ritorno carrello
bloccare l'input dal terminale e lo sblocca con il
carattere START.\\
\const{IMAXBEL}& Se impostato fa suonare il cicalino se si riempie la cosa
- di ingresso; in Linux non è implementato e il kernel si
- comporta cose se fosse sempre impostato (è una estensione
+ di ingresso; in Linux non è implementato e il kernel si
+ comporta cose se fosse sempre impostato (è una estensione
BSD).\\
\hline
\end{tabular}
\caption{Costanti identificative dei vari bit del flag di controllo
- \var{c\_iflag} delle modalità di input di un terminale.}
+ \var{c\_iflag} delle modalità di input di un terminale.}
\label{tab:sess_termios_iflag}
\end{table}
-Il primo flag, mantenuto nel campo \var{c\_iflag}, è detto \textsl{flag di
- input} e controlla le modalità di funzionamento dell'input dei caratteri sul
-terminale, come il controllo di parità, il controllo di flusso, la gestione
+Il primo flag, mantenuto nel campo \var{c\_iflag}, è detto \textsl{flag di
+ input} e controlla le modalità di funzionamento dell'input dei caratteri sul
+terminale, come il controllo di parità, il controllo di flusso, la gestione
dei caratteri speciali; un elenco dei vari bit, del loro significato e delle
-costanti utilizzate per identificarli è riportato in
+costanti utilizzate per identificarli è riportato in
tab.~\ref{tab:sess_termios_iflag}.
Si noti come alcuni di questi flag (come quelli per la gestione del flusso)
fanno riferimento a delle caratteristiche che ormai sono completamente
-obsolete; la maggior parte inoltre è tipica di terminali seriali, e non ha
+obsolete; la maggior parte inoltre è tipica di terminali seriali, e non ha
alcun effetto su dispositivi diversi come le console virtuali o gli
pseudo-terminali usati nelle connessioni di rete.
\const{OPOST} & Se impostato i caratteri vengono convertiti opportunamente
(in maniera dipendente dall'implementazione) per la
visualizzazione sul terminale, ad esempio al
- carattere di a capo (NL) può venire aggiunto un ritorno
+ carattere di a capo (NL) può venire aggiunto un ritorno
carrello (CR).\\
\const{OCRNL} & Se impostato converte automaticamente il carattere di a
capo (NL) nella coppia di caratteri ritorno carrello, a
carrello (CR).\\
\const{OFILL} & Se impostato in caso di ritardo sulla linea invia dei
caratteri di riempimento invece di attendere.\\
- \const{OFDEL} & Se impostato il carattere di riempimento è DEL
+ \const{OFDEL} & Se impostato il carattere di riempimento è DEL
(\texttt{0x3F}), invece che NUL (\texttt{0x00}).\\
\const{NLDLY} & Maschera per i bit che indicano il ritardo per il
carattere di a capo (NL), i valori possibili sono
\hline
\end{tabular}
\caption{Costanti identificative dei vari bit del flag di controllo
- \var{c\_oflag} delle modalità di output di un terminale.}
+ \var{c\_oflag} delle modalità di output di un terminale.}
\label{tab:sess_termios_oflag}
\end{table}
-Il secondo flag, mantenuto nel campo \var{c\_oflag}, è detto \textsl{flag di
- output} e controlla le modalità di funzionamento dell'output dei caratteri,
+Il secondo flag, mantenuto nel campo \var{c\_oflag}, è detto \textsl{flag di
+ output} e controlla le modalità di funzionamento dell'output dei caratteri,
come l'impacchettamento dei caratteri sullo schermo, la traslazione degli a
capo, la conversione dei caratteri speciali; un elenco dei vari bit, del loro
-significato e delle costanti utilizzate per identificarli è riportato in
+significato e delle costanti utilizzate per identificarli è riportato in
tab.~\ref{tab:sess_termios_oflag}.
Si noti come alcuni dei valori riportati in tab.~\ref{tab:sess_termios_oflag}
\var{c\_oflag} deve essere fornito avendo cura di cancellare prima tutti i bit
della maschera, i valori da immettere infatti (quelli riportati nella
spiegazione corrispondente) sono numerici e non per bit, per cui possono
-sovrapporsi fra di loro. Occorrerà perciò utilizzare un codice del tipo:
+sovrapporsi fra di loro. Occorrerà perciò utilizzare un codice del tipo:
\includecodesnip{listati/oflag.c}
\textbf{Valore}& \textbf{Significato}\\
\hline
\hline
- \const{CLOCAL} & Se impostato indica che il terminale è connesso in locale
+ \const{CLOCAL} & Se impostato indica che il terminale è connesso in locale
e che le linee di controllo del modem devono essere
ignorate. Se non impostato effettuando una chiamata ad
\func{open} senza aver specificato il flag di
- \const{O\_NOBLOCK} si bloccherà il processo finché
- non si è stabilita una connessione con il modem; inoltre
+ \const{O\_NOBLOCK} si bloccherà il processo finché
+ non si è stabilita una connessione con il modem; inoltre
se viene rilevata una disconnessione viene inviato un
segnale di \const{SIGHUP} al processo di controllo del
terminale. La lettura su un terminale sconnesso comporta
una condizione di \textit{end of file} e la scrittura un
errore di \errcode{EIO}.\\
- \const{HUPCL} & Se è impostato viene distaccata la connessione del
+ \const{HUPCL} & Se è impostato viene distaccata la connessione del
modem quando l'ultimo dei processi che ha ancora un file
aperto sul terminale lo chiude o esce.\\
- \const{CREAD} & Se è impostato si può leggere l'input del terminale,
+ \const{CREAD} & Se è impostato si può leggere l'input del terminale,
altrimenti i caratteri in ingresso vengono scartati
quando arrivano.\\
\const{CSTOPB} & Se impostato vengono usati due bit di stop sulla linea
seriale, se non impostato ne viene usato soltanto uno.\\
\const{PARENB} & Se impostato abilita la generazione il controllo di
- parità. La reazione in caso di errori dipende dai
+ parità. La reazione in caso di errori dipende dai
relativi valori per \var{c\_iflag}, riportati in
- tab.~\ref{tab:sess_termios_iflag}. Se non è impostato i
- bit di parità non vengono generati e i caratteri non
+ tab.~\ref{tab:sess_termios_iflag}. Se non è impostato i
+ bit di parità non vengono generati e i caratteri non
vengono controllati.\\
- \const{PARODD} & Ha senso solo se è attivo anche \const{PARENB}. Se
- impostato viene usata una parità è dispari, altrimenti
- viene usata una parità pari.\\
+ \const{PARODD} & Ha senso solo se è attivo anche \const{PARENB}. Se
+ impostato viene usata una parità è dispari, altrimenti
+ viene usata una parità pari.\\
\const{CSIZE} & Maschera per i bit usati per specificare la dimensione
del carattere inviato lungo la linea di trasmissione, i
valore ne indica la lunghezza (in bit), ed i valori
possibili sono \val{CS5}, \val{CS6}, \val{CS7} e \val{CS8}
corrispondenti ad un analogo numero di bit.\\
- \const{CBAUD} & Maschera dei bit (4+1) usati per impostare della velocità
+ \const{CBAUD} & Maschera dei bit (4+1) usati per impostare della velocità
della linea (il \textit{baud rate}) in ingresso; in Linux
- non è implementato in quanto viene usato un apposito
+ non è implementato in quanto viene usato un apposito
campo di \struct{termios}.\\
- \const{CBAUDEX}& Bit aggiuntivo per l'impostazione della velocità della
- linea, per le stesse motivazioni del precedente non è
+ \const{CBAUDEX}& Bit aggiuntivo per l'impostazione della velocità della
+ linea, per le stesse motivazioni del precedente non è
implementato in Linux.\\
- \const{CIBAUD} & Maschera dei bit della velocità della linea in
- ingresso; analogo a \const{CBAUD}, anch'esso in Linux è
+ \const{CIBAUD} & Maschera dei bit della velocità della linea in
+ ingresso; analogo a \const{CBAUD}, anch'esso in Linux è
mantenuto in un apposito campo di \struct{termios}.\\
\const{CRTSCTS}& Abilita il controllo di flusso hardware sulla seriale,
attraverso l'utilizzo delle dei due fili di RTS e CTS.\\
\hline
\end{tabular}
\caption{Costanti identificative dei vari bit del flag di controllo
- \var{c\_cflag} delle modalità di controllo di un terminale.}
+ \var{c\_cflag} delle modalità di controllo di un terminale.}
\label{tab:sess_termios_cflag}
\end{table}
-Il terzo flag, mantenuto nel campo \var{c\_cflag}, è detto \textsl{flag di
- controllo} ed è legato al funzionamento delle linee seriali, permettendo di
+Il terzo flag, mantenuto nel campo \var{c\_cflag}, è detto \textsl{flag di
+ controllo} ed è legato al funzionamento delle linee seriali, permettendo di
impostarne varie caratteristiche, come il numero di bit di stop, le
-impostazioni della parità, il funzionamento del controllo di flusso; esso ha
+impostazioni della parità, il funzionamento del controllo di flusso; esso ha
senso solo per i terminali connessi a linee seriali. Un elenco dei vari bit,
-del loro significato e delle costanti utilizzate per identificarli è riportato
+del loro significato e delle costanti utilizzate per identificarli è riportato
in tab.~\ref{tab:sess_termios_cflag}.
I valori di questo flag sono molto specifici, e completamente indirizzati al
Inoltre alcuni valori sono previsti solo per quelle implementazioni (lo
standard POSIX non specifica nulla riguardo l'implementazione, ma solo delle
-funzioni di lettura e scrittura) che mantengono le velocità delle linee
+funzioni di lettura e scrittura) che mantengono le velocità delle linee
seriali all'interno dei flag; come accennato in Linux questo viene fatto
(seguendo l'esempio di BSD) attraverso due campi aggiuntivi, \var{c\_ispeed} e
\var{c\_ospeed}, nella struttura \struct{termios} (mostrati in
\hline
\const{ICANON} & Se impostato il terminale opera in modo canonico,
altrimenti opera in modo non canonico.\\
- \const{ECHO} & Se è impostato viene attivato l'eco dei caratteri in
+ \const{ECHO} & Se è impostato viene attivato l'eco dei caratteri in
input sull'output del terminale.\\
- \const{ECHOE} & Se è impostato l'eco mostra la cancellazione di un
+ \const{ECHOE} & Se è impostato l'eco mostra la cancellazione di un
carattere in input (in reazione al carattere ERASE)
cancellando l'ultimo carattere della riga corrente dallo
- schermo; altrimenti il carattere è rimandato in eco per
+ schermo; altrimenti il carattere è rimandato in eco per
mostrare quanto accaduto (usato per i terminali con
l'uscita su una stampante).\\
\const{ECHOPRT}& Se impostato abilita la visualizzazione del carattere di
- cancellazione in una modalità adatta ai terminali con
+ cancellazione in una modalità adatta ai terminali con
l'uscita su stampante; l'invio del carattere di ERASE
comporta la stampa di un ``\texttt{|}'' seguito dal
- carattere cancellato, e così via in caso di successive
+ carattere cancellato, e così via in caso di successive
cancellazioni, quando si riprende ad immettere carattere
- normali prima verrà stampata una ``\texttt{/}''.\\
+ normali prima verrà stampata una ``\texttt{/}''.\\
\const{ECHOK} & Se impostato abilita il trattamento della visualizzazione
del carattere KILL, andando a capo dopo aver visualizzato
lo stesso, altrimenti viene solo mostrato il carattere e
- sta all'utente ricordare che l'input precedente è stato
+ sta all'utente ricordare che l'input precedente è stato
cancellato.\\
\const{ECHOKE} & Se impostato abilita il trattamento della visualizzazione
del carattere KILL cancellando i caratteri precedenti
- nella linea secondo le modalità specificate dai valori di
+ nella linea secondo le modalità specificate dai valori di
\const{ECHOE} e \const{ECHOPRT}.\\
\const{ECHONL} & Se impostato viene effettuato l'eco di un a
- capo (\verb|\n|) anche se non è stato impostato
+ capo (\verb|\n|) anche se non è stato impostato
\const{ECHO}.\\
\const{ECHOCTL}& Se impostato insieme ad \const{ECHO} i caratteri di
controllo ASCII (tranne TAB, NL, START, e STOP) sono
mostrati nella forma che prepone un ``\texttt{\circonf}''
alla lettera ottenuta sommando \texttt{0x40} al valore del
carattere (di solito questi si possono ottenere anche
- direttamente premendo il tasto \texttt{ctrl} più la
+ direttamente premendo il tasto \texttt{ctrl} più la
relativa lettera).\\
\const{ISIG} & Se impostato abilita il riconoscimento dei caratteri
INTR, QUIT, e SUSP generando il relativo segnale.\\
\const{IEXTEN} & Abilita alcune estensioni previste dalla
- implementazione. Deve essere impostato perché caratteri
+ implementazione. Deve essere impostato perché caratteri
speciali come EOL2, LNEXT, REPRINT e WERASE possano
essere interpretati.\\
\const{NOFLSH} & Se impostato disabilita lo scarico delle code di ingresso
genera il segnale \const{SIGTTOU} per un processo in
background che cerca di scrivere sul terminale.\\
\const{XCASE} & Se impostato il terminale funziona solo con le
- maiuscole. L'input è convertito in minuscole tranne per i
+ maiuscole. L'input è convertito in minuscole tranne per i
caratteri preceduti da una ``\texttt{\bslash}''. In output
le maiuscole sono precedute da una ``\texttt{\bslash}'' e
le minuscole convertite in maiuscole.\\
- \const{DEFECHO}& Se impostato effettua l'eco solo se c'è un processo in
+ \const{DEFECHO}& Se impostato effettua l'eco solo se c'è un processo in
lettura.\\
\const{FLUSHO} & Effettua la cancellazione della coda di uscita. Viene
- attivato dal carattere DISCARD. Non è supportato in
+ attivato dal carattere DISCARD. Non è supportato in
Linux.\\
\const{PENDIN} & Indica che la linea deve essere ristampata, viene
attivato dal carattere REPRINT e resta attivo fino alla
- fine della ristampa. Non è supportato in Linux.\\
+ fine della ristampa. Non è supportato in Linux.\\
\hline
\end{tabular}
\caption{Costanti identificative dei vari bit del flag di controllo
- \var{c\_lflag} delle modalità locali di un terminale.}
+ \var{c\_lflag} delle modalità locali di un terminale.}
\label{tab:sess_termios_lflag}
\end{table}
-Il quarto flag, mantenuto nel campo \var{c\_lflag}, è detto \textsl{flag
+Il quarto flag, mantenuto nel campo \var{c\_lflag}, è detto \textsl{flag
locale}, e serve per controllare il funzionamento dell'interfaccia fra il
driver e l'utente, come abilitare l'eco, gestire i caratteri di controllo e
l'emissione dei segnali, impostare modo canonico o non canonico; un elenco dei
-vari bit, del loro significato e delle costanti utilizzate per identificarli è
+vari bit, del loro significato e delle costanti utilizzate per identificarli è
riportato in tab.~\ref{tab:sess_termios_lflag}. Con i terminali odierni l'unico
-flag con cui probabilmente si può avere a che fare è questo, in quanto è con
+flag con cui probabilmente si può avere a che fare è questo, in quanto è con
questo che si impostano le caratteristiche generiche comuni a tutti i
terminali.
-Si tenga presente che i flag che riguardano le modalità di eco dei caratteri
+Si tenga presente che i flag che riguardano le modalità di eco dei caratteri
(\const{ECHOE}, \const{ECHOPRT}, \const{ECHOK}, \const{ECHOKE},
\const{ECHONL}) controllano solo il comportamento della visualizzazione, il
-riconoscimento dei vari caratteri dipende dalla modalità di operazione, ed
+riconoscimento dei vari caratteri dipende dalla modalità di operazione, ed
avviene solo in modo canonico, pertanto questi flag non hanno significato se
-non è impostato \const{ICANON}.
+non è impostato \const{ICANON}.
Oltre ai vari flag per gestire le varie caratteristiche dei terminali,
\struct{termios} contiene pure il campo \var{c\_cc} che viene usato per
impostare i caratteri speciali associati alle varie funzioni di controllo. Il
-numero di questi caratteri speciali è indicato dalla costante \const{NCCS},
+numero di questi caratteri speciali è indicato dalla costante \const{NCCS},
POSIX ne specifica almeno 11, ma molte implementazioni ne definiscono molti
-altri.\footnote{in Linux il valore della costante è 32, anche se i caratteri
+altri.\footnote{in Linux il valore della costante è 32, anche se i caratteri
effettivamente definiti sono solo 17.}
\begin{table}[htb]
l'invio del contenuto del
buffer di ingresso al
processo in lettura anche se
- non è ancora stato ricevuto
- un a capo. Se è il primo
+ non è ancora stato ricevuto
+ un a capo. Se è il primo
carattere immesso comporta il
ritorno di \func{read} con
- zero caratteri, cioè la
+ zero caratteri, cioè la
condizione di
\textit{end-of-file}.\\
\const{VTIME} & --- & --- & Timeout, in decimi di secondo, per
\const{SIGTSTP}.\\
\const{VEOL} &\texttt{0x00}& NUL & Carattere di fine riga. Agisce come
un a capo, ma non viene scartato ed
- è letto come l'ultimo carattere
+ è letto come l'ultimo carattere
nella riga.\\
\const{VREPRINT}&\texttt{0x12}&(\texttt{C-r})& Ristampa i caratteri non
ancora letti.\\
direttamente all'output.\\
\const{VEOL2} &\texttt{0x00}& NUL & Ulteriore carattere di fine
riga. Ha lo stesso effetto di
- \const{VEOL} ma può essere un
+ \const{VEOL} ma può essere un
carattere diverso. \\
\hline
\end{tabular}
A ciascuna di queste funzioni di controllo corrisponde un elemento del vettore
-\var{c\_cc} che specifica quale è il carattere speciale associato; per
-portabilità invece di essere indicati con la loro posizione numerica nel
+\var{c\_cc} che specifica quale è il carattere speciale associato; per
+portabilità invece di essere indicati con la loro posizione numerica nel
vettore, i vari elementi vengono indicizzati attraverso delle opportune
costanti, il cui nome corrisponde all'azione ad essi associata. Un elenco
-completo dei caratteri di controllo, con le costanti e delle funzionalità
-associate è riportato in tab.~\ref{tab:sess_termios_cc}, usando quelle
+completo dei caratteri di controllo, con le costanti e delle funzionalità
+associate è riportato in tab.~\ref{tab:sess_termios_cc}, usando quelle
definizioni diventa possibile assegnare un nuovo carattere di controllo con un
codice del tipo:
\includecodesnip{listati/value_c_cc.c}
Per leggere ed scrivere tutte le varie impostazioni dei terminali viste finora
lo standard POSIX prevede due funzioni che utilizzano come argomento un
-puntatore ad una struttura \struct{termios} che sarà quella in cui andranno
+puntatore ad una struttura \struct{termios} che sarà quella in cui andranno
immagazzinate le impostazioni. Le funzioni sono \funcd{tcgetattr} e
-\funcd{tcsetattr} ed il loro prototipo è:
+\funcd{tcsetattr} ed il loro prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
Scrive le impostazioni di un terminale.
\bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
- caso di errore, nel qual caso \var{errno} assumerà i valori:
+ caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta.
+ \item[\errcode{EINTR}] la funzione è stata interrotta.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{ENOTTY} ed \errval{EINVAL}.
}
Le funzioni operano sul terminale cui fa riferimento il file descriptor
\param{fd} utilizzando la struttura indicata dal puntatore \param{termios\_p}
per lo scambio dei dati. Si tenga presente che le impostazioni sono associate
-al terminale e non al file descriptor; questo significa che se si è cambiata
+al terminale e non al file descriptor; questo significa che se si è cambiata
una impostazione un qualunque altro processo che apra lo stesso terminale, od
-un qualunque altro file descriptor che vi faccia riferimento, vedrà le nuove
-impostazioni pur non avendo nulla a che fare con il file descriptor che si è
+un qualunque altro file descriptor che vi faccia riferimento, vedrà le nuove
+impostazioni pur non avendo nulla a che fare con il file descriptor che si è
usato per effettuare i cambiamenti.
-Questo significa che non è possibile usare file descriptor diversi per
-utilizzare automaticamente il terminale in modalità diverse, se esiste una
-necessità di accesso differenziato di questo tipo occorrerà cambiare
-esplicitamente la modalità tutte le volte che si passa da un file descriptor
+Questo significa che non è possibile usare file descriptor diversi per
+utilizzare automaticamente il terminale in modalità diverse, se esiste una
+necessità di accesso differenziato di questo tipo occorrerà cambiare
+esplicitamente la modalità tutte le volte che si passa da un file descriptor
ad un altro.
La funzione \func{tcgetattr} legge i valori correnti delle impostazioni di un
terminale qualunque nella struttura puntata da \param{termios\_p};
\func{tcsetattr} invece effettua la scrittura delle impostazioni e quando
-viene invocata sul proprio terminale di controllo può essere eseguita con
+viene invocata sul proprio terminale di controllo può essere eseguita con
successo solo da un processo in foreground. Se invocata da un processo in
-background infatti tutto il gruppo riceverà un segnale di \const{SIGTTOU} come
+background infatti tutto il gruppo riceverà un segnale di \const{SIGTTOU} come
se si fosse tentata una scrittura, a meno che il processo chiamante non abbia
-\const{SIGTTOU} ignorato o bloccato, nel qual caso l'operazione sarà eseguita.
+\const{SIGTTOU} ignorato o bloccato, nel qual caso l'operazione sarà eseguita.
-La funzione \func{tcsetattr} prevede tre diverse modalità di funzionamento,
+La funzione \func{tcsetattr} prevede tre diverse modalità di funzionamento,
specificabili attraverso l'argomento \param{optional\_actions}, che permette
di stabilire come viene eseguito il cambiamento delle impostazioni del
terminale, i valori possibili sono riportati in
\hline
\const{TCSANOW} & Esegue i cambiamenti in maniera immediata.\\
\const{TCSADRAIN}& I cambiamenti vengono eseguiti dopo aver atteso che
- tutto l'output presente sulle code è stato scritto.\\
- \const{TCSAFLUSH}& È identico a \const{TCSADRAIN}, ma in più scarta
+ tutto l'output presente sulle code è stato scritto.\\
+ \const{TCSAFLUSH}& È identico a \const{TCSADRAIN}, ma in più scarta
tutti i dati presenti sulla coda di input.\\
\hline
\end{tabular}
\end{table}
Occorre infine tenere presente che \func{tcsetattr} ritorna con successo anche
-se soltanto uno dei cambiamenti richiesti è stato eseguito. Pertanto se si
-effettuano più cambiamenti è buona norma controllare con una ulteriore
+se soltanto uno dei cambiamenti richiesti è stato eseguito. Pertanto se si
+effettuano più cambiamenti è buona norma controllare con una ulteriore
chiamata a \func{tcgetattr} che essi siano stati eseguiti tutti quanti.
\begin{figure}[!htb]
\label{fig:term_set_attr}
\end{figure}
-Come già accennato per i cambiamenti effettuati ai vari flag di controllo
+Come già accennato per i cambiamenti effettuati ai vari flag di controllo
occorre che i valori di ciascun bit siano specificati avendo cura di mantenere
intatti gli altri; per questo motivo in generale si deve prima leggere il
valore corrente delle impostazioni con \func{tcgetattr} per poi modificare i
valori impostati.
-In fig.~\ref{fig:term_set_attr} e fig.~\ref{fig:term_unset_attr} si è riportato
+In fig.~\ref{fig:term_set_attr} e fig.~\ref{fig:term_unset_attr} si è riportato
rispettivamente il codice delle due funzioni \func{SetTermAttr} e
\func{UnSetTermAttr}, che possono essere usate per impostare o rimuovere, con
le dovute precauzioni, un qualunque bit di \var{c\_lflag}. Il codice di
-entrambe le funzioni può essere trovato nel file \file{SetTermAttr.c} dei
+entrambe le funzioni può essere trovato nel file \file{SetTermAttr.c} dei
sorgenti allegati.
La funzione \func{SetTermAttr} provvede ad impostare il bit specificato
dall'argomento \param{flag}; prima si leggono i valori correnti
(\texttt{\small 10}) con \func{tcgetattr}, uscendo con un messaggio in caso di
errore (\texttt{\small 11--14}), poi si provvede a impostare solo i bit
-richiesti (possono essere più di uno) con un OR binario (\texttt{\small 15});
+richiesti (possono essere più di uno) con un OR binario (\texttt{\small 15});
infine si scrive il nuovo valore modificato con \func{tcsetattr}
(\texttt{\small 16}), notificando un eventuale errore (\texttt{\small 11--14})
o uscendo normalmente.
\label{fig:term_unset_attr}
\end{figure}
-La seconda funzione, \func{UnSetTermAttr}, è assolutamente identica alla
+La seconda funzione, \func{UnSetTermAttr}, è assolutamente identica alla
prima, solo che in questo caso, in (\texttt{\small 15}), si rimuovono i bit
specificati dall'argomento \param{flag} usando un AND binario del valore
negato.
Al contrario di tutte le altre caratteristiche dei terminali, che possono
essere impostate esplicitamente utilizzando gli opportuni campi di
-\struct{termios}, per le velocità della linea (il cosiddetto \textit{baud
- rate}) non è prevista una implementazione standardizzata, per cui anche se
+\struct{termios}, per le velocità della linea (il cosiddetto \textit{baud
+ rate}) non è prevista una implementazione standardizzata, per cui anche se
in Linux sono mantenute in due campi dedicati nella struttura, questi non
devono essere acceduti direttamente ma solo attraverso le apposite funzioni di
interfaccia provviste da POSIX.1.
-Lo standard prevede due funzioni per scrivere la velocità delle linee seriali,
-\funcd{cfsetispeed} per la velocità della linea di ingresso e
-\funcd{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
+Lo standard prevede due funzioni per scrivere la velocità delle linee seriali,
+\funcd{cfsetispeed} per la velocità della linea di ingresso e
+\funcd{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
\funcdecl{int cfsetispeed(struct termios *termios\_p, speed\_t speed)}
- Imposta la velocità delle linee seriali in ingresso.
+ Imposta la velocità delle linee seriali in ingresso.
\funcdecl{int cfsetospeed(struct termios *termios\_p, speed\_t speed)}
- Imposta la velocità delle linee seriali in uscita.
+ Imposta la velocità delle linee seriali in uscita.
\bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
- caso di errore, che avviene solo quando il valore specificato non è
+ caso di errore, che avviene solo quando il valore specificato non è
valido.}
\end{functions}
Si noti che le funzioni si limitano a scrivere opportunamente il valore della
-velocità prescelta \param{speed} all'interno della struttura puntata da
-\param{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
+velocità prescelta \param{speed} all'interno della struttura puntata da
+\param{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
chiamare \func{tcsetattr}.
-Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
+Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
validi; questi possono essere specificati direttamente (le \acr{glibc}
prevedono che i valori siano indicati in bit per secondo), ma in generale
altre versioni di librerie possono utilizzare dei valori diversi; per questo
-POSIX.1 prevede una serie di costanti che però servono solo per specificare le
-velocità tipiche delle linee seriali:
+POSIX.1 prevede una serie di costanti che però servono solo per specificare le
+velocità tipiche delle linee seriali:
\begin{verbatim}
B0 B50 B75 B110 B134 B150 B200
B300 B600 B1200 B1800 B2400 B4800 B9600
B19200 B38400 B57600 B115200 B230400 B460800
\end{verbatim}
-Un terminale può utilizzare solo alcune delle velocità possibili, le funzioni
-però non controllano se il valore specificato è valido, dato che non possono
-sapere a quale terminale le velocità saranno applicate; sarà l'esecuzione di
-\func{tcsetattr} a fallire quando si cercherà di eseguire l'impostazione.
+Un terminale può utilizzare solo alcune delle velocità possibili, le funzioni
+però non controllano se il valore specificato è valido, dato che non possono
+sapere a quale terminale le velocità saranno applicate; sarà l'esecuzione di
+\func{tcsetattr} a fallire quando si cercherà di eseguire l'impostazione.
Di norma il valore ha senso solo per i terminali seriali dove indica appunto
-la velocità della linea di trasmissione; se questa non corrisponde a quella
-del terminale quest'ultimo non potrà funzionare: quando il terminale non è
-seriale il valore non influisce sulla velocità di trasmissione dei dati.
+la velocità della linea di trasmissione; se questa non corrisponde a quella
+del terminale quest'ultimo non potrà funzionare: quando il terminale non è
+seriale il valore non influisce sulla velocità di trasmissione dei dati.
In generale impostare un valore nullo (\val{B0}) sulla linea di output fa si
-che il modem non asserisca più le linee di controllo, interrompendo di fatto
+che il modem non asserisca più le linee di controllo, interrompendo di fatto
la connessione, qualora invece si utilizzi questo valore per la linea di input
-l'effetto sarà quello di rendere la sua velocità identica a quella della linea
+l'effetto sarà quello di rendere la sua velocità identica a quella della linea
di output.
-Analogamente a quanto avviene per l'impostazione, le velocità possono essere
+Analogamente a quanto avviene per l'impostazione, le velocità possono essere
lette da una struttura \struct{termios} utilizzando altre due funzioni,
\funcd{cfgetispeed} e \funcd{cfgetospeed}, i cui prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
\funcdecl{speed\_t cfgetispeed(struct termios *termios\_p)}
- Legge la velocità delle linee seriali in ingresso.
+ Legge la velocità delle linee seriali in ingresso.
\funcdecl{speed\_t cfgetospeed(struct termios *termios\_p)}
- Legge la velocità delle linee seriali in uscita.
+ Legge la velocità delle linee seriali in uscita.
- \bodydesc{Entrambe le funzioni restituiscono la velocità della linea, non
+ \bodydesc{Entrambe le funzioni restituiscono la velocità della linea, non
sono previste condizioni di errore.}
\end{functions}
-Anche in questo caso le due funzioni estraggono i valori della velocità della
-linea da una struttura, il cui indirizzo è specificato dall'argomento
+Anche in questo caso le due funzioni estraggono i valori della velocità della
+linea da una struttura, il cui indirizzo è specificato dall'argomento
\param{termios\_p} che deve essere stata letta in precedenza con
\func{tcgetattr}.
\label{sec:term_line_discipline}
Come illustrato dalla struttura riportata in fig.~\ref{fig:term_struct} tutti
-i terminali hanno un insieme di funzionalità comuni, che prevedono la presenza
+i terminali hanno un insieme di funzionalità comuni, che prevedono la presenza
di code di ingresso ed uscita; in generale si fa riferimento ad esse con il
nome di \textsl{discipline di linea}.
funzioni di scrittura, pertanto se usate da processi in background sul loro
terminale di controllo provocano l'emissione di \const{SIGTTOU} come
illustrato in sez.~\ref{sec:sess_ctrl_term}.\footnote{con la stessa eccezione,
- già vista per \func{tcsetattr}, che quest'ultimo sia bloccato o ignorato dal
+ già vista per \func{tcsetattr}, che quest'ultimo sia bloccato o ignorato dal
processo chiamante.}
-Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
-(non fa niente per tutti gli altri terminali), è \funcd{tcsendbreak}; il suo
-prototipo è:
+Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
+(non fa niente per tutti gli altri terminali), è \funcd{tcsendbreak}; il suo
+prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
break inviando un flusso di bit nulli.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+ errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
\errval{ENOTTY}.}
\end{functions}
La funzione invia un flusso di bit nulli (che genera una condizione di break)
sul terminale associato a \param{fd}; un valore nullo di \param{duration}
implica una durata del flusso fra 0.25 e 0.5 secondi, un valore diverso da
-zero implica una durata pari a \code{duration*T} dove \code{T} è un valore
+zero implica una durata pari a \code{duration*T} dove \code{T} è un valore
compreso fra 0.25 e 0.5.\footnote{lo standard POSIX specifica il comportamento
solo nel caso si sia impostato un valore nullo per \param{duration}; il
- comportamento negli altri casi può dipendere dalla implementazione.}
+ comportamento negli altri casi può dipendere dalla implementazione.}
Le altre funzioni previste da POSIX servono a controllare il comportamento
-dell'interazione fra le code associate al terminale e l'utente; la prima è
-\funcd{tcdrain}, il cui prototipo è:
+dell'interazione fra le code associate al terminale e l'utente; la prima è
+\funcd{tcdrain}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
\funcdecl{int tcdrain(int fd)} Attende lo svuotamento della coda di output.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+ errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
\errval{ENOTTY}.}
\end{functions}
La funzione blocca il processo fino a che tutto l'output presente sulla coda
-di uscita non è stato trasmesso al terminale associato ad \param{fd}. % La
- % funzione è un punto di cancellazione per i
+di uscita non è stato trasmesso al terminale associato ad \param{fd}. % La
+ % funzione è un punto di cancellazione per i
% programmi multi-thread, in tal caso le
% chiamate devono essere protette con dei
% gestori di cancellazione.
Una seconda funzione, \funcd{tcflush}, permette svuotare immediatamente le code
-di cancellando tutti i dati presenti al loro interno; il suo prototipo è:
+di cancellando tutti i dati presenti al loro interno; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
nelle code di ingresso o di uscita.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+ errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
\errval{ENOTTY}.}
\end{functions}
La funzione agisce sul terminale associato a \param{fd}, l'argomento
\param{queue} permette di specificare su quale coda (ingresso, uscita o
-entrambe), operare. Esso può prendere i valori riportati in
+entrambe), operare. Esso può prendere i valori riportati in
tab.~\ref{tab:sess_tcflush_queue}, nel caso si specifichi la coda di ingresso
-cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda
-di uscita cancellerà i dati scritti ma non ancora trasmessi.
+cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda
+di uscita cancellerà i dati scritti ma non ancora trasmessi.
\begin{table}[htb]
\footnotesize
\end{table}
-L'ultima funzione dell'interfaccia che interviene sulla disciplina di linea è
+L'ultima funzione dell'interfaccia che interviene sulla disciplina di linea è
\funcd{tcflow}, che viene usata per sospendere la trasmissione e la ricezione
-dei dati sul terminale; il suo prototipo è:
+dei dati sul terminale; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
Sospende e riavvia il flusso dei dati sul terminale.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
+ errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
\errval{ENOTTY}.}
\end{functions}
La funzione permette di controllare (interrompendo e facendo riprendere) il
flusso dei dati fra il terminale ed il sistema sia in ingresso che in uscita.
-Il comportamento della funzione è regolato dall'argomento \param{action}, i
+Il comportamento della funzione è regolato dall'argomento \param{action}, i
cui possibili valori, e relativa azione eseguita dalla funzione, sono
riportati in tab.~\ref{tab:sess_tcflow_action}.
\subsection{Operare in \textsl{modo non canonico}}
\label{sec:term_non_canonical}
-Operare con un terminale in modo canonico è relativamente semplice; basta
-eseguire una lettura e la funzione ritornerà quando una il driver del
-terminale avrà completato una linea di input. Non è detto che la linea sia
-letta interamente (si può aver richiesto un numero inferiore di byte) ma in
-ogni caso nessun dato verrà perso, e il resto della linea sarà letto alla
+Operare con un terminale in modo canonico è relativamente semplice; basta
+eseguire una lettura e la funzione ritornerà quando una il driver del
+terminale avrà completato una linea di input. Non è detto che la linea sia
+letta interamente (si può aver richiesto un numero inferiore di byte) ma in
+ogni caso nessun dato verrà perso, e il resto della linea sarà letto alla
chiamata successiva.
-Inoltre in modo canonico la gestione dell'input è di norma eseguita
+Inoltre in modo canonico la gestione dell'input è di norma eseguita
direttamente dal driver del terminale, che si incarica (a seconda di quanto
impostato con le funzioni viste nei paragrafi precedenti) di cancellare i
caratteri, bloccare e riavviare il flusso dei dati, terminare la linea quando
In modo non canonico tocca invece al programma gestire tutto quanto, i
caratteri NL, EOL, EOL2, EOF, ERASE, KILL, CR, REPRINT non vengono
-interpretati automaticamente ed inoltre, non dividendo più l'input in linee,
-il sistema non ha più un limite definito per quando ritornare i dati ad un
+interpretati automaticamente ed inoltre, non dividendo più l'input in linee,
+il sistema non ha più un limite definito per quando ritornare i dati ad un
processo. Per questo motivo abbiamo visto che in \var{c\_cc} sono previsti due
caratteri speciali, MIN e TIME (specificati dagli indici \const{VMIN} e
\const{VTIME} in \var{c\_cc}) che dicono al sistema di ritornare da una
-\func{read} quando è stata letta una determinata quantità di dati o è passato
+\func{read} quando è stata letta una determinata quantità di dati o è passato
un certo tempo.
Come accennato nella relativa spiegazione in tab.~\ref{tab:sess_termios_cc},
-TIME e MIN non sono in realtà caratteri ma valori numerici. Il comportamento
-del sistema per un terminale in modalità non canonica prevede quattro casi
+TIME e MIN non sono in realtà caratteri ma valori numerici. Il comportamento
+del sistema per un terminale in modalità non canonica prevede quattro casi
distinti:
\begin{description}
\item[MIN$>0$, TIME$>0$] In questo caso MIN stabilisce il numero minimo di
caratteri desiderati e TIME un tempo di attesa, in decimi di secondo, fra un
carattere e l'altro. Una \func{read} ritorna se vengono ricevuti almeno MIN
- caratteri prima della scadenza di TIME (MIN è solo un limite inferiore, se
+ caratteri prima della scadenza di TIME (MIN è solo un limite inferiore, se
la funzione ha richiesto un numero maggiore di caratteri ne possono essere
- restituiti di più); se invece TIME scade vengono restituiti i byte ricevuti
+ restituiti di più); se invece TIME scade vengono restituiti i byte ricevuti
fino ad allora (un carattere viene sempre letto, dato che il timer inizia a
scorrere solo dopo la ricezione del primo carattere).
\item[MIN$>0$, TIME$=0$] Una \func{read} ritorna solo dopo che sono stati
- ricevuti almeno MIN caratteri. Questo significa che una \func{read} può
+ ricevuti almeno MIN caratteri. Questo significa che una \func{read} può
bloccarsi indefinitamente.
\item[MIN$=0$, TIME$>0$] In questo caso TIME indica un tempo di attesa dalla
chiamata di \func{read}, la funzione ritorna non appena viene ricevuto un
- carattere o scade il tempo. Si noti che è possibile che \func{read} ritorni
+ carattere o scade il tempo. Si noti che è possibile che \func{read} ritorni
con un valore nullo.
\item[MIN$=0$, TIME$=0$] In questo caso una \func{read} ritorna immediatamente
- restituendo tutti i caratteri ricevuti. Anche in questo caso può ritornare
+ restituendo tutti i caratteri ricevuti. Anche in questo caso può ritornare
con un valore nullo.
\end{description}
%
% TODO terminali virtuali
-% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
+% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
% degli stessi
%
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
-%%% End:
\ No newline at end of file
+%%% End:
\chapter{I segnali}
\label{cha:signals}
-I segnali sono il primo e più semplice meccanismo di comunicazione nei
-confronti dei processi. Nella loro versione originale essi portano con sé
+I segnali sono il primo e più semplice meccanismo di comunicazione nei
+confronti dei processi. Nella loro versione originale essi portano con sé
nessuna informazione che non sia il loro tipo; si tratta in sostanza di
un'interruzione software portata ad un processo.
In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
partendo da una introduzione relativa ai concetti base con cui essi vengono
-realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
+realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
di generazione fino ad esaminare in dettaglio le funzioni e le metodologie di
gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
versioni dello standard POSIX.
In questa sezione esamineremo i concetti generali relativi ai segnali, vedremo
le loro caratteristiche di base, introdurremo le nozioni di fondo relative
-all'architettura del funzionamento dei segnali e alle modalità con cui il
+all'architettura del funzionamento dei segnali e alle modalità con cui il
sistema gestisce l'interazione fra di essi ed i processi.
Come il nome stesso indica i segnali sono usati per notificare ad un processo
l'occorrenza di un qualche evento. Gli eventi che possono generare un segnale
-sono vari; un breve elenco di possibili cause per l'emissione di un segnale è
+sono vari; un breve elenco di possibili cause per l'emissione di un segnale è
il seguente:
\begin{itemize*}
accesso alla memoria fuori dai limiti validi;
\item la terminazione di un processo figlio;
\item la scadenza di un timer o di un allarme;
-\item il tentativo di effettuare un'operazione di input/output che non può
+\item il tentativo di effettuare un'operazione di input/output che non può
essere eseguita;
\item una richiesta dell'utente di terminare o fermare il programma. In genere
si realizza attraverso un segnale mandato dalla shell in corrispondenza
Quando un processo riceve un segnale, invece del normale corso del programma,
viene eseguita una azione predefinita o una apposita funzione di gestione
(quello che da qui in avanti chiameremo il \textsl{gestore} del segnale,
-dall'inglese \textit{signal handler}) che può essere stata specificata
+dall'inglese \textit{signal handler}) che può essere stata specificata
dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
\subsection{Le \textsl{semantiche} del funzionamento dei segnali}
\label{sec:sig_semantics}
-Negli anni il comportamento del sistema in risposta ai segnali è stato
+Negli anni il comportamento del sistema in risposta ai segnali è stato
modificato in vari modi nelle differenti implementazioni di Unix. Si possono
individuare due tipologie fondamentali di comportamento dei segnali (dette
\textsl{semantiche}) che vengono chiamate rispettivamente \textsl{semantica
Nella \textsl{semantica inaffidabile} (quella implementata dalle prime
versioni di Unix) la funzione di gestione del segnale specificata dall'utente
-non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
+non resta attiva una volta che è stata eseguita; è perciò compito dell'utente
stesso ripetere l'installazione all'interno del \textsl{gestore} del segnale,
in tutti quei casi in cui si vuole che esso resti attivo.
-In questo caso è possibile una situazione in cui i segnali possono essere
+In questo caso è possibile una situazione in cui i segnali possono essere
perduti. Si consideri il segmento di codice riportato in
fig.~\ref{fig:sig_old_handler}, nel programma principale viene installato un
gestore (\texttt{\small 5}), ed in quest'ultimo la prima operazione
-(\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
+(\texttt{\small 11}) è quella di reinstallare se stesso. Se nell'esecuzione
del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la
-reinstallazione, verrà eseguito il comportamento predefinito assegnato al
-segnale stesso, il che può comportare, a seconda dei casi, che il segnale
+reinstallazione, verrà eseguito il comportamento predefinito assegnato al
+segnale stesso, il che può comportare, a seconda dei casi, che il segnale
viene perso (se l'impostazione predefinita era quello di ignorarlo) o la
terminazione immediata del processo; in entrambi i casi l'azione prevista non
-verrà eseguita.
+verrà eseguita.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sig_old_handler}
\end{figure}
-Questa è la ragione per cui l'implementazione dei segnali secondo questa
+Questa è la ragione per cui l'implementazione dei segnali secondo questa
semantica viene chiamata \textsl{inaffidabile}; infatti la ricezione del
segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
sono sempre possibili delle \itindex{race~condition} \textit{race condition}
(sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
-Un altro problema è che in questa semantica non esiste un modo per bloccare i
+Un altro problema è che in questa semantica non esiste un modo per bloccare i
segnali quando non si vuole che arrivino; i processi possono ignorare il
-segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
-di un segnale, pur mantenendo memoria del fatto che è avvenuto.
+segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
+di un segnale, pur mantenendo memoria del fatto che è avvenuto.
Nella semantica \textsl{affidabile} (quella utilizzata da Linux e da ogni Unix
moderno) il gestore una volta installato resta attivo e non si hanno tutti i
Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
\textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
per tutto il tempo che passa fra la generazione del segnale e la sua consegna
-esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
+esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
procedura viene effettuata dallo \itindex{scheduler} scheduler quando,
riprendendo l'esecuzione del processo in questione, verifica la presenza del
segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
-In questa semantica un processo ha la possibilità di bloccare la consegna dei
-segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
+In questa semantica un processo ha la possibilità di bloccare la consegna dei
+segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
ignorarlo, il segnale resta \textsl{pendente} fintanto che il processo non lo
sblocca (nel qual caso viene consegnato) o imposta l'azione corrispondente per
ignorarlo.
-Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
+Si tenga presente che il kernel stabilisce cosa fare con un segnale che è
stato bloccato al momento della consegna, non quando viene generato; questo
consente di cambiare l'azione per il segnale prima che esso venga consegnato,
-e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
+e si può usare la funzione \func{sigpending} (vedi sez.~\ref{sec:sig_sigmask})
per determinare quali segnali sono bloccati e quali sono pendenti.
In generale gli eventi che generano segnali si possono dividere in tre
categorie principali: errori, eventi esterni e richieste esplicite.
-Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
+Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
-genere le condizioni di errore più comuni comportano la restituzione di un
+genere le condizioni di errore più comuni comportano la restituzione di un
codice di errore da parte di una funzione di libreria; sono gli errori che
possono avvenire nella esecuzione delle istruzioni di un programma che causano
l'emissione di un segnale, come le divisioni per zero o l'uso di indirizzi di
Una richiesta esplicita significa l'uso di una chiamata di sistema (come
\func{kill} o \func{raise}) per la generazione di un segnale, cosa che
viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
-di stop o di suspend, ma può essere pure inserita all'interno di un programma.
+di stop o di suspend, ma può essere pure inserita all'interno di un programma.
Si dice poi che i segnali possono essere \textsl{asincroni} o
-\textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
-specifica di un programma ed è inviato (a meno che non sia bloccato) durante
-tale azione; molti errori generano segnali \textsl{sincroni}, così come la
+\textsl{sincroni}. Un segnale \textsl{sincrono} è legato ad una azione
+specifica di un programma ed è inviato (a meno che non sia bloccato) durante
+tale azione; molti errori generano segnali \textsl{sincroni}, così come la
richiesta esplicita da parte del processo tramite le chiamate al sistema.
Alcuni errori come la divisione per zero non sono completamente sincroni e
possono arrivare dopo qualche istruzione.
I segnali \textsl{asincroni} sono generati da eventi fuori dal controllo del
processo che li riceve, e arrivano in tempi impredicibili nel corso
dell'esecuzione del programma. Eventi esterni come la terminazione di un
-processo figlio generano segnali \textsl{asincroni}, così come le richieste di
+processo figlio generano segnali \textsl{asincroni}, così come le richieste di
generazione di un segnale effettuate da altri processi.
-In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
+In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in
cui esso sia generato attraverso una richiesta esplicita tramite chiamata al
sistema, nel qual caso qualunque tipo di segnale (quello scelto nella
-chiamata) può diventare sincrono o asincrono a seconda che sia generato
+chiamata) può diventare sincrono o asincrono a seconda che sia generato
internamente o esternamente al processo.
\label{sec:sig_notification}
Come accennato quando un segnale viene generato, se la sua azione predefinita
-non è quella di essere ignorato, il kernel prende nota del fatto nella
-\struct{task\_struct} del processo; si dice così che il segnale diventa
+non è quella di essere ignorato, il kernel prende nota del fatto nella
+\struct{task\_struct} del processo; si dice così che il segnale diventa
\textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
-verrà notificato al processo (o verrà specificata come azione quella di
+verrà notificato al processo (o verrà specificata come azione quella di
ignorarlo).
-Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
+Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
avviene non appena questo viene rimesso in esecuzione dallo
\itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
che il segnale in questione non sia stato bloccato prima della notifica, nel
qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
-indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
-notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
+indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
+notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
accodano, alla generazione infatti il kernel marca un flag nella
\struct{task\_struct} del processo, per cui se prima della notifica ne vengono
-generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
+generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
una sola volta.
-Si ricordi però che se l'azione specificata per un segnale è quella di essere
-ignorato questo sarà scartato immediatamente al momento della sua generazione,
-e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
+Si ricordi però che se l'azione specificata per un segnale è quella di essere
+ignorato questo sarà scartato immediatamente al momento della sua generazione,
+e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
segnale significa bloccarne la notifica). Per questo motivo un segnale,
-fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
-bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
+fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
+bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
i segnali successivi alla nuova specificazione saranno notificati).
Una volta che un segnale viene notificato (che questo avvenga subito o dopo
-una attesa più o meno lunga) viene eseguita l'azione specificata per il
+una attesa più o meno lunga) viene eseguita l'azione specificata per il
segnale. Per alcuni segnali (\const{SIGKILL} e \const{SIGSTOP}) questa azione
-è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
-una delle tre possibilità seguenti:
+è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
+una delle tre possibilità seguenti:
\begin{itemize*}
\item ignorare il segnale;
\item accettare l'azione predefinita per quel segnale.
\end{itemize*}
-Un programma può specificare queste scelte usando le due funzioni
+Un programma può specificare queste scelte usando le due funzioni
\func{signal} e \func{sigaction} (vedi sez.~\ref{sec:sig_signal} e
-sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
-ad essere eseguito alla notifica del segnale. Inoltre il sistema farà si che
+sez.~\ref{sec:sig_sigaction}). Se si è installato un gestore sarà quest'ultimo
+ad essere eseguito alla notifica del segnale. Inoltre il sistema farà si che
mentre viene eseguito il gestore di un segnale, quest'ultimo venga
-automaticamente bloccato (così si possono evitare \itindex{race~condition}
+automaticamente bloccato (così si possono evitare \itindex{race~condition}
\textit{race condition}).
Nel caso non sia stata specificata un'azione, viene utilizzata l'azione
-standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
+standard che (come vedremo in sez.~\ref{sec:sig_standard}) è propria di ciascun
segnale; nella maggior parte dei casi essa porta alla terminazione del
processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
-Quando un segnale termina un processo, il padre può determinare la causa della
+Quando un segnale termina un processo, il padre può determinare la causa della
terminazione esaminando il codice di stato riportato dalle funzioni
-\func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
+\func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
in cui la shell determina i motivi della terminazione di un programma e scrive
un eventuale messaggio di errore.
violazioni di accesso) hanno anche la caratteristica di scrivere un file di
\itindex{core~dump} \textit{core dump} che registra lo stato del processo (ed
in particolare della memoria e dello \itindex{stack} \textit{stack}) prima
-della terminazione. Questo può essere esaminato in seguito con un debugger
+della terminazione. Questo può essere esaminato in seguito con un debugger
per investigare sulla causa dell'errore. Lo stesso avviene se i suddetti
segnali vengono generati con una \func{kill}.
\subsection{I segnali standard}
\label{sec:sig_standard}
-Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
-diretto di questo numero da parte dei programmi è da evitare, in quanto esso
-può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
+Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
+diretto di questo numero da parte dei programmi è da evitare, in quanto esso
+può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
anche a seconda dell'architettura hardware.
Per questo motivo ad ogni segnale viene associato un nome, definendo con una
macro di preprocessore una costante uguale al suddetto numero. Sono questi
implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
-Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
+Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
anche al successivo del valore numerico assegnato all'ultimo segnale definito.
-In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
+In tab.~\ref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
definiti in vari standard.
\textbf{Sigla} & \textbf{Significato} \\
\hline
\hline
- A & L'azione predefinita è terminare il processo.\\
- B & L'azione predefinita è ignorare il segnale.\\
- C & L'azione predefinita è terminare il processo e scrivere un
+ A & L'azione predefinita è terminare il processo.\\
+ B & L'azione predefinita è ignorare il segnale.\\
+ C & L'azione predefinita è terminare il processo e scrivere un
\itindex{core~dump} \textit{core dump}.\\
- D & L'azione predefinita è fermare il processo.\\
- E & Il segnale non può essere intercettato.\\
- F & Il segnale non può essere ignorato.\\
+ D & L'azione predefinita è fermare il processo.\\
+ E & Il segnale non può essere intercettato.\\
+ F & Il segnale non può essere ignorato.\\
\hline
\end{tabular}
\caption{Legenda delle azioni predefinite dei segnali riportate in
\end{table}
In tab.~\ref{tab:sig_signal_list} si sono anche riportate le azioni predefinite
-di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
-tab.~\ref{tab:sig_action_leg}), quando nessun gestore è installato un
-segnale può essere ignorato o causare la terminazione del processo. Nella
+di ciascun segnale (riassunte con delle lettere, la cui legenda completa è in
+tab.~\ref{tab:sig_action_leg}), quando nessun gestore è installato un
+segnale può essere ignorato o causare la terminazione del processo. Nella
colonna standard sono stati indicati anche gli standard in cui ciascun segnale
-è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}.
+è definito, secondo lo schema di tab.~\ref{tab:sig_standard_leg}.
\begin{table}[htb]
\label{tab:sig_standard_leg}
\end{table}
-In alcuni casi alla terminazione del processo è associata la creazione di un
+In alcuni casi alla terminazione del processo è associata la creazione di un
file (posto nella directory corrente del processo e chiamato \file{core}) su
cui viene salvata un'immagine della memoria del processo (il cosiddetto
-\itindex{core~dump} \textit{core dump}), che può essere usata da un debugger
+\itindex{core~dump} \textit{core dump}), che può essere usata da un debugger
per esaminare lo stato dello \itindex{stack} \textit{stack} e delle variabili
al momento della ricezione del segnale.
\const{SIGEMT} &L & & \\
% TODO che roba e` SIGEMT
\const{SIGSTKFLT}&L & A & Errore sullo stack del coprocessore. \\
- \const{SIGIO} &LB & A & L'I/O è possibile (4.2 BSD). \\
+ \const{SIGIO} &LB & A & L'I/O è possibile (4.2 BSD). \\
\const{SIGCLD} &L & & Sinonimo di \const{SIGCHLD}. \\
\const{SIGPWR} &L & A & Fallimento dell'alimentazione. \\
\const{SIGINFO} &L & & Sinonimo di \const{SIGPWR}. \\
\const{SIGLOST} &L & A & Perso un lock sul file (per NFS). \\
\const{SIGWINCH} &LB & B & Finestra ridimensionata (4.3 BSD, Sun). \\
- \const{SIGUNUSED}&L & A & Segnale inutilizzato (diventerà
+ \const{SIGUNUSED}&L & A & Segnale inutilizzato (diventerà
\const{SIGSYS}). \\
\hline
\end{tabular}
\end{table}
La descrizione dettagliata del significato dei vari segnali, raggruppati per
-tipologia, verrà affrontata nei paragrafi successivi.
+tipologia, verrà affrontata nei paragrafi successivi.
\subsection{Segnali di errore di programma}
rileva un qualche errore insanabile nel programma in esecuzione. In generale
la generazione di questi segnali significa che il programma ha dei gravi
problemi (ad esempio ha dereferenziato un puntatore non valido o ha eseguito
-una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.
+una operazione aritmetica proibita) e l'esecuzione non può essere proseguita.
In genere si intercettano questi segnali per permettere al programma di
terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
console o eliminare i \index{file!di lock} file di lock prima dell'uscita. In
questo caso il gestore deve concludersi ripristinando l'azione predefinita e
-rialzando il segnale, in questo modo il programma si concluderà senza effetti
+rialzando il segnale, in questo modo il programma si concluderà senza effetti
spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
gestore non ci fosse stato.
-L'azione predefinita per tutti questi segnali è causare la terminazione del
+L'azione predefinita per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
la registrazione su disco di un file di \itindex{core~dump} \textit{core dump}
che viene scritto in un file \file{core} nella directory corrente del processo
-al momento dell'errore, che il debugger può usare per ricostruire lo stato del
+al momento dell'errore, che il debugger può usare per ricostruire lo stato del
programma al momento della terminazione. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
+\item[\const{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
aritmetici compresa la divisione per zero e l'overflow. Se il gestore
- ritorna il comportamento del processo è indefinito, ed ignorare questo
- segnale può condurre ad un ciclo infinito.
+ ritorna il comportamento del processo è indefinito, ed ignorare questo
+ segnale può condurre ad un ciclo infinito.
% Per questo segnale le cose sono complicate dal fatto che possono esserci
% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
\item[\const{SIGILL}] Il nome deriva da \textit{illegal instruction},
significa che il programma sta cercando di eseguire una istruzione
- privilegiata o inesistente, in generale del codice illecito. Poiché il
+ privilegiata o inesistente, in generale del codice illecito. Poiché il
compilatore del C genera del codice valido si ottiene questo segnale se il
- file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
- Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
+ file eseguibile è corrotto o si stanno cercando di eseguire dei dati.
+ Quest'ultimo caso può accadere quando si passa un puntatore sbagliato al
posto di un puntatore a funzione, o si eccede la scrittura di un vettore di
una variabile locale, andando a corrompere lo \itindex{stack}
\textit{stack}. Lo stesso segnale viene generato in caso di overflow dello
\itindex{stack} \textit{stack} o di problemi nell'esecuzione di un gestore.
- Se il gestore ritorna il comportamento del processo è indefinito.
+ Se il gestore ritorna il comportamento del processo è indefinito.
\item[\const{SIGSEGV}] Il nome deriva da \itindex{segment~violation}
\textit{segment violation}, e significa che il programma sta cercando di
leggere o scrivere in una zona di memoria protetta al di fuori di quella che
- gli è stata riservata dal sistema. In genere è il meccanismo della
+ gli è stata riservata dal sistema. In genere è il meccanismo della
protezione della memoria che si accorge dell'errore ed il kernel genera il
- segnale. Se il gestore ritorna il comportamento del processo è indefinito.
+ segnale. Se il gestore ritorna il comportamento del processo è indefinito.
- È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
- inizializzato leggendo al di là della fine di un vettore.
+ È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
+ inizializzato leggendo al di là della fine di un vettore.
\item[\const{SIGBUS}] Il nome deriva da \textit{bus error}. Come
- \const{SIGSEGV} questo è un segnale che viene generato di solito quando si
- dereferenzia un puntatore non inizializzato, la differenza è che
+ \const{SIGSEGV} questo è un segnale che viene generato di solito quando si
+ dereferenzia un puntatore non inizializzato, la differenza è che
\const{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
(tipo fuori dallo heap o dallo \itindex{stack} \textit{stack}), mentre
\const{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso di
\item[\const{SIGABRT}] Il nome deriva da \textit{abort}. Il segnale indica che
il programma stesso ha rilevato un errore che viene riportato chiamando la
funzione \func{abort} che genera questo segnale.
-\item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
- dall'attivazione del tracciamento per il processo. È usato dai programmi per
+\item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
+ dall'attivazione del tracciamento per il processo. È usato dai programmi per
il debugging e un programma normale non dovrebbe ricevere questo segnale.
-\item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
- richiede l'esecuzione di una system call, ma si è fornito un codice
+\item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
+ richiede l'esecuzione di una system call, ma si è fornito un codice
sbagliato per quest'ultima.
\end{basedescript}
\label{sec:sig_termination}
Questo tipo di segnali sono usati per terminare un processo; hanno vari nomi a
-causa del differente uso che se ne può fare, ed i programmi possono
+causa del differente uso che se ne può fare, ed i programmi possono
trattarli in maniera differente.
-La ragione per cui può essere necessario trattare questi segnali è che il
-programma può dover eseguire una serie di azioni di pulizia prima di
+La ragione per cui può essere necessario trattare questi segnali è che il
+programma può dover eseguire una serie di azioni di pulizia prima di
terminare, come salvare informazioni sullo stato in cui si trova, cancellare
file temporanei, o ripristinare delle condizioni alterate durante il
funzionamento (come il modo del terminale o le impostazioni di una qualche
periferica).
-L'azione predefinita di questi segnali è di terminare il processo, questi
+L'azione predefinita di questi segnali è di terminare il processo, questi
segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
+\item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
generico usato per causare la conclusione di un programma. Al contrario di
- \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
+ \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
concludersi.
-\item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
- interruzione per il programma. È quello che viene generato di default dal
+\item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
+ interruzione per il programma. È quello che viene generato di default dal
comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
INTR (interrupt, generato dalla sequenza \cmd{C-c}).
-\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
+\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è
controllato da un altro carattere di controllo, QUIT, corrispondente alla
sequenza \texttt{C-\bslash}. A differenza del precedente l'azione
predefinita, oltre alla terminazione del processo, comporta anche la
creazione di un \itindex{core~dump} \textit{core dump}.
- In genere lo si può pensare come corrispondente ad una condizione di errore
- del programma rilevata dall'utente. Per questo motivo non è opportuno fare
+ In genere lo si può pensare come corrispondente ad una condizione di errore
+ del programma rilevata dall'utente. Per questo motivo non è opportuno fare
eseguire al gestore di questo segnale le operazioni di pulizia normalmente
previste (tipo la cancellazione di file temporanei), dato che in certi casi
esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
\textit{core dump}.
-\item[\const{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
- qualunque programma. Questo segnale non può essere né intercettato, né
- ignorato, né bloccato, per cui causa comunque la terminazione del processo.
+\item[\const{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
+ qualunque programma. Questo segnale non può essere né intercettato, né
+ ignorato, né bloccato, per cui causa comunque la terminazione del processo.
In genere esso viene generato solo per richiesta esplicita dell'utente dal
- comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
- intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
+ comando (o tramite la funzione) \cmd{kill}. Dato che non lo si può
+ intercettare è sempre meglio usarlo come ultima risorsa quando metodi meno
brutali, come \const{SIGTERM} o \cmd{C-c} non funzionano.
Se un processo non risponde a nessun altro segnale \const{SIGKILL} ne causa
sempre la terminazione (in effetti il fallimento della terminazione di un
processo da parte di \const{SIGKILL} costituirebbe un malfunzionamento del
- kernel). Talvolta è il sistema stesso che può generare questo segnale quando
- per condizioni particolari il processo non può più essere eseguito neanche
+ kernel). Talvolta è il sistema stesso che può generare questo segnale quando
+ per condizioni particolari il processo non può più essere eseguito neanche
per eseguire un gestore.
\item[\const{SIGHUP}] Il nome sta per \textit{hang-up}. Segnala che il
- terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
+ terminale dell'utente si è disconnesso (ad esempio perché si è interrotta la
rete). Viene usato anche per riportare la terminazione del processo di
controllo di un terminale a tutti i processi della sessione, in modo che
essi possano disconnettersi dal relativo terminale.
Viene inoltre usato in genere per segnalare ai demoni (che non hanno un
- terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
+ terminale di controllo) la necessità di reinizializzarsi e rileggere il/i
file di configurazione.
\end{basedescript}
\label{sec:sig_alarm}
Questi segnali sono generati dalla scadenza di un timer (vedi
-sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
+sez.~\ref{sec:sig_alarm_abort}). Il loro comportamento predefinito è quello di
causare la terminazione del programma, ma con questi segnali la scelta
-predefinita è irrilevante, in quanto il loro uso presuppone sempre la
-necessità di un gestore. Questi segnali sono:
+predefinita è irrilevante, in quanto il loro uso presuppone sempre la
+necessità di un gestore. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGALRM}] Il nome sta per \textit{alarm}. Segnale la scadenza di
- un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
+ un timer misurato sul tempo reale o sull'orologio di sistema. È normalmente
usato dalla funzione \func{alarm}.
-\item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
+\item[\const{SIVGTALRM}] Il nome sta per \textit{virtual alarm}. È analogo al
precedente ma segnala la scadenza di un timer sul tempo di CPU usato dal
processo.
Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per
questo occorre comunque usare \func{fcntl} per abilitare un file descriptor a
-generare questi segnali. L'azione predefinita è di essere ignorati. Questi
+generare questi segnali. L'azione predefinita è di essere ignorati. Questi
segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
+\item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
pronto per eseguire dell'input/output. In molti sistemi solo i
socket e i terminali possono generare questo segnale, in Linux
- questo può essere usato anche per i file, posto che la \func{fcntl} abbia
+ questo può essere usato anche per i file, posto che la \func{fcntl} abbia
avuto successo.
-\item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
+\item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
urgenti o \itindex{out-of-band} \textit{out-of-band} su di un
socket; per maggiori dettagli al proposito si veda
sez.~\ref{sec:TCP_urgent_data}.
-\item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
- definito solo per compatibilità con i sistemi System V.
+\item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
+ definito solo per compatibilità con i sistemi System V.
\end{basedescript}
\label{sec:sig_job_control}
Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
-loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
+loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
in cui si trattano gli argomenti relativi. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
- figlio termina o viene fermato. L'azione predefinita è di ignorare il
- segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
+\item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
+ figlio termina o viene fermato. L'azione predefinita è di ignorare il
+ segnale, la sua gestione è trattata in sez.~\ref{sec:proc_wait}.
-\item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
- precedente, il nome è obsoleto e andrebbe evitato.
+\item[\const{SIGCLD}] Per Linux questo è solo un segnale identico al
+ precedente, il nome è obsoleto e andrebbe evitato.
\item[\const{SIGCONT}] Il nome sta per \textit{continue}. Il segnale viene
usato per fare ripartire un programma precedentemente fermato da
\const{SIGSTOP}. Questo segnale ha un comportamento speciale, e fa sempre
ripartire il processo prima della sua consegna. Il comportamento predefinito
- è di fare solo questo; il segnale non può essere bloccato. Si può anche
+ è di fare solo questo; il segnale non può essere bloccato. Si può anche
installare un gestore, ma il segnale provoca comunque il riavvio del
processo.
- La maggior pare dei programmi non hanno necessità di intercettare il
- segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
+ La maggior pare dei programmi non hanno necessità di intercettare il
+ segnale, in quanto esso è completamente trasparente rispetto all'esecuzione
che riparte senza che il programma noti niente. Si possono installare dei
gestori per far si che un programma produca una qualche azione speciale
se viene fermato e riavviato, come per esempio riscrivere un prompt, o
inviare un avviso.
-\item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
- stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
- intercettato, né ignorato, né bloccato.
+\item[\const{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno
+ stato di sleep, vedi sez.~\ref{sec:proc_sched}); il segnale non può essere né
+ intercettato, né ignorato, né bloccato.
\item[\const{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
- ferma il processo interattivamente, ed è generato dal carattere SUSP
+ ferma il processo interattivamente, ed è generato dal carattere SUSP
(prodotto dalla combinazione \cmd{C-z}), ed al contrario di
- \const{SIGSTOP} può essere intercettato e ignorato. In genere un programma
+ \const{SIGSTOP} può essere intercettato e ignorato. In genere un programma
installa un gestore per questo segnale quando vuole lasciare il sistema
o il terminale in uno stato definito prima di fermarsi; se per esempio un
- programma ha disabilitato l'eco sul terminale può installare un gestore
+ programma ha disabilitato l'eco sul terminale può installare un gestore
per riabilitarlo prima di fermarsi.
-\item[\const{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
+\item[\const{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
sessione di lavoro in \textit{background}. Quando un processo in background
tenta di leggere da un terminale viene inviato questo segnale a tutti i
- processi della sessione di lavoro. L'azione predefinita è di fermare il
- processo. L'argomento è trattato in
+ processi della sessione di lavoro. L'azione predefinita è di fermare il
+ processo. L'argomento è trattato in
sez.~\ref{sec:sess_job_control_overview}.
\item[\const{SIGTTOU}] Segnale analogo al precedente \const{SIGTTIN}, ma
generato quando si tenta di scrivere o modificare uno dei modi del
- terminale. L'azione predefinita è di fermare il processo, l'argomento è
+ terminale. L'azione predefinita è di fermare il processo, l'argomento è
trattato in sez.~\ref{sec:sess_job_control_overview}.
\end{basedescript}
Questi segnali sono usati per riportare al programma errori generati da
operazioni da lui eseguite; non indicano errori del programma quanto errori
che impediscono il completamento dell'esecuzione dovute all'interazione con il
-resto del sistema. L'azione predefinita di questi segnali è di terminare il
+resto del sistema. L'azione predefinita di questi segnali è di terminare il
processo, questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
- (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
+ (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
- sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
+ sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
- segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
+ segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
-\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
+\item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
segnale che viene generato quando si perde un advisory lock su un file su
- NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
- indicare ad un client il crollo inaspettato di un server. In Linux è
- definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
+ NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
+ indicare ad un client il crollo inaspettato di un server. In Linux è
+ definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
nella pagina di manuale.}
\item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
- segnale è generato quando un processo eccede il limite impostato per il
+ segnale è generato quando un processo eccede il limite impostato per il
tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}.
\item[\const{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
- segnale è generato quando un processo tenta di estendere un file oltre le
+ segnale è generato quando un processo tenta di estendere un file oltre le
dimensioni specificate dal limite impostato per le dimensioni massime di un
file, vedi sez.~\ref{sec:sys_resource_limit}.
\end{basedescript}
Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
classificabili in maniera omogenea. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
- dell'utente che lo può usare per quello che vuole. Viene generato solo
+\item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
+ dell'utente che lo può usare per quello che vuole. Viene generato solo
attraverso l'invocazione della funzione \func{kill}. Entrambi i segnali
possono essere utili per implementare una comunicazione elementare fra
processi diversi, o per eseguire a richiesta una operazione utilizzando un
- gestore. L'azione predefinita è di terminare il processo.
-\item[\const{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
+ gestore. L'azione predefinita è di terminare il processo.
+\item[\const{SIGUSR2}] È il secondo segnale a disposizione degli utenti. Vedi
quanto appena detto per \const{SIGUSR1}.
\item[\const{SIGWINCH}] Il nome sta per \textit{window (size) change} e viene
generato in molti sistemi (GNU/Linux compreso) quando le dimensioni (in
righe e colonne) di un terminale vengono cambiate. Viene usato da alcuni
programmi testuali per riformattare l'uscita su schermo quando si cambia
- dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
-\item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
+ dimensione a quest'ultimo. L'azione predefinita è di essere ignorato.
+\item[\const{SIGINFO}] Il segnale indica una richiesta di informazioni. È
usato con il controllo di sessione, causa la stampa di informazioni da parte
del processo leader del gruppo associato al terminale di controllo, gli
altri processi lo ignorano.
Per la descrizione dei segnali il sistema mette a disposizione due funzioni
che stampano un messaggio di descrizione dato il numero. In genere si usano
quando si vuole notificare all'utente il segnale ricevuto (nel caso di
-terminazione di un processo figlio o di un gestore che gestisce più segnali);
-la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
-definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
+terminazione di un processo figlio o di un gestore che gestisce più segnali);
+la prima funzione, \funcd{strsignal}, è una estensione GNU, accessibile avendo
+definito \macro{\_GNU\_SOURCE}, ed è analoga alla funzione \func{strerror} (si
veda sez.~\ref{sec:sys_strerror}) per gli errori:
\begin{prototype}{string.h}{char *strsignal(int signum)}
Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
\param{signum}.
\end{prototype}
-\noindent dato che la stringa è allocata staticamente non se ne deve
+\noindent dato che la stringa è allocata staticamente non se ne deve
modificare il contenuto, che resta valido solo fino alla successiva chiamata
-di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
+di \func{strsignal}. Nel caso si debba mantenere traccia del messaggio sarà
necessario copiarlo.
-La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
+La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione
\func{perror} descritta sempre in sez.~\ref{sec:sys_strerror}; il suo prototipo
-è:
+è:
\begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
\end{prototype}
-Una modalità alternativa per utilizzare le descrizioni restituite da
-\func{strsignal} e \func{psignal} è quello di usare la variabile
-\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
+Una modalità alternativa per utilizzare le descrizioni restituite da
+\func{strsignal} e \func{psignal} è quello di usare la variabile
+\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
con la dichiarazione:
\includecodesnip{listati/siglist.c}
L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
- *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
+ *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
*decr = sys\_siglist[SIGINT]}.
\section{La gestione di base dei segnali}
\label{sec:sig_management}
-I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
+I segnali sono il primo e più classico esempio di eventi asincroni, cioè di
eventi che possono accadere in un qualunque momento durante l'esecuzione di un
-programma. Per questa loro caratteristica la loro gestione non può essere
-effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
+programma. Per questa loro caratteristica la loro gestione non può essere
+effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
delegata appunto agli eventuali gestori che si sono installati.
In questa sezione vedremo come si effettua la gestione dei segnali, a partire
\subsection{Il comportamento generale del sistema}
\label{sec:sig_gen_beha}
-Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
-gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
+Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
+gestisce l'interazione fra segnali e processi, ci resta da esaminare però il
comportamento delle system call; in particolare due di esse, \func{fork} ed
\func{exec}, dovranno essere prese esplicitamente in considerazione, data la
loro stretta relazione con la creazione di nuovi processi.
figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
Quando si mette in esecuzione un nuovo programma con \func{exec} (si ricordi
-quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
-installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
+quanto detto in sez.~\ref{sec:proc_exec}) tutti i segnali per i quali è stato
+installato un gestore vengono reimpostati a \const{SIG\_DFL}. Non ha più
senso infatti fare riferimento a funzioni definite nel programma originario,
che non sono presenti nello spazio di indirizzi del nuovo programma.
-Si noti che questo vale solo per le azioni per le quali è stato installato un
+Si noti che questo vale solo per le azioni per le quali è stato installato un
gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
\const{SIG\_IGN}. Questo permette ad esempio alla shell di impostare ad
\const{SIG\_IGN} le risposte per \const{SIGINT} e \const{SIGQUIT} per i
Per quanto riguarda il comportamento di tutte le altre system call si danno
sostanzialmente due casi, a seconda che esse siano \index{system~call~lente}
\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
-parte di esse appartiene a quest'ultima categoria, che non è influenzata
+parte di esse appartiene a quest'ultima categoria, che non è influenzata
dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
-esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
-data dopo che la system call è stata completata, in quanto attendere per
+esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
+data dopo che la system call è stata completata, in quanto attendere per
eseguire un gestore non comporta nessun inconveniente.
-In alcuni casi però alcune system call (che per questo motivo vengono chiamate
-\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
-attendere la conclusione della system call, perché questo renderebbe
+In alcuni casi però alcune system call (che per questo motivo vengono chiamate
+\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
+attendere la conclusione della system call, perché questo renderebbe
impossibile una risposta pronta al segnale, per cui il gestore viene
eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si
-presenta questa situazione è il seguente:
+presenta questa situazione è il seguente:
\begin{itemize*}
\item la lettura da file che possono bloccarsi in attesa di dati non ancora
presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
\item l'apertura di un file di dispositivo che richiede operazioni non
immediate per una risposta (ad esempio l'apertura di un nastro che deve
essere riavvolto);
-\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
+\item le operazioni eseguite con \func{ioctl} che non è detto possano essere
eseguite immediatamente;
\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
da altri processi;
\item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
segnale);
-\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
+\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
\end{itemize*}
In questo caso si pone il problema di cosa fare una volta che il gestore sia
ritornato. La scelta originaria dei primi Unix era quella di far ritornare
-anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
+anche la system call restituendo l'errore di \errcode{EINTR}. Questa è a
tutt'oggi una scelta corrente, ma comporta che i programmi che usano dei
gestori controllino lo stato di uscita delle funzioni che eseguono una system
call lenta per ripeterne la chiamata qualora l'errore fosse questo.
-Dimenticarsi di richiamare una system call interrotta da un segnale è un
+Dimenticarsi di richiamare una system call interrotta da un segnale è un
errore comune, tanto che le \acr{glibc} provvedono una macro
\code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
-non è diverso dall'uscita con un errore \errcode{EINTR}.
+non è diverso dall'uscita con un errore \errcode{EINTR}.
-La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
-diverso, che è quello di fare ripartire automaticamente una system call
-interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
-di preoccuparsi di controllare il codice di errore; si perde però la
-possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
+La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
+diverso, che è quello di fare ripartire automaticamente una system call
+interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
+di preoccuparsi di controllare il codice di errore; si perde però la
+possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
condizione.
Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
attraverso una opportuna opzione di \func{sigaction} (vedi
-sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
+sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
interruzione nel mezzo di un trasferimento parziale di dati, le system call
ritornano sempre indicando i byte trasferiti.
-% TODO: alcune syscall danno EINTR anche se il segnale è installato con
+% TODO: alcune syscall danno EINTR anche se il segnale è installato con
% SA_RESTART, vedi signal(7)
\subsection{La funzione \func{signal}}
\label{sec:sig_signal}
-L'interfaccia più semplice per la gestione dei segnali è costituita dalla
-funzione \funcd{signal} che è definita fin dallo standard ANSI C.
-Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
-tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
+L'interfaccia più semplice per la gestione dei segnali è costituita dalla
+funzione \funcd{signal} che è definita fin dallo standard ANSI C.
+Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
+tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
per cui ogni implementazione successiva ne ha modificato e ridefinito il
-comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
+comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
alcuni argomenti aggiuntivi per definire il comportamento della funzione,
- vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
- funzione \func{sigaction}.} che è:
+ vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
+ funzione \func{sigaction}.} che è:
\begin{prototype}{signal.h}
{sighandler\_t signal(int signum, sighandler\_t handler)}
o \const{SIG\_ERR} in caso di errore.}
\end{prototype}
-In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
+In questa definizione si è usato un tipo di dato, \type{sighandler\_t}, che è
una estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
-prototipo di \func{signal} nella forma appena vista, molto più leggibile di
-quanto non sia la versione originaria, che di norma è definita come:
+prototipo di \func{signal} nella forma appena vista, molto più leggibile di
+quanto non sia la versione originaria, che di norma è definita come:
\includecodesnip{listati/signal.c}
questa infatti, per la poca chiarezza della sintassi del C quando si vanno a
-trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
-con il precedente prototipo si può dedurre la definizione di
-\type{sighandler\_t} che è:
+trattare puntatori a funzioni, è molto meno comprensibile. Da un confronto
+con il precedente prototipo si può dedurre la definizione di
+\type{sighandler\_t} che è:
\includecodesnip{listati/sighandler_t.c}
-e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
+e cioè un puntatore ad una funzione \ctyp{void} (cioè senza valore di ritorno)
e che prende un argomento di tipo \ctyp{int}.\footnote{si devono usare le
parentesi intorno al nome della funzione per via delle precedenze degli
operatori del C, senza di esse si sarebbe definita una funzione che ritorna
un puntatore a \ctyp{void} e non un puntatore ad una funzione \ctyp{void}.}
La funzione \func{signal} quindi restituisce e prende come secondo argomento
-un puntatore a una funzione di questo tipo, che è appunto la funzione che
-verrà usata come gestore del segnale.
+un puntatore a una funzione di questo tipo, che è appunto la funzione che
+verrà usata come gestore del segnale.
-Il numero di segnale passato nell'argomento \param{signum} può essere indicato
+Il numero di segnale passato nell'argomento \param{signum} può essere indicato
direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}.
L'argomento \param{handler} che indica il gestore invece, oltre all'indirizzo
-della funzione da chiamare all'occorrenza del segnale, può assumere anche i
+della funzione da chiamare all'occorrenza del segnale, può assumere anche i
due valori costanti \const{SIG\_IGN} e \const{SIG\_DFL}; il primo indica che
-il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
- \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
+il segnale deve essere ignorato,\footnote{si ricordi però che i due segnali
+ \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
effetto.} mentre il secondo ripristina l'azione predefinita.\footnote{e
- serve a tornare al comportamento di default quando non si intende più
+ serve a tornare al comportamento di default quando non si intende più
gestire direttamente un segnale.}
-La funzione restituisce l'indirizzo dell'azione precedente, che può essere
+La funzione restituisce l'indirizzo dell'azione precedente, che può essere
salvato per poterlo ripristinare (con un'altra chiamata a \func{signal}) in un
secondo tempo. Si ricordi che se si imposta come azione \const{SIG\_IGN} (o si
-imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
+imposta un \const{SIG\_DFL} per un segnale la cui azione predefinita è di
essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno
mai notificati.
-L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
+L'uso di \func{signal} è soggetto a problemi di compatibilità, dato che essa
si comporta in maniera diversa per sistemi derivati da BSD o da System V. In
-questi ultimi infatti la funzione è conforme al comportamento originale dei
+questi ultimi infatti la funzione è conforme al comportamento originale dei
primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la
semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
- \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
+ \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
ridefinita per seguire la semantica affidabile usata da BSD.}
Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
-\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
-comportamento della versione originale della funzione, il cui uso è deprecato
-per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
+\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
+comportamento della versione originale della funzione, il cui uso è deprecato
+per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
chiamando \func{sysv\_signal}, una volta che si sia definita la macro
\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
\func{signal}, che tra l'altro ha un comportamento indefinito in caso di
-processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
+processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
programmi dovrebbero usare \func{sigaction}.
-È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
+È da tenere presente che, seguendo lo standard POSIX, il comportamento di un
processo che ignora i segnali \const{SIGFPE}, \const{SIGILL}, o
\const{SIGSEGV} (qualora questi non originino da una chiamata ad una
-\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
-questi segnali può dare luogo ad un ciclo infinito.
+\func{kill} o ad una \func{raise}) è indefinito. Un gestore che ritorna da
+questi segnali può dare luogo ad un ciclo infinito.
\subsection{Le funzioni \func{kill} e \func{raise}}
\label{sec:sig_kill_raise}
-Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
+Come precedentemente accennato in sez.~\ref{sec:sig_types}, un segnale può
anche essere generato direttamente nell'esecuzione di un programma, attraverso
la chiamata ad una opportuna system call. Le funzioni che si utilizzano di
solito per inviare un segnale generico ad un processo sono due: \func{raise} e
\func{kill}.
-La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
+La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
serve per inviare un segnale al processo corrente,\footnote{non prevedendo la
presenza di un sistema multiutente lo standard ANSI C non poteva che
definire una funzione che invia il segnale al programma in esecuzione. Nel
- caso di Linux questa viene implementata come funzione di compatibilità.} il
-suo prototipo è:
+ caso di Linux questa viene implementata come funzione di compatibilità.} il
+suo prototipo è:
\begin{prototype}{signal.h}{int raise(int sig)}
Invia il segnale \param{sig} al processo corrente.
\bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, il solo errore restituito è \errval{EINVAL} qualora si sia
+ errore, il solo errore restituito è \errval{EINVAL} qualora si sia
specificato un numero di segnale invalido.}
\end{prototype}
-Il valore di \param{sig} specifica il segnale che si vuole inviare e può
+Il valore di \param{sig} specifica il segnale che si vuole inviare e può
essere specificato con una delle macro definite in
sez.~\ref{sec:sig_classification}. In genere questa funzione viene usata per
riprodurre il comportamento predefinito di un segnale che sia stato
intercettato. In questo caso, una volta eseguite le operazioni volute, il
-gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
+gestore dovrà prima reinstallare l'azione predefinita, per poi attivarla
chiamando \func{raise}.
-Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
+Mentre \func{raise} è una funzione di libreria, quando si vuole inviare un
segnale generico ad un processo occorre utilizzare la apposita system call,
-questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
-prototipo è:
+questa può essere chiamata attraverso la funzione \funcd{kill}, il cui
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{signal.h}
processo specificato con \param{pid}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore nel qual caso \var{errno} assumerà uno dei valori:
+ errore nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] il segnale specificato non esiste.
\item[\errcode{ESRCH}] il processo selezionato non esiste.
Lo standard POSIX prevede che il valore 0 per \param{sig} sia usato per
specificare il segnale nullo. Se la funzione viene chiamata con questo valore
non viene inviato nessun segnale, ma viene eseguito il controllo degli errori,
-in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
+in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi
necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste.
-Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
+Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in
sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che
esso sia realmente quello a cui si intendeva mandare il segnale.
Il valore dell'argomento \param{pid} specifica il processo (o i processi) di
-destinazione a cui il segnale deve essere inviato e può assumere i valori
+destinazione a cui il segnale deve essere inviato e può assumere i valori
riportati in tab.~\ref{tab:sig_kill_values}.
-Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
-termini di \func{kill}, ed è sostanzialmente equivalente ad una
-\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
+Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
+termini di \func{kill}, ed è sostanzialmente equivalente ad una
+\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
-l'uso di \func{kill} finisce per essere più portabile.
+l'uso di \func{kill} finisce per essere più portabile.
-Una seconda funzione che può essere definita in termini di \func{kill} è
-\funcd{killpg}, che è sostanzialmente equivalente a
-\code{kill(-pidgrp, signal)}; il suo prototipo è:
+Una seconda funzione che può essere definita in termini di \func{kill} è
+\funcd{killpg}, che è sostanzialmente equivalente a
+\code{kill(-pidgrp, signal)}; il suo prototipo è:
\begin{prototype}{signal.h}{int killpg(pid\_t pidgrp, int signal)}
Invia il segnale \param{signal} al \itindex{process~group} \textit{process
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
- 0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
+ $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\
+ 0 & Il segnale è mandato ad ogni processo del \itindex{process~group}
\textit{process group} del chiamante.\\
- $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
- $<-1$ & Il segnale è mandato ad ogni processo del \textit{process group}
+ $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\
+ $<-1$ & Il segnale è mandato ad ogni processo del \textit{process group}
\itindex{process~group} $|\code{pid}|$.\\
\hline
\end{tabular}
\label{tab:sig_kill_values}
\end{table}
-Solo l'amministratore può inviare un segnale ad un processo qualunque, in
+Solo l'amministratore può inviare un segnale ad un processo qualunque, in
tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
destinazione. Fa eccezione il caso in cui il segnale inviato sia
\const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
-(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
-inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
+(si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile
+inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso non abbia
un gestore installato.
Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
\subsection{Le funzioni \func{alarm}, \func{abort} ed i \textit{timer}}
\label{sec:sig_alarm_abort}
-Un caso particolare di segnali generati a richiesta è quello che riguarda i
+Un caso particolare di segnali generati a richiesta è quello che riguarda i
vari segnali di temporizzazione e \const{SIGABRT}, per ciascuno di questi
-segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
-comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
-prototipo è:
+segnali sono previste funzioni specifiche che ne effettuino l'invio. La più
+comune delle funzioni usate per la temporizzazione è \funcd{alarm} il cui
+prototipo è:
\begin{prototype}{unistd.h}{unsigned int alarm(unsigned int seconds)}
Predispone l'invio di \const{SIGALRM} dopo \param{seconds} secondi.
caso in questione \const{SIGALRM}) dopo il numero di secondi specificato da
\param{seconds}.
-Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
+Se si specifica per \param{seconds} un valore nullo non verrà inviato nessun
segnale; siccome alla chiamata viene cancellato ogni precedente allarme,
-questo può essere usato per cancellare una programmazione precedente.
+questo può essere usato per cancellare una programmazione precedente.
La funzione inoltre ritorna il numero di secondi rimanenti all'invio
-dell'allarme programmato in precedenza. In questo modo è possibile controllare
-se non si è cancellato un precedente allarme e predisporre eventuali misure
-che permettano di gestire il caso in cui servono più interruzioni.
+dell'allarme programmato in precedenza. In questo modo è possibile controllare
+se non si è cancellato un precedente allarme e predisporre eventuali misure
+che permettano di gestire il caso in cui servono più interruzioni.
In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
di questo timer provoca l'emissione di \const{SIGPROF}.
\end{itemize*}
-Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
-tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
+Il timer usato da \func{alarm} è il \textit{clock time}, e corrisponde cioè al
+tempo reale. La funzione come abbiamo visto è molto semplice, ma proprio per
questo presenta numerosi limiti: non consente di usare gli altri timer, non
-può specificare intervalli di tempo con precisione maggiore del secondo e
+può specificare intervalli di tempo con precisione maggiore del secondo e
genera il segnale una sola volta.
Per ovviare a questi limiti Linux deriva da BSD la funzione \funcd{setitimer}
che permette di usare un timer qualunque e l'invio di segnali periodici, al
-costo però di una maggiore complessità d'uso e di una minore portabilità. Il
-suo prototipo è:
+costo però di una maggiore complessità d'uso e di una minore portabilità. Il
+suo prototipo è:
\begin{prototype}{sys/time.h}{int setitimer(int which, const struct
itimerval *value, struct itimerval *ovalue)}
\param{value} sul timer specificato da \param{which}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
+ errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o
\errval{EFAULT}.}
\end{prototype}
\end{table}
Il valore della struttura specificata \param{value} viene usato per impostare
-il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
+il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
viene salvato qui. I valori dei timer devono essere indicati attraverso una
struttura \struct{itimerval}, definita in fig.~\ref{fig:file_stat_struct}.
-La struttura è composta da due membri, il primo, \var{it\_interval} definisce
+La struttura è composta da due membri, il primo, \var{it\_interval} definisce
il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
permette una precisione fino al microsecondo.
Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
il segnale e reimposta \var{it\_value} al valore di \var{it\_interval}, in
-questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
-è nullo il timer si ferma.
+questo modo il ciclo verrà ripetuto; se invece il valore di \var{it\_interval}
+è nullo il timer si ferma.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
-caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
-definita direttamente nello standard POSIX.1, può a sua volta essere espressa
+caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
+definita direttamente nello standard POSIX.1, può a sua volta essere espressa
in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
\cite{glibc} che ne riporta la definizione mostrata in
-fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
+fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
\begin{figure}[!htb]
Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di
queste funzioni era limitata dalla frequenza del timer di sistema,\footnote{il
- valore della costante \texttt{HZ}, di cui abbiamo già parlato in
+ valore della costante \texttt{HZ}, di cui abbiamo già parlato in
sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
in numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
''\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
-stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
-effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
+stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
+effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
causava l'emissione del segnale con un arrotondamento per difetto.} L'uso
del contatore dei \itindex{jiffies} \textit{jiffies}, un intero a 32 bit,
-comportava inoltre l'impossibilità di specificare tempi molto
+comportava inoltre l'impossibilità di specificare tempi molto
lunghi.\footnote{superiori al valore della costante
\const{MAX\_SEC\_IN\_JIFFIES}, pari, nel caso di default di un valore di
\const{HZ} di 250, a circa 99 giorni e mezzo.} Con il cambiamento della
-rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
+rappresentazione effettuato nel kernel 2.6.16 questo problema è scomparso e
con l'introduzione dei timer ad alta risoluzione (vedi
-sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
+sez.~\ref{sec:sig_timer_adv}) nel kernel 2.6.21 la precisione è diventata
quella fornita dall'hardware disponibile.
-Una seconda causa di potenziali ritardi è che il segnale viene generato alla
+Una seconda causa di potenziali ritardi è che il segnale viene generato alla
scadenza del timer, ma poi deve essere consegnato al processo; se quest'ultimo
-è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
-immediata, altrimenti può esserci un ulteriore ritardo che può variare a
+è attivo (questo è sempre vero per \const{ITIMER\_VIRT}) la consegna è
+immediata, altrimenti può esserci un ulteriore ritardo che può variare a
seconda del carico del sistema.
-Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
-conto poi che in caso di sistema molto carico, si può avere il caso patologico
+Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga
+conto poi che in caso di sistema molto carico, si può avere il caso patologico
in cui un timer scade prima che il segnale di una precedente scadenza sia
stato consegnato; in questo caso, per il comportamento dei segnali descritto
-in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
-oggi l'uso di questa funzione è deprecato a favore dei \textit{POSIX timer}
+in sez.~\ref{sec:sig_sigchld}, un solo segnale sarà consegnato. Per questo
+oggi l'uso di questa funzione è deprecato a favore dei \textit{POSIX timer}
che tratteremo in sez.~\ref{sec:sig_timer_adv}.
Dato che sia \func{alarm} che \func{setitimer} non consentono di leggere il
-valore corrente di un timer senza modificarlo, è possibile usare la funzione
-\funcd{getitimer}, il cui prototipo è:
+valore corrente di un timer senza modificarlo, è possibile usare la funzione
+\funcd{getitimer}, il cui prototipo è:
\begin{prototype}{sys/time.h}{int getitimer(int which, struct
itimerval *value)}
\func{setitimer}.
-L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
+L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo
-prototipo è:
+prototipo è:
\begin{prototype}{stdlib.h}{void abort(void)}
Abortisce il processo corrente.
- \bodydesc{La funzione non ritorna, il processo è terminato inviando il
+ \bodydesc{La funzione non ritorna, il processo è terminato inviando il
segnale di \const{SIGABRT}.}
\end{prototype}
-La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
-segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
-può però essere intercettato per effettuare eventuali operazioni di chiusura
+La differenza fra questa funzione e l'uso di \func{raise} è che anche se il
+segnale è bloccato o ignorato, la funzione ha effetto lo stesso. Il segnale
+può però essere intercettato per effettuare eventuali operazioni di chiusura
prima della terminazione del processo.
Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
\subsection{Le funzioni di pausa e attesa}
\label{sec:sig_pause_sleep}
-Sono parecchie le occasioni in cui si può avere necessità di sospendere
-temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
+Sono parecchie le occasioni in cui si può avere necessità di sospendere
+temporaneamente l'esecuzione di un processo. Nei sistemi più elementari in
genere questo veniva fatto con un opportuno loop di attesa, ma in un sistema
-multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
+multitasking un loop di attesa è solo un inutile spreco di CPU, per questo ci
sono apposite funzioni che permettono di mettere un processo in stato di
attesa.\footnote{si tratta in sostanza di funzioni che permettono di portare
esplicitamente il processo in stato di \textit{sleep}, vedi
sez.~\ref{sec:proc_sched}.}
Il metodo tradizionale per fare attendere ad un processo fino all'arrivo di un
-segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
+segnale è quello di usare la funzione \funcd{pause}, il cui prototipo è:
\begin{prototype}{unistd.h}{int pause(void)}
Pone il processo in stato di sleep fino al ritorno di un gestore.
- \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
- il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
- \var{errno} assumerà il valore \errval{EINTR}.}
+ \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
+ il relativo gestore è ritornato, nel qual caso restituisce $-1$ e
+ \var{errno} assumerà il valore \errval{EINTR}.}
\end{prototype}
La funzione segnala sempre una condizione di errore (il successo sarebbe
quello di aspettare indefinitamente). In genere si usa questa funzione quando
si vuole mettere un processo in attesa di un qualche evento specifico che non
-è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
+è sotto il suo diretto controllo (ad esempio la si può usare per interrompere
l'esecuzione del processo fino all'arrivo di un segnale inviato da un altro
processo).
Quando invece si vuole fare attendere un processo per un intervallo di tempo
-già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
-cui prototipo è:
+già noto nello standard POSIX.1 viene definita la funzione \funcd{sleep}, il
+cui prototipo è:
\begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
Pone il processo in stato di sleep per \param{seconds} secondi.
\end{prototype}
La funzione attende per il tempo specificato, a meno di non essere interrotta
-da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
-tempo rimanente, in quanto la riattivazione del processo può avvenire in un
-qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
-con la conseguenza che, se la successione dei segnali è particolarmente
+da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
+tempo rimanente, in quanto la riattivazione del processo può avvenire in un
+qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
+con la conseguenza che, se la successione dei segnali è particolarmente
sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
-parecchi secondi. In genere la scelta più sicura è quella di stabilire un
+parecchi secondi. In genere la scelta più sicura è quella di stabilire un
termine per l'attesa, e ricalcolare tutte le volte il numero di secondi da
aspettare.
-In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
-con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
+In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
+con quello di \const{SIGALRM}, dato che la funzione può essere realizzata con
l'uso di \func{pause} e \func{alarm} (in maniera analoga all'esempio che
vedremo in sez.~\ref{sec:sig_example}). In tal caso mescolare chiamata di
-\func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
-causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
+\func{alarm} e \func{sleep} o modificare l'azione di \const{SIGALRM}, può
+causare risultati indefiniti. Nel caso delle \acr{glibc} è stata usata una
implementazione completamente indipendente e questi problemi non ci sono.
-La granularità di \func{sleep} permette di specificare attese soltanto in
-secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
-\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
+La granularità di \func{sleep} permette di specificare attese soltanto in
+secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
+\funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
standard hanno delle definizioni diverse, ma le \acr{glibc}
seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
seguono quella di SUSv2 che prevede il seguente prototipo:
Pone il processo in stato di sleep per \param{usec} microsecondi.
\bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
- in caso di errore, nel qual caso \var{errno} assumerà il valore
+ in caso di errore, nel qual caso \var{errno} assumerà il valore
\errval{EINTR}.}
\end{prototype}
-Anche questa funzione, a seconda delle implementazioni, può presentare
-problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
+Anche questa funzione, a seconda delle implementazioni, può presentare
+problemi nell'interazione con \func{alarm} e \const{SIGALRM}. È pertanto
deprecata in favore della funzione \funcd{nanosleep}, definita dallo standard
-POSIX1.b, il cui prototipo è:
+POSIX1.b, il cui prototipo è:
\begin{prototype}{unistd.h}{int nanosleep(const struct timespec *req, struct
timespec *rem)}
In caso di interruzione restituisce il tempo restante in \param{rem}.
\bodydesc{La funzione restituisce zero se l'attesa viene completata, o $-1$
- in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
+ \item[\errcode{EINVAL}] si è specificato un numero di secondi negativo o un
numero di nanosecondi maggiore di 999.999.999.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}}
\end{prototype}
Lo standard richiede che la funzione sia implementata in maniera del tutto
-indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
+indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
-delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
+delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
fig.~\ref{fig:sys_timespec_struct}, che permette di specificare un tempo con
una precisione fino al nanosecondo.
2.4, in cui, per i processi riavviati dopo essere stati fermati da un
segnale, il tempo passato in stato \texttt{T} non viene considerato nel
calcolo della rimanenza.} e basta richiamare la funzione per completare
-l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
+l'attesa.\footnote{anche qui però occorre tenere presente che i tempi sono
arrotondati, per cui la precisione, per quanto migliore di quella ottenibile
- con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
+ con \func{sleep}, è relativa e in caso di molte interruzioni si può avere
una deriva, per questo esiste la funzione \func{clock\_nanosleep} (vedi
sez.~\ref{sec:sig_timer_adv}) che permette di specificare un tempo assoluto
- anziché un tempo relativo.}
+ anziché un tempo relativo.}
-Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
-nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
-temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
+Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al
+nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
+temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere la successiva interruzione del timer di sistema,
-cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
+occorrerà almeno attendere la successiva interruzione del timer di sistema,
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\const{HZ}, (sempre
che il sistema sia scarico ed il processa venga immediatamente rimesso in
-esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
arrotondato al multiplo successivo di 1/\const{HZ}.
-Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
+Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
precise del centesimo di secondo usando politiche di \itindex{scheduler}
scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
tal caso infatti il calcolo sul numero di interruzioni del timer veniva
evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
-pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
-rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
+pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
+rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
-può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
+può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
precisione disponibile sull'hardware della propria macchina.
\subsection{Un esempio elementare}
\label{sec:sig_sigchld}
-Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
+Un semplice esempio per illustrare il funzionamento di un gestore di segnale è
quello della gestione di \const{SIGCHLD}. Abbiamo visto in
sez.~\ref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
-conclusione di un processo è quella di inviare questo segnale al
-padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
+conclusione di un processo è quella di inviare questo segnale al
+padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
segnale non viene generato ed il sistema non genera \index{zombie} zombie
(lo stato di terminazione viene scartato senza dover chiamare una
- \func{wait}). L'azione predefinita è sempre quella di ignorare il segnale,
+ \func{wait}). L'azione predefinita è sempre quella di ignorare il segnale,
ma non attiva questo comportamento. Linux, come BSD e POSIX, non supporta
questa semantica ed usa il nome di \const{SIGCLD} come sinonimo di
\const{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
-stato di uscita di un processo, si può completare la gestione della
+stato di uscita di un processo, si può completare la gestione della
terminazione installando un gestore per \const{SIGCHLD} il cui unico compito
sia quello di chiamare \func{waitpid} per completare la procedura di
terminazione in modo da evitare la formazione di \index{zombie} zombie.
-In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
+In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
implementazione generica di una funzione di gestione per \const{SIGCHLD}, (che
si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
\cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
-gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
+gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
di \index{zombie} zombie.
\begin{figure}[!htb]
\label{fig:sig_sigchld_handl}
\end{figure}
-Il codice del gestore è di lettura immediata; come buona norma di
+Il codice del gestore è di lettura immediata; come buona norma di
programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
-Il compito principale del gestore è quello di ricevere lo stato di
+Il compito principale del gestore è quello di ricevere lo stato di
terminazione del processo, cosa che viene eseguita nel ciclo in
-(\texttt{\small 9--15}). Il ciclo è necessario a causa di una caratteristica
-fondamentale della gestione dei segnali: abbiamo già accennato come fra la
+(\texttt{\small 9--15}). Il ciclo è necessario a causa di una caratteristica
+fondamentale della gestione dei segnali: abbiamo già accennato come fra la
generazione di un segnale e l'esecuzione del gestore possa passare un certo
lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
i segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne
viene recapitato soltanto uno.
-Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
+Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
che molti processi figli terminino in rapida successione. Esso inoltre si
presenta tutte le volte che un segnale viene bloccato: per quanti siano i
-segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
-rimosso verrà recapitato un solo segnale.
+segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
+rimosso verrà recapitato un solo segnale.
Allora, nel caso della terminazione dei processi figli, se si chiamasse
\func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
-solo processo, anche se i processi terminati sono più di uno, e gli altri
+solo processo, anche se i processi terminati sono più di uno, e gli altri
resterebbero in stato di \index{zombie} zombie per un tempo indefinito.
Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
\section{La gestione avanzata dei segnali}
\label{sec:sig_adv_control}
-Le funzioni esaminate finora fanno riferimento alle modalità più elementari
+Le funzioni esaminate finora fanno riferimento alle modalità più elementari
della gestione dei segnali; non si sono pertanto ancora prese in
-considerazione le tematiche più complesse, collegate alle varie
+considerazione le tematiche più complesse, collegate alle varie
\itindex{race~condition} \textit{race condition} che i segnali possono
generare e alla natura asincrona degli stessi.
Affronteremo queste problematiche in questa sezione, partendo da un esempio
che le evidenzi, per poi prendere in esame le varie funzioni che permettono di
-risolvere i problemi più complessi connessi alla programmazione con i segnali,
+risolvere i problemi più complessi connessi alla programmazione con i segnali,
fino a trattare le caratteristiche generali della gestione dei medesimi nella
casistica ordinaria.
\subsection{Alcune problematiche aperte}
\label{sec:sig_example}
-Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
+Come accennato in sez.~\ref{sec:sig_pause_sleep} è possibile implementare
\func{sleep} a partire dall'uso di \func{pause} e \func{alarm}. A prima vista
-questo può sembrare di implementazione immediata; ad esempio una semplice
+questo può sembrare di implementazione immediata; ad esempio una semplice
versione di \func{sleep} potrebbe essere quella illustrata in
fig.~\ref{fig:sig_sleep_wrong}.
\label{fig:sig_sleep_wrong}
\end{figure}
-Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
-nostra implementazione sarà quello di installare il relativo gestore salvando
-il precedente (\texttt{\small 14-17}). Si effettuerà poi una chiamata ad
+Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
+nostra implementazione sarà quello di installare il relativo gestore salvando
+il precedente (\texttt{\small 14-17}). Si effettuerà poi una chiamata ad
\func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
18-20}) fino alla sua ricezione. Al ritorno di \func{pause}, causato dal
ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
(\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
-(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
+(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
l'interruzione di \func{pause} venisse causata da un altro segnale.
-Questo codice però, a parte il non gestire il caso in cui si è avuta una
-precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
+Questo codice però, a parte il non gestire il caso in cui si è avuta una
+precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
presenta una pericolosa \itindex{race~condition} \textit{race condition}.
Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
-\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
-tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
+\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
+tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
troverebbe di fronte ad un \itindex{deadlock} deadlock, in quanto \func{pause}
-non verrebbe mai più interrotta (se non in caso di un altro segnale).
+non verrebbe mai più interrotta (se non in caso di un altro segnale).
-Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
+Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
SVr2) usando la funzione \func{longjmp} (vedi sez.~\ref{sec:proc_longjmp}) per
uscire dal gestore; in questo modo, con una condizione sullo stato di
-uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
+uscita di quest'ultima, si può evitare la chiamata a \func{pause}, usando un
codice del tipo di quello riportato in fig.~\ref{fig:sig_sleep_incomplete}.
\begin{figure}[!htb]
In questo caso il gestore (\texttt{\small 18-27}) non ritorna come in
fig.~\ref{fig:sig_sleep_wrong}, ma usa \func{longjmp} (\texttt{\small 25}) per
rientrare nel corpo principale del programma; dato che in questo caso il
-valore di uscita di \func{setjmp} è 1, grazie alla condizione in
+valore di uscita di \func{setjmp} è 1, grazie alla condizione in
(\texttt{\small 9-12}) si evita comunque che \func{pause} sia chiamata a
vuoto.
Ma anche questa implementazione comporta dei problemi; in questo caso infatti
non viene gestita correttamente l'interazione con gli altri segnali; se
infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
-riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
+riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
inopportunamente l'esecuzione. Lo stesso tipo di problemi si presenterebbero
se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
system call bloccante.
-Un secondo esempio è quello in cui si usa il segnale per notificare una
-qualche forma di evento; in genere quello che si fa in questo caso è impostare
+Un secondo esempio è quello in cui si usa il segnale per notificare una
+qualche forma di evento; in genere quello che si fa in questo caso è impostare
nel gestore un opportuno flag da controllare nel corpo principale del
programma (con un codice del tipo di quello riportato in
-fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
+fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
gestore (\texttt{\small 14-19}) una variabile globale preventivamente
-inizializzata nel programma principale, il quale potrà determinare,
+inizializzata nel programma principale, il quale potrà determinare,
osservandone il contenuto, l'occorrenza o meno del segnale, e prendere le
relative azioni conseguenti (\texttt{\small 6-11}).
\label{fig:sig_event_wrong}
\end{figure}
-Questo è il tipico esempio di caso, già citato in
+Questo è il tipico esempio di caso, già citato in
sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
-\textit{race condition}; infatti, in una situazione in cui un segnale è già
-arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
+\textit{race condition}; infatti, in una situazione in cui un segnale è già
+arrivato (e \var{flag} è già ad 1) se un altro segnale arriva immediatamente
dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima della
-cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
+cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà perduta.
Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
-delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
+delle funzioni più sofisticate di quelle finora illustrate, queste hanno la
loro origine nella semplice interfaccia dei primi sistemi Unix, ma con esse
-non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
+non è possibile gestire in maniera adeguata di tutti i possibili aspetti con
cui un processo deve reagire alla ricezione di un segnale.
Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali
originarie, nate con la semantica inaffidabile, hanno dei limiti non
-superabili; in particolare non è prevista nessuna funzione che permetta di
+superabili; in particolare non è prevista nessuna funzione che permetta di
gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei
segnali ha introdotto una interfaccia di gestione completamente nuova, che
-permette di ottenere un controllo molto più dettagliato. In particolare lo
+permette di ottenere un controllo molto più dettagliato. In particolare lo
standard ha introdotto un nuovo tipo di dato \type{sigset\_t}, che permette di
rappresentare un \textsl{insieme di segnali} (un \textit{signal set}, come
viene usualmente chiamato), tale tipo di dato viene usato per gestire il
blocco dei segnali.
-In genere un \textsl{insieme di segnali} è rappresentato da un intero di
+In genere un \textsl{insieme di segnali} è rappresentato da un intero di
dimensione opportuna, di solito pari al numero di bit dell'architettura della
macchina,\footnote{nel caso dei PC questo comporta un massimo di 32 segnali
- distinti: dato che in Linux questi sono sufficienti non c'è necessità di
- nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
-specifico segnale; in questo modo è di solito possibile implementare le
+ distinti: dato che in Linux questi sono sufficienti non c'è necessità di
+ nessuna struttura più complicata.} ciascun bit del quale è associato ad uno
+specifico segnale; in questo modo è di solito possibile implementare le
operazioni direttamente con istruzioni elementari del processore. Lo standard
POSIX.1 definisce cinque funzioni per la manipolazione degli insiemi di
segnali: \funcd{sigemptyset}, \funcd{sigfillset}, \funcd{sigaddset},
\headdecl{signal.h}
\funcdecl{int sigemptyset(sigset\_t *set)} Inizializza un insieme di segnali
- vuoto (in cui non c'è nessun segnale).
+ vuoto (in cui non c'è nessun segnale).
\funcdecl{int sigfillset(sigset\_t *set)} Inizializza un insieme di segnali
pieno (in cui ci sono tutti i segnali).
\param{signum} dall'insieme di segnali \param{set}.
\funcdecl{int sigismember(const sigset\_t *set, int signum)} Controlla se il
- segnale \param{signum} è nell'insieme di segnali \param{set}.
+ segnale \param{signum} è nell'insieme di segnali \param{set}.
\bodydesc{Le prime quattro funzioni ritornano 0 in caso di successo, mentre
- \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
+ \func{sigismember} ritorna 1 se \param{signum} è in \param{set} e 0
altrimenti. In caso di errore tutte ritornano $-1$, con \var{errno}
- impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
+ impostata a \errval{EINVAL} (il solo errore possibile è che \param{signum}
non sia un segnale valido).}
\end{functions}
-Dato che in generale non si può fare conto sulle caratteristiche di una
-implementazione (non è detto che si disponga di un numero di bit sufficienti
+Dato che in generale non si può fare conto sulle caratteristiche di una
+implementazione (non è detto che si disponga di un numero di bit sufficienti
per mettere tutti i segnali in un intero, o in \type{sigset\_t} possono essere
immagazzinate ulteriori informazioni) tutte le operazioni devono essere
comunque eseguite attraverso queste funzioni.
\subsection{La funzione \func{sigaction}}
\label{sec:sig_sigaction}
-Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
+Abbiamo già accennato in sez.~\ref{sec:sig_signal} i problemi di compatibilità
relativi all'uso di \func{signal}. Per ovviare a tutto questo lo standard
POSIX.1 ha ridefinito completamente l'interfaccia per la gestione dei segnali,
-rendendola molto più flessibile e robusta, anche se leggermente più complessa.
+rendendola molto più flessibile e robusta, anche se leggermente più complessa.
-La funzione principale dell'interfaccia POSIX.1 per i segnali è
+La funzione principale dell'interfaccia POSIX.1 per i segnali è
\funcd{sigaction}. Essa ha sostanzialmente lo stesso uso di \func{signal},
-permette cioè di specificare le modalità con cui un segnale può essere gestito
-da un processo. Il suo prototipo è:
+permette cioè di specificare le modalità con cui un segnale può essere gestito
+da un processo. Il suo prototipo è:
\begin{prototype}{signal.h}{int sigaction(int signum, const struct sigaction
*act, struct sigaction *oldact)}
Installa una nuova azione per il segnale \param{signum}.
\bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido o si è
cercato di installare il gestore per \const{SIGKILL} o
\const{SIGSTOP}.
\item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
\param{signum}; si parla di \textsl{azione} e non di \textsl{gestore}
come nel caso di \func{signal}, in quanto la funzione consente di specificare
le varie caratteristiche della risposta al segnale, non solo la funzione che
-verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
+verrà eseguita alla sua occorrenza. Per questo lo standard raccomanda di
usare sempre questa funzione al posto di \func{signal} (che in genere viene
definita tramite essa), in quanto permette un controllo completo su tutti gli
aspetti della gestione di un segnale, sia pure al prezzo di una maggiore
-complessità d'uso.
+complessità d'uso.
-Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
-da esso specificata, se \param{oldact} non è nullo il valore dell'azione
+Se il puntatore \param{act} non è nullo, la funzione installa la nuova azione
+da esso specificata, se \param{oldact} non è nullo il valore dell'azione
corrente viene restituito indietro. Questo permette (specificando \param{act}
nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
che non consente di ottenere l'azione corrente senza installarne una nuova.
Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
tramite la quale si specificano tutte le caratteristiche dell'azione associata
-ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
definita secondo quanto riportato in fig.~\ref{fig:sig_sigaction}. Il campo
-\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
-più usato.
+\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
+più usato.
\begin{figure}[!htb]
\footnotesize \centering
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
+ \const{SA\_NOCLDSTOP}& Se il segnale è \const{SIGCHLD} allora non deve
essere notificato quando il processo figlio viene
fermato da uno dei segnali \const{SIGSTOP},
\const{SIGTSTP}, \const{SIGTTIN} o
\const{SIGTTOU}.\\
\const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
- predefinito una volta che il gestore è stato
- lanciato, riproduce cioè il comportamento della
+ predefinito una volta che il gestore è stato
+ lanciato, riproduce cioè il comportamento della
semantica inaffidabile.\\
\const{SA\_ONESHOT} & Nome obsoleto, sinonimo non standard di
\const{SA\_RESETHAND}; da evitare.\\
sez.~\ref{sec:sig_specific_features}).\\
\const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
call} quando vengono interrotte dal suddetto
- segnale; riproduce cioè il comportamento standard
+ segnale; riproduce cioè il comportamento standard
di BSD.\index{system~call~lente}\\
\const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
l'esecuzione del gestore.\\
gestore in forma estesa usando
\var{sa\_sigaction} al posto di
\var{sa\_handler}.\\
- \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora i processi
+ \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora i processi
figli non diventano \textit{zombie} quando
terminano.\footnotemark \\
\hline
\label{tab:sig_sa_flag}
\end{table}
-\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
+\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
modificare il comportamento di \func{waitpid}.}
-Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
-di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
- dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
+Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
+di utilizzare due forme diverse di gestore,\footnote{la possibilità è prevista
+ dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
con l'introduzione dei segnali \textit{real-time} (vedi
sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
informazioni addizionali usando \var{sa\_handler} con un secondo parametro
- addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
+ addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
rispettivamente attraverso i campi \var{sa\_sigaction} o
\var{sa\_handler},\footnote{i due campi devono essere usati in maniera
alternativa, in certe implementazioni questi campi vengono addirittura
- definiti come \ctyp{union}.} Quest'ultima è quella classica usata anche con
-\func{signal}, mentre la prima permette di usare un gestore più complesso, in
-grado di ricevere informazioni più dettagliate dal sistema, attraverso la
+ definiti come \ctyp{union}.} Quest'ultima è quella classica usata anche con
+\func{signal}, mentre la prima permette di usare un gestore più complesso, in
+grado di ricevere informazioni più dettagliate dal sistema, attraverso la
struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
Installando un gestore di tipo \var{sa\_sigaction} diventa allora possibile
valori possibili si trovano in \file{bits/siginfo.h}.} ed i valori possibili
in questo caso sono riportati in tab.~\ref{tab:sig_si_code_generic}.
-Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
+Nel caso di alcuni segnali però il valore di \var{si\_code} viene usato per
fornire una informazione specifica relativa alle motivazioni della ricezione
dello stesso; ad esempio i vari segnali di errore (\const{SIGILL},
\const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS}) lo usano per fornire
messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
\const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_access}) è stata
+ sez.~\ref{sec:file_asyncronous_access}) è stata
completata.\\
\const{SI\_SIGIO} & segnale di \const{SIGIO} da una coda (vedi
sez.~\ref{sec:file_asyncronous_operation}).\\
In questo caso il valore del campo \var{si\_code} deve essere verificato nei
confronti delle diverse costanti previste per ciascuno di detti
segnali;\footnote{dato che si tratta di una costante, e non di una maschera
- binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
- significato diverso a seconda del segnale a cui è associato.} l'elenco
-dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
+ binaria, i valori numerici vengono riutilizzati e ciascuno di essi avrà un
+ significato diverso a seconda del segnale a cui è associato.} l'elenco
+dettagliato dei nomi di queste costanti è riportato nelle diverse sezioni di
tab.~\ref{tab:sig_si_code_special} che sono state ordinate nella sequenza in
cui si sono appena citati i rispettivi segnali.\footnote{il prefisso del nome
indica comunque in maniera diretta il segnale a cui le costanti fanno
\const{TRAP\_BRKPT} & breakpoint sul processo.\\
\const{TRAP\_TRACE} & trappola di tracciamento del processo.\\
\hline
- \const{CLD\_EXITED} & il figlio è uscito.\\
- \const{CLD\_KILLED} & il figlio è stato terminato.\\
- \const{CLD\_DUMPED} & il figlio è terminato in modo anormale.\\
+ \const{CLD\_EXITED} & il figlio è uscito.\\
+ \const{CLD\_KILLED} & il figlio è stato terminato.\\
+ \const{CLD\_DUMPED} & il figlio è terminato in modo anormale.\\
\const{CLD\_TRAPPED} & un figlio tracciato ha raggiunto una trappola.\\
- \const{CLD\_STOPPED} & il figlio è stato fermato.\\
- \const{CLD\_CONTINUED}& il figlio è ripartito.\\
+ \const{CLD\_STOPPED} & il figlio è stato fermato.\\
+ \const{CLD\_CONTINUED}& il figlio è ripartito.\\
\hline
\const{POLL\_IN} & disponibili dati in ingresso.\\
\const{POLL\_OUT} & spazio disponibile sul buffer di uscita.\\
\const{POLL\_MSG} & disponibili messaggi in ingresso.\\
\const{POLL\_ERR} & errore di I/O.\\
- \const{POLL\_PRI} & disponibili dati di alta priorità in ingresso.\\
- \const{POLL\_HUP} & il dispositivo è stato disconnesso.\\
+ \const{POLL\_PRI} & disponibili dati di alta priorità in ingresso.\\
+ \const{POLL\_HUP} & il dispositivo è stato disconnesso.\\
\hline
\end{tabular}
\caption{Valori del campo \var{si\_code} della struttura \struct{sigaction}
\label{tab:sig_si_code_special}
\end{table}
-Il resto della struttura \struct{siginfo\_t} è definito come \ctyp{union} ed i
-valori eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
+Il resto della struttura \struct{siginfo\_t} è definito come \ctyp{union} ed i
+valori eventualmente presenti dipendono dal segnale, così \const{SIGCHLD} ed i
segnali \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) inviati tramite
\func{kill} avvalorano \var{si\_pid} e \var{si\_uid} coi valori corrispondenti
al processo che ha emesso il segnale, \const{SIGCHLD} avvalora anche i campi
rispettivamente lo stato di uscita, l'\textit{user time} e il \textit{system
time} (vedi sez.~\ref{sec:sys_cpu_times}) usati dal processo;
\const{SIGILL}, \const{SIGFPE}, \const{SIGSEGV} e \const{SIGBUS} avvalorano
-\var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \const{SIGIO} (vedi
+\var{si\_addr} con l'indirizzo in cui è avvenuto l'errore, \const{SIGIO} (vedi
sez.~\ref{sec:file_asyncronous_io}) avvalora \var{si\_fd} con il numero del
file descriptor e \var{si\_band} per i \itindex{out-of-band} dati urgenti
(vedi sez.~\ref{sec:TCP_urgent_data}) su un socket, il segnale inviato alla
scadenza di un timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}) avvalora i
campi \var{si\_timerid} e \var{si\_overrun}.
-Benché sia possibile usare nello stesso programma sia \func{sigaction} che
+Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
interagire in maniera anomala. Infatti l'azione specificata con
\struct{sigaction} contiene un maggior numero di informazioni rispetto al
semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
se si usa quest'ultima per installare un gestore sostituendone uno
-precedentemente installato con \func{sigaction}, non sarà possibile effettuare
+precedentemente installato con \func{sigaction}, non sarà possibile effettuare
un ripristino corretto dello stesso.
-Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
-ripristinare correttamente un gestore precedente, anche se questo è stato
-installato con \func{signal}. In generale poi non è il caso di usare il valore
+Per questo è sempre opportuno usare \func{sigaction}, che è in grado di
+ripristinare correttamente un gestore precedente, anche se questo è stato
+installato con \func{signal}. In generale poi non è il caso di usare il valore
di ritorno di \func{signal} come campo \var{sa\_handler}, o viceversa, dato
che in certi sistemi questi possono essere diversi. In definitiva dunque, a
-meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
+meno che non si sia vincolati all'aderenza stretta allo standard ISO C, è
sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}.
\begin{figure}[!htb]
\label{fig:sig_Signal_code}
\end{figure}
-Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
+Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
che abbia le stesse caratteristiche di \func{signal}, a definire attraverso
-\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
+\func{sigaction} una funzione equivalente \func{Signal}, il cui codice è
riportato in fig.~\ref{fig:sig_Signal_code} (il codice completo si trova nel
file \file{SigHand.c} nei sorgenti allegati). Si noti come, essendo la
-funzione estremamente semplice, essa è definita come
+funzione estremamente semplice, essa è definita come
\direct{inline};\footnote{la direttiva \direct{inline} viene usata per dire al
compilatore di trattare la funzione cui essa fa riferimento in maniera
speciale inserendo il codice direttamente nel testo del programma. Anche se
- i compilatori più moderni sono in grado di effettuare da soli queste
- manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
+ i compilatori più moderni sono in grado di effettuare da soli queste
+ manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica
usata per migliorare le prestazioni per le funzioni piccole ed usate di
frequente (in particolare nel kernel, dove in certi casi le ottimizzazioni
dal compilatore, tarate per l'uso in user space, non sono sempre adatte). In
Originariamente questo comportamento veniva ottenuto con delle macro, ma
queste hanno tutta una serie di problemi di sintassi nel passaggio degli
argomenti (si veda ad esempio \cite{PratC}) che in questo modo possono
- essere evitati.} per semplificare ulteriormente la definizione si è poi
+ essere evitati.} per semplificare ulteriormente la definizione si è poi
definito un apposito tipo \texttt{SigFunc}.
Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
permettono di bloccare temporaneamente (o di eliminare completamente,
impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un
-processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
+processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
- essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
- processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
+ essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
+ processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
accennato in sez.~\ref{sec:proc_fork} che la \textit{signal mask} viene
ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
-paragrafo precedente che essa può essere modificata, durante l'esecuzione di
+paragrafo precedente che essa può essere modificata, durante l'esecuzione di
un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong}
-è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
+è che in molti casi è necessario proteggere delle sezioni di codice (nel caso
in questione la sezione fra il controllo e la eventuale cancellazione del flag
che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri
che essi siano eseguite senza interruzioni.
-Le operazioni più semplici, come l'assegnazione o il controllo di una
-variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
-norma sono atomiche; quando si devono eseguire operazioni più complesse si può
+Le operazioni più semplici, come l'assegnazione o il controllo di una
+variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di
+norma sono atomiche; quando si devono eseguire operazioni più complesse si può
invece usare la funzione \funcd{sigprocmask} che permette di bloccare uno o
-più segnali; il suo prototipo è:
+più segnali; il suo prototipo è:
\begin{prototype}{signal.h}
{int sigprocmask(int how, const sigset\_t *set, sigset\_t *oldset)}
Cambia la \textsl{maschera dei segnali} del processo corrente.
\bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
\item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
\end{errlist}}
\end{prototype}
La funzione usa l'insieme di segnali dato all'indirizzo \param{set} per
modificare la maschera dei segnali del processo corrente. La modifica viene
-effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
+effettuata a seconda del valore dell'argomento \param{how}, secondo le modalità
specificate in tab.~\ref{tab:sig_procmask_how}. Qualora si specifichi un valore
non nullo per \param{oldset} la maschera dei segnali corrente viene salvata a
quell'indirizzo.
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
+ \const{SIG\_BLOCK} & L'insieme dei segnali bloccati è l'unione fra
quello specificato e quello corrente.\\
\const{SIG\_UNBLOCK} & I segnali specificati in \param{set} sono rimossi
dalla maschera dei segnali, specificare la
- cancellazione di un segnale non bloccato è legale.\\
- \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
+ cancellazione di un segnale non bloccato è legale.\\
+ \const{SIG\_SETMASK} & La maschera dei segnali è impostata al valore
specificato da \param{set}.\\
\hline
\end{tabular}
problemi come quelli mostrati in fig.~\ref{fig:sig_event_wrong}, proteggendo
la sezione fra il controllo del flag e la sua cancellazione.
-La funzione può essere usata anche all'interno di un gestore, ad esempio
-per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
+La funzione può essere usata anche all'interno di un gestore, ad esempio
+per riabilitare la consegna del segnale che l'ha invocato, in questo caso però
occorre ricordare che qualunque modifica alla maschera dei segnali viene
perduta alla conclusione del terminatore.
-Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
+Benché con l'uso di \func{sigprocmask} si possano risolvere la maggior parte
dei casi di \itindex{race~condition} \textit{race condition} restano aperte
-alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
+alcune possibilità legate all'uso di \func{pause}; il caso è simile a quello
del problema illustrato nell'esempio di fig.~\ref{fig:sig_sleep_incomplete}, e
-cioè la possibilità che il processo riceva il segnale che si intende usare per
+cioè la possibilità che il processo riceva il segnale che si intende usare per
uscire dallo stato di attesa invocato con \func{pause} immediatamente prima
dell'esecuzione di quest'ultima. Per poter effettuare atomicamente la modifica
della maschera dei segnali (di solito attivandone uno specifico) insieme alla
sospensione del processo lo standard POSIX ha previsto la funzione
-\funcd{sigsuspend}, il cui prototipo è:
+\funcd{sigsuspend}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigsuspend(const sigset\_t *mask)}
Imposta la \textit{signal mask} specificata, mettendo in attesa il processo.
\bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
+ \item[\errcode{EINVAL}] si è specificato un numero di segnale invalido.
\item[\errcode{EFAULT}] si sono specificati indirizzi non validi.
\end{errlist}}
\end{prototype}
sez.~\ref{sec:sig_sigaction} come con \func{sigaction} sia possibile bloccare
\const{SIGALRM} nell'installazione dei gestori degli altri segnali, per poter
usare l'implementazione vista in fig.~\ref{fig:sig_sleep_incomplete} senza
-interferenze. Questo però comporta una precauzione ulteriore al semplice uso
-della funzione, vediamo allora come usando la nuova interfaccia è possibile
+interferenze. Questo però comporta una precauzione ulteriore al semplice uso
+della funzione, vediamo allora come usando la nuova interfaccia è possibile
ottenere un'implementazione, riportata in fig.~\ref{fig:sig_sleep_ok} che non
-presenta neanche questa necessità.
+presenta neanche questa necessità.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Per evitare i problemi di interferenza con gli altri segnali in questo caso
-non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
+non si è usato l'approccio di fig.~\ref{fig:sig_sleep_incomplete} evitando
l'uso di \func{longjmp}. Come in precedenza il gestore (\texttt{\small 27-30})
non esegue nessuna operazione, limitandosi a ritornare per interrompere il
programma messo in attesa.
La prima parte della funzione (\texttt{\small 6-10}) provvede ad installare
l'opportuno gestore per \const{SIGALRM}, salvando quello originario, che
-sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
-successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
+sarà ripristinato alla conclusione della stessa (\texttt{\small 23}); il passo
+successivo è quello di bloccare \const{SIGALRM} (\texttt{\small 11-14}) per
evitare che esso possa essere ricevuto dal processo fra l'esecuzione di
\func{alarm} (\texttt{\small 16}) e la sospensione dello stesso. Nel fare
-questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
+questo si salva la maschera corrente dei segnali, che sarà ripristinata alla
fine (\texttt{\small 22}), e al contempo si prepara la maschera dei segnali
\var{sleep\_mask} per riattivare \const{SIGALRM} all'esecuzione di
\func{sigsuspend}.
-In questo modo non sono più possibili \itindex{race~condition} \textit{race
+In questo modo non sono più possibili \itindex{race~condition} \textit{race
condition} dato che \const{SIGALRM} viene disabilitato con
-\func{sigprocmask} fino alla chiamata di \func{sigsuspend}. Questo metodo è
-assolutamente generale e può essere applicato a qualunque altra situazione in
+\func{sigprocmask} fino alla chiamata di \func{sigsuspend}. Questo metodo è
+assolutamente generale e può essere applicato a qualunque altra situazione in
cui si deve attendere per un segnale, i passi sono sempre i seguenti:
\begin{enumerate*}
\item leggere la maschera dei segnali corrente e bloccare il segnale voluto
\label{sec:sig_signal_handler}
Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in
-corrispondenza della consegna di un segnale. In realtà un gestore non può
-essere una funzione qualunque, in quanto esso può essere eseguito in
+corrispondenza della consegna di un segnale. In realtà un gestore non può
+essere una funzione qualunque, in quanto esso può essere eseguito in
corrispondenza all'interruzione in un punto qualunque del programma
-principale, cosa che ad esempio può rendere problematico chiamare all'interno
-di un gestore di segnali la stessa funzione che dal segnale è stata
+principale, cosa che ad esempio può rendere problematico chiamare all'interno
+di un gestore di segnali la stessa funzione che dal segnale è stata
interrotta.
\index{funzioni!sicure|(}
-Il concetto è comunque più generale e porta ad una distinzione fra quelle che
+Il concetto è comunque più generale e porta ad una distinzione fra quelle che
POSIX chiama \textsl{funzioni insicure} (\textit{signal unsafe function}) e
-\textsl{funzioni sicure} (o più precisamente \textit{signal safe function});
+\textsl{funzioni sicure} (o più precisamente \textit{signal safe function});
quando un segnale interrompe una funzione insicura ed il gestore chiama al suo
-interno una funzione insicura il sistema può dare luogo ad un comportamento
+interno una funzione insicura il sistema può dare luogo ad un comportamento
indefinito, la cosa non avviene invece per le funzioni sicure.
Tutto questo significa che la funzione che si usa come gestore di segnale deve
-essere programmata con molta cura per evirare questa evenienza e che non è
+essere programmata con molta cura per evirare questa evenienza e che non è
possibile utilizzare al suo interno una qualunque funzione di sistema, se si
-vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
+vogliono evitare questi problemi si può ricorrere soltanto all'uso delle
funzioni considerate sicure.
L'elenco delle funzioni considerate sicure varia a seconda della
implementazione utilizzata e dello standard a cui si fa
-riferimento;\footnote{non è riportata una lista specifica delle funzioni
+riferimento;\footnote{non è riportata una lista specifica delle funzioni
sicure per Linux, si suppone pertanto che siano quelle richieste dallo
standard.} secondo quanto riportato dallo standard POSIX 1003.1 nella
revisione del 2003, le ``\textit{signal safe function}'' che possono essere
\end{figure}
-Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
+Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni
effettuate all'interno di un gestore di segnali, qualora si debbano compiere
-operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
+operazioni complesse è sempre preferibile utilizzare la tecnica in cui si usa
il gestore per impostare il valore di una qualche variabile globale, e poi si
eseguono le operazioni complesse nel programma verificando (con tutti gli
accorgimenti visti in precedenza) il valore di questa variabile tutte le volte
-che si è rilevata una interruzione dovuta ad un segnale.
+che si è rilevata una interruzione dovuta ad un segnale.
-\section{Funzionalità avanzate}
+\section{Funzionalità avanzate}
\label{sec:sig_advanced_signal}
-Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
+Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai
segnali ed in generale ai meccanismi di notifica, a partire dalla funzioni
introdotte per la gestione dei cosiddetti ``\textsl{segnali real-time}'', alla
gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione
Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi
\textit{real-time}, ha introdotto una estensione del modello classico dei
segnali che presenta dei significativi miglioramenti,\footnote{questa
- estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
+ estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle
\acr{glibc} 2.1.} in particolare sono stati superati tre limiti fondamentali
dei segnali classici:
\begin{basedescript}{\desclabelwidth{1cm}\desclabelstyle{\nextlinelabel}}
\item[I segnali non sono accumulati]
- se più segnali vengono generati prima dell'esecuzione di un gestore
- questo sarà eseguito una sola volta, ed il processo non sarà in grado di
- accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
+ se più segnali vengono generati prima dell'esecuzione di un gestore
+ questo sarà eseguito una sola volta, ed il processo non sarà in grado di
+ accorgersi di quante volte l'evento che ha generato il segnale è accaduto;
\item[I segnali non trasportano informazione]
i segnali classici non prevedono altra informazione sull'evento
che li ha generati se non il fatto che sono stati emessi (tutta
- l'informazione che il kernel associa ad un segnale è il suo numero);
+ l'informazione che il kernel associa ad un segnale è il suo numero);
\item[I segnali non hanno un ordine di consegna]
- l'ordine in cui diversi segnali vengono consegnati è casuale e non
- prevedibile. Non è possibile stabilire una priorità per cui la reazione a
+ l'ordine in cui diversi segnali vengono consegnati è casuale e non
+ prevedibile. Non è possibile stabilire una priorità per cui la reazione a
certi segnali ha la precedenza rispetto ad altri.
\end{basedescript}
Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle
nuove caratteristiche, che sono state associate ad una nuova classe di
segnali, che vengono chiamati \textsl{segnali real-time}, in particolare le
-funzionalità aggiunte sono:
+funzionalità aggiunte sono:
\begin{enumerate}
\item i segnali sono inseriti in una coda che permette di consegnare istanze
- multiple dello stesso segnale qualora esso venga inviato più volte prima
- dell'esecuzione del gestore; si assicura così che il processo riceva un
+ multiple dello stesso segnale qualora esso venga inviato più volte prima
+ dell'esecuzione del gestore; si assicura così che il processo riceva un
segnale per ogni occorrenza dell'evento che lo genera.
-\item è stata introdotta una priorità nella consegna dei segnali: i segnali
+\item è stata introdotta una priorità nella consegna dei segnali: i segnali
vengono consegnati in ordine a seconda del loro valore, partendo da quelli
- con un numero minore, che pertanto hanno una priorità maggiore.
-\item è stata introdotta la possibilità di restituire dei dati al gestore,
+ con un numero minore, che pertanto hanno una priorità maggiore.
+\item è stata introdotta la possibilità di restituire dei dati al gestore,
attraverso l'uso di un apposito campo \var{si\_value} nella struttura
\struct{siginfo\_t}, accessibile tramite gestori di tipo
\var{sa\_sigaction}.
\end{enumerate}
-Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
-sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
+Tutte queste nuove funzionalità eccetto l'ultima, che, come illustrato in
+sez.~\ref{sec:sig_sigaction}, è disponibile anche con i segnali ordinari, si
applicano solo ai nuovi segnali \textit{real-time}; questi ultimi sono
accessibili in un intervallo di valori specificati dalle due costanti
\const{SIGRTMIN} e \const{SIGRTMAX}, che specificano il numero minimo e
massimo associato ad un segnale \textit{real-time}.
-Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
-che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
+Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
+che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
-presente però che i primi segnali \textit{real-time} disponibili vendono usati
+presente però che i primi segnali \textit{real-time} disponibili vendono usati
dalle \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
modificato di conseguenza.\footnote{vengono usati i primi tre per la vecchia
implementazione dei \textit{LinuxThread} ed i primi due per la nuova NTPL
(\textit{New Thread Posix Library}), il che comporta che \const{SIGRTMIN} a
- seconda dei casi può essere 34 o 35.}
+ seconda dei casi può essere 34 o 35.}
Per questo motivo nei programmi che usano i segnali \textit{real-time} non si
deve mai usare un valore assoluto dato che si correrebbe il rischio di
\code{SIGRTMIN + n}) avendo inoltre cura di controllare di non aver mai
superato \const{SIGRTMAX}.
-I segnali con un numero più basso hanno una priorità maggiore e vengono
+I segnali con un numero più basso hanno una priorità maggiore e vengono
consegnati per primi, inoltre i segnali \textit{real-time} non possono
-interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
-loro azione predefinita è quella di terminare il programma. I segnali
-ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
+interrompere l'esecuzione di un gestore di un segnale a priorità più alta; la
+loro azione predefinita è quella di terminare il programma. I segnali
+ordinari hanno tutti la stessa priorità, che è più alta di quella di qualunque
segnale \textit{real-time}.\footnote{lo standard non definisce niente al
riguardo ma Linux, come molte altre implementazioni, adotta questa
politica.}
sez.~\ref{sec:file_asyncronous_io}) o per le code di messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_mq}); pertanto devono essere inviati esplicitamente.
-Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
+Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi
gestori devono essere installati con \func{sigaction}, specificando per
-\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
+\var{sa\_flags} la modalità \const{SA\_SIGINFO} che permette di utilizzare la
forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In
questo modo tutti i segnali \textit{real-time} possono restituire al gestore
una serie di informazioni aggiuntive attraverso l'argomento
-\struct{siginfo\_t}, la cui definizione è stata già vista in
+\struct{siginfo\_t}, la cui definizione è stata già vista in
fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa.
In particolare i campi utilizzati dai segnali \textit{real-time} sono
\label{fig:sig_sigval}
\end{figure}
-Questo è una \ctyp{union} di tipo \struct{sigval} (la sua definizione è in
-fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
+Questo è una \ctyp{union} di tipo \struct{sigval} (la sua definizione è in
+fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
\var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
-vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è
+vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è
presente anche nella struttura \struct{sigevent} (definita in
fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica
come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O
del segnale; in alcune definizioni essa viene identificata anche con
l'abbreviazione \type{sigval\_t}.
-A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
-inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
+A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
+inviare segnali \textit{real-time}, poiché non è in grado di fornire alcun
valore per \struct{sigval}; per questo motivo lo standard ha previsto una
-nuova funzione, \funcd{sigqueue}, il cui prototipo è:
+nuova funzione, \funcd{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigqueue(pid\_t pid, int signo, const union sigval value)}
gestore il valore \param{value}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
+ \item[\errcode{EAGAIN}] la coda è esaurita, ci sono già
\const{SIGQUEUE\_MAX} segnali in attesa si consegna.
\item[\errcode{EPERM}] non si hanno privilegi appropriati per inviare il
segnale al processo specificato.
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
\param{signo}.
\end{errlist}
ed inoltre \errval{ENOMEM}.}
\end{prototype}
-Il comportamento della funzione è analogo a quello di \func{kill}, ed i
+Il comportamento della funzione è analogo a quello di \func{kill}, ed i
privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli
stessi; un valore nullo di \param{signo} permette di verificare le condizioni
di errore senza inviare nessun segnale.
-Se il segnale è bloccato la funzione ritorna immediatamente, se si è
+Se il segnale è bloccato la funzione ritorna immediatamente, se si è
installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
-(vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
-viene inserito e diventa pendente; una volta consegnato riporterà nel campo
+(vale a dire che c'è posto nella coda dei segnali \textit{real-time}) esso
+viene inserito e diventa pendente; una volta consegnato riporterà nel campo
\var{si\_code} di \struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo
-\var{si\_value} riceverà quanto inviato con \param{value}. Se invece si è
-installato un gestore nella forma classica il segnale sarà generato, ma tutte
-le caratteristiche tipiche dei segnali \textit{real-time} (priorità e coda)
+\var{si\_value} riceverà quanto inviato con \param{value}. Se invece si è
+installato un gestore nella forma classica il segnale sarà generato, ma tutte
+le caratteristiche tipiche dei segnali \textit{real-time} (priorità e coda)
saranno perse.
-Secondo lo standard POSIX la profondità della coda è indicata dalla costante
+Secondo lo standard POSIX la profondità della coda è indicata dalla costante
\const{SIGQUEUE\_MAX},\footnote{una della tante costanti di sistema definite
dallo standard POSIX che non abbiamo riportato esplicitamente in
sez.~\ref{sec:sys_limits}.} il suo valore minimo secondo lo standard,
-\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una
+\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
- pari a 1024.} a partire dal kernel 2.6.8 il valore globale è stato rimosso e
+ 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
+utente, che può essere modificata con \func{setrlimit} come illustrato in
sez.~\ref{sec:sys_resource_limit}.
Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
gestire l'attesa di segnali specifici su una coda, esse servono in particolar
modo nel caso dei \itindex{thread} \textit{thread}, in cui si possono usare i
segnali \textit{real-time} come meccanismi di comunicazione elementare; la
-prima di queste funzioni è \funcd{sigwait}, il cui prototipo è:
+prima di queste funzioni è \funcd{sigwait}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigwait(const sigset\_t *set, int *sig)}
Attende che uno dei segnali specificati in \param{set} sia pendente.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINTR}] la funzione è stata interrotta.
- \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ \item[\errcode{EINTR}] la funzione è stata interrotta.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
\param{set}.
\end{errlist}
ed inoltre \errval{EFAULT}.}
La funzione estrae dall'insieme dei segnali pendenti uno qualunque dei segnali
specificati da \param{set}, il cui valore viene restituito in \param{sig}. Se
-sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
-il numero più basso). Se, nel caso di segnali \textit{real-time}, c'è più di
-un segnale pendente, ne verrà estratto solo uno. Una volta estratto il segnale
-non verrà più consegnato, e se era in una coda il suo posto sarà liberato. Se
-non c'è nessun segnale pendente il processo viene bloccato fintanto che non ne
+sono pendenti più segnali, viene estratto quello a priorità più alta (cioè con
+il numero più basso). Se, nel caso di segnali \textit{real-time}, c'è più di
+un segnale pendente, ne verrà estratto solo uno. Una volta estratto il segnale
+non verrà più consegnato, e se era in una coda il suo posto sarà liberato. Se
+non c'è nessun segnale pendente il processo viene bloccato fintanto che non ne
arriva uno.
Per un funzionamento corretto la funzione richiede che alla sua chiamata i
segnali di \param{set} siano bloccati. In caso contrario si avrebbe un
conflitto con gli eventuali gestori: pertanto non si deve utilizzare per
lo stesso segnale questa funzione e \func{sigaction}. Se questo non avviene il
-comportamento del sistema è indeterminato: il segnale può sia essere
+comportamento del sistema è indeterminato: il segnale può sia essere
consegnato che essere ricevuto da \func{sigwait}, il tutto in maniera non
prevedibile.
\funcdecl{int sigtimedwait(const sigset\_t *set, siginfo\_t *info, const
struct timespec *timeout)}
- Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
+ Analoga a \func{sigwaitinfo}, con un la possibilità di specificare un
timeout in \param{timeout}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
+ errore, nel qual caso \var{errno} assumerà uno dei valori già visti per
\func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
\begin{errlist}
- \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
+ \item[\errcode{EAGAIN}] si è superato il timeout senza che un segnale atteso
fosse emesso.
\end{errlist}
}
Entrambe le funzioni sono estensioni di \func{sigwait}. La prima permette di
ricevere, oltre al numero del segnale, anche le informazioni ad esso associate
tramite \param{info}; in particolare viene restituito il numero del segnale
-nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
+nel campo \var{si\_signo}, la sua causa in \var{si\_code}, e se il segnale è
stato immesso sulla coda con \func{sigqueue}, il valore di ritorno ad esso
-associato viene riportato in \var{si\_value}, che altrimenti è indefinito.
+associato viene riportato in \var{si\_value}, che altrimenti è indefinito.
-La seconda è identica alla prima ma in più permette di specificare un timeout,
-scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
-il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
-di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
-immediatamente; in questo modo si può eliminare un segnale dalla coda senza
+La seconda è identica alla prima ma in più permette di specificare un timeout,
+scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
+il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
+di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
+immediatamente; in questo modo si può eliminare un segnale dalla coda senza
dover essere bloccati qualora esso non sia presente.
\itindbeg{thread}
-L'uso di queste funzioni è principalmente associato alla gestione dei segnali
+L'uso di queste funzioni è principalmente associato alla gestione dei segnali
con i \textit{thread}. In genere esse vengono chiamate dal \textit{thread}
incaricato della gestione, che al ritorno della funzione esegue il codice che
usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
sez.~\ref{sec:sig_alarm_abort} sono state a lungo limitate dalla risoluzione
massima dei tempi dell'orologio interno del kernel, che era quella ottenibile
dal timer di sistema che governa lo \textit{scheduler},\footnote{e quindi
- limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
- sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
+ limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
+ sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
\texttt{HZ}.} i contatori usati per il calcolo dei tempo infatti erano
basati sul numero di \itindex{jiffies} \textit{jiffies} che vengono
incrementati ad ogni \textit{clock tick} del timer di sistema.\footnote{il che
comportava anche, come accennato in sez.~\ref{sec:sig_alarm_abort} per
\func{setitimer}, problemi per il massimo periodo di tempo copribile da
alcuni di questi orologi, come quelli associati al \textit{process time}
- almeno fino a quando, con il kernel 2.6.16, non è stato rimosso il limite di
+ almeno fino a quando, con il kernel 2.6.16, non è stato rimosso il limite di
un valore a 32 bit per i \textit{jiffies}.}
-Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
+Nelle architetture moderne però tutti i computer sono dotati di temporizzatori
hardware che possono supportare risoluzioni molto elevate, ed in maniera del
tutto indipendente dalla frequenza scelta per il timer di sistema che governa
lo \textit{scheduler};\footnote{normalmente si possono ottenere precisioni
questo lo standard POSIX.1-2001 ha previsto una serie di nuove funzioni
relative a quelli che vengono chiamati ``\textsl{orologi}
\textit{real-time}'', in grado di supportare risoluzioni fino al
-nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
+nanosecondo. Inoltre le CPU più moderne sono dotate a loro volta di contatori
ad alta definizione che consentono una grande accuratezza nella misura del
tempo da esse dedicato all'esecuzione di un processo.
-Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
-occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
-\textit{high resolution timer} che consentono di fare ciò sono stati
+Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
+occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
+\textit{high resolution timer} che consentono di fare ciò sono stati
introdotti nel kernel ufficiale solo a partire dalla versione
2.6.21.\footnote{deve essere stata abilitata l'opzione di compilazione
- \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
+ \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
precedenza come patch facenti parte dello sviluppo delle estensioni
\textit{real-time} del kernel, per cui alcune distribuzioni possono avere
questo supporto anche con versioni precedenti del kernel.} Le funzioni
-definite dallo standard POSIX per gestire orologi ad alta definizione però
-erano già presenti, essendo stata introdotte insieme ad altre funzioni per il
+definite dallo standard POSIX per gestire orologi ad alta definizione però
+erano già presenti, essendo stata introdotte insieme ad altre funzioni per il
supporto delle estensioni \textit{real-time} con il rilascio del kernel 2.6,
ma la risoluzione effettiva era nominale.
-A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
+A tutte le implementazioni che si rifanno a queste estensioni è richiesto di
disporre di una versione \textit{real-time} almeno per l'orologio generale di
sistema, quello che mantiene il \textit{calendar time} (vedi
sez.~\ref{sec:sys_time_base}), che in questa forma deve indicare il numero di
hardware specializzato).} Oltre all'orologio generale di sistema possono
essere presenti altri tipi di orologi \textit{real-time}, ciascuno dei quali
viene identificato da un opportuno valore di una variabile di tipo
-\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
+\type{clockid\_t}; un elenco di quelli disponibili su Linux è riportato in
tab.~\ref{tab:sig_timer_clockid_types}.
\begin{table}[htb]
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
+ \const{CLOCK\_REALTIME} & Orologio \textit{real-time} di sistema, può
essere impostato solo con privilegi
amministrativi.\\
\const{CLOCK\_MONOTONIC} & Orologio che indica un tempo monotono
crescente (a partire da un tempo iniziale non
- specificato) che non può essere modificato.\\
+ specificato) che non può essere modificato.\\
\const{CLOCK\_MONOTONIC\_RAW}&Simile al precedente, ma non subisce gli
aggiustamenti dovuti all'uso di NTP (viene
usato per fare riferimento ad una fonte
% TODO, dal 2.6.39 anche CLOCK_BOOTTIME, vedi http://lwn.net/Articles/432757/
-Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
+Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
programmi che le usano devono essere collegati con la libreria delle estensioni
\textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}. Si tenga
-presente inoltre che la disponibilità di queste funzionalità avanzate può
+presente inoltre che la disponibilità di queste funzionalità avanzate può
essere controllato dalla definizione della macro \macro{\_POSIX\_TIMERS} ad un
valore maggiore di 0, e che le ulteriori macro
\macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
\const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{tutte queste macro sono definite
in \texttt{unistd.h}, che pertanto deve essere incluso per poterle
controllarle.} Infine se il kernel ha il supporto per gli \textit{high
- resolution timer} un elenco degli orologi e dei timer può essere ottenuto
+ resolution timer} un elenco degli orologi e dei timer può essere ottenuto
tramite il file \procfile{/proc/timer\_list}.
Le due funzioni che ci consentono rispettivamente di modificare o leggere il
Imposta o legge un orologio \textit{real-time}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
- valido o il relativo orologio \textit{real-time} non è supportato dal
+ \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+ valido o il relativo orologio \textit{real-time} non è supportato dal
sistema.
\item[\errcode{EPERM}] non si ha il permesso di impostare l'orologio
indicato (solo per \func{clock\_settime}).
- \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
+ \item[\errcode{EFAULT}] l'indirizzo \param{tp} non è valido.
\end{errlist}
}
\end{functions}
di orologio su cui si vuole operare con uno dei valori di
tab.~\ref{tab:sig_timer_clockid_types} o con il risultato di una chiamata a
\func{clock\_getcpuclockid} (che tratteremo a breve), il secondo argomento
-invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
+invece è sempre il puntatore \param{tp} ad una struttura \struct{timespec}
(vedi fig.~\ref{fig:sys_timespec_struct}) che deve essere stata
-precedentemente allocata; nel primo caso questa dovrà anche essere stata
+precedentemente allocata; nel primo caso questa dovrà anche essere stata
inizializzata con il valore che si vuole impostare sull'orologio, mentre nel
-secondo verrà restituito al suo interno il valore corrente dello stesso.
+secondo verrà restituito al suo interno il valore corrente dello stesso.
Si tenga presente inoltre che per eseguire un cambiamento sull'orologio
generale di sistema \const{CLOCK\_REALTIME} occorrono i privilegi
amministrativi;\footnote{ed in particolare la \textit{capability}
- \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
+ \const{CAP\_SYS\_TIME}.} inoltre ogni cambiamento ad esso apportato non avrà
nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
-impostate sulle quantità di \textit{process time} o per un intervallo di tempo
+impostate sulle quantità di \textit{process time} o per un intervallo di tempo
da trascorrere, ma solo su quelle che hanno richiesto una temporizzazione ad
un istante preciso (in termini di \textit{calendar time}). Si tenga inoltre
-presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
-cui si può effettuare una modifica, infatti nonostante lo standard preveda la
-possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
+presente che nel caso di Linux \const{CLOCK\_REALTIME} è l'unico orologio per
+cui si può effettuare una modifica, infatti nonostante lo standard preveda la
+possibilità di modifiche anche per \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
\const{CLOCK\_THREAD\_CPUTIME\_ID}, il kernel non le consente.
Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza
funzione che consenta di ottenere la risoluzione effettiva fornita da un certo
-orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo è:
+orologio, la funzione è \funcd{clock\_getres} ed il suo prototipo è:
\begin{functions}
\headdecl{time.h}
Legge la risoluzione di un orologio \textit{real-time}.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
\begin{errlist}
- \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
+ \item[\errcode{EINVAL}] il valore specificato per \param{clockid} non è
valido.
- \item[\errcode{EFAULT}] l'indirizzo di \param{res} non è valido.
+ \item[\errcode{EFAULT}] l'indirizzo di \param{res} non è valido.
\end{errlist}
}
\end{functions}
La funzione richiede come primo argomento l'indicazione dell'orologio di cui
si vuole conoscere la risoluzione (effettuata allo stesso modo delle due
-precedenti) e questa verrà restituita in una struttura \struct{timespec}
+precedenti) e questa verrà restituita in una struttura \struct{timespec}
all'indirizzo puntato dall'argomento \param{res}.
Come accennato il valore di questa risoluzione dipende sia dall'hardware
disponibile che dalla implementazione delle funzioni, e costituisce il limite
-minimo di un intervallo di tempo che si può indicare. Qualunque valore si
+minimo di un intervallo di tempo che si può indicare. Qualunque valore si
voglia utilizzare nelle funzioni di impostazione che non corrisponda ad un
-multiplo intero di questa risoluzione, sarà troncato in maniera automatica.
+multiplo intero di questa risoluzione, sarà troncato in maniera automatica.
Si tenga presente inoltre che con l'introduzione degli \textit{high resolution
timer} i due orologi \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
\const{CLOCK\_THREAD\_CPUTIME\_ID} fanno riferimento ai contatori presenti in
opportuni registri interni del processore; questo sui sistemi multiprocessore
-può avere delle ripercussioni sulla precisione delle misure di tempo che vanno
-al di là della risoluzione teorica ottenibile con \func{clock\_getres}, che
-può essere ottenuta soltanto quando si è sicuri che un processo (o un
+può avere delle ripercussioni sulla precisione delle misure di tempo che vanno
+al di là della risoluzione teorica ottenibile con \func{clock\_getres}, che
+può essere ottenuta soltanto quando si è sicuri che un processo (o un
\textit{thread}) sia sempre stato eseguito sullo stesso processore.
Con i sistemi multiprocessore infatti ogni singola CPU ha i suoi registri
-interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il
+interni, e se ciascuna di esse utilizza una base di tempo diversa (se cioè il
segnale di temporizzazione inviato ai processori non ha una sola provenienza)
-in genere ciascuna di queste potrà avere delle frequenze leggermente diverse,
+in genere ciascuna di queste potrà avere delle frequenze leggermente diverse,
e si otterranno pertanto dei valori dei contatori scorrelati fra loro, senza
-nessuna possibilità di sincronizzazione.
+nessuna possibilità di sincronizzazione.
-Il problema si presenta, in forma più lieve, anche se la base di tempo è la
+Il problema si presenta, in forma più lieve, anche se la base di tempo è la
stessa, dato che un sistema multiprocessore non avvia mai tutte le CPU allo
-stesso istante, si potrà così avere di nuovo una differenza fra i contatori,
-soggetta però soltanto ad uno sfasamento costante. Per questo caso il kernel
+stesso istante, si potrà così avere di nuovo una differenza fra i contatori,
+soggetta però soltanto ad uno sfasamento costante. Per questo caso il kernel
per alcune architetture ha del codice che consente di ridurre al minimo la
-differenza, ma non può essere comunque garantito che questa si annulli (anche
+differenza, ma non può essere comunque garantito che questa si annulli (anche
se in genere risulta molto piccola e trascurabile nella gran parte dei casi).
Per poter gestire questo tipo di problematiche lo standard ha previsto una
apposita funzione che sia in grado di ottenere l'identificativo dell'orologio
-associato al \textit{process time} di un processo, la funzione è
-\funcd{clock\_getcpuclockid} ed il suo prototipo è:
+associato al \textit{process time} di un processo, la funzione è
+\funcd{clock\_getcpuclockid} ed il suo prototipo è:
\begin{functions}
\headdecl{time.h}
Ottiene l'identificatore dell'orologio di CPU usato da un processo.
\bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
- in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
+ in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
valori:
\begin{errlist}
- \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo
+ \item[\errcode{ENOSYS}] non c'è il supporto per ottenere l'orologio relativo
al \textit{process time} di un altro processo, e \param{pid} non
corrisponde al processo corrente.
\item[\errcode{EPERM}] il chiamante non ha il permesso di accedere alle
La funzione ritorna l'identificativo di un orologio di sistema associato ad un
processo indicato tramite l'argomento \param{pid}. Un utente normale, posto
-che il kernel sia sufficientemente recente da supportare questa funzionalità,
-può accedere soltanto ai dati relativi ai propri processi.
+che il kernel sia sufficientemente recente da supportare questa funzionalità,
+può accedere soltanto ai dati relativi ai propri processi.
Del tutto analoga a \func{clock\_getcpuclockid}, ma da utilizzare per ottenere
-l'orologio associato ad un \textit{thread} invece che a un processo, è
+l'orologio associato ad un \textit{thread} invece che a un processo, è
\funcd{pthread\_getcpuclockid},\footnote{per poter usare la funzione, come per
qualunque funzione che faccia riferimento ai \textit{thread}, occorre
effettuare il collegamento alla relativa libreria di gestione compilando il
- programma con \texttt{-lpthread}.} il cui prototipo è:
+ programma con \texttt{-lpthread}.} il cui prototipo è:
\begin{functions}
\headdecl{pthread.h}
\headdecl{time.h}
\textit{thread}.
\bodydesc{La funzione restituisce 0 in caso di successo o un numero positivo
- in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
+ in caso di errore, nel qual caso \var{errno} assumerà uno dei seguenti
valori:
\begin{errlist}
- \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
+ \item[\errcode{ENOENT}] la funzione non è supportata dal sistema.
\item[\errcode{ESRCH}] non esiste il \textit{thread} identificato
da \param{thread}.
\end{errlist}
% TODO, dal 2.6.39 aggiunta clock_adjtime
-Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
-ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
+Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile
+ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in
sez.~\ref{sec:sig_alarm_abort} come l'interfaccia di \func{setitimer} derivata
da BSD presenti delle serie limitazioni,\footnote{in particolare la
- possibilità di perdere un segnale sotto carico.} tanto che nello standard
+ possibilità di perdere un segnale sotto carico.} tanto che nello standard
POSIX.1-2008 questa viene marcata come obsoleta, e ne viene fortemente
consigliata la sostituzione con nuova interfaccia definita dallo standard
POSIX.1-2001 che va sotto il nome di \textit{Posix Timer API}. Questa
-interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
-di varie funzionalità è stato aggiunto solo in un secondo tempo.
+interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto
+di varie funzionalità è stato aggiunto solo in un secondo tempo.
-Una delle principali differenze della nuova interfaccia è che un processo può
+Una delle principali differenze della nuova interfaccia è che un processo può
utilizzare un numero arbitrario di timer; questi vengono creati (ma non
-avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo è:
+avviati) tramite la funzione \funcd{timer\_create}, il cui prototipo è:
\begin{functions}
\headdecl{signal.h}
\headdecl{time.h}
Crea un nuovo timer Posix.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
\begin{errlist}
\item[\errcode{EAGAIN}] fallimento nel tentativo di allocare le strutture
dei timer.
\item[\errcode{EINVAL}] uno dei valori specificati per \param{clockid} o per
i campi \var{sigev\_notify}, \var{sigev\_signo} o
- \var{sigev\_notify\_thread\_id} di \param{evp} non è valido.
+ \var{sigev\_notify\_thread\_id} di \param{evp} non è valido.
\item[\errcode{ENOMEM}] errore di allocazione della memoria.
\end{errlist}
}
La funzione richiede tre argomenti: il primo argomento serve ad indicare quale
tipo di orologio si vuole utilizzare e prende uno dei valori di
-tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è
+tab.~\ref{tab:sig_timer_clockid_types},\footnote{di detti valori però non è
previsto l'uso di \const{CLOCK\_MONOTONIC\_RAW} mentre
\const{CLOCK\_PROCESS\_CPUTIME\_ID} e \const{CLOCK\_THREAD\_CPUTIME\_ID}
- sono disponibili solo a partire dal kernel 2.6.12.} si può così fare
+ sono disponibili solo a partire dal kernel 2.6.12.} si può così fare
riferimento sia ad un tempo assoluto che al tempo utilizzato dal processo (o
\textit{thread}) stesso.
-Il secondo argomento richiede una trattazione più dettagliata, in quanto
+Il secondo argomento richiede una trattazione più dettagliata, in quanto
introduce una struttura di uso generale, \struct{sigevent}, che viene
utilizzata anche da altre funzioni, come quelle per l'I/O asincrono (vedi
sez.~\ref{sec:file_asyncronous_io}) o le code di messaggi POSIX (vedi
\end{minipage}
\normalsize
\caption{La struttura \structd{sigevent}, usata per specificare in maniera
- generica diverse modalità di notifica degli eventi.}
+ generica diverse modalità di notifica degli eventi.}
\label{fig:struct_sigevent}
\end{figure}
-La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è
+La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è
riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva
- dipende dall'implementazione, quella mostrata è la versione descritta nella
- pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il
-più importante essendo quello che indica le modalità della notifica, gli altri
-dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono
+ dipende dall'implementazione, quella mostrata è la versione descritta nella
+ pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il
+più importante essendo quello che indica le modalità della notifica, gli altri
+dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono
riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del meccanismo di
notifica viene fatta impostando uno dei valori di
tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli
eventuali ulteriori argomenti necessari a secondo della scelta
-effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
+effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
(nel caso di uso dei \textit{thread}) di una funzione di modifica in un
\textit{thread} dedicato.
\const{SIGEV\_SIGNAL} & La notifica viene effettuata inviando al processo
chiamante il segnale specificato dal campo
\var{sigev\_signo}; se il gestore di questo
- segnale è stato installato con
- \const{SA\_SIGINFO} gli verrà restituito il
+ segnale è stato installato con
+ \const{SA\_SIGINFO} gli verrà restituito il
valore specificato con \var{sigev\_value} (una
\ctyp{union} \texttt{sigval}, la cui definizione
- è in fig.~\ref{fig:sig_sigval}) come valore del
+ è in fig.~\ref{fig:sig_sigval}) come valore del
campo \var{si\_value} di \struct{siginfo\_t}.\\
\const{SIGEV\_THREAD} & La notifica viene effettuata creando un nuovo
\itindex{thread} \textit{thread} che esegue la
funzione di notifica specificata da
\var{sigev\_notify\_function} con argomento
- \var{sigev\_value}. Se questo è diverso da
+ \var{sigev\_value}. Se questo è diverso da
\val{NULL}, il \textit{thread} viene creato con
gli attributi specificati da
\var{sigev\_notify\_attribute}.\footnotemark\\
\const{SIGEV\_THREAD\_ID}& Invia la notifica come segnale (con le stesse
- modalità di \const{SIGEV\_SIGNAL}) che però viene
+ modalità di \const{SIGEV\_SIGNAL}) che però viene
recapitato al \textit{thread} indicato dal campo
- \var{sigev\_notify\_thread\_id}. Questa modalità
- è una estensione specifica di Linux, creata come
+ \var{sigev\_notify\_thread\_id}. Questa modalità
+ è una estensione specifica di Linux, creata come
supporto per le librerie di gestione dei
\textit{thread}, pertanto non deve essere usata
da codice normale.\\
\label{tab:sigevent_sigev_notify}
\end{table}
-\footnotetext{nel caso dei \textit{timer} questa funzionalità è considerata un
+\footnotetext{nel caso dei \textit{timer} questa funzionalità è considerata un
esempio di pessima implementazione di una interfaccia, richiesta dallo
- standard POSIX, ma da evitare totalmente, a causa della possibilità di
- creare disservizi generando una gran quantità di processi, tanto che ne è
+ standard POSIX, ma da evitare totalmente, a causa della possibilità di
+ creare disservizi generando una gran quantità di processi, tanto che ne è
stata richiesta addirittura la rimozione.}
-Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
-argomento l'indirizzo di una di queste strutture per indicare le modalità con
+Nel caso di \func{timer\_create} occorrerà passare alla funzione come secondo
+argomento l'indirizzo di una di queste strutture per indicare le modalità con
cui si vuole essere notificati della scadenza del timer, se non si specifica
-nulla (passando un valore \val{NULL}) verrà inviato il segnale
-\const{SIGALRM} al processo corrente, o per essere più precisi verrà
+nulla (passando un valore \val{NULL}) verrà inviato il segnale
+\const{SIGALRM} al processo corrente, o per essere più precisi verrà
utilizzato un valore equivalente all'aver specificato \const{SIGEV\_SIGNAL}
per \var{sigev\_notify}, \const{SIGALRM} per \var{sigev\_signo} e
l'identificatore del timer come valore per \var{sigev\_value.sival\_int}.
Il terzo argomento deve essere l'indirizzo di una variabile di tipo
-\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
+\type{timer\_t} dove sarà scritto l'identificativo associato al timer appena
creato, da usare in tutte le successive funzioni di gestione. Una volta creato
-questo identificativo resterà univoco all'interno del processo stesso fintanto
+questo identificativo resterà univoco all'interno del processo stesso fintanto
che il timer non viene cancellato.
Si tenga presente che eventuali POSIX timer creati da un processo non vengono
segnale \textit{real-time} per ciascun timer che viene creato con
\func{timer\_create}; dato che ciascuno di essi richiede un posto nella coda
dei segnali \textit{real-time}, il numero massimo di timer utilizzabili da un
-processo è limitato dalle dimensioni di detta coda, ed anche, qualora questo
+processo è limitato dalle dimensioni di detta coda, ed anche, qualora questo
sia stato impostato, dal limite \const{RLIMIT\_SIGPENDING}.
Una volta creato il timer \func{timer\_create} ed ottenuto il relativo
-identificatore, si può attivare o disattivare un allarme (in gergo
+identificatore, si può attivare o disattivare un allarme (in gergo
\textsl{armare} o \textsl{disarmare} il timer) con la funzione
-\funcd{timer\_settime}, il cui prototipo è:
+\funcd{timer\_settime}, il cui prototipo è:
\begin{functions}
\headdecl{signal.h}
\headdecl{time.h}
Arma o disarma il timer POSIX.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
\begin{errlist}
- \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
+ \item[\errcode{EINVAL}] all'interno di \param{new\_value.value} si è
specificato un tempo negativo o un numero di nanosecondi maggiore di
999999999.
- \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
+ \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
per \param{new\_value} o \param{old\_value}.
\end{errlist}
}
La funzione richiede che si indichi la scadenza del timer con
l'argomento \param{new\_value}, che deve essere specificato come puntatore ad
-una struttura di tipo \struct{itimerspec}, la cui definizione è riportata in
-fig.~\ref{fig:struct_itimerspec}; se il puntatore \param{old\_value} è diverso
-da \val{NULL} il valore corrente della scadenza verrà restituito in una
+una struttura di tipo \struct{itimerspec}, la cui definizione è riportata in
+fig.~\ref{fig:struct_itimerspec}; se il puntatore \param{old\_value} è diverso
+da \val{NULL} il valore corrente della scadenza verrà restituito in una
analoga struttura, ovviamente in entrambi i casi le strutture devono essere
state allocate.
Ciascuno dei due campi di \struct{itimerspec} indica un tempo, da specificare
con una precisione fino al nanosecondo tramite una struttura \struct{timespec}
-(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
+(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
\var{it\_value} indica la prima scadenza dell'allarme. Di default, quando il
-valore di \param{flags} è nullo, questo valore viene considerato come un
-intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
+valore di \param{flags} è nullo, questo valore viene considerato come un
+intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
dopo il numero di secondi e nanosecondi indicati da questo campo.} se invece
si usa per \param{flags} il valore \const{TIMER\_ABSTIME},\footnote{al momento
- questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
+ questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
considerato come un valore assoluto rispetto al valore usato dall'orologio a
-cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
+cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
indicare o come un tempo assoluto, quando si opera rispetto all'orologio di
sistema (nel qual caso il valore deve essere in secondi e nanosecondi dalla
\textit{epoch}) o come numero di secondi o nanosecondi rispetto alla
partenza di un orologio di CPU, quando si opera su uno di questi.} Infine
un valore nullo di \var{it\_value}\footnote{per nullo si intende con valori
- nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
+ nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
utilizzato, indipendentemente dal tipo di orologio utilizzato, per disarmare
l'allarme.
Il campo \var{it\_interval} di \struct{itimerspec} viene invece utilizzato per
-impostare un allarme periodico. Se il suo valore è nullo (se cioè sono nulli
-tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
+impostare un allarme periodico. Se il suo valore è nullo (se cioè sono nulli
+tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
una sola volta secondo quando indicato con \var{it\_value}, altrimenti il
-valore specificato verrà preso come l'estensione del periodo di ripetizione
-della generazione dell'allarme, che proseguirà indefinitamente fintanto che
+valore specificato verrà preso come l'estensione del periodo di ripetizione
+della generazione dell'allarme, che proseguirà indefinitamente fintanto che
non si disarmi il timer.
-Se il timer era già stato armato la funzione sovrascrive la precedente
-impostazione, se invece si indica come prima scadenza un tempo già passato,
-l'allarme verrà notificato immediatamente e al contempo verrà incrementato il
+Se il timer era già stato armato la funzione sovrascrive la precedente
+impostazione, se invece si indica come prima scadenza un tempo già passato,
+l'allarme verrà notificato immediatamente e al contempo verrà incrementato il
contatore dei superamenti. Questo contatore serve a fornire una indicazione al
programma che riceve l'allarme su un eventuale numero di scadenze che sono
passate prima della ricezione della notifica dell'allarme.
-É infatti possibile, qualunque sia il meccanismo di notifica scelto, che
-quest'ultima venga ricevuta dopo che il timer è scaduto più di una
+É infatti possibile, qualunque sia il meccanismo di notifica scelto, che
+quest'ultima venga ricevuta dopo che il timer è scaduto più di una
volta.\footnote{specialmente se si imposta un timer con una ripetizione a
frequenza elevata.} Nel caso dell'uso di un segnale infatti il sistema mette
in coda un solo segnale per timer,\footnote{questo indipendentemente che si
tratti di un segnale ordinario o \textit{real-time}; per questi ultimi
- sarebbe anche possibile inviare un segnale per ogni scadenza, questo però
+ sarebbe anche possibile inviare un segnale per ogni scadenza, questo però
non viene fatto per evitare il rischio, tutt'altro che remoto, di riempire
- la coda.} e se il sistema è sotto carico o se il segnale è bloccato, prima
-della sua ricezione può passare un intervallo di tempo sufficientemente lungo
-ad avere scadenze multiple, e lo stesso può accadere anche se si usa un
+ la coda.} e se il sistema è sotto carico o se il segnale è bloccato, prima
+della sua ricezione può passare un intervallo di tempo sufficientemente lungo
+ad avere scadenze multiple, e lo stesso può accadere anche se si usa un
\textit{thread} di notifica.
-Per questo motivo il gestore del segnale o il \textit{thread} di notifica può
-ottenere una indicazione di quante volte il timer è scaduto dall'invio della
-notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo è:
+Per questo motivo il gestore del segnale o il \textit{thread} di notifica può
+ottenere una indicazione di quante volte il timer è scaduto dall'invio della
+notifica utilizzando la funzione \funcd{timer\_getoverrun}, il cui prototipo è:
\begin{functions}
\headdecl{time.h}
Ottiene il numero di scadenze di un timer POSIX.
\bodydesc{La funzione restituisce il numero di scadenze di un timer in caso
- di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà
+ di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà
il valore:
\begin{errlist}
\item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
}
\end{functions}
-La funzione ritorna il numero delle scadenze avvenute, che può anche essere
+La funzione ritorna il numero delle scadenze avvenute, che può anche essere
nullo se non ve ne sono state. Come estensione specifica di Linux,\footnote{in
- realtà lo standard POSIX.1-2001 prevede gli \textit{overrun} solo per i
+ realtà lo standard POSIX.1-2001 prevede gli \textit{overrun} solo per i
segnali e non ne parla affatto in riferimento ai \textit{thread}.} quando
-si usa un segnale come meccanismo di notifica, si può ottenere direttamente
+si usa un segnale come meccanismo di notifica, si può ottenere direttamente
questo valore nel campo \var{si\_overrun} della struttura \struct{siginfo\_t}
(illustrata in fig.~\ref{fig:sig_siginfo_t}) restituita al gestore del segnale
-installato con \func{sigaction}; in questo modo non è più necessario eseguire
+installato con \func{sigaction}; in questo modo non è più necessario eseguire
successivamente una chiamata a questa funzione per ottenere il numero delle
scadenze. Al gestore del segnale viene anche restituito, come ulteriore
informazione, l'identificativo del timer, in questo caso nel campo
Qualora si voglia rileggere lo stato corrente di un timer, ed ottenere il
tempo mancante ad una sua eventuale scadenza, si deve utilizzare la funzione
-\funcd{timer\_gettime}, il cui prototipo è:
+\funcd{timer\_gettime}, il cui prototipo è:
\begin{functions}
\headdecl{time.h}
Legge lo stato di un timer POSIX.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
- \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
+ \item[\errcode{EFAULT}] si è specificato un indirizzo non valido
per \param{curr\_value}.
\end{errlist}
}
\var{it\_value}. Questo tempo viene sempre indicato in forma relativa, anche
nei casi in cui il timer era stato precedentemente impostato con
\const{TIMER\_ABSTIME} indicando un tempo assoluto. Il ritorno di un valore
-nullo nel campo \var{it\_value} significa che il timer è disarmato o è
+nullo nel campo \var{it\_value} significa che il timer è disarmato o è
definitivamente scaduto.
Nel campo \var{it\_interval} di \param{curr\_value} viene invece restituito,
impostato per una ripetizione e doveva operare, come suol dirsi, a colpo
singolo (in gergo \textit{one shot}).
-Infine, quando un timer non viene più utilizzato, lo si può cancellare,
+Infine, quando un timer non viene più utilizzato, lo si può cancellare,
rimuovendolo dal sistema e recuperando le relative risorse, effettuando in
sostanza l'operazione inversa rispetto a \funcd{timer\_create}. Per questo
compito lo standard prevede una apposita funzione \funcd{timer\_delete}, il
-cui prototipo è:
+cui prototipo è:
\begin{functions}
\headdecl{time.h}
Cancella un timer POSIX.
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
+ errore, nel qual caso \var{errno} assumerà uno dei seguenti valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{timerid} non indica un timer valido.
\end{errlist}
La funzione elimina il timer identificato da \param{timerid}, disarmandolo se
questo era stato attivato. Nel caso, poco probabile ma comunque possibile, che
un timer venga cancellato prima della ricezione del segnale pendente per la
-notifica di una scadenza, il comportamento del sistema è indefinito.
+notifica di una scadenza, il comportamento del sistema è indefinito.
\subsection{Ulteriori funzioni di gestione}
\label{sec:sig_specific_features}
In questo ultimo paragrafo esamineremo le rimanenti funzioni di gestione dei
-segnali non descritte finora, relative agli aspetti meno utilizzati e più
+segnali non descritte finora, relative agli aspetti meno utilizzati e più
``\textsl{esoterici}'' della interfaccia.
-La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
-standard POSIX.1; il suo prototipo è:
+La prima di queste funzioni è \funcd{sigpending}, anch'essa introdotta dallo
+standard POSIX.1; il suo prototipo è:
\begin{prototype}{signal.h}
{int sigpending(sigset\_t *set)}
\end{prototype}
La funzione permette di ricavare quali sono i segnali pendenti per il processo
-in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
+in corso, cioè i segnali che sono stati inviati dal kernel ma non sono stati
ancora ricevuti dal processo in quanto bloccati. Non esiste una funzione
-equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
-dato che essa può solo assicurare che un segnale è stato inviato, dato che
+equivalente nella vecchia interfaccia, ma essa è tutto sommato poco utile,
+dato che essa può solo assicurare che un segnale è stato inviato, dato che
escluderne l'avvenuto invio al momento della chiamata non significa nulla
rispetto a quanto potrebbe essere in un qualunque momento successivo.
-Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
-di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
+Una delle caratteristiche di BSD, disponibile anche in Linux, è la possibilità
+di usare uno \itindex{stack} \textit{stack} alternativo per i segnali; è cioè
possibile fare usare al sistema un altro \itindex{stack} \textit{stack}
(invece di quello relativo al processo, vedi sez.~\ref{sec:proc_mem_layout})
solo durante l'esecuzione di un gestore. L'uso di uno \textit{stack}
-alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
+alternativo è del tutto trasparente ai gestori, occorre però seguire una certa
procedura:
\begin{enumerate*}
\item allocare un'area di memoria di dimensione sufficiente da usare come
In genere il primo passo viene effettuato allocando un'opportuna area di
memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
\const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
-allocare una quantità di spazio opportuna, in modo da evitare overflow. La
-prima delle due è la dimensione canonica per uno \itindex{stack}
-\textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
+allocare una quantità di spazio opportuna, in modo da evitare overflow. La
+prima delle due è la dimensione canonica per uno \itindex{stack}
+\textit{stack} di segnali e di norma è sufficiente per tutti gli usi normali.
-La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
+La seconda è lo spazio che occorre al sistema per essere in grado di lanciare
il gestore e la dimensione di uno \textit{stack} alternativo deve essere
-sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
-spazio necessario al gestore gli si può aggiungere questo valore per allocare
+sempre maggiore di questo valore. Quando si conosce esattamente quanto è lo
+spazio necessario al gestore gli si può aggiungere questo valore per allocare
uno \itindex{stack} \textit{stack} di dimensione sufficiente.
Come accennato, per poter essere usato, lo \itindex{stack} \textit{stack} per
i segnali deve essere indicato al sistema attraverso la funzione
-\funcd{sigaltstack}; il suo prototipo è:
+\funcd{sigaltstack}; il suo prototipo è:
\begin{prototype}{signal.h}
{int sigaltstack(const stack\_t *ss, stack\_t *oss)}
Installa un nuovo \textit{stack} per i segnali.
\bodydesc{La funzione restituisce zero in caso di successo e $-1$ per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ENOMEM}] la dimensione specificata per il nuovo
- \textit{stack} è minore di \const{MINSIGSTKSZ}.
- \item[\errcode{EPERM}] uno degli indirizzi non è valido.
- \item[\errcode{EFAULT}] si è cercato di cambiare lo \textit{stack}
- alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
+ \textit{stack} è minore di \const{MINSIGSTKSZ}.
+ \item[\errcode{EPERM}] uno degli indirizzi non è valido.
+ \item[\errcode{EFAULT}] si è cercato di cambiare lo \textit{stack}
+ alternativo mentre questo è attivo (cioè il processo è in esecuzione su di
esso).
- \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
- valore diverso da zero che non è \const{SS\_DISABLE}.
+ \item[\errcode{EINVAL}] \param{ss} non è nullo e \var{ss\_flags} contiene un
+ valore diverso da zero che non è \const{SS\_DISABLE}.
\end{errlist}}
\end{prototype}
disabilitare uno \textit{stack} occorre indicare \const{SS\_DISABLE} come
valore di \var{ss\_flags} e gli altri valori saranno ignorati.
-Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
+Se \param{oss} non è nullo verrà restituito dalla funzione indirizzo e
dimensione dello \itindex{stack} \textit{stack} corrente nei relativi campi,
-mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
-processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
-possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
+mentre \var{ss\_flags} potrà assumere il valore \const{SS\_ONSTACK} se il
+processo è in esecuzione sullo \textit{stack} alternativo (nel qual caso non è
+possibile cambiarlo) e \const{SS\_DISABLE} se questo non è abilitato.
In genere si installa uno \itindex{stack} \textit{stack} alternativo per i
segnali quando si teme di avere problemi di esaurimento dello \textit{stack}
\textit{stack} alternativo continueranno ad usare quest'ultimo, che, al
contrario di quanto avviene per lo \itindex{stack} \textit{stack} ordinario
dei processi, non si accresce automaticamente (ed infatti eccederne le
-dimensioni può portare a conseguenze imprevedibili). Si ricordi infine che
+dimensioni può portare a conseguenze imprevedibili). Si ricordi infine che
una chiamata ad una funzione della famiglia \func{exec} cancella ogni
\textit{stack} alternativo.
Abbiamo visto in fig.~\ref{fig:sig_sleep_incomplete} come si possa usare
\func{longjmp} per uscire da un gestore rientrando direttamente nel corpo
-del programma; sappiamo però che nell'esecuzione di un gestore il segnale
+del programma; sappiamo però che nell'esecuzione di un gestore il segnale
che l'ha invocato viene bloccato, e abbiamo detto che possiamo ulteriormente
modificarlo con \func{sigprocmask}.
caratteristiche si sono abilitate con le macro viste in
sez.~\ref{sec:intro_gcc_glibc_std}.
-Lo standard POSIX però prevede anche la presenza di altre due funzioni
+Lo standard POSIX però prevede anche la presenza di altre due funzioni
\funcd{sigsetjmp} e \funcd{siglongjmp}, che permettono di decidere quale dei
due comportamenti il programma deve assumere; i loro prototipi sono:
\begin{functions}
Le due funzioni prendono come primo argomento la variabile su cui viene
salvato il contesto dello \itindex{stack} \textit{stack} per permettere il
-\index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
+\index{salto~non-locale} salto non-locale; nel caso specifico essa è di tipo
\type{sigjmp\_buf}, e non \type{jmp\_buf} come per le analoghe di
sez.~\ref{sec:proc_longjmp} in quanto in questo caso viene salvata anche la
maschera dei segnali.
Nel caso di \func{sigsetjmp}, se si specifica un valore di \param{savesigs}
-diverso da zero la maschera dei valori sarà salvata in \param{env} e
+diverso da zero la maschera dei valori sarà salvata in \param{env} e
ripristinata in un successivo \func{siglongjmp}; quest'ultima funzione, a
-parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
+parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a
\func{longjmp}.
\label{cha:advanced_socket}
-Esamineremo in questo capitolo le funzionalità più evolute della gestione dei
+Esamineremo in questo capitolo le funzionalità più evolute della gestione dei
socket, le funzioni avanzate, la gestione dei dati urgenti e
\textit{out-of-band} e dei messaggi ancillari, come l'uso come l'uso del I/O
multiplexing (vedi sez.~\ref{sec:file_multiplexing}) con i socket.
\section{Le funzioni di I/O avanzate}
\label{sec:sock_advanced_IO}
-Tratteremo in questa sezione le funzioni di I/O più avanzate che permettono di
-controllare le funzionalità specifiche della comunicazione dei dati che sono
+Tratteremo in questa sezione le funzioni di I/O più avanzate che permettono di
+controllare le funzionalità specifiche della comunicazione dei dati che sono
disponibili con i vari tipi di socket.
\subsection{I messaggi ancillari}
\label{sec:net_ancillary_data}
-Quanto è stata attivata l'opzione \const{IP\_RECVERR} il kernel attiva per il
+Quanto è stata attivata l'opzione \const{IP\_RECVERR} il kernel attiva per il
socket una speciale coda su cui vengono inviati tutti gli errori riscontrati.
Questi possono essere riletti usando il flag \const{MSG\_ERRQUEUE}, nel qual
-caso sarà passato come messaggio ancillare una struttura di tipo
+caso sarà passato come messaggio ancillare una struttura di tipo
\struct{sock\_extended\_err} illustrata in
fig.~\ref{fig:sock_extended_err_struct}.
\itindbeg{out-of-band}
-Una caratteristica particolare dei socket TCP è quella che consente di inviare
+Una caratteristica particolare dei socket TCP è quella che consente di inviare
all'altro capo della comunicazione una sorta di messaggio privilegiato, che si
richiede che sia trattato il prima possibile. Si fa riferimento a questa
-funzionalità come all'invio dei cosiddetti \textsl{dati urgenti} (o
+funzionalità come all'invio dei cosiddetti \textsl{dati urgenti} (o
\textit{urgent data}); talvolta essi chiamati anche dati \textit{out-of-band}
-poiché, come vedremo più avanti, possono essere letti anche al di fuori del
+poiché, come vedremo più avanti, possono essere letti anche al di fuori del
flusso di dati normale.
-Come già accennato in sez.~\ref{sec:file_multiplexing} la presenza di dati
+Come già accennato in sez.~\ref{sec:file_multiplexing} la presenza di dati
urgenti viene rilevata in maniera specifica sia di \func{select} (con il
\itindex{file~descriptor~set} \textit{file descriptor set} \param{exceptfds})
che da \func{poll} (con la condizione \const{POLLRDBAND}).
-Le modalità di lettura dei dati urgenti sono due, la prima e più comune
+Le modalità di lettura dei dati urgenti sono due, la prima e più comune
prevede l'uso di \func{recvmsg} con
% TODO aggiungere pezzo di codice per inviare dati urgenti all'echo server
-La seconda modalità di lettura prevede invece l'uso dell'opzione dei socket
+La seconda modalità di lettura prevede invece l'uso dell'opzione dei socket
\const{SO\_OOBINLINE} (vedi sez.~\ref{sec:sock_generic_options}) che consente
di ricevere i dati urgenti direttamente nel flusso dei dati del socket; in tal
-caso però si pone il problema di come distinguere i dati normali da quelli
-urgenti. Come già accennato in sez.~\ref{sec:sock_ioctl_IP} a questo scopo si
-può usare \func{ioctl} con l'operazione \const{SIOCATMARK}, che consente di
-sapere se si è arrivati o meno all'\textit{urgent mark}.
+caso però si pone il problema di come distinguere i dati normali da quelli
+urgenti. Come già accennato in sez.~\ref{sec:sock_ioctl_IP} a questo scopo si
+può usare \func{ioctl} con l'operazione \const{SIOCATMARK}, che consente di
+sapere se si è arrivati o meno all'\textit{urgent mark}.
La procedura allora prevede che, una volta che si sia rilevata la presenza di
dati urgenti, si ripeta la lettura ordinaria dal socket fintanto che
\const{SIOCATMARK} non restituisce un valore diverso da zero; la successiva
-lettura restituirà i dati urgenti.
+lettura restituirà i dati urgenti.
\itindend{out-of-band}
\section{L'uso dell'I/O non bloccante}
\label{sec:sock_noblok_IO}
-Tratteremo in questa sezione le modalità avanzate che permettono di utilizzare
+Tratteremo in questa sezione le modalità avanzate che permettono di utilizzare
i socket con una comunicazione non bloccante, in modo da
Abbiamo visto in sez.~\ref{sec:sock_ipv4_options} come di possa usare
\func{setsockopt} con l'opzione \const{IP\_OPTIONS} per impostare le opzioni
IP associate per i pacchetti associati ad un socket. Vedremo qui il
-significato di tali opzioni e le modalità con cui esse possono essere
+significato di tali opzioni e le modalità con cui esse possono essere
utilizzate ed impostate.
% LocalWords: socket of multiplexing sez sendmsg recvmsg RECVERR kernel MSG
\chapter{La gestione dei socket}
\label{cha:sock_generic_management}
-Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
+Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative
alla gestione dei socket, come la gestione della risoluzione di nomi e
-indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
+indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai
socket, e le funzioni di controllo che permettono di modificarne il
comportamento.
\label{sec:sock_name_resolution}
Negli esempi dei capitoli precedenti abbiamo sempre identificato le singole
-macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
+macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
conversione elementare illustrate in sez.~\ref{sec:sock_addr_func} che
permettono di passare da un indirizzo espresso in forma \textit{dotted
decimal} ad un numero. Vedremo in questa sezione le funzioni utilizzate per
poter utilizzare dei nomi simbolici al posto dei valori numerici, e viceversa
quelle che permettono di ottenere i nomi simbolici associati ad indirizzi,
-porte o altre proprietà del sistema.
+porte o altre proprietà del sistema.
\subsection{La struttura del \textit{resolver}}
\label{sec:sock_resolver}
\itindbeg{resolver}
-La risoluzione dei nomi è associata tradizionalmente al servizio del
+La risoluzione dei nomi è associata tradizionalmente al servizio del
\textit{Domain Name Service} che permette di identificare le macchine su
internet invece che per numero IP attraverso il relativo \textsl{nome a
dominio}.\footnote{non staremo ad entrare nei dettagli della definizione di
- cosa è un nome a dominio, dandolo per noto, una introduzione alla
+ cosa è un nome a dominio, dandolo per noto, una introduzione alla
problematica si trova in \cite{AGL} (cap.~9) mentre per una trattazione
- approfondita di tutte le problematiche relative al DNS si può fare
- riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
+ approfondita di tutte le problematiche relative al DNS si può fare
+ riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
server che forniscono su internet questo servizio, mentre nel nostro caso
affronteremo la problematica dal lato client, di un qualunque programma che
necessita di compiere questa operazione.
\label{fig:sock_resolver_schema}
\end{figure}
-Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza
+Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza
possibile fra nomi simbolici e valori numerici, come abbiamo visto anche in
sez.~\ref{sec:sys_user_group} per le corrispondenze fra nomi di utenti e
-gruppi e relativi identificatori numerici; per quanto riguarda però tutti i
+gruppi e relativi identificatori numerici; per quanto riguarda però tutti i
nomi associati a identificativi o servizi relativi alla rete il servizio di
-risoluzione è gestito in maniera unificata da un insieme di funzioni fornite
+risoluzione è gestito in maniera unificata da un insieme di funzioni fornite
con le librerie del C, detto appunto \textit{resolver}.
-Lo schema di funzionamento del \textit{resolver} è illustrato in
+Lo schema di funzionamento del \textit{resolver} è illustrato in
fig.~\ref{fig:sock_resolver_schema}; in sostanza i programmi hanno a
disposizione un insieme di funzioni di libreria con cui chiamano il
-\textit{resolver}, indicate con le frecce nere. Ricevuta la richiesta è
+\textit{resolver}, indicate con le frecce nere. Ricevuta la richiesta è
quest'ultimo che, sulla base della sua configurazione, esegue le operazioni
necessarie a fornire la risposta, che possono essere la lettura delle
informazioni mantenute nei relativi dei file statici presenti sulla macchina,
una interrogazione ad un DNS (che a sua volta, per il funzionamento del
-protocollo, può interrogarne altri) o la richiesta ad altri server per i quali
+protocollo, può interrogarne altri) o la richiesta ad altri server per i quali
sia fornito il supporto, come LDAP.\footnote{la sigla LDAP fa riferimento ad
un protocollo, il \textit{Lightweight Directory Access Protocol}, che
prevede un meccanismo per la gestione di \textsl{elenchi} di informazioni
- via rete; il contenuto di un elenco può essere assolutamente generico, e
- questo permette il mantenimento dei più vari tipi di informazioni su una
+ via rete; il contenuto di un elenco può essere assolutamente generico, e
+ questo permette il mantenimento dei più vari tipi di informazioni su una
infrastruttura di questo tipo.}
-La configurazione del \textit{resolver} attiene più alla amministrazione di
-sistema che alla programmazione, ciò non di meno, prima di trattare le varie
+La configurazione del \textit{resolver} attiene più alla amministrazione di
+sistema che alla programmazione, ciò non di meno, prima di trattare le varie
funzioni di librerie utilizzate dai programmi, vale la pena fare una
panoramica generale. Originariamente la configurazione del \textit{resolver}
riguardava esclusivamente le questioni relative alla gestione dei nomi a
dominio, e prevedeva solo l'utilizzo del DNS e del file statico
\conffile{/etc/hosts}.
-Per questo aspetto il file di configurazione principale del sistema è
+Per questo aspetto il file di configurazione principale del sistema è
\conffile{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi
IP dei server DNS da contattare; a questo si affianca il file
-\conffile{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui
+\conffile{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui
eseguire la risoluzione dei nomi (se usare prima i valori di
\conffile{/etc/hosts} o quelli del DNS). Tralasciamo i dettagli relativi alle
varie direttive che possono essere usate in questi file, che si trovano nelle
rispettive pagine di manuale.
-Con il tempo però è divenuto possibile fornire diversi sostituti per
+Con il tempo però è divenuto possibile fornire diversi sostituti per
l'utilizzo delle associazione statiche in \conffile{/etc/hosts}, inoltre oltre
alla risoluzione dei nomi a dominio ci sono anche altri nomi da risolvere,
come quelli che possono essere associati ad una rete (invece che ad una
singola macchina) o ai gruppi di macchine definiti dal servizio
-NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
+NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
Sun, e poi diffuso su tutte le piattaforme unix-like, che permette di
raggruppare all'interno di una rete (in quelli che appunto vengono chiamati
\textit{netgroup}) varie macchine, centralizzando i servizi di definizione
- di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
+ di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
file statici \conffile{/etc/protocols} e \conffile{/etc/services}. Molte di
-queste informazioni non si trovano su un DNS, ma in una rete locale può essere
+queste informazioni non si trovano su un DNS, ma in una rete locale può essere
molto utile centralizzare il mantenimento di alcune di esse su opportuni
server. Inoltre l'uso di diversi supporti possibili per le stesse
-informazioni (ad esempio il nome delle macchine può essere mantenuto sia
+informazioni (ad esempio il nome delle macchine può essere mantenuto sia
tramite \conffile{/etc/hosts}, che con il DNS, che con NIS) comporta il
problema dell'ordine in cui questi vengono interrogati.\footnote{con le
implementazioni classiche i vari supporti erano introdotti modificando
\itindbeg{Name~Service~Switch}
Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
-eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
+eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
-associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
+associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
introdotto la prima volta nelle librerie standard di Solaris, le \acr{glibc}
hanno ripreso lo stesso schema, si tenga presente che questo sistema non
esiste per altre librerie standard come le \acr{libc5} o le \acr{uclib}.}
cui abbiamo accennato anche in sez.~\ref{sec:sys_user_group} per quanto
riguarda la gestione dei dati associati a utenti e gruppi. Il \textit{Name
- Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
+ Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
sistema di librerie dinamiche che permette di definire in maniera generica sia
i supporti su cui mantenere i dati di corrispondenza fra nomi e valori
numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti
\hline
\hline
\texttt{passwd} & Corrispondenze fra nome dell'utente e relative
- proprietà (\acr{uid}, gruppo principale, ecc.).\\
+ proprietà (\acr{uid}, gruppo principale, ecc.).\\
\texttt{shadow} & Corrispondenze fra username e password dell'utente
(e altre informazioni relative alle password).\\
- \texttt{group} & Corrispondenze fra nome del gruppo e proprietà dello
+ \texttt{group} & Corrispondenze fra nome del gruppo e proprietà dello
stesso.\\
\texttt{aliases} & Alias per la posta elettronica.\\
\texttt{ethers} & Corrispondenze fra numero IP e MAC address della
% TODO rivedere meglio la tabella
-Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
+Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
file \conffile{/etc/nsswitch.conf}; questo contiene una riga\footnote{seguendo
una convezione comune per i file di configurazione le righe vuote vengono
ignorate e tutto quello che segue un carattere ``\texttt{\#}'' viene
le relative informazioni sono raggiungibili, scritti nell'ordine in cui si
vuole siano interrogati.
-Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
+Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
\texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che
-realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
-nome utilizzato dentro \conffile{/etc/nsswitch.conf}, dovrà essere presente
+realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
+nome utilizzato dentro \conffile{/etc/nsswitch.conf}, dovrà essere presente
(usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
implementa le funzioni.
-In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
-su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
+In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
+su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
fornire dal sistema del \textit{Name Service Switch}, dal punto di vista di un
programma che deve effettuare la risoluzione di un nome a dominio, tutto
quello che conta sono le funzioni classiche che il \textit{resolver} mette a
-disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
+disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
quelle che tratteremo nelle sezioni successive.
\itindend{Name~Service~Switch}
\label{sec:sock_resolver_functions}
Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
-dominio conviene trattare in maniera più dettagliata il meccanismo principale
-da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
-benché in teoria sia solo uno dei possibili supporti su cui mantenere le
+dominio conviene trattare in maniera più dettagliata il meccanismo principale
+da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
+benché in teoria sia solo uno dei possibili supporti su cui mantenere le
informazioni, in pratica costituisce il meccanismo principale con cui vengono
risolti i nomi a dominio. Per questo motivo esistono una serie di funzioni di
libreria che servono specificamente ad eseguire delle interrogazioni verso un
server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
generiche di libreria usate anche dal sistema del \textit{resolver}.
-Il sistema del DNS è in sostanza di un database distribuito organizzato in
+Il sistema del DNS è in sostanza di un database distribuito organizzato in
maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno
dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a
dominio sono organizzati in una struttura ad albero analoga a quella
secondo livello (come \texttt{.truelite.it}), ecc. In questo caso le
separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}''
ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si
- stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
- ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
+ stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
+ ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
genere non viene mai scritto esplicitamente, ma che, come chiunque abbia
- configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
+ configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
\textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo
funziona con il criterio della \textsl{delegazione}, un server responsabile
-per un dominio di primo livello può delegare la risoluzione degli indirizzi
+per un dominio di primo livello può delegare la risoluzione degli indirizzi
per un suo dominio di secondo livello ad un altro server, il quale a sua volta
-potrà delegare la risoluzione di un eventuale sotto-dominio di terzo livello ad
+potrà delegare la risoluzione di un eventuale sotto-dominio di terzo livello ad
un altro server ancora.
-In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
+In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
un nome a dominio in un indirizzo IP; ciascuna voce nel database viene
-chiamata \textit{resource record}, e può contenere diverse informazioni. In
+chiamata \textit{resource record}, e può contenere diverse informazioni. In
genere i \textit{resource record} vengono classificati per la \textsl{classe
di indirizzi} cui i dati contenuti fanno riferimento, e per il \textsl{tipo}
di questi ultimi.\footnote{ritroveremo classi di indirizzi e tipi di record
- più avanti in tab.~\ref{tab:DNS_address_class} e
+ più avanti in tab.~\ref{tab:DNS_address_class} e
tab.~\ref{tab:DNS_record_type}.} Oggigiorno i dati mantenuti nei server DNS
sono quasi esclusivamente relativi ad indirizzi internet, per cui in pratica
viene utilizzata soltanto una classe di indirizzi; invece le corrispondenze
fra un nome a dominio ed un indirizzo IP sono solo uno fra i vari tipi di
informazione che un server DNS fornisce normalmente.
-L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
+L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
\textit{resolver} prevede, rispetto a quelle relative alla semplice
risoluzione dei nomi, un insieme di funzioni specifiche dedicate
-all'interrogazione di un server DNS; la prima di queste funzioni è
-\funcd{res\_init}, il cui prototipo è:
+all'interrogazione di un server DNS; la prima di queste funzioni è
+\funcd{res\_init}, il cui prototipo è:
\begin{functions}
\headdecl{netinet/in.h} \headdecl{arpa/nameser.h} \headdecl{resolv.h}
\funcdecl{int res\_init(void)}
errore.}
\end{functions}
-La funzione legge il contenuto dei file di configurazione (i già citati
+La funzione legge il contenuto dei file di configurazione (i già citati
\file{resolv.conf} e \file{host.conf}) per impostare il dominio di default,
gli indirizzi dei server DNS da contattare e l'ordine delle ricerche; se non
-sono specificati server verrà utilizzato l'indirizzo locale, e se non è
-definito un dominio di default sarà usato quello associato con l'indirizzo
-locale (ma questo può essere sovrascritto con l'uso della variabile di
-ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
+sono specificati server verrà utilizzato l'indirizzo locale, e se non è
+definito un dominio di default sarà usato quello associato con l'indirizzo
+locale (ma questo può essere sovrascritto con l'uso della variabile di
+ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
funzione direttamente in quanto viene automaticamente chiamata la prima volta
che si esegue una delle altre.
Le impostazioni e lo stato del \textit{resolver} vengono mantenuti in una
serie di variabili raggruppate nei campi di una apposita struttura \var{\_res}
-usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
+usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
utilizzata internamente alle funzioni essendo definita come variabile globale;
questo consente anche di accedervi direttamente all'interno di un qualunque
programma, una volta che la sia opportunamente dichiarata come:
Tutti i campi della struttura sono ad uso interno, e vengono usualmente
inizializzati da \func{res\_init} in base al contenuto dei file di
-configurazione e ad una serie di valori di default. L'unico campo che può
-essere utile modificare è \var{\_res.options}, una maschera binaria che
+configurazione e ad una serie di valori di default. L'unico campo che può
+essere utile modificare è \var{\_res.options}, una maschera binaria che
contiene una serie di bit di opzione che permettono di controllare il
comportamento del \textit{resolver}.
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \const{RES\_INIT} & Viene attivato se è stata chiamata
+ \const{RES\_INIT} & Viene attivato se è stata chiamata
\func{res\_init}. \\
\const{RES\_DEBUG} & Stampa dei messaggi di debug.\\
\const{RES\_AAONLY} & Accetta solo risposte autoritative.\\
eseguire una interrogazione ricorsiva.\\
\const{RES\_DEFNAMES} & Se attivo \func{res\_search} aggiunge il nome
del dominio di default ai nomi singoli (che non
- contengono cioè un ``\texttt{.}'').\\
+ contengono cioè un ``\texttt{.}'').\\
\const{RES\_STAYOPEN} & Usato con \const{RES\_USEVC} per mantenere
aperte le connessioni TCP fra interrogazioni
diverse. \\
\label{tab:resolver_option}
\end{table}
-Per utilizzare questa funzionalità per modificare le impostazioni direttamente
-da programma occorrerà impostare un opportuno valore per questo campo ed
+Per utilizzare questa funzionalità per modificare le impostazioni direttamente
+da programma occorrerà impostare un opportuno valore per questo campo ed
invocare esplicitamente \func{res\_init}, dopo di che le altre funzioni
prenderanno le nuove impostazioni. Le costanti che definiscono i vari bit di
questo campo, ed il relativo significato sono illustrate in
tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
esempio il valore di default delle opzioni, espresso dalla costante
-\const{RES\_DEFAULT}, è definito come:
+\const{RES\_DEFAULT}, è definito come:
\includecodesnip{listati/resolv_option_def.c}
-Non tratteremo il significato degli altri campi non essendovi necessità di
+Non tratteremo il significato degli altri campi non essendovi necessità di
modificarli direttamente; gran parte di essi sono infatti impostati dal
-contenuto dei file di configurazione, mentre le funzionalità controllate da
+contenuto dei file di configurazione, mentre le funzionalità controllate da
alcuni di esse possono essere modificate con l'uso delle opportune variabili
di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
\texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
controlla quante volte viene ripetuto il tentativo di connettersi ad un server
-DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
+DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
- della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
+ della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
valore preso come base (in numero di secondi) per definire la scadenza di una
richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
il tempo di scadenza per il numero massimo di volte stabilito da
\texttt{RES\_RETRY}.
-La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
+La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
eseguire una richiesta ad un server DNS per un nome a dominio
\textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
- Qualified Domain Name}); il suo prototipo è:
+ Qualified Domain Name}); il suo prototipo è:
\begin{functions}
\headdecl{netinet/in.h}
risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve
essere specificata la classe di indirizzi in cui eseguire la ricerca con
\param{class}, ed il tipo di \textit{resource record} che si vuole ottenere
-con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
-lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
+con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
+lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
allocato in precedenza.
Una seconda funzione di ricerca, analoga a \func{res\_query}, che prende gli
-stessi argomenti, ma che esegue l'interrogazione con le funzionalità
+stessi argomenti, ma che esegue l'interrogazione con le funzionalità
addizionali previste dalle due opzioni \const{RES\_DEFNAMES} e
-\const{RES\_DNSRCH}, è \funcd{res\_search}, il cui prototipo è:
+\const{RES\_DNSRCH}, è \funcd{res\_search}, il cui prototipo è:
\begin{functions}
\headdecl{netinet/in.h}
\headdecl{arpa/nameser.h}
In sostanza la funzione ripete una serie di chiamate a \func{res\_query}
aggiungendo al nome contenuto nella stringa \param{dname} il dominio di
default da cercare, fermandosi non appena trova un risultato. Il risultato di
-entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
-seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
+entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
+seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
programma (o di altre funzioni) estrarre i relativi dati, esistono una serie
di funzioni interne usate per la scansione di questi dati, per chi fosse
-interessato una trattazione dettagliata è riportata nel quattordicesimo
+interessato una trattazione dettagliata è riportata nel quattordicesimo
capitolo di \cite{DNSbind}.
Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in
pratica oggi viene utilizzata soltanto quella degli indirizzi internet; le
costanti che identificano dette classi, da usare come valore per l'argomento
\param{class} delle precedenti funzioni, sono riportate in
-tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
- \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
+tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
+ \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
\begin{table}[htb]
\centering
record}. L'elenco delle costanti\footnote{ripreso dai file di dichiarazione
\file{arpa/nameser.h} e \file{arpa/nameser\_compat.h}.} che definiscono i
valori che si possono usare per l'argomento \param{type} per specificare il
-tipo di \textit{resource record} da richiedere è riportato in
+tipo di \textit{resource record} da richiedere è riportato in
tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
hanno gli stessi nomi usati per identificare i record nei file di zona di
-BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
+BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
implementazione di un server DNS, ed, essendo utilizzata nella stragrande
maggioranza dei casi, fa da riferimento; i dati relativi ad un certo
- dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
+ dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
che sono usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo
- di dominio è identificato da un nome che è appunto identico a quello delle
+ di dominio è identificato da un nome che è appunto identico a quello delle
costanti di tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.}
e che normalmente sono anche usati come nomi per indicare i record.
\const{T\_MD} & Destinazione per la posta elettronica.\\
\const{T\_MF} & Redistributore per la posta elettronica.\\
\const{T\_CNAME} & Nome canonico.\\
- \const{T\_SOA} & Inizio di una zona di autorità.\\
+ \const{T\_SOA} & Inizio di una zona di autorità.\\
\const{T\_MB} & Nome a dominio di una casella di posta.\\
\const{T\_MG} & Nome di un membro di un gruppo di posta.\\
\const{T\_MR} & Nome di un cambiamento di nome per la posta.\\
\const{T\_NAPTR} & Puntatore ad una \textit{naming authority}.\\
\const{T\_TSIG} & Firma di transazione.\\
\const{T\_IXFR} & Trasferimento di zona incrementale.\\
- \const{T\_AXFR} & Trasferimento di zona di autorità.\\
+ \const{T\_AXFR} & Trasferimento di zona di autorità.\\
\const{T\_MAILB} & Trasferimento di record di caselle di posta.\\
\const{T\_MAILA} & Trasferimento di record di server di posta.\\
\const{T\_ANY} & Valore generico.\\
\end{table}
-L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
+L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
\textit{resource record} definiti, con una breve descrizione del relativo
-significato. Di tutti questi però viene impiegato correntemente solo un
+significato. Di tutti questi però viene impiegato correntemente solo un
piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati
applicativi che non ci interessano non avendo nulla a che fare con la
risoluzione degli indirizzi IP, pertanto non entreremo nei dettagli del
significato di tutti i \textit{resource record}, ma solo di quelli usati dalle
funzioni del \textit{resolver}. Questi sono sostanzialmente i seguenti (per
-indicarli si è usata la notazione dei file di zona di BIND):
+indicarli si è usata la notazione dei file di zona di BIND):
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{A}] viene usato per indicare la corrispondenza fra un nome a
dominio ed un indirizzo IPv4; ad esempio la corrispondenza fra
\texttt{dodds.truelite.it} e l'indirizzo IP \texttt{62.48.34.25}.
\item[\texttt{AAAA}] viene usato per indicare la corrispondenza fra un nome a
- dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
- dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
+ dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
+ dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
\item[\texttt{PTR}] per fornire la corrispondenza inversa fra un indirizzo IP
ed un nome a dominio ad esso associato si utilizza questo tipo di record (il
cui nome sta per \textit{pointer}).
-\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
+\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
stesso indirizzo (come ad esempio \texttt{www.truelite.it} e
\texttt{sources.truelite.it}, che fanno entrambi riferimento alla stessa
- macchina (nel caso \texttt{dodds.truelite.it}) si può usare questo tipo di
+ macchina (nel caso \texttt{dodds.truelite.it}) si può usare questo tipo di
record per creare degli \textit{alias} in modo da associare un qualunque
- altro nome al \textsl{nome canonico} della macchina (si chiama così quello
+ altro nome al \textsl{nome canonico} della macchina (si chiama così quello
associato al record \texttt{A}).
\end{basedescript}
Come accennato in caso di successo le due funzioni di richiesta restituiscono
il risultato della interrogazione al server, in caso di insuccesso l'errore
invece viene segnalato da un valore di ritorno pari a -1, ma in questo caso,
-non può essere utilizzata la variabile \var{errno} per riportare un codice di
+non può essere utilizzata la variabile \var{errno} per riportare un codice di
errore, in quanto questo viene impostato per ciascuna delle chiamate al
-sistema utilizzate dalle funzioni del \textit{resolver}, non avrà alcun
-significato nell'indicare quale parte del procedimento di risoluzione è
+sistema utilizzate dalle funzioni del \textit{resolver}, non avrà alcun
+significato nell'indicare quale parte del procedimento di risoluzione è
fallita.
-Per questo motivo è stata definita una variabile di errore separata,
+Per questo motivo è stata definita una variabile di errore separata,
\var{h\_errno}, che viene utilizzata dalle funzioni del \textit{resolver} per
indicare quale problema ha causato il fallimento della risoluzione del nome.
-Ad essa si può accedere una volta che la si dichiara con:
+Ad essa si può accedere una volta che la si dichiara con:
\includecodesnip{listati/herrno.c}
-ed i valori che può assumere, con il relativo significato, sono riportati in
+ed i valori che può assumere, con il relativo significato, sono riportati in
tab.~\ref{tab:h_errno_values}.
\begin{table}[!htb]
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \const{HOST\_NOT\_FOUND} & L'indirizzo richiesto non è valido e la
- macchina indicata è sconosciuta.\\
- \const{NO\_ADDRESS} & Il nome a dominio richiesto è valido, ma non ha
+ \const{HOST\_NOT\_FOUND} & L'indirizzo richiesto non è valido e la
+ macchina indicata è sconosciuta.\\
+ \const{NO\_ADDRESS} & Il nome a dominio richiesto è valido, ma non ha
un indirizzo associato ad esso
- (alternativamente può essere indicato come
+ (alternativamente può essere indicato come
\const{NO\_DATA}).\\
- \const{NO\_RECOVERY} & Si è avuto un errore non recuperabile
+ \const{NO\_RECOVERY} & Si è avuto un errore non recuperabile
nell'interrogazione di un server DNS.\\
- \const{TRY\_AGAIN} & Si è avuto un errore temporaneo
- nell'interrogazione di un server DNS, si può
+ \const{TRY\_AGAIN} & Si è avuto un errore temporaneo
+ nell'interrogazione di un server DNS, si può
ritentare l'interrogazione in un secondo
tempo.\\
\hline
Insieme alla nuova variabile vengono definite anche due nuove funzioni per
stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror}
-per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima è
-\funcd{herror} ed il suo prototipo è:
+per \var{errno}, ma che usano il valore di \var{h\_errno}; la prima è
+\funcd{herror} ed il suo prototipo è:
\begin{functions}
\headdecl{netdb.h}
\funcdecl{void herror(const char *string)}
Stampa un errore di risoluzione.
\end{functions}
-La funzione è l'analoga di \func{perror} e stampa sullo standard error un
+La funzione è l'analoga di \func{perror} e stampa sullo standard error un
messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui
viene anteposta la stringa \param{string} passata come argomento. La seconda
-funzione è \funcd{hstrerror} ed il suo prototipo è:
+funzione è \funcd{hstrerror} ed il suo prototipo è:
\begin{functions}
\headdecl{netdb.h}
\funcdecl{const char *hstrerror(int err)}
Restituisce una stringa corrispondente ad un errore di risoluzione.
\end{functions}
\noindent che, come l'analoga \func{strerror}, restituisce una stringa con un
-messaggio di errore già formattato, corrispondente al codice passato come
+messaggio di errore già formattato, corrispondente al codice passato come
argomento (che si presume sia dato da \var{h\_errno}).
\itindend{resolver}
\subsection{La risoluzione dei nomi a dominio}
\label{sec:sock_name_services}
-La principale funzionalità del \itindex{resolver} \textit{resolver} resta
+La principale funzionalità del \itindex{resolver} \textit{resolver} resta
quella di risolvere i nomi a dominio in indirizzi IP, per cui non ci
dedicheremo oltre alle funzioni di richiesta generica ed esamineremo invece le
-funzioni a questo dedicate. La prima funzione è \funcd{gethostbyname} il cui
-scopo è ottenere l'indirizzo di una stazione noto il suo nome a dominio, il
-suo prototipo è:
+funzioni a questo dedicate. La prima funzione è \funcd{gethostbyname} il cui
+scopo è ottenere l'indirizzo di una stazione noto il suo nome a dominio, il
+suo prototipo è:
\begin{prototype}{netdb.h}
{struct hostent *gethostbyname(const char *name)}
La funzione prende come argomento una stringa \param{name} contenente il nome
a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
vengono memorizzati in una opportuna struttura \struct{hostent} la cui
-definizione è riportata in fig.~\ref{fig:sock_hostent_struct}.
+definizione è riportata in fig.~\ref{fig:sock_hostent_struct}.
\begin{figure}[!htb]
\footnotesize \centering
\end{figure}
Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
-effettuare la risoluzione del nome, è con i valori contenuti nei relativi
+effettuare la risoluzione del nome, è con i valori contenuti nei relativi
record che vengono riempite le varie parti della struttura \struct{hostent}.
Il primo campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
- canonico}, che nel caso del DNS è appunto il nome associato ad un record
-\texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
+ canonico}, che nel caso del DNS è appunto il nome associato ad un record
+\texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
puntatore del vettore punta ad una stringa contenente uno degli altri
possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel
DNS vengono inseriti come record di tipo \texttt{CNAME}).
Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
-che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
+che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
\const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
lunghezza dell'indirizzo stesso in byte.
-Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
-ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre,
+Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
+ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre,
come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
-\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
+\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
diretto al primo indirizzo della lista.
Oltre ai normali nomi a dominio la funzione accetta come argomento
\param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation} per IPv6. In
-tal caso \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma
-si limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
+tal caso \func{gethostbyname} non eseguirà nessuna interrogazione remota, ma
+si limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
corrispondente struttura \var{in\_addr} da indirizzare con
\code{h\_addr\_list[0]}.
Con l'uso di \func{gethostbyname} normalmente si ottengono solo gli indirizzi
-IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
+IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
l'opzione \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e poi
chiamare \func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per
modificare le opzioni del \itindex{resolver} \textit{resolver}; dato che
-questo non è molto comodo è stata definita\footnote{questa è una estensione
+questo non è molto comodo è stata definita\footnote{questa è una estensione
fornita dalle \acr{glibc}, disponibile anche in altri sistemi unix-like.}
-un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è:
+un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/socket.h}
In questo caso la funzione prende un secondo argomento \param{af} che indica
(i soli valori consentiti sono \const{AF\_INET} o \const{AF\_INET6}, per
-questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
-che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
-il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
+questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
+che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
+il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
suoi risultati.
\begin{figure}[!htb]
\end{figure}
Vediamo allora un primo esempio dell'uso delle funzioni di risoluzione, in
-fig.~\ref{fig:mygethost_example} è riportato un estratto del codice di un
+fig.~\ref{fig:mygethost_example} è riportato un estratto del codice di un
programma che esegue una semplice interrogazione al
\itindex{resolver} \textit{resolver} usando \func{gethostbyname} e poi ne
stampa a video i risultati. Al solito il sorgente completo, che comprende il
trattamento delle opzioni ed una funzione per stampare un messaggio di aiuto,
-è nel file \texttt{mygethost.c} dei sorgenti allegati alla guida.
+è nel file \texttt{mygethost.c} dei sorgenti allegati alla guida.
Il programma richiede un solo argomento che specifichi il nome da cercare,
senza il quale (\texttt{\small 15--18}) esce con un errore. Dopo di che
controllato per rilevare eventuali errori, nel qual caso il programma esce
dopo aver stampato un messaggio con \func{herror}.
-Se invece la risoluzione è andata a buon fine si inizia (\texttt{\small 25})
+Se invece la risoluzione è andata a buon fine si inizia (\texttt{\small 25})
con lo stampare il nome canonico, dopo di che (\texttt{\small 26--30}) si
stampano eventuali altri nomi. Per questo prima (\texttt{\small 26}) si prende
il puntatore alla cima della lista che contiene i nomi e poi (\texttt{\small
- 27--30}) si esegue un ciclo che sarà ripetuto fin tanto che nella lista si
+ 27--30}) si esegue un ciclo che sarà ripetuto fin tanto che nella lista si
troveranno dei puntatori validi\footnote{si ricordi che la lista viene
terminata da un puntatore nullo.} per le stringhe dei nomi; prima
-(\texttt{\small 28}) si stamperà la stringa e poi (\texttt{\small 29}) si
-provvederà ad incrementare il puntatore per passare al successivo elemento
+(\texttt{\small 28}) si stamperà la stringa e poi (\texttt{\small 29}) si
+provvederà ad incrementare il puntatore per passare al successivo elemento
della lista.
-Una volta stampati i nomi si passerà a stampare gli indirizzi, il primo passo
-(\texttt{\small 31--38}) è allora quello di riconoscere il tipo di indirizzo
-sulla base del valore del campo \var{h\_addrtype}, stampandolo a video. Si è
+Una volta stampati i nomi si passerà a stampare gli indirizzi, il primo passo
+(\texttt{\small 31--38}) è allora quello di riconoscere il tipo di indirizzo
+sulla base del valore del campo \var{h\_addrtype}, stampandolo a video. Si è
anche previsto di stampare un errore nel caso (che non dovrebbe mai accadere)
di un indirizzo non valido.
Infine (\texttt{\small 39--44}) si stamperanno i valori degli indirizzi, di
-nuovo (\texttt{\small 39}) si inizializzerà un puntatore alla cima della lista
-e si eseguirà un ciclo fintanto che questo punterà ad indirizzi validi in
+nuovo (\texttt{\small 39}) si inizializzerà un puntatore alla cima della lista
+e si eseguirà un ciclo fintanto che questo punterà ad indirizzi validi in
maniera analoga a quanto fatto in precedenza per i nomi a dominio. Si noti
come, essendo il campo \var{h\_addr\_list} un puntatore ad strutture di
indirizzi generiche, questo sia ancora di tipo \texttt{char **} e si possa
riutilizzare lo stesso puntatore usato per i nomi.
-Per ciascun indirizzo valido si provvederà (\texttt{\small 41}) ad una
+Per ciascun indirizzo valido si provvederà (\texttt{\small 41}) ad una
conversione con la funzione \func{inet\_ntop} (vedi
sez.~\ref{sec:sock_addr_func}) passandole gli opportuni argomenti, questa
-restituirà la stringa da stampare (\texttt{\small 42}) con il valore
-dell'indirizzo in \var{buffer}, che si è avuto la cura di dichiarare
+restituirà la stringa da stampare (\texttt{\small 42}) con il valore
+dell'indirizzo in \var{buffer}, che si è avuto la cura di dichiarare
inizialmente (\texttt{\small 10}) con dimensioni adeguate; dato che la
-funzione è in grado di tenere conto automaticamente del tipo di indirizzo non
+funzione è in grado di tenere conto automaticamente del tipo di indirizzo non
ci sono precauzioni particolari da prendere.\footnote{volendo essere pignoli
- si dovrebbe controllarne lo stato di uscita, lo si è tralasciato per non
+ si dovrebbe controllarne lo stato di uscita, lo si è tralasciato per non
appesantire il codice, dato che in caso di indirizzi non validi si sarebbe
avuto un errore con \func{gethostbyname}, ma si ricordi che la sicurezza non
- è mai troppa.}
+ è mai troppa.}
Le funzioni illustrate finora hanno un difetto: utilizzando una area di
memoria interna per allocare i contenuti della struttura \struct{hostent} non
possono essere\index{funzioni!rientranti} rientranti. Questo comporta anche
che in due successive chiamate i dati potranno essere sovrascritti. Si tenga
-presente poi che copiare il contenuto della sola struttura non è sufficiente
+presente poi che copiare il contenuto della sola struttura non è sufficiente
per salvare tutti i dati, in quanto questa contiene puntatori ad altri dati,
che pure possono essere sovrascritti; per questo motivo, se si vuole salvare
-il risultato di una chiamata, occorrerà eseguire quella che si chiama una
-\itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così quella tecnica
+il risultato di una chiamata, occorrerà eseguire quella che si chiama una
+\itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così quella tecnica
per cui, quando si deve copiare il contenuto di una struttura complessa (con
puntatori che puntano ad altri dati, che a loro volta possono essere
puntatori ad altri dati) si deve copiare non solo il contenuto della
struttura, ma eseguire una scansione per risolvere anche tutti i puntatori
- contenuti in essa (e così via se vi sono altre sotto-strutture con altri
+ contenuti in essa (e così via se vi sono altre sotto-strutture con altri
puntatori) e copiare anche i dati da questi referenziati.}
Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
Gli argomenti \param{name} (e \param{af} per \func{gethostbyname2\_r}) hanno
lo stesso significato visto in precedenza. Tutti gli altri argomenti hanno lo
stesso significato per entrambe le funzioni. Per evitare l'uso di variabili
-globali si dovrà allocare preventivamente una struttura \struct{hostent} in
+globali si dovrà allocare preventivamente una struttura \struct{hostent} in
cui ricevere il risultato, passandone l'indirizzo alla funzione nell'argomento
-\param{ret}. Inoltre, dato che \struct{hostent} contiene dei puntatori, dovrà
+\param{ret}. Inoltre, dato che \struct{hostent} contiene dei puntatori, dovrà
essere allocato anche un buffer in cui le funzioni possano scrivere tutti i
dati del risultato dell'interrogazione da questi puntati; l'indirizzo e la
lunghezza di questo buffer devono essere indicati con gli argomenti
Gli ultimi due argomenti vengono utilizzati per avere indietro i risultati
come \itindex{value~result~argument} \textit{value result argument}, si deve
-specificare l'indirizzo della variabile su cui la funzione dovrà salvare il
-codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
-puntatore che si userà per accedere i dati con \param{result}.
+specificare l'indirizzo della variabile su cui la funzione dovrà salvare il
+codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
+puntatore che si userà per accedere i dati con \param{result}.
In caso di successo entrambe le funzioni restituiscono un valore nullo,
altrimenti restituiscono un codice di errore negativo e all'indirizzo puntato
-da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
-\param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
-essere \index{funzioni!rientranti} rientrante la funzione non può la variabile
+da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
+\param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
+essere \index{funzioni!rientranti} rientrante la funzione non può la variabile
globale \var{h\_errno}. In questo caso il codice di errore, oltre ai valori di
-tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
+tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
qualora il buffer allocato su \param{buf} non sia sufficiente a contenere i
-dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
+dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
con un buffer di dimensione maggiore.
-Una delle caratteristiche delle interrogazioni al servizio DNS è che queste
+Una delle caratteristiche delle interrogazioni al servizio DNS è che queste
sono normalmente eseguite con il protocollo UDP, ci sono casi in cui si
preferisce che vengano usate connessioni permanenti con il protocollo TCP. Per
ottenere questo\footnote{si potrebbero impostare direttamente le opzioni di
\var{\_\_res.options}, ma queste funzioni permettono di semplificare la
- procedura.} sono previste delle funzioni apposite; la prima è
-\funcd{sethostent}, il cui prototipo è:
+ procedura.} sono previste delle funzioni apposite; la prima è
+\funcd{sethostent}, il cui prototipo è:
\begin{prototype}{netdb.h}
{void sethostent(int stayopen)}
La funzione permette di richiedere l'uso di connessioni TCP per la richiesta
dei dati, e che queste restino aperte per successive richieste. Il valore
-dell'argomento \param{stayopen} indica se attivare questa funzionalità, un
+dell'argomento \param{stayopen} indica se attivare questa funzionalità, un
valore pari a 1 (o diverso da zero), che indica una condizione vera in C,
-attiva la funzionalità. Come si attiva l'uso delle connessioni TCP lo si può
-disattivare con la funzione \funcd{endhostent}; il suo prototipo è:
+attiva la funzionalità. Come si attiva l'uso delle connessioni TCP lo si può
+disattivare con la funzione \funcd{endhostent}; il suo prototipo è:
\begin{prototype}{netdb.h}
{void endhostent(void)}
\bodydesc{La funzione non restituisce nulla.}
\end{prototype}
-\noindent e come si può vedere la funzione è estremamente semplice, non
+\noindent e come si può vedere la funzione è estremamente semplice, non
richiedendo nessun argomento.
-Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
-per ottenerne il nome a dominio ad esso associato, per fare questo si può
-usare la funzione \funcd{gethostbyaddr}, il cui prototipo è:
+Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
+per ottenerne il nome a dominio ad esso associato, per fare questo si può
+usare la funzione \funcd{gethostbyaddr}, il cui prototipo è:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/socket.h}
\struct{hostent} in caso di successo ed \const{NULL} in caso di errore.}
\end{functions}
-In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
+In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
appropriata struttura contenente il valore dell'indirizzo IP (o IPv6) che si
-vuole risolvere. L'uso del tipo \texttt{char *} per questo argomento è
-storico, il dato dovrà essere fornito in una struttura
+vuole risolvere. L'uso del tipo \texttt{char *} per questo argomento è
+storico, il dato dovrà essere fornito in una struttura
\struct{in\_addr}\footnote{si ricordi che, come illustrato in
- fig.~\ref{fig:sock_sa_ipv4_struct}, questo in realtà corrisponde ad un
+ fig.~\ref{fig:sock_sa_ipv4_struct}, questo in realtà corrisponde ad un
numero intero, da esprimere comunque in \textit{network order}, non
- altrettanto avviene però per \struct{in6\_addr}, pertanto è sempre opportuno
+ altrettanto avviene però per \struct{in6\_addr}, pertanto è sempre opportuno
inizializzare questi indirizzi con \func{inet\_pton} (vedi
sez.~\ref{sec:sock_conv_func_gen}).} per un indirizzo IPv4 ed una struttura
-\struct{in6\_addr} per un indirizzo IPv6, mentre in \param{len} se ne dovrà
+\struct{in6\_addr} per un indirizzo IPv6, mentre in \param{len} se ne dovrà
specificare la dimensione (rispettivamente 4 o 16), infine l'argomento
-\param{type} indica il tipo di indirizzo e dovrà essere o \const{AF\_INET} o
+\param{type} indica il tipo di indirizzo e dovrà essere o \const{AF\_INET} o
\const{AF\_INET6}.
La funzione restituisce, in caso di successo, un puntatore ad una struttura
richiedendo al DNS un record di tipo \texttt{PTR} corrispondente all'indirizzo
specificato. In caso di errore al solito viene usata la variabile
\var{h\_errno} per restituire un opportuno codice. In questo caso l'unico
-campo del risultato che interessa è \var{h\_name} che conterrà il nome a
+campo del risultato che interessa è \var{h\_name} che conterrà il nome a
dominio, la funziona comunque inizializza anche il primo campo della lista
\var{h\_addr\_list} col valore dell'indirizzo passato come argomento.
Per risolvere il problema dell'uso da parte delle due funzioni
-\func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
-sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
-indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
+\func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
+sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
+indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
con \func{gethostbyname}), vennero introdotte due nuove funzioni di
risoluzione,\footnote{le funzioni sono presenti nelle \acr{glibc} versione
2.1.96, ma essendo considerate deprecate (vedi
\end{functions}
Entrambe le funzioni supportano esplicitamente la scelta di una famiglia di
-indirizzi con l'argomento \param{af} (che può assumere i valori
+indirizzi con l'argomento \param{af} (che può assumere i valori
\const{AF\_INET} o \const{AF\_INET6}), e restituiscono un codice di errore
(con valori identici a quelli precedentemente illustrati in
tab.~\ref{tab:h_errno_values}) nella variabile puntata da \param{error\_num}.
saranno rimappati in IPv6.\\
\const{AI\_ADDRCONFIG}& Richiede che una richiesta IPv4 o IPv6 venga
eseguita solo se almeno una interfaccia del
- sistema è associata ad un indirizzo di tale tipo.\\
- \const{AI\_DEFAULT} & Il valore di default, è equivalente alla
+ sistema è associata ad un indirizzo di tale tipo.\\
+ \const{AI\_DEFAULT} & Il valore di default, è equivalente alla
combinazione di \const{AI\_ADDRCONFIG} e di
\const{AI\_V4MAPPED}.\\
\hline
insieme a tutto lo spazio necessario a contenere i dati in essa referenziati;
per questo motivo queste funzioni non soffrono dei problemi dovuti all'uso di
una sezione statica di memoria presenti con le precedenti \func{gethostbyname}
-e \func{gethostbyaddr}. L'uso di una allocazione dinamica però comporta anche
-la necessità di disallocare esplicitamente la memoria occupata dai risultati
-una volta che questi non siano più necessari; a tale scopo viene fornita la
-funzione \funcd{freehostent}, il cui prototipo è:
+e \func{gethostbyaddr}. L'uso di una allocazione dinamica però comporta anche
+la necessità di disallocare esplicitamente la memoria occupata dai risultati
+una volta che questi non siano più necessari; a tale scopo viene fornita la
+funzione \funcd{freehostent}, il cui prototipo è:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/types.h}
\itindex{Name~Service~Switch} \textit{Name Service Switch} che permettono
rispettivamente di trovare una corrispondenza cercando per nome o per numero.
-L'elenco di queste funzioni è riportato nelle colonne finali di
+L'elenco di queste funzioni è riportato nelle colonne finali di
tab.~\ref{tab:name_resolution_functions}, dove le si sono suddivise rispetto
al tipo di informazione che forniscono (riportato in prima colonna). Nella
-tabella si è anche riportato il file su cui vengono ordinariamente mantenute
-queste informazioni, che però può essere sostituito da un qualunque supporto
+tabella si è anche riportato il file su cui vengono ordinariamente mantenute
+queste informazioni, che però può essere sostituito da un qualunque supporto
interno al \itindex{Name~Service~Switch} \textit{Name Service Switch} (anche
se usualmente questo avviene solo per la risoluzione degli indirizzi).
Ciascuna funzione fa riferimento ad una sua apposita struttura che contiene i
Delle funzioni di tab.~\ref{tab:name_resolution_functions} abbiamo trattato
finora soltanto quelle relative alla risoluzione dei nomi, dato che sono le
-più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
-una entità esterna; per le altre invece, estensioni fornite dal
+più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
+una entità esterna; per le altre invece, estensioni fornite dal
\itindex{Name~Service~Switch} NSS a parte, si fa sempre riferimento ai dati
mantenuti nei rispettivi file.
-Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
-sui nomi dei servizi di rete più comuni (cioè \texttt{http}, \texttt{smtp},
+Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
+sui nomi dei servizi di rete più comuni (cioè \texttt{http}, \texttt{smtp},
ecc.) da associare alle rispettive porte. Le due funzioni da utilizzare per
questo sono \funcd{getservbyname} e \funcd{getservbyaddr}, che permettono
rispettivamente di ottenere il numero di porta associato ad un servizio dato
ricerca,\footnote{le informazioni mantenute in \conffile{/etc/services}
infatti sono relative sia alle porte usate su UDP che su TCP, occorre quindi
specificare a quale dei due protocolli si fa riferimento.} che nel caso si
-IP può avere come valori possibili solo \texttt{udp} o
+IP può avere come valori possibili solo \texttt{udp} o
\texttt{tcp};\footnote{in teoria si potrebbe avere un qualunque protocollo fra
quelli citati in \conffile{/etc/protocols}, posto che lo stesso supporti il
concetto di \textsl{porta}, in pratica questi due sono gli unici presenti.}
-se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
+se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
qualsiasi.
-Il primo argomento è il nome del servizio per \func{getservbyname},
+Il primo argomento è il nome del servizio per \func{getservbyname},
specificato tramite la stringa \param{name}, mentre \func{getservbyport}
richiede il numero di porta in \param{port}. Entrambe le funzioni eseguono una
ricerca sul file \conffile{/etc/services}\footnote{il
una apposita struttura \struct{servent} contenente tutti i risultati,
altrimenti viene restituito un puntatore nullo. Si tenga presente che anche
in questo caso i dati vengono mantenuti in una area di memoria statica e che
-quindi la funzione non è \index{funzioni!rientranti} rientrante.
+quindi la funzione non è \index{funzioni!rientranti} rientrante.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sock_servent_struct}
\end{figure}
-La definizione della struttura \struct{servent} è riportata in
+La definizione della struttura \struct{servent} è riportata in
fig.~\ref{fig:sock_servent_struct}, il primo campo, \var{s\_name} contiene
-sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
+sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
ad un vettore di stringhe contenenti gli eventuali nomi alternativi
utilizzabili per identificare lo stesso servizio. Infine \var{s\_port}
contiene il numero di porta e \var{s\_proto} il nome del protocollo.
Come riportato in tab.~\ref{tab:name_resolution_functions} ci sono analoghe
funzioni per la risoluzione del nome dei protocolli e delle reti; non staremo
-a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
+a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
comunque utilizzano una loro struttura dedicata del tutto analoga alle
precedenti: tutti i dettagli relativi al loro funzionamento possono essere
trovati nelle rispettive pagine di manuale.
\end{functions}
La prima funzione, \func{getservent}, legge una singola voce a partire dalla
-posizione corrente in \conffile{/etc/services}, pertanto si può eseguire una
-lettura sequenziale dello stesso invocandola più volte. Se il file non è
-aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
+posizione corrente in \conffile{/etc/services}, pertanto si può eseguire una
+lettura sequenziale dello stesso invocandola più volte. Se il file non è
+aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
voce. La seconda funzione, \func{setservent}, permette di aprire il file
-\conffile{/etc/services} per una successiva lettura, ma se il file è già stato
+\conffile{/etc/services} per una successiva lettura, ma se il file è già stato
aperto riporta la posizione di lettura alla prima voce del file, in questo
-modo si può far ricominciare da capo una lettura sequenziale. L'argomento
-\param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
+modo si può far ricominciare da capo una lettura sequenziale. L'argomento
+\param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
diverse chiamate a \func{getservbyname} e \func{getservbyaddr}.\footnote{di
- default dopo una chiamata a queste funzioni il file viene chiuso, cosicché
+ default dopo una chiamata a queste funzioni il file viene chiuso, cosicché
una successiva chiamata a \func{getservent} riparte dall'inizio.} La terza
funzione, \funcd{endservent}, provvede semplicemente a chiudere il file.
\label{sec:sock_advanced_name_services}
Quelle illustrate nella sezione precedente sono le funzioni classiche per la
-risoluzione di nomi ed indirizzi IP, ma abbiamo già visto come esse soffrano
+risoluzione di nomi ed indirizzi IP, ma abbiamo già visto come esse soffrano
di vari inconvenienti come il fatto che usano informazioni statiche, e non
-prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
+prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
state create delle estensioni o metodi diversi che permettono di risolvere
alcuni di questi inconvenienti,\footnote{rimane ad esempio il problema
generico che si deve sapere in anticipo quale tipo di indirizzi IP (IPv4 o
quello del servizio a cui ci si vuole rivolgere. Per questo motivo con lo
standard POSIX 1003.1-2001 sono state indicate come deprecate le varie
funzioni \func{gethostbyaddr}, \func{gethostbyname}, \var{getipnodebyname} e
-\var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
+\var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
nuova.
-La prima funzione di questa interfaccia è \funcd{getaddrinfo},\footnote{la
- funzione è definita, insieme a \func{getnameinfo} che vedremo più avanti,
+La prima funzione di questa interfaccia è \funcd{getaddrinfo},\footnote{la
+ funzione è definita, insieme a \func{getnameinfo} che vedremo più avanti,
nell'\href{http://www.ietf.org/rfc/rfc2553.txt}{RFC~2553}.} che combina le
-funzionalità delle precedenti \func{getipnodebyname}, \func{getipnodebyaddr},
+funzionalità delle precedenti \func{getipnodebyname}, \func{getipnodebyaddr},
\func{getservbyname} e \func{getservbyport}, consentendo di ottenere
contemporaneamente sia la risoluzione di un indirizzo simbolico che del nome
-di un servizio; il suo prototipo è:
+di un servizio; il suo prototipo è:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/socket.h}
La funzione prende come primo argomento il nome della macchina che si vuole
risolvere, specificato tramite la stringa \param{node}. Questo argomento,
-oltre ad un comune nome a dominio, può indicare anche un indirizzo numerico in
+oltre ad un comune nome a dominio, può indicare anche un indirizzo numerico in
forma \textit{dotted-decimal} per IPv4 o in formato esadecimale per IPv6. Si
-può anche specificare il nome di una rete invece che di una singola macchina.
+può anche specificare il nome di una rete invece che di una singola macchina.
Il secondo argomento, \param{service}, specifica invece il nome del servizio
-che si intende risolvere. Per uno dei due argomenti si può anche usare il
-valore \const{NULL}, nel qual caso la risoluzione verrà effettuata soltanto
+che si intende risolvere. Per uno dei due argomenti si può anche usare il
+valore \const{NULL}, nel qual caso la risoluzione verrà effettuata soltanto
sulla base del valore dell'altro.
Il terzo argomento, \param{hints}, deve essere invece un puntatore ad una
struttura \struct{addrinfo} usata per dare dei \textsl{suggerimenti} al
procedimento di risoluzione riguardo al protocollo o del tipo di socket che si
-intenderà utilizzare; \func{getaddrinfo} infatti permette di effettuare
+intenderà utilizzare; \func{getaddrinfo} infatti permette di effettuare
ricerche generiche sugli indirizzi, usando sia IPv4 che IPv6, e richiedere
risoluzioni sui nomi dei servizi indipendentemente dal protocollo (ad esempio
TCP o UDP) che questi possono utilizzare.
Come ultimo argomento in \param{res} deve essere passato un puntatore ad una
-variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
+variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
utilizzata dalla funzione per riportare (come \itindex{value~result~argument}
-\textit{value result argument}) i propri risultati. La funzione infatti è
+\textit{value result argument}) i propri risultati. La funzione infatti è
\index{funzioni!rientranti} rientrante, ed alloca autonomamente tutta la
memoria necessaria in cui verranno riportati i risultati della risoluzione.
-La funzione scriverà all'indirizzo puntato da \param{res} il puntatore
+La funzione scriverà all'indirizzo puntato da \param{res} il puntatore
iniziale ad una \itindex{linked~list} \textit{linked list} di strutture di
tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
\end{figure}
Come illustrato la struttura \struct{addrinfo}, la cui definizione\footnote{la
- definizione è ripresa direttamente dal file \texttt{netdb.h} in questa
+ definizione è ripresa direttamente dal file \texttt{netdb.h} in questa
struttura viene dichiarata, la pagina di manuale riporta \type{size\_t} come
tipo di dato per il campo \var{ai\_addrlen}, qui viene usata quanto previsto
dallo standard POSIX, in cui viene utilizzato \type{socklen\_t}; i due tipi
- di dati sono comunque equivalenti.} è riportata in
+ di dati sono comunque equivalenti.} è riportata in
fig.~\ref{fig:sock_addrinfo_struct}, viene usata sia in ingresso, per passare
dei valori di controllo alla funzione, che in uscita, per ricevere i
-risultati. Il primo campo, \var{ai\_flags}, è una maschera binaria di bit che
-permettono di controllare le varie modalità di risoluzione degli indirizzi,
+risultati. Il primo campo, \var{ai\_flags}, è una maschera binaria di bit che
+permettono di controllare le varie modalità di risoluzione degli indirizzi,
che viene usato soltanto in ingresso. I tre campi successivi \var{ai\_family},
\var{ai\_socktype}, e \var{ai\_protocol} contengono rispettivamente la
famiglia di indirizzi, il tipo di socket e il protocollo, in ingresso vengono
Tutti i campi seguenti vengono usati soltanto in uscita; il campo
\var{ai\_addrlen} indica la dimensione della struttura degli indirizzi
-ottenuta come risultato, il cui contenuto sarà memorizzato nella struttura
+ottenuta come risultato, il cui contenuto sarà memorizzato nella struttura
\struct{sockaddr} posta all'indirizzo puntato dal campo \var{ai\_addr}. Il
-campo \var{ai\_canonname} è un puntatore alla stringa contenente il nome
-canonico della macchina, ed infine, quando la funzione restituisce più di un
-risultato, \var{ai\_next} è un puntatore alla successiva struttura
+campo \var{ai\_canonname} è un puntatore alla stringa contenente il nome
+canonico della macchina, ed infine, quando la funzione restituisce più di un
+risultato, \var{ai\_next} è un puntatore alla successiva struttura
\struct{addrinfo} della lista.
-Ovviamente non è necessario dare dei suggerimenti in ingresso, ed usando
+Ovviamente non è necessario dare dei suggerimenti in ingresso, ed usando
\const{NULL} come valore per l'argomento \param{hints} si possono compiere
-ricerche generiche. Se però si specifica un valore non nullo questo deve
+ricerche generiche. Se però si specifica un valore non nullo questo deve
puntare ad una struttura \struct{addrinfo} precedentemente allocata nella
quale siano stati opportunamente impostati i valori dei campi
\var{ai\_family}, \var{ai\_socktype}, \var{ai\_protocol} ed \var{ai\_flags}.
degli analoghi argomenti della funzione \func{socket}; in particolare per
\var{ai\_family} si possono usare i valori di tab.~\ref{tab:net_pf_names} ma
sono presi in considerazione solo \const{PF\_INET} e \const{PF\_INET6}, mentre
-se non si vuole specificare nessuna famiglia di indirizzi si può usare il
+se non si vuole specificare nessuna famiglia di indirizzi si può usare il
valore \const{PF\_UNSPEC}. Allo stesso modo per \var{ai\_socktype} si possono
usare i valori illustrati in sez.~\ref{sec:sock_type} per indicare per quale
tipo di socket si vuole risolvere il servizio indicato, anche se i soli
significativi sono \const{SOCK\_STREAM} e \const{SOCK\_DGRAM}; in questo caso,
-se non si vuole effettuare nessuna risoluzione specifica, si potrà usare un
+se non si vuole effettuare nessuna risoluzione specifica, si potrà usare un
valore nullo.
Il campo \var{ai\_protocol} permette invece di effettuare la selezione dei
\hline
\const{AI\_PASSIVE} & Viene utilizzato per ottenere un indirizzo in
formato adatto per una successiva chiamata a
- \func{bind}. Se specificato quando si è usato
+ \func{bind}. Se specificato quando si è usato
\const{NULL} come valore per \param{node} gli
indirizzi restituiti saranno inizializzati al
valore generico (\const{INADDR\_ANY} per IPv4 e
\const{IN6ADDR\_ANY\_INIT} per IPv6), altrimenti
- verrà usato l'indirizzo dell'interfaccia di
- \textit{loopback}. Se invece non è impostato gli
+ verrà usato l'indirizzo dell'interfaccia di
+ \textit{loopback}. Se invece non è impostato gli
indirizzi verranno restituiti in formato adatto ad
una chiamata a \func{connect} o \func{sendto}.\\
\const{AI\_CANONNAME} & Richiede la restituzione del nome canonico della
- macchina, che verrà salvato in una stringa il cui
- indirizzo sarà restituito nel campo
+ macchina, che verrà salvato in una stringa il cui
+ indirizzo sarà restituito nel campo
\var{ai\_canonname} della prima struttura
\struct{addrinfo} dei risultati. Se il nome
- canonico non è disponibile al suo posto
+ canonico non è disponibile al suo posto
viene restituita una copia di \param{node}. \\
\const{AI\_NUMERICHOST}& Se impostato il nome della macchina specificato
con \param{node} deve essere espresso in forma
- numerica, altrimenti sarà restituito un errore
+ numerica, altrimenti sarà restituito un errore
\const{EAI\_NONAME} (vedi
tab.~\ref{tab:addrinfo_error_code}), in questo
modo si evita ogni chiamata alle funzioni di
\end{table}
-Infine l'ultimo campo è \var{ai\_flags}; che deve essere impostato come una
+Infine l'ultimo campo è \var{ai\_flags}; che deve essere impostato come una
maschera binaria; i bit di questa variabile infatti vengono usati per dare
delle indicazioni sul tipo di risoluzione voluta, ed hanno valori analoghi a
quelli visti in sez.~\ref{sec:sock_name_services} per \func{getipnodebyname};
-il valore di \var{ai\_flags} può essere impostata con un OR aritmetico delle
+il valore di \var{ai\_flags} può essere impostata con un OR aritmetico delle
costanti di tab.~\ref{tab:ai_flags_values}, ciascuna delle quali identifica un
bit della maschera.
caso di errore. I valori usati come codice di errore sono riportati in
tab.~\ref{tab:addrinfo_error_code}; dato che la funzione utilizza altre
funzioni e chiamate al sistema per ottenere il suo risultato in generale il
-valore di \var{errno} non è significativo, eccetto il caso in cui si sia
+valore di \var{errno} non è significativo, eccetto il caso in cui si sia
ricevuto un errore di \const{EAI\_SYSTEM}, nel qual caso l'errore
-corrispondente è riportato tramite \var{errno}.
+corrispondente è riportato tramite \var{errno}.
\begin{table}[!htb]
\centering
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \const{EAI\_FAMILY} & La famiglia di indirizzi richiesta non è
+ \const{EAI\_FAMILY} & La famiglia di indirizzi richiesta non è
supportata. \\
- \const{EAI\_SOCKTYPE}& Il tipo di socket richiesto non è supportato. \\
+ \const{EAI\_SOCKTYPE}& Il tipo di socket richiesto non è supportato. \\
\const{EAI\_BADFLAGS}& Il campo \var{ai\_flags} contiene dei valori non
validi. \\
\const{EAI\_NONAME} & Il nome a dominio o il servizio non sono noti,
viene usato questo errore anche quando si specifica
il valore \const{NULL} per entrambi gli argomenti
\param{node} e \param{service}. \\
- \const{EAI\_SERVICE} & Il servizio richiesto non è disponibile per il tipo
- di socket richiesto, anche se può esistere per
+ \const{EAI\_SERVICE} & Il servizio richiesto non è disponibile per il tipo
+ di socket richiesto, anche se può esistere per
altri tipi di socket. \\
\const{EAI\_ADDRFAMILY}& La rete richiesta non ha nessun indirizzo di rete
per la famiglia di indirizzi specificata. \\
\const{EAI\_NODATA} & La macchina specificata esiste, ma non ha nessun
indirizzo di rete definito. \\
- \const{EAI\_MEMORY} & È stato impossibile allocare la memoria necessaria
+ \const{EAI\_MEMORY} & È stato impossibile allocare la memoria necessaria
alle operazioni. \\
\const{EAI\_FAIL} & Il DNS ha restituito un errore di risoluzione
permanente. \\
\const{EAI\_AGAIN} & Il DNS ha restituito un errore di risoluzione
- temporaneo, si può ritentare in seguito. \\
- \const{EAI\_SYSTEM} & C'è stato un errore di sistema, si può controllare
+ temporaneo, si può ritentare in seguito. \\
+ \const{EAI\_SYSTEM} & C'è stato un errore di sistema, si può controllare
\var{errno} per i dettagli. \\
% \hline
% TODO estensioni GNU, trovarne la documentazione
% \const{EAI\_INPROGRESS}& Richiesta in corso. \\
-% \const{EAI\_CANCELED}& La richiesta è stata cancellata.\\
-% \const{EAI\_NOTCANCELED}& La richiesta non è stata cancellata. \\
+% \const{EAI\_CANCELED}& La richiesta è stata cancellata.\\
+% \const{EAI\_NOTCANCELED}& La richiesta non è stata cancellata. \\
% \const{EAI\_ALLDONE} & Tutte le richieste sono complete. \\
% \const{EAI\_INTR} & Richiesta interrotta. \\
\hline
\label{tab:addrinfo_error_code}
\end{table}
-Come per i codici di errore di \func{gethostbyname} anche in questo caso è
+Come per i codici di errore di \func{gethostbyname} anche in questo caso è
fornita una apposita funzione, analoga di \func{strerror}, che consente di
utilizzarli direttamente per stampare a video un messaggio esplicativo; la
-funzione è \func{gai\_strerror} ed il suo prototipo è:
+funzione è \func{gai\_strerror} ed il suo prototipo è:
\begin{functions}
\headdecl{netdb.h}
La funzione restituisce un puntatore alla stringa contenente il messaggio
corrispondente dal codice di errore \param{errcode} ottenuto come valore di
-ritorno di \func{getaddrinfo}. La stringa è allocata staticamente, ma essendo
+ritorno di \func{getaddrinfo}. La stringa è allocata staticamente, ma essendo
costante, ed accessibile in sola lettura, questo non comporta nessun problema
di rientranza della funzione.
-Dato che ad un certo nome a dominio possono corrispondere più indirizzi IP
-(sia IPv4 che IPv6), e che un certo servizio può essere fornito su protocolli
+Dato che ad un certo nome a dominio possono corrispondere più indirizzi IP
+(sia IPv4 che IPv6), e che un certo servizio può essere fornito su protocolli
e tipi di socket diversi, in generale, a meno di non aver eseguito una
-selezione specifica attraverso l'uso di \param{hints}, si otterrà una diversa
-struttura \struct{addrinfo} per ciascuna possibilità. Ad esempio se si
+selezione specifica attraverso l'uso di \param{hints}, si otterrà una diversa
+struttura \struct{addrinfo} per ciascuna possibilità. Ad esempio se si
richiede la risoluzione del servizio \textit{echo} per l'indirizzo
\texttt{www.truelite.it}, e si imposta \const{AI\_CANONNAME} per avere anche
-la risoluzione del nome canonico, si avrà come risposta della funzione la
+la risoluzione del nome canonico, si avrà come risposta della funzione la
lista illustrata in fig.~\ref{fig:sock_addrinfo_list}.
\begin{figure}[!htb]
Come primo esempio di uso di \func{getaddrinfo} vediamo un programma
elementare di interrogazione del \itindex{resolver} \textit{resolver} basato
-questa funzione, il cui corpo principale è riportato in
+questa funzione, il cui corpo principale è riportato in
fig.~\ref{fig:mygetaddr_example}. Il codice completo del programma, compresa
-la gestione delle opzioni in cui è gestita l'eventuale inizializzazione
+la gestione delle opzioni in cui è gestita l'eventuale inizializzazione
dell'argomento \var{hints} per restringere le ricerche su protocolli, tipi di
-socket o famiglie di indirizzi, è disponibile nel file \texttt{mygetaddr.c}
+socket o famiglie di indirizzi, è disponibile nel file \texttt{mygetaddr.c}
dei sorgenti allegati alla guida.
\begin{figure}[!htb]
senza il quale si esce immediatamente stampando il relativo codice di errore.
Se la funzione ha restituito un valore nullo il programma prosegue
-inizializzando (\texttt{\small 12}) il puntatore \var{ptr} che sarà usato nel
+inizializzando (\texttt{\small 12}) il puntatore \var{ptr} che sarà usato nel
successivo ciclo (\texttt{\small 14--35}) di scansione della lista delle
strutture \struct{addrinfo} restituite dalla funzione. Prima di eseguire
questa scansione (\texttt{\small 12}) viene stampato il valore del nome
-canonico che è presente solo nella prima struttura.
+canonico che è presente solo nella prima struttura.
La scansione viene ripetuta (\texttt{\small 14}) fintanto che si ha un
-puntatore valido. La selezione principale è fatta sul campo \var{ai\_family},
+puntatore valido. La selezione principale è fatta sul campo \var{ai\_family},
che stabilisce a quale famiglia di indirizzi fa riferimento la struttura in
-esame. Le possibilità sono due, un indirizzo IPv4 o IPv6, se nessuna delle due
+esame. Le possibilità sono due, un indirizzo IPv4 o IPv6, se nessuna delle due
si verifica si provvede (\texttt{\small 27--30}) a stampare un messaggio di
-errore ed uscire.\footnote{questa eventualità non dovrebbe mai verificarsi,
+errore ed uscire.\footnote{questa eventualità non dovrebbe mai verificarsi,
almeno fintanto che la funzione \func{getaddrinfo} lavora correttamente.}
Per ciascuno delle due possibili famiglie di indirizzi si estraggono le
informazioni che poi verranno stampate alla fine del ciclo (\texttt{\small
- 31--34}). Il primo caso esaminato (\texttt{\small 15--21}) è quello degli
+ 31--34}). Il primo caso esaminato (\texttt{\small 15--21}) è quello degli
indirizzi IPv4, nel qual caso prima se ne stampa l'identificazione
(\texttt{\small 16}) poi si provvede a ricavare la struttura degli indirizzi
(\texttt{\small 17}) indirizzata dal campo \var{ai\_addr}, eseguendo un
opportuno casting del puntatore per poter estrarre da questa la porta
-(\texttt{\small 18}) e poi l'indirizzo (\texttt{\small 19}) che verrà
+(\texttt{\small 18}) e poi l'indirizzo (\texttt{\small 19}) che verrà
convertito con una chiamata ad \func{inet\_ntop}.
La stessa operazione (\texttt{\small 21--27}) viene ripetuta per gli indirizzi
IPv6, usando la rispettiva struttura degli indirizzi. Si noti anche come in
entrambi i casi per la chiamata a \func{inet\_ntop} si sia dovuto passare il
puntatore al campo contenente l'indirizzo IP nella struttura puntata dal campo
-\var{ai\_addr}.\footnote{il meccanismo è complesso a causa del fatto che al
- contrario di IPv4, in cui l'indirizzo IP può essere espresso con un semplice
+\var{ai\_addr}.\footnote{il meccanismo è complesso a causa del fatto che al
+ contrario di IPv4, in cui l'indirizzo IP può essere espresso con un semplice
numero intero, in IPv6 questo deve essere necessariamente fornito come
struttura, e pertanto anche se nella struttura puntata da \var{ai\_addr}
sono presenti direttamente i valori finali, per l'uso con \func{inet\_ntop}
occorre comunque passare un puntatore agli stessi (ed il costrutto
- \code{\&addr6->sin6\_addr} è corretto in quanto l'operatore \texttt{->} ha
+ \code{\&addr6->sin6\_addr} è corretto in quanto l'operatore \texttt{->} ha
on questo caso precedenza su \texttt{\&}).}
Una volta estratte dalla struttura \struct{addrinfo} tutte le informazioni
relative alla risoluzione richiesta e stampati i relativi valori, l'ultimo
-passo (\texttt{\small 34}) è di estrarre da \var{ai\_next} l'indirizzo della
+passo (\texttt{\small 34}) è di estrarre da \var{ai\_next} l'indirizzo della
eventuale successiva struttura presente nella lista e ripetere il ciclo, fin
-tanto che, completata la scansione, questo avrà un valore nullo e si potrà
+tanto che, completata la scansione, questo avrà un valore nullo e si potrà
terminare (\texttt{\small 36}) il programma.
Si tenga presente che \func{getaddrinfo} non garantisce nessun particolare
ordinamento della lista delle strutture \struct{addrinfo} restituite, anche se
-usualmente i vari indirizzi IP (se ne è presente più di uno) sono forniti
+usualmente i vari indirizzi IP (se ne è presente più di uno) sono forniti
nello stesso ordine in cui vengono inviati dal server DNS. In particolare
nulla garantisce che vengano forniti prima i dati relativi ai servizi di un
determinato protocollo o tipo di socket, se ne sono presenti di diversi. Se
%$
Una volta estratti i risultati dalla \itindex{linked~list} \textit{linked list}
-puntata da \param{res} se questa non viene più utilizzata si dovrà avere cura
+puntata da \param{res} se questa non viene più utilizzata si dovrà avere cura
di disallocare opportunamente tutta la memoria, per questo viene fornita
-l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
+l'apposita funzione \funcd{freeaddrinfo}, il cui prototipo è:
\begin{functions}
\headdecl{netdb.h}
\struct{addrinfo} restituite nella lista indicizzata da \param{res}, occorre
avere cura di eseguire una \itindex{deep~copy} \textit{deep copy} in cui
si copiano anche tutti i dati presenti agli indirizzi contenuti nella
-struttura \struct{addrinfo}, perché una volta disallocati i dati con
-\func{freeaddrinfo} questi non sarebbero più disponibili.
+struttura \struct{addrinfo}, perché una volta disallocati i dati con
+\func{freeaddrinfo} questi non sarebbero più disponibili.
Anche la nuova interfaccia definita da POSIX prevede una nuova funzione per
eseguire la risoluzione inversa e determinare nomi di servizi e di dominio
dati i rispettivi valori numerici. La funzione che sostituisce le varie
-\func{gethostbyname}, \func{getipnodebyname} e \func{getservname} è
-\funcd{getnameinfo}, ed il suo prototipo è:
+\func{gethostbyname}, \func{getipnodebyname} e \func{getservname} è
+\funcd{getnameinfo}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/socket.h}
\headdecl{netdb.h}
errore diverso da zero altrimenti.}
\end{functions}
-La principale caratteristica di \func{getnameinfo} è che la funzione è in
+La principale caratteristica di \func{getnameinfo} è che la funzione è in
grado di eseguire una risoluzione inversa in maniera indipendente dal
-protocollo; il suo primo argomento \param{sa} infatti è il puntatore ad una
-struttura degli indirizzi generica, che può contenere sia indirizzi IPv4 che
+protocollo; il suo primo argomento \param{sa} infatti è il puntatore ad una
+struttura degli indirizzi generica, che può contenere sia indirizzi IPv4 che
IPv6, la cui dimensione deve comunque essere specificata con l'argomento
\param{salen}.
I risultati della funzione saranno restituiti nelle due stringhe puntate da
\param{host} e \param{serv}, che dovranno essere state precedentemente
allocate per una lunghezza massima che deve essere specificata con gli altri
-due argomenti \param{hostlen} e \param{servlen}. Si può, quando non si è
+due argomenti \param{hostlen} e \param{servlen}. Si può, quando non si è
interessati ad uno dei due, passare il valore \const{NULL} come argomento,
-così che la corrispondente informazione non verrà richiesta. Infine l'ultimo
-argomento \param{flags} è una maschera binaria i cui bit consentono di
-impostare le modalità con cui viene eseguita la ricerca, e deve essere
+così che la corrispondente informazione non verrà richiesta. Infine l'ultimo
+argomento \param{flags} è una maschera binaria i cui bit consentono di
+impostare le modalità con cui viene eseguita la ricerca, e deve essere
specificato attraverso l'OR aritmetico dei valori illustrati in
tab.~\ref{tab:getnameinfo_flags}.
nome completo (FQDN).\\
\const{NI\_NUMERICHOST}& Richiede che venga restituita la forma numerica
dell'indirizzo (questo succede sempre se il nome
- non può essere ottenuto).\\
+ non può essere ottenuto).\\
\const{NI\_NAMEREQD} & Richiede la restituzione di un errore se il nome
- non può essere risolto.\\
+ non può essere risolto.\\
\const{NI\_NUMERICSERV}& Richiede che il servizio venga restituito in
forma numerica (attraverso il numero di porta).\\
\const{NI\_DGRAM} & Richiede che venga restituito il nome del
A questo punto possiamo fornire degli esempi di utilizzo della nuova
interfaccia, adottandola per le precedenti implementazioni del client e del
server per il servizio \textit{echo}; dato che l'uso delle funzioni appena
-illustrate (in particolare di \func{getaddrinfo}) è piuttosto complesso,
+illustrate (in particolare di \func{getaddrinfo}) è piuttosto complesso,
essendo necessaria anche una impostazione diretta dei campi dell'argomento
\param{hints}, provvederemo una interfaccia semplificata per i due casi visti
finora, quello in cui si specifica nel client un indirizzo remoto per la
connessione al server, e quello in cui si specifica nel server un indirizzo
locale su cui porsi in ascolto.
-La prima funzione della nostra interfaccia semplificata è \func{sockconn} che
+La prima funzione della nostra interfaccia semplificata è \func{sockconn} che
permette di ottenere un socket, connesso all'indirizzo ed al servizio
-specificati. Il corpo della funzione è riportato in
-fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
-dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
+specificati. Il corpo della funzione è riportato in
+fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
+dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
l'uso dei socket.
\begin{figure}[!htb]
La funzione prende quattro argomenti, i primi due sono le stringhe che
indicano il nome della macchina a cui collegarsi ed il relativo servizio su
-cui sarà effettuata la risoluzione; seguono il protocollo da usare (da
+cui sarà effettuata la risoluzione; seguono il protocollo da usare (da
specificare con il valore numerico di \conffile{/etc/protocols}) ed il tipo di
socket (al solito specificato con i valori illustrati in
sez.~\ref{sec:sock_type}). La funzione ritorna il valore del file descriptor
associato al socket (un numero positivo) in caso di successo, o -1 in caso di
errore; per risolvere il problema di non poter passare indietro i valori di
ritorno di \func{getaddrinfo} contenenti i relativi codici di
-errore\footnote{non si può avere nessuna certezza che detti valori siano
- negativi, è questo è invece necessario per evitare ogni possibile ambiguità
+errore\footnote{non si può avere nessuna certezza che detti valori siano
+ negativi, è questo è invece necessario per evitare ogni possibile ambiguità
nei confronti del valore di ritorno in caso di successo.} si sono stampati i
messaggi d'errore direttamente nella funzione.
chiamata (\texttt{\small 10}) a \func{getaddrinfo}. Di quest'ultima si
controlla (\texttt{\small 12-16}) il codice di ritorno, in modo da stampare un
avviso di errore, azzerare \var{errno} ed uscire in caso di errore. Dato che
-ad una macchina possono corrispondere più indirizzi IP, e di tipo diverso (sia
-IPv4 che IPv6), mentre il servizio può essere in ascolto soltanto su uno solo
+ad una macchina possono corrispondere più indirizzi IP, e di tipo diverso (sia
+IPv4 che IPv6), mentre il servizio può essere in ascolto soltanto su uno solo
di questi, si provvede a tentare la connessione per ciascun indirizzo
restituito all'interno di un ciclo (\texttt{\small 18-40}) di scansione della
lista restituita da \func{getaddrinfo}, ma prima (\texttt{\small 17}) si salva
creazione del socket ha avuto successo si procede (\texttt{\small 29})
direttamente con la connessione, di nuovo in caso di fallimento viene ripetuto
(\texttt{\small 30--38}) il controllo se vi sono o no altri indirizzi da
-provare nella stessa modalità fatta in precedenza, aggiungendovi però in
+provare nella stessa modalità fatta in precedenza, aggiungendovi però in
entrambi i casi (\texttt{\small 32} e (\texttt{\small 36}) la chiusura del
-socket precedentemente aperto, che non è più utilizzabile.
+socket precedentemente aperto, che non è più utilizzabile.
Se la connessione ha avuto successo invece si termina (\texttt{\small 39})
direttamente il ciclo, e prima di ritornare (\texttt{\small 31}) il valore del
programma client per il servizio \textit{echo}; in questo caso rispetto al
codice usato finora per collegarsi (vedi fig.~\ref{fig:TCP_echo_client_1})
avremo una semplificazione per cui il corpo principale del nostro client
-diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
+diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
chiamate a \func{socket}, \func{inet\_pton} e \func{connect} sono sostituite
da una singola chiamata a \func{sockconn}. Inoltre il nuovo client (il cui
-codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
+codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
consente di utilizzare come argomento del programma un nome a dominio al posto
-dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
+dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:sockbind_code}
\end{figure}
-La seconda funzione di ausilio è \func{sockbind}, il cui corpo principale è
-riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
-nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
-notare la funzione è del tutto analoga alla precedente \func{sockconn}, e
-prende gli stessi argomenti, però invece di eseguire una connessione con
+La seconda funzione di ausilio è \func{sockbind}, il cui corpo principale è
+riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
+nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
+notare la funzione è del tutto analoga alla precedente \func{sockconn}, e
+prende gli stessi argomenti, però invece di eseguire una connessione con
\func{connect} si limita a chiamare \func{bind} per collegare il socket ad una
porta.
-Dato che la funzione è pensata per essere utilizzata da un server ci si può
+Dato che la funzione è pensata per essere utilizzata da un server ci si può
chiedere a quale scopo mantenere l'argomento \param{host} quando l'indirizzo
-di questo è usualmente noto. Si ricordi però quanto detto in
+di questo è usualmente noto. Si ricordi però quanto detto in
sez.~\ref{sec:TCP_func_bind}, relativamente al significato della scelta di un
indirizzo specifico come argomento di \func{bind}, che consente di porre il
server in ascolto su uno solo dei possibili diversi indirizzi presenti su di
una macchina. Se non si vuole che la funzione esegua \func{bind} su un
-indirizzo specifico, ma utilizzi l'indirizzo generico, occorrerà avere cura di
+indirizzo specifico, ma utilizzi l'indirizzo generico, occorrerà avere cura di
passare un valore \const{NULL} come valore per l'argomento \var{host}; l'uso
del valore \const{AI\_PASSIVE} serve ad ottenere il valore generico nella
rispettiva struttura degli indirizzi.
-Come già detto la funzione è analoga a \func{sockconn} ed inizia azzerando ed
+Come già detto la funzione è analoga a \func{sockconn} ed inizia azzerando ed
inizializzando (\texttt{\small 6-11}) opportunamente la struttura \var{hint}
-con i valori ricevuti come argomenti, soltanto che in questo caso si è usata
+con i valori ricevuti come argomenti, soltanto che in questo caso si è usata
(\texttt{\small 8}) una impostazione specifica dei flag di \var{hint} usando
-\const{AI\_PASSIVE} per indicare che il socket sarà usato per una apertura
+\const{AI\_PASSIVE} per indicare che il socket sarà usato per una apertura
passiva. Per il resto la chiamata (\texttt{\small 12-18}) a \func{getaddrinfo}
-e ed il ciclo principale (\texttt{\small 20--42}) sono identici, solo che si è
+e ed il ciclo principale (\texttt{\small 20--42}) sono identici, solo che si è
sostituita (\texttt{\small 31}) la chiamata a \func{connect} con una chiamata
-a \func{bind}. Anche la conclusione (\texttt{\small 43--44}) della funzione è
+a \func{bind}. Anche la conclusione (\texttt{\small 43--44}) della funzione è
identica.
Si noti come anche in questo caso si siano inserite le stampe degli errori
sullo standard error, nonostante la funzione possa essere invocata da un
-demone. Nel nostro caso questo non è un problema in quanto se la funzione non
+demone. Nel nostro caso questo non è un problema in quanto se la funzione non
ha successo il programma deve uscire immediatamente prima di essere posto in
-background, e può quindi scrivere gli errori direttamente sullo standard
+background, e può quindi scrivere gli errori direttamente sullo standard
error.
\begin{figure}[!htb]
\label{fig:TCP_echod_third}
\end{figure}
-Con l'uso di questa funzione si può modificare anche il codice del nostro
+Con l'uso di questa funzione si può modificare anche il codice del nostro
server \textit{echo}, che rispetto a quanto illustrato nella versione iniziale
di fig.~\ref{fig:TCP_echo_server_first_code} viene modificato nella forma
riportata in fig.~\ref{fig:TCP_echod_third}. In questo caso il socket su cui
\section{Le opzioni dei socket}
\label{sec:sock_options}
-Benché dal punto di vista del loro uso come canali di trasmissione di dati i
+Benché dal punto di vista del loro uso come canali di trasmissione di dati i
socket siano trattati allo stesso modo dei file, ed acceduti tramite i file
-descriptor, la normale interfaccia usata per la gestione dei file non è
+descriptor, la normale interfaccia usata per la gestione dei file non è
sufficiente a poterne controllare tutte le caratteristiche, che variano tra
l'altro a seconda del loro tipo (e della relativa forma di comunicazione
sottostante). In questa sezione vedremo allora quali sono le funzioni dedicate
Le varie caratteristiche dei socket possono essere gestite attraverso l'uso di
due funzioni generiche che permettono rispettivamente di impostarle e di
recuperarne il valore corrente. La prima di queste due funzioni, quella usata
-per impostare le \textit{socket options}, è \funcd{setsockopt}, ed il suo
-prototipo è:
+per impostare le \textit{socket options}, è \funcd{setsockopt}, ed il suo
+prototipo è:
\begin{functions}
\headdecl{sys/socket.h}
\headdecl{sys/types.h}
Imposta le opzioni di un socket.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
- \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
- \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
+ \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
+ \item[\errcode{EFAULT}] l'indirizzo \param{optval} non è valido.
+ \item[\errcode{EINVAL}] il valore di \param{optlen} non è valido.
\item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
indicato.
\item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
intende operare; per indicare l'opzione da impostare si devono usare i due
argomenti successivi, \param{level} e \param{optname}. Come abbiamo visto in
sez.~\ref{sec:net_protocols} i protocolli di rete sono strutturati su vari
-livelli, ed l'interfaccia dei socket può usarne più di uno. Si avranno allora
-funzionalità e caratteristiche diverse per ciascun protocollo usato da un
+livelli, ed l'interfaccia dei socket può usarne più di uno. Si avranno allora
+funzionalità e caratteristiche diverse per ciascun protocollo usato da un
socket, e quindi saranno anche diverse le opzioni che si potranno impostare
per ciascun socket, a seconda del \textsl{livello} (trasporto, rete, ecc.) su
cui si vuole andare ad operare.
intervenire, mentre \param{optname} permette di scegliere su quale delle
opzioni che sono definite per quel protocollo si vuole operare. In sostanza la
selezione di una specifica opzione viene fatta attraverso una coppia di valori
-\param{level} e \param{optname} e chiaramente la funzione avrà successo
-soltanto se il protocollo in questione prevede quella opzione ed è utilizzato
+\param{level} e \param{optname} e chiaramente la funzione avrà successo
+soltanto se il protocollo in questione prevede quella opzione ed è utilizzato
dal socket. Infine \param{level} prevede anche il valore speciale
\const{SOL\_SOCKET} usato per le opzioni generiche che sono disponibili per
qualunque tipo di socket.
I valori usati per \param{level}, corrispondenti ad un dato protocollo usato
da un socket, sono quelli corrispondenti al valore numerico che identifica il
-suddetto protocollo in \conffile{/etc/protocols}; dato che la leggibilità di un
+suddetto protocollo in \conffile{/etc/protocols}; dato che la leggibilità di un
programma non trarrebbe certo beneficio dall'uso diretto dei valori numerici,
-più comunemente si indica il protocollo tramite le apposite costanti
+più comunemente si indica il protocollo tramite le apposite costanti
\texttt{SOL\_*} riportate in tab.~\ref{tab:sock_option_levels}, dove si sono
riassunti i valori che possono essere usati per l'argomento
-\param{level}.\footnote{la notazione in questo caso è, purtroppo, abbastanza
- confusa: infatti in Linux il valore si può impostare sia usando le costanti
+\param{level}.\footnote{la notazione in questo caso è, purtroppo, abbastanza
+ confusa: infatti in Linux il valore si può impostare sia usando le costanti
\texttt{SOL\_*}, che le analoghe \texttt{IPPROTO\_*} (citate anche da
Stevens in \cite{UNP1}); entrambe hanno gli stessi valori che sono
equivalenti ai numeri di protocollo di \conffile{/etc/protocols}, con una
- eccezione specifica, che è quella del protocollo ICMP, per la quale non
- esista una costante, il che è comprensibile dato che il suo valore, 1, è
+ eccezione specifica, che è quella del protocollo ICMP, per la quale non
+ esista una costante, il che è comprensibile dato che il suo valore, 1, è
quello che viene assegnato a \const{SOL\_SOCKET}.}
\begin{table}[!htb]
\label{tab:sock_option_levels}
\end{table}
-Il quarto argomento, \param{optval} è un puntatore ad una zona di memoria che
+Il quarto argomento, \param{optval} è un puntatore ad una zona di memoria che
contiene i dati che specificano il valore dell'opzione che si vuole passare al
-socket, mentre l'ultimo argomento \param{optlen},\footnote{questo argomento è
- in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
- \acr{libc5}; l'uso di \ctyp{socklen\_t} è stato introdotto da POSIX (valgono
+socket, mentre l'ultimo argomento \param{optlen},\footnote{questo argomento è
+ in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
+ \acr{libc5}; l'uso di \ctyp{socklen\_t} è stato introdotto da POSIX (valgono
le stesse considerazioni per l'uso di questo tipo di dato fatte in
- sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
+ sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
dimensione in byte dei dati presenti all'indirizzo indicato da \param{optval}.
-Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
-individuare qual è quello che deve essere usato, ed utilizzare le opportune
+Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
+individuare qual è quello che deve essere usato, ed utilizzare le opportune
variabili.
La gran parte delle opzioni utilizzano per \param{optval} un valore intero, se
-poi l'opzione esprime una condizione logica, il valore è sempre un intero, ma
-si dovrà usare un valore non nullo per abilitarla ed un valore nullo per
+poi l'opzione esprime una condizione logica, il valore è sempre un intero, ma
+si dovrà usare un valore non nullo per abilitarla ed un valore nullo per
disabilitarla. Se invece l'opzione non prevede di dover ricevere nessun tipo
di valore si deve impostare \param{optval} a \const{NULL}. Un piccolo numero
-di opzioni però usano dei tipi di dati peculiari, è questo il motivo per cui
-\param{optval} è stato definito come puntatore generico.
+di opzioni però usano dei tipi di dati peculiari, è questo il motivo per cui
+\param{optval} è stato definito come puntatore generico.
-La seconda funzione usata per controllare le proprietà dei socket è
+La seconda funzione usata per controllare le proprietà dei socket è
\funcd{getsockopt}, che serve a leggere i valori delle opzioni dei socket ed a
-farsi restituire i dati relativi al loro funzionamento; il suo prototipo è:
+farsi restituire i dati relativi al loro funzionamento; il suo prototipo è:
\begin{functions}
\headdecl{sys/socket.h}
\headdecl{sys/types.h}
socklen\_t *optlen)} Legge le opzioni di un socket.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
+ \item[\errcode{EBADF}] il file descriptor \param{sock} non è valido.
\item[\errcode{EFAULT}] l'indirizzo \param{optval} o quello di
- \param{optlen} non è valido.
+ \param{optlen} non è valido.
\item[\errcode{ENOPROTOOPT}] l'opzione scelta non esiste per il livello
indicato.
\item[\errcode{ENOTSOCK}] il file descriptor \param{sock} non corrisponde ad
\end{functions}
I primi tre argomenti sono identici ed hanno lo stesso significato di quelli
-di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
+di \func{setsockopt}, anche se non è detto che tutte le opzioni siano definite
per entrambe le funzioni. In questo caso \param{optval} viene usato per
ricevere le informazioni ed indica l'indirizzo a cui andranno scritti i dati
letti dal socket, infine \param{optlen} diventa un puntatore ad una variabile
argument} per indicare, prima della chiamata della funzione, la lunghezza
del buffer allocato per \param{optval} e per ricevere indietro, dopo la
chiamata della funzione, la dimensione effettiva dei dati scritti su di esso.
-Se la dimensione del buffer allocato per \param{optval} non è sufficiente si
-avrà un errore.
+Se la dimensione del buffer allocato per \param{optval} non è sufficiente si
+avrà un errore.
Come accennato esiste un insieme generico di opzioni dei socket che possono
applicarsi a qualunque tipo di socket,\footnote{una descrizione di queste
- opzioni è generalmente disponibile nella settima sezione delle pagine di
- manuale, nel caso specifico la si può consultare con \texttt{man 7 socket}.}
+ opzioni è generalmente disponibile nella settima sezione delle pagine di
+ manuale, nel caso specifico la si può consultare con \texttt{man 7 socket}.}
indipendentemente da quale protocollo venga poi utilizzato. Se si vuole
-operare su queste opzioni generiche il livello da utilizzare è
-\const{SOL\_SOCKET}; si è riportato un elenco di queste opzioni in
+operare su queste opzioni generiche il livello da utilizzare è
+\const{SOL\_SOCKET}; si è riportato un elenco di queste opzioni in
tab.~\ref{tab:sock_opt_socklevel}.
\hline
\hline
\const{SO\_KEEPALIVE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
- Controlla l'attività della connessione.\\
+ Controlla l'attività della connessione.\\
\const{SO\_OOBINLINE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Lascia in linea i dati \itindex{out-of-band}
\textit{out-of-band}.\\
\const{SO\_SNDTIMEO} &$\bullet$&$\bullet$& &\texttt{timeval}&
Timeout in trasmissione.\\
\const{SO\_BSDCOMPAT}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
- Abilita la compatibilità con BSD.\\
+ Abilita la compatibilità con BSD.\\
\const{SO\_PASSCRED} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Abilita la ricezione di credenziali.\\
\const{SO\_PEERCRED} &$\bullet$& & &\texttt{ucred}&
\const{SO\_TYPE} &$\bullet$& & &\texttt{int}&
Restituisce il tipo di socket.\\
\const{SO\_ACCEPTCONN}&$\bullet$& & &\texttt{int}&
- Indica se il socket è in ascolto.\\
+ Indica se il socket è in ascolto.\\
\const{SO\_DONTROUTE}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Non invia attraverso un gateway.\\
\const{SO\_BROADCAST}&$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
\const{SO\_LINGER} &$\bullet$&$\bullet$& &\texttt{linger}&
Indugia nella chiusura con dati da spedire.\\
\const{SO\_PRIORITY} &$\bullet$&$\bullet$& &\texttt{int}&
- Imposta la priorità del socket.\\
+ Imposta la priorità del socket.\\
\const{SO\_ERROR} &$\bullet$& & &\texttt{int}&
Riceve e cancella gli errori pendenti.\\
\hline
La tabella elenca le costanti che identificano le singole opzioni da usare
come valore per \param{optname}; le due colonne seguenti indicano per quali
-delle due funzioni (\func{getsockopt} o \func{setsockopt}) l'opzione è
+delle due funzioni (\func{getsockopt} o \func{setsockopt}) l'opzione è
disponibile, mentre la colonna successiva indica, quando di ha a che fare con
-un valore di \param{optval} intero, se l'opzione è da considerare un numero o
-un valore logico. Si è inoltre riportato sulla quinta colonna il tipo di dato
+un valore di \param{optval} intero, se l'opzione è da considerare un numero o
+un valore logico. Si è inoltre riportato sulla quinta colonna il tipo di dato
usato per \param{optval} ed una breve descrizione del significato delle
singole opzioni sulla sesta.
Le descrizioni delle opzioni presenti in tab.~\ref{tab:sock_opt_socklevel}
-sono estremamente sommarie, è perciò necessario fornire un po' più di
+sono estremamente sommarie, è perciò necessario fornire un po' più di
informazioni. Alcune opzioni inoltre hanno una notevole rilevanza nella
-gestione dei socket, e pertanto il loro utilizzo sarà approfondito
-separatamente in sez.~\ref{sec:sock_options_main}. Quello che segue è quindi
-soltanto un elenco più dettagliato della breve descrizione di
+gestione dei socket, e pertanto il loro utilizzo sarà approfondito
+separatamente in sez.~\ref{sec:sock_options_main}. Quello che segue è quindi
+soltanto un elenco più dettagliato della breve descrizione di
tab.~\ref{tab:sock_opt_socklevel} sul significato delle varie opzioni:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{SO\_KEEPALIVE}] questa opzione abilita un meccanismo di verifica
- della persistenza di una connessione associata al socket (ed è pertanto
- effettiva solo sui socket che supportano le connessioni, ed è usata
+ della persistenza di una connessione associata al socket (ed è pertanto
+ effettiva solo sui socket che supportano le connessioni, ed è usata
principalmente con il TCP). L'opzione utilizza per \param{optval} un intero
usato come valore logico. Maggiori dettagli sul suo funzionamento sono
forniti in sez.~\ref{sec:sock_options_main}.
\itindex{out-of-band} \textit{out-of-band} vengono inviati direttamente nel
flusso di dati del socket (e sono quindi letti con una normale \func{read})
invece che restare disponibili solo per l'accesso con l'uso del flag
- \const{MSG\_OOB} di \func{recvmsg}. L'argomento è trattato in dettaglio in
+ \const{MSG\_OOB} di \func{recvmsg}. L'argomento è trattato in dettaglio in
sez.~\ref{sec:TCP_urgent_data}. L'opzione funziona soltanto con socket che
supportino i dati \itindex{out-of-band} \textit{out-of-band} (non ha senso
per socket UDP ad esempio), ed utilizza per \param{optval} un intero usato
\item[\const{SO\_RCVLOWAT}] questa opzione imposta il valore che indica il
numero minimo di byte che devono essere presenti nel buffer di ricezione
- perché il kernel passi i dati all'utente, restituendoli ad una \func{read} o
+ perché il kernel passi i dati all'utente, restituendoli ad una \func{read} o
segnalando ad una \func{select} (vedi sez.~\ref{sec:TCP_sock_select}) che ci
sono dati in ingresso. L'opzione utilizza per \param{optval} un intero che
- specifica il numero di byte, ma con Linux questo valore è sempre 1 e non può
- essere cambiato; \func{getsockopt} leggerà questo valore mentre
- \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
+ specifica il numero di byte, ma con Linux questo valore è sempre 1 e non può
+ essere cambiato; \func{getsockopt} leggerà questo valore mentre
+ \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
\item[\const{SO\_SNDLOWAT}] questa opzione imposta il valore che indica il
numero minimo di byte che devono essere presenti nel buffer di trasmissione
- perché il kernel li invii al protocollo successivo, consentendo ad una
+ perché il kernel li invii al protocollo successivo, consentendo ad una
\func{write} di ritornare o segnalando ad una \func{select} (vedi
- sez.~\ref{sec:TCP_sock_select}) che è possibile eseguire una scrittura.
+ sez.~\ref{sec:TCP_sock_select}) che è possibile eseguire una scrittura.
L'opzione utilizza per \param{optval} un intero che specifica il numero di
- byte, come per la precedente \const{SO\_RCVLOWAT} con Linux questo valore è
- sempre 1 e non può essere cambiato; \func{getsockopt} leggerà questo valore
- mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
+ byte, come per la precedente \const{SO\_RCVLOWAT} con Linux questo valore è
+ sempre 1 e non può essere cambiato; \func{getsockopt} leggerà questo valore
+ mentre \func{setsockopt} darà un errore di \errcode{ENOPROTOOPT}.
\item[\const{SO\_RCVTIMEO}] l'opzione permette di impostare un tempo massimo
sulle operazioni di lettura da un socket, e prende per \param{optval} una
struttura di tipo \struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct})
- identica a quella usata con \func{select}. Con \func{getsockopt} si può
+ identica a quella usata con \func{select}. Con \func{getsockopt} si può
leggere il valore attuale, mentre con \func{setsockopt} si imposta il tempo
voluto, usando un valore nullo per \struct{timeval} il timeout viene
rimosso.
Se l'opzione viene attivata tutte le volte che una delle funzioni di lettura
(\func{read}, \func{readv}, \func{recv}, \func{recvfrom} e \func{recvmsg})
si blocca in attesa di dati per un tempo maggiore di quello impostato, essa
- ritornerà un valore -1 e la variabile \var{errno} sarà impostata con un
- errore di \errcode{EAGAIN} e \errcode{EWOULDBLOCK}, così come sarebbe
- avvenuto se si fosse aperto il socket in modalità non bloccante.\footnote{in
+ ritornerà un valore -1 e la variabile \var{errno} sarà impostata con un
+ errore di \errcode{EAGAIN} e \errcode{EWOULDBLOCK}, così come sarebbe
+ avvenuto se si fosse aperto il socket in modalità non bloccante.\footnote{in
teoria, se il numero di byte presenti nel buffer di ricezione fosse
inferiore a quello specificato da \const{SO\_RCVLOWAT}, l'effetto potrebbe
essere semplicemente quello di provocare l'uscita delle funzioni di
lettura restituendo il numero di byte fino ad allora ricevuti; dato che
- con Linux questo valore è sempre 1 questo caso non esiste.}
+ con Linux questo valore è sempre 1 questo caso non esiste.}
- In genere questa opzione non è molto utilizzata se si ha a che fare con la
- lettura dei dati, in quanto è sempre possibile usare una \func{select} che
+ In genere questa opzione non è molto utilizzata se si ha a che fare con la
+ lettura dei dati, in quanto è sempre possibile usare una \func{select} che
consente di specificare un \textit{timeout}; l'uso di \func{select} non
- consente però di impostare il timeout per l'uso di \func{connect}, per avere
- il quale si può ricorrere a questa opzione.
+ consente però di impostare il timeout per l'uso di \func{connect}, per avere
+ il quale si può ricorrere a questa opzione.
% TODO verificare il timeout con un programma di test
\item[\const{SO\_SNDTIMEO}] l'opzione permette di impostare un tempo massimo
sulle operazioni di scrittura su un socket, ed usa gli stessi valori di
- \const{SO\_RCVTIMEO}. In questo caso però si avrà un errore di
+ \const{SO\_RCVTIMEO}. In questo caso però si avrà un errore di
\errcode{EAGAIN} o \errcode{EWOULDBLOCK} per le funzioni di scrittura
\func{write}, \func{writev}, \func{send}, \func{sendto} e \func{sendmsg}
qualora queste restino bloccate per un tempo maggiore di quello specificato.
-\item[\const{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
- comportamento di BSD (in particolare ne riproduce i bug). Attualmente è una
- opzione usata solo per il protocollo UDP e ne è prevista la rimozione in
+\item[\const{SO\_BSDCOMPAT}] questa opzione abilita la compatibilità con il
+ comportamento di BSD (in particolare ne riproduce i bug). Attualmente è una
+ opzione usata solo per il protocollo UDP e ne è prevista la rimozione in
futuro. L'opzione utilizza per \param{optval} un intero usato come valore
logico.
Quando viene abilitata gli errori riportati da messaggi ICMP per un socket
UDP non vengono passati al programma in user space. Con le versioni 2.0.x
del kernel erano anche abilitate altre opzioni per i socket raw, che sono
- state rimosse con il passaggio al 2.2; è consigliato correggere i programmi
+ state rimosse con il passaggio al 2.2; è consigliato correggere i programmi
piuttosto che usare questa funzione.
\item[\const{SO\_PASSCRED}] questa opzione abilita sui socket unix-domain
come valore logico.
\item[\const{SO\_PEERCRED}] questa opzione restituisce le credenziali del
- processo remoto connesso al socket; l'opzione è disponibile solo per socket
- unix-domain e può essere usata solo con \func{getsockopt}. Utilizza per
+ processo remoto connesso al socket; l'opzione è disponibile solo per socket
+ unix-domain e può essere usata solo con \func{getsockopt}. Utilizza per
\param{optval} una apposita struttura \struct{ucred} (vedi
sez.~\ref{sec:unix_socket}).
inviare pacchetti solo su quella. L'opzione richiede per \param{optval} il
puntatore ad una stringa contenente il nome dell'interfaccia (ad esempio
\texttt{eth0}); utilizzando una stringa nulla o un valore nullo per
- \param{optlen} si può rimuovere un precedente collegamento.
+ \param{optlen} si può rimuovere un precedente collegamento.
Il nome della interfaccia deve essere specificato con una stringa terminata
- da uno zero e di lunghezza massima pari a \const{IFNAMSIZ}; l'opzione è
+ da uno zero e di lunghezza massima pari a \const{IFNAMSIZ}; l'opzione è
effettiva solo per alcuni tipi di socket, ed in particolare per quelli della
- famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
+ famiglia \const{AF\_INET}; non è invece supportata per i \textit{packet
socket} (vedi sez.~\ref{sec:socket_raw}).
\item[\const{SO\_DEBUG}] questa opzione abilita il debugging delle operazioni
dei socket; l'opzione utilizza per \param{optval} un intero usato come
- valore logico, e può essere utilizzata solo da un processo con i privilegi
+ valore logico, e può essere utilizzata solo da un processo con i privilegi
di amministratore (in particolare con la \itindex{capabilities}
\textit{capability} \const{CAP\_NET\_ADMIN}). L'opzione necessita inoltre
- dell'opportuno supporto nel kernel;\footnote{deve cioè essere definita la
+ dell'opportuno supporto nel kernel;\footnote{deve cioè essere definita la
macro di preprocessore \macro{SOCK\_DEBUGGING} nel file
- \file{include/net/sock.h} dei sorgenti del kernel, questo è sempre vero
+ \file{include/net/sock.h} dei sorgenti del kernel, questo è sempre vero
nei kernel delle serie superiori alla 2.3, per i kernel delle serie
- precedenti invece è necessario aggiungere a mano detta definizione; è
+ precedenti invece è necessario aggiungere a mano detta definizione; è
inoltre possibile abilitare anche il tracciamento degli stati del TCP
definendo la macro \macro{STATE\_TRACE} in \file{include/net/tcp.h}.}
quando viene abilitata una serie di messaggi con le informazioni di debug
vengono inviati direttamente al sistema del kernel log.\footnote{si tenga
- presente che il comportamento è diverso da quanto avviene con BSD, dove
+ presente che il comportamento è diverso da quanto avviene con BSD, dove
l'opzione opera solo sui socket TCP, causando la scrittura di tutti i
pacchetti inviati sulla rete su un buffer circolare che viene letto da un
apposito programma, \cmd{trpt}.}
\item[\const{SO\_REUSEADDR}] questa opzione permette di eseguire la funzione
- \func{bind} su indirizzi locali che siano già in uso da altri socket;
+ \func{bind} su indirizzi locali che siano già in uso da altri socket;
l'opzione utilizza per \param{optval} un intero usato come valore logico.
Questa opzione modifica il comportamento normale dell'interfaccia dei socket
che fa fallire l'esecuzione della funzione \func{bind} con un errore di
- \errcode{EADDRINUSE} quando l'indirizzo locale\footnote{più propriamente il
- controllo viene eseguito sulla porta.} è già in uso da parte di un altro
+ \errcode{EADDRINUSE} quando l'indirizzo locale\footnote{più propriamente il
+ controllo viene eseguito sulla porta.} è già in uso da parte di un altro
socket. Maggiori dettagli sul suo funzionamento sono forniti in
sez.~\ref{sec:sock_options_main}.
\item[\const{SO\_TYPE}] questa opzione permette di leggere il tipo di socket
su cui si opera; funziona solo con \func{getsockopt}, ed utilizza per
- \param{optval} un intero in cui verrà restituito il valore numerico che lo
+ \param{optval} un intero in cui verrà restituito il valore numerico che lo
identifica (ad esempio \const{SOCK\_STREAM}).
\item[\const{SO\_ACCEPTCONN}] questa opzione permette di rilevare se il socket
- su cui opera è stato posto in modalità di ricezione di eventuali connessioni
- con una chiamata a \func{listen}. L'opzione può essere usata soltanto con
+ su cui opera è stato posto in modalità di ricezione di eventuali connessioni
+ con una chiamata a \func{listen}. L'opzione può essere usata soltanto con
\func{getsockopt} e utilizza per \param{optval} un intero in cui viene
- restituito 1 se il socket è in ascolto e 0 altrimenti.
+ restituito 1 se il socket è in ascolto e 0 altrimenti.
\item[\const{SO\_DONTROUTE}] questa opzione forza l'invio diretto dei
pacchetti del socket, saltando ogni processo relativo all'uso della tabella
\item[\const{SO\_RCVBUF}] questa opzione imposta la dimensione del buffer di
ricezione del socket. Prende per \param{optval} un intero indicante il
- numero di byte. Il valore di default ed il valore massimo che si può
+ numero di byte. Il valore di default ed il valore massimo che si può
specificare come argomento per questa opzione sono impostabili tramiti gli
opportuni valori di \func{sysctl} (vedi sez.~\ref{sec:sock_sysctl}).
Si tenga presente che nel caso di socket TCP, per entrambe le opzioni
\const{SO\_RCVBUF} e \const{SO\_SNDBUF}, il kernel alloca effettivamente una
- quantità di memoria doppia rispetto a quanto richiesto con
+ quantità di memoria doppia rispetto a quanto richiesto con
\func{setsockopt}. Questo comporta che una successiva lettura con
- \func{getsockopt} riporterà un valore diverso da quello impostato con
- \func{setsockopt}. Questo avviene perché TCP necessita dello spazio in più
+ \func{getsockopt} riporterà un valore diverso da quello impostato con
+ \func{setsockopt}. Questo avviene perché TCP necessita dello spazio in più
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
+ \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
essere effettive, devono essere impostate prima della chiamata alle funzioni
\func{listen} o \func{connect}.
-\item[\const{SO\_LINGER}] questa opzione controlla le modalità con cui viene
+\item[\const{SO\_LINGER}] questa opzione controlla le modalità con cui viene
chiuso un socket quando si utilizza un protocollo che supporta le
- connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
+ connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
modifica il comportamento delle funzioni \func{close} e \func{shutdown}.
L'opzione richiede che l'argomento \param{optval} sia una struttura di tipo
\struct{linger}, definita in \texttt{sys/socket.h} ed illustrata in
fig.~\ref{fig:sock_linger_struct}. Maggiori dettagli sul suo funzionamento
sono forniti in sez.~\ref{sec:sock_options_main}.
-\item[\const{SO\_PRIORITY}] questa opzione permette di impostare le priorità
+\item[\const{SO\_PRIORITY}] questa opzione permette di impostare le priorità
per tutti i pacchetti che sono inviati sul socket, prende per \param{optval}
un valore intero. Con questa opzione il kernel usa il valore per ordinare le
- priorità sulle code di rete,\footnote{questo richiede che sia abilitato il
+ priorità sulle code di rete,\footnote{questo richiede che sia abilitato il
sistema di \textit{Quality of Service} disponibile con le opzioni di
- routing avanzato.} i pacchetti con priorità più alta vengono processati
- per primi, in modalità che dipendono dalla disciplina di gestione della
+ routing avanzato.} i pacchetti con priorità più alta vengono processati
+ per primi, in modalità che dipendono dalla disciplina di gestione della
coda. Nel caso di protocollo IP questa opzione permette anche di impostare i
valori del campo \textit{type of service} (noto come TOS, vedi
sez.~\ref{sec:IP_header}) per i pacchetti uscenti. Per impostare una
- priorità al di fuori dell'intervallo di valori fra 0 e 6 sono richiesti i
+ priorità al di fuori dell'intervallo di valori fra 0 e 6 sono richiesti i
privilegi di amministratore con la \itindex{capabilities} capability
\const{CAP\_NET\_ADMIN}.
\item[\const{SO\_ERROR}] questa opzione riceve un errore presente sul socket;
- può essere utilizzata soltanto con \func{getsockopt} e prende per
+ può essere utilizzata soltanto con \func{getsockopt} e prende per
\param{optval} un valore intero, nel quale viene restituito il codice di
errore, e la condizione di errore sul socket viene cancellata. Viene
usualmente utilizzata per ricevere il codice di errore, come accennato in
\label{sec:sock_options_main}
La descrizione sintetica del significato delle opzioni generiche dei socket,
-riportata nell'elenco in sez.~\ref{sec:sock_generic_options}, è
-necessariamente sintetica, alcune di queste però possono essere utilizzate
-per controllare delle funzionalità che hanno una notevole rilevanza nella
+riportata nell'elenco in sez.~\ref{sec:sock_generic_options}, è
+necessariamente sintetica, alcune di queste però possono essere utilizzate
+per controllare delle funzionalità che hanno una notevole rilevanza nella
programmazione dei socket. Per questo motivo faremo in questa sezione un
-approfondimento sul significato delle opzioni generiche più importanti.
+approfondimento sul significato delle opzioni generiche più importanti.
\index{costante!{SO\_KEEPALIVE}@{{\tt {SO\_KEEPALIVE}}}|(}
\subsubsection{L'opzione \const{SO\_KEEPALIVE}}
-La prima opzione da approfondire è \const{SO\_KEEPALIVE} che permette di
+La prima opzione da approfondire è \const{SO\_KEEPALIVE} che permette di
tenere sotto controllo lo stato di una connessione. Una connessione infatti
-resta attiva anche quando non viene effettuato alcun traffico su di essa; è
+resta attiva anche quando non viene effettuato alcun traffico su di essa; è
allora possibile, in caso di una interruzione completa della rete, che la
caduta della connessione non venga rilevata, dato che sulla stessa non passa
comunque alcun traffico.
-Se si imposta questa opzione, è invece cura del kernel inviare degli appositi
+Se si imposta questa opzione, è invece cura del kernel inviare degli appositi
messaggi sulla rete, detti appunto \textit{keep-alive}, per verificare se la
-connessione è attiva. L'opzione funziona soltanto con i socket che supportano
+connessione è attiva. L'opzione funziona soltanto con i socket che supportano
le connessioni (non ha senso per socket UDP ad esempio) e si applica
principalmente ai socket TCP.
Con le impostazioni di default (che sono riprese da BSD) Linux emette un
messaggio di \textit{keep-alive}\footnote{in sostanza un segmento ACK vuoto,
- cui sarà risposto con un altro segmento ACK vuoto.} verso l'altro capo della
-connessione se questa è rimasta senza traffico per più di due ore. Se è tutto
-a posto il messaggio viene ricevuto e verrà emesso un segmento ACK di
-risposta, alla cui ricezione ripartirà un altro ciclo di attesa per altre due
-ore di inattività; il tutto avviene all'interno del kernel e le applicazioni
+ cui sarà risposto con un altro segmento ACK vuoto.} verso l'altro capo della
+connessione se questa è rimasta senza traffico per più di due ore. Se è tutto
+a posto il messaggio viene ricevuto e verrà emesso un segmento ACK di
+risposta, alla cui ricezione ripartirà un altro ciclo di attesa per altre due
+ore di inattività; il tutto avviene all'interno del kernel e le applicazioni
non riceveranno nessun dato.
Qualora ci siano dei problemi di rete si possono invece verificare i due casi
-di terminazione precoce del server già illustrati in
-sez.~\ref{sec:TCP_conn_crash}. Il primo è quello in cui la macchina remota ha
-avuto un crollo del sistema ed è stata riavviata, per cui dopo il riavvio la
-connessione non esiste più.\footnote{si ricordi che un normale riavvio o il
+di terminazione precoce del server già illustrati in
+sez.~\ref{sec:TCP_conn_crash}. Il primo è quello in cui la macchina remota ha
+avuto un crollo del sistema ed è stata riavviata, per cui dopo il riavvio la
+connessione non esiste più.\footnote{si ricordi che un normale riavvio o il
crollo dell'applicazione non ha questo effetto, in quanto in tal caso si
passa sempre per la chiusura del processo, e questo, come illustrato in
sez.~\ref{sec:file_close}, comporta anche la regolare chiusura del socket
con l'invio di un segmento FIN all'altro capo della connessione.} In questo
-caso all'invio del messaggio di \textit{keep-alive} si otterrà come risposta
-un segmento RST che indica che l'altro capo non riconosce più l'esistenza
-della connessione ed il socket verrà chiuso riportando un errore di
+caso all'invio del messaggio di \textit{keep-alive} si otterrà come risposta
+un segmento RST che indica che l'altro capo non riconosce più l'esistenza
+della connessione ed il socket verrà chiuso riportando un errore di
\errcode{ECONNRESET}.
-Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
-più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di 75
+Se invece non viene ricevuta nessuna risposta (indice che la macchina non è
+più raggiungibile) l'emissione dei messaggi viene ripetuta ad intervalli di 75
secondi per un massimo di 9 volte\footnote{entrambi questi valori possono
- essere modificati a livello di sistema (cioè per tutti i socket) con gli
+ essere modificati a livello di sistema (cioè per tutti i socket) con gli
opportuni parametri illustrati in sez.~\ref{sec:sock_sysctl} ed a livello di
singolo socket con le opzioni \texttt{TCP\_KEEP*} di
sez.~\ref{sec:sock_tcp_udp_options}.} (per un totale di 11 minuti e 15
-secondi) dopo di che, se non si è ricevuta nessuna risposta, il socket viene
+secondi) dopo di che, se non si è ricevuta nessuna risposta, il socket viene
chiuso dopo aver impostato un errore di \errcode{ETIMEDOUT}. Qualora la
connessione si sia ristabilita e si riceva un successivo messaggio di risposta
il ciclo riparte come se niente fosse avvenuto. Infine se si riceve come
risposta un pacchetto ICMP di destinazione irraggiungibile (vedi
-sez.~\ref{sec:ICMP_protocol}), verrà restituito l'errore corrispondente.
+sez.~\ref{sec:ICMP_protocol}), verrà restituito l'errore corrispondente.
In generale questa opzione serve per individuare una caduta della connessione
anche quando non si sta facendo traffico su di essa. Viene usata
principalmente sui server per evitare di mantenere impegnate le risorse che
-verrebbero dedicate a trattare delle connessioni che in realtà sono già
+verrebbero dedicate a trattare delle connessioni che in realtà sono già
terminate (quelle che vengono anche chiamate connessioni
-\textsl{semi-aperte}); in tutti quei casi cioè in cui il server si trova in
-attesa di dati in ingresso su una connessione che non arriveranno mai o perché
-il client sull'altro capo non è più attivo o perché non è più in grado di
+\textsl{semi-aperte}); in tutti quei casi cioè in cui il server si trova in
+attesa di dati in ingresso su una connessione che non arriveranno mai o perché
+il client sull'altro capo non è più attivo o perché non è più in grado di
comunicare con il server via rete.
\begin{figure}[!htb]
Abilitandola dopo un certo tempo le connessioni effettivamente terminate
verranno comunque chiuse per cui, utilizzando ad esempio una \func{select}, se
-be potrà rilevare la conclusione e ricevere il relativo errore. Si tenga
-presente però che non può avere la certezza assoluta che un errore di
+be potrà rilevare la conclusione e ricevere il relativo errore. Si tenga
+presente però che non può avere la certezza assoluta che un errore di
\errcode{ETIMEDOUT} ottenuto dopo aver abilitato questa opzione corrisponda
necessariamente ad una reale conclusione della connessione, il problema
potrebbe anche essere dovuto ad un problema di routing che perduri per un
tempo maggiore di quello impiegato nei vari tentativi di ritrasmissione del
-\textit{keep-alive} (anche se questa non è una condizione molto probabile).
+\textit{keep-alive} (anche se questa non è una condizione molto probabile).
Come esempio dell'utilizzo di questa opzione introduciamo all'interno del
nostro server per il servizio \textit{echo} la nuova opzione \texttt{-k} che
permette di attivare il \textit{keep-alive} sui socket; tralasciando la parte
relativa alla gestione di detta opzione (che si limita ad assegnare ad 1 la
variabile \var{keepalive}) tutte le modifiche al server sono riportate in
-fig.~\ref{fig:echod_keepalive_code}. Al solito il codice completo è contenuto
+fig.~\ref{fig:echod_keepalive_code}. Al solito il codice completo è contenuto
nel file \texttt{TCP\_echod\_fourth.c} dei sorgenti allegati alla guida.
-Come si può notare la variabile \var{keepalive} è preimpostata (\texttt{\small
+Come si può notare la variabile \var{keepalive} è preimpostata (\texttt{\small
8}) ad un valore nullo; essa viene utilizzata sia come variabile logica per
la condizione (\texttt{\small 14}) che controlla l'attivazione del
\textit{keep-alive} che come valore dell'argomento \param{optval} della
chiamata a \func{setsockopt} (\texttt{\small 16}). A seconda del suo valore
tutte le volte che un processo figlio viene eseguito in risposta ad una
-connessione verrà pertanto eseguita o meno la sezione (\texttt{\small 14--17})
+connessione verrà pertanto eseguita o meno la sezione (\texttt{\small 14--17})
che esegue l'impostazione di \const{SO\_KEEPALIVE} sul socket connesso,
attivando il relativo comportamento.
\index{costante!{SO\_KEEPALIVE}@{{\tt {SO\_KEEPALIVE}}}|)}
\index{costante!{SO\_REUSEADDR}@{{\tt {SO\_REUSEADDR}}}|(}
\subsubsection{L'opzione \const{SO\_REUSEADDR}}
-La seconda opzione da approfondire è \const{SO\_REUSEADDR}, che consente di
-eseguire \func{bind} su un socket anche quando la porta specificata è già in
+La seconda opzione da approfondire è \const{SO\_REUSEADDR}, che consente di
+eseguire \func{bind} su un socket anche quando la porta specificata è già in
uso da parte di un altro socket. Si ricordi infatti che, come accennato in
sez.~\ref{sec:TCP_func_bind}, normalmente la funzione \func{bind} fallisce con
-un errore di \errcode{EADDRINUSE} se la porta scelta è già utilizzata da un
+un errore di \errcode{EADDRINUSE} se la porta scelta è già utilizzata da un
altro socket, proprio per evitare che possano essere lanciati due server sullo
stesso indirizzo e la stessa porta, che verrebbero a contendersi i pacchetti
aventi quella destinazione.
-Esistono però situazioni ed esigenze particolari in cui non si vuole che
-questo comportamento di salvaguardia accada, ed allora si può fare ricorso a
-questa opzione. La questione è comunque abbastanza complessa in quanto, come
+Esistono però situazioni ed esigenze particolari in cui non si vuole che
+questo comportamento di salvaguardia accada, ed allora si può fare ricorso a
+questa opzione. La questione è comunque abbastanza complessa in quanto, come
sottolinea Stevens in \cite{UNP1}, si distinguono ben quattro casi diversi in
-cui è prevista la possibilità di un utilizzo di questa opzione, il che la
-rende una delle più difficili da capire.
+cui è prevista la possibilità di un utilizzo di questa opzione, il che la
+rende una delle più difficili da capire.
-Il primo caso, che è anche il più comune, in cui si fa ricorso a
-\const{SO\_REUSEADDR} è quello in cui un server è terminato ma esistono ancora
+Il primo caso, che è anche il più comune, in cui si fa ricorso a
+\const{SO\_REUSEADDR} è quello in cui un server è terminato ma esistono ancora
dei processi figli che mantengono attiva almeno una connessione remota che
utilizza l'indirizzo locale, mantenendo occupata la porta. Quando si riesegue
il server allora questo riceve un errore sulla chiamata a \func{bind} dato che
-la porta è ancora utilizzata in una connessione esistente.\footnote{questa è
- una delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
- quanto è piuttosto comune trovarsi in questa situazione quando si sta
+la porta è ancora utilizzata in una connessione esistente.\footnote{questa è
+ una delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
+ quanto è piuttosto comune trovarsi in questa situazione quando si sta
sviluppando un server che si ferma e si riavvia in continuazione dopo aver
- fatto modifiche.} Inoltre se si usa il protocollo TCP questo può avvenire
-anche dopo tutti i processi figli sono terminati, dato che una connessione può
+ fatto modifiche.} Inoltre se si usa il protocollo TCP questo può avvenire
+anche dopo tutti i processi figli sono terminati, dato che una connessione può
restare attiva anche dopo la chiusura del socket, mantenendosi nello stato
\texttt{TIME\_WAIT} (vedi sez.~\ref{sec:TCP_time_wait}).
Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
\func{bind} si consente a quest'ultima di avere comunque successo anche se la
-connessione è attiva (o nello stato \texttt{TIME\_WAIT}). È bene però
+connessione è attiva (o nello stato \texttt{TIME\_WAIT}). È bene però
ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si usa
-questa opzione esiste sempre una probabilità, anche se estremamente
-remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
+questa opzione esiste sempre una probabilità, anche se estremamente
+remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
- numeri di sequenza dei pacchetti, e questo è estremamente improbabile.} che
+ numeri di sequenza dei pacchetti, e questo è estremamente improbabile.} che
eventuali pacchetti rimasti intrappolati in una precedente connessione possano
finire fra quelli di una nuova.
Come esempio di uso di questa connessione abbiamo predisposto una nuova
versione della funzione \func{sockbind} (vedi fig.~\ref{fig:sockbind_code})
-che consenta l'impostazione di questa opzione. La nuova funzione è
+che consenta l'impostazione di questa opzione. La nuova funzione è
\func{sockbindopt}, e le principali differenze rispetto alla precedente sono
illustrate in fig.~\ref{fig:sockbindopt_code}, dove si sono riportate le
sezioni di codice modificate rispetto alla versione precedente. Il codice
\label{fig:sockbindopt_code}
\end{figure}
-In realtà tutto quello che si è fatto è stato introdurre nella nuova funzione
-(\texttt{\small 1}) un nuovo argomento intero, \param{reuse}, che conterrà il
+In realtà tutto quello che si è fatto è stato introdurre nella nuova funzione
+(\texttt{\small 1}) un nuovo argomento intero, \param{reuse}, che conterrà il
valore logico da usare nella successiva chiamata (\texttt{\small 14}) a
-\func{setsockopt}. Si è poi aggiunta una sezione (\texttt{\small 13-17}) che
+\func{setsockopt}. Si è poi aggiunta una sezione (\texttt{\small 13-17}) che
esegue l'impostazione dell'opzione fra la chiamata a \func{socket} e quella a
\func{bind}.
-A questo punto basterà modificare il server per utilizzare la nuova
+A questo punto basterà modificare il server per utilizzare la nuova
funzione; in fig.~\ref{fig:TCP_echod_fifth} abbiamo riportato le sezioni
modificate rispetto alla precedente versione di
-fig.~\ref{fig:TCP_echod_third}. Al solito il codice completo è coi sorgenti
+fig.~\ref{fig:TCP_echod_third}. Al solito il codice completo è coi sorgenti
allegati alla guida, nel file \texttt{TCP\_echod\_fifth.c}.
-Anche in questo caso si è introdotta (\texttt{\small 8}) una nuova variabile
-\var{reuse} che consente di controllare l'uso dell'opzione e che poi sarà
+Anche in questo caso si è introdotta (\texttt{\small 8}) una nuova variabile
+\var{reuse} che consente di controllare l'uso dell'opzione e che poi sarà
usata (\texttt{\small 14}) come ultimo argomento di \func{setsockopt}. Il
-valore di default di questa variabile è nullo, ma usando l'opzione \texttt{-r}
-nell'invocazione del server (al solito la gestione delle opzioni non è
-riportata in fig.~\ref{fig:TCP_echod_fifth}) se ne potrà impostare ad 1 il
+valore di default di questa variabile è nullo, ma usando l'opzione \texttt{-r}
+nell'invocazione del server (al solito la gestione delle opzioni non è
+riportata in fig.~\ref{fig:TCP_echod_fifth}) se ne potrà impostare ad 1 il
valore, per cui in tal caso la successiva chiamata (\texttt{\small 13-17}) a
-\func{setsockopt} attiverà l'opzione \const{SO\_REUSEADDR}.
+\func{setsockopt} attiverà l'opzione \const{SO\_REUSEADDR}.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:TCP_echod_fifth}
\end{figure}
-Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
+Il secondo caso in cui viene usata \const{SO\_REUSEADDR} è quando si ha una
macchina cui sono assegnati diversi numeri IP (o come suol dirsi
\textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
programma diverso (o una istanza diversa dello stesso programma) per indirizzi
-IP diversi. Si ricordi infatti che è sempre possibile indicare a \func{bind}
+IP diversi. Si ricordi infatti che è sempre possibile indicare a \func{bind}
di collegarsi solo su di un indirizzo specifico; in tal caso se un altro
programma cerca di riutilizzare la stessa porta (anche specificando un
-indirizzo diverso) otterrà un errore, a meno di non aver preventivamente
+indirizzo diverso) otterrà un errore, a meno di non aver preventivamente
impostato \const{SO\_REUSEADDR}.
Usando questa opzione diventa anche possibile eseguire \func{bind}
-sull'indirizzo generico, e questo permetterà il collegamento per tutti gli
+sull'indirizzo generico, e questo permetterà il collegamento per tutti gli
indirizzi (di quelli presenti) per i quali la porta non risulti occupata da
-una precedente chiamata più specifica. Infine si tenga presente che con il
-protocollo TCP non è mai possibile far partire server che eseguano \func{bind}
-sullo stesso indirizzo e la stessa porta, cioè ottenere quello che viene
+una precedente chiamata più specifica. Infine si tenga presente che con il
+protocollo TCP non è mai possibile far partire server che eseguano \func{bind}
+sullo stesso indirizzo e la stessa porta, cioè ottenere quello che viene
chiamato un \textit{completely duplicate binding}.
-Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
+Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
all'interno dello stesso programma per associare indirizzi locali diversi a
-socket diversi. In genere questo viene fatto per i socket UDP quando è
+socket diversi. In genere questo viene fatto per i socket UDP quando è
necessario ottenere l'indirizzo a cui sono rivolte le richieste del client ed
il sistema non supporta l'opzione \const{IP\_RECVDSTADDR};\footnote{nel caso
- di Linux questa opzione è stata supportata per in certo periodo nello
- sviluppo del kernel 2.1.x, ma è in seguito stata soppiantata dall'uso di
+ di Linux questa opzione è stata supportata per in certo periodo nello
+ sviluppo del kernel 2.1.x, ma è in seguito stata soppiantata dall'uso di
\const{IP\_PKTINFO} (vedi sez.~\ref{sec:sock_ipv4_options}).} in tale modo
-si può sapere a quale socket corrisponde un certo indirizzo. Non ha senso
-fare questa operazione per un socket TCP dato che su di essi si può sempre
-invocare \func{getsockname} una volta che si è completata la connessione.
+si può sapere a quale socket corrisponde un certo indirizzo. Non ha senso
+fare questa operazione per un socket TCP dato che su di essi si può sempre
+invocare \func{getsockname} una volta che si è completata la connessione.
-Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
-\textit{completely duplicate binding}, quando cioè si vuole eseguire
-\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
+Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
+\textit{completely duplicate binding}, quando cioè si vuole eseguire
+\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
altro socket. Questo ovviamente non ha senso per il normale traffico di rete,
in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma
quando un sistema supporta il traffico in \itindex{multicast}
\textit{multicast}, in cui una applicazione invia i pacchetti a molte altre
(vedi sez.~\ref{sec:xxx_multicast}), allora ha senso che su una macchina i
pacchetti provenienti dal traffico in \itindex{multicast} \textit{multicast}
-possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
- traffico in \textit{multicast} è quello di uno streaming di dati (audio,
+possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
+ traffico in \textit{multicast} è quello di uno streaming di dati (audio,
video, ecc.), l'uso del \textit{multicast} consente in tal caso di
- trasmettere un solo pacchetto, che potrà essere ricevuto da tutti i
+ trasmettere un solo pacchetto, che potrà essere ricevuto da tutti i
possibili destinatari (invece di inviarne un duplicato a ciascuno); in
- questo caso è perfettamente logico aspettarsi che sulla stessa macchina più
+ questo caso è perfettamente logico aspettarsi che sulla stessa macchina più
utenti possano lanciare un programma che permetta loro di ricevere gli
stessi dati.} o da diverse istanze della stessa applicazione.
\itindex{multicast}
In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una
applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
-un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
+un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di
-applicazione è normale l'uso del protocollo UDP). La regola è che quando si
-hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
+applicazione è normale l'uso del protocollo UDP). La regola è che quando si
+hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
tutti pacchetti destinati ad un indirizzo di \itindex{broadcast}
\textit{broadcast} o di \itindex{multicast} \textit{multicast} viene inviata
-una copia a ciascuna applicazione. Non è definito invece cosa accade qualora
+una copia a ciascuna applicazione. Non è definito invece cosa accade qualora
il pacchetto sia destinato ad un indirizzo normale (unicast).
-Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
+Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta
opzione sia specificata per tutti i socket per i quali si vuole eseguire il
\textit{completely duplicate binding}. Nel caso di Linux questa opzione non
-esiste, ma il comportamento di \const{SO\_REUSEADDR} è analogo, sarà cioè
+esiste, ma il comportamento di \const{SO\_REUSEADDR} è analogo, sarà cioè
possibile effettuare un \textit{completely duplicate binding} ed ottenere il
successo di \func{bind} su un socket legato allo stesso indirizzo e porta solo
se il programma che ha eseguito per primo \func{bind} su di essi ha impostato
questa opzione.\footnote{questa restrizione permette di evitare il cosiddetto
\textit{port stealing}, in cui un programma, usando \const{SO\_REUSEADDR},
- può collegarsi ad una porta già in uso e ricevere i pacchetti destinati ad
- un altro programma; con questa caratteristica ciò è possibile soltanto se il
+ può collegarsi ad una porta già in uso e ricevere i pacchetti destinati ad
+ un altro programma; con questa caratteristica ciò è possibile soltanto se il
primo programma a consentirlo, avendo usato fin dall'inizio
\const{SO\_REUSEADDR}.}
\index{costante!{SO\_LINGER}@{{\tt {SO\_LINGER}}}|(}
\subsubsection{L'opzione \const{SO\_LINGER}}
-La terza opzione da approfondire è \const{SO\_LINGER}; essa, come il nome
+La terza opzione da approfondire è \const{SO\_LINGER}; essa, come il nome
suggerisce, consente di ``\textsl{indugiare}'' nella chiusura di un socket. Il
-comportamento standard sia di \func{close} che \func{shutdown} è infatti
+comportamento standard sia di \func{close} che \func{shutdown} è infatti
quello di terminare immediatamente dopo la chiamata, mentre il procedimento di
chiusura della connessione (o di un lato di essa) ed il rispettivo invio sulla
rete di tutti i dati ancora presenti nei buffer, viene gestito in sottofondo
eventualmente ripristinare) questo comportamento in base ai valori passati nei
campi della struttura \struct{linger}, illustrata in
fig.~\ref{fig:sock_linger_struct}. Fintanto che il valore del campo
-\var{l\_onoff} di \struct{linger} è nullo la modalità che viene impostata
-(qualunque sia il valore di \var{l\_linger}) è quella standard appena
+\var{l\_onoff} di \struct{linger} è nullo la modalità che viene impostata
+(qualunque sia il valore di \var{l\_linger}) è quella standard appena
illustrata; questa combinazione viene utilizzata per riportarsi al
comportamento normale qualora esso sia stato cambiato da una precedente
chiamata.
Se si utilizza un valore di \var{l\_onoff} diverso da zero, il comportamento
alla chiusura viene a dipendere dal valore specificato per il campo
-\var{l\_linger}; se quest'ultimo è nullo l'uso delle funzioni \func{close} e
+\var{l\_linger}; se quest'ultimo è nullo l'uso delle funzioni \func{close} e
\func{shutdown} provoca la terminazione immediata della connessione: nel caso
-di TCP cioè non viene eseguito il procedimento di chiusura illustrato in
+di TCP cioè non viene eseguito il procedimento di chiusura illustrato in
sez.~\ref{sec:TCP_conn_term}, ma tutti i dati ancora presenti nel buffer
vengono immediatamente scartati e sulla rete viene inviato un segmento di RST
che termina immediatamente la connessione.
-Un esempio di questo comportamento si può abilitare nel nostro client del
+Un esempio di questo comportamento si può abilitare nel nostro client del
servizio \textit{echo} utilizzando l'opzione \texttt{-r}; riportiamo in
fig.~\ref{fig:TCP_echo_sixth} la sezione di codice che permette di introdurre
-questa funzionalità,; al solito il codice completo è disponibile nei sorgenti
+questa funzionalità,; al solito il codice completo è disponibile nei sorgenti
allegati.
\begin{figure}[!htb]
\end{figure}
La sezione indicata viene eseguita dopo aver effettuato la connessione e prima
-di chiamare la funzione di gestione, cioè fra le righe (\texttt{\small 12}) e
+di chiamare la funzione di gestione, cioè fra le righe (\texttt{\small 12}) e
(\texttt{\small 13}) del precedente esempio di fig.~\ref{fig:TCP_echo_fifth}.
Il codice si limita semplicemente a controllare (\texttt{\small 3}) il
valore della variabile \var{reset} che assegnata nella gestione delle opzioni
il valore di ritorno e si termina il programma in caso di errore, stampandone
il valore.
-Infine l'ultima possibilità, quella in cui si utilizza effettivamente
-\const{SO\_LINGER} per \textsl{indugiare} nella chiusura, è quella in cui sia
+Infine l'ultima possibilità, quella in cui si utilizza effettivamente
+\const{SO\_LINGER} per \textsl{indugiare} nella chiusura, è quella in cui sia
\var{l\_onoff} che \var{l\_linger} hanno un valore diverso da zero. Se si
esegue l'impostazione con questi valori sia \func{close} che \func{shutdown}
si bloccano, nel frattempo viene eseguita la normale procedura di conclusione
della connessione (quella di sez.~\ref{sec:TCP_conn_term}) ma entrambe le
funzioni non ritornano fintanto che non si sia concluso il procedimento di
chiusura della connessione, o non sia passato un numero di
-secondi\footnote{questa è l'unità di misura indicata da POSIX ed adottata da
- Linux, altri kernel possono usare unità di misura diverse, oppure usare il
+secondi\footnote{questa è l'unità di misura indicata da POSIX ed adottata da
+ Linux, altri kernel possono usare unità di misura diverse, oppure usare il
campo \var{l\_linger} come valore logico (ignorandone il valore) per rendere
(quando diverso da zero) \func{close} e \func{shutdown} bloccanti fino al
completamento della trasmissione dei dati sul buffer.} pari al valore
\subsection{Le opzioni per il protocollo IPv4}
\label{sec:sock_ipv4_options}
-Il secondo insieme di opzioni dei socket che tratteremo è quello relativo ai
+Il secondo insieme di opzioni dei socket che tratteremo è quello relativo ai
socket che usano il protocollo IPv4.\footnote{come per le precedenti opzioni
- generiche una descrizione di esse è disponibile nella settima sezione delle
- pagine di manuale, nel caso specifico la documentazione si può consultare
+ generiche una descrizione di esse è disponibile nella settima sezione delle
+ pagine di manuale, nel caso specifico la documentazione si può consultare
con \texttt{man 7 ip}.} Se si vuole operare su queste opzioni generiche il
-livello da utilizzare è \const{SOL\_IP} (o l'equivalente \const{IPPROTO\_IP});
-si è riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_iplevel}.
+livello da utilizzare è \const{SOL\_IP} (o l'equivalente \const{IPPROTO\_IP});
+si è riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_iplevel}.
Le costanti indicanti le opzioni e tutte le altre costanti ad esse collegate
sono definite in \file{netinet/ip.h}, ed accessibili includendo detto file.
\end{table}
Le descrizioni riportate in tab.~\ref{tab:sock_opt_iplevel} sono estremamente
-succinte, una maggiore quantità di dettagli sulle varie opzioni è fornita nel
+succinte, una maggiore quantità di dettagli sulle varie opzioni è fornita nel
seguente elenco:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_PKTINFO} contenente
una struttura \struct{pktinfo} (vedi fig.~\ref{fig:sock_pktinfo_struct}) che
mantiene una serie di informazioni riguardo i pacchetti in arrivo. In
- particolare è possibile conoscere l'interfaccia su cui è stato ricevuto un
+ particolare è possibile conoscere l'interfaccia su cui è stato ricevuto un
pacchetto (nel campo \var{ipi\_ifindex}),\footnote{in questo campo viene
restituito il valore numerico dell'indice dell'interfaccia,
sez.~\ref{sec:sock_ioctl_netdevice}.} l'indirizzo locale da esso
\end{figure}
-L'opzione è utilizzabile solo per socket di tipo \const{SOCK\_DGRAM}. Questa è
-una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
+L'opzione è utilizzabile solo per socket di tipo \const{SOCK\_DGRAM}. Questa è
+una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
Linux;\footnote{non dovrebbe pertanto essere utilizzata se si ha a cuore la
- portabilità.} essa permette di sostituire le opzioni \const{IP\_RECVDSTADDR}
-e \const{IP\_RECVIF} presenti in altri Unix (la relativa informazione è quella
+ portabilità.} essa permette di sostituire le opzioni \const{IP\_RECVDSTADDR}
+e \const{IP\_RECVIF} presenti in altri Unix (la relativa informazione è quella
ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
\struct{pktinfo}).
L'opzione prende per \param{optval} un intero usato come valore logico, che
specifica soltanto se insieme al pacchetto deve anche essere inviato o
ricevuto il messaggio \const{IP\_PKTINFO} (vedi
-sez.~\ref{sec:net_ancillary_data}); il messaggio stesso dovrà poi essere
+sez.~\ref{sec:net_ancillary_data}); il messaggio stesso dovrà poi essere
letto o scritto direttamente con \func{recvmsg} e \func{sendmsg} (vedi
sez.~\ref{sec:net_sendmsg}).
sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_RECVTTL}, contenente
un byte con il valore del campo \textit{Time to Live} dell'intestazione IP
(vedi sez.~\ref{sec:IP_header}). L'opzione richiede per \param{optval} un
- intero usato come valore logico. L'opzione non è supportata per socket di
+ intero usato come valore logico. L'opzione non è supportata per socket di
tipo \const{SOCK\_STREAM}.
\item[\const{IP\_RECVOPTS}] Quando abilitata l'opzione permette di ricevere
insieme ai pacchetti un messaggio ancillare (vedi
sez.~\ref{sec:net_ancillary_data}) di tipo \const{IP\_OPTIONS}, contenente
le opzioni IP del protocollo (vedi sez.~\ref{sec:IP_options}). Le
- intestazioni di instradamento e le altre opzioni sono già riempite con i
+ intestazioni di instradamento e le altre opzioni sono già riempite con i
dati locali. L'opzione richiede per \param{optval} un intero usato come
- valore logico. L'opzione non è supportata per socket di tipo
+ valore logico. L'opzione non è supportata per socket di tipo
\const{SOCK\_STREAM}.
\item[\const{IP\_RETOPTS}] Identica alla precedente \const{IP\_RECVOPTS}, ma
in questo caso restituisce i dati grezzi delle opzioni, senza che siano
riempiti i capi di instradamento e le marche temporali. L'opzione richiede
- per \param{optval} un intero usato come valore logico. L'opzione non è
+ per \param{optval} un intero usato come valore logico. L'opzione non è
supportata per socket di tipo \const{SOCK\_STREAM}.
\item[\const{IP\_TOS}] L'opzione consente di leggere o impostare il campo
- \textit{Type of Service} dell'intestazione IP (per una trattazione più
+ \textit{Type of Service} dell'intestazione IP (per una trattazione più
dettagliata, che riporta anche i valori possibili e le relative costanti di
definizione si veda sez.~\ref{sec:IP_header}) che permette di indicare le
- priorità dei pacchetti. Se impostato il valore verrà mantenuto per tutti i
- pacchetti del socket; alcuni valori (quelli che aumentano la priorità)
+ priorità dei pacchetti. Se impostato il valore verrà mantenuto per tutti i
+ pacchetti del socket; alcuni valori (quelli che aumentano la priorità)
richiedono i privilegi di amministrazione con la \itindex{capabilities}
capability \const{CAP\_NET\_ADMIN}.
- Il campo TOS è di 8 bit e l'opzione richiede per \param{optval} un intero
+ Il campo TOS è di 8 bit e l'opzione richiede per \param{optval} un intero
che ne contenga il valore. Sono definite anche alcune costanti che
definiscono alcuni valori standardizzati per il \textit{Type of Service},
riportate in tab.~\ref{tab:IP_TOS_values}, il valore di default usato da
- Linux è \const{IPTOS\_LOWDELAY}, ma esso può essere modificato con le
- funzionalità del cosiddetto \textit{Advanced Routing}. Si ricordi che la
- priorità dei pacchetti può essere impostata anche in maniera indipendente
+ Linux è \const{IPTOS\_LOWDELAY}, ma esso può essere modificato con le
+ funzionalità del cosiddetto \textit{Advanced Routing}. Si ricordi che la
+ priorità dei pacchetti può essere impostata anche in maniera indipendente
dal protocollo utilizzando l'opzione \const{SO\_PRIORITY} illustrata in
sez.~\ref{sec:sock_generic_options}.
\item[\const{IP\_TTL}] L'opzione consente di leggere o impostare per tutti i
pacchetti associati al socket il campo \textit{Time to Live}
dell'intestazione IP che indica il numero massimo di \textit{hop} (passaggi
- da un router ad un altro) restanti al paccheto (per una trattazione più
- estesa si veda sez.~\ref{sec:IP_header}). Il campo TTL è di 8 bit e
- l'opzione richiede che \param{optval} sia un intero, che ne conterrà il
+ da un router ad un altro) restanti al paccheto (per una trattazione più
+ estesa si veda sez.~\ref{sec:IP_header}). Il campo TTL è di 8 bit e
+ l'opzione richiede che \param{optval} sia un intero, che ne conterrà il
valore.
\item[\const{IP\_MINTTL}] L'opzione, introdotta con il kernel 2.6.34, imposta
un valore minimo per il campo \textit{Time to Live} dei pacchetti associati
- al socket su cui è attivata, che se non rispettato ne causa lo scarto
- automatico. L'opzione è nata per implementare
+ al socket su cui è attivata, che se non rispettato ne causa lo scarto
+ automatico. L'opzione è nata per implementare
l'\href{http://www.ietf.org/rfc/rfc5082.txt}{RFC~5082} che la prevede come
- forma di protezione per i router che usano il protocollo BGP poiché questi,
+ forma di protezione per i router che usano il protocollo BGP poiché questi,
essendo in genere adiacenti, possono, impostando un valore di 255, scartare
automaticamente tutti gli eventuali pacchetti falsi creati da un attacco a
questo protocollo, senza doversi curare di verificarne la
- validità.\footnote{l'attacco viene in genere portato per causare un
+ validità.\footnote{l'attacco viene in genere portato per causare un
\textit{Denial of Service} aumentando il consumo di CPU del router nella
- verifica dell'autenticità di un gran numero di pacchetti di pacchetti
+ verifica dell'autenticità di un gran numero di pacchetti di pacchetti
falsi; questi, arrivando da sorgenti diverse da un router adiacente, non
- potrebbero più avere un TTL di 255 anche qualora questo fosse stato il
+ potrebbero più avere un TTL di 255 anche qualora questo fosse stato il
valore di partenza, e l'impostazione dell'opzione consente di scartarli
senza carico aggiuntivo sulla CPU (che altrimenti dovrebbe calcolare una
checksum).}
\item[\const{IP\_HDRINCL}] Se abilitata l'utente deve fornire lui stesso
- l'intestazione IP in cima ai propri dati. L'opzione è valida soltanto per
+ l'intestazione IP in cima ai propri dati. L'opzione è valida soltanto per
socket di tipo \const{SOCK\_RAW}, e quando utilizzata eventuali valori
impostati con \const{IP\_OPTIONS}, \const{IP\_TOS} o \const{IP\_TTL} sono
ignorati. In ogni caso prima della spedizione alcuni campi
dell'intestazione vengono comunque modificati dal kernel, torneremo
sull'argomento in sez.~\ref{sec:socket_raw}
-\item[\const{IP\_RECVERR}] Questa è una opzione introdotta con i kernel della
- serie 2.2.x, ed è specifica di Linux. Essa permette di usufruire di un
+\item[\const{IP\_RECVERR}] Questa è una opzione introdotta con i kernel della
+ serie 2.2.x, ed è specifica di Linux. Essa permette di usufruire di un
meccanismo affidabile per ottenere un maggior numero di informazioni in caso
- di errori. Se l'opzione è abilitata tutti gli errori generati su un socket
+ di errori. Se l'opzione è abilitata tutti gli errori generati su un socket
vengono memorizzati su una coda, dalla quale poi possono essere letti con
\func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) come messaggi ancillari
(torneremo su questo in sez.~\ref{sec:net_ancillary_data}) di tipo
\const{IP\_RECVERR}. L'opzione richiede per \param{optval} un intero usato
- come valore logico e non è applicabile a socket di tipo
+ come valore logico e non è applicabile a socket di tipo
\const{SOCK\_STREAM}.
\itindbeg{Maximum~Transfer~Unit}
-\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
- della serie 2.2.x, ed è specifica di Linux. L'opzione permette di scrivere
- o leggere le impostazioni della modalità usata per la determinazione della
+\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
+ della serie 2.2.x, ed è specifica di Linux. L'opzione permette di scrivere
+ o leggere le impostazioni della modalità usata per la determinazione della
\textit{Path Maximum Transfer Unit} (vedi sez.~\ref{sec:net_lim_dim}) del
socket. L'opzione prende per \param{optval} un valore intero che indica la
- modalità usata, da specificare con una delle costanti riportate in
+ modalità usata, da specificare con una delle costanti riportate in
tab.~\ref{tab:sock_ip_mtu_discover}.
\begin{table}[!htb]
\label{tab:sock_ip_mtu_discover}
\end{table}
- Il valore di default applicato ai socket di tipo \const{SOCK\_STREAM} è
+ Il valore di default applicato ai socket di tipo \const{SOCK\_STREAM} è
determinato dal parametro \texttt{ip\_no\_pmtu\_disc} (vedi
sez.~\ref{sec:sock_sysctl}), mentre per tutti gli altri socket di default la
- ricerca è disabilitata ed è responsabilità del programma creare pacchetti di
+ ricerca è disabilitata ed è responsabilità del programma creare pacchetti di
dimensioni appropriate e ritrasmettere eventuali pacchetti persi. Se
- l'opzione viene abilitata, il kernel si incaricherà di tenere traccia
+ l'opzione viene abilitata, il kernel si incaricherà di tenere traccia
automaticamente della \itindex{Maximum~Transfer~Unit} \textit{Path MTU}
- verso ciascuna destinazione, e rifiuterà immediatamente la trasmissione di
+ verso ciascuna destinazione, e rifiuterà immediatamente la trasmissione di
pacchetti di dimensioni maggiori della MTU con un errore di
\errval{EMSGSIZE}.\footnote{in caso contrario la trasmissione del pacchetto
sarebbe effettuata, ottenendo o un fallimento successivo della
\item[\const{IP\_MTU}] Permette di leggere il valore della \textit{Path MTU}
di percorso del socket. L'opzione richiede per \param{optval} un intero che
- conterrà il valore della \textit{Path MTU} in byte. Questa è una opzione
- introdotta con i kernel della serie 2.2.x, ed è specifica di Linux.
+ conterrà il valore della \textit{Path MTU} in byte. Questa è una opzione
+ introdotta con i kernel della serie 2.2.x, ed è specifica di Linux.
- È tramite questa opzione che un programma può leggere, quando si è avuto un
+ È tramite questa opzione che un programma può leggere, quando si è avuto un
errore di \errval{EMSGSIZE}, il valore della MTU corrente del socket. Si
tenga presente che per poter usare questa opzione, oltre ad avere abilitato
la scoperta della \textit{Path MTU}, occorre che il socket sia stato
esplicitamente connesso con \func{connect}.
- Ad esempio con i socket UDP si potrà ottenere una stima iniziale della
+ Ad esempio con i socket UDP si potrà ottenere una stima iniziale della
\itindex{Maximum~Transfer~Unit} \textit{Path MTU} eseguendo prima una
\func{connect} verso la destinazione, e poi usando \func{getsockopt} con
- questa opzione. Si può anche avviare esplicitamente il procedimento di
- scoperta inviando un pacchetto di grosse dimensioni (che verrà scartato) e
+ questa opzione. Si può anche avviare esplicitamente il procedimento di
+ scoperta inviando un pacchetto di grosse dimensioni (che verrà scartato) e
ripetendo l'invio coi dati aggiornati. Si tenga infine conto che durante il
- procedimento i pacchetti iniziali possono essere perduti, ed è compito
+ procedimento i pacchetti iniziali possono essere perduti, ed è compito
dell'applicazione gestirne una eventuale ritrasmissione.
\itindend{Maximum~Transfer~Unit}
-\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
- kernel della serie 2.2.x, ed è specifica di Linux. Prende per
+\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
+ kernel della serie 2.2.x, ed è specifica di Linux. Prende per
\param{optval} un intero usato come valore logico. Se abilitata
passa tutti i pacchetti con l'opzione \textit{IP Router Alert} (vedi
sez.~\ref{sec:IP_options}) che devono essere inoltrati al socket
- corrente. Può essere usata soltanto per socket di tipo raw.
+ corrente. Può essere usata soltanto per socket di tipo raw.
\itindbeg{multicast}
\item[\const{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il
valore del campo TTL per i pacchetti \textit{multicast} in uscita associati
- al socket. È importante che questo valore sia il più basso possibile, ed il
- default è 1, che significa che i pacchetti non potranno uscire dalla rete
+ al socket. È importante che questo valore sia il più basso possibile, ed il
+ default è 1, che significa che i pacchetti non potranno uscire dalla rete
locale. Questa opzione consente ai programmi che lo richiedono di superare
questo limite. L'opzione richiede per
- \param{optval} un intero che conterrà il valore del TTL.
+ \param{optval} un intero che conterrà il valore del TTL.
\item[\const{IP\_MULTICAST\_LOOP}] L'opzione consente di decidere se i dati
che si inviano su un socket usato con il \textit{multicast} vengano ricevuti
\param{optval} un intero usato come valore logico.
In generale se si vuole che eventuali client possano ricevere i dati che si
- inviano occorre che questa funzionalità sia abilitata (come avviene di
- default). Qualora però non si voglia generare traffico per dati che già sono
+ inviano occorre che questa funzionalità sia abilitata (come avviene di
+ default). Qualora però non si voglia generare traffico per dati che già sono
disponibili in locale l'uso di questa opzione permette di disabilitare
questo tipo di traffico.
\item[\const{IP\_ADD\_MEMBERSHIP}] L'opzione consente di unirsi ad gruppo di
- \textit{multicast}, e può essere usata solo con \func{setsockopt}.
+ \textit{multicast}, e può essere usata solo con \func{setsockopt}.
L'argomento \param{optval} in questo caso deve essere una struttura di tipo
\struct{ip\_mreqn}, illustrata in fig.~\ref{fig:ip_mreqn_struct}, che
permette di indicare, con il campo \var{imr\_multiaddr} l'indirizzo del
dell'interfaccia da utilizzare (un valore nullo indica una interfaccia
qualunque).
- Per compatibilità è possibile utilizzare anche un argomento di tipo
+ Per compatibilità è possibile utilizzare anche un argomento di tipo
\struct{ip\_mreq}, una precedente versione di \struct{ip\_mreqn}, che
differisce da essa soltanto per l'assenza del campo \var{imr\_ifindex}.
In questa sezione tratteremo le varie opzioni disponibili per i socket che
usano i due principali protocolli di comunicazione del livello di trasporto;
UDP e TCP.\footnote{come per le precedenti, una descrizione di queste opzioni
- è disponibile nella settima sezione delle pagine di manuale, che si può
+ è disponibile nella settima sezione delle pagine di manuale, che si può
consultare rispettivamente con \texttt{man 7 tcp} e \texttt{man 7 udp}; le
- pagine di manuale però, alla stesura di questa sezione (Agosto 2006) sono
+ pagine di manuale però, alla stesura di questa sezione (Agosto 2006) sono
alquanto incomplete.} Dato che questi due protocolli sono entrambi
trasportati su IP,\footnote{qui si sottintende IPv4, ma le opzioni per TCP e
UDP sono le stesse anche quando si usa IPv6.} oltre alle opzioni generiche
di sez.~\ref{sec:sock_generic_options} saranno comunque disponibili anche le
-precedenti opzioni di sez.~\ref{sec:sock_ipv4_options}.\footnote{in realtà in
+precedenti opzioni di sez.~\ref{sec:sock_ipv4_options}.\footnote{in realtà in
sez.~\ref{sec:sock_ipv4_options} si sono riportate le opzioni per IPv4, al
solito, qualora si stesse utilizzando IPv6, si potrebbero utilizzare le
opzioni di quest'ultimo.}
-Il protocollo che supporta il maggior numero di opzioni è TCP; per poterle
+Il protocollo che supporta il maggior numero di opzioni è TCP; per poterle
utilizzare occorre specificare \const{SOL\_TCP} (o l'equivalente
\const{IPPROTO\_TCP}) come valore per l'argomento \param{level}. Si sono
riportate le varie opzioni disponibili in tab.~\ref{tab:sock_opt_tcplevel},
dove sono elencate le rispettive costanti da utilizzare come valore per
l'argomento \param{optname}. Dette costanti e tutte le altre costanti e
strutture collegate all'uso delle opzioni TCP sono definite in
-\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
- questo è il file usato dalle librerie; la definizione delle opzioni
+\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
+ questo è il file usato dalle librerie; la definizione delle opzioni
effettivamente supportate da Linux si trova nel file \texttt{linux/tcp.h},
dal quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
\const{TCP\_INFO} &$\bullet$& & &\struct{tcp\_info}&
Restituisce informazioni sul socket.\\
\const{TCP\_QUICKACK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
- Abilita la modalità \textit{quickack}.\\
+ Abilita la modalità \textit{quickack}.\\
\const{TCP\_CONGESTION} &$\bullet$&$\bullet$& &\texttt{char *}&
Imposta l'algoritmo per il controllo della congestione.\\
\hline
Le descrizioni delle varie opzioni riportate in
tab.~\ref{tab:sock_opt_tcplevel} sono estremamente sintetiche ed indicative,
la spiegazione del funzionamento delle singole opzioni con una maggiore
-quantità di dettagli è fornita nel seguente elenco:
+quantità di dettagli è fornita nel seguente elenco:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{TCP\_NODELAY}] il protocollo TCP utilizza un meccanismo di
bufferizzazione dei dati uscenti, per evitare la trasmissione di tanti
piccoli segmenti con un utilizzo non ottimale della banda
- disponibile.\footnote{il problema è chiamato anche \textit{silly window
+ disponibile.\footnote{il problema è chiamato anche \textit{silly window
syndrome}, per averne un'idea si pensi al risultato che si ottiene
quando un programma di terminale invia un segmento TCP per ogni tasto
premuto, 40 byte di intestazione di protocollo con 1 byte di dati
- trasmessi; per evitare situazioni del genere è stato introdotto
+ trasmessi; per evitare situazioni del genere è stato introdotto
\index{algoritmo~di~Nagle} l'\textsl{algoritmo di Nagle}.} Questo
- meccanismo è controllato da un apposito algoritmo (detto
+ meccanismo è controllato da un apposito algoritmo (detto
\index{algoritmo~di~Nagle} \textsl{algoritmo di Nagle}, vedi
sez.~\ref{sec:tcp_protocol_xxx}). Il comportamento normale del protocollo
prevede che i dati siano accumulati fintanto che non si raggiunge una
- quantità considerata adeguata per eseguire la trasmissione di un singolo
+ quantità considerata adeguata per eseguire la trasmissione di un singolo
segmento.
- Ci sono però delle situazioni in cui questo comportamento può non essere
- desiderabile, ad esempio quando si sa in anticipo che l'applicazione invierà
- soltanto un piccolo quantitativo di dati;\footnote{è il caso classico di una
+ Ci sono però delle situazioni in cui questo comportamento può non essere
+ desiderabile, ad esempio quando si sa in anticipo che l'applicazione invierà
+ soltanto un piccolo quantitativo di dati;\footnote{è il caso classico di una
richiesta HTTP.} in tal caso l'attesa introdotta dall'algoritmo di
- bufferizzazione non soltanto è inutile, ma peggiora le prestazioni
+ bufferizzazione non soltanto è inutile, ma peggiora le prestazioni
introducendo un ritardo. Impostando questa opzione si disabilita l'uso
\index{algoritmo~di~Nagle} dell'\textsl{algoritmo di Nagle} ed i dati
vengono inviati immediatamente in singoli segmenti, qualunque sia la loro
- dimensione. Ovviamente l'uso di questa opzione è dedicato a chi ha esigenze
+ dimensione. Ovviamente l'uso di questa opzione è dedicato a chi ha esigenze
particolari come quella illustrata, che possono essere stabilite solo per la
singola applicazione.
Si tenga conto che questa opzione viene sovrascritta dall'eventuale
- impostazione dell'opzione \const{TCP\_CORK} (il cui scopo è sostanzialmente
+ impostazione dell'opzione \const{TCP\_CORK} (il cui scopo è sostanzialmente
l'opposto) che blocca l'invio immediato. Tuttavia quando la si abilita viene
sempre forzato lo scaricamento della coda di invio (con conseguente
- trasmissione di tutti i dati pendenti), anche qualora si fosse già abilitata
- \const{TCP\_CORK}.\footnote{si tenga presente però che \const{TCP\_CORK} può
+ trasmissione di tutti i dati pendenti), anche qualora si fosse già abilitata
+ \const{TCP\_CORK}.\footnote{si tenga presente però che \const{TCP\_CORK} può
essere specificata insieme a \const{TCP\_NODELAY} soltanto a partire dal
kernel 2.5.71.}
\item[\const{TCP\_MAXSEG}] con questa opzione si legge o si imposta il valore
della \itindex{Maximum~Segment~Size} MSS (\textit{Maximum~Segment~Size},
vedi sez.~\ref{sec:net_lim_dim} e sez.~\ref{sec:tcp_protocol_xxx}) dei
- segmenti TCP uscenti. Se l'opzione è impostata prima di stabilire la
+ segmenti TCP uscenti. Se l'opzione è impostata prima di stabilire la
connessione, si cambia anche il valore della \itindex{Maximum~Segment~Size}
MSS annunciata all'altro capo della connessione. Se si specificano valori
maggiori della \itindex{Maximum~Transfer~Unit} MTU questi verranno ignorati,
- inoltre TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
+ inoltre TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
-\item[\const{TCP\_CORK}] questa opzione è il complemento naturale di
+\item[\const{TCP\_CORK}] questa opzione è il complemento naturale di
\const{TCP\_NODELAY} e serve a gestire a livello applicativo la situazione
- opposta, cioè quella in cui si sa fin dal principio che si dovranno inviare
- grosse quantità di dati. Anche in questo caso \index{algoritmo~di~Nagle}
- l'\textsl{algoritmo di Nagle} tenderà a suddividerli in dimensioni da lui
+ opposta, cioè quella in cui si sa fin dal principio che si dovranno inviare
+ grosse quantità di dati. Anche in questo caso \index{algoritmo~di~Nagle}
+ l'\textsl{algoritmo di Nagle} tenderà a suddividerli in dimensioni da lui
ritenute opportune,\footnote{l'algoritmo cerca di tenere conto di queste
- situazioni, ma essendo un algoritmo generico tenderà comunque ad
+ situazioni, ma essendo un algoritmo generico tenderà comunque ad
introdurre delle suddivisioni in segmenti diversi, anche quando potrebbero
non essere necessarie, con conseguente spreco di banda.} ma sapendo fin
- dall'inizio quale è la dimensione dei dati si potranno di nuovo ottenere
+ dall'inizio quale è la dimensione dei dati si potranno di nuovo ottenere
delle migliori prestazioni disabilitandolo, e gestendo direttamente l'invio
del nostro blocco di dati in soluzione unica.
Quando questa opzione viene abilitata non vengono inviati segmenti di dati
fintanto che essa non venga disabilitata; a quel punto tutti i dati rimasti
in coda saranno inviati in un solo segmento TCP. In sostanza con questa
- opzione si può controllare il flusso dei dati mettendo una sorta di
+ opzione si può controllare il flusso dei dati mettendo una sorta di
``\textsl{tappo}'' (da cui il nome in inglese) al flusso di uscita, in modo
ottimizzare a mano l'uso della banda. Si tenga presente che per l'effettivo
funzionamento ci si deve ricordare di disattivare l'opzione al termine
notevole penalizzazione delle prestazioni.
Si tenga presente che l'implementazione corrente di \const{TCP\_CORK} non
- consente di bloccare l'invio dei dati per più di 200 millisecondi, passati i
- quali i dati accumulati in coda sanno inviati comunque. Questa opzione è
- tipica di Linux\footnote{l'opzione è stata introdotta con i kernel della
- serie 2.4.x.} e non è disponibile su tutti i kernel unix-like, pertanto
+ consente di bloccare l'invio dei dati per più di 200 millisecondi, passati i
+ quali i dati accumulati in coda sanno inviati comunque. Questa opzione è
+ tipica di Linux\footnote{l'opzione è stata introdotta con i kernel della
+ serie 2.4.x.} e non è disponibile su tutti i kernel unix-like, pertanto
deve essere evitata se si vuole scrivere codice portabile.
\item[\const{TCP\_KEEPIDLE}] con questa opzione si legge o si imposta
socket prima che vengano inviati, qualora si sia attivata su di esso
l'opzione \const{SO\_KEEPALIVE}, i messaggi di \textit{keep-alive} (si veda
la trattazione relativa al \textit{keep-alive} in
- sez.~\ref{sec:sock_options_main}). Anche questa opzione non è disponibile
+ sez.~\ref{sec:sock_options_main}). Anche questa opzione non è disponibile
su tutti i kernel unix-like e deve essere evitata se si vuole scrivere
codice portabile.
\item[\const{TCP\_KEEPINTVL}] con questa opzione si legge o si imposta
l'intervallo di tempo, in secondi, fra due messaggi di \textit{keep-alive}
successivi (si veda sempre quanto illustrato in
- sez.~\ref{sec:sock_options_main}). Come la precedente non è disponibile su
+ sez.~\ref{sec:sock_options_main}). Come la precedente non è disponibile su
tutti i kernel unix-like e deve essere evitata se si vuole scrivere codice
portabile.
\item[\const{TCP\_KEEPCNT}] con questa opzione si legge o si imposta il numero
totale di messaggi di \textit{keep-alive} da inviare prima di concludere che
- la connessione è caduta per assenza di risposte ad un messaggio di
+ la connessione è caduta per assenza di risposte ad un messaggio di
\textit{keep-alive} (di nuovo vedi sez.~\ref{sec:sock_options_main}). Come
- la precedente non è disponibile su tutti i kernel unix-like e deve essere
+ la precedente non è disponibile su tutti i kernel unix-like e deve essere
evitata se si vuole scrivere codice portabile.
\item[\const{TCP\_SYNCNT}] con questa opzione si legge o si imposta il numero
sez.~\ref{sec:TCP_func_connect}). Sovrascrive per il singolo socket il valore
globale impostato con la \textit{sysctl} \texttt{tcp\_syn\_retries} (vedi
sez.~\ref{sec:sock_ipv4_sysctl}). Non vengono accettati valori maggiori di
- 255; anche questa opzione non è standard e deve essere evitata se si vuole
+ 255; anche questa opzione non è standard e deve essere evitata se si vuole
scrivere codice portabile.
\item[\const{TCP\_LINGER2}] con questa opzione si legge o si imposta, in
abbiamo visto in sez.~\ref{sec:sock_options_main}.} Questa opzione
consente di sovrascrivere per il singolo socket il valore globale impostato
con la \textit{sysctl} \texttt{tcp\_fin\_timeout} (vedi
- sez.~\ref{sec:sock_ipv4_sysctl}). Anche questa opzione è da evitare se si
- ha a cuore la portabilità del codice.
+ sez.~\ref{sec:sock_ipv4_sysctl}). Anche questa opzione è da evitare se si
+ ha a cuore la portabilità del codice.
\item[\const{TCP\_DEFER\_ACCEPT}] questa opzione consente di modificare il
comportamento standard del protocollo TCP nello stabilirsi di una
connessione; se ricordiamo il meccanismo del \itindex{three~way~handshake}
\textit{three way handshake} illustrato in fig.~\ref{fig:TCP_TWH} possiamo
- vedere che in genere un client inizierà ad inviare i dati ad un server solo
+ vedere che in genere un client inizierà ad inviare i dati ad un server solo
dopo l'emissione dell'ultimo segmento di ACK.
- Di nuovo esistono situazioni (e la più tipica è quella di una richiesta
+ Di nuovo esistono situazioni (e la più tipica è quella di una richiesta
HTTP) in cui sarebbe utile inviare immediatamente la richiesta all'interno
del segmento con l'ultimo ACK del \itindex{three~way~handshake}
- \textit{three way handshake}; si potrebbe così risparmiare l'invio di un
+ \textit{three way handshake}; si potrebbe così risparmiare l'invio di un
segmento successivo per la richiesta e il ritardo sul server fra la
ricezione dell'ACK e quello della richiesta.
- Se si invoca \const{TCP\_DEFER\_ACCEPT} su un socket dal lato client (cioè
+ Se si invoca \const{TCP\_DEFER\_ACCEPT} su un socket dal lato client (cioè
dal lato da cui si invoca \func{connect}) si istruisce il kernel a non
inviare immediatamente l'ACK finale del \itindex{three~way~handshake}
\textit{three way handshake}, attendendo per un po' di tempo la prima
Allo stesso tempo il protocollo TCP prevede che sul lato del server la
funzione \func{accept} ritorni dopo la ricezione dell'ACK finale, in tal
- caso quello che si fa usualmente è lanciare un nuovo processo per leggere i
- successivi dati, che si bloccherà su una \func{read} se questi non sono
+ caso quello che si fa usualmente è lanciare un nuovo processo per leggere i
+ successivi dati, che si bloccherà su una \func{read} se questi non sono
disponibili; in questo modo si saranno impiegate delle risorse (per la
creazione del nuovo processo) che non vengono usate immediatamente. L'uso
di \const{TCP\_DEFER\_ACCEPT} consente di intervenire anche in questa
situazione; quando la si invoca sul lato server (vale a dire su un socket in
- ascolto) l'opzione fa sì che \func{accept} ritorni soltanto quando sono
+ ascolto) l'opzione fa sì che \func{accept} ritorni soltanto quando sono
presenti dei dati sul socket, e non alla ricezione dell'ACK conclusivo del
\itindex{three~way~handshake} \textit{three way handshake}.
L'opzione prende un valore intero che indica il numero massimo di secondi
per cui mantenere il ritardo, sia per quanto riguarda il ritorno di
\func{accept} su un server, che per l'invio dell'ACK finale insieme ai dati
- su un client. L'opzione è specifica di Linux non deve essere utilizzata in
- codice che vuole essere portabile.\footnote{su FreeBSD è presente una
+ su un client. L'opzione è specifica di Linux non deve essere utilizzata in
+ codice che vuole essere portabile.\footnote{su FreeBSD è presente una
opzione \texttt{SO\_ACCEPTFILTER} che consente di ottenere lo stesso
comportamento di \const{TCP\_DEFER\_ACCEPT} per quanto riguarda il lato
server.}
anche in altri kernel (ad esempio FreeBSD) permette di controllare lo stato
interno di un socket TCP direttamente da un programma in user space.
L'opzione restituisce in una speciale struttura \struct{tcp\_info}, la cui
- definizione è riportata in fig.~\ref{fig:tcp_info_struct}, tutta una serie
+ definizione è riportata in fig.~\ref{fig:tcp_info_struct}, tutta una serie
di dati che il kernel mantiene, relativi al socket. Anche questa opzione
deve essere evitata se si vuole scrivere codice portabile.
Con questa opzione diventa possibile ricevere una serie di informazioni
- relative ad un socket TCP così da poter effettuare dei controlli senza dover
- passare attraverso delle operazioni di lettura. Ad esempio si può verificare
- se un socket è stato chiuso usando una funzione analoga a quella illustrata
+ relative ad un socket TCP così da poter effettuare dei controlli senza dover
+ passare attraverso delle operazioni di lettura. Ad esempio si può verificare
+ se un socket è stato chiuso usando una funzione analoga a quella illustrata
in fig.~\ref{fig:is_closing}, in cui si utilizza il valore del campo
\var{tcpi\_state} di \struct{tcp\_info} per controllare lo stato del socket.
%Si noti come nell'esempio si sia (
-\item[\const{TCP\_QUICKACK}] con questa opzione è possibile eseguire una forma
+\item[\const{TCP\_QUICKACK}] con questa opzione è possibile eseguire una forma
di controllo sull'invio dei segmenti ACK all'interno di in flusso di dati su
TCP. In genere questo invio viene gestito direttamente dal kernel, il
comportamento standard, corrispondente la valore logico di vero (in genere
- 1) per questa opzione, è quello di inviare immediatamente i segmenti ACK, in
- quanto normalmente questo significa che si è ricevuto un blocco di dati e si
- può passare all'elaborazione del blocco successivo.
+ 1) per questa opzione, è quello di inviare immediatamente i segmenti ACK, in
+ quanto normalmente questo significa che si è ricevuto un blocco di dati e si
+ può passare all'elaborazione del blocco successivo.
- Qualora però la nostra applicazione sappia in anticipo che alla ricezione di
- un blocco di dati seguirà immediatamente l'invio di un altro
+ Qualora però la nostra applicazione sappia in anticipo che alla ricezione di
+ un blocco di dati seguirà immediatamente l'invio di un altro
blocco,\footnote{caso tipico ad esempio delle risposte alle richieste HTTP.}
poter accorpare quest'ultimo al segmento ACK permette di risparmiare sia in
- termini di dati inviati che di velocità di risposta. Per far questo si può
- utilizzare \const{TCP\_QUICKACK} impostando un valore logico falso (cioè 0),
- in questo modo il kernel attenderà così da inviare il prossimo segmento di
+ termini di dati inviati che di velocità di risposta. Per far questo si può
+ utilizzare \const{TCP\_QUICKACK} impostando un valore logico falso (cioè 0),
+ in questo modo il kernel attenderà così da inviare il prossimo segmento di
ACK insieme ai primi dati disponibili.
- Si tenga presente che l'opzione non è permanente, vale a dire che una volta
- che la si sia impostata a 0 il kernel la riporterà al valore di default dopo
- il suo primo utilizzo. Sul lato server la si può impostare anche una volta
- sola su un socket in ascolto, ed essa verrà ereditata da tutti i socket che
+ Si tenga presente che l'opzione non è permanente, vale a dire che una volta
+ che la si sia impostata a 0 il kernel la riporterà al valore di default dopo
+ il suo primo utilizzo. Sul lato server la si può impostare anche una volta
+ sola su un socket in ascolto, ed essa verrà ereditata da tutti i socket che
si otterranno da esso al ritorno di \func{accept}.
% TODO trattare con gli esempi di apache
\item[\const{TCP\_CONGESTION}] questa opzione permette di impostare quale
algoritmo per il controllo della congestione\footnote{il controllo della
- congestione è un meccanismo previsto dal protocollo TCP (vedi
+ congestione è un meccanismo previsto dal protocollo TCP (vedi
sez.~\ref{sec:tcp_protocol_xxx}) per evitare di trasmettere inutilmente
- dati quando una connessione è congestionata; un buon algoritmo è
+ dati quando una connessione è congestionata; un buon algoritmo è
fondamentale per il funzionamento del protocollo, dato che i pacchetti
persi andrebbero ritrasmessi, per cui inviare un pacchetto su una linea
congestionata potrebbe causare facilmente un peggioramento della
- situazione.} utilizzare per il singolo socket. L'opzione è stata
+ situazione.} utilizzare per il singolo socket. L'opzione è stata
introdotta con il kernel 2.6.13,\footnote{alla data di stesura di queste
- note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
+ note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
definita nelle intestazioni delle \acr{glibc} per cui occorre definirla a
- mano al suo valore che è 13.} e prende come per \param{optval} il
+ mano al suo valore che è 13.} e prende come per \param{optval} il
puntatore ad un buffer contenente il nome dell'algoritmo di controllo che
si vuole usare.
- L'uso di un nome anziché di un valore numerico è dovuto al fatto che gli
+ L'uso di un nome anziché di un valore numerico è dovuto al fatto che gli
algoritmi di controllo della congestione sono realizzati attraverso
altrettanti moduli del kernel, e possono pertanto essere attivati a
richiesta; il nome consente di caricare il rispettivo modulo e di introdurre
moduli aggiuntivi che implementino altri meccanismi.
- Per poter disporre di questa funzionalità occorre aver compilato il kernel
+ Per poter disporre di questa funzionalità occorre aver compilato il kernel
attivando l'opzione di configurazione generale
\texttt{TCP\_CONG\_ADVANCED},\footnote{disponibile come \textit{TCP:
- advanced congestion control} nel menù \textit{Network->Networking
- options}, che a sua volta renderà disponibile un ulteriore menù con gli
+ advanced congestion control} nel menù \textit{Network->Networking
+ options}, che a sua volta renderà disponibile un ulteriore menù con gli
algoritmi presenti.} e poi abilitare i singoli moduli voluti con le varie
\texttt{TCP\_CONG\_*} presenti per i vari algoritmi disponibili; un elenco
- di quelli attualmente supportati nella versione ufficiale del kernel è
- riportato in tab.~\ref{tab:sock_tcp_congestion_algo}.\footnote{la lista è
+ di quelli attualmente supportati nella versione ufficiale del kernel è
+ riportato in tab.~\ref{tab:sock_tcp_congestion_algo}.\footnote{la lista è
presa dalla versione 2.6.17.}
Si tenga presente che prima della implementazione modulare alcuni di questi
algoritmi erano disponibili soltanto come caratteristiche generali del
- sistema, attivabili per tutti i socket, questo è ancora possibile con la
+ sistema, attivabili per tutti i socket, questo è ancora possibile con la
\textit{sysctl} \texttt{tcp\_congestion\_control} (vedi
sez.~\ref{sec:sock_ipv4_sysctl}) che ha sostituito le precedenti
\textit{sysctl}.\footnote{riportate anche, alla data di stesura di queste
- pagine (Set. 2006) nelle pagine di manuale, ma non più presenti.}
+ pagine (Set. 2006) nelle pagine di manuale, ma non più presenti.}
\begin{table}[!htb]
\centering
\end{basedescript}
-Il protocollo UDP, anche per la sua maggiore semplicità, supporta un numero
+Il protocollo UDP, anche per la sua maggiore semplicità, supporta un numero
ridotto di opzioni, riportate in tab.~\ref{tab:sock_opt_udplevel}; anche in
-questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
-l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
+questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
+l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
\const{IPPROTO\_UDP}). Le costanti che identificano dette opzioni sono
definite in \file{netinet/udp.h}, ed accessibili includendo detto
file.\footnote{come per TCP, la definizione delle opzioni effettivamente
- supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
+ supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_udplevel}.}
\begin{table}[!htb]
% TODO documentare \const{UDP\_ENCAP}
Ancora una volta le descrizioni contenute tab.~\ref{tab:sock_opt_udplevel}
-sono un semplice riferimento, una maggiore quantità di dettagli sulle
-caratteristiche delle opzioni citate è quello dell'elenco seguente:
+sono un semplice riferimento, una maggiore quantità di dettagli sulle
+caratteristiche delle opzioni citate è quello dell'elenco seguente:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{UDP\_CORK}] questa opzione ha l'identico effetto dell'analoga
\const{TCP\_CORK} vista in precedenza per il protocollo TCP, e quando
abilitata consente di accumulare i dati in uscita su un solo pacchetto che
- verrà inviato una volta che la si disabiliti. L'opzione è stata introdotta
+ verrà inviato una volta che la si disabiliti. L'opzione è stata introdotta
con il kernel 2.5.44, e non deve essere utilizzata in codice che vuole
essere portabile.
\item[\const{UDP\_ENCAP}] Questa opzione permette di gestire l'incapsulazione
- dei dati nel protocollo UDP. L'opzione è stata introdotta con il kernel
- 2.5.67, e non è documentata. Come la precedente è specifica di Linux e non
+ dei dati nel protocollo UDP. L'opzione è stata introdotta con il kernel
+ 2.5.67, e non è documentata. Come la precedente è specifica di Linux e non
deve essere utilizzata in codice portabile.
\end{basedescript}
\section{La gestione attraverso le funzioni di controllo}
\label{sec:sock_ctrl_func}
-Benché la maggior parte delle caratteristiche dei socket sia gestibile con le
-funzioni \func{setsockopt} e \func{getsockopt}, alcune proprietà possono
-essere impostate attraverso le funzioni \func{fcntl} e \func{ioctl} già
+Benché la maggior parte delle caratteristiche dei socket sia gestibile con le
+funzioni \func{setsockopt} e \func{getsockopt}, alcune proprietà possono
+essere impostate attraverso le funzioni \func{fcntl} e \func{ioctl} già
trattate in sez.~\ref{sec:file_fcntl} e sez.~\ref{sec:file_ioctl}; in
quell'occasione abbiamo parlato di queste funzioni esclusivamente nell'ambito
della loro applicazione a file descriptor associati a dei file normali; qui
Tratteremo in questa sezione le caratteristiche specifiche delle funzioni
\func{ioctl} e \func{fcntl} quando esse vengono utilizzate con dei socket
-generici. Quanto già detto in precedenza in sez.~\ref{sec:file_fcntl} e
+generici. Quanto già detto in precedenza in sez.~\ref{sec:file_fcntl} e
sez.~\ref{sec:file_ioctl} continua a valere; quello che tratteremo qui sono le
operazioni ed i comandi che sono validi, o che hanno significati peculiari,
quando queste funzioni vengono applicate a dei socket generici.
-Nell'elenco seguente si riportano i valori specifici che può assumere il
+Nell'elenco seguente si riportano i valori specifici che può assumere il
secondo argomento della funzione \func{ioctl} (\param{request}, che indica il
tipo di operazione da effettuare) quando essa viene applicata ad un socket
-generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
+generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
dato usato come terzo argomento della funzione ed il significato che esso
viene ad assumere. Dato che in caso di lettura questi dati vengono restituiti
come \itindex{value~result~argument} \textit{value result argument}, con
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{SIOCGSTAMP}] restituisce il contenuto di una struttura
\struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
- socket, questa operazione può essere utilizzata per effettuare delle
+ socket, questa operazione può essere utilizzata per effettuare delle
misurazioni precise del tempo di andata e ritorno\footnote{il
- \itindex{Round~Trip~Time} \textit{Round Trip Time} cui abbiamo già
+ \itindex{Round~Trip~Time} \textit{Round Trip Time} cui abbiamo già
accennato in sez.~\ref{sec:net_tcp}.} dei pacchetti sulla rete.
\item[\const{SIOCSPGRP}] imposta il processo o il \itindex{process~group}
\type{pid\_t}; un valore positivo indica direttamente il \acr{pid} del
processo, mentre un valore negativo indica (col valore assoluto) il
\textit{process group}. Senza privilegi di amministratore o la capability
- \const{CAP\_KILL} si può impostare solo se stessi o il proprio
+ \const{CAP\_KILL} si può impostare solo se stessi o il proprio
\textit{process group}.
\item[\const{SIOCGPGRP}] legge le impostazioni presenti sul socket
\textit{process group} cui devono essere inviati i segnali \const{SIGIO} e
\const{SIGURG}. Come per \const{SIOCSPGRP} l'argomento passato deve un
puntatore ad una variabile di tipo \type{pid\_t}, con lo stesso significato.
- Qualora non sia presente nessuna impostazione verrà restituito un valore
+ Qualora non sia presente nessuna impostazione verrà restituito un valore
nullo.
-\item[\const{FIOASYNC}] Abilita o disabilita la modalità di I/O asincrono sul
+\item[\const{FIOASYNC}] Abilita o disabilita la modalità di I/O asincrono sul
socket. Questo significa (vedi sez.~\ref{sec:file_asyncronous_operation})
- che verrà inviato il segnale di \const{SIGIO} (o quanto impostato con
+ che verrà inviato il segnale di \const{SIGIO} (o quanto impostato con
\const{F\_SETSIG}, vedi sez.~\ref{sec:file_fcntl}) in caso di eventi di I/O
sul socket.
\end{basedescript}
Nel caso dei socket generici anche \func{fcntl} prevede un paio di comandi
specifici; in questo caso il secondo argomento (\param{cmd}, che indica il
-comando) può assumere i due valori \const{FIOGETOWN} e \const{FIOSETOWN},
-mentre il terzo argomento dovrà essere un puntatore ad una variabile di tipo
-\type{pid\_t}. Questi due comandi sono una modalità alternativa di eseguire le
+comando) può assumere i due valori \const{FIOGETOWN} e \const{FIOSETOWN},
+mentre il terzo argomento dovrà essere un puntatore ad una variabile di tipo
+\type{pid\_t}. Questi due comandi sono una modalità alternativa di eseguire le
stesse operazioni (lettura o impostazione del processo o del gruppo di
processo che riceve i segnali) che si effettuano chiamando \func{ioctl} con
\const{SIOCGPGRP} e \const{SIOCSPGRP}.
\subsection{L'uso di \func{ioctl} per l'accesso ai dispositivi di rete}
\label{sec:sock_ioctl_netdevice}
-Benché non strettamente attinenti alla gestione dei socket, vale la pena di
+Benché non strettamente attinenti alla gestione dei socket, vale la pena di
trattare qui l'interfaccia di accesso a basso livello ai dispositivi di rete
-che viene appunto fornita attraverso la funzione \texttt{ioctl}. Questa non è
+che viene appunto fornita attraverso la funzione \texttt{ioctl}. Questa non è
attinente a caratteristiche specifiche di un qualche protocollo, ma si applica
a tutti i socket, indipendentemente da tipo e famiglia degli stessi, e
-permette di impostare e rilevare le funzionalità delle interfacce di rete.
+permette di impostare e rilevare le funzionalità delle interfacce di rete.
\begin{figure}[!htb]
\footnotesize \centering
Tutte le operazioni di questo tipo utilizzano come terzo argomento di
\func{ioctl} il puntatore ad una struttura \struct{ifreq}, la cui definizione
-è illustrata in fig.~\ref{fig:netdevice_ifreq_struct}. Normalmente si utilizza
+è illustrata in fig.~\ref{fig:netdevice_ifreq_struct}. Normalmente si utilizza
il primo campo della struttura, \var{ifr\_name} per specificare il nome
dell'interfaccia su cui si vuole operare (ad esempio \texttt{eth0},
\texttt{ppp0}, ecc.), e si inseriscono (o ricevono) i valori relativi alle
-diversa caratteristiche e funzionalità nel secondo campo, che come si può
-notare è definito come una \ctyp{union} proprio in quanto il suo significato
+diversa caratteristiche e funzionalità nel secondo campo, che come si può
+notare è definito come una \ctyp{union} proprio in quanto il suo significato
varia a secondo dell'operazione scelta.
Si tenga inoltre presente che alcune di queste operazioni (in particolare
quelle che modificano le caratteristiche dell'interfaccia) sono privilegiate e
richiedono i privilegi di amministratore o la \itindex{capabilities}
-\textit{capability} \const{CAP\_NET\_ADMIN}, altrimenti si otterrà un errore
+\textit{capability} \const{CAP\_NET\_ADMIN}, altrimenti si otterrà un errore
di \errval{EPERM}. Le costanti che identificano le operazioni disponibili
sono le seguenti:
\begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{SIOCGIFNAME}] questa è l'unica operazione che usa il campo
+\item[\const{SIOCGIFNAME}] questa è l'unica operazione che usa il campo
\var{ifr\_name} per restituire un risultato, tutte le altre lo utilizzano
per indicare l'interfaccia sulla quale operare. L'operazione richiede che si
indichi nel campo \var{ifr\_ifindex} il valore numerico dell'\textsl{indice}
dell'interfaccia, e restituisce il relativo nome in \var{ifr\_name}.
Il kernel infatti assegna ad ogni interfaccia un numero progressivo, detto
- appunto \itindex{interface~index} \textit{interface index}, che è quello che
+ appunto \itindex{interface~index} \textit{interface index}, che è quello che
effettivamente la identifica nelle operazioni a basso livello, il nome
- dell'interfaccia è soltanto una etichetta associata a detto \textsl{indice},
- che permette di rendere più comprensibile l'indicazione dell'interfaccia
- all'interno dei comandi. Una modalità per ottenere questo valore è usare il
+ dell'interfaccia è soltanto una etichetta associata a detto \textsl{indice},
+ che permette di rendere più comprensibile l'indicazione dell'interfaccia
+ all'interno dei comandi. Una modalità per ottenere questo valore è usare il
comando \cmd{ip link}, che fornisce un elenco delle interfacce presenti
ordinato in base a tale valore (riportato come primo campo).
\item[\const{SIOCGIFINDEX}] restituisce nel campo \var{ifr\_ifindex} il valore
- numerico dell'indice dell'interfaccia specificata con \var{ifr\_name}, è in
+ numerico dell'indice dell'interfaccia specificata con \var{ifr\_name}, è in
sostanza l'operazione inversa di \const{SIOCGIFNAME}.
\item[\const{SIOCGIFFLAGS}] permette di ottenere nel campo \var{ifr\_flags} il
valore corrente dei flag dell'interfaccia specificata (con \var{ifr\_name}).
- Il valore restituito è una maschera binaria i cui bit sono identificabili
+ Il valore restituito è una maschera binaria i cui bit sono identificabili
attraverso le varie costanti di tab.~\ref{tab:netdevice_iface_flag}.
\begin{table}[htb]
\textbf{Flag} & \textbf{Significato} \\
\hline
\hline
- \const{IFF\_UP} & L'interfaccia è attiva.\\
+ \const{IFF\_UP} & L'interfaccia è attiva.\\
\const{IFF\_BROADCAST} & L'interfaccia ha impostato un indirizzo di
\itindex{broadcast} \textit{broadcast} valido.\\
- \const{IFF\_DEBUG} & È attivo il flag interno di debug.\\
- \const{IFF\_LOOPBACK} & L'interfaccia è una interfaccia di
+ \const{IFF\_DEBUG} & È attivo il flag interno di debug.\\
+ \const{IFF\_LOOPBACK} & L'interfaccia è una interfaccia di
\textit{loopback}.\\
- \const{IFF\_POINTOPOINT}&L'interfaccia è associata ad un collegamento
+ \const{IFF\_POINTOPOINT}&L'interfaccia è associata ad un collegamento
\textsl{punto-punto}.\\
- \const{IFF\_RUNNING} & L'interfaccia ha delle risorse allocate (non può
+ \const{IFF\_RUNNING} & L'interfaccia ha delle risorse allocate (non può
quindi essere disattivata).\\
\const{IFF\_NOARP} & L'interfaccia ha il protocollo ARP disabilitato o
- l'indirizzo del livello di rete non è impostato.\\
- \const{IFF\_PROMISC} & L'interfaccia è in \index{modo~promiscuo}
- \textsl{modo promiscuo} (riceve cioè tutti i
+ l'indirizzo del livello di rete non è impostato.\\
+ \const{IFF\_PROMISC} & L'interfaccia è in \index{modo~promiscuo}
+ \textsl{modo promiscuo} (riceve cioè tutti i
pacchetti che vede passare, compresi quelli non
direttamente indirizzati a lei).\\
\const{IFF\_NOTRAILERS}& Evita l'uso di \textit{trailer} nei pacchetti.\\
\const{IFF\_ALLMULTI} & Riceve tutti i pacchetti di \itindex{multicast}
\textit{multicast}.\\
- \const{IFF\_MASTER} & L'interfaccia è il master di un bundle per il
+ \const{IFF\_MASTER} & L'interfaccia è il master di un bundle per il
bilanciamento di carico.\\
- \const{IFF\_SLAVE} & L'interfaccia è uno slave di un bundle per il
+ \const{IFF\_SLAVE} & L'interfaccia è uno slave di un bundle per il
bilanciamento di carico.\\
\const{IFF\_MULTICAST} & L'interfaccia ha il supporto per il
\textit{multicast} \itindex{multicast} attivo.\\
- \const{IFF\_PORTSEL} & L'interfaccia può impostare i suoi parametri
+ \const{IFF\_PORTSEL} & L'interfaccia può impostare i suoi parametri
hardware (con l'uso di \struct{ifmap}).\\
- \const{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare
+ \const{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare
automaticamente il tipo di collegamento.\\
\const{IFF\_DYNAMIC} & Gli indirizzi assegnati all'interfaccia vengono
persi quando questa viene disattivata.\\
\item[\const{SIOCSIFFLAGS}] permette di impostare il valore dei flag
dell'interfaccia specificata (sempre con \var{ifr\_name}, non staremo a
ripeterlo oltre) attraverso il valore della maschera binaria da passare nel
- campo \var{ifr\_flags}, che può essere ottenuta con l'OR aritmetico delle
- costanti di tab.~\ref{tab:netdevice_iface_flag}; questa operazione è
+ campo \var{ifr\_flags}, che può essere ottenuta con l'OR aritmetico delle
+ costanti di tab.~\ref{tab:netdevice_iface_flag}; questa operazione è
privilegiata.
\item[\const{SIOCGIFMETRIC}] permette di leggere il valore della metrica del
dispositivo associato all'interfaccia specificata nel campo
- \var{ifr\_metric}. Attualmente non è implementato, e l'operazione
+ \var{ifr\_metric}. Attualmente non è implementato, e l'operazione
restituisce sempre un valore nullo.
\item[\const{SIOCSIFMETRIC}] permette di impostare il valore della metrica del
\item[\const{SIOCSIFMTU}] permette di impostare il valore della
\itindex{Maximum~Transfer~Unit} \textit{Maximum Transfer Unit} del
- dispositivo al valore specificato campo \var{ifr\_mtu}. L'operazione è
- privilegiata, e si tenga presente che impostare un valore troppo basso può
+ dispositivo al valore specificato campo \var{ifr\_mtu}. L'operazione è
+ privilegiata, e si tenga presente che impostare un valore troppo basso può
causare un blocco del kernel.
\item[\const{SIOCGIFHWADDR}] permette di leggere il valore dell'indirizzo
\item[\const{SIOCSIFHWADDR}] permette di impostare il valore dell'indirizzo
hardware del dispositivo associato all'interfaccia attraverso il valore
della struttura \struct{sockaddr} (con lo stesso formato illustrato per
- \const{SIOCGIFHWADDR}) passata nel campo \var{ifr\_hwaddr}. L'operazione è
+ \const{SIOCGIFHWADDR}) passata nel campo \var{ifr\_hwaddr}. L'operazione è
privilegiata.
\item[\const{SIOCSIFHWBROADCAST}] imposta l'indirizzo \textit{broadcast}
\itindex{broadcast} hardware dell'interfaccia al valore specificato dal
- campo \var{ifr\_hwaddr}. L'operazione è privilegiata.
+ campo \var{ifr\_hwaddr}. L'operazione è privilegiata.
\item[\const{SIOCGIFMAP}] legge alcuni parametri hardware (memoria, interrupt,
canali di DMA) del driver dell'interfaccia specificata, restituendo i
relativi valori nel campo \var{ifr\_map}; quest'ultimo contiene una
- struttura di tipo \struct{ifmap}, la cui definizione è illustrata in
+ struttura di tipo \struct{ifmap}, la cui definizione è illustrata in
fig.~\ref{fig:netdevice_ifmap_struct}.
\begin{figure}[!htb]
\item[\const{SIOCADDMULTI}] aggiunge un indirizzo di \itindex{multicast}
\textit{multicast} ai filtri del livello di collegamento associati
dell'interfaccia. Si deve usare un indirizzo hardware da specificare
- attraverso il campo \var{ifr\_hwaddr}, che conterrà l'opportuna struttura
- \struct{sockaddr}; l'operazione è privilegiata. Per una modalità alternativa
+ attraverso il campo \var{ifr\_hwaddr}, che conterrà l'opportuna struttura
+ \struct{sockaddr}; l'operazione è privilegiata. Per una modalità alternativa
per eseguire la stessa operazione si possono usare i \textit{packet socket},
vedi sez.~\ref{sec:packet_socket}.
\item[\const{SIOCDELMULTI}] rimuove un indirizzo di \itindex{multicast}
\textit{multicast} ai filtri del livello di collegamento dell'interfaccia,
vuole un indirizzo hardware specificato come per \const{SIOCADDMULTI}. Anche
- questa operazione è privilegiata e può essere eseguita in forma alternativa
+ questa operazione è privilegiata e può essere eseguita in forma alternativa
con i \textit{packet socket}.
\item[\const{SIOCGIFTXQLEN}] permette di leggere la lunghezza della coda di
\item[\const{SIOCSIFTXQLEN}] permette di impostare il valore della lunghezza
della coda di trasmissione del dispositivo associato all'interfaccia, questo
- deve essere specificato nel campo \var{ifr\_qlen}. L'operazione è
+ deve essere specificato nel campo \var{ifr\_qlen}. L'operazione è
privilegiata.
\item[\const{SIOCSIFNAME}] consente di cambiare il nome dell'interfaccia
\end{basedescript}
Una ulteriore operazione, che consente di ricavare le caratteristiche delle
-interfacce di rete, è \const{SIOCGIFCONF}; però per ragioni di compatibilità
-questa operazione è disponibile soltanto per i socket della famiglia
-\const{AF\_INET} (vale ad dire per socket IPv4). In questo caso l'utente dovrà
+interfacce di rete, è \const{SIOCGIFCONF}; però per ragioni di compatibilità
+questa operazione è disponibile soltanto per i socket della famiglia
+\const{AF\_INET} (vale ad dire per socket IPv4). In questo caso l'utente dovrà
passare come argomento una struttura \struct{ifconf}, definita in
fig.~\ref{fig:netdevice_ifconf_struct}.
\label{fig:netdevice_ifconf_struct}
\end{figure}
-Per eseguire questa operazione occorrerà allocare preventivamente un buffer di
+Per eseguire questa operazione occorrerà allocare preventivamente un buffer di
contenente un vettore di strutture \struct{ifreq}. La dimensione (in byte) di
questo buffer deve essere specificata nel campo \var{ifc\_len} di
-\struct{ifconf}, mentre il suo indirizzo andrà specificato nel campo
+\struct{ifconf}, mentre il suo indirizzo andrà specificato nel campo
\var{ifc\_req}. Qualora il buffer sia stato allocato come una stringa, il suo
-indirizzo potrà essere fornito usando il campo \var{ifc\_buf}.\footnote{si
- noti che l'indirizzo del buffer è definito in \struct{ifconf} con una
+indirizzo potrà essere fornito usando il campo \var{ifc\_buf}.\footnote{si
+ noti che l'indirizzo del buffer è definito in \struct{ifconf} con una
\ctyp{union}, questo consente di utilizzare una delle due forme a piacere.}
La funzione restituisce nel buffer indicato una serie di strutture
\struct{ifreq} contenenti nel campo \var{ifr\_name} il nome dell'interfaccia e
nel campo \var{ifr\_addr} il relativo indirizzo IP. Se lo spazio allocato nel
-buffer è sufficiente il kernel scriverà una struttura \struct{ifreq} per
+buffer è sufficiente il kernel scriverà una struttura \struct{ifreq} per
ciascuna interfaccia attiva, restituendo nel campo \var{ifc\_len} il totale
-dei byte effettivamente scritti. Il valore di ritorno è 0 se l'operazione ha
+dei byte effettivamente scritti. Il valore di ritorno è 0 se l'operazione ha
avuto successo e negativo in caso contrario.
-Si tenga presente che il kernel non scriverà mai sul buffer di uscita dati
+Si tenga presente che il kernel non scriverà mai sul buffer di uscita dati
eccedenti numero di byte specificato col valore di \var{ifc\_len} impostato
alla chiamata della funzione, troncando il risultato se questi non dovessero
essere sufficienti. Questa condizione non viene segnalata come errore per cui
occorre controllare il valore di \var{ifc\_len} all'uscita della funzione, e
-verificare che esso sia inferiore a quello di ingresso. In caso contrario si è
-probabilmente\footnote{probabilmente perché si potrebbe essere nella
+verificare che esso sia inferiore a quello di ingresso. In caso contrario si è
+probabilmente\footnote{probabilmente perché si potrebbe essere nella
condizione in cui sono stati usati esattamente quel numero di byte.} avuta
una situazione di troncamento dei dati.
\label{fig:netdevice_iflist}
\end{figure}
-Come esempio dell'uso di queste funzioni si è riportato in
+Come esempio dell'uso di queste funzioni si è riportato in
fig.~\ref{fig:netdevice_iflist} il corpo principale del programma
\texttt{iflist} in cui si utilizza l'operazione \const{SIOCGIFCONF} per
ottenere una lista delle interfacce attive e dei relativi indirizzi. Al solito
-il codice completo è fornito nei sorgenti allegati alla guida.
+il codice completo è fornito nei sorgenti allegati alla guida.
Il programma inizia (\texttt{\small 7--11}) con la creazione del socket
necessario ad eseguire l'operazione, dopo di che si inizializzano
opportunamente (\texttt{\small 13--14}) i valori della struttura
\struct{ifconf} indicando la dimensione del buffer ed il suo
indirizzo;\footnote{si noti come in questo caso si sia specificato l'indirizzo
- usando il campo \var{ifc\_buf}, mentre nel seguito del programma si accederà
+ usando il campo \var{ifc\_buf}, mentre nel seguito del programma si accederà
ai valori contenuti nel buffer usando \var{ifc\_req}.} si esegue poi
l'operazione invocando \func{ioctl}, controllando come sempre la corretta
esecuzione, ed uscendo in caso di errore (\texttt{\small 15--19}).
-Si esegue poi un controllo sulla quantità di dati restituiti segnalando un
-eventuale overflow del buffer (\texttt{\small 21--23}); se invece è tutto a
+Si esegue poi un controllo sulla quantità di dati restituiti segnalando un
+eventuale overflow del buffer (\texttt{\small 21--23}); se invece è tutto a
posto (\texttt{\small 24--27}) si calcola e si stampa a video il numero di
interfacce attive trovate. L'ultima parte del programma (\texttt{\small
- 28--33}) è il ciclo sul contenuto delle varie strutture \struct{ifreq}
+ 28--33}) è il ciclo sul contenuto delle varie strutture \struct{ifreq}
restituite in cui si estrae (\texttt{\small 30}) l'indirizzo ad esse
-assegnato\footnote{si è definito \var{access} come puntatore ad una struttura
+assegnato\footnote{si è definito \var{access} come puntatore ad una struttura
di tipo \struct{sockaddr\_in} per poter eseguire un \textit{casting}
- dell'indirizzo del valore restituito nei vari campi \var{ifr\_addr}, così
+ dell'indirizzo del valore restituito nei vari campi \var{ifr\_addr}, così
poi da poterlo poi usare come argomento di \func{inet\_ntoa}.} e lo si
stampa (\texttt{\small 31--32}) insieme al nome dell'interfaccia.
\label{sec:sock_ioctl_IP}
Non esistono operazioni specifiche per i socket IP in quanto tali,\footnote{a
- parte forse \const{SIOCGIFCONF}, che però resta attinente alle proprietà
+ parte forse \const{SIOCGIFCONF}, che però resta attinente alle proprietà
delle interfacce di rete, per cui l'abbiamo trattata in
sez.~\ref{sec:sock_ioctl_netdevice} insieme alle altre che comunque si
applicano anche ai socket IP.} mentre per i pacchetti di altri protocolli
-trasportati su IP, qualora li si gestisca attraverso dei socket, si dovrà fare
+trasportati su IP, qualora li si gestisca attraverso dei socket, si dovrà fare
riferimento direttamente all'eventuale supporto presente per il tipo di socket
usato: ad esempio si possono ricevere pacchetti ICMP con socket di tipo
-\texttt{raw}, nel qual caso si dovrà fare riferimento alle operazioni di
+\texttt{raw}, nel qual caso si dovrà fare riferimento alle operazioni di
quest'ultimo.
Tuttavia la gran parte dei socket utilizzati nella programmazione di rete
-utilizza proprio il protocollo IP, e quello che succede è che in realtà la
+utilizza proprio il protocollo IP, e quello che succede è che in realtà la
funzione \func{ioctl} consente di effettuare alcune operazioni specifiche per
i socket che usano questo protocollo, ma queste vendono eseguite, invece che a
livello di IP, al successivo livello di trasporto, vale a dire in maniera
come \itindex{value~result~argument} \textit{value result argument}, deve
essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{SIOCINQ}] restituisce la quantità di dati non ancora letti
+\item[\const{SIOCINQ}] restituisce la quantità di dati non ancora letti
presenti nel buffer di ricezione; il socket non deve essere in stato
- \texttt{LISTEN}, altrimenti si avrà un errore di \errval{EINVAL}.
+ \texttt{LISTEN}, altrimenti si avrà un errore di \errval{EINVAL}.
\item[\const{SIOCATMARK}] ritorna un intero non nullo, da intendere come
- valore logico, se il flusso di dati letti sul socket è arrivato sulla
+ valore logico, se il flusso di dati letti sul socket è arrivato sulla
posizione (detta anche \textit{urgent mark}) in cui sono stati ricevuti
\itindex{out-of-band} dati urgenti (vedi sez.~\ref{sec:TCP_urgent_data}).
Una operazione di lettura da un socket non attraversa mai questa posizione,
- per cui è possibile controllare se la si è raggiunta o meno con questa
+ per cui è possibile controllare se la si è raggiunta o meno con questa
operazione.
- Questo è utile quando si attiva l'opzione \const{SO\_OOBINLINE} (vedi
+ Questo è utile quando si attiva l'opzione \const{SO\_OOBINLINE} (vedi
sez.~\ref{sec:sock_generic_options}) per ricevere i dati urgenti all'interno
del flusso dei dati ordinari del socket;\footnote{vedremo in
sez.~\ref{sec:TCP_urgent_data} che in genere i dati urgenti presenti su un
socket si leggono \textit{out-of-band} usando un opportuno flag per
\func{recvmsg}.} in tal caso quando \const{SIOCATMARK} restituisce un
- valore non nullo si saprà che la successiva lettura dal socket restituirà i
+ valore non nullo si saprà che la successiva lettura dal socket restituirà i
dati urgenti e non il normale traffico; torneremo su questo in maggior
dettaglio in sez.~\ref{sec:TCP_urgent_data}.
-\item[\const{SIOCOUTQ}] restituisce la quantità di dati non ancora inviati
+\item[\const{SIOCOUTQ}] restituisce la quantità di dati non ancora inviati
presenti nel buffer di spedizione; come per \const{SIOCINQ} il socket non
- deve essere in stato \texttt{LISTEN}, altrimenti si avrà un errore di
+ deve essere in stato \texttt{LISTEN}, altrimenti si avrà un errore di
\errval{EINVAL}.
\end{basedescript}
\item[\const{FIONREAD}] restituisce la dimensione in byte del primo pacchetto
in attesa di ricezione, o 0 qualora non ci sia nessun pacchetto.
\item[\const{TIOCOUTQ}] restituisce il numero di byte presenti nella coda di
- invio locale; questa opzione è supportata soltanto a partire dal kernel 2.4
+ invio locale; questa opzione è supportata soltanto a partire dal kernel 2.4
\end{basedescript}
\label{sec:sock_sysctl_proc}
Come ultimo argomento di questo capitolo tratteremo l'uso della funzione
-\func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
-sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
-impostazioni relative alle proprietà dei socket. Dato che le stesse
-funzionalità sono controllabili direttamente attraverso il filesystem
+\func{sysctl} (che è stata introdotta nelle sue funzionalità generiche in
+sez.~\ref{sec:sys_sysctl}) per quanto riguarda le sue capacità di effettuare
+impostazioni relative alle proprietà dei socket. Dato che le stesse
+funzionalità sono controllabili direttamente attraverso il filesystem
\texttt{/proc}, le tratteremo attraverso i file presenti in quest'ultimo.
-\subsection{L'uso di \func{sysctl} e \texttt{/proc} per le proprietà della
+\subsection{L'uso di \func{sysctl} e \texttt{/proc} per le proprietà della
rete}
\label{sec:sock_sysctl}
La differenza nell'uso di \func{sysctl} e del filesystem \texttt{/proc}
rispetto a quello delle funzioni \func{ioctl} e \func{fcntl} visto in
sez.~\ref{sec:sock_ctrl_func} o all'uso di \func{getsockopt} e
-\func{setsockopt} è che queste funzioni consentono di controllare le proprietà
+\func{setsockopt} è che queste funzioni consentono di controllare le proprietà
di un singolo socket, mentre con \func{sysctl} e con \texttt{/proc} si
-impostano proprietà (o valori di default) validi a livello dell'intero
-sistema, e cioè per tutti i socket.
+impostano proprietà (o valori di default) validi a livello dell'intero
+sistema, e cioè per tutti i socket.
-Le opzioni disponibili per le proprietà della rete, nella gerarchia dei valori
+Le opzioni disponibili per le proprietà della rete, nella gerarchia dei valori
impostabili con \func{sysctl}, sono riportate sotto il nodo \texttt{net}, o,
se acceduti tramite l'interfaccia del filesystem \texttt{/proc}, sotto
\texttt{/proc/sys/net}. In genere sotto questa directory compaiono le
sottodirectory (corrispondenti ad altrettanti sotto-nodi per \func{sysctl})
-relative ai vari protocolli e tipi di interfacce su cui è possibile
+relative ai vari protocolli e tipi di interfacce su cui è possibile
intervenire per effettuare impostazioni; un contenuto tipico di questa
-directory è il seguente:
+directory è il seguente:
\begin{verbatim}
/proc/sys/net/
|-- core
`-- unix
\end{verbatim}
e sono presenti varie centinaia di parametri, molti dei quali non sono neanche
-documentati; nel nostro caso ci limiteremo ad illustrare quelli più
+documentati; nel nostro caso ci limiteremo ad illustrare quelli più
significativi.
-Si tenga presente infine che se è sempre possibile utilizzare il filesystem
+Si tenga presente infine che se è sempre possibile utilizzare il filesystem
\texttt{/proc} come sostituto di \func{sysctl}, dato che i valori di nodi e
sotto-nodi di quest'ultima sono mappati come file e directory sotto
-\texttt{/proc/sys/}, non è vero il contrario, ed in particolare Linux consente
+\texttt{/proc/sys/}, non è vero il contrario, ed in particolare Linux consente
di impostare alcuni parametri o leggere lo stato della rete a livello di
sistema sotto \texttt{/proc/net}, dove sono presenti dei file che non
corrispondono a nessun nodo di \func{sysctl}.
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\procrelfile{/proc/sys/net/core}{rmem\_default}] imposta la dimensione
- di default del buffer di ricezione (cioè per i dati in ingresso) dei socket.
+ 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
- massima che si può assegnare al buffer di ricezione dei socket attraverso
+ 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
- di default del buffer di trasmissione (cioè per i dati in uscita) dei
+ 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
- massima che si può assegnare al buffer di trasmissione dei socket attraverso
+ 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
traffico che generi intenzionalmente messaggi di errore, per saturare il
sistema dei log.}
- Il \itindex{bucket~filter} \textit{bucket filter} è un algoritmo generico
- che permette di impostare dei limiti di flusso su una quantità\footnote{uno
+ Il \itindex{bucket~filter} \textit{bucket filter} è un algoritmo generico
+ che permette di impostare dei limiti di flusso su una quantità\footnote{uno
analogo viene usato nel \itindex{netfilter} \textit{netfilter} per imporre
dei limiti sul flusso dei pacchetti.} senza dovere eseguire medie
temporali, che verrebbero a dipendere in misura non controllabile dalla
\textit{burst}) il flusso medio verrebbe a dipendere in maniera esclusiva
dalla dimensione dell'intervallo di tempo su cui calcola la media.} in
questo caso si definisce la dimensione di un ``\textsl{bidone}'' (il
- \textit{bucket}) e del flusso che da esso può uscire, la presenza di una
+ \textit{bucket}) e del flusso che da esso può uscire, la presenza di una
dimensione iniziale consente di assorbire eventuali picchi di emissione,
- l'aver fissato un flusso di uscita garantisce che a regime questo sarà il
+ l'aver fissato un flusso di uscita garantisce che a regime questo sarà il
valore medio del flusso ottenibile dal \textit{bucket}.
- I due valori indicano rispettivamente il flusso a regime (non sarà inviato
- più di un messaggio per il numero di secondi specificato da
+ I due valori indicano rispettivamente il flusso a regime (non sarà inviato
+ più di un messaggio per il numero di secondi specificato da
\texttt{message\_cost}) e la dimensione iniziale per in caso di picco di
emissione (verranno accettati inizialmente fino ad un massimo di
\texttt{message\_cost/message\_burst} messaggi).
Oltre a questi nella directory \texttt{/proc/sys/net/core} si trovano altri
file, la cui documentazione dovrebbe essere mantenuta nei sorgenti del kernel,
nel file \texttt{Documentation/networking/ip-sysctl.txt}; la maggior parte di
-questi però non è documentato:
+questi però non è documentato:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\procrelfile{/proc/sys/net/core}{dev\_weight}] blocco di lavoro
(\textit{work quantum}) dello scheduler di processo dei pacchetti.
\item[\procrelfile{/proc/sys/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
- % soltanto quando si è compilato il kernel con l'apposita opzione di
+ % \item[\procrelfile{/proc/sys/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
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.
+ costante \const{SOMAXCONN}; il suo valore di default è 128.
\end{basedescript}
\item[\procrelfile{/proc/sys/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
+ pacchetti uscenti, stabilendo così il numero massimo di router che i
+ pacchetti possono attraversare. Il valore può essere modificato anche per il
singolo socket con l'opzione \const{IP\_TTL}. Prende un valore intero, ma
- dato che il campo citato è di 8 bit hanno senso solo valori fra 0 e 255. Il
- valore di default è 64, e normalmente non c'è nessuna necessità di
+ dato che il campo citato è di 8 bit hanno senso solo valori fra 0 e 255. Il
+ valore di default è 64, e normalmente non c'è nessuna necessità di
modificarlo.\footnote{l'unico motivo sarebbe per raggiungere macchine
- estremamente ``{lontane}'' in termini di \textit{hop}, ma è praticamente
- impossibile trovarne.} Aumentare il valore è una pratica poco gentile, in
+ estremamente ``{lontane}'' in termini di \textit{hop}, ma è praticamente
+ impossibile trovarne.} Aumentare il valore è una pratica poco gentile, in
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
- pacchetti da una interfaccia ad un altra, e può essere impostato anche per
+ 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.
+ zero abilita), di default è disabilitato.
\item[\procrelfile{/proc/sys/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
- può essere modificato. Prende un valore intero, con 0 si disabilita la
- funzionalità, con 1 la si abilita, con 2 (o con qualunque altro valore
- diverso dai precedenti) la si abilità in modalità \textsl{prolissa}; di
- default la funzionalità è disabilitata.
+ può essere modificato. Prende un valore intero, con 0 si disabilita la
+ funzionalità, con 1 la si abilita, con 2 (o con qualunque altro valore
+ 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
- l'indirizzo IP è stato configurato automaticamente dal kernel all'avvio
+ 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
+ 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
l'intervallo dei valori usati per l'assegnazione delle porte effimere,
- permette cioè di modificare i valori illustrati in
+ permette cioè di modificare i valori illustrati in
fig.~\ref{fig:TCP_port_alloc}; prende due valori interi separati da spazi,
che indicano gli estremi dell'intervallo. Si abbia cura di non definire un
intervallo che si sovrappone a quello delle porte usate per il
- \itindex{masquerading} \textit{masquerading}, il kernel può gestire la
- sovrapposizione, ma si avrà una perdita di prestazioni. Si imposti sempre un
+ \itindex{masquerading} \textit{masquerading}, il kernel può gestire la
+ sovrapposizione, ma si avrà una perdita di prestazioni. Si imposti sempre un
valore iniziale maggiore di 1024 (o meglio ancora di 4096) per evitare
conflitti con le porte usate dai servizi noti.
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
- valore logico, e di default è disabilitato (cioè la ricerca viene eseguita).
+ valore logico, e di default è disabilitato (cioè la ricerca viene eseguita).
In genere si abilita questo parametro quando per qualche motivo il
procedimento del \itindex{Maximum~Transfer~Unit} \textit{Path MTU discovery}
- fallisce; dato che questo può avvenire a causa di router\footnote{ad
- esempio se si scartano tutti i pacchetti ICMP, il problema è affrontato
+ fallisce; dato che questo può avvenire a causa di router\footnote{ad
+ esempio se si scartano tutti i pacchetti ICMP, il problema è affrontato
anche in sez.~1.4.4 di \cite{FwGL}.} o interfacce\footnote{ad esempio se i
due capi di un collegamento \textit{point-to-point} non si accordano sulla
- stessa MTU.} mal configurate è opportuno correggere le configurazioni,
- perché disabilitare globalmente il procedimento con questo parametro ha
+ stessa MTU.} mal configurate è opportuno correggere le configurazioni,
+ 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
precedenti questo comportamento poteva essere solo stabilito un volta per
tutte in fase di compilazione del kernel con l'opzione
\texttt{CONFIG\_IP\_ALWAYS\_DEFRAG}.} Prende un valore logico e di default
- è disabilitato. Con i kernel dalla serie 2.4 in poi la deframmentazione
+ è disabilitato. Con i kernel dalla serie 2.4 in poi la deframmentazione
viene attivata automaticamente quando si utilizza il sistema del
- \itindex{netfilter} \textit{netfilter}, e questo parametro non è più
+ \itindex{netfilter} \textit{netfilter}, e questo parametro non è più
presente.
\item[\procrelfile{/proc/sys/net/ipv4}{ipfrag\_high\_thresh}] indica il limite
\item[\procrelfile{/proc/sys/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.
+ non è presente su nessuna interfaccia locale. Prende un valore logico e di
+ default è disabilitato.
- Questo può risultare utile per applicazioni particolari (come gli
- \textit{sniffer}) che hanno la necessità di ricevere pacchetti anche non
+ Questo può risultare utile per applicazioni particolari (come gli
+ \textit{sniffer}) che hanno la necessità di ricevere pacchetti anche non
diretti agli indirizzi presenti sulla macchina, ad esempio per intercettare
il traffico per uno specifico indirizzo che si vuole tenere sotto
- controllo. Il suo uso però può creare problemi ad alcune applicazioni.
+ controllo. Il suo uso però può creare problemi ad alcune applicazioni.
% \item[\texttt{neigh/*}] La directory contiene i valori
-% TODO trattare neigh/* nella parte su arp, da capire dove sarà.
+% TODO trattare neigh/* nella parte su arp, da capire dove sarà.
\end{basedescript}
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\procrelfile{/proc/sys/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
+ 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
eccesso dovuto ad un qualche picco di traffico, ma ovviamente va a discapito
- dei client che interrogano il server. Pertanto è da abilitare soltanto
- quando si è sicuri che non è possibile ottimizzare il server in modo che sia
- in grado di accettare connessioni più rapidamente.
+ dei client che interrogano il server. Pertanto è da abilitare soltanto
+ 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
quale frazione del buffer associato ad un socket\footnote{quello impostato
che determina la suddetta frazione secondo la formula
$\texttt{buffer}/2^\texttt{tcp\_adv\_win\_scale}$ se positivo o con
$\texttt{buffer}-\texttt{buffer}/2^\texttt{tcp\_adv\_win\_scale}$ se
- negativo. Il default è 2 che significa che al buffer dell'applicazione
+ 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
bufferizzazione. Prende un valore valore intero che consente di calcolare la
dimensione in byte come il massimo fra la \itindex{Maximum~Segment~Size}
MSS e $\texttt{window}/2^\texttt{tcp\_app\_win}$. Un valore nullo significa
- che non viene riservato nessuno spazio; il valore di default è 31.
+ che non viene riservato nessuno spazio; il valore di default è 31.
% vecchi, presumibilmente usati quando gli algoritmi di congestione non erano
% modularizzabili
nell'\href{http://www.ietf.org/rfc/rfc2018.txt}{RFC~2018}, usata per dare
un \textit{acknowledgement} unico su blocchi di pacchetti non contigui,
che consente di diminuire il numero di pacchetti scambiati.} Prende un
- valore logico e di default è abilitato.
-% TODO documentare o descrivere che cos'è il Duplicate SACK o
+ valore logico e di default è abilitato.
+% TODO documentare o descrivere che cos'è il Duplicate SACK o
% mettere riferimento nelle appendici
\item[\procrelfile{/proc/sys/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
- meccanismo che consente di notificare quando una rotta o una rete è
- congestionata da un eccesso di traffico,\footnote{il meccanismo è descritto
+ TCP. Prende valore logico che di default è disabilitato. La \textit{Explicit
+ Congestion Notification} \itindex{Explicit~Congestion~Notification} è un
+ meccanismo che consente di notificare quando una rotta o una rete è
+ congestionata da un eccesso di traffico,\footnote{il meccanismo è descritto
in dettaglio nell'\href{http://www.ietf.org/rfc/rfc3168.txt}{RFC~3168}
mentre gli effetti sulle prestazioni del suo utilizzo sono documentate
- nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}.} si può così
+ nell'\href{http://www.ietf.org/rfc/rfc2884.txt}{RFC~2884}.} si può così
essere avvisati e cercare rotte alternative oppure diminuire l'emissione di
pacchetti (in modo da non aumentare la congestione).
dovuti al fatto che alcuni vecchi router non supportano il meccanismo ed
alla sua attivazione scartano i relativi pacchetti, bloccando completamente
il traffico.
-% TODO documentare o descrivere che cos'è l'Explicit Congestion Notification o
+% TODO documentare o descrivere che cos'è l'Explicit Congestion Notification o
% mettere riferimento nelle appendici
\item[\procrelfile{/proc/sys/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.
+ congestione del traffico. Prende un valore logico e di default è abilitato.
-% TODO documentare o descrivere che cos'è il TCP Forward Acknowledgement o
+% 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
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
- e di default è 60.\footnote{nei kernel della serie 2.2.x era il valore
+ e di default è 60.\footnote{nei kernel della serie 2.2.x era il valore
utilizzato era invece di 120 secondi.} L'uso di questa opzione realizza
- quella che in sostanza è una violazione delle specifiche del protocollo TCP,
- ma è utile per fronteggiare alcuni attacchi di
+ quella che in sostanza è una violazione delle specifiche del protocollo TCP,
+ 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
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 è
+ 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
numero di secondi che deve trascorrere fra l'emissione di due successivi
- pacchetti di test quando è abilitata la funzionalità del \textit{keepalive}
+ 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.
+ default è 75.
\item[\procrelfile{/proc/sys/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.
+ 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
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 è
+ \textit{keepalive}.\footnote{ha effetto solo per i socket per cui si è
impostata l'opzione \const{SO\_KEEPALIVE} (vedi
sez.~\ref{sec:sock_options_main}.} Prende un valore intero che di default
- è 7200, pari a due ore.
+ è 7200, pari a due ore.
\item[\procrelfile{/proc/sys/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
- della banda è preferito, ma esistono applicazioni particolari in cui la
- riduzione della latenza è più importante (ad esempio per i cluster di
- calcolo parallelo) nelle quali lo si può abilitare.
+ 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
+ della banda è preferito, ma esistono applicazioni particolari in cui la
+ 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
massimo di socket TCP ``\textsl{orfani}'' (vale a dire non associati a
processo di chiusura.} Quando il limite viene ecceduto la connessione
orfana viene resettata e viene stampato un avvertimento. Questo limite viene
usato per contrastare alcuni elementari attacchi di \textit{denial of
- service}. Diminuire il valore non è mai raccomandato, in certe condizioni
- di rete può essere opportuno aumentarlo, ma si deve tenere conto del fatto
- che ciascuna connessione orfana può consumare fino a 64K di memoria del
+ service}. Diminuire il valore non è mai raccomandato, in certe condizioni
+ di rete può essere opportuno aumentarlo, ma si deve tenere conto del fatto
+ che ciascuna connessione orfana può consumare fino a 64K di memoria del
kernel. Prende un valore intero, il valore di default viene impostato
inizialmente al valore del parametro del kernel \texttt{NR\_FILE}, e viene
aggiustato a seconda della memoria disponibile.
% TODO verificare la spiegazione di connessione orfana.
\item[\procrelfile{/proc/sys/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
+ 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
illustrato in sez.~\ref{sec:TCP_func_listen}).
- Quando questo valore è superato il kernel scarterà immediatamente ogni
+ Quando questo valore è superato il kernel scarterà immediatamente ogni
ulteriore richiesta di connessione. Prende un valore intero; il default, che
- è 256, viene automaticamente portato a 1024 qualora nel sistema ci sia
+ è 256, viene automaticamente portato a 1024 qualora nel sistema ci sia
sufficiente memoria (se maggiore di 128Mb) e ridotto a 128 qualora la
memoria sia poca (inferiore a 32Mb).\footnote{si raccomanda, qualora si
voglia aumentare il valore oltre 1024, di seguire la procedura citata
\item[\procrelfile{/proc/sys/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
+ sistema. Prende un valore intero di default è impostato al doppio del valore
del parametro \texttt{NR\_FILE}, ma che viene aggiustato automaticamente a
seconda della memoria presente. Se il valore viene superato il socket viene
- chiuso con la stampa di un avviso; l'uso di questa funzionalità consente di
+ chiuso con la stampa di un avviso; l'uso di questa funzionalità consente di
prevenire alcuni semplici attacchi di \textit{denial of service}.
\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_mem}] viene usato dallo stack TCP
- per gestire le modalità con cui esso utilizzerà la memoria. Prende una
+ per gestire le modalità con cui esso utilizzerà la memoria. Prende una
tripletta di valori interi, che indicano un numero di pagine:
\begin{itemize*}
\item[\procrelfile{/proc/sys/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.
+ 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
- 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
+ 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
questa metrica di riconoscimento dei riordinamenti per evitare inutili
ritrasmissioni provocate dal riordinamento. Prende un valore intero che di
- default che è 3, e che non è opportuno modificare.
+ default che è 3, e che non è opportuno modificare.
\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retrans\_collapse}] in caso di
pacchetti persi durante una connessione, per ottimizzare l'uso della banda
massima dimensione possibile; in sostanza dati che in precedenza erano stati
trasmessi su pacchetti diversi possono essere ritrasmessi riuniti su un solo
pacchetto (o su un numero minore di pacchetti di dimensione
- maggiore). Prende un valore logico e di default è abilitato.
+ maggiore). Prende un valore logico e di default è abilitato.
\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retries1}] imposta il massimo
- numero di volte che protocollo tenterà la ritrasmissione si un pacchetto su
+ 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
- ritrasmissioni verrà fatto eseguire al livello di rete un tentativo di
+ ritrasmissioni verrà fatto eseguire al livello di rete un tentativo di
aggiornamento della rotta verso la destinazione prima di eseguire ogni
- successiva ritrasmissione. Prende un valore intero che di default è 3.
+ successiva ritrasmissione. Prende un valore intero che di default è 3.
\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_retries2}] imposta il numero di
- tentativi di ritrasmissione di un pacchetto inviato su una connessione già
+ 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
- valore intero che di default è 15, il che comporta un tempo variabile fra 13
+ valore intero che di default è 15, il che comporta un tempo variabile fra 13
e 30 minuti; questo non corrisponde a quanto richiesto
- 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.
+ 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
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
+ logico e di default è disabilitato, il che significa che alla ricezione di
un segmento RST in stato \texttt{TIME\_WAIT} il socket viene chiuso
immediatamente senza attendere la conclusione del periodo di
\texttt{TIME\_WAIT}.
\begin{itemize}
\item il primo valore, chiamato \textit{min} nelle pagine di manuale, indica
- la dimensione minima in byte del buffer di ricezione; il default è 4Kb, ma
+ la dimensione minima in byte del buffer di ricezione; il default è 4Kb, ma
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
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 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
+ 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
+ (di default è abilitato, vedi più avanti
\procrelfile{/proc/sys/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
+ 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
incidere sulla dimensione del buffer di ricezione di un singolo socket
\item[\procrelfile{/proc/sys/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.
+ logico e di default è abilitato.
\item[\procrelfile{/proc/sys/net/ipv4}{tcp\_stdurg}] indica al kernel di
utilizzare l'interpretazione che viene data
\textit{dati urgenti} (vedi sez.~\ref{sec:TCP_urgent_data}) in cui questo
punta all'ultimo byte degli stessi; se disabilitato viene usata
l'interpretazione usata da BSD per cui esso punta al primo byte successivo.
- Prende un valore logico e di default è disabilitato, perché abilitarlo può
- dar luogo a problemi di interoperabilità.
+ 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
- massimo di volte che verrà ritrasmesso il segmento SYN/ACK nella creazione di
+ 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.
+ 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
- syncookies}.\footnote{per poter usare questa funzionalità è necessario
+ 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
- funzionalità serve a fornire una protezione in caso di un attacco di tipo
+ del kernel.} Prende un valore logico, e di default è disabilitato. Questa
+ funzionalità serve a fornire una protezione in caso di un attacco di tipo
\index{SYN~flood} \textit{SYN flood}, e deve essere utilizzato come ultima
risorsa dato che costituisce una violazione del protocollo TCP e confligge
- con altre funzionalità come le estensioni e può causare problemi per i
+ 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
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.
+ 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
\textit{TCP timestamps}, come definiti
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}. Prende un valore
- logico e di default è abilitato.
+ logico e di default è abilitato.
\item[\procrelfile{/proc/sys/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
- Translation} è una tecnica, impiegata nei firewall e nei router, che
+ logico e di default è disabilitato. Non è opportuno abilitare questa opzione
+ che può causare problemi con il NAT.\footnote{il \textit{Network Address
+ Translation} è una tecnica, impiegata nei firewall e nei router, che
consente di modificare al volo gli indirizzi dei pacchetti che transitano
per una macchina, Linux la supporta con il \itindex{netfilter}
\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
- dello stato \texttt{TIME\_WAIT} quando questo è sicuro dal punto di vista
- del protocollo. Prende un valore logico e di default è disabilitato.
+ 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
- logico, attivo di default, che abilita la funzionalità del
+ 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
- logico e di default è abilitato. Come accennato in
+ logico e di default è abilitato. Come accennato in
sez.~\ref{sec:TCP_TCP_opt} i 16 bit della finestra TCP comportano un limite
massimo di dimensione di 64Kb, ma esiste una opportuna opzione del
protocollo che permette di applicare un fattore di scale che consente di
- aumentarne le dimensioni. Questa è pienamente supportata dallo stack TCP di
+ aumentarne le dimensioni. Questa è pienamente supportata dallo stack TCP di
Linux, ma se lo si disabilita la negoziazione del
\itindex{TCP~window~scaling} \textit{TCP window scaling} con l'altro capo
della connessione non viene effettuata.
\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
+ byte del buffer di spedizione; il default è 4Kb. Come per l'analogo di
\procrelfile{/proc/sys/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
\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
- byte, ridotto a 43689 per sistemi con poca memoria. Si può aumentare
- questo valore quando si desiderano dimensioni più ampie del buffer di
+ socket con \procfile{/proc/sys/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
corrispondenza aumentino anche le dimensioni usate per la finestra TCP si
con \procrelfile{/proc/sys/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
+ 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
+ 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
ad incidere sulla dimensione del buffer di trasmissione di un singolo
socket dichiarata con l'opzione \const{SO\_SNDBUF}.
In questo capitolo inizieremo a spiegare le caratteristiche salienti della
principale interfaccia per la programmazione di rete, quella dei
-\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
+\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
tutti i sistemi operativi.
Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
come creare un socket e come collegarlo allo specifico protocollo di rete che
-si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
+si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
teorica concluderemo il capitolo con un primo esempio di applicazione.
\section{Una panoramica}
Quella dei socket costituisce infatti la principale interfaccia usata nella
programmazione di rete. La loro origine risale al 1983, quando furono
-introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
-piccole modifiche, negli anni successivi. Benché siano state sviluppate
+introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
+piccole modifiche, negli anni successivi. Benché siano state sviluppate
interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
- Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
-di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
+ Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
+di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
-La flessibilità e la genericità dell'interfaccia inoltre consente di
-utilizzare i socket con i più disparati meccanismi di comunicazione, e non
-solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
-di cui tratteremo in maniera più estesa.
+La flessibilità e la genericità dell'interfaccia inoltre consente di
+utilizzare i socket con i più disparati meccanismi di comunicazione, e non
+solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
+di cui tratteremo in maniera più estesa.
\subsection{Concetti base}
\label{sec:sock_gen}
Per capire il funzionamento dei socket occorre avere presente il funzionamento
-dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
-tutto generale e benché le problematiche (e quindi le modalità di risolvere i
+dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
+tutto generale e benché le problematiche (e quindi le modalità di risolvere i
problemi) siano diverse a seconda del tipo di protocollo di comunicazione
usato, le funzioni da usare restano le stesse.
-Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
+Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
inutile, in quanto il comportamento di quest'ultima e le problematiche da
affrontare cambiano radicalmente a seconda dello \textsl{stile} di
comunicazione usato. La scelta di questo stile va infatti ad incidere sulla
-semantica che verrà utilizzata a livello utente per gestire la comunicazione
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
(su come inviare e ricevere i dati) e sul comportamento effettivo delle
funzioni utilizzate.
altri invece li raggruppano in \textsl{pacchetti} (in inglese
\textit{datagram}) che vengono inviati in blocchi separati.
-Un altro esempio di stile concerne la possibilità che la comunicazione possa o
+Un altro esempio di stile concerne la possibilità che la comunicazione possa o
meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
-inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
+inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
-Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
-avviene, in certi casi essa può essere condotta con una connessione diretta
+Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
+avviene, in certi casi essa può essere condotta con una connessione diretta
con un solo corrispondente, come per una telefonata; altri casi possono
prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
ogni pacchetto, altri ancora una comunicazione \itindex{broadcast}
\textit{broadcast} come per la radio, in cui i pacchetti vengono emessi su
appositi ``\textsl{canali}'' dove chiunque si collega possa riceverli.
-É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
-la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
-gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
+É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
+la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
+gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
dovranno essere opportunamente trattati, ecc.
\section{La creazione di un socket}
\label{sec:sock_creation}
-Come accennato l'interfaccia dei socket è estremamente flessibile e permette
+Come accennato l'interfaccia dei socket è estremamente flessibile e permette
di interagire con protocolli di comunicazione anche molto diversi fra di loro;
-in questa sezione vedremo come è possibile creare un socket e come specificare
+in questa sezione vedremo come è possibile creare un socket e come specificare
il tipo di comunicazione che esso deve utilizzare.
\subsection{La funzione \func{socket}}
\funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
tutto analogo a quelli che si ottengono per i file di dati e le pipe,
descritti in sez.~\ref{sec:file_fd}.} che serve come riferimento al socket;
-il suo prototipo è:
+il suo prototipo è:
\begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
Apre un socket.
\bodydesc{La funzione restituisce un intero positivo in caso di successo, e
- -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
+ -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
i valori:
\begin{errlist}
\item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
non sono supportati nel dominio.
\item[\errcode{ENFILE}] il kernel non ha memoria sufficiente a creare una
nuova struttura per il socket.
- \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
+ \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
\item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
dominio o con il protocollo specificato.
\item[\errcode{EINVAL}] protocollo sconosciuto o dominio non disponibile.
- \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
- (può essere anche \errval{ENOMEM}).
+ \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
+ (può essere anche \errval{ENOMEM}).
\end{errlist}
inoltre, a seconda del protocollo usato, potranno essere generati altri
errori, che sono riportati nelle relative pagine di manuale.}
\end{prototype}
La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
-(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
-protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
+(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
+protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
-\param{protocol} il protocollo; in genere quest'ultimo è indicato
+\param{protocol} il protocollo; in genere quest'ultimo è indicato
implicitamente dal tipo di socket, per cui di norma questo valore viene messo
a zero (con l'eccezione dei \textit{raw socket}).
chiamano \textsl{domini}. La scelta di un dominio equivale in sostanza alla
scelta di una famiglia di protocolli, e viene effettuata attraverso
l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
-suo nome simbolico che convenzionalmente è indicato da una costante che inizia
+suo nome simbolico che convenzionalmente è indicato da una costante che inizia
per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
cui si indicano i domini.
L'idea alla base della distinzione fra questi due insiemi di costanti era che
una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
-il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
+il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
-valori numerici.\footnote{in Linux, come si può verificare andando a guardare
+valori numerici.\footnote{in Linux, come si può verificare andando a guardare
il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
- e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
+ e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
lo stesso nome.}
-I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
indirizzi, sono definiti dall'header \texttt{socket.h}. Un elenco delle
-famiglie di protocolli disponibili in Linux è riportato in
+famiglie di protocolli disponibili in Linux è riportato in
tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
- definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
+ definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
viene definita anche una costante \const{PF\_MAX} che indica il valore
massimo associabile ad un dominio (nel caso il suo valore 32).}
Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
dall'utente generico, ad esempio in generale tutti i socket di tipo
\const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
-di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
+di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
\itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
\subsection{Il tipo di socket}
\label{sec:sock_type}
-La scelta di un dominio non comporta però la scelta dello stile di
-comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
+La scelta di un dominio non comporta però la scelta dello stile di
+comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
socket permette di scegliere lo stile di comunicazione indicando il tipo di
socket con l'argomento \param{type} di \func{socket}. Linux mette a
disposizione vari tipi di socket (che corrispondono a quelli che il manuale
della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
- tre tipi, Linux supporta anche gli altri, come si può verificare nel file
+ tre tipi, Linux supporta anche gli altri, come si può verificare nel file
\texttt{include/linux/net.h} dei sorgenti del kernel.}
\begin{basedescript}{\desclabelwidth{2.9cm}\desclabelstyle{\nextlinelabel}}
bidirezionale, sequenziale e affidabile. Opera su una connessione con un
altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
- dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
+ dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
urgenti (o \itindex{out-of-band} \textit{out-of-band}, vedi
sez.~\ref{sec:TCP_urgent_data}).
\item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
(\textit{datagram}) di lunghezza massima prefissata, indirizzati
- singolarmente. Non esiste una connessione e la trasmissione è effettuata in
+ singolarmente. Non esiste una connessione e la trasmissione è effettuata in
maniera non affidabile.
\item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
bidirezionale, sequenziale e affidabile. Opera su una connessione con un
\func{read}.
\item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
rete e alle varie interfacce. I normali programmi di comunicazione non
- devono usarlo, è riservato all'uso di sistema.
+ devono usarlo, è riservato all'uso di sistema.
\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
- affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
-\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
+ affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
+\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
pertanto non ne parleremo ulteriormente.}
\end{basedescript}
Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
-e un tipo di socket sono valide, in quanto non è detto che in una famiglia
+e un tipo di socket sono valide, in quanto non è detto che in una famiglia
esista un protocollo per ciascuno dei diversi stili di comunicazione appena
elencati.
In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
valide possibili per le principali famiglie di protocolli. Per ogni
-combinazione valida si è indicato il tipo di protocollo, o la parola
+combinazione valida si è indicato il tipo di protocollo, o la parola
\textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
sono lasciate vuote le caselle per le combinazioni non supportate.
\section{Le strutture degli indirizzi dei socket}
\label{sec:sock_sockaddr}
-Come si è visto nella creazione di un socket non si specifica nulla oltre al
+Come si è visto nella creazione di un socket non si specifica nulla oltre al
tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
indirizzo che identifichi i due capi della comunicazione. La funzione infatti
si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
\label{sec:sock_sa_gen}
Le strutture degli indirizzi vengono sempre passate alle varie funzioni
-attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
+attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
nelle varie famiglie di protocolli; questo pone il problema di come passare
questi puntatori, il C moderno risolve questo problema coi i puntatori
-generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
+generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
-è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
+è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
\begin{figure}[!htb]
\footnotesize \centering
Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
prototipo un puntatore a questa struttura; per questo motivo quando si
invocano dette funzioni passando l'indirizzo di un protocollo specifico
-occorrerà eseguire una conversione del relativo puntatore.
+occorrerà eseguire una conversione del relativo puntatore.
I tipi di dati che compongono la struttura sono stabiliti dallo standard
POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
-rispettivi file di include in cui sono definiti; la struttura è invece
+rispettivi file di include in cui sono definiti; la struttura è invece
definita nell'include file \file{sys/socket.h}.
\begin{table}[!htb]
\label{tab:sock_data_types}
\end{table}
-In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
+In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
aggiuntivo \code{uint8\_t sin\_len} (come riportato da R. Stevens in
\cite{UNP1}). Questo campo non verrebbe usato direttamente dal programmatore e
-non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
+non è richiesto dallo standard POSIX.1g, in Linux pertanto non esiste. Il
campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
-Dal punto di vista del programmatore l'unico uso di questa struttura è quello
+Dal punto di vista del programmatore l'unico uso di questa struttura è quello
di fare da riferimento per il casting, per il kernel le cose sono un po'
diverse, in quanto esso usa il puntatore per recuperare il campo
\var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
-sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
-è stato mantenuto l'uso di questa struttura.
+sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
+è stato mantenuto l'uso di questa struttura.
\subsection{La struttura degli indirizzi IPv4}
I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
attraverso internet; la struttura per gli indirizzi per un socket internet (se
-si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
+si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
\file{netinet/in.h} ed ha la forma mostrata in
fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
\end{figure}
L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
-internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
+internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}). Il
protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
-protocolli di livello superiore come TCP e UDP. Questa struttura però viene
+protocolli di livello superiore come TCP e UDP. Questa struttura però viene
usata anche per i socket RAW che accedono direttamente al livello di IP, nel
qual caso il numero della porta viene impostato al numero di protocollo.
Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
-altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
+altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
soltanto processi con i privilegi di amministratore (con user-ID effettivo
una \direct{union} usata per accedere alle diverse classi di indirizzi) che
direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
costanti che identificano alcuni indirizzi speciali, riportati in
-tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
+tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
-essere specificati in quello che viene chiamato \textit{network order}, cioè
+essere specificati in quello che viene chiamato \textit{network order}, cioè
con i bit ordinati in formato \textit{big endian}, questo comporta la
-necessità di usare apposite funzioni di conversione per mantenere la
-portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
+necessità di usare apposite funzioni di conversione per mantenere la
+portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
problema e le relative soluzioni).
Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
sostanzialmente identici ai precedenti; la parte in cui si trovano
-praticamente tutte le differenze fra i due socket è quella della struttura
-degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
+praticamente tutte le differenze fra i due socket è quella della struttura
+degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
in fig.~\ref{fig:sock_sa_ipv6_struct}.
\begin{figure}[!htb]
\end{figure}
Il campo \var{sin6\_family} deve essere sempre impostato ad \const{AF\_INET6},
-il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
-il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
-bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
+il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole;
+il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24
+bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e
gli ultimi 4 sono riservati. Questi valori fanno riferimento ad alcuni campi
specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed
-il loro uso è sperimentale.
+il loro uso è sperimentale.
Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
-espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
+espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni
riguardanti il \itindex{multicast} \textit{multicasting}. Si noti infine che
\struct{sockaddr\_in6} ha una dimensione maggiore della struttura
\struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi
-occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
+occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
di contenere i dati nelle dimensioni di quest'ultima.
vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
hanno la caratteristica ulteriore di poter essere creati anche in maniera
anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
-sez.~\ref{sec:ipc_socketpair}). Quando però si vuole fare riferimento
+sez.~\ref{sec:ipc_socketpair}). Quando però si vuole fare riferimento
esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
-di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
+di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
fig.~\ref{fig:sock_sa_local_struct}.
\begin{figure}[!htb]
In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
-può essere un file (di tipo socket) nel filesystem o una stringa univoca
+può essere un file (di tipo socket) nel filesystem o una stringa univoca
(mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
specificato come una stringa (terminata da uno zero) corrispondente al
\itindex{pathname} \textit{pathname} del file; nel secondo invece
\file{netatalk} per implementare la comunicazione secondo il protocollo
AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
-kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
+kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
questo argomento principalmente per mostrare l'uso di un protocollo
alternativo.
-I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
+I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
-\func{socket} deve essere nullo. È altresì possibile usare i socket raw
+\func{socket} deve essere nullo. È altresì possibile usare i socket raw
specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
-per \param{protocol} è \const{ATPROTO\_DDP}.
+per \param{protocol} è \const{ATPROTO\_DDP}.
Gli indirizzi AppleTalk devono essere specificati tramite una struttura
-\struct{sockaddr\_atalk}, la cui definizione è riportata in
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
il file \file{netatalk/at.h}.
inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
usati solo da processi con i privilegi di amministratore o con la
\itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
-L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
-essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
-composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
+essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
valore \const{AT\_ANYNET}, che indica una rete generica e vale anche per
-indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
-può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
+indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
+può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
rete.
I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
un'interfaccia specifica di Linux per inviare e ricevere pacchetti
direttamente su un'interfaccia di rete, senza passare per le funzioni di
-gestione dei protocolli di livello superiore. In questo modo è possibile
+gestione dei protocolli di livello superiore. In questo modo è possibile
implementare dei protocolli in user space, agendo direttamente sul livello
fisico. In genere comunque si preferisce usare la libreria
-\file{pcap},\footnote{la libreria è mantenuta insieme al comando
+\file{pcap},\footnote{la libreria è mantenuta insieme al comando
\cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
progetto \href{http://www.tcpdump.org/}{\textsf{http://www.tcpdump.org/}}.}
-che assicura la portabilità su altre piattaforme, anche se con funzionalità
+che assicura la portabilità su altre piattaforme, anche se con funzionalità
ridotte.
Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
-Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
+Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
del dispositivo e viceversa. In questo modo, in fase di trasmissione, il
contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
-di questi socket è una operazione privilegiata e può essere effettuati solo da
+di questi socket è una operazione privilegiata e può essere effettuati solo da
un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
\label{fig:sock_sa_packet_struct}
\end{figure}
-Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
-\struct{sockaddr\_ll}, e la sua definizione è riportata in
-fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
+Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
+\struct{sockaddr\_ll}, e la sua definizione è riportata in
+fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
leggermente diverso rispetto a quanto visto finora per gli altri tipi di
-socket. Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
-scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
+socket. Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
+scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
\const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
e deve essere indicato in \textit{network order}, facendo uso delle costanti
-simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
-l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
-stesso tipo (se ad esempio si hanno più schede ethernet), permette di
+simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
+l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
+stesso tipo (se ad esempio si hanno più schede ethernet), permette di
selezionare quella con cui si vuole operare (un valore nullo indica qualunque
interfaccia). Questi sono i due soli campi che devono essere specificati
quando si vuole selezionare una interfaccia specifica, usando questa struttura
Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
\file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
-senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
+senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
seguenti valori: \const{PACKET\_HOST} per un pacchetto indirizzato alla
macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di
\itindex{broadcast} \textit{broadcast}, \const{PACKET\_MULTICAST} per un
Si tenga presente infine che in fase di ricezione, anche se si richiede il
troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
\func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
-lunghezza effettiva del pacchetto così come arrivato sulla linea.
+lunghezza effettiva del pacchetto così come arrivato sulla linea.
%% \subsection{La struttura degli indirizzi DECnet}
%% \label{sec:sock_sa_decnet}
%% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
%% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
-%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
+%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
%% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
%% solo come esempio
\label{sec:sock_addr_func}
In questa sezione tratteremo delle varie funzioni usate per manipolare gli
-indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
+indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
indirizzi e i numeri di porta usati nella rete devono essere forniti in
formato opportuno (il \textit{network order}). Per capire cosa significa tutto
-ciò occorre introdurre un concetto generale che tornerà utile anche in
+ciò occorre introdurre un concetto generale che tornerà utile anche in
seguito.
\label{sec:sock_endianess}
\itindbeg{endianess}
-La rappresentazione di un numero binario in un computer può essere fatta in
+La rappresentazione di un numero binario in un computer può essere fatta in
due modi, chiamati rispettivamente \textit{big endian} e \textit{little
endian} a seconda di come i singoli bit vengono aggregati per formare le
variabili intere (ed in genere in diretta corrispondenza a come sono poi in
-realtà cablati sui bus interni del computer).
+realtà cablati sui bus interni del computer).
\begin{figure}[htb]
\centering
Per capire meglio il problema si consideri un intero a 32 bit scritto in una
locazione di memoria posta ad un certo indirizzo. Come illustrato in
fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
-in due modi: a partire dal più significativo o a partire dal meno
-significativo. Così nel primo caso si troverà il byte che contiene i bit più
+in due modi: a partire dal più significativo o a partire dal meno
+significativo. Così nel primo caso si troverà il byte che contiene i bit più
significativi all'indirizzo menzionato e il byte con i bit meno significativi
-nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
-dato che si trova per prima la parte più grande. Il caso opposto, in cui si
-parte dal bit meno significativo è detto per lo stesso motivo \textit{little
+nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
+dato che si trova per prima la parte più grande. Il caso opposto, in cui si
+parte dal bit meno significativo è detto per lo stesso motivo \textit{little
endian}.
-Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+Si può allora verificare quale tipo di \textit{endianess} usa il proprio
computer con un programma elementare che si limita ad assegnare un valore ad
una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
-Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
+Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
allora se lo eseguiamo su un PC otterremo:
\begin{verbatim}
[piccardi@gont sources]$ ./endtest
La \textit{endianess} di un computer dipende essenzialmente dalla architettura
hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
-formato dei dati contenuti nelle intestazioni dei protocolli di rete è
+formato dei dati contenuti nelle intestazioni dei protocolli di rete è
anch'esso \textit{big endian}; altri esempi di uso di questi due diversi
-formati sono quello del bus PCI, che è \textit{little endian}, o quello del
-bus VME che è \textit{big endian}.
+formati sono quello del bus PCI, che è \textit{little endian}, o quello del
+bus VME che è \textit{big endian}.
Esistono poi anche dei processori che possono scegliere il tipo di formato
all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
-in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
+in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
questi cambiamenti.
\label{fig:sock_endian_code}
\end{figure}
-Per controllare quale tipo di ordinamento si ha sul proprio computer si è
-scritta una piccola funzione di controllo, il cui codice è riportato
+Per controllare quale tipo di ordinamento si ha sul proprio computer si è
+scritta una piccola funzione di controllo, il cui codice è riportato
fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
-l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
-è \textit{little endian}.
+l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
+è \textit{little endian}.
-Come si vede la funzione è molto semplice, e si limita, una volta assegnato
+Come si vede la funzione è molto semplice, e si limita, una volta assegnato
(\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
-di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
+di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
11}) il valore della seconda assumendo che il primo byte sia quello meno
-significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
\textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
il valore del confronto delle due variabili.
\itindend{endianess}
\subsection{Le funzioni per il riordinamento}
\label{sec:sock_func_ord}
-Il problema connesso \itindex{endianess} all'endianess è che quando si passano
+Il problema connesso \itindex{endianess} all'endianess è che quando si passano
dei dati da un tipo di architettura all'altra i dati vengono interpretati in
-maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
-con i due byte in cui è suddiviso scambiati di posto. Per questo motivo si
+maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
+con i due byte in cui è suddiviso scambiati di posto. Per questo motivo si
usano delle funzioni di conversione che servono a tener conto automaticamente
della possibile differenza fra l'ordinamento usato sul computer e quello che
viene usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
macchina che si sta usando abbia una architettura \textit{big endian} queste
funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
-assicurare la portabilità del codice su tutte le architetture.
+assicurare la portabilità del codice su tutte le architetture.
\subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
dei numeri IP che si usa normalmente.
Le prime tre funzioni di manipolazione riguardano la conversione degli
-indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
-cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
+indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
+cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
\texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
-tipicamente sono trentadue bit a uno. Questo però comporta che la stringa
-\texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
-con questa funzione; per questo motivo essa è generalmente deprecata in favore
+tipicamente sono trentadue bit a uno. Questo però comporta che la stringa
+\texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
+con questa funzione; per questo motivo essa è generalmente deprecata in favore
di \func{inet\_aton}.
La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
nell'indirizzo binario che viene memorizzato nell'opportuna struttura
\struct{in\_addr} (si veda fig.~\ref{fig:sock_sa_ipv4_struct}) situata
-all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
+all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
modo da poterla usare direttamente con il puntatore usato per passare la
struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1
in caso di fallimento. Se usata con \param{dest} inizializzato a \val{NULL}
dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
alla stringa che contiene l'espressione in formato dotted decimal. Si deve
tenere presente che la stringa risiede in memoria statica, per cui questa
-funzione non è \index{funzioni!rientranti} rientrante.
+funzione non è \index{funzioni!rientranti} rientrante.
\subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
\label{sec:sock_conv_func_gen}
Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
-motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
+motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
\func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
e \textit{numeric}.
Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
-indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
+indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
-indirizzo; il suo prototipo è:
+indirizzo; il suo prototipo è:
\begin{prototype}{sys/socket.h}
{int inet\_pton(int af, const char *src, void *addr\_ptr)}
rappresenta un indirizzo valido, e negativo se \param{af} specifica una
famiglia di indirizzi non valida.
-La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
-indirizzo in una stringa; il suo prototipo è:
+La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
+indirizzo in una stringa; il suo prototipo è:
\begin{prototype}{sys/socket.h}
{char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
\begin{errlist}
\item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
dell'indirizzo eccedono la lunghezza specificata da \param{len}.
- \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
+ \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
una valida.
\end{errlist}}
\end{prototype}
(una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
per IPv6), che devono essere precedentemente allocate e passate attraverso il
puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
-può essere nullo e deve essere allocato precedentemente.
+può essere nullo e deve essere allocato precedentemente.
-Il formato usato per gli indirizzi in formato di presentazione è la notazione
+Il formato usato per gli indirizzi in formato di presentazione è la notazione
\textit{dotted decimal} per IPv4 e quello descritto in
sez.~\ref{sec:IP_ipv6_notation} per IPv6.
\chapter{La gestione del sistema, del tempo e degli errori}
\label{cha:system}
-In questo capitolo tratteremo varie interfacce che attengono agli aspetti più
+In questo capitolo tratteremo varie interfacce che attengono agli aspetti più
generali del sistema, come quelle per la gestione dei parametri e della
configurazione dello stesso, quelle per la lettura dei limiti e delle
caratteristiche, quelle per il controllo dell'uso delle risorse dei processi,
-\section{Capacità e caratteristiche del sistema}
+\section{Capacità e caratteristiche del sistema}
\label{sec:sys_characteristics}
-In questa sezione tratteremo le varie modalità con cui un programma può
-ottenere informazioni riguardo alle capacità del sistema. Ogni sistema
-unix-like infatti è contraddistinto da un gran numero di limiti e costanti che
+In questa sezione tratteremo le varie modalità con cui un programma può
+ottenere informazioni riguardo alle capacità del sistema. Ogni sistema
+unix-like infatti è contraddistinto da un gran numero di limiti e costanti che
lo caratterizzano, e che possono dipendere da fattori molteplici, come
l'architettura hardware, l'implementazione del kernel e delle librerie, le
opzioni di configurazione.
La definizione di queste caratteristiche ed il tentativo di provvedere dei
-meccanismi generali che i programmi possono usare per ricavarle è uno degli
-aspetti più complessi e controversi con cui le diverse standardizzazioni si
+meccanismi generali che i programmi possono usare per ricavarle è uno degli
+aspetti più complessi e controversi con cui le diverse standardizzazioni si
sono dovute confrontare, spesso con risultati spesso tutt'altro che chiari.
Daremo comunque una descrizione dei principali metodi previsti dai vari
standard per ricavare sia le caratteristiche specifiche del sistema, che
\label{sec:sys_limits}
Quando si devono determinare le caratteristiche generali del sistema ci si
-trova di fronte a diverse possibilità; alcune di queste infatti possono
+trova di fronte a diverse possibilità; alcune di queste infatti possono
dipendere dall'architettura dell'hardware (come le dimensioni dei tipi
interi), o dal sistema operativo (come la presenza o meno del gruppo degli
identificatori \textit{saved}), altre invece possono dipendere dalle opzioni
-con cui si è costruito il sistema (ad esempio da come si è compilato il
+con cui si è costruito il sistema (ad esempio da come si è compilato il
kernel), o dalla configurazione del medesimo; per questo motivo in generale
-sono necessari due tipi diversi di funzionalità:
+sono necessari due tipi diversi di funzionalità:
\begin{itemize*}
-\item la possibilità di determinare limiti ed opzioni al momento della
+\item la possibilità di determinare limiti ed opzioni al momento della
compilazione.
-\item la possibilità di determinare limiti ed opzioni durante l'esecuzione.
+\item la possibilità di determinare limiti ed opzioni durante l'esecuzione.
\end{itemize*}
-La prima funzionalità si può ottenere includendo gli opportuni header file che
+La prima funzionalità si può ottenere includendo gli opportuni header file che
contengono le costanti necessarie definite come macro di preprocessore, per la
-seconda invece sono ovviamente necessarie delle funzioni. La situazione è
+seconda invece sono ovviamente necessarie delle funzioni. La situazione è
complicata dal fatto che ci sono molti casi in cui alcuni di questi limiti
sono fissi in un'implementazione mentre possono variare in un altra. Tutto
-questo crea una ambiguità che non è sempre possibile risolvere in maniera
-chiara; in generale quello che succede è che quando i limiti del sistema sono
+questo crea una ambiguità che non è sempre possibile risolvere in maniera
+chiara; in generale quello che succede è che quando i limiti del sistema sono
fissi essi vengono definiti come macro di preprocessore nel file
-\file{limits.h}, se invece possono variare, il loro valore sarà ottenibile
+\file{limits.h}, se invece possono variare, il loro valore sarà ottenibile
tramite la funzione \func{sysconf} (che esamineremo in
sez.~\ref{sec:sys_sysconf}).
Lo standard ANSI C definisce dei limiti che sono tutti fissi, pertanto questo
saranno sempre disponibili al momento della compilazione. Un elenco, ripreso
-da \file{limits.h}, è riportato in tab.~\ref{tab:sys_ansic_macro}. Come si può
+da \file{limits.h}, è riportato in tab.~\ref{tab:sys_ansic_macro}. Come si può
vedere per la maggior parte questi limiti attengono alle dimensioni dei dati
interi, che sono in genere fissati dall'architettura hardware (le analoghe
informazioni per i dati in virgola mobile sono definite a parte, ed
accessibili includendo \file{float.h}). Lo standard prevede anche un'altra
-costante, \const{FOPEN\_MAX}, che può non essere fissa e che pertanto non è
+costante, \const{FOPEN\_MAX}, che può non essere fissa e che pertanto non è
definita in \file{limits.h}; essa deve essere definita in \file{stdio.h} ed
avere un valore minimo di 8.
\const{ULONG\_MAX}& 4294967295 & Massimo di \ctyp{unsigned long}.\\
\hline
\end{tabular}
- \caption{Costanti definite in \file{limits.h} in conformità allo standard
+ \caption{Costanti definite in \file{limits.h} in conformità allo standard
ANSI C.}
\label{tab:sys_ansic_macro}
\end{table}
-\footnotetext[1]{il valore può essere 0 o \const{SCHAR\_MIN} a seconda che il
+\footnotetext[1]{il valore può essere 0 o \const{SCHAR\_MIN} a seconda che il
sistema usi caratteri con segno o meno.}
-\footnotetext[2]{il valore può essere \const{UCHAR\_MAX} o \const{SCHAR\_MAX}
+\footnotetext[2]{il valore può essere \const{UCHAR\_MAX} o \const{SCHAR\_MAX}
a seconda che il sistema usi caratteri con segno o meno.}
A questi valori lo standard ISO C90 ne aggiunge altri tre, relativi al tipo
Massimo di \ctyp{unsigned long long}.\\
\hline
\end{tabular}
- \caption{Macro definite in \file{limits.h} in conformità allo standard
+ \caption{Macro definite in \file{limits.h} in conformità allo standard
ISO C90.}
\label{tab:sys_isoc90_macro}
\end{table}
limiti relativi alle caratteristiche dei file che vedremo in
sez.~\ref{sec:sys_file_limits}.
-Purtroppo la sezione dello standard che tratta questi argomenti è una delle
+Purtroppo la sezione dello standard che tratta questi argomenti è una delle
meno chiare\footnote{tanto che Stevens, in \cite{APUE}, la porta come esempio
di ``\textsl{standardese}''.}. Lo standard prevede che ci siano 13 macro che
descrivono le caratteristiche del sistema (7 per le caratteristiche generiche,
passati ad una funzione della famiglia
\func{exec}.\\
\const{CHILD\_MAX} & 999& Numero massimo di processi contemporanei
- che un utente può eseguire.\\
+ che un utente può eseguire.\\
\const{OPEN\_MAX} & 256& Numero massimo di file che un processo
- può mantenere aperti in contemporanea.\\
+ può mantenere aperti in contemporanea.\\
\const{STREAM\_MAX}& 8& Massimo numero di stream aperti per
processo in contemporanea.\\
\const{TZNAME\_MAX}& 6& Dimensione massima del nome di una
Lo standard dice che queste macro devono essere definite in \file{limits.h}
quando i valori a cui fanno riferimento sono fissi, e altrimenti devono essere
lasciate indefinite, ed i loro valori dei limiti devono essere accessibili
-solo attraverso \func{sysconf}. In realtà queste vengono sempre definite ad
+solo attraverso \func{sysconf}. In realtà queste vengono sempre definite ad
un valore generico. Si tenga presente poi che alcuni di questi limiti possono
-assumere valori molto elevati (come \const{CHILD\_MAX}), e non è pertanto il
+assumere valori molto elevati (come \const{CHILD\_MAX}), e non è pertanto il
caso di utilizzarli per allocare staticamente della memoria.
A complicare la faccenda si aggiunge il fatto che POSIX.1 prevede una serie di
altre costanti (il cui nome inizia sempre con \code{\_POSIX\_}) che
-definiscono i valori minimi le stesse caratteristiche devono avere, perché una
+definiscono i valori minimi le stesse caratteristiche devono avere, perché una
implementazione possa dichiararsi conforme allo standard; detti valori sono
riportati in tab.~\ref{tab:sys_posix1_general}.
passati ad una funzione della famiglia
\func{exec}.\\
\const{\_POSIX\_CHILD\_MAX} & 6& Numero massimo di processi
- contemporanei che un utente può
+ contemporanei che un utente può
eseguire.\\
\const{\_POSIX\_OPEN\_MAX} & 16& Numero massimo di file che un processo
- può mantenere aperti in
+ può mantenere aperti in
contemporanea.\\
\const{\_POSIX\_STREAM\_MAX} & 8& Massimo numero di stream aperti per
processo in contemporanea.\\
\hline
\end{tabular}
\caption{Macro dei valori minimi delle caratteristiche generali del sistema
- per la conformità allo standard POSIX.1.}
+ per la conformità allo standard POSIX.1.}
\label{tab:sys_posix1_general}
\end{table}
-In genere questi valori non servono a molto, la loro unica utilità è quella di
-indicare un limite superiore che assicura la portabilità senza necessità di
+In genere questi valori non servono a molto, la loro unica utilità è quella di
+indicare un limite superiore che assicura la portabilità senza necessità di
ulteriori controlli. Tuttavia molti di essi sono ampiamente superati in tutti
-i sistemi POSIX in uso oggigiorno. Per questo è sempre meglio utilizzare i
+i sistemi POSIX in uso oggigiorno. Per questo è sempre meglio utilizzare i
valori ottenuti da \func{sysconf}.
\begin{table}[htb]
199009L).\\
\hline
\end{tabular}
- \caption{Alcune macro definite in \file{limits.h} in conformità allo standard
+ \caption{Alcune macro definite in \file{limits.h} in conformità allo standard
POSIX.1.}
\label{tab:sys_posix1_other}
\end{table}
Oltre ai precedenti valori (e a quelli relativi ai file elencati in
tab.~\ref{tab:sys_posix1_file}), che devono essere obbligatoriamente definiti,
lo standard POSIX.1 ne prevede parecchi altri. La lista completa si trova
-dall'header file \file{bits/posix1\_lim.h} (da non usare mai direttamente, è
+dall'header file \file{bits/posix1\_lim.h} (da non usare mai direttamente, è
incluso automaticamente all'interno di \file{limits.h}). Di questi vale la
pena menzionare alcune macro di uso comune, (riportate in
tab.~\ref{tab:sys_posix1_other}), che non indicano un valore specifico, ma
-denotano la presenza di alcune funzionalità nel sistema (come il supporto del
+denotano la presenza di alcune funzionalità nel sistema (come il supporto del
\textit{job control} o degli identificatori del gruppo \textit{saved}).
Oltre allo standard POSIX.1, anche lo standard POSIX.2 definisce una serie di
\label{sec:sys_sysconf}
Come accennato in sez.~\ref{sec:sys_limits} quando uno dei limiti o delle
-caratteristiche del sistema può variare, per non dover essere costretti a
-ricompilare un programma tutte le volte che si cambiano le opzioni con cui è
-compilato il kernel, o alcuni dei parametri modificabili a run time, è
+caratteristiche del sistema può variare, per non dover essere costretti a
+ricompilare un programma tutte le volte che si cambiano le opzioni con cui è
+compilato il kernel, o alcuni dei parametri modificabili a run time, è
necessario ottenerne il valore attraverso la funzione \funcd{sysconf}. Il
-prototipo di questa funzione è:
+prototipo di questa funzione è:
\begin{prototype}{unistd.h}{long sysconf(int name)}
Restituisce il valore del parametro di sistema \param{name}.
\bodydesc{La funzione restituisce indietro il valore del parametro
richiesto, o 1 se si tratta di un'opzione disponibile, 0 se l'opzione non
- è disponibile e -1 in caso di errore (ma \var{errno} non viene impostata).}
+ è disponibile e -1 in caso di errore (ma \var{errno} non viene impostata).}
\end{prototype}
La funzione prende come argomento un intero che specifica quale dei limiti si
vuole conoscere; uno specchietto contenente i principali valori disponibili in
-Linux è riportato in tab.~\ref{tab:sys_sysconf_par}; l'elenco completo è
-contenuto in \file{bits/confname.h}, ed una lista più esaustiva, con le
-relative spiegazioni, si può trovare nel manuale delle \acr{glibc}.
+Linux è riportato in tab.~\ref{tab:sys_sysconf_par}; l'elenco completo è
+contenuto in \file{bits/confname.h}, ed una lista più esaustiva, con le
+relative spiegazioni, si può trovare nel manuale delle \acr{glibc}.
\begin{table}[htb]
\centering
ad una funzione della famiglia \func{exec}.\\
\texttt{\_SC\_CHILD\_MAX} & \const{\_CHILD\_MAX}&
Il numero massimo di processi contemporanei
- che un utente può eseguire.\\
+ che un utente può eseguire.\\
\texttt{\_SC\_OPEN\_MAX} & \const{\_OPEN\_MAX}&
- Il numero massimo di file che un processo può
+ Il numero massimo di file che un processo può
mantenere aperti in contemporanea.\\
\texttt{\_SC\_STREAM\_MAX}& \const{STREAM\_MAX}&
Il massimo numero di stream che un processo
- può mantenere aperti in contemporanea. Questo
+ può mantenere aperti in contemporanea. Questo
limite previsto anche dallo standard ANSI C,
che specifica la macro {FOPEN\_MAX}.\\
\texttt{\_SC\_TZNAME\_MAX}& \const{TZNAME\_MAX}&
sez.~\ref{sec:sys_date}).\\
\texttt{\_SC\_NGROUPS\_MAX}&\const{NGROUP\_MAX}&
Massimo numero di gruppi supplementari che
- può avere un processo (vedi
+ può avere un processo (vedi
sez.~\ref{sec:proc_access_id}).\\
\texttt{\_SC\_SSIZE\_MAX} & \const{SSIZE\_MAX}&
Valore massimo del tipo di dato
\texttt{\_SC\_CLK\_TCK} & \const{CLK\_TCK} &
Il numero di \itindex{clock~tick}
\textit{clock tick} al secondo,
- cioè l'unità di misura del
+ cioè l'unità di misura del
\itindex{process~time} \textit{process
time} (vedi
sez.~\ref{sec:sys_unix_time}).\\
\texttt{\_SC\_JOB\_CONTROL}&\macro{\_POSIX\_JOB\_CONTROL}&
- Indica se è supportato il \textit{job
+ Indica se è supportato il \textit{job
control} (vedi
sez.~\ref{sec:sess_job_control}) in stile
POSIX.\\
Indica il mese e l'anno di approvazione
della revisione dello standard POSIX.1 a cui
il sistema fa riferimento, nel formato
- YYYYMML, la revisione più recente è 199009L,
+ YYYYMML, la revisione più recente è 199009L,
che indica il Settembre 1990.\\
\hline
\end{tabular}
\label{tab:sys_sysconf_par}
\end{table}
-In generale ogni limite o caratteristica del sistema per cui è definita una
-macro, sia dagli standard ANSI C e ISO C90, che da POSIX.1 e POSIX.2, può
-essere ottenuto attraverso una chiamata a \func{sysconf}. Il valore si otterrà
+In generale ogni limite o caratteristica del sistema per cui è definita una
+macro, sia dagli standard ANSI C e ISO C90, che da POSIX.1 e POSIX.2, può
+essere ottenuto attraverso una chiamata a \func{sysconf}. Il valore si otterrà
specificando come valore dell'argomento \param{name} il nome ottenuto
aggiungendo \code{\_SC\_} ai nomi delle macro definite dai primi due, o
sostituendolo a \code{\_POSIX\_} per le macro definite dagli gli altri due.
In generale si dovrebbe fare uso di \func{sysconf} solo quando la relativa
-macro non è definita, quindi con un codice analogo al seguente:
+macro non è definita, quindi con un codice analogo al seguente:
\includecodesnip{listati/get_child_max.c}
-ma in realtà in Linux queste macro sono comunque definite, indicando però un
-limite generico. Per questo motivo è sempre meglio usare i valori restituiti
+ma in realtà in Linux queste macro sono comunque definite, indicando però un
+limite generico. Per questo motivo è sempre meglio usare i valori restituiti
da \func{sysconf}.
\hline
\end{tabular}
\caption{Costanti dei valori minimi delle caratteristiche dei file per la
- conformità allo standard POSIX.1.}
+ conformità allo standard POSIX.1.}
\label{tab:sys_posix1_file}
\end{table}
Tutti questi limiti sono definiti in \file{limits.h}; come nel caso precedente
-il loro uso è di scarsa utilità in quanto ampiamente superati in tutte le
+il loro uso è di scarsa utilità in quanto ampiamente superati in tutte le
implementazioni moderne.
\subsection{La funzione \func{pathconf}}
\label{sec:sys_pathconf}
-In generale i limiti per i file sono molto più soggetti ad essere variabili
+In generale i limiti per i file sono molto più soggetti ad essere variabili
rispetto ai limiti generali del sistema; ad esempio parametri come la
lunghezza del nome del file o il numero di link possono variare da filesystem
a filesystem; per questo motivo questi limiti devono essere sempre controllati
-con la funzione \funcd{pathconf}, il cui prototipo è:
+con la funzione \funcd{pathconf}, il cui prototipo è:
\begin{prototype}{unistd.h}{long pathconf(char *path, int name)}
Restituisce il valore del parametro \param{name} per il file \param{path}.
\end{prototype}
E si noti come la funzione in questo caso richieda un argomento che specifichi
-a quale file si fa riferimento, dato che il valore del limite cercato può
+a quale file si fa riferimento, dato che il valore del limite cercato può
variare a seconda del filesystem. Una seconda versione della funzione,
\funcd{fpathconf}, opera su un file descriptor invece che su un
-\itindex{pathname} \textit{pathname}. Il suo prototipo è:
+\itindex{pathname} \textit{pathname}. Il suo prototipo è:
\begin{prototype}{unistd.h}{long fpathconf(int fd, int name)}
Restituisce il valore del parametro \param{name} per il file \param{fd}.
- \bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor
+ \bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor
invece di un \itindex{pathname} \textit{pathname}; pertanto gli errori
restituiti cambiano di conseguenza.}
\end{prototype}
-\noindent ed il suo comportamento è identico a quello di \func{pathconf}.
+\noindent ed il suo comportamento è identico a quello di \func{pathconf}.
\subsection{La funzione \func{uname}}
\label{sec:sys_uname}
-Un'altra funzione che si può utilizzare per raccogliere informazioni sia
-riguardo al sistema che al computer su cui esso sta girando è \funcd{uname};
-il suo prototipo è:
+Un'altra funzione che si può utilizzare per raccogliere informazioni sia
+riguardo al sistema che al computer su cui esso sta girando è \funcd{uname};
+il suo prototipo è:
\begin{prototype}{sys/utsname.h}{int uname(struct utsname *info)}
Restituisce informazioni sul sistema nella struttura \param{info}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà il valore \errval{EFAULT}.}
+ fallimento, nel qual caso \var{errno} assumerà il valore \errval{EFAULT}.}
\end{prototype}
La funzione, che viene usata dal comando \cmd{uname}, restituisce le
-informazioni richieste nella struttura \param{info}; anche questa struttura è
+informazioni richieste nella struttura \param{info}; anche questa struttura è
definita in \file{sys/utsname.h}, secondo quanto mostrato in
fig.~\ref{fig:sys_utsname}, e le informazioni memorizzate nei suoi membri
indicano rispettivamente:
\item il nome della stazione;
\item il nome del domino.
\end{itemize*}
-l'ultima informazione è stata aggiunta di recente e non è prevista dallo
-standard POSIX, essa è accessibile, come mostrato in
+l'ultima informazione è stata aggiunta di recente e non è prevista dallo
+standard POSIX, essa è accessibile, come mostrato in
fig.~\ref{fig:sys_utsname}, solo definendo \macro{\_GNU\_SOURCE}.
\begin{figure}[!htb]
\end{figure}
In generale si tenga presente che le dimensioni delle stringhe di una
-struttura \struct{utsname} non è specificata, e che esse sono sempre terminate
+struttura \struct{utsname} non è specificata, e che esse sono sempre terminate
con NUL; il manuale delle \acr{glibc} indica due diverse dimensioni,
\const{\_UTSNAME\_LENGTH} per i campi standard e
\const{\_UTSNAME\_DOMAIN\_LENGTH} per quello specifico per il nome di dominio;
altri sistemi usano nomi diversi come \const{SYS\_NMLN} o \const{\_SYS\_NMLN}
o \const{UTSLEN} che possono avere valori diversi.\footnote{nel caso di Linux
- \func{uname} corrisponde in realtà a 3 system call diverse, le prime due
+ \func{uname} corrisponde in realtà a 3 system call diverse, le prime due
usano rispettivamente delle lunghezze delle stringhe di 9 e 65 byte; la
terza usa anch'essa 65 byte, ma restituisce anche l'ultimo campo,
\var{domainname}, con una lunghezza di 257 byte.}
Come abbiamo accennato nella sezione precedente, non tutti i limiti che
caratterizzano il sistema sono fissi, o perlomeno non lo sono in tutte le
-implementazioni. Finora abbiamo visto come si può fare per leggerli, ci manca
+implementazioni. Finora abbiamo visto come si può fare per leggerli, ci manca
di esaminare il meccanismo che permette, quando questi possono variare durante
l'esecuzione del sistema, di modificarli.
Inoltre, al di la di quelli che possono essere limiti caratteristici previsti
-da uno standard, ogni sistema può avere una sua serie di altri parametri di
+da uno standard, ogni sistema può avere una sua serie di altri parametri di
configurazione, che, non essendo mai fissi e variando da sistema a sistema,
non sono stati inclusi nella standardizzazione della sezione precedente. Per
questi occorre, oltre al meccanismo di impostazione, pure un meccanismo di
\label{sec:sys_sysctl}
La funzione che permette la lettura ed l'impostazione dei parametri del
-sistema è \funcd{sysctl}; è una funzione derivata da BSD4.4, ma
-l'implementazione è specifica di Linux; il suo prototipo è:
+sistema è \funcd{sysctl}; è una funzione derivata da BSD4.4, ma
+l'implementazione è specifica di Linux; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int sysctl(int *name, int nlen, void *oldval, size\_t *oldlenp, void
Legge o scrive uno dei parametri di sistema.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] non si ha il permesso di accedere ad uno dei
componenti nel cammino specificato per il parametro, o di accedere al
- parametro nella modalità scelta.
+ parametro nella modalità scelta.
\item[\errcode{ENOTDIR}] non esiste un parametro corrispondente al nome
\param{name}.
-% \item[\errcode{EFAULT}] si è specificato \param{oldlenp} zero quando
-% \param{oldval} è non nullo.
- \item[\errcode{EINVAL}] o si è specificato un valore non valido per il
+% \item[\errcode{EFAULT}] si è specificato \param{oldlenp} zero quando
+% \param{oldval} è non nullo.
+ \item[\errcode{EINVAL}] o si è specificato un valore non valido per il
parametro che si vuole impostare o lo spazio provvisto per il ritorno di un
- valore non è delle giuste dimensioni.
- \item[\errcode{ENOMEM}] talvolta viene usato più correttamente questo errore
- quando non si è specificato sufficiente spazio per ricevere il valore di un
+ valore non è delle giuste dimensioni.
+ \item[\errcode{ENOMEM}] talvolta viene usato più correttamente questo errore
+ quando non si è specificato sufficiente spazio per ricevere il valore di un
parametro.
\end{errlist}
ed inoltre \errval{EFAULT}.
maniera gerarchica all'interno di un albero;\footnote{si tenga presente che
includendo solo \file{unistd.h}, saranno definiti solo i parametri generici;
dato che ce ne sono molti specifici dell'implementazione, nel caso di Linux
- occorrerà includere anche i file \file{linux/unistd.h} e
+ occorrerà includere anche i file \file{linux/unistd.h} e
\file{linux/sysctl.h}.} per accedere ad uno di essi occorre specificare un
cammino attraverso i vari nodi dell'albero, in maniera analoga a come avviene
per la risoluzione di un \itindex{pathname} \textit{pathname} (da cui l'uso
alternativo del filesystem \file{/proc}, che vedremo dopo).
-Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
-arriva ad identificare un parametro specifico è passato alla funzione
+Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
+arriva ad identificare un parametro specifico è passato alla funzione
attraverso l'array \param{name}, di lunghezza \param{nlen}, che contiene la
sequenza dei vari nodi da attraversare. Ogni parametro ha un valore in un
-formato specifico che può essere un intero, una stringa o anche una struttura
+formato specifico che può essere un intero, una stringa o anche una struttura
complessa, per questo motivo i valori vengono passati come puntatori
\ctyp{void}.
-L'indirizzo a cui il valore corrente del parametro deve essere letto è
-specificato da \param{oldvalue}, e lo spazio ivi disponibile è specificato da
+L'indirizzo a cui il valore corrente del parametro deve essere letto è
+specificato da \param{oldvalue}, e lo spazio ivi disponibile è specificato da
\param{oldlenp} (passato come puntatore per avere indietro la dimensione
-effettiva di quanto letto); il valore che si vuole impostare nel sistema è
+effettiva di quanto letto); il valore che si vuole impostare nel sistema è
passato in \param{newval} e la sua dimensione in \param{newlen}.
-Si può effettuare anche una lettura e scrittura simultanea, nel qual caso il
-valore letto restituito dalla funzione è quello precedente alla scrittura.
+Si può effettuare anche una lettura e scrittura simultanea, nel qual caso il
+valore letto restituito dalla funzione è quello precedente alla scrittura.
I parametri accessibili attraverso questa funzione sono moltissimi, e possono
essere trovati in \file{sysctl.h}, essi inoltre dipendono anche dallo stato
corrente del kernel (ad esempio dai moduli che sono stati caricati nel
sistema) e in genere i loro nomi possono variare da una versione di kernel
-all'altra; per questo è sempre il caso di evitare l'uso di \func{sysctl}
-quando esistono modalità alternative per ottenere le stesse informazioni.
+all'altra; per questo è sempre il caso di evitare l'uso di \func{sysctl}
+quando esistono modalità alternative per ottenere le stesse informazioni.
Alcuni esempi di parametri ottenibili sono:
\begin{itemize}
\item il nome di dominio
\item il numero massimo di file aperti
\end{itemize}
-Come accennato in Linux si ha una modalità alternativa per accedere alle
+Come accennato in Linux si ha una modalità alternativa per accedere alle
stesse informazioni di \func{sysctl} attraverso l'uso del filesystem
-\file{/proc}. Questo è un filesystem virtuale, generato direttamente dal
+\file{/proc}. Questo è un filesystem virtuale, generato direttamente dal
kernel, che non fa riferimento a nessun dispositivo fisico, ma presenta in
forma di file alcune delle strutture interne del kernel stesso.
In particolare l'albero dei valori di \func{sysctl} viene presentato in forma
-di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
+di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
specificando un \itindex{pathname} \textit{pathname} e leggendo e scrivendo sul
file corrispondente al parametro scelto. Il kernel si occupa di generare al
volo il contenuto ed i nomi dei file corrispondenti, e questo ha il grande
e di permettere la navigazione dell'albero dei valori.
Alcune delle corrispondenze dei file presenti in \file{/proc/sys} con i valori
-di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
+di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
in \file{linux/sysctl.h},\footnote{indicando un file di definizioni si fa
riferimento alla directory standard dei file di include, che in ogni
- distribuzione che si rispetti è \file{/usr/include}.} la informazione
-disponibile in \file{/proc/sys} è riportata inoltre nella documentazione
+ distribuzione che si rispetti è \file{/usr/include}.} la informazione
+disponibile in \file{/proc/sys} è riportata inoltre nella documentazione
inclusa nei sorgenti del kernel, nella directory \file{Documentation/sysctl}.
Ma oltre alle informazioni ottenibili da \func{sysctl} dentro \file{proc} sono
-\subsection{La gestione delle proprietà dei filesystem}
+\subsection{La gestione delle proprietà dei filesystem}
\label{sec:sys_file_config}
Come accennato in sez.~\ref{sec:file_organization} per poter accedere ai file
occorre prima rendere disponibile al sistema il filesystem su cui essi sono
-memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica
- di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui
-prototipo è:
+memorizzati; l'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica
+ di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui
+prototipo è:
\begin{prototype}{sys/mount.h}
{mount(const char *source, const char *target, const char *filesystemtype,
unsigned long mountflags, const void *data)}
essere restituiti in \var{errno} sono:
\begin{errlist}
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{ENODEV}] \param{filesystemtype} non esiste o non è configurato
+ \item[\errcode{ENODEV}] \param{filesystemtype} non esiste o non è configurato
nel kernel.
- \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
+ \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
\param{source} quando era richiesto.
- \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
- rimontato in read-only perché ci sono ancora file aperti in scrittura, o
- \param{target} è ancora in uso.
+ \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
+ rimontato in read-only perché ci sono ancora file aperti in scrittura, o
+ \param{target} è ancora in uso.
\item[\errcode{EINVAL}] il device \param{source} presenta un
- \textit{superblock} non valido, o si è cercato di rimontare un filesystem
+ \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{/}.
+ \textit{mount point} o di spostarlo quando \param{target} non è un
+ \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
+ componenti del \itindex{pathname} \textit{pathname}, o si è cercato
di montare un filesystem disponibile in sola lettura senza averlo
- specificato o il device \param{source} è su un filesystem montato con
+ specificato o il device \param{source} è su un filesystem montato con
l'opzione \const{MS\_NODEV}.
\item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
- device \param{source} è sbagliato.
- \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+ device \param{source} è sbagliato.
+ \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
\end{errlist}
ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
\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 è
+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 virtual filesystem vista in sez.~\ref{sec:file_vfs} è molto
-più flessibile e può essere usata anche per oggetti diversi da un disco. Ad
-esempio usando il \textit{loop device} si può montare un file qualunque (come
+Ma la struttura del virtual filesystem vista in sez.~\ref{sec:file_vfs} è molto
+più flessibile e può essere usata anche per oggetti diversi da un disco. Ad
+esempio usando il \textit{loop device} si può montare un file qualunque (come
l'immagine di un CD-ROM o di un floppy) che contiene un filesystem, inoltre
alcuni filesystem, come \file{proc} o \file{devfs} sono del tutto virtuali, i
loro dati sono generati al volo ad ogni lettura, e passati al kernel ad ogni
scrittura.
-Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
+Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
una delle stringhe riportate nel file \procfile{/proc/filesystems}, che
contiene l'elenco dei filesystem supportati dal kernel; nel caso si sia
indicato uno dei filesystem virtuali, il contenuto di \param{source} viene
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
+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
+\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
-contenuto dell'ultimo filesystem montato sarà visibile).
+contenuto dell'ultimo filesystem montato sarà visibile).
-Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
-attivate o meno, alcune di queste sono generali (anche se non è detto siano
+Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
+attivate o meno, alcune di queste sono generali (anche se non è detto siano
disponibili in ogni filesystem), e vengono specificate come opzioni di
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
+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
\end{table}
% TODO aggiornare con i nuovi flag di man mount
-% gli S_* non esistono più come segnalato da Alessio...
+% gli S_* non esistono più come segnalato da Alessio...
% verificare i readonly mount bind del 2.6.26
Per l'impostazione delle caratteristiche particolari di ciascun filesystem si
usa invece l'argomento \param{data} che serve per passare le ulteriori
informazioni necessarie, che ovviamente variano da filesystem a filesystem.
-La funzione \func{mount} può essere utilizzata anche per effettuare il
+La funzione \func{mount} può essere utilizzata anche per effettuare il
\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
alcune delle caratteristiche di funzionamento (ad esempio passare da sola
-lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
+lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che
deve essere effettuato il rimontaggio del filesystem (con le opzioni
specificate dagli altri bit), anche in questo caso il valore di \param{source}
viene ignorato.
-Una volta che non si voglia più utilizzare un certo filesystem è possibile
-\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
+Una volta che non si voglia più utilizzare un certo filesystem è possibile
+\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
\begin{prototype}{sys/mount.h}{umount(const char *target)}
Smonta il filesystem montato sulla directory \param{target}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà uno dei valori:
+ fallimento, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
processo, o contiene dei file aperti, o un altro mount point.
\end{errlist}
ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
\errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
\end{prototype}
-\noindent la funzione prende il nome della directory su cui il filesystem è
-montato e non il file o il dispositivo che è stato montato,\footnote{questo è
+\noindent la funzione prende il nome della directory su cui il filesystem è
+montato e non il file o il dispositivo che è stato montato,\footnote{questo è
vero a partire dal kernel 2.3.99-pre7, prima esistevano due chiamate
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
+ 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.
-Si tenga presente che la funzione fallisce quando il filesystem è
+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}.
+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
-risulti occupato; il suo prototipo è:
+risulti occupato; il suo prototipo è:
\begin{prototype}{sys/mount.h}{umount2(const char *target, int flags)}
- La funzione è identica a \func{umount} per comportamento e codici di errore,
- ma con \param{flags} si può specificare se forzare lo smontaggio.
+ La funzione è identica a \func{umount} per comportamento e codici di errore,
+ ma con \param{flags} si può specificare se forzare lo smontaggio.
\end{prototype}
-Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
-definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
-Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
-anche se è occupato per via di una delle condizioni descritte in precedenza. A
+Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
+definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
+Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
+anche se è occupato per via di una delle condizioni descritte in precedenza. A
seconda del tipo di filesystem alcune (o tutte) possono essere superate,
evitando l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio
viene eseguita una sincronizzazione dei dati.
\funcdecl{int fstatfs(int fd, struct statfs *buf)}
- Restituisce in \param{buf} le informazioni relative al filesystem su cui è
+ Restituisce in \param{buf} le informazioni relative al filesystem su cui è
posto il file specificato.
\bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non
supporta la funzione.
filesystem in esame sono impostati a zero. I valori del campo \var{f\_type}
sono definiti per i vari filesystem nei relativi file di header dei sorgenti
del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in
-genere è il nome del filesystem stesso.
+genere è il nome del filesystem stesso.
\begin{figure}[!htb]
\footnotesize \centering
In generale si dovrebbero usare queste funzioni (in particolare quelle
relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che
-effettua il montaggio di un filesystem; in realtà in questi casi è molto più
+effettua il montaggio di un filesystem; in realtà in questi casi è molto più
semplice invocare direttamente il programma \cmd{mount}, per cui ne
tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
\cite{glibc} per la documentazione completa.
Tradizionalmente le informazioni utilizzate nella gestione di utenti e gruppi
(password, corrispondenze fra nomi simbolici e user-id, home directory, ecc.)
venivano registrate all'interno dei due file di testo \conffile{/etc/passwd}
-ed \conffile{/etc/group},\footnote{in realtà oltre a questi nelle
- distribuzioni più recenti è stato introdotto il sistema delle \textit{shadow
+ed \conffile{/etc/group},\footnote{in realtà oltre a questi nelle
+ distribuzioni più recenti è stato introdotto il sistema delle \textit{shadow
password} che prevede anche i due file \conffile{/etc/shadow} e
\conffile{/etc/gshadow}, in cui sono state spostate le informazioni di
autenticazione (ed inserite alcune estensioni) per toglierle dagli altri
file che devono poter essere letti per poter effettuare l'associazione fra
- username e \acr{uid}.} il cui formato è descritto dalle relative pagine del
+ username e \acr{uid}.} il cui formato è descritto dalle relative pagine del
manuale\footnote{nella quinta sezione, quella dei file di configurazione,
- occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la
+ occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la
pagina di manuale del comando \cmd{passwd}.} e tutte le funzioni che
richiedevano l'accesso a queste informazione andavano a leggere direttamente
il contenuto di questi file.
-Col tempo però questa impostazione ha incominciato a mostrare dei limiti: da
-una parte il meccanismo classico di autenticazione è stato ampliato, ed oggi
+Col tempo però questa impostazione ha incominciato a mostrare dei limiti: da
+una parte il meccanismo classico di autenticazione è stato ampliato, ed oggi
la maggior parte delle distribuzioni di GNU/Linux usa la libreria PAM (sigla
che sta per \textit{Pluggable Authentication Method}) che fornisce una
interfaccia comune per i processi di autenticazione,\footnote{il
- \textit{Pluggable Authentication Method} è un sistema modulare, in cui è
- possibile utilizzare anche più meccanismi insieme, diventa così possibile
+ \textit{Pluggable Authentication Method} è un sistema modulare, in cui è
+ possibile utilizzare anche più meccanismi insieme, diventa così possibile
avere vari sistemi di riconoscimento (biometria, chiavi hardware, ecc.),
diversi formati per le password e diversi supporti per le informazioni, il
- tutto in maniera trasparente per le applicazioni purché per ciascun
+ tutto in maniera trasparente per le applicazioni purché per ciascun
meccanismo si disponga della opportuna libreria che implementa l'interfaccia
di PAM.} svincolando completamente le singole applicazione dai dettagli del
come questa viene eseguita e di dove vengono mantenuti i dati relativi;
-dall'altra con il diffondersi delle reti la necessità di centralizzare le
+dall'altra con il diffondersi delle reti la necessità di centralizzare le
informazioni degli utenti e dei gruppi per insiemi di macchine, in modo da
-mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare
+mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare
e memorizzare dette informazioni su supporti diversi, introducendo il sistema
del \itindex{Name~Service~Switch} \textit{Name Service Switch} che tratteremo
-brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior
+brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior
parte delle sua applicazioni sono relative alla risoluzioni di nomi di rete.
In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche
\end{functions}
Le due funzioni forniscono le informazioni memorizzate nel registro degli
-utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM)
+utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM)
relative all'utente specificato attraverso il suo \acr{uid} o il nome di
login. Entrambe le funzioni restituiscono un puntatore ad una struttura di
-tipo \struct{passwd} la cui definizione (anch'essa eseguita in \file{pwd.h}) è
-riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente
+tipo \struct{passwd} la cui definizione (anch'essa eseguita in \file{pwd.h}) è
+riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente
illustrato il significato dei vari campi.
\begin{figure}[!htb]
\label{fig:sys_passwd_struct}
\end{figure}
-La struttura usata da entrambe le funzioni è allocata staticamente, per questo
+La struttura usata da entrambe le funzioni è allocata staticamente, per questo
motivo viene sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la
memoria dove sono scritte le stringhe a cui i puntatori in essa contenuti
fanno riferimento. Ovviamente questo implica che dette funzioni non possono
Restituiscono le informazioni relative all'utente specificato.
\bodydesc{Le funzioni ritornano 0 in caso di successo e un codice d'errore
- altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
+ altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
\end{functions}
-In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare
+In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare
la memoria necessaria a contenere le informazioni. In particolare i valori
della struttura \struct{passwd} saranno restituiti all'indirizzo
\param{password} mentre la memoria allocata all'indirizzo \param{buffer}, per
-un massimo di \param{buflen} byte, sarà utilizzata per contenere le stringhe
+un massimo di \param{buflen} byte, sarà utilizzata per contenere le stringhe
puntate dai campi di \param{password}. Infine all'indirizzo puntato da
-\param{result} viene restituito il puntatore ai dati ottenuti, cioè
+\param{result} viene restituito il puntatore ai dati ottenuti, cioè
\param{buffer} nel caso l'utente esista, o \val{NULL} altrimenti. Qualora i
dati non possano essere contenuti nei byte specificati da \param{buflen}, la
-funzione fallirà restituendo \errcode{ERANGE} (e \param{result} sarà comunque
+funzione fallirà restituendo \errcode{ERANGE} (e \param{result} sarà comunque
impostato a \val{NULL}).
Del tutto analoghe alle precedenti sono le funzioni \funcd{getgrnam} e
Restituiscono le informazioni relative al gruppo specificato.
\bodydesc{Le funzioni ritornano 0 in caso di successo e un codice d'errore
- altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
+ altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.}
\end{functions}
-Il comportamento di tutte queste funzioni è assolutamente identico alle
-precedenti che leggono le informazioni sugli utenti, l'unica differenza è che
+Il comportamento di tutte queste funzioni è assolutamente identico alle
+precedenti che leggono le informazioni sugli utenti, l'unica differenza è che
in questo caso le informazioni vengono restituite in una struttura di tipo
-\struct{group}, la cui definizione è riportata in
+\struct{group}, la cui definizione è riportata in
fig.~\ref{fig:sys_group_struct}.
\begin{figure}[!htb]
Le funzioni viste finora sono in grado di leggere le informazioni sia
direttamente dal file delle password in \conffile{/etc/passwd} che tramite il
sistema del \itindex{Name~Service~Switch} \textit{Name Service Switch} e sono
-completamente generiche. Si noti però che non c'è una funzione che permetta di
-impostare direttamente una password.\footnote{in realtà questo può essere
- fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che POSIX non
-prevede questa possibilità esiste un'altra interfaccia che lo fa, derivata da
+completamente generiche. Si noti però che non c'è una funzione che permetta di
+impostare direttamente una password.\footnote{in realtà questo può essere
+ fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che POSIX non
+prevede questa possibilità esiste un'altra interfaccia che lo fa, derivata da
SVID le cui funzioni sono riportate in tab.~\ref{tab:sys_passwd_func}. Questa
-però funziona soltanto quando le informazioni sono mantenute su un apposito
+però funziona soltanto quando le informazioni sono mantenute su un apposito
file di \textsl{registro} di utenti e gruppi, con il formato classico di
\conffile{/etc/passwd} e \conffile{/etc/group}.
almeno le \textit{shadow password} (quindi con delle modifiche rispetto al
formato classico del file \conffile{/etc/passwd}), si tenga presente che le
funzioni di questa interfaccia che permettono di scrivere delle voci in un
-\textsl{registro} degli utenti (cioè \func{putpwent} e \func{putgrent}) non
-hanno la capacità di farlo specificando tutti i contenuti necessari rispetto a
-questa estensione. Per questo motivo l'uso di queste funzioni è deprecato, in
+\textsl{registro} degli utenti (cioè \func{putpwent} e \func{putgrent}) non
+hanno la capacità di farlo specificando tutti i contenuti necessari rispetto a
+questa estensione. Per questo motivo l'uso di queste funzioni è deprecato, in
quanto comunque non funzionale, pertanto ci limiteremo a fornire soltanto
l'elenco di tab.~\ref{tab:sys_passwd_func}, senza nessuna spiegazione
-ulteriore. Chi volesse insistere ad usare questa interfaccia può fare
+ulteriore. Chi volesse insistere ad usare questa interfaccia può fare
riferimento alle pagine di manuale delle rispettive funzioni ed al manuale
delle \acr{glibc} per i dettagli del funzionamento.
-\subsection{Il registro della \textsl{contabilità} degli utenti}
+\subsection{Il registro della \textsl{contabilità} degli utenti}
\label{sec:sys_accounting}
L'ultimo insieme di funzioni relative alla gestione del sistema che
-esamineremo è quello che permette di accedere ai dati del registro della
-cosiddetta \textsl{contabilità} (o \textit{accounting}) degli utenti. In esso
+esamineremo è quello che permette di accedere ai dati del registro della
+cosiddetta \textsl{contabilità} (o \textit{accounting}) degli utenti. In esso
vengono mantenute una serie di informazioni storiche relative sia agli utenti
che si sono collegati al sistema, (tanto per quelli correntemente collegati,
che per la registrazione degli accessi precedenti), sia relative all'intero
cambiamento dell'orologio di sistema, il cambiamento di runlevel o il riavvio
della macchina.
-I dati vengono usualmente\footnote{questa è la locazione specificata dal
+I dati vengono usualmente\footnote{questa è la locazione specificata dal
\textit{Linux Filesystem Hierarchy Standard}, adottato dalla gran parte
delle distribuzioni.} memorizzati nei due file \file{/var/run/utmp} e
\file{/var/log/wtmp}.\footnote{non si confonda quest'ultimo con il simile
In questo modo il primo file viene utilizzato per registrare chi sta
utilizzando il sistema al momento corrente, mentre il secondo mantiene la
-registrazione delle attività degli utenti. A quest'ultimo vengono anche
+registrazione delle attività degli utenti. A quest'ultimo vengono anche
aggiunte delle voci speciali per tenere conto dei cambiamenti del sistema,
come la modifica del runlevel, il riavvio della macchina, ecc. Tutte queste
informazioni sono descritte in dettaglio nel manuale delle \acr{glibc}.
contengono possono essere ricavate attraverso le opportune funzioni di
libreria. Queste sono analoghe alle precedenti funzioni (vedi
tab.~\ref{tab:sys_passwd_func}) usate per accedere al registro degli utenti,
-solo che in questo caso la struttura del registro della \textsl{contabilità} è
-molto più complessa, dato che contiene diversi tipi di informazione.
+solo che in questo caso la struttura del registro della \textsl{contabilità} è
+molto più complessa, dato che contiene diversi tipi di informazione.
Le prime tre funzioni, \funcd{setutent}, \funcd{endutent} e \funcd{utmpname}
servono rispettivamente a aprire e a chiudere il file che contiene il
\bodydesc{Le funzioni non ritornano codici di errore.}
\end{functions}
e si tenga presente che le funzioni non restituiscono nessun valore, pertanto
-non è possibile accorgersi di eventuali errori (ad esempio se si è impostato
+non è possibile accorgersi di eventuali errori (ad esempio se si è impostato
un nome di file sbagliato con \func{utmpname}).
Nel caso non si sia utilizzata \func{utmpname} per specificare un file di
registro alternativo, sia \func{setutent} che \func{endutent} operano usando
-il default che è \file{/var/run/utmp}. Il nome di questo file, così come una
-serie di altri valori di default per i \textit{pathname} di uso più comune,
+il default che è \file{/var/run/utmp}. Il nome di questo file, così come una
+serie di altri valori di default per i \textit{pathname} di uso più comune,
viene mantenuto nei valori di una serie di costanti definite includendo
\file{paths.h}, in particolare quelle che ci interessano sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{\_PATH\_UTMP}] specifica il file che contiene il registro per gli
- utenti correntemente collegati; questo è il valore che viene usato se non si
- è utilizzato \func{utmpname} per modificarlo.
+ utenti correntemente collegati; questo è il valore che viene usato se non si
+ è utilizzato \func{utmpname} per modificarlo.
\item[\const{\_PATH\_WTMP}] specifica il file che contiene il registro per
l'archivio storico degli utenti collegati.
\end{basedescript}
che nel caso di Linux hanno un valore corrispondente ai file
\file{/var/run/utmp} e \file{/var/log/wtmp} citati in precedenza.
-Una volta aperto il file del registro degli utenti si può eseguire una
+Una volta aperto il file del registro degli utenti si può eseguire una
scansione leggendo o scrivendo una voce con le funzioni \funcd{getutent},
\funcd{getutid}, \funcd{getutline} e \funcd{pututline}, i cui prototipi sono:
\begin{functions}
\end{functions}
Tutte queste funzioni fanno riferimento ad una struttura di tipo
-\struct{utmp}, la cui definizione in Linux è riportata in
+\struct{utmp}, la cui definizione in Linux è riportata in
fig.~\ref{fig:sys_utmp_struct}. Le prime tre funzioni servono per leggere una
voce dal registro; \func{getutent} legge semplicemente la prima voce
disponibile; le altre due permettono di eseguire una ricerca.
\end{minipage}
\normalsize
\caption{La struttura \structd{utmp} contenente le informazioni di una voce
- del registro di \textsl{contabilità}.}
+ del registro di \textsl{contabilità}.}
\label{fig:sys_utmp_struct}
\end{figure}
-Con \func{getutid} si può cercare una voce specifica, a seconda del valore del
-campo \var{ut\_type} dell'argomento \param{ut}. Questo può assumere i valori
+Con \func{getutid} si può cercare una voce specifica, a seconda del valore del
+campo \var{ut\_type} dell'argomento \param{ut}. Questo può assumere i valori
riportati in tab.~\ref{tab:sys_ut_type}, quando assume i valori
\const{RUN\_LVL}, \const{BOOT\_TIME}, \const{OLD\_TIME}, \const{NEW\_TIME},
-verrà restituito la prima voce che corrisponde al tipo determinato; quando
+verrà restituito la prima voce che corrisponde al tipo determinato; quando
invece assume i valori \const{INIT\_PROCESS}, \const{LOGIN\_PROCESS},
-\const{USER\_PROCESS} o \const{DEAD\_PROCESS} verrà restituita la prima voce
+\const{USER\_PROCESS} o \const{DEAD\_PROCESS} verrà restituita la prima voce
corrispondente al valore del campo \var{ut\_id} specificato in \param{ut}.
\begin{table}[htb]
\const{EMPTY} & Non contiene informazioni valide.\\
\const{RUN\_LVL} & Identica il runlevel del sistema.\\
\const{BOOT\_TIME} & Identifica il tempo di avvio del sistema.\\
- \const{OLD\_TIME} & Identifica quando è stato modificato l'orologio di
+ \const{OLD\_TIME} & Identifica quando è stato modificato l'orologio di
sistema.\\
- \const{NEW\_TIME} & Identifica da quanto è stato modificato il
+ \const{NEW\_TIME} & Identifica da quanto è stato modificato il
sistema.\\
\const{INIT\_PROCESS} & Identifica un processo lanciato da \cmd{init}.\\
\const{LOGIN\_PROCESS}& Identifica un processo di login.\\
\var{ut\_type} uguale a \const{LOGIN\_PROCESS} o \const{USER\_PROCESS},
restituendo la prima che corrisponde al valore di \var{ut\_line}, che
specifica il device\footnote{espresso senza il \file{/dev/} iniziale.} di
-terminale che interessa. Lo stesso criterio di ricerca è usato da
+terminale che interessa. Lo stesso criterio di ricerca è usato da
\func{pututline} per trovare uno spazio dove inserire la voce specificata,
qualora non sia trovata la voce viene aggiunta in coda al registro.
-In generale occorre però tenere conto che queste funzioni non sono
+In generale occorre però tenere conto che queste funzioni non sono
completamente standardizzate, e che in sistemi diversi possono esserci
differenze; ad esempio \func{pututline} restituisce \code{void} in vari
sistemi (compreso Linux, fino alle \acr{libc5}). Qui seguiremo la sintassi
introdotto delle nuove strutture (e relativi file) di tipo \code{utmpx}, che
sono un sovrainsieme di \code{utmp}.
-Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende
+Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende
inutili queste nuove strutture; pertanto esse e le relative funzioni di
gestione (\func{getutxent}, \func{getutxid}, \func{getutxline},
\func{pututxline}, \func{setutxent} e \func{endutxent}) sono ridefinite come
Dopo aver esaminato le funzioni che permettono di controllare le varie
-caratteristiche, capacità e limiti del sistema a livello globale, in questa
+caratteristiche, capacità e limiti del sistema a livello globale, in questa
sezione tratteremo le varie funzioni che vengono usate per quantificare le
risorse (CPU, memoria, ecc.) utilizzate da ogni singolo processo e quelle che
permettono di imporre a ciascuno di essi vincoli e limiti di
\label{sec:sys_resource_use}
Come abbiamo accennato in sez.~\ref{sec:proc_wait} le informazioni riguardo
-l'utilizzo delle risorse da parte di un processo è mantenuto in una struttura
+l'utilizzo delle risorse da parte di un processo è mantenuto in una struttura
di tipo \struct{rusage}, la cui definizione (che si trova in
-\file{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}.
+\file{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}.
\begin{figure}[!htb]
\footnotesize
\label{fig:sys_rusage_struct}
\end{figure}
-La definizione della struttura in fig.~\ref{fig:sys_rusage_struct} è ripresa
+La definizione della struttura in fig.~\ref{fig:sys_rusage_struct} è ripresa
da BSD 4.3,\footnote{questo non ha a nulla a che fare con il cosiddetto
\textit{BSD accounting} (vedi sez. \ref{sec:sys_bsd_accounting}) che si trova
- nelle opzioni di compilazione del kernel (e di norma è disabilitato) che
- serve per mantenere una contabilità delle risorse usate da ciascun processo
- in maniera molto più dettagliata.} ma attualmente (con i kernel della serie
+ nelle opzioni di compilazione del kernel (e di norma è disabilitato) che
+ serve per mantenere una contabilità delle risorse usate da ciascun processo
+ in maniera molto più dettagliata.} ma attualmente (con i kernel della serie
2.4.x e 2.6.x) i soli campi che sono mantenuti sono: \var{ru\_utime},
\var{ru\_stime}, \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}. I
primi due indicano rispettivamente il tempo impiegato dal processo
\itindex{page~fault} \textit{page fault} (vedi sez.~\ref{sec:proc_mem_gen})
avvenuti senza richiedere I/O su disco (i cosiddetti \textit{minor page
fault}), a quelli che invece han richiesto I/O su disco (detti invece
-\textit{major page fault}) ed al numero di volte che il processo è stato
+\textit{major page fault}) ed al numero di volte che il processo è stato
completamente tolto dalla memoria per essere inserito nello swap.
-In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
-necessario, ma aumenta la portabilità, e serve comunque quando, come nella
+In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
+necessario, ma aumenta la portabilità, e serve comunque quando, come nella
maggior parte dei casi, si debba accedere ai campi di \struct{rusage} relativi
ai tempi di utilizzo del processore, che sono definiti come strutture di tipo
\struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct}).
-Questa è la stessa struttura utilizzata da \func{wait4} (si ricordi quando
-visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di risorse
-impiegate dal processo di cui si è letto lo stato di terminazione, ma essa può
+Questa è la stessa struttura utilizzata da \func{wait4} (si ricordi quando
+visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di risorse
+impiegate dal processo di cui si è letto lo stato di terminazione, ma essa può
anche essere letta direttamente utilizzando la funzione \funcd{getrusage}, il
-cui prototipo è:
+cui prototipo è:
\begin{functions}
\headdecl{sys/time.h}
\headdecl{sys/resource.h}
\headdecl{unistd.h}
\funcdecl{int getrusage(int who, struct rusage *usage)}
- Legge la quantità di risorse usate da un processo.
+ Legge la quantità di risorse usate da un processo.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può essere \errval{EINVAL} o \errval{EFAULT}.}
+ nel qual caso \var{errno} può essere \errval{EINVAL} o \errval{EFAULT}.}
\end{functions}
L'argomento \param{who} permette di specificare il processo di cui si vuole
-leggere l'uso delle risorse; esso può assumere solo i due valori
+leggere l'uso delle risorse; esso può assumere solo i due valori
\const{RUSAGE\_SELF} per indicare il processo corrente e
-\const{RUSAGE\_CHILDREN} per indicare l'insieme dei processi figli di cui si è
+\const{RUSAGE\_CHILDREN} per indicare l'insieme dei processi figli di cui si è
ricevuto lo stato di terminazione.
% TODO previsto in futuro \const{RUSAGE\_THREAD}, verificare.
\label{sec:sys_resource_limit}
Come accennato nell'introduzione il kernel mette a disposizione delle
-funzionalità che permettono non solo di mantenere dati statistici relativi
+funzionalità che permettono non solo di mantenere dati statistici relativi
all'uso delle risorse, ma anche di imporre dei limiti precisi sul loro
utilizzo da parte dei vari processi o degli utenti.
Per far questo esistono una serie di risorse e ad ogni processo vengono
associati due diversi limiti per ciascuna di esse; questi sono il
\textsl{limite corrente} (o \textit{current limit}) che esprime un valore
-massimo che il processo non può superare ad un certo momento, ed il
+massimo che il processo non può superare ad un certo momento, ed il
\textsl{limite massimo} (o \textit{maximum limit}) che invece esprime il
-valore massimo che può assumere il \textsl{limite corrente}. In generale il
-primo viene chiamato anche \textit{soft limit} dato che il suo valore può
-essere aumentato dal processo stesso durante l'esecuzione, ciò può però essere
+valore massimo che può assumere il \textsl{limite corrente}. In generale il
+primo viene chiamato anche \textit{soft limit} dato che il suo valore può
+essere aumentato dal processo stesso durante l'esecuzione, ciò può però essere
fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
limit}.
esse falliranno con un errore di
\errcode{ENOMEM}, mentre se il superamento viene
causato dalla crescita dello \itindex{stack}
- \textit{stack} il processo riceverà un segnale di
+ \textit{stack} il processo riceverà un segnale di
\const{SIGSEGV}.\\
\const{RLIMIT\_CORE} & La massima dimensione per di un file di
\itindex{core~dump} \textit{core dump} (vedi
sez.~\ref{sec:sig_prog_error}) creato nella
terminazione di un processo; file di dimensioni
maggiori verranno troncati a questo valore,
- mentre con un valore si bloccherà la creazione
+ mentre con un valore si bloccherà la creazione
dei \itindex{core~dump} \textit{core dump}.\\
\const{RLIMIT\_CPU} & Il massimo tempo di CPU (vedi
- sez.~\ref{sec:sys_cpu_times}) che il processo può
+ sez.~\ref{sec:sys_cpu_times}) che il processo può
usare. Il superamento del limite corrente
comporta l'emissione di un segnale di
\const{SIGXCPU}, la cui azione predefinita (vedi
- sez.~\ref{sec:sig_classification}) è terminare
+ sez.~\ref{sec:sig_classification}) è terminare
il processo, una volta al secondo fino al
raggiungimento del limite massimo. Il
superamento del limite massimo
\const{RLIMIT\_DATA} & La massima dimensione del \index{segmento!dati}
segmento dati di un
processo (vedi sez.~\ref{sec:proc_mem_layout}).
- Il tentativo di allocare più memoria di quanto
+ Il tentativo di allocare più memoria di quanto
indicato dal limite corrente causa il fallimento
della funzione di allocazione (\func{brk} o
\func{sbrk}) con un errore di \errcode{ENOMEM}.\\
\const{RLIMIT\_FSIZE} & La massima dimensione di un file che un processo
- può creare. Se il processo cerca di scrivere
- oltre questa dimensione riceverà un segnale di
+ può creare. Se il processo cerca di scrivere
+ oltre questa dimensione riceverà un segnale di
\const{SIGXFSZ}, che di norma termina il
processo; se questo viene intercettato la
- system call che ha causato l'errore fallirà con
+ system call che ha causato l'errore fallirà con
un errore di \errcode{EFBIG}.\\
- \const{RLIMIT\_LOCKS}& È un limite presente solo nelle prime versioni
+ \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
sez.~\ref{sec:file_locking}) che un
processo poteva effettuare.\\
- \const{RLIMIT\_MEMLOCK}& L'ammontare massimo di memoria che può essere
+ \const{RLIMIT\_MEMLOCK}& L'ammontare massimo di memoria che può essere
bloccata in RAM da un processo (vedi
sez.~\ref{sec:proc_mem_lock}). Dal kernel 2.6.9
- questo limite comprende anche la memoria che può
+ questo limite comprende anche la memoria che può
essere bloccata da ciascun utente nell'uso della
memoria condivisa (vedi
sez.~\ref{sec:ipc_sysv_shm}) che viene
% \const{RLIMIT\_RTPRIO}& Il numero massimo di \\
% aggiungere i limiti che mancano come RLIMIT_RTTIME introdotto con il 2.6.25
% vedi file include/asm-generic/resource.h
- \const{RLIMIT\_NOFILE} & Il numero massimo di file che il processo può
- aprire. L'apertura di un ulteriore file farà
+ \const{RLIMIT\_NOFILE} & Il numero massimo di file che il processo può
+ aprire. L'apertura di un ulteriore file farà
fallire la funzione (\func{open}, \func{dup} o
\func{pipe}) con un errore \errcode{EMFILE}.\\
\const{RLIMIT\_NPROC} & Il numero massimo di processi che possono essere
creati sullo stesso user id real. Se il limite
- viene raggiunto \func{fork} fallirà con un
+ viene raggiunto \func{fork} fallirà con un
\errcode{EAGAIN}.\\
\const{RLIMIT\_SIGPENDING}& Il numero massimo di segnali che possono
essere mantenuti in coda per ciascun utente,
considerando sia i segnali normali che real-time
- (vedi sez.~\ref{sec:sig_real_time}). Il limite è
+ (vedi sez.~\ref{sec:sig_real_time}). Il limite è
attivo solo per \func{sigqueue}, con \func{kill}
- si potrà sempre inviare un segnale che non sia
- già presente su una coda.\footnotemark\\
+ si potrà sempre inviare un segnale che non sia
+ già presente su una coda.\footnotemark\\
\const{RLIMIT\_STACK} & La massima dimensione dello \itindex{stack}
\textit{stack} del processo. Se il processo
esegue operazioni che estendano lo
\textit{stack} oltre questa dimensione
- riceverà un segnale di \const{SIGSEGV}.\\
+ riceverà un segnale di \const{SIGSEGV}.\\
\const{RLIMIT\_RSS} & L'ammontare massimo di pagine di memoria dato al
\index{segmento!testo} testo del processo. Il
- limite è solo una indicazione per il kernel,
+ limite è solo una indicazione per il kernel,
qualora ci fosse un surplus di memoria questa
verrebbe assegnata.\\
% TODO integrare con la roba di madvise
\label{tab:sys_rlimit_values}
\end{table}
-\footnotetext[18]{questo è quanto avviene per i kernel dalla serie 2.2 fino ad
+\footnotetext[18]{questo è quanto avviene per i kernel dalla serie 2.2 fino ad
oggi (la 2.6.x); altri kernel possono avere comportamenti diversi per quanto
- avviene quando viene superato il \textit{soft limit}; perciò per avere
- operazioni portabili è sempre opportuno intercettare il primo
+ avviene quando viene superato il \textit{soft limit}; perciò per avere
+ operazioni portabili è sempre opportuno intercettare il primo
\const{SIGXCPU} e terminare in maniera ordinata il processo.}
-\footnotetext{il limite su questa risorsa è stato introdotto con il kernel
+\footnotetext{il limite su questa risorsa è stato introdotto con il kernel
2.6.8.}
% TODO trattare prlimit64 introdotta con il 2.6.36 che dovrebbe sostituire
avviene al superamento del limite corrente, con l'eccezione
\const{RLIMIT\_CPU} in cui si ha in comportamento diverso per il superamento
dei due limiti.} comporta o l'emissione di un segnale o il fallimento della
-system call che lo ha provocato;\footnote{si nuovo c'è una eccezione per
+system call che lo ha provocato;\footnote{si nuovo c'è una eccezione per
\const{RLIMIT\_CORE} che influenza soltanto la dimensione (o l'eventuale
creazione) dei file di \itindex{core~dump} \textit{core dump}.} per
permettere di leggere e di impostare i limiti di utilizzo delle risorse da
Imposta il limite per la risorsa \param{resource}.
\bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] i valori per \param{resource} non sono validi.
\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
questo argomento sono elencati in tab.~\ref{tab:sys_rlimit_values}. L'acceso
(rispettivamente in lettura e scrittura) ai valori effettivi dei limiti viene
poi effettuato attraverso la struttura \struct{rlimit} puntata da
-\param{rlim}, la cui definizione è riportata in
+\param{rlim}, la cui definizione è riportata in
fig.~\ref{fig:sys_rlimit_struct}, ed i cui campi corrispondono appunto a
limite corrente e limite massimo.
\end{figure}
-Nello specificare un limite, oltre a fornire dei valori specifici, si può
+Nello specificare un limite, oltre a fornire dei valori specifici, si può
anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso
di una risorsa; ma si ricordi che solo un processo con i privilegi di
-amministratore\footnote{per essere precisi in questo caso quello che serve è
+amministratore\footnote{per essere precisi in questo caso quello che serve è
la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE}
- (vedi sez.~\ref{sec:proc_capabilities}).} può innalzare un limite al di
+ (vedi sez.~\ref{sec:proc_capabilities}).} può innalzare un limite al di
sopra del valore corrente del limite massimo ed usare un valore qualsiasi per
entrambi i limiti. Si tenga conto infine che tutti i limiti vengono ereditati
dal processo padre attraverso una \func{fork} (vedi sez.~\ref{sec:proc_fork})
\subsection{Le risorse di memoria e processore}
\label{sec:sys_memory_res}
-La gestione della memoria è già stata affrontata in dettaglio in
+La gestione della memoria è già stata affrontata in dettaglio in
sez.~\ref{sec:proc_memory}; abbiamo visto allora che il kernel provvede il
meccanismo della \index{memoria~virtuale} memoria virtuale attraverso la
divisione della memoria fisica in pagine.
-In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi
+In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi
casi, come per l'I/O mappato in memoria (vedi sez.~\ref{sec:file_memory_map})
-che usa lo stesso meccanismo per accedere ai file, è necessario conoscere le
+che usa lo stesso meccanismo per accedere ai file, è necessario conoscere le
dimensioni delle pagine usate dal kernel. Lo stesso vale quando si vuole
gestire in maniera ottimale l'interazione della memoria che si sta allocando
con il meccanismo della \index{paginazione} paginazione.
-Di solito la dimensione delle pagine di memoria è fissata dall'architettura
+Di solito la dimensione delle pagine di memoria è fissata dall'architettura
hardware, per cui il suo valore di norma veniva mantenuto in una costante che
bastava utilizzare in fase di compilazione, ma oggi, con la presenza di alcune
architetture (ad esempio Sun Sparc) che permettono di variare questa
dimensione, per non dover ricompilare i programmi per ogni possibile modello e
-scelta di dimensioni, è necessario poter utilizzare una funzione.
+scelta di dimensioni, è necessario poter utilizzare una funzione.
Dato che si tratta di una caratteristica generale del sistema, questa
-dimensione può essere ottenuta come tutte le altre attraverso una chiamata a
+dimensione può essere ottenuta come tutte le altre attraverso una chiamata a
\func{sysconf}, \footnote{nel caso specifico si dovrebbe utilizzare il
- parametro \const{\_SC\_PAGESIZE}.} ma in BSD 4.2 è stata introdotta una
+ parametro \const{\_SC\_PAGESIZE}.} ma in BSD 4.2 è stata introdotta una
apposita funzione, \funcd{getpagesize}, che restituisce la dimensione delle
-pagine di memoria; il suo prototipo è:
+pagine di memoria; il suo prototipo è:
\begin{prototype}{unistd.h}{int getpagesize(void)}
Legge le dimensioni delle pagine di memoria.
sono previsti errori.}
\end{prototype}
-La funzione è prevista in SVr4, BSD 4.4 e SUSv2, anche se questo ultimo
+La funzione è prevista in SVr4, BSD 4.4 e SUSv2, anche se questo ultimo
standard la etichetta come obsoleta, mentre lo standard POSIX 1003.1-2001 la
-ha eliminata. In Linux è implementata come una system call nelle architetture
-in cui essa è necessaria, ed in genere restituisce il valore del simbolo
+ha eliminata. In Linux è implementata come una system call nelle architetture
+in cui essa è necessaria, ed in genere restituisce il valore del simbolo
\const{PAGE\_SIZE} del kernel, che dipende dalla architettura hardware, anche
se le versioni delle librerie del C precedenti le \acr{glibc} 2.1
implementavano questa funzione restituendo sempre un valore statico.
\const{\_SC\_NPROCESSORS\_CONF} e \const{\_SC\_NPROCESSORS\_ONLN}.
Infine le \acr{glibc} riprendono da BSD la funzione \funcd{getloadavg} che
-permette di ottenere il carico di processore della macchina, in questo modo è
+permette di ottenere il carico di processore della macchina, in questo modo è
possibile prendere decisioni su quando far partire eventuali nuovi processi.
-Il suo prototipo è:
+Il suo prototipo è:
\begin{prototype}{stdlib.h}{int getloadavg(double loadavg[], int nelem)}
Legge il carico medio della macchina.
La funzione restituisce in ciascun elemento di \param{loadavg} il numero medio
di processi attivi sulla coda dello \itindex{scheduler} scheduler, calcolato
su diversi intervalli di tempo. Il numero di intervalli che si vogliono
-leggere è specificato da \param{nelem}, dato che nel caso di Linux il carico
+leggere è specificato da \param{nelem}, dato che nel caso di Linux il carico
viene valutato solo su tre intervalli (corrispondenti a 1, 5 e 15 minuti),
-questo è anche il massimo valore che può essere assegnato a questo argomento.
+questo è anche il massimo valore che può essere assegnato a questo argomento.
-\subsection{La \textsl{contabilità} in stile BSD}
+\subsection{La \textsl{contabilità} in stile BSD}
\label{sec:sys_bsd_accounting}
-Una ultima modalità per monitorare l'uso delle risorse è, se si è compilato il
-kernel con il relativo supporto,\footnote{se cioè si è abilitata l'opzione di
+Una ultima modalità per monitorare l'uso delle risorse è, se si è compilato il
+kernel con il relativo supporto,\footnote{se cioè si è abilitata l'opzione di
compilazione \texttt{CONFIG\_BSD\_PROCESS\_ACCT}.} quella di attivare il
cosiddetto \textit{BSD accounting}, che consente di registrare su file una
serie di informazioni\footnote{contenute nella struttura \texttt{acct}
definita nel file \texttt{include/linux/acct.h} dei sorgenti del kernel.}
-riguardo alla \textsl{contabilità} delle risorse utilizzate da ogni processo
+riguardo alla \textsl{contabilità} delle risorse utilizzate da ogni processo
che viene terminato.
-Linux consente di salvare la contabilità delle informazioni relative alle
+Linux consente di salvare la contabilità delle informazioni relative alle
risorse utilizzate dai processi grazie alla funzione \funcd{acct}, il cui
-prototipo è:
+prototipo è:
\begin{prototype}{unistd.h}{int acct(const char *filename)}
Abilita il \textit{BSD accounting}.
\bodydesc{La funzione ritorna 0 in caso di successo o $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCESS}] non si hanno i permessi per accedere a
\param{pathname}.
abilitare il \textit{BSD accounting}.
\item[\errcode{ENOSYS}] il kernel non supporta il \textit{BSD accounting}.
\item[\errcode{EUSER}] non sono disponibili nel kernel strutture per il
- file o si è finita la memoria.
+ file o si è finita la memoria.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
\errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOENT}, \errval{ENOMEM},
La funzione attiva il salvataggio dei dati sul file indicato dal pathname
contenuti nella stringa puntata da \param{filename}; la funzione richiede che
-il processo abbia i privilegi di amministratore (è necessaria la
+il processo abbia i privilegi di amministratore (è necessaria la
\itindex{capabilities} capability \const{CAP\_SYS\_PACCT}, vedi
sez.~\ref{sec:proc_capabilities}). Se si specifica il valore \const{NULL} per
\param{filename} il \textit{BSD accounting} viene invece disabilitato. Un
-semplice esempio per l'uso di questa funzione è riportato nel programma
+semplice esempio per l'uso di questa funzione è riportato nel programma
\texttt{AcctCtrl.c} dei sorgenti allegati alla guida.
-Quando si attiva la contabilità, il file che si indica deve esistere; esso
-verrà aperto in sola scrittura;\footnote{si applicano al pathname indicato da
+Quando si attiva la contabilità, il file che si indica deve esistere; esso
+verrà aperto in sola scrittura;\footnote{si applicano al pathname indicato da
\param{filename} tutte le restrizioni viste in cap.~\ref{cha:file_intro}.}
le informazioni verranno registrate in \itindex{append~mode} \textit{append}
in coda al file tutte le volte che un processo termina. Le informazioni
\itindex{process~time} \textit{process time}, secondo le definizioni:
\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
\item[\textit{calendar time}] \itindex{calendar~time} detto anche
- \textsl{tempo di calendario}. È il numero di secondi dalla mezzanotte del
+ \textsl{tempo di calendario}. È il numero di secondi dalla mezzanotte del
primo gennaio 1970, in tempo universale coordinato (o UTC), data che viene
usualmente indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata \textit{the
Epoch}. Questo tempo viene anche chiamato anche GMT (Greenwich Mean Time)
- dato che l'UTC corrisponde all'ora locale di Greenwich. È il tempo su cui
+ dato che l'UTC corrisponde all'ora locale di Greenwich. È il tempo su cui
viene mantenuto l'orologio del kernel, e viene usato ad esempio per indicare
le date di modifica dei file o quelle di avvio dei processi. Per memorizzare
- questo tempo è stato riservato il tipo primitivo \type{time\_t}.
+ questo tempo è stato riservato il tipo primitivo \type{time\_t}.
\item[\textit{process time}] \itindex{process~time} detto talvolta
\textsl{tempo di processore}. Viene misurato in \itindex{clock~tick}
\textit{clock tick}. Un tempo questo corrispondeva al numero di interruzioni
sia pari al valore della costante \const{CLOCKS\_PER\_SEC}, che deve essere
definita come 1000000, qualunque sia la risoluzione reale dell'orologio di
sistema e la frequenza delle interruzioni del timer.\footnote{quest'ultima,
- come accennato in sez.~\ref{sec:proc_hierarchy}, è invece data dalla
- costante \const{HZ}.} Il dato primitivo usato per questo tempo è
+ come accennato in sez.~\ref{sec:proc_hierarchy}, è invece data dalla
+ costante \const{HZ}.} Il dato primitivo usato per questo tempo è
\type{clock\_t}, che ha quindi una risoluzione del microsecondo. Il numero
- di \itindex{clock~tick} \textit{tick} al secondo può essere ricavato anche
+ di \itindex{clock~tick} \textit{tick} al secondo può essere ricavato anche
attraverso \func{sysconf} (vedi sez.~\ref{sec:sys_sysconf}). Il vecchio
- simbolo \const{CLK\_TCK} definito in \file{time.h} è ormai considerato
+ simbolo \const{CLK\_TCK} definito in \file{time.h} è ormai considerato
obsoleto.
\end{basedescript}
Di solito questo tempo viene convertito automaticamente dal valore in UTC al
tempo locale, utilizzando le opportune informazioni di localizzazione
(specificate in \conffile{/etc/timezone}). E da tenere presente che questo
-tempo è mantenuto dal sistema e non è detto che corrisponda al tempo tenuto
+tempo è mantenuto dal sistema e non è detto che corrisponda al tempo tenuto
dall'orologio hardware del calcolatore.
Anche il \itindex{process~time} \textit{process time} di solito si esprime in
secondi, ma fornisce una precisione ovviamente superiore al \textit{calendar
- time} (che è mantenuto dal sistema con una granularità di un secondo) e
+ time} (che è mantenuto dal sistema con una granularità di un secondo) e
viene usato per tenere conto dei tempi di esecuzione dei processi. Per ciascun
processo il kernel calcola tre tempi diversi:
\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
quanti altri processi stavano girando nello stesso periodo.
\item[\textit{user time}] il tempo effettivo che il processore ha impiegato
- nell'esecuzione delle istruzioni del processo in user space. È quello
+ nell'esecuzione delle istruzioni del processo in user space. È quello
riportato nella risorsa \var{ru\_utime} di \struct{rusage} vista in
sez.~\ref{sec:sys_resource_use}.
\item[\textit{system time}] il tempo effettivo che il processore ha impiegato
- per eseguire codice delle system call nel kernel per conto del processo. È
+ per eseguire codice delle system call nel kernel per conto del processo. È
quello riportato nella risorsa \var{ru\_stime} di \struct{rusage} vista in
sez.~\ref{sec:sys_resource_use}.
\end{basedescript}
In genere la somma di \textit{user time} e \textit{system time} indica il
tempo di processore totale che il sistema ha effettivamente utilizzato per
eseguire un certo processo, questo viene chiamato anche \textit{CPU time} o
-\textsl{tempo di CPU}. Si può ottenere un riassunto dei valori di questi tempi
+\textsl{tempo di CPU}. Si può ottenere un riassunto dei valori di questi tempi
quando si esegue un qualsiasi programma lanciando quest'ultimo come argomento
del comando \cmd{time}.
Di norma tutte le operazioni del sistema fanno sempre riferimento al
\itindex{calendar~time} \textit{calendar time}, l'uso del \textit{process
- time} è riservato a quei casi in cui serve conoscere i tempi di esecuzione
+ time} è riservato a quei casi in cui serve conoscere i tempi di esecuzione
di un processo (ad esempio per valutarne l'efficienza). In tal caso infatti
-fare ricorso al \textit{calendar time} è inutile in quanto il tempo può essere
+fare ricorso al \textit{calendar time} è inutile in quanto il tempo può essere
trascorso mentre un altro processo era in esecuzione o in attesa del risultato
di una operazione di I/O.
-La funzione più semplice per leggere il \textit{process time} di un processo è
+La funzione più semplice per leggere il \textit{process time} di un processo è
\funcd{clock}, che da una valutazione approssimativa del tempo di CPU
-utilizzato dallo stesso; il suo prototipo è:
+utilizzato dallo stesso; il suo prototipo è:
\begin{prototype}{time.h}{clock\_t clock(void)}
Legge il valore corrente del tempo di CPU.
1000000 indipendentemente dalla risoluzione del timer di sistema.} In genere
\type{clock\_t} viene rappresentato come intero a 32 bit, il che comporta un
valore massimo corrispondente a circa 72 minuti, dopo i quali il contatore
-riprenderà lo stesso valore iniziale.
+riprenderà lo stesso valore iniziale.
-Come accennato in sez.~\ref{sec:sys_unix_time} il tempo di CPU è la somma di
+Come accennato in sez.~\ref{sec:sys_unix_time} il tempo di CPU è la somma di
altri due tempi, l'\textit{user time} ed il \textit{system time} che sono
quelli effettivamente mantenuti dal kernel per ciascun processo. Questi
-possono essere letti attraverso la funzione \funcd{times}, il cui prototipo è:
+possono essere letti attraverso la funzione \funcd{times}, il cui prototipo è:
\begin{prototype}{sys/times.h}{clock\_t times(struct tms *buf)}
Legge in \param{buf} il valore corrente dei tempi di processore.
\end{prototype}
La funzione restituisce i valori di \textit{process time} del processo
-corrente in una struttura di tipo \struct{tms}, la cui definizione è riportata
+corrente in una struttura di tipo \struct{tms}, la cui definizione è riportata
in fig.~\ref{fig:sys_tms_struct}. La struttura prevede quattro campi; i primi
due, \var{tms\_utime} e \var{tms\_stime}, sono l'\textit{user time} ed il
-\textit{system time} del processo, così come definiti in
+\textit{system time} del processo, così come definiti in
sez.~\ref{sec:sys_unix_time}.
\begin{figure}[!htb]
Gli altri due campi mantengono rispettivamente la somma dell'\textit{user
time} ed del \textit{system time} di tutti i processi figli che sono
-terminati; il kernel cioè somma in \var{tms\_cutime} il valore di
-\var{tms\_utime} e \var{tms\_cutime} per ciascun figlio del quale è stato
+terminati; il kernel cioè somma in \var{tms\_cutime} il valore di
+\var{tms\_utime} e \var{tms\_cutime} per ciascun figlio del quale è stato
ricevuto lo stato di terminazione, e lo stesso vale per \var{tms\_cstime}.
Si tenga conto che l'aggiornamento di \var{tms\_cutime} e \var{tms\_cstime}
-viene eseguito solo quando una chiamata a \func{wait} o \func{waitpid} è
+viene eseguito solo quando una chiamata a \func{wait} o \func{waitpid} è
ritornata. Per questo motivo se un processo figlio termina prima di ricevere
lo stato di terminazione di tutti i suoi figli, questi processi
``\textsl{nipoti}'' non verranno considerati nel calcolo di questi tempi.
\itindbeg{calendar~time}
-Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time} è
+Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time} è
mantenuto dal kernel in una variabile di tipo \type{time\_t},\footnote{in
- realtà il kernel usa una rappresentazione interna di che fornisce una
+ realtà il kernel usa una rappresentazione interna di che fornisce una
precisione molto maggiore, e consente per questo anche di usare
rappresentazioni diverse del \textit{calendar time}.} che usualmente
-corrisponde ad un tipo elementare (in Linux è definito come \ctyp{long int},
+corrisponde ad un tipo elementare (in Linux è definito come \ctyp{long int},
che di norma corrisponde a 32 bit). Il valore corrente del \textit{calendar
- time}, che indicheremo come \textsl{tempo di sistema}, può essere ottenuto
+ time}, che indicheremo come \textsl{tempo di sistema}, può essere ottenuto
con la funzione \funcd{time} che lo restituisce nel suddetto formato; il suo
-prototipo è:
+prototipo è:
\begin{prototype}{time.h}{time\_t time(time\_t *t)}
Legge il valore corrente del \textit{calendar time}.
\bodydesc{La funzione ritorna il valore del \textit{calendar time} in caso
- di successo e -1 in caso di errore, che può essere solo \errval{EFAULT}.}
+ di successo e -1 in caso di errore, che può essere solo \errval{EFAULT}.}
\end{prototype}
\noindent dove \param{t}, se non nullo, deve essere l'indirizzo di una
variabile su cui duplicare il valore di ritorno.
-Analoga a \func{time} è la funzione \funcd{stime} che serve per effettuare
-l'operazione inversa, e cioè per impostare il tempo di sistema qualora questo
-sia necessario; il suo prototipo è:
+Analoga a \func{time} è la funzione \funcd{stime} che serve per effettuare
+l'operazione inversa, e cioè per impostare il tempo di sistema qualora questo
+sia necessario; il suo prototipo è:
\begin{prototype}{time.h}{int stime(time\_t *t)}
Imposta a \param{t} il valore corrente del \textit{calendar time}.
\bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- che può essere \errval{EFAULT} o \errval{EPERM}.}
+ che può essere \errval{EFAULT} o \errval{EPERM}.}
\end{prototype}
\noindent dato che modificare l'ora ha un impatto su tutto il sistema
-il cambiamento dell'orologio è una operazione privilegiata e questa funzione
-può essere usata solo da un processo con i privilegi di amministratore,
-altrimenti la chiamata fallirà con un errore di \errcode{EPERM}.
+il cambiamento dell'orologio è una operazione privilegiata e questa funzione
+può essere usata solo da un processo con i privilegi di amministratore,
+altrimenti la chiamata fallirà con un errore di \errcode{EPERM}.
Data la scarsa precisione nell'uso di \type{time\_t} (che ha una risoluzione
massima di un secondo) quando si devono effettuare operazioni sui tempi di
-norma l'uso delle funzioni precedenti è sconsigliato, ed esse sono di solito
+norma l'uso delle funzioni precedenti è sconsigliato, ed esse sono di solito
sostituite da \funcd{gettimeofday} e \funcd{settimeofday},\footnote{le due
- funzioni \func{time} e \func{stime} sono più antiche e derivano da SVr4,
+ funzioni \func{time} e \func{stime} sono più antiche e derivano da SVr4,
\func{gettimeofday} e \func{settimeofday} sono state introdotte da BSD, ed
in BSD4.3 sono indicate come sostitute delle precedenti.} i cui prototipi
sono:
Imposta il tempo di sistema.
\bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
- caso di errore, nel qual caso \var{errno} può assumere i valori
+ caso di errore, nel qual caso \var{errno} può assumere i valori
\errval{EINVAL} \errval{EFAULT} e per \func{settimeofday} anche
\errval{EPERM}.}
\end{functions}
Si noti come queste funzioni utilizzino per indicare il tempo una struttura di
-tipo \struct{timeval}, la cui definizione si è già vista in
+tipo \struct{timeval}, la cui definizione si è già vista in
fig.~\ref{fig:sys_timeval_struct}, questa infatti permette una espressione
alternativa dei valori del \textit{calendar time}, con una precisione,
-rispetto a \type{time\_t}, fino al microsecondo.\footnote{la precisione è solo
+rispetto a \type{time\_t}, fino al microsecondo.\footnote{la precisione è solo
teorica, la precisione reale della misura del tempo dell'orologio di sistema
non dipende dall'uso di queste strutture.}
Come nel caso di \func{stime} anche \func{settimeofday} (la cosa continua a
valere per qualunque funzione che vada a modificare l'orologio di sistema,
-quindi anche per quelle che tratteremo in seguito) può essere utilizzata solo
-da un processo coi privilegi di amministratore.\footnote{più precisamente la
+quindi anche per quelle che tratteremo in seguito) può essere utilizzata solo
+da un processo coi privilegi di amministratore.\footnote{più precisamente la
capabitity \const{CAP\_SYS\_TIME}.}
-Il secondo argomento di entrambe le funzioni è una struttura
+Il secondo argomento di entrambe le funzioni è una struttura
\struct{timezone}, che storicamente veniva utilizzata per specificare appunto
-la \textit{time zone}, cioè l'insieme del fuso orario e delle convenzioni per
+la \textit{time zone}, cioè l'insieme del fuso orario e delle convenzioni per
l'ora legale che permettevano il passaggio dal tempo universale all'ora
-locale. Questo argomento oggi è obsoleto ed in Linux non è mai stato
-utilizzato; esso non è supportato né dalle vecchie \textsl{libc5}, né dalle
+locale. Questo argomento oggi è obsoleto ed in Linux non è mai stato
+utilizzato; esso non è supportato né dalle vecchie \textsl{libc5}, né dalle
\textsl{glibc}: pertanto quando si chiama questa funzione deve essere sempre
impostato a \val{NULL}.
-Modificare l'orologio di sistema con queste funzioni è comunque problematico,
-in quanto esse effettuano un cambiamento immediato. Questo può creare dei
+Modificare l'orologio di sistema con queste funzioni è comunque problematico,
+in quanto esse effettuano un cambiamento immediato. Questo può creare dei
buchi o delle ripetizioni nello scorrere dell'orologio di sistema, con
conseguenze indesiderate. Ad esempio se si porta avanti l'orologio si possono
-perdere delle esecuzioni di \cmd{cron} programmate nell'intervallo che si è
+perdere delle esecuzioni di \cmd{cron} programmate nell'intervallo che si è
saltato. Oppure se si porta indietro l'orologio si possono eseguire due volte
delle operazioni previste nell'intervallo di tempo che viene ripetuto.
-Per questo motivo la modalità più corretta per impostare l'ora è quella di
-usare la funzione \funcd{adjtime}, il cui prototipo è:
+Per questo motivo la modalità più corretta per impostare l'ora è quella di
+usare la funzione \funcd{adjtime}, il cui prototipo è:
\begin{prototype}{sys/time.h}
{int adjtime(const struct timeval *delta, struct timeval *olddelta)}
Aggiusta del valore \param{delta} l'orologio di sistema.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errcode{EPERM}.}
+ errore, nel qual caso \var{errno} assumerà il valore \errcode{EPERM}.}
\end{prototype}
Questa funzione permette di avere un aggiustamento graduale del tempo di
sistema in modo che esso sia sempre crescente in maniera monotona. Il valore
-di \param{delta} esprime il valore di cui si vuole spostare l'orologio; se è
-positivo l'orologio sarà accelerato per un certo tempo in modo da guadagnare
-il tempo richiesto, altrimenti sarà rallentato. Il secondo argomento viene
+di \param{delta} esprime il valore di cui si vuole spostare l'orologio; se è
+positivo l'orologio sarà accelerato per un certo tempo in modo da guadagnare
+il tempo richiesto, altrimenti sarà rallentato. Il secondo argomento viene
usato, se non nullo, per ricevere il valore dell'ultimo aggiustamento
effettuato.
\label{fig:sys_timex_struct}
\end{figure}
-Linux poi prevede un'altra funzione, che consente un aggiustamento molto più
+Linux poi prevede un'altra funzione, che consente un aggiustamento molto più
dettagliato del tempo, permettendo ad esempio anche di modificare anche la
-velocità dell'orologio di sistema. La funzione è \funcd{adjtimex} ed il suo
-prototipo è:
+velocità dell'orologio di sistema. La funzione è \funcd{adjtimex} ed il suo
+prototipo è:
\begin{prototype}{sys/timex.h}
{int adjtimex(struct timex *buf)}
\bodydesc{La funzione restituisce lo stato dell'orologio (un valore $>0$) in
caso di successo e -1 in caso di errore, nel qual caso \var{errno}
- assumerà i valori \errval{EFAULT}, \errval{EINVAL} ed \errval{EPERM}.}
+ assumerà i valori \errval{EFAULT}, \errval{EINVAL} ed \errval{EPERM}.}
\end{prototype}
La funzione richiede una struttura di tipo \struct{timex}, la cui definizione,
-così come effettuata in \file{sys/timex.h}, è riportata in
+così come effettuata in \file{sys/timex.h}, è riportata in
fig.~\ref{fig:sys_timex_struct}. L'azione della funzione dipende dal valore del
campo \var{mode}, che specifica quale parametro dell'orologio di sistema,
specificato in un opportuno campo di \struct{timex}, deve essere impostato. Un
tab.~\ref{tab:sys_timex_mode}.
La funzione utilizza il meccanismo di David L. Mills, descritto
-nell'\href{http://www.ietf.org/rfc/rfc1305.txt}{RFC~1305}, che è alla base del
-protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la
-portabilità è un requisito, le \acr{glibc} provvedono anche un suo omonimo
+nell'\href{http://www.ietf.org/rfc/rfc1305.txt}{RFC~1305}, che è alla base del
+protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la
+portabilità è un requisito, le \acr{glibc} provvedono anche un suo omonimo
\func{ntp\_adjtime}. La trattazione completa di questa funzione necessita di
una lettura approfondita del meccanismo descritto nell'RFC~1305, ci limitiamo
a descrivere in tab.~\ref{tab:sys_timex_mode} i principali valori utilizzabili
-per il campo \var{mode}, un elenco più dettagliato del significato dei vari
-campi della struttura \struct{timex} può essere ritrovato in \cite{glibc}.
+per il campo \var{mode}, un elenco più dettagliato del significato dei vari
+campi della struttura \struct{timex} può essere ritrovato in \cite{glibc}.
\begin{table}[!htb]
\footnotesize
\label{tab:sys_timex_mode}
\end{table}
-Il valore delle costanti per \var{mode} può essere anche espresso, secondo la
+Il valore delle costanti per \var{mode} può essere anche espresso, secondo la
sintassi specificata per la forma equivalente di questa funzione definita come
\func{ntp\_adjtime}, utilizzando il prefisso \code{MOD} al posto di
\code{ADJ}.
\textbf{Nome} & \textbf{Valore} & \textbf{Significato}\\
\hline
\hline
- \const{TIME\_OK} & 0 & L'orologio è sincronizzato.\\
+ \const{TIME\_OK} & 0 & L'orologio è sincronizzato.\\
\const{TIME\_INS} & 1 & Insert leap second.\\
\const{TIME\_DEL} & 2 & Delete leap second.\\
\const{TIME\_OOP} & 3 & Leap second in progress.\\
\const{TIME\_WAIT} & 4 & Leap second has occurred.\\
- \const{TIME\_BAD} & 5 & L'orologio non è sincronizzato.\\
+ \const{TIME\_BAD} & 5 & L'orologio non è sincronizzato.\\
\hline
\end{tabular}
\caption{Possibili valori di ritorno di \func{adjtimex}.}
\end{table}
La funzione ritorna un valore positivo che esprime lo stato dell'orologio di
-sistema; questo può assumere i valori riportati in
+sistema; questo può assumere i valori riportati in
tab.~\ref{tab:sys_adjtimex_return}. Un valore di -1 viene usato per riportare
-un errore; al solito se si cercherà di modificare l'orologio di sistema
+un errore; al solito se si cercherà di modificare l'orologio di sistema
(specificando un \var{mode} diverso da zero) senza avere i privilegi di
-amministratore si otterrà un errore di \errcode{EPERM}.
+amministratore si otterrà un errore di \errcode{EPERM}.
\label{sec:sys_date}
Le funzioni viste al paragrafo precedente sono molto utili per trattare le
-operazioni elementari sui tempi, però le rappresentazioni del tempo ivi
+operazioni elementari sui tempi, però le rappresentazioni del tempo ivi
illustrate, se han senso per specificare un intervallo, non sono molto
-intuitive quando si deve esprimere un'ora o una data. Per questo motivo è
+intuitive quando si deve esprimere un'ora o una data. Per questo motivo è
stata introdotta una ulteriore rappresentazione, detta \textit{broken-down
time}, che permette appunto di \textsl{suddividere} il \textit{calendar
time} usuale in ore, minuti, secondi, ecc.
Questo viene effettuato attraverso una opportuna struttura \struct{tm}, la cui
-definizione è riportata in fig.~\ref{fig:sys_tm_struct}, ed è in genere questa
+definizione è riportata in fig.~\ref{fig:sys_tm_struct}, ed è in genere questa
struttura che si utilizza quando si deve specificare un tempo a partire dai
dati naturali (ora e data), dato che essa consente anche di trattare la
-gestione del fuso orario e dell'ora legale.\footnote{in realtà i due campi
+gestione del fuso orario e dell'ora legale.\footnote{in realtà i due campi
\var{tm\_gmtoff} e \var{tm\_zone} sono estensioni previste da BSD e dalle
- \acr{glibc}, che, quando è definita \macro{\_BSD\_SOURCE}, hanno la forma in
+ \acr{glibc}, che, quando è definita \macro{\_BSD\_SOURCE}, hanno la forma in
fig.~\ref{fig:sys_tm_struct}.}
Le funzioni per la gestione del \textit{broken-down time} sono varie e vanno
"Wed Jun 30 21:49:08 1993\n"
\end{verbatim}
e impostano anche la variabile \var{tzname} con l'informazione della
-\textit{time zone} corrente; \func{ctime} è banalmente definita in termini di
+\textit{time zone} corrente; \func{ctime} è banalmente definita in termini di
\func{asctime} come \code{asctime(localtime(t)}. Dato che l'uso di una stringa
statica rende le funzioni non \index{funzioni!rientranti} rientranti POSIX.1c
e SUSv2 prevedono due sostitute \index{funzioni!rientranti} rientranti, il cui
-nome è al solito ottenuto aggiungendo un \code{\_r}, che prendono un secondo
+nome è al solito ottenuto aggiungendo un \code{\_r}, che prendono un secondo
argomento \code{char *buf}, in cui l'utente deve specificare il buffer su cui
la stringa deve essere copiata (deve essere di almeno 26 caratteri).
Le altre tre funzioni, \func{gmtime}, \func{localtime} e \func{mktime} servono
per convertire il tempo dal formato \type{time\_t} a quello di \struct{tm} e
viceversa; \func{gmtime} effettua la conversione usando il tempo coordinato
-universale (UTC), cioè l'ora di Greenwich; mentre \func{localtime} usa l'ora
+universale (UTC), cioè l'ora di Greenwich; mentre \func{localtime} usa l'ora
locale; \func{mktime} esegue la conversione inversa.
Anche in questo caso le prime due funzioni restituiscono l'indirizzo di una
struttura allocata staticamente, per questo sono state definite anche altre
due versioni \index{funzioni!rientranti} rientranti (con la solita estensione
\code{\_r}), che prevedono un secondo argomento \code{struct tm *result},
-fornito dal chiamante, che deve preallocare la struttura su cui sarà
+fornito dal chiamante, che deve preallocare la struttura su cui sarà
restituita la conversione.
Come mostrato in fig.~\ref{fig:sys_tm_struct} il \textit{broken-down time}
variabili globali mostrate in fig.~\ref{fig:sys_tzname}, cui si accede quando
si include \file{time.h}. Queste variabili vengono impostate quando si chiama
una delle precedenti funzioni di conversione, oppure invocando direttamente la
-funzione \funcd{tzset}, il cui prototipo è:
+funzione \funcd{tzset}, il cui prototipo è:
\begin{prototype}{sys/timex.h}
{void tzset(void)}
Imposta le variabili globali della \textit{time zone}.
- \bodydesc{La funzione non ritorna niente e non dà errori.}
+ \bodydesc{La funzione non ritorna niente e non dà errori.}
\end{prototype}
La funzione inizializza le variabili di fig.~\ref{fig:sys_tzname} a partire dal
-valore della variabile di ambiente \const{TZ}, se quest'ultima non è definita
-verrà usato il file \conffile{/etc/localtime}.
+valore della variabile di ambiente \const{TZ}, se quest'ultima non è definita
+verrà usato il file \conffile{/etc/localtime}.
\begin{figure}[!htb]
\footnotesize
\end{figure}
La variabile \var{tzname} contiene due stringhe, che indicano i due nomi
-standard della \textit{time zone} corrente. La prima è il nome per l'ora
+standard della \textit{time zone} corrente. La prima è il nome per l'ora
solare, la seconda per l'ora legale.\footnote{anche se sono indicati come
- \code{char *} non è il caso di modificare queste stringhe.} La variabile
+ \code{char *} non è il caso di modificare queste stringhe.} La variabile
\var{timezone} indica la differenza di fuso orario in secondi, mentre
-\var{daylight} indica se è attiva o meno l'ora legale.
+\var{daylight} indica se è attiva o meno l'ora legale.
-Benché la funzione \func{asctime} fornisca la modalità più immediata per
-stampare un tempo o una data, la flessibilità non fa parte delle sue
+Benché la funzione \func{asctime} fornisca la modalità più immediata per
+stampare un tempo o una data, la flessibilità non fa parte delle sue
caratteristiche; quando si vuole poter stampare solo una parte (l'ora, o il
-giorno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime},
-il cui prototipo è:
+giorno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime},
+il cui prototipo è:
\begin{prototype}{time.h}
{size\_t strftime(char *s, size\_t max, const char *format,
const struct tm *tm)}
\end{prototype}
La funzione converte opportunamente il tempo \param{tm} in una stringa di
-testo da salvare in \param{s}, purché essa sia di dimensione, indicata da
+testo da salvare in \param{s}, purché essa sia di dimensione, indicata da
\param{size}, sufficiente. I caratteri generati dalla funzione vengono
restituiti come valore di ritorno, ma non tengono conto del terminatore
finale, che invece viene considerato nel computo della dimensione; se
-quest'ultima è eccessiva viene restituito 0 e lo stato di \param{s} è
+quest'ultima è eccessiva viene restituito 0 e lo stato di \param{s} è
indefinito.
\begin{table}[htb]
domenica).\\
\var{\%w}&\texttt{3} & Giorno della settimana. \\
\var{\%W}&\texttt{16} & Settimana dell'anno (partendo dal
- lunedì).\\
+ lunedì).\\
\var{\%x}&\texttt{04/24/02} & La data.\\
\var{\%X}&\texttt{18:40:50} & L'ora.\\
\var{\%y}&\texttt{02} & Anno nel secolo.\\
\label{tab:sys_strftime_format}
\end{table}
-Il risultato della funzione è controllato dalla stringa di formato
+Il risultato della funzione è controllato dalla stringa di formato
\param{format}, tutti i caratteri restano invariati eccetto \texttt{\%} che
viene utilizzato come modificatore; alcuni\footnote{per la precisione quelli
definiti dallo standard ANSI C, che sono anche quelli riportati da POSIX.1;
le \acr{glibc} provvedono tutte le estensioni introdotte da POSIX.2 per il
comando \cmd{date}, i valori introdotti da SVID3 e ulteriori estensioni GNU;
- l'elenco completo dei possibili valori è riportato nella pagina di manuale
- della funzione.} dei possibili valori che esso può assumere sono riportati
+ l'elenco completo dei possibili valori è riportato nella pagina di manuale
+ della funzione.} dei possibili valori che esso può assumere sono riportati
in tab.~\ref{tab:sys_strftime_format}. La funzione tiene conto anche della
presenza di una localizzazione per stampare in maniera adeguata i vari nomi.
unix-like il kernel non avvisa mai direttamente un processo dell'occorrenza di
un errore nell'esecuzione di una funzione, ma di norma questo viene riportato
semplicemente usando un opportuno valore di ritorno della funzione invocata.
-Inoltre il sistema di classificazione degli errori è basato sull'architettura
+Inoltre il sistema di classificazione degli errori è basato sull'architettura
a processi, e presenta una serie di problemi nel caso lo si debba usare con i
\itindex{thread} \textit{thread}.
\label{sec:sys_errno}
Quasi tutte le funzioni delle librerie del C sono in grado di individuare e
-riportare condizioni di errore, ed è una norma fondamentale di buona
+riportare condizioni di errore, ed è una norma fondamentale di buona
programmazione controllare \textbf{sempre} che le funzioni chiamate si siano
concluse correttamente.
In genere le funzioni di libreria usano un valore speciale per indicare che
-c'è stato un errore. Di solito questo valore è -1 o un puntatore nullo o la
+c'è stato un errore. Di solito questo valore è -1 o un puntatore nullo o la
costante \val{EOF} (a seconda della funzione); ma questo valore segnala solo
-che c'è stato un errore, non il tipo di errore.
+che c'è stato un errore, non il tipo di errore.
Per riportare il tipo di errore il sistema usa la variabile globale
-\var{errno},\footnote{l'uso di una variabile globale può comportare alcuni
+\var{errno},\footnote{l'uso di una variabile globale può comportare alcuni
problemi (ad esempio nel caso dei \itindex{thread} \textit{thread}) ma lo
standard ISO C consente anche di definire \var{errno} come un
- \textit{modifiable lvalue}, quindi si può anche usare una macro, e questo è
+ \textit{modifiable lvalue}, quindi si può anche usare una macro, e questo è
infatti il modo usato da Linux per renderla locale ai singoli
\itindex{thread} \textit{thread}.} definita nell'header \file{errno.h}; la
-variabile è in genere definita come \direct{volatile} dato che può essere
+variabile è in genere definita come \direct{volatile} dato che può essere
cambiata in modo asincrono da un segnale (si veda sez.~\ref{sec:sig_sigchld}
per un esempio, ricordando quanto trattato in sez.~\ref{sec:proc_race_cond}),
ma dato che un gestore di segnale scritto bene salva e ripristina il valore
-della variabile, di questo non è necessario preoccuparsi nella programmazione
+della variabile, di questo non è necessario preoccuparsi nella programmazione
normale.
-I valori che può assumere \var{errno} sono riportati in app.~\ref{cha:errors},
+I valori che può assumere \var{errno} sono riportati in app.~\ref{cha:errors},
nell'header \file{errno.h} sono anche definiti i nomi simbolici per le
costanti numeriche che identificano i vari errori; essi iniziano tutti per
\val{E} e si possono considerare come nomi riservati. In seguito faremo
Il valore di \var{errno} viene sempre impostato a zero all'avvio di un
programma, gran parte delle funzioni di libreria impostano \var{errno} ad un
-valore diverso da zero in caso di errore. Il valore è invece indefinito in
-caso di successo, perché anche se una funzione ha successo, può chiamarne
-altre al suo interno che falliscono, modificando così \var{errno}.
-
-Pertanto un valore non nullo di \var{errno} non è sintomo di errore (potrebbe
-essere il risultato di un errore precedente) e non lo si può usare per
-determinare quando o se una chiamata a funzione è fallita. La procedura da
-seguire è sempre quella di controllare \var{errno} immediatamente dopo aver
+valore diverso da zero in caso di errore. Il valore è invece indefinito in
+caso di successo, perché anche se una funzione ha successo, può chiamarne
+altre al suo interno che falliscono, modificando così \var{errno}.
+
+Pertanto un valore non nullo di \var{errno} non è sintomo di errore (potrebbe
+essere il risultato di un errore precedente) e non lo si può usare per
+determinare quando o se una chiamata a funzione è fallita. La procedura da
+seguire è sempre quella di controllare \var{errno} immediatamente dopo aver
verificato il fallimento della funzione attraverso il suo codice di ritorno.
\subsection{Le funzioni \func{strerror} e \func{perror}}
\label{sec:sys_strerror}
-Benché gli errori siano identificati univocamente dal valore numerico di
+Benché gli errori siano identificati univocamente dal valore numerico di
\var{errno} le librerie provvedono alcune funzioni e variabili utili per
riportare in opportuni messaggi le condizioni di errore verificatesi. La
-prima funzione che si può usare per ricavare i messaggi di errore è
-\funcd{strerror}, il cui prototipo è:
+prima funzione che si può usare per ricavare i messaggi di errore è
+\funcd{strerror}, il cui prototipo è:
\begin{prototype}{string.h}{char *strerror(int errnum)}
Restituisce una stringa con il messaggio di errore relativo ad
\param{errnum}.
La funzione ritorna il puntatore alla stringa contenente il messaggio di
-errore corrispondente al valore di \param{errnum}, se questo non è un valore
-valido verrà comunque restituita una stringa valida contenente un messaggio
-che dice che l'errore è sconosciuto, e \var{errno} verrà modificata assumendo
+errore corrispondente al valore di \param{errnum}, se questo non è un valore
+valido verrà comunque restituita una stringa valida contenente un messaggio
+che dice che l'errore è sconosciuto, e \var{errno} verrà modificata assumendo
il valore \errval{EINVAL}.
In generale \func{strerror} viene usata passando \var{errno} come argomento,
-ed il valore di quest'ultima non verrà modificato. La funzione inoltre tiene
+ed il valore di quest'ultima non verrà modificato. La funzione inoltre tiene
conto del valore della variabile di ambiente \val{LC\_MESSAGES} per usare le
appropriate traduzioni dei messaggi d'errore nella localizzazione presente.
La funzione utilizza una stringa statica che non deve essere modificata dal
-programma; essa è utilizzabile solo fino ad una chiamata successiva a
+programma; essa è utilizzabile solo fino ad una chiamata successiva a
\func{strerror} o \func{perror}, nessun'altra funzione di libreria tocca
questa stringa. In ogni caso l'uso di una stringa statica rende la funzione
non \index{funzioni!rientranti} rientrante, per cui nel caso si usino i
\itindex{thread} \textit{thread} le librerie forniscono\footnote{questa
- funzione è la versione prevista dalle \acr{glibc}, ed effettivamente
+ funzione è la versione prevista dalle \acr{glibc}, ed effettivamente
definita in \file{string.h}, ne esiste una analoga nello standard SUSv3
(quella riportata dalla pagina di manuale), che restituisce \code{int} al
posto di \code{char *}, e che tronca la stringa restituita a
\param{size}.} una apposita versione \index{funzioni!rientranti} rientrante
-\func{strerror\_r}, il cui prototipo è:
+\func{strerror\_r}, il cui prototipo è:
\begin{prototype}{string.h}
{char * strerror\_r(int errnum, char *buf, size\_t size)}
\bodydesc{La funzione restituisce l'indirizzo del messaggio in caso di
successo e \val{NULL} in caso di errore; nel qual caso \var{errno}
- assumerà i valori:
+ assumerà i valori:
\begin{errlist}
- \item[\errcode{EINVAL}] si è specificato un valore di \param{errnum} non
+ \item[\errcode{EINVAL}] si è specificato un valore di \param{errnum} non
valido.
- \item[\errcode{ERANGE}] la lunghezza di \param{buf} è insufficiente a
+ \item[\errcode{ERANGE}] la lunghezza di \param{buf} è insufficiente a
contenere la stringa di errore.
\end{errlist}}
\end{prototype}
\noindent
-La funzione è analoga a \func{strerror} ma restituisce la stringa di errore
+La funzione è analoga a \func{strerror} ma restituisce la stringa di errore
nel buffer \param{buf} che il singolo \itindex{thread} \textit{thread} deve
allocare autonomamente per evitare i problemi connessi alla condivisione del
-buffer statico. Il messaggio è copiato fino alla dimensione massima del
+buffer statico. Il messaggio è copiato fino alla dimensione massima del
buffer, specificata dall'argomento
\param{size}, che deve comprendere pure il carattere di terminazione;
altrimenti la stringa viene troncata.
Una seconda funzione usata per riportare i codici di errore in maniera
-automatizzata sullo standard error (vedi sez.~\ref{sec:file_std_descr}) è
-\funcd{perror}, il cui prototipo è:
+automatizzata sullo standard error (vedi sez.~\ref{sec:file_std_descr}) è
+\funcd{perror}, il cui prototipo è:
\begin{prototype}{stdio.h}{void perror(const char *message)}
Stampa il messaggio di errore relativo al valore corrente di \var{errno}
sullo standard error; preceduto dalla stringa \param{message}.
in app.~\ref{cha:errors}), e, usando il valore corrente di \var{errno}, si
riferiscono all'ultimo errore avvenuto. La stringa specificata con
\param{message} viene stampato prima del messaggio d'errore, seguita dai due
-punti e da uno spazio, il messaggio è terminato con un a capo.
+punti e da uno spazio, il messaggio è terminato con un a capo.
-Il messaggio può essere riportato anche usando le due variabili globali:
+Il messaggio può essere riportato anche usando le due variabili globali:
\includecodesnip{listati/errlist.c}
dichiarate in \file{errno.h}. La prima contiene i puntatori alle stringhe di
-errore indicizzati da \var{errno}; la seconda esprime il valore più alto per
-un codice di errore, l'utilizzo di questa stringa è sostanzialmente
+errore indicizzati da \var{errno}; la seconda esprime il valore più alto per
+un codice di errore, l'utilizzo di questa stringa è sostanzialmente
equivalente a quello di \func{strerror}.
\begin{figure}[!htb]
\label{fig:sys_err_mess}
\end{figure}
-In fig.~\ref{fig:sys_err_mess} è riportata la sezione attinente del codice del
-programma \cmd{errcode}, che può essere usato per stampare i messaggi di
+In fig.~\ref{fig:sys_err_mess} è riportata la sezione attinente del codice del
+programma \cmd{errcode}, che può essere usato per stampare i messaggi di
errore e le costanti usate per identificare i singoli errori; il sorgente
-completo del programma è allegato nel file \file{ErrCode.c} e contiene pure la
+completo del programma è allegato nel file \file{ErrCode.c} e contiene pure la
gestione delle opzioni e tutte le definizioni necessarie ad associare il
-valore numerico alla costante simbolica. In particolare si è riportata la
+valore numerico alla costante simbolica. In particolare si è riportata la
sezione che converte la stringa passata come argomento in un intero
(\texttt{\small 1--2}), controllando con i valori di ritorno di \func{strtol}
che la conversione sia avvenuta correttamente (\texttt{\small 4--10}), e poi
\label{sec:sys_err_GNU}
Le precedenti funzioni sono quelle definite ed usate nei vari standard; le
-\acr{glibc} hanno però introdotto una serie di estensioni ``GNU'' che
-forniscono alcune funzionalità aggiuntive per una gestione degli errori
-semplificata e più efficiente.
+\acr{glibc} hanno però introdotto una serie di estensioni ``GNU'' che
+forniscono alcune funzionalità aggiuntive per una gestione degli errori
+semplificata e più efficiente.
La prima estensione consiste in due variabili, \code{char *
program\_invocation\_name} e \code{char * program\_invocation\_short\_name}
aggiungere il nome del programma (cosa comune quando si ha un programma che
non viene lanciato da linea di comando e salva gli errori in un file di log)
al messaggio d'errore. La prima contiene il nome usato per lanciare il
-programma (ed è equivalente ad \code{argv[0]}); la seconda mantiene solo il
+programma (ed è equivalente ad \code{argv[0]}); la seconda mantiene solo il
nome del programma (senza eventuali directory in testa).
-Uno dei problemi che si hanno con l'uso di \func{perror} è che non c'è
-flessibilità su quello che si può aggiungere al messaggio di errore, che può
+Uno dei problemi che si hanno con l'uso di \func{perror} è che non c'è
+flessibilità su quello che si può aggiungere al messaggio di errore, che può
essere solo una stringa. In molte occasioni invece serve poter scrivere dei
messaggi con maggiore informazione; ad esempio negli standard di
programmazione GNU si richiede che ogni messaggio di errore sia preceduto dal
-nome del programma, ed in generale si può voler stampare il contenuto di
+nome del programma, ed in generale si può voler stampare il contenuto di
qualche variabile; per questo le \acr{glibc} definiscono la funzione
-\funcd{error}, il cui prototipo è:
+\funcd{error}, il cui prototipo è:
\begin{prototype}{stdio.h}
{void error(int status, int errnum, const char *format, ...)}
nome del programma, come indicato dalla variabile globale \var{program\_name},
seguito da due punti ed uno spazio, poi dalla stringa generata da
\param{format} e dagli argomenti seguenti, seguita da due punti ed uno spazio
-infine il messaggio di errore relativo ad \param{errnum}, il tutto è terminato
+infine il messaggio di errore relativo ad \param{errnum}, il tutto è terminato
da un a capo.
-Il comportamento della funzione può essere ulteriormente controllato se si
+Il comportamento della funzione può essere ulteriormente controllato se si
definisce una variabile \var{error\_print\_progname} come puntatore ad una
funzione \ctyp{void} che restituisce \ctyp{void} che si incarichi di stampare
il nome del programma.
-L'argomento \param{status} può essere usato per terminare direttamente il
+L'argomento \param{status} può essere usato per terminare direttamente il
programma in caso di errore, nel qual caso \func{error} dopo la stampa del
messaggio di errore chiama \func{exit} con questo stato di uscita. Se invece
-il valore è nullo \func{error} ritorna normalmente ma viene incrementata
+il valore è nullo \func{error} ritorna normalmente ma viene incrementata
un'altra variabile globale, \var{error\_message\_count}, che tiene conto di
quanti errori ci sono stati.
-Un'altra funzione per la stampa degli errori, ancora più sofisticata, che
-prende due argomenti aggiuntivi per indicare linea e file su cui è avvenuto
-l'errore è \funcd{error\_at\_line}; il suo prototipo è:
+Un'altra funzione per la stampa degli errori, ancora più sofisticata, che
+prende due argomenti aggiuntivi per indicare linea e file su cui è avvenuto
+l'errore è \funcd{error\_at\_line}; il suo prototipo è:
\begin{prototype}{stdio.h}
{void error\_at\_line(int status, int errnum, const char *fname,
unsigned int lineno, const char *format, ...)}
\bodydesc{La funzione non restituisce nulla e non riporta errori.}
\end{prototype}
-\noindent ed il suo comportamento è identico a quello di \func{error} se non
+\noindent ed il suo comportamento è identico a quello di \func{error} se non
per il fatto che, separati con il solito due punti-spazio, vengono inseriti un
nome di file indicato da \param{fname} ed un numero di linea subito dopo la
stampa del nome del programma. Inoltre essa usa un'altra variabile globale,
\label{sec:TCP_connession}
Prima di entrare nei dettagli delle singole funzioni usate nelle applicazioni
-che utilizzano i socket TCP, è fondamentale spiegare alcune delle basi del
-funzionamento del protocollo, poiché questa conoscenza è essenziale per
+che utilizzano i socket TCP, è fondamentale spiegare alcune delle basi del
+funzionamento del protocollo, poiché questa conoscenza è essenziale per
comprendere il comportamento di dette funzioni per questo tipo di socket, ed
il relativo modello di programmazione.
Si ricordi che il protocollo TCP serve a creare degli \textit{stream socket},
-cioè una forma di canale di comunicazione che stabilisce una connessione
+cioè una forma di canale di comunicazione che stabilisce una connessione
stabile fra due stazioni, in modo che queste possano scambiarsi dei dati. In
-questa sezione ci concentreremo sulle modalità con le quali il protocollo dà
+questa sezione ci concentreremo sulle modalità con le quali il protocollo dà
inizio e conclude una connessione e faremo inoltre un breve accenno al
significato di alcuni dei vari \textsl{stati} ad essa associati.
\label{sec:TCP_conn_cre}
\itindbeg{three~way~handshake}
-Il processo che porta a creare una connessione TCP è chiamato \textit{three
+Il processo che porta a creare una connessione TCP è chiamato \textit{three
way handshake}; la successione tipica degli eventi (e dei
-\textsl{segmenti}\footnote{si ricordi che il segmento è l'unità elementare di
+\textsl{segmenti}\footnote{si ricordi che il segmento è l'unità elementare di
dati trasmessa dal protocollo TCP al livello successivo; tutti i segmenti
hanno un header che contiene le informazioni che servono allo \textit{stack
- TCP} (così viene di solito chiamata la parte del kernel che implementa il
+ TCP} (così viene di solito chiamata la parte del kernel che implementa il
protocollo) per realizzare la comunicazione, fra questi dati ci sono una
serie di flag usati per gestire la connessione, come SYN, ACK, URG, FIN,
alcuni di essi, come SYN (che sta per \textit{syncronize}) corrispondono a
funzioni particolari del protocollo e danno il nome al segmento, (per
maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).} di dati che vengono
-scambiati) che porta alla creazione di una connessione è la seguente:
+scambiati) che porta alla creazione di una connessione è la seguente:
\begin{enumerate}
\item Il server deve essere preparato per accettare le connessioni in arrivo;
e ACK.
\item una volta che il client ha ricevuto l'acknowledge dal server la funzione
- \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
+ \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
server inviando un ACK. Alla ricezione di quest'ultimo la funzione
- \func{accept} del server ritorna e la connessione è stabilita.
+ \func{accept} del server ritorna e la connessione è stabilita.
\end{enumerate}
Il procedimento viene chiamato \textit{three way handshake} dato che per
realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
-si è rappresentata graficamente la sequenza di scambio dei segmenti che
+si è rappresentata graficamente la sequenza di scambio dei segmenti che
stabilisce la connessione.
-% Una analogia citata da R. Stevens per la connessione TCP è quella con il
-% sistema del telefono. La funzione \func{socket} può essere considerata
-% l'equivalente di avere un telefono. La funzione \func{bind} è analoga al
-% dire alle altre persone qual è il proprio numero di telefono perché possano
-% chiamare. La funzione \func{listen} è accendere il campanello del telefono
+% Una analogia citata da R. Stevens per la connessione TCP è quella con il
+% sistema del telefono. La funzione \func{socket} può essere considerata
+% l'equivalente di avere un telefono. La funzione \func{bind} è analoga al
+% dire alle altre persone qual è il proprio numero di telefono perché possano
+% chiamare. La funzione \func{listen} è accendere il campanello del telefono
% per sentire le chiamate in arrivo. La funzione \func{connect} richiede di
-% conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è
+% conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è
% quando si risponde al telefono.
\begin{figure}[htb]
\label{fig:TCP_TWH}
\end{figure}
-Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
+Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
riportati in fig.~\ref{fig:TCP_TWH}): per gestire una connessione affidabile
infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
\textit{acknowledge number}) pari al numero di sequenza che il ricevente si
aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
-è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
-varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
+è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
+varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
\itindend{three~way~handshake}
\item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
\textit{Maximum Segment Size}, con questa opzione ciascun capo della
connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
- accettare per ciascun segmento nella connessione corrente. È possibile
+ accettare per ciascun segmento nella connessione corrente. È possibile
leggere e scrivere questo valore attraverso l'opzione del socket
\const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}).
window} (la ``\textsl{finestra annunciata}'', vedi
sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun capo della
comunicazione dichiara quanto spazio disponibile ha in memoria per i dati.
- Questo è un numero a 16 bit dell'header, che così può indicare un massimo di
- 65535 byte;\footnote{in Linux il massimo è 32767 per evitare problemi con
+ Questo è un numero a 16 bit dell'header, che così può indicare un massimo di
+ 65535 byte;\footnote{in Linux il massimo è 32767 per evitare problemi con
alcune implementazioni che usano l'aritmetica con segno per implementare
- lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità
+ lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità
(sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel cammino dei
- pacchetti (come i satelliti) richiedono una finestra più grande per poter
+ pacchetti (come i satelliti) richiedono una finestra più grande per poter
ottenere il massimo dalla trasmissione. Per questo esiste questa opzione che
indica un fattore di scala da applicare al valore della
\itindex{advertised~window} finestra annunciata\footnote{essendo una nuova
- opzione per garantire la compatibilità con delle vecchie implementazioni
+ opzione per garantire la compatibilità con delle vecchie implementazioni
del protocollo la procedura che la attiva prevede come negoziazione che
l'altro capo della connessione riconosca esplicitamente l'opzione
inserendola anche lui nel suo SYN di risposta dell'apertura della
connessione.} per la connessione corrente (espresso come numero di bit cui
spostare a sinistra il valore della finestra annunciata inserito nel
- pacchetto). Con Linux è possibile indicare al kernel di far negoziare il
+ pacchetto). Con Linux è possibile indicare al kernel di far negoziare il
fattore di scala in fase di creazione di una connessione tramite la
\textit{sysctl} \itindex{TCP~window~scaling} \texttt{tcp\_window\_scaling}
(vedi sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
- funzionalità è comunque necessario ampliare le dimensioni dei buffer di
- ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
+ funzionalità è comunque necessario ampliare le dimensioni dei buffer di
+ ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl})
che a livello di singoli socket con le relative opzioni (vedi
sez.~\ref{sec:sock_tcp_udp_options}).}
-\item \textit{timestamp option}, è anche questa una nuova opzione necessaria
- per le connessioni ad alta velocità per evitare possibili corruzioni di dati
+\item \textit{timestamp option}, è anche questa una nuova opzione necessaria
+ per le connessioni ad alta velocità per evitare possibili corruzioni di dati
dovute a pacchetti perduti che riappaiono; anche questa viene negoziata come
la precedente.
\end{itemize}
-La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
+La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
le implementazioni del protocollo, le ultime due opzioni (trattate
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
-vengono anche dette \textit{long fat pipe options} dato che questo è il nome
-che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
+vengono anche dette \textit{long fat pipe options} dato che questo è il nome
+che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
Mentre per la creazione di una connessione occorre un interscambio di tre
segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
-caso la successione degli eventi è la seguente:
+caso la successione degli eventi è la seguente:
\begin{enumerate}
\item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
\textit{active close}). Questo comporta l'emissione di un segmento FIN, che
- serve ad indicare che si è finito con l'invio dei dati sulla connessione.
+ serve ad indicare che si è finito con l'invio dei dati sulla connessione.
-\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
+\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
\textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
viene segnalato al processo che ha aperto il socket (dopo che ogni altro
- eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
- lettura: questo perché il ricevimento di un FIN significa che non si
+ eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
+ lettura: questo perché il ricevimento di un FIN significa che non si
riceveranno altri dati sulla connessione.
-\item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
+\item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
funzione \func{close} sul proprio socket, causando l'emissione di un altro
segmento FIN.
-\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
+\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
con un ACK.
\end{enumerate}
Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
-normalmente i segmenti scambiati sono quattro. Questo non è vero sempre
-giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
-Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
+normalmente i segmenti scambiati sono quattro. Questo non è vero sempre
+giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
+Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
effettua la chiusura passiva, siano accorpati in un singolo segmento. In
-fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
+fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
scambio dei segmenti che conclude la connessione.
\begin{figure}[htb]
\end{figure}
Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
-l'ACK riporterà un \textit{acknowledge number} incrementato di uno.
+l'ACK riporterà un \textit{acknowledge number} incrementato di uno.
-Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
+Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
possibile che si mantenga un flusso di dati dal capo della connessione che
deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
chiusura attiva. Nella sequenza indicata i dati verrebbero persi, dato che si
-è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
-situazioni in cui si vuole poter sfruttare questa possibilità, usando una
-procedura che è chiamata \itindex{half-close} \textit{half-close}; torneremo
+è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
+situazioni in cui si vuole poter sfruttare questa possibilità, usando una
+procedura che è chiamata \itindex{half-close} \textit{half-close}; torneremo
su questo aspetto e su come utilizzarlo in sez.~\ref{sec:TCP_shutdown}, quando
parleremo della funzione \func{shutdown}.
-La emissione del FIN avviene quando il socket viene chiuso, questo però non
+La emissione del FIN avviene quando il socket viene chiuso, questo però non
avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
alla terminazione di un processo, quando tutti i file vengono chiusi. Questo
comporta ad esempio che se un processo viene terminato da un segnale tutte le
connessioni aperte verranno chiuse.
-Infine occorre sottolineare che, benché nella figura (e nell'esempio che
-vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
-la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
+Infine occorre sottolineare che, benché nella figura (e nell'esempio che
+vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
+la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
dei due capi della comunicazione (come nell'esempio di
-fig.~\ref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
-resta quello del client, ci sono alcuni servizi, il principale dei quali è
-l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
+fig.~\ref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
+resta quello del client, ci sono alcuni servizi, il principale dei quali è
+l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
\subsection{Un esempio di connessione}
Come abbiamo visto le operazioni del TCP nella creazione e conclusione di una
connessione sono piuttosto complesse, ed abbiamo esaminato soltanto quelle
relative ad un andamento normale. In sez.~\ref{sec:TCP_states} vedremo con
-maggiori dettagli che una connessione può assumere vari stati, che ne
+maggiori dettagli che una connessione può assumere vari stati, che ne
caratterizzano il funzionamento, e che sono quelli che vengono riportati dal
comando \cmd{netstat}, per ciascun socket TCP aperto, nel campo
\textit{State}.
semplice esempio di connessione e le transizioni che avvengono nei due casi
appena citati (creazione e terminazione della connessione).
-In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
+In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
applicazione esegue una apertura attiva il TCP emette un SYN e lo stato
diventa \texttt{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
-emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
+emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
finale in cui avviene la gran parte del trasferimento dei dati.
Dal lato server in genere invece il passaggio che si opera con l'apertura
-passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
+passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
stato \texttt{LISTEN} in cui vengono accettate le connessioni.
-Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
+Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
chiama la funzione \func{close} prima di aver ricevuto un
-\textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
+\textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
\texttt{FIN\_WAIT\_1}; se invece l'applicazione riceve un FIN nello stato
-\texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
+\texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
\texttt{CLOSE\_WAIT}.
-In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
+In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
che il protocollo viene ad assumere per i due lati, server e client.
IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe essere
anche un valore diverso).
-Una volta che la connessione è stabilita il client scrive al server una
-richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
+Una volta che la connessione è stabilita il client scrive al server una
+richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
restituisce una risposta (che di nuovo supponiamo stare in un singolo
-segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
+segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
-volte che il server è sufficientemente veloce a costruire la risposta; in
+volte che il server è sufficientemente veloce a costruire la risposta; in
caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
risposta.
connessione che esegue la chiusura attiva entra nello stato
\texttt{TIME\_WAIT}, sul cui significato torneremo fra poco.
-È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
+È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
e uno di risposta) il TCP necessiti di ulteriori otto segmenti, se invece si
-fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
-costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
+fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
+costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
fosse usato UDP si sarebbe dovuto trasferire la gestione di tutta una serie di
dettagli (come la verifica della ricezione dei pacchetti) dal livello del
trasporto all'interno dell'applicazione.
-Quello che è bene sempre tenere presente è allora quali sono le esigenze che
-si hanno in una applicazione di rete, perché non è detto che TCP sia la
+Quello che è bene sempre tenere presente è allora quali sono le esigenze che
+si hanno in una applicazione di rete, perché non è detto che TCP sia la
miglior scelta in tutti i casi (ad esempio se si devono solo scambiare dati
-già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
-per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
-specifico le sue caratteristiche di velocità e compattezza nello scambio dei
+già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
+per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
+specifico le sue caratteristiche di velocità e compattezza nello scambio dei
dati rispondono meglio alle esigenze che devono essere affrontate.
\subsection{Lo stato \texttt{TIME\_WAIT}}
\label{sec:TCP_time_wait}
-Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
-probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
+Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
+probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
comune trovare domande su come sia possibile evitare che un'applicazione resti
-in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
+in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
-Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
-\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
+Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
+\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
esegue la chiusura attiva resta prima di passare alla chiusura definitiva
della connessione. Il tempo in cui l'applicazione resta in questo stato deve
essere due volte la MSL (\textit{Maximum Segment Lifetime}).
-La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
-sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
+La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
+sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
-Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
+Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
IP (per maggiori dettagli vedi sez.~\ref{sec:ip_protocol}), e viene
decrementato ad ogni passaggio da un router; quando si annulla il pacchetto
-viene scartato. Siccome il numero è ad 8 bit il numero massimo di
-``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
- live}) non è propriamente un limite sul tempo di vita, si stima che un
-pacchetto IP non possa restare nella rete per più di MSL secondi.
+viene scartato. Siccome il numero è ad 8 bit il numero massimo di
+``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
+ live}) non è propriamente un limite sul tempo di vita, si stima che un
+pacchetto IP non possa restare nella rete per più di MSL secondi.
Ogni implementazione del TCP deve scegliere un valore per la MSL
(l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
Linux usa 30 secondi), questo comporta una durata dello stato
-\texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
+\texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
minuti. Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due
motivi principali:
\begin{enumerate}
\item consentire l'eliminazione dei segmenti duplicati dalla rete.
\end{enumerate}
-Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
-riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
-capisce il perché della scelta di un tempo pari al doppio della MSL come
+Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
+riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
+capisce il perché della scelta di un tempo pari al doppio della MSL come
durata di questo stato.
-Il primo dei due motivi precedenti si può capire tornando a
+Il primo dei due motivi precedenti si può capire tornando a
fig.~\ref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
(quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue
-la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
+la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
-Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
+Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
verrebbe interpretato come un errore.
Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
dopo l'invio dell'ultimo ACK, per potere essere in grado di gestirne
l'eventuale ritrasmissione, in caso esso venga perduto.
-Il secondo motivo è più complesso da capire, e necessita di una spiegazione
-degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
+Il secondo motivo è più complesso da capire, e necessita di una spiegazione
+degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
rete o restare intrappolati, per poi riemergere in un secondo tempo.
-Il caso più comune in cui questo avviene è quello di anomalie
-nell'instradamento; può accadere cioè che un router smetta di funzionare o che
+Il caso più comune in cui questo avviene è quello di anomalie
+nell'instradamento; può accadere cioè che un router smetta di funzionare o che
una connessione fra due router si interrompa. In questo caso i protocolli di
instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
dei minuti) prima di trovare e stabilire un percorso alternativo per i
pacchetti. Nel frattempo possono accadere casi in cui un router manda i
pacchetti verso un altro e quest'ultimo li rispedisce indietro, o li manda ad
-un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
+un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
-Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
-non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
-frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
-giungerà a destinazione.
+Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
+non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
+frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
+giungerà a destinazione.
Ma se dopo un po' di tempo (che non supera il limite dell'MSL, dato che
altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare, il circolo di
instradamento viene spezzato i pacchetti intrappolati potranno essere inviati
alla destinazione finale, con la conseguenza di avere dei pacchetti duplicati;
-questo è un caso che il TCP deve essere in grado di gestire.
+questo è un caso che il TCP deve essere in grado di gestire.
Allora per capire la seconda ragione per l'esistenza dello stato
\texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
potrebbe trovare con dei pacchetti duplicati relativi alla precedente
connessione che riappaiono nella nuova.
-Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
+Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
\subsection{I numeri di porta}
\label{sec:TCP_port_num}
-In un ambiente multitasking in un dato momento più processi devono poter usare
-sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
+In un ambiente multitasking in un dato momento più processi devono poter usare
+sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i
-\textsl{numeri di porta}, che fanno parte, come si può vedere in
+\textsl{numeri di porta}, che fanno parte, come si può vedere in
sez.~\ref{sec:sock_sa_ipv4} e sez.~\ref{sec:sock_sa_ipv6} pure delle strutture
degli indirizzi del socket.
servizio SSH) effettuati da appositi server che rispondono alle connessioni
verso tali porte.
-D'altra parte un client non ha necessità di usare un numero di porta
+D'altra parte un client non ha necessità di usare un numero di porta
specifico, per cui in genere vengono usate le cosiddette \textsl{porte
- effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
+ effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
nessun servizio noto e che vengono assegnate automaticamente dal kernel alla
creazione della connessione. Queste sono dette effimere in quanto vengono
usate solo per la durata della connessione, e l'unico requisito che deve
-essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
+essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
-La lista delle porte conosciute è definita
+La lista delle porte conosciute è definita
dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene
l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
-internet (una versione aggiornata si può trovare all'indirizzo
+internet (una versione aggiornata si può trovare all'indirizzo
\href{http://www.iana.org/assignments/port-numbers}
{\textsf{http://www.iana.org/assignments/port-numbers}}); inoltre in un
sistema unix-like un analogo elenco viene mantenuto nel file
\begin{enumerate*}
\item \textsl{le porte note}. I numeri da 0 a 1023. Queste sono controllate e
- assegnate dalla IANA. Se è possibile la stessa porta è assegnata allo stesso
- servizio sia su UDP che su TCP (ad esempio la porta 22 è assegnata a SSH su
+ assegnate dalla IANA. Se è possibile la stessa porta è assegnata allo stesso
+ servizio sia su UDP che su TCP (ad esempio la porta 22 è assegnata a SSH su
entrambi i protocolli, anche se viene usata solo dal TCP).
\item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
- sono controllate dalla IANA, che però registra ed elenca chi usa queste
+ sono controllate dalla IANA, che però registra ed elenca chi usa queste
porte come servizio agli utenti. Come per le precedenti si assegna una porta
- ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
+ ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
- anche se il protocollo è implementato solo tramite TCP.
+ anche se il protocollo è implementato solo tramite TCP.
\item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a
65535. La IANA non dice nulla riguardo a queste porte che pertanto
sono i candidati naturali ad essere usate come porte effimere.
\end{enumerate*}
-In realtà rispetto a quanto indicato
+In realtà rispetto a quanto indicato
nell'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} i vari sistemi hanno
fatto scelte diverse per le porte effimere, in particolare in
fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux.
I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che
corrispondono alle porte con numero minore di 1024 e coincidono quindi con le
-\textsl{porte note}). La loro caratteristica è che possono essere assegnate a
-un socket solo da un processo con i privilegi di amministratore, per far sì
+\textsl{porte note}). La loro caratteristica è che possono essere assegnate a
+un socket solo da un processo con i privilegi di amministratore, per far sì
che solo l'amministratore possa allocare queste porte per far partire i
relativi servizi.
vale 1024) indica il limite superiore delle porte riservate, e la seconda (che
vale 5000) il limite inferiore delle porte a disposizione degli utenti. La
convenzione vorrebbe che le porte \textsl{effimere} siano allocate fra questi
-due valori. Nel caso di Linux questo è vero solo in uno dei due casi di
+due valori. Nel caso di Linux questo è vero solo in uno dei due casi di
fig.~\ref{fig:TCP_port_alloc}, e la scelta fra i due possibili intervalli
viene fatta dinamicamente dal kernel a seconda della memoria disponibile per
la gestione delle relative tabelle.
Si tenga conto poi che ci sono alcuni client, in particolare \cmd{rsh} e
\cmd{rlogin}, che richiedono una connessione su una porta riservata anche dal
lato client come parte dell'autenticazione, contando appunto sul fatto che
-solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
-termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
+solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
+termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
disuso.
Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da
non confondere con la coppia di socket della omonima funzione
\func{socketpair} che fanno riferimento ad una coppia di socket sulla stessa
macchina, non ai capi di una connessione TCP.} la combinazione dei quattro
-numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
+numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
locale e la porta TCP locale, e l'indirizzo IP remoto e la porta TCP remota.
Questa combinazione, che scriveremo usando una notazione del tipo
(\texttt{195.110.112.152:22}, \texttt{192.84.146.100:20100}), identifica
univocamente una connessione su internet. Questo concetto viene di solito
-esteso anche a UDP, benché in questo caso non abbia senso parlare di
+esteso anche a UDP, benché in questo caso non abbia senso parlare di
connessione. L'utilizzo del programma \cmd{netstat} permette di visualizzare
queste informazioni nei campi \textit{Local Address} e \textit{Foreing
Address}.
caching locale.
Questo ci mostra ad esempio che il server SSH ha compiuto un'apertura passiva,
-mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
+mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
-\cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
+\cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
definito in \file{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
anche per gli indirizzi l'asterisco come carattere che indica il valore
generico.
-Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
+Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
chiedere che senso abbia l'utilizzo dell'indirizzo generico per specificare
-l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
+l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
indirizzo IP (il cosiddetto \textit{multihoming}) esiste sempre anche
l'indirizzo di loopback, per cui con l'uso dell'indirizzo generico si possono
accettare connessioni indirizzate verso uno qualunque degli indirizzi IP
-presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
-sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
-indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
+presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
+sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
+indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
sull'interfaccia di loopback.
-Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
-quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
+Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
+quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
quest'ultima un client \cmd{ssh} per creare una connessione, e il kernel gli
-assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
+assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
espressa dalla socket pair (\texttt{192.84.146.100:21100},
\texttt{195.110.112.152:22}).
-Alla ricezione della richiesta dal client il server creerà un processo figlio
+Alla ricezione della richiesta dal client il server creerà un processo figlio
per gestire la connessione, se a questo punto eseguiamo nuovamente il
programma \cmd{netstat} otteniamo come risultato:
\begin{verbatim}
tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED
\end{verbatim}
-Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
-c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
-la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
+Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
+c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
+la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
il processo figlio gestisce la connessione mentre il padre resta in ascolto
sul socket originale.
Se a questo punto lanciamo un'altra volta il client \cmd{ssh} per una seconda
-connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
+connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
genere:
\begin{verbatim}
Active Internet connections (servers and established)
tcp 0 0 195.110.112.152:22 192.84.146.100:21100 ESTABLISHED
tcp 0 0 195.110.112.152:22 192.84.146.100:21101 ESTABLISHED
\end{verbatim}
-cioè il client effettuerà la connessione usando un'altra porta effimera: con
-questa sarà aperta la connessione, ed il server creerà un altro processo
+cioè il client effettuerà la connessione usando un'altra porta effimera: con
+questa sarà aperta la connessione, ed il server creerà un altro processo
figlio per gestirla.
-Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
-concorrente, non può suddividere i pacchetti solo sulla base della porta di
+Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
+concorrente, non può suddividere i pacchetti solo sulla base della porta di
destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
compresa la porta dell'indirizzo remoto. E se andassimo a vedere quali sono i
processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}, o
\label{sec:TCP_functions}
In questa sezione descriveremo in maggior dettaglio le varie funzioni che
-vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
-funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
+vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
+funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
precedente in sez.~\ref{sec:sock_socket}.
La funzione \funcd{bind} assegna un indirizzo locale ad un
socket.\footnote{nel nostro caso la utilizzeremo per socket TCP, ma la
- funzione è generica e deve essere usata per qualunque tipo di socket
- \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata
-cioè per specificare la prima parte dalla socket pair. Viene usata sul lato
+ funzione è generica e deve essere usata per qualunque tipo di socket
+ \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata
+cioè per specificare la prima parte dalla socket pair. Viene usata sul lato
server per specificare la porta (e gli eventuali indirizzi locali) su cui poi
-ci si porrà in ascolto. Il prototipo della funzione è il seguente:
+ci si porrà in ascolto. Il prototipo della funzione è il seguente:
\begin{prototype}{sys/socket.h}
{int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t addrlen)}
in caso di errore la variabile \var{errno} viene impostata secondo i
seguenti codici di errore:
\begin{errlist}
- \item[\errcode{EBADF}] il file descriptor non è valido.
- \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
- \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
- \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
+ \item[\errcode{EBADF}] il file descriptor non è valido.
+ \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
+ \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
+ \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
sufficienti privilegi.
- \item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
+ \item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
disponibile.
- \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
+ \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
\end{errlist}
ed anche \errval{EFAULT} e per i socket di tipo \const{AF\_UNIX},
\errval{ENOTDIR}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ELOOP},
\errval{ENOSR} e \errval{EROFS}.}
\end{prototype}
-Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
+Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
\func{socket}, mentre il secondo e terzo argomento sono rispettivamente
l'indirizzo (locale) del socket e la dimensione della struttura che lo
-contiene, secondo quanto già trattato in sez.~\ref{sec:sock_sockaddr}.
+contiene, secondo quanto già trattato in sez.~\ref{sec:sock_sockaddr}.
Con i socket TCP la chiamata \func{bind} permette di specificare l'indirizzo,
la porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
-nota che assegnano all'avvio, se questo non viene fatto è il kernel a
+nota che assegnano all'avvio, se questo non viene fatto è il kernel a
scegliere una porta effimera quando vengono eseguite la funzioni
-\func{connect} o \func{listen}, ma se questo è normale per il client non lo è
-per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
+\func{connect} o \func{listen}, ma se questo è normale per il client non lo è
+per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
In questo caso viene fatta assegnare dal kernel una porta effimera che poi
- viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
+ viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
demone che deve essere contattato dai client per ottenere la porta effimera
su cui si trova il server.} che in genere viene identificato dalla porta su
-cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
+cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
\conffile{/etc/services}).
-Con \func{bind} si può assegnare un indirizzo IP specifico ad un socket,
-purché questo appartenga ad una interfaccia della macchina. Per un client TCP
-questo diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati
-sul socket, mentre per un server TCP questo restringerà l'accesso al socket
+Con \func{bind} si può assegnare un indirizzo IP specifico ad un socket,
+purché questo appartenga ad una interfaccia della macchina. Per un client TCP
+questo diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati
+sul socket, mentre per un server TCP questo restringerà l'accesso al socket
solo alle connessioni che arrivano verso tale indirizzo.
Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel
sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla
-base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
+base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
regole di instradamento usate per raggiungere il server). Se un server non
-specifica il suo indirizzo locale il kernel userà come indirizzo di origine
+specifica il suo indirizzo locale il kernel userà come indirizzo di origine
l'indirizzo di destinazione specificato dal SYN del client.
Per specificare un indirizzo generico, con IPv4 si usa il valore
\const{INADDR\_ANY}, il cui valore, come accennato in
-sez.~\ref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
-fig.~\ref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione
+sez.~\ref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
+fig.~\ref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione
immediata del tipo: \includecodesnip{listati/serv_addr_sin_addr.c}
-Si noti che si è usato \func{htonl} per assegnare il valore
-\const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
+Si noti che si è usato \func{htonl} per assegnare il valore
+\const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
inutile. Si tenga presente comunque che tutte le costanti \val{INADDR\_}
(riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
\itindex{endianess} l'\textit{endianess} della macchina, ed anche se esse
-possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
+possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
norma usare sempre la funzione \func{htonl}.
\begin{table}[htb]
\label{tab:TCP_ipv4_addr}
\end{table}
-L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
-rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
+L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
+rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
metodo con IPv6, in cui l'indirizzo deve necessariamente essere specificato
-con una struttura, perché il linguaggio C non consente l'uso di una struttura
+con una struttura, perché il linguaggio C non consente l'uso di una struttura
costante come operando a destra in una assegnazione.
-Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
+Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
\macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
-maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per
+maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per
indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
\subsection{La funzione \func{connect}}
\label{sec:TCP_func_connect}
-La funzione \funcd{connect} è usata da un client TCP per stabilire la
-connessione con un server TCP,\footnote{di nuovo la funzione è generica e
- supporta vari tipi di socket, la differenza è che per socket senza
+La funzione \funcd{connect} è usata da un client TCP per stabilire la
+connessione con un server TCP,\footnote{di nuovo la funzione è generica e
+ supporta vari tipi di socket, la differenza è che per socket senza
connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si
- limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
+ limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
- \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
+ \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
TCP il \itindex{three~way~handshake} \textit{three way handshake}) della
- connessione.} il prototipo della funzione è il seguente:
+ connessione.} il prototipo della funzione è il seguente:
\begin{prototype}{sys/socket.h}
{int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t
addrlen)}
Stabilisce una connessione fra due socket.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
+ \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
remoto.
- \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
+ \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
connessione.
- \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
- \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
- sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa
+ \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
+ \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
+ sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa
immediatamente.
- \item[\errcode{EALREADY}] il socket è non bloccante (vedi
+ \item[\errcode{EALREADY}] il socket è non bloccante (vedi
sez.~\ref{sec:file_noblocking}) e un tentativo precedente di connessione
- non si è ancora concluso.
- \item[\errcode{EAGAIN}] non ci sono più porte locali libere.
+ non si è ancora concluso.
+ \item[\errcode{EAGAIN}] non ci sono più porte locali libere.
\item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
corretta nel relativo campo.
- \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
+ \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
connessione ad un indirizzo \itindex{broadcast} \textit{broadcast} senza
che il socket fosse stato abilitato per il \itindex{broadcast}
\textit{broadcast}.
\errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
\end{prototype}
-Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
+Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
\func{socket}, mentre il secondo e terzo argomento sono rispettivamente
l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
-socket, già descritta in sez.~\ref{sec:sock_sockaddr}.
+socket, già descritta in sez.~\ref{sec:sock_sockaddr}.
La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
numero di porta del server a cui ci si vuole connettere, come mostrato
Nel caso di socket TCP la funzione \func{connect} avvia il
\itindex{three~way~handshake} \textit{three way handshake}, e ritorna solo
-quando la connessione è stabilita o si è verificato un errore. Le possibili
+quando la connessione è stabilita o si è verificato un errore. Le possibili
cause di errore sono molteplici (ed i relativi codici riportati sopra), quelle
-che però dipendono dalla situazione della rete e non da errori o problemi
+che però dipendono dalla situazione della rete e non da errori o problemi
nella chiamata della funzione sono le seguenti:
\begin{enumerate}
-\item Il client non riceve risposta al SYN: l'errore restituito è
+\item Il client non riceve risposta al SYN: l'errore restituito è
\errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla
chiamata di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24
secondi, se dopo 75 secondi non ha ricevuto risposta viene ritornato
l'errore. Linux invece ripete l'emissione del SYN ad intervalli di 30
- 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
+ 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
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
+ valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
un timeout dopo circa 180 secondi.
-\item Il client riceve come risposta al SYN un RST significa che non c'è
+\item Il client riceve come risposta al SYN un RST significa che non c'è
nessun programma in ascolto per la connessione sulla porta specificata (il
- che vuol dire probabilmente che o si è sbagliato il numero della porta o che
- non è stato avviato il server), questo è un errore fatale e la funzione
+ che vuol dire probabilmente che o si è sbagliato il numero della porta o che
+ non è stato avviato il server), questo è un errore fatale e la funzione
ritorna non appena il RST viene ricevuto riportando un errore
\errcode{ECONNREFUSED}.
- Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
+ Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
quando arriva un SYN per una porta che non ha nessun server in ascolto,
quando il TCP abortisce una connessione in corso, quando TCP riceve un
segmento per una connessione che non esiste.
\item Il SYN del client provoca l'emissione di un messaggio ICMP di
- destinazione non raggiungibile. In questo caso dato che il messaggio può
+ destinazione non raggiungibile. In questo caso dato che il messaggio può
essere dovuto ad una condizione transitoria si ripete l'emissione dei SYN
come nel caso precedente, fino al timeout, e solo allora si restituisce il
codice di errore dovuto al messaggio ICMP, che da luogo ad un
dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
-socket non è più utilizzabile e deve essere chiuso.
+socket non è più utilizzabile e deve essere chiuso.
-Si noti infine che con la funzione \func{connect} si è specificato solo
-indirizzo e porta del server, quindi solo una metà della socket pair; essendo
-questa funzione usata nei client l'altra metà contenente indirizzo e porta
-locale viene lasciata all'assegnazione automatica del kernel, e non è
+Si noti infine che con la funzione \func{connect} si è specificato solo
+indirizzo e porta del server, quindi solo una metà della socket pair; essendo
+questa funzione usata nei client l'altra metà contenente indirizzo e porta
+locale viene lasciata all'assegnazione automatica del kernel, e non è
necessario effettuare una \func{bind}.
\subsection{La funzione \func{listen}}
\label{sec:TCP_func_listen}
-La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
+La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
come dice il nome, per metterlo in ascolto di eventuali
-connessioni;\footnote{questa funzione può essere usata con socket che
- supportino le connessioni, cioè di tipo \const{SOCK\_STREAM} o
- \const{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare
+connessioni;\footnote{questa funzione può essere usata con socket che
+ supportino le connessioni, cioè di tipo \const{SOCK\_STREAM} o
+ \const{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare
il socket dallo stato \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si
chiama la funzione in un server dopo le chiamate a \func{socket} e \func{bind}
e prima della chiamata ad \func{accept}. Il prototipo della funzione, come
-definito dalla pagina di manuale, è:
+definito dalla pagina di manuale, è:
\begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
Pone un socket in attesa di una connessione.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore. I codici di errore restituiti in \var{errno} sono i seguenti:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
valido.
- \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
- \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
operazione.
\end{errlist}}
\end{prototype}
-La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
+La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
predispone una coda per le connessioni in arrivo di lunghezza pari a
-\param{backlog}. La funzione si può applicare solo a socket di tipo
+\param{backlog}. La funzione si può applicare solo a socket di tipo
\const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}.
L'argomento \param{backlog} indica il numero massimo di connessioni pendenti
accettate; se esso viene ecceduto il client al momento della richiesta della
-connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
+connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
protocollo, come accade nel caso del TCP, supporta la ritrasmissione, la
-richiesta sarà ignorata in modo che la connessione possa venire ritentata.
+richiesta sarà ignorata in modo che la connessione possa venire ritentata.
-Per capire meglio il significato di tutto ciò occorre approfondire la modalità
+Per capire meglio il significato di tutto ciò occorre approfondire la modalità
con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto
infatti vengono mantenute due code:
\begin{enumerate}
\item La coda delle connessioni incomplete (\textit{incomplete connection
- queue}) che contiene un riferimento per ciascun socket per il quale è
+ queue}) che contiene un riferimento per ciascun socket per il quale è
arrivato un SYN ma il \itindex{three~way~handshake} \textit{three way
- handshake} non si è ancora concluso. Questi socket sono tutti nello stato
+ handshake} non si è ancora concluso. Questi socket sono tutti nello stato
\texttt{SYN\_RECV}.
\item La coda delle connessioni complete (\textit{complete connection queue})
che contiene un ingresso per ciascun socket per il quale il
- \itindex{three~way~handshake} \textit{three way handshake} è stato
- completato ma ancora \func{accept} non è ritornata. Questi socket sono
+ \itindex{three~way~handshake} \textit{three way handshake} è stato
+ completato ma ancora \func{accept} non è ritornata. Questi socket sono
tutti nello stato \texttt{ESTABLISHED}.
\end{enumerate}
-Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
+Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
quando arriva un SYN da un client il server crea una nuova voce nella coda
-delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
+delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
client o fino ad un timeout. Nel caso di completamento del
\itindex{three~way~handshake} \textit{three way handshake} la voce viene
spostata nella coda delle connessioni complete. Quando il processo chiama la
funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept}) la prima voce
-nella coda delle connessioni complete è passata al programma, o, se la coda è
+nella coda delle connessioni complete è passata al programma, o, se la coda è
vuota, il processo viene posto in attesa e risvegliato all'arrivo della prima
connessione completa.
kernel, compreso Linux 2.0, che mostrano le differenze fra diverse
implementazioni.
-In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
+In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
per prevenire l'attacco chiamato \index{SYN~flood} \textit{SYN flood}. Questo
si basa sull'emissione da parte dell'attaccante di un grande numero di
pacchetti SYN indirizzati verso una porta, forgiati con indirizzo IP
-fasullo\footnote{con la tecnica che viene detta \textit{ip spoofing}.} così
+fasullo\footnote{con la tecnica che viene detta \textit{ip spoofing}.} così
che i SYN$+$ACK vanno perduti e la coda delle connessioni incomplete viene
saturata, impedendo di fatto ulteriori connessioni.
-Per ovviare a questo il significato del \param{backlog} è stato cambiato a
+Per ovviare a questo il significato del \param{backlog} è stato cambiato a
indicare la lunghezza della coda delle connessioni complete. La lunghezza
-della coda delle connessioni incomplete può essere ancora controllata usando
+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
-protezione dei syncookies però (con l'opzione da compilare nel kernel e da
+protezione dei syncookies però (con l'opzione da compilare nel kernel e da
attivare usando \procfile{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore
-viene ignorato e non esiste più un valore massimo. In ogni caso in Linux il
+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
- questa costante può essere controllato con un altro parametro di
+è superiore a detta costante (che di default vale 128).\footnote{il valore di
+ questa costante può essere controllato con un altro parametro di
\func{sysctl}, vedi sez.~\ref{sec:sock_ioctl_IP}.}
La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
-kernel non supportavano neanche valori superiori, ma la situazione corrente è
+kernel non supportavano neanche valori superiori, ma la situazione corrente è
molto cambiata per via della presenza di server web che devono gestire un gran
-numero di connessioni per cui un tale valore non è più adeguato. Non esiste
+numero di connessioni per cui un tale valore non è più adeguato. Non esiste
comunque una risposta univoca per la scelta del valore, per questo non
conviene specificarlo con una costante (il cui cambiamento richiederebbe la
ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
sez.~\ref{sec:proc_environ}).
Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
-da casi reali su web server, ed in particolare evidenzia come non sia più vero
+da casi reali su web server, ed in particolare evidenzia come non sia più vero
che il compito principale della coda sia quello di gestire il caso in cui il
-server è occupato fra chiamate successive alla \func{accept} (per cui la coda
-più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
+server è occupato fra chiamate successive alla \func{accept} (per cui la coda
+più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
di gestire la presenza di un gran numero di SYN in attesa di concludere il
\itindex{three~way~handshake} \textit{three way handshake}.
Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
-con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
-condizione in cui le code sono piene è ovviamente transitoria, per cui se il
-client ritrasmette il SYN è probabile che passato un po' di tempo possa
+con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
+condizione in cui le code sono piene è ovviamente transitoria, per cui se il
+client ritrasmette il SYN è probabile che passato un po' di tempo possa
trovare nella coda lo spazio per una nuova connessione. Se invece si
-rispondesse con un RST, per indicare l'impossibilità di effettuare la
+rispondesse con un RST, per indicare l'impossibilità di effettuare la
connessione, la chiamata a \func{connect} nel client ritornerebbe con una
condizione di errore, costringendo a inserire nell'applicazione la gestione
-dei tentativi di riconnessione, che invece può essere effettuata in maniera
+dei tentativi di riconnessione, che invece può essere effettuata in maniera
trasparente dal protocollo TCP.
\subsection{La funzione \func{accept}}
\label{sec:TCP_func_accept}
-La funzione \funcd{accept} è chiamata da un server per gestire la connessione
+La funzione \funcd{accept} è chiamata da un server per gestire la connessione
una volta che sia stato completato il \itindex{three~way~handshake}
-\textit{three way handshake},\footnote{la funzione è comunque generica ed è
+\textit{three way handshake},\footnote{la funzione è comunque generica ed è
utilizzabile su socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET}
e \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su
-cui si potrà operare per effettuare la comunicazione. Se non ci sono
+cui si potrà operare per effettuare la comunicazione. Se non ci sono
connessioni completate il processo viene messo in attesa. Il prototipo della
-funzione è il seguente:
+funzione è il seguente:
\begin{prototype}{sys/socket.h}
{int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)}
impostata ai seguenti valori:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
valido.
- \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
- \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
operazione.
- \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
+ \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
come non bloccante (vedi sez.~\ref{sec:file_noblocking}), e non ci sono
connessioni in attesa di essere accettate.
\item[\errcode{EPERM}] le regole del firewall non consentono la connessione.
\item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
- l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
+ l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
non dalla memoria di sistema.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
+ \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}
Inoltre possono essere restituiti gli errori di rete relativi al nuovo
socket, diversi a secondo del protocollo, come: \errval{EMFILE},
toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene
posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella
variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza
-del client che si è connesso.
+del client che si è connesso.
-I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
+I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
passato per indirizzo per avere indietro il valore) sono usati per ottenere
l'indirizzo del client da cui proviene la connessione. Prima della chiamata
\param{addrlen} deve essere inizializzato alle dimensioni della struttura il
-cui indirizzo è passato come argomento in \param{addr}; al ritorno della
-funzione \param{addrlen} conterrà il numero di byte scritti dentro
-\param{addr}. Se questa informazione non interessa basterà inizializzare a
+cui indirizzo è passato come argomento in \param{addr}; al ritorno della
+funzione \param{addrlen} conterrà il numero di byte scritti dentro
+\param{addr}. Se questa informazione non interessa basterà inizializzare a
\val{NULL} detti puntatori.
Se la funzione ha successo restituisce il descrittore di un nuovo socket
creato dal kernel (detto \textit{connected socket}) a cui viene associata la
prima connessione completa (estratta dalla relativa coda, vedi
sez.~\ref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
-\param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
+\param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
funzione. Se non ci sono connessioni pendenti da accettare la funzione mette
in attesa il processo\footnote{a meno che non si sia impostato il socket per
essere non bloccante (vedi sez.~\ref{sec:file_noblocking}), nel qual caso
- ritorna con l'errore \errcode{EAGAIN}. Torneremo su questa modalità di
+ ritorna con l'errore \errcode{EAGAIN}. Torneremo su questa modalità di
operazione in sez.~\ref{sec:TCP_sock_multiplexing}.} fintanto che non ne
arriva una.
-La funzione può essere usata solo con socket che supportino la connessione
-(cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
+La funzione può essere usata solo con socket che supportino la connessione
+(cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
\const{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha
questo comportamento.} la funzione opera solo l'estrazione dalla coda delle
prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della
connessione viene eseguito con la funzione \func{close}.
-È da chiarire che Linux presenta un comportamento diverso nella gestione degli
+È da chiarire che Linux presenta un comportamento diverso nella gestione degli
errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
\func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
eventualmente ripetere la chiamata alla funzione come per l'errore di
\errcode{EAGAIN} (torneremo su questo in sez.~\ref{sec:TCP_echo_critical}).
-Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
+Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale
tutti quelli che si possono impostare con \func{fcntl}, vedi
sez.~\ref{sec:file_fcntl}.} che devono essere rispecificati ogni volta. Tutto
questo deve essere tenuto in conto se si devono scrivere programmi portabili.
-Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
-funzionamento di un server: in generale infatti c'è sempre un solo socket in
+Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
+funzionamento di un server: in generale infatti c'è sempre un solo socket in
ascolto, detto per questo \textit{listening socket}, che resta per tutto il
tempo nello stato \texttt{LISTEN}, mentre le connessioni vengono gestite dai
nuovi socket, detti \textit{connected socket}, ritornati da \func{accept}, che
si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
-della connessione. Si può riconoscere questo schema anche nell'esempio
+della connessione. Si può riconoscere questo schema anche nell'esempio
elementare di fig.~\ref{fig:TCP_daytime_iter_server_code}, dove per ogni
connessione il socket creato da \func{accept} viene chiuso dopo l'invio dei
dati.
Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono
alcune funzioni ausiliarie che possono essere usate per recuperare alcune
informazioni relative ai socket ed alle connessioni ad essi associate. Le due
-funzioni più elementari sono queste, che vengono usate per ottenere i dati
+funzioni più elementari sono queste, che vengono usate per ottenere i dati
relativi alla socket pair associata ad un certo socket.
-La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
-associato ad un socket; il suo prototipo è:
+La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
+associato ad un socket; il suo prototipo è:
\begin{prototype}{sys/socket.h}
{int getsockname(int sockfd, struct sockaddr *name, socklen\_t *namelen)}
Legge l'indirizzo locale di un socket.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore. I codici di errore restituiti in \var{errno} sono i seguenti:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
valido.
- \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
\item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
eseguire l'operazione.
- \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
+ \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
\end{errlist}}
\end{prototype}
La funzione restituisce la struttura degli indirizzi del socket \param{sockfd}
-nella struttura indicata dal puntatore \param{name} la cui lunghezza è
+nella struttura indicata dal puntatore \param{name} la cui lunghezza è
specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato
come indirizzo per avere indietro anche il numero di byte effettivamente
-scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
-utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
+scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
+utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
troncato.
La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
-socket; ad esempio può essere usata da un client (che usualmente non chiama
+socket; ad esempio può essere usata da un client (che usualmente non chiama
\func{bind}) per ottenere numero IP e porta locale associati al socket
restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
su un socket usando 0 come porta locale per ottenere il numero di porta
quella connessione.
Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
-funzione \funcd{getpeername}, il cui prototipo è:
+funzione \funcd{getpeername}, il cui prototipo è:
\begin{prototype}{sys/socket.h}
{int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
Legge l'indirizzo remoto di un socket.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore. I codici di errore restituiti in \var{errno} sono i seguenti:
\begin{errlist}
- \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
valido.
- \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
- \item[\errcode{ENOTCONN}] il socket non è connesso.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{ENOTCONN}] il socket non è connesso.
\item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
eseguire l'operazione.
\item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
\end{errlist}}
\end{prototype}
-La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
-restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
-capo della connessione. Ci si può chiedere a cosa serva questa funzione dato
-che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
+La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
+restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
+capo della connessione. Ci si può chiedere a cosa serva questa funzione dato
+che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
\func{connect} mentre dal lato server si possono usare, come vedremo in
fig.~\ref{fig:TCP_daytime_cunc_server_code}, i valori di ritorno di
\func{accept}.
-Il fatto è che in generale quest'ultimo caso non è sempre possibile. In
+Il fatto è che in generale quest'ultimo caso non è sempre possibile. In
particolare questo avviene quando il server, invece di gestire la connessione
direttamente in un processo figlio, come vedremo nell'esempio di server
concorrente di sez.~\ref{sec:TCP_daytime_cunc_server}, lancia per ciascuna
connessione un altro programma, usando \func{exec}.\footnote{questa ad esempio
- è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
+ è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
gestire tutta una serie di servizi diversi, eseguendo su ogni connessione
ricevuta sulle porte tenute sotto controllo, il relativo server.}
-In questo caso benché il processo figlio abbia una immagine della memoria che
-è copia di quella del processo padre (e contiene quindi anche la struttura
-ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
+In questo caso benché il processo figlio abbia una immagine della memoria che
+è copia di quella del processo padre (e contiene quindi anche la struttura
+ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
memoria l'immagine del programma eseguito, che a questo punto perde ogni
-riferimento ai valori tornati da \func{accept}. Il socket descriptor però
-resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
-programma eseguito qual è il socket connesso, \footnote{ad esempio il solito
+riferimento ai valori tornati da \func{accept}. Il socket descriptor però
+resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
+programma eseguito qual è il socket connesso, \footnote{ad esempio il solito
\cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
- al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
+ al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
per determinare l'indirizzo remoto del client.
-Infine è da chiarire (si legga la pagina di manuale) che, come per
-\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
-come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
-\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
+Infine è da chiarire (si legga la pagina di manuale) che, come per
+\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
+come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
+\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
socket BSD fanno questa assunzione.
\label{sec:TCP_func_close}
La funzione standard Unix \func{close} (vedi sez.~\ref{sec:file_close}) che si
-usa sui file può essere usata con lo stesso effetto anche sui file descriptor
+usa sui file può essere usata con lo stesso effetto anche sui file descriptor
associati ad un socket.
-L'azione di questa funzione quando applicata a socket è di marcarlo come
+L'azione di questa funzione quando applicata a socket è di marcarlo come
chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
-descriptor non è più utilizzabile dal processo e non può essere usato come
+descriptor non è più utilizzabile dal processo e non può essere usato come
argomento per una \func{write} o una \func{read} (anche se l'altro capo della
-connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
+connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
i dati che ha in coda prima di iniziare la sequenza di chiusura.
-Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile
-cambiare questo comportamento, e cosa può essere fatto perché il processo
+Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile
+cambiare questo comportamento, e cosa può essere fatto perché il processo
possa assicurarsi che l'altro capo abbia ricevuto tutti i dati.
Come per tutti i file descriptor anche per i socket viene mantenuto un numero
-di riferimenti, per cui se più di un processo ha lo stesso socket aperto
+di riferimenti, per cui se più di un processo ha lo stesso socket aperto
l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
fintanto che il numero di riferimenti non si annulla, questo si applica, come
visto in sez.~\ref{sec:file_sharing}, sia ai file descriptor duplicati che a
-quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
+quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
si aspetta in una qualunque applicazione client/server.
Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
-descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
+descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
\func{shutdown} su cui torneremo in seguito (vedi
sez.~\ref{sec:TCP_shutdown}).
implementa il servizio \textit{daytime} su TCP, secondo quanto specificato
dall'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}. Prima di passare
agli esempi del client e del server, inizieremo riesaminando con maggiori
-dettagli una peculiarità delle funzioni di I/O, già accennata in
-sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è
+dettagli una peculiarità delle funzioni di I/O, già accennata in
+sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è
particolarmente rilevante. Passeremo poi ad illustrare gli esempi
-dell'implementazione, sia dal lato client, che dal lato server, che si è
+dell'implementazione, sia dal lato client, che dal lato server, che si è
realizzato sia in forma iterativa che concorrente.
\subsection{Il comportamento delle funzioni di I/O}
\label{sec:sock_io_behav}
-Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
+Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
le funzioni di input/output non sempre hanno lo stesso comportamento che
avrebbero con i normali file di dati (in particolare questo accade per i
socket di tipo stream).
-Infatti con i socket è comune che funzioni come \func{read} o \func{write}
+Infatti con i socket è comune che funzioni come \func{read} o \func{write}
possano restituire in input o scrivere in output un numero di byte minore di
-quello richiesto. Come già accennato in sez.~\ref{sec:file_read} questo è un
+quello richiesto. Come già accennato in sez.~\ref{sec:file_read} questo è un
comportamento normale per le funzioni di I/O, ma con i normali file di dati il
problema si avverte solo in lettura, quando si incontra la fine del file. In
-generale non è così, e con i socket questo è particolarmente evidente.
+generale non è così, e con i socket questo è particolarmente evidente.
\begin{figure}[htb]
\end{figure}
Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
-fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
+fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
-sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
+sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
sez.~\ref{sec:ipc_pipes}).
definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
ritornare solo dopo avere letto o scritto esattamente il numero di byte
-specificato; il sorgente è riportato rispettivamente in
-fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
+specificato; il sorgente è riportato rispettivamente in
+fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
\file{FullWrite.c}.
\label{fig:sock_FullWrite_code}
\end{figure}
-Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
+Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
fino all'esaurimento del numero di byte richiesti, in caso di errore viene
-controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
+controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
-Nel caso della lettura, se il numero di byte letti è zero, significa che si è
+Nel caso della lettura, se il numero di byte letti è zero, significa che si è
arrivati alla fine del file (per i socket questo significa in genere che
-l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
+l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
pertanto si ritorna senza aver concluso la lettura di tutti i byte
richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
valore negativo in caso di errore, \func{FullRead} restituisce il numero di
\label{sec:TCP_daytime_client}
Il primo esempio di applicazione delle funzioni di base illustrate in
-sez.~\ref{sec:TCP_functions} è relativo alla creazione di un client elementare
+sez.~\ref{sec:TCP_functions} è relativo alla creazione di un client elementare
per il servizio \textit{daytime}, un servizio elementare, definito
nell'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}, che restituisce
-l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
+l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
alla porta 13.
-In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
+In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
del codice del nostro client. Il sorgente completo del programma
(\texttt{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
-funzione per stampare un messaggio di aiuto) è allegato alla guida nella
-sezione dei codici sorgente e può essere compilato su una qualunque macchina
+funzione per stampare un messaggio di aiuto) è allegato alla guida nella
+sezione dei codici sorgente e può essere compilato su una qualunque macchina
GNU/Linux.
\begin{figure}[!htb]
\end{figure}
Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
-dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
+dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
tutta la parte relativa al trattamento degli argomenti passati dalla linea di
comando (effettuata con le apposite funzioni illustrate in
sez.~\ref{sec:proc_opt_handling}).
-Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
+Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
\const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
\func{socket} ritorna il descrittore che viene usato per identificare il
socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
(\texttt{\small 17}) con un codice di errore.
-Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
-struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
-il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
+Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
+struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
+il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
inizializzare tutto a zero, per poi inserire il tipo di indirizzo
(\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
la funzione \func{htons} per convertire il formato dell'intero usato dal
-computer a quello usato nella rete, infine \texttt{\small 23--27} si può
+computer a quello usato nella rete, infine \texttt{\small 23--27} si può
utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
passato dalla linea di comando.
A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
-socket creato in precedenza (\texttt{\small 29}) si può stabilire la
+socket creato in precedenza (\texttt{\small 29}) si può stabilire la
connessione con il server. Per questo si deve utilizzare come secondo
argomento la struttura preparata in precedenza con il relativo indirizzo; si
noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
ritorna (\texttt{\small 31}).
Completata con successo la connessione il passo successivo (\texttt{\small
- 34--40}) è leggere la data dal socket; il protocollo prevede che il server
-invii sempre una stringa alfanumerica, il formato della stringa non è
+ 34--40}) è leggere la data dal socket; il protocollo prevede che il server
+invii sempre una stringa alfanumerica, il formato della stringa non è
specificato dallo standard, per cui noi useremo il formato usato dalla
-funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
+funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
qualcosa del tipo:
\begin{verbatim}
Wed Apr 4 00:53:00 2001\r\n
35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
36}) sullo standard output con l'uso di \func{fputs}.
-Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
-potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
+Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
+potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte. Per
-questo nel caso generale non si può mai assumere che tutti i dati arrivino con
+questo nel caso generale non si può mai assumere che tutti i dati arrivino con
una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
minore di zero (che significa un errore nella connessione).
Si noti come in questo caso la fine dei dati sia specificata dal server che
-chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
-è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
+chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
+è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
-punto essenziale è che TCP non provvede nessuna indicazione che permetta di
-marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
+punto essenziale è che TCP non provvede nessuna indicazione che permetta di
+marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
programma stesso.
Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
Dopo aver illustrato il client daremo anche un esempio di un server
elementare, che sia anche in grado di rispondere al precedente client. Come
primo esempio realizzeremo un server iterativo, in grado di fornire una sola
-risposta alla volta. Il codice del programma è nuovamente mostrato in
+risposta alla volta. Il codice del programma è nuovamente mostrato in
fig.~\ref{fig:TCP_daytime_iter_server_code}, il sorgente completo
-(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
+(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
esempi.
\begin{figure}[!htbp]
\end{figure}
Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
-cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
+cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
14--18}) alcune costanti e le variabili necessarie in seguito. Come nel caso
precedente si sono omesse le parti relative al trattamento delle opzioni da
riga di comando.
-La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
+La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
\struct{sockaddr\_in}. Anche in questo caso (\texttt{\small 28}) si usa la
porta standard del servizio daytime, ma come indirizzo IP si usa
31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
programma.
-Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{in
+Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{in
ascolto}'' il socket; questo viene fatto (\texttt{\small 36}) con la
funzione \func{listen} che dice al kernel di accettare connessioni per il
socket che abbiamo creato; la funzione indica inoltre, con il secondo
-argomento, il numero massimo di connessioni che il kernel accetterà di mettere
+argomento, il numero massimo di connessioni che il kernel accetterà di mettere
in coda per il suddetto socket. Di nuovo in caso di errore si stampa
(\texttt{\small 37}) un messaggio, e si esce (\texttt{\small 38})
immediatamente.
La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
-(che viene chiamato anche \textit{listening descriptor}) a questo punto si può
+(che viene chiamato anche \textit{listening descriptor}) a questo punto si può
procedere con il ciclo principale (\texttt{\small 40--53}) che viene eseguito
-indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
+indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
(\texttt{\small 44}).
-Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
+Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
accettata una connessione da un client; quando questo avviene \func{accept}
ritorna, restituendo un secondo descrittore, che viene chiamato
-\textit{connected descriptor}, e che è quello che verrà usato dalla successiva
+\textit{connected descriptor}, e che è quello che verrà usato dalla successiva
chiamata alla \func{write} per scrivere la risposta al client.
-Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
-con una chiamata a \texttt{time}, con il quale si potrà opportunamente
+Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
+con una chiamata a \texttt{time}, con il quale si potrà opportunamente
costruire (\texttt{\small 47}) la stringa con la data da trasmettere
(\texttt{\small 48}) con la chiamata a \func{write}. Completata la
trasmissione il nuovo socket viene chiuso (\texttt{\small 52}). A questo
punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
l'invio della data in risposta ad una successiva connessione.
-È importante notare che questo server è estremamente elementare, infatti, a
-parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
-di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
-\textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
+È importante notare che questo server è estremamente elementare, infatti, a
+parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
+di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
+\textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
ciclo principale.} per tener conto di quanto illustrato in
-sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
+sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
di gestione della terminazione del processo, dato che tutti i file descriptor
vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
-non è necessario preoccuparsi di gestire la loro terminazione.
+non è necessario preoccuparsi di gestire la loro terminazione.
\subsection{Un server \textit{daytime} concorrente}
\label{sec:TCP_daytime_cunc_server}
Il server \texttt{daytime} dell'esempio in
-sez.~\ref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
-in cui viene servita una richiesta alla volta; in generale però, specie se il
-servizio è più complesso e comporta uno scambio di dati più sostanzioso di
-quello in questione, non è opportuno bloccare un server nel servizio di un
-client per volta; per questo si ricorre alle capacità di multitasking del
+sez.~\ref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
+in cui viene servita una richiesta alla volta; in generale però, specie se il
+servizio è più complesso e comporta uno scambio di dati più sostanzioso di
+quello in questione, non è opportuno bloccare un server nel servizio di un
+client per volta; per questo si ricorre alle capacità di multitasking del
sistema.
-Come accennato anche in sez.~\ref{sec:proc_gen} una delle modalità più comuni
-di funzionamento da parte dei server è quella di usare la funzione \func{fork}
+Come accennato anche in sez.~\ref{sec:proc_gen} una delle modalità più comuni
+di funzionamento da parte dei server è quella di usare la funzione \func{fork}
per creare, ad ogni richiesta da parte di un client, un processo figlio che si
-incarichi della gestione della comunicazione. Si è allora riscritto il server
+incarichi della gestione della comunicazione. Si è allora riscritto il server
\textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
una opzione per la stampa degli indirizzi delle connessioni ricevute.
-In fig.~\ref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
+In fig.~\ref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
-rimaste invariate rispetto al precedente esempio (cioè tutta la parte
+rimaste invariate rispetto al precedente esempio (cioè tutta la parte
riguardante l'apertura passiva del socket). Al solito il sorgente completo del
-server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
+server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
sorgenti degli altri esempi.
\begin{figure}[!htb]
\label{fig:TCP_daytime_cunc_server_code}
\end{figure}
-Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
+Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
la porta da cui il client effettua la connessione, che in un secondo tempo,
-(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
+(\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
output.
Quando \func{accept} ritorna il server chiama la funzione \func{fork}
-(\texttt{\small 27--31}) per creare il processo figlio che effettuerà
+(\texttt{\small 27--31}) per creare il processo figlio che effettuerà
(\texttt{\small 32--46}) tutte le operazioni relative a quella connessione,
-mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
+mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
ulteriori connessioni.
Si noti come il figlio operi solo sul socket connesso, chiudendo
continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 48})
\var{conn\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
sez.~\ref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
-l'innesco della sequenza di chiusura perché il numero di riferimenti al file
-descriptor non si è annullato.
+l'innesco della sequenza di chiusura perché il numero di riferimenti al file
+descriptor non si è annullato.
Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
\func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
entrambi i socket si trovano con due referenze. Questo fa si che quando il
padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
-e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
-le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
+e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
+le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
-In realtà per il figlio non sarebbe necessaria nessuna chiamata a
+In realtà per il figlio non sarebbe necessaria nessuna chiamata a
\func{close}, in quanto con la \func{exit} finale (\texttt{\small 45}) tutti i
file descriptor, quindi anche quelli associati ai socket, vengono
-automaticamente chiusi. Tuttavia si è preferito effettuare esplicitamente le
+automaticamente chiusi. Tuttavia si è preferito effettuare esplicitamente le
chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali
errori, prevenendo ad esempio un uso involontario del \textit{listening
descriptor}.
Si noti invece come sia essenziale che il padre chiuda ogni volta il socket
-connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
+connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio
-resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
+resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato
per ogni processo) e soprattutto nessuna delle connessioni con i client
verrebbe chiusa.
(\texttt{\small 35}) sulla stringa contenuta in \var{buffer} con l'uso di
\func{snprintf} e \func{ctime}. Poi la stringa viene scritta (\texttt{\small
36--39}) sul socket, controllando che non ci siano errori. Anche in questo
-caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
-estremamente breve e verrà senz'altro scritta in un singolo segmento.
+caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
+estremamente breve e verrà senz'altro scritta in un singolo segmento.
Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
provvede anche (\texttt{\small 40--43}) a stampare sullo standard output
valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
opportune conversioni con \func{inet\_ntop} e \func{ntohs}.
-Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
-non si sia gestita né la terminazione del processo né il suo uso come demone,
+Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
+non si sia gestita né la terminazione del processo né il suo uso come demone,
che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging
che stampa gli indirizzi delle connessioni sullo standard output. Un altro
-aspetto tralasciato è la gestione della terminazione dei processi figli,
-torneremo su questo più avanti quando tratteremo alcuni esempi di server più
+aspetto tralasciato è la gestione della terminazione dei processi figli,
+torneremo su questo più avanti quando tratteremo alcuni esempi di server più
complessi.
-\section{Un esempio più completo: il servizio \textit{echo}}
+\section{Un esempio più completo: il servizio \textit{echo}}
\label{sec:TCP_echo_application}
-L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
+L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
elementare, in cui il flusso dei dati va solo nella direzione dal server al
client. In questa sezione esamineremo un esempio di applicazione client/server
-un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
+un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
le direzioni.
Ci limiteremo a fornire una implementazione elementare, che usi solo le
in condizioni normali, anche tutti i possibili scenari particolari (errori,
sconnessione della rete, crash del client o del server durante la connessione)
che possono avere luogo durante l'impiego di un'applicazione di rete, partendo
-da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
+da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
poter tenere conto di tutte le evenienze che si possono manifestare nella vita
reale di un'applicazione di rete, fino ad arrivare ad un'implementazione
completa.
Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
-bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
+bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
-immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
+immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
servizio costituisce il prototipo ideale per una generica applicazione di rete
in cui un server risponde alle richieste di un client. Nel caso di una
-applicazione più complessa quello che si potrà avere in più è una elaborazione
+applicazione più complessa quello che si potrà avere in più è una elaborazione
dell'input del client, che in molti casi viene interpretato come un comando,
da parte di un server che risponde fornendo altri dati in uscita.
-Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
-direttamente dal superserver \cmd{inetd}, ed è definito
+Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
+direttamente dal superserver \cmd{inetd}, ed è definito
dall'\href{http://www.ietf.org/rfc/rfc862.txt}{RFC~862}. Come dice il nome il
servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
il primo stabilisce che una volta stabilita la connessione ogni dato in
ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
-chiude la connessione. Al servizio è assegnata la porta riservata 7.
+chiude la connessione. Al servizio è assegnata la porta riservata 7.
-Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
+Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
caratteri dallo standard input e la scrive sul server. A sua volta il server
-leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
+leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
compito del client leggere la risposta del server e stamparla sullo standard
output.
\label{sec:TCP_echo_client}
Il codice della prima versione del client per il servizio \textit{echo},
-disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
+disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
client per il servizio \textit{daytime} (vedi
sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
-è sostanzialmente identica, a parte l'uso di una porta diversa.
+è sostanzialmente identica, a parte l'uso di una porta diversa.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:TCP_echo_client_1}
\end{figure}
-Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
+Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
riga di comando. Una volta dichiarate le variabili, si prosegue
(\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
\textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
-specificato a riga di comando. A questo punto (\texttt{\small 23--27}) si può
-eseguire la connessione al server secondo la stessa modalità usata in
+specificato a riga di comando. A questo punto (\texttt{\small 23--27}) si può
+eseguire la connessione al server secondo la stessa modalità usata in
sez.~\ref{sec:TCP_daytime_client}.
Completata la connessione, per gestire il funzionamento del protocollo si usa
-la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
+la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
fig.~\ref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
sez.~\ref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo
automaticamente l'invio multiplo qualora una singola \func{write} non sia
sufficiente. I dati vengono riletti indietro (\texttt{\small 7}) con una
-\func{read}\footnote{si è fatta l'assunzione implicita che i dati siano
- contenuti tutti in un solo segmento, così che la chiamata a \func{read} li
+\func{read}\footnote{si è fatta l'assunzione implicita che i dati siano
+ contenuti tutti in un solo segmento, così che la chiamata a \func{read} li
restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer
- questo sarà sempre vero, vedremo più avanti come superare il problema di
+ questo sarà sempre vero, vedremo più avanti come superare il problema di
rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} sul
buffer di ricezione e viene inserita (\texttt{\small 8}) la terminazione della
stringa e per poter usare (\texttt{\small 9}) la funzione \func{fputs} per
\label{fig:TCP_client_echo_sub}
\end{figure}
-Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
-input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
+Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
+input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
quanto spiegato in sez.~\ref{sec:file_line_io}) e la conseguente uscita dal
ciclo; al che la subroutine ritorna ed il nostro programma client termina.
-Si può effettuare una verifica del funzionamento del client abilitando il
+Si può effettuare una verifica del funzionamento del client abilitando il
servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
macchina ed usandolo direttamente verso di esso in locale, vedremo in
-dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
-programma, usato però con la nostra versione del server \textit{echo}, che
+dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
+programma, usato però con la nostra versione del server \textit{echo}, che
illustriamo immediatamente.
\label{sec:TCPsimp_server_main}
La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
-è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
-per il client anche il server è stato diviso in un corpo principale,
-costituito dalla funzione \code{main}, che è molto simile a quello visto nel
+è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
+per il client anche il server è stato diviso in un corpo principale,
+costituito dalla funzione \code{main}, che è molto simile a quello visto nel
precedente esempio per il server del servizio \textit{daytime} di
sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
\code{ServEcho} che si cura della gestione del servizio.
\label{fig:TCP_echo_server_first_code}
\end{figure}
-In questo caso però, rispetto a quanto visto nell'esempio di
-fig.~\ref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
+In questo caso però, rispetto a quanto visto nell'esempio di
+fig.~\ref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
curando maggiormente alcuni dettagli, per tenere conto anche di alcune
esigenze generali (che non riguardano direttamente la rete), come la
-possibilità di lanciare il server anche in modalità interattiva e la cessione
-dei privilegi di amministratore non appena questi non sono più necessari.
+possibilità di lanciare il server anche in modalità interattiva e la cessione
+dei privilegi di amministratore non appena questi non sono più necessari.
-La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
+La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
server di sez.~\ref{sec:TCP_daytime_cunc_server}, ed ivi descritta in
dettaglio: crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato
-che quest'ultima funzione viene usata su una porta riservata, il server dovrà
+che quest'ultima funzione viene usata su una porta riservata, il server dovrà
essere eseguito da un processo con i privilegi di amministratore, pena il
fallimento della chiamata.
-Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
-non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
-evitare problemi in caso di eventuali vulnerabilità del server. Per questo
+Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
+non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
+evitare problemi in caso di eventuali vulnerabilità del server. Per questo
prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il
-processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
+processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
ovvero -1 per il formato \ctyp{short}, che di norma in tutte le
distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e
l'utente \texttt{nobody}, usati appunto per eseguire programmi che non
richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small
27--30}) l'operazione usando \func{setuid} per cambiare anche
l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
- due operazioni è importante, infatti solo avendo i privilegi di
- amministratore si può cambiare il gruppo di un processo ad un altro di cui
+ due operazioni è importante, infatti solo avendo i privilegi di
+ amministratore si può cambiare il gruppo di un processo ad un altro di cui
non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
successiva chiamata a \func{setgid}. Inoltre si ricordi (si riveda quanto
esposto in sez.~\ref{sec:proc_perms}) che usando queste due funzioni il
- rilascio dei privilegi è irreversibile.} Infine (\texttt{\small 30--36}),
+ rilascio dei privilegi è irreversibile.} Infine (\texttt{\small 30--36}),
qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31})
si apre il sistema di logging per la stampa degli errori, e poi
(\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
processo come demone.
-A questo punto il programma riprende di nuovo lo schema già visto usato dal
+A questo punto il programma riprende di nuovo lo schema già visto usato dal
server per il servizio \textit{daytime}, con l'unica differenza della chiamata
alla funzione \code{PrintErr}, riportata in fig.~\ref{fig:TCP_PrintErr}, al
posto di \func{perror} per la stampa degli errori.
Il padre invece si limita (\texttt{\small 57}) a chiudere il \textit{connected
socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
-questo modo si ha un server concorrente. La terminazione del padre non è
+questo modo si ha un server concorrente. La terminazione del padre non è
gestita esplicitamente, e deve essere effettuata inviando un segnale al
processo.
-Avendo trattato direttamente la gestione del programma come demone, si è
-dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
+Avendo trattato direttamente la gestione del programma come demone, si è
+dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
errore attraverso il sistema del \textit{syslog} trattato in
-sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
-come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
+sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
+come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
in fig.~\ref{fig:TCP_PrintErr}.
-In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
+In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
-messaggio di errore fornito come argomento sui log di sistema. Se invece si è
-in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
+messaggio di errore fornito come argomento sui log di sistema. Se invece si è
+in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
(\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
standard error.
\end{figure}
La gestione del servizio \textit{echo} viene effettuata interamente nella
-funzione \code{ServEcho}, il cui codice è mostrato in
+funzione \code{ServEcho}, il cui codice è mostrato in
fig.~\ref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
di un ciclo (\texttt{\small 6--13}). I dati inviati dal client vengono letti
(\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
funzione \func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_code}) che
-si incarica di tenere conto automaticamente della possibilità che non tutti i
-dati di cui è richiesta la scrittura vengano trasmessi con una singola
+si incarica di tenere conto automaticamente della possibilità che non tutti i
+dati di cui è richiesta la scrittura vengano trasmessi con una singola
\func{write}.
\begin{figure}[!htb]
\subsection{L'avvio e il funzionamento normale}
\label{sec:TCP_echo_startup}
-Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
+Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
di considerare in dettaglio le varie problematiche che si possono incontrare
nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
-modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
+modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
che avviene nelle varie situazioni limite, da una parte potremo approfondire
la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
necessarie per essere in grado di scrivere applicazioni robuste, in grado di
gestire anche i casi limite.
-Il primo passo è compilare e lanciare il server (da root, per poter usare la
-porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
+Il primo passo è compilare e lanciare il server (da root, per poter usare la
+porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
-si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
+si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
stato con \cmd{netstat}:
\begin{verbatim}
[piccardi@roke piccardi]$ netstat -at
connessioni da qualunque indirizzo e da qualunque porta e su qualunque
interfaccia locale.
-A questo punto si può lanciare il client, esso chiamerà \func{socket} e
+A questo punto si può lanciare il client, esso chiamerà \func{socket} e
\func{connect}; una volta completato il \itindex{three~way~handshake}
-\textit{three way handshake} la connessione è stabilita; la \func{connect}
-ritornerà nel client\footnote{si noti che è sempre la \func{connect} del
+\textit{three way handshake} la connessione è stabilita; la \func{connect}
+ritornerà nel client\footnote{si noti che è sempre la \func{connect} del
client a ritornare per prima, in quanto questo avviene alla ricezione del
secondo segmento (l'ACK del server) del \itindex{three~way~handshake}
\textit{three way handshake}, la \func{accept} del server ritorna solo dopo
mentre per quanto riguarda l'esecuzione dei programmi avremo che:
\begin{itemize}
\item il client chiama la funzione \code{ClientEcho} che si blocca sulla
- \func{fgets} dato che non si è ancora scritto nulla sul terminale.
-\item il server eseguirà una \func{fork} facendo chiamare al processo figlio
- la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
+ \func{fgets} dato che non si è ancora scritto nulla sul terminale.
+\item il server eseguirà una \func{fork} facendo chiamare al processo figlio
+ la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
dal socket sul quale ancora non sono presenti dati.
-\item il processo padre del server chiamerà di nuovo \func{accept}
+\item il processo padre del server chiamerà di nuovo \func{accept}
bloccandosi fino all'arrivo di un'altra connessione.
\end{itemize}
e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
tre processi, tutti in stato di \textit{sleep} (vedi
tab.~\ref{tab:proc_proc_states}).
-Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
+Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
-\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
+\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
-a sua volta sarà inviato sullo standard output, che nel caso ne provoca
+a sua volta sarà inviato sullo standard output, che nel caso ne provoca
l'immediata stampa a video.
\subsection{La conclusione normale}
\label{sec:TCP_echo_conclusion}
-Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
+Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
ristampato a video fintanto che non concluderemo l'immissione dei dati; una
-sessione tipica sarà allora del tipo:
+sessione tipica sarà allora del tipo:
\begin{verbatim}
[piccardi@roke sources]$ ./echo 127.0.0.1
Questa e` una prova
con il client che entra in \texttt{TIME\_WAIT}.
Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
-terminazione normale della connessione, che ci servirà poi da riferimento
+terminazione normale della connessione, che ci servirà poi da riferimento
quando affronteremo il comportamento in caso di conclusioni anomale:
\begin{enumerate}
\item inviando un carattere di EOF da terminale la \func{fgets} ritorna
restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
- così la funzione \code{ClientEcho} ritorna.
+ così la funzione \code{ClientEcho} ritorna.
\item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
come parte del processo terminazione tutti i file descriptor vengono chiusi
(si ricordi quanto detto in sez.~\ref{sec:proc_term_conclusion}); questo
- causa la chiusura del socket di comunicazione; il client allora invierà un
- FIN al server a cui questo risponderà con un ACK. A questo punto il client
- verrà a trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
+ causa la chiusura del socket di comunicazione; il client allora invierà un
+ FIN al server a cui questo risponderà con un ACK. A questo punto il client
+ verrà a trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
\texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
sez.~\ref{sec:TCP_conn_term}).
\item quando il server riceve il FIN la \func{read} del processo figlio che
- gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
+ gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
ciclo e il ritorno di \code{ServEcho}, a questo punto il processo figlio
termina chiamando \func{exit}.
\item all'uscita del figlio tutti i file descriptor vengono chiusi, la
- chiusura del socket connesso fa sì che venga effettuata la sequenza finale
- di chiusura della connessione, viene emesso un FIN dal server che riceverà
- un ACK dal client, a questo punto la connessione è conclusa e il client
+ chiusura del socket connesso fa sì che venga effettuata la sequenza finale
+ di chiusura della connessione, viene emesso un FIN dal server che riceverà
+ un ACK dal client, a questo punto la connessione è conclusa e il client
resta nello stato \texttt{TIME\_WAIT}.
\end{enumerate}
\subsection{La gestione dei processi figli}
\label{sec:TCP_child_hand}
-Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
+Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
del procedimento di chiusura del processo figlio nel server (si veda quanto
esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
-del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
-gestore e che l'azione predefinita per questo segnale è quella di essere
+del segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
+gestore e che l'azione predefinita per questo segnale è quella di essere
ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
-(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
+otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
+(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
ripetendo il comando \cmd{ps}:
\begin{verbatim}
2356 pts/0 S 0:00 ./echod
2359 pts/0 Z 0:00 [echod <defunct>]
\end{verbatim}
-Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
+Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
ricevere opportunamente lo stato di terminazione del processo (si veda
sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al nostro
-server è pertanto quella di inserire la gestione della terminazione dei
+server è pertanto quella di inserire la gestione della terminazione dei
processi figli attraverso l'uso di un gestore. Per questo useremo la funzione
\code{Signal} (che abbiamo illustrato in fig.~\ref{fig:sig_Signal_code}), per
-installare il gestore che riceve i segnali dei processi figli terminati già
-visto in fig.~\ref{fig:sig_sigchld_handl}. Basterà allora aggiungere il
+installare il gestore che riceve i segnali dei processi figli terminati già
+visto in fig.~\ref{fig:sig_sigchld_handl}. Basterà allora aggiungere il
seguente codice: \includecodesnip{listati/sigchildhand.c}
\noindent
all'esempio illustrato in fig.~\ref{fig:TCP_echo_server_first_code}.
-In questo modo però si introduce un altro problema. Si ricordi infatti che,
+In questo modo però si introduce un altro problema. Si ricordi infatti che,
come spiegato in sez.~\ref{sec:sig_gen_beha}, quando un programma si trova in
stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene
interrotta alla ricezione di un segnale. Per questo motivo, alla fine
dell'esecuzione del gestore del segnale, se questo ritorna, il programma
-riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
+riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
di \errcode{EINTR}.
Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
-client, il processo figlio che gestisce la connessione terminerà, ed il padre,
-per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
-eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
-padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
+client, il processo figlio che gestisce la connessione terminerà, ed il padre,
+per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
+eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
+padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
un caso fortuito in cui il segnale arriva durante l'esecuzione del programma
in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo
-previsto questa eventualità il programma considera questo un errore fatale
+previsto questa eventualità il programma considera questo un errore fatale
terminando a sua volta con un messaggio del tipo:
\begin{verbatim}
[root@gont sources]# ./echod -i
Come accennato in sez.~\ref{sec:sig_gen_beha} le conseguenze di questo
comportamento delle system call possono essere superate in due modi diversi,
-il più semplice è quello di modificare il codice di \func{Signal} per
+il più semplice è quello di modificare il codice di \func{Signal} per
richiedere il riavvio automatico delle system call interrotte secondo la
semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora la
-nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
+nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
alle altre funzioni riguardanti la gestione dei segnali, nel file
- \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
+ \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
allegati.} come mostrato in fig.~\ref{fig:sig_SignalRestart_code}, ed
installeremo il gestore usando quest'ultima.
\label{fig:sig_SignalRestart_code}
\end{figure}
-Come si può notare questa funzione è identica alla precedente \func{Signal},
+Come si può notare questa funzione è identica alla precedente \func{Signal},
illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece di
inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
-funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
+funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
modifica: le system call interrotte saranno automaticamente riavviate, e
-l'errore \errcode{EINTR} non si manifesterà più.
+l'errore \errcode{EINTR} non si manifesterà più.
-La seconda soluzione è più invasiva e richiede di controllare tutte le volte
+La seconda soluzione è più invasiva e richiede di controllare tutte le volte
l'errore restituito dalle varie system call, ripetendo la chiamata qualora
-questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
-della portabilità, infatti lo standard POSIX dice che la funzionalità di
-riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
-opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
+questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
+della portabilità, infatti lo standard POSIX dice che la funzionalità di
+riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
+opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri
non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
- caso di Linux viene sempre fatta.} anche quando questa è presente, non è
+ caso di Linux viene sempre fatta.} anche quando questa è presente, non è
detto possa essere usata con \func{accept}.
-La portabilità nella gestione dei segnali però viene al costo di una
+La portabilità nella gestione dei segnali però viene al costo di una
riscrittura parziale del server, la nuova versione di questo, in cui si sono
-introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
+introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
mostrata in fig.~\ref{fig:TCP_echo_server_code_second}, dove si sono riportate
la sezioni di codice modificate nella seconda versione del programma, il
codice completo di quest'ultimo si trova nel file
\texttt{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
-La prima modifica effettuata è stata quella di introdurre una nuova opzione a
+La prima modifica effettuata è stata quella di introdurre una nuova opzione a
riga di comando, \texttt{-c}, che permette di richiedere il comportamento
compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
-impostando la variabile \var{compat} ad un valore non nullo. Questa è
-preimpostata al valore nullo, cosicché se non si usa questa opzione il
-comportamento di default del server è di usare la semantica BSD.
+impostando la variabile \var{compat} ad un valore non nullo. Questa è
+preimpostata al valore nullo, cosicché se non si usa questa opzione il
+comportamento di default del server è di usare la semantica BSD.
-Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
+Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
specificato in secondi fra il ritorno della funzione \func{listen} e la
chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
-permette di impostare la variabile \var{waiting}. Infine si è introdotta una
+permette di impostare la variabile \var{waiting}. Infine si è introdotta una
opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
-nullo la variabile \var{debugging}. Al solito si è omessa da
+nullo la variabile \var{debugging}. Al solito si è omessa da
fig.~\ref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
-gestione di tutte queste opzioni, che può essere trovata nel sorgente del
+gestione di tutte queste opzioni, che può essere trovata nel sorgente del
programma.
\begin{figure}[!htb]
\label{fig:TCP_echo_server_code_second}
\end{figure}
-Vediamo allora come è cambiato il nostro server; una volta definite le
-variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
+Vediamo allora come è cambiato il nostro server; una volta definite le
+variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
(\texttt{\small 12}), essendo quest'ultimo il valore di default.
Tutta la sezione seguente, che crea il socket, cede i privilegi di
-amministratore ed eventualmente lancia il programma come demone, è rimasta
-invariata e pertanto è stata omessa in
+amministratore ed eventualmente lancia il programma come demone, è rimasta
+invariata e pertanto è stata omessa in
fig.~\ref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima
-dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
+dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una
eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
\var{waiting}, che viene inizializzata, con l'opzione \texttt{-w Nsec}, al
-numero di secondi da aspettare (il valore preimpostato è nullo).
+numero di secondi da aspettare (il valore preimpostato è nullo).
-Si è potuto lasciare inalterata tutta la sezione di creazione del socket
-perché nel server l'unica chiamata ad una system call lenta, che può essere
-interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
-l'unica funzione che può mettere il processo padre in stato di sleep nel
-periodo in cui un figlio può terminare; si noti infatti come le altre
+Si è potuto lasciare inalterata tutta la sezione di creazione del socket
+perché nel server l'unica chiamata ad una system call lenta, che può essere
+interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
+l'unica funzione che può mettere il processo padre in stato di sleep nel
+periodo in cui un figlio può terminare; si noti infatti come le altre
\index{system~call~lente} \textit{slow system call}\footnote{si ricordi la
distinzione fatta in sez.~\ref{sec:sig_gen_beha}.} o sono chiamate prima di
entrare nel ciclo principale, quando ancora non esistono processi figli, o
Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
23--42}), rispetto precedente versione di fig.~\ref{fig:TCP_ServEcho_first},
-è nella sezione (\texttt{\small 25--31}) in cui si effettua la chiamata di
+è nella sezione (\texttt{\small 25--31}) in cui si effettua la chiamata di
\func{accept}. Quest'ultima viene effettuata (\texttt{\small 26--27})
all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
- questo ciclo può non essere del tutto chiara. In questo caso infatti si è
+ questo ciclo può non essere del tutto chiara. In questo caso infatti si è
usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
- quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
+ quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
condizione all'interno del \code{while}.} che la ripete indefinitamente
qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
altrimenti il programma prosegue.
-Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
+Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
(\texttt{\small 32--40}) di aiuto per il debug del programma, che eseguita con
un controllo (\texttt{\small 33}) sul valore della variabile \var{debugging}
impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
(\texttt{\small 34--39}) viene opportunamente stampata o sullo schermo o nei
log.
-Infine come ulteriore miglioria si è perfezionata la funzione \code{ServEcho},
-sia per tenere conto della nuova funzionalità di debugging, che per effettuare
-un controllo in caso di errore; il codice della nuova versione è mostrato in
+Infine come ulteriore miglioria si è perfezionata la funzione \code{ServEcho},
+sia per tenere conto della nuova funzionalità di debugging, che per effettuare
+un controllo in caso di errore; il codice della nuova versione è mostrato in
fig.~\ref{fig:TCP_ServEcho_second}.
\begin{figure}[!htb]
\end{figure}
Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
-questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
+questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
ritorno di \func{read} per rilevare un eventuale errore, in modo da stampare
(\texttt{\small 8}) un messaggio di errore e ritornare (\texttt{\small 9})
concludendo la connessione.
-Inoltre qualora sia stata attivata la funzionalità di debug (avvalorando
-\var{debugging} tramite l'apposita opzione \texttt{-d}) si provvederà a
-stampare (tenendo conto della modalità di invocazione del server, se
+Inoltre qualora sia stata attivata la funzionalità di debug (avvalorando
+\var{debugging} tramite l'apposita opzione \texttt{-d}) si provvederà a
+stampare (tenendo conto della modalità di invocazione del server, se
interattiva o in forma di demone) il numero di byte e la stringa letta dal
client (\texttt{\small 16--24}).
diventa in grado di affrontare la gestione ordinaria delle connessioni, ma un
server di rete deve tenere conto che, al contrario di quanto avviene per i
server che operano nei confronti di processi presenti sulla stessa macchina,
-la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
+la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
gestire tutta una serie di situazioni critiche che non esistono per i processi
locali.
\subsection{La terminazione precoce della connessione}
\label{sec:TCP_conn_early_abort}
-La prima situazione critica è quella della terminazione precoce, causata da un
+La prima situazione critica è quella della terminazione precoce, causata da un
qualche errore sulla rete, della connessione effettuata da un client. Come
accennato in sez.~\ref{sec:TCP_func_accept} la funzione \func{accept} riporta
tutti gli eventuali errori di rete pendenti su una connessione sul
-\textit{connected socket}. Di norma questo non è un problema, in quanto non
-appena completata la connessione, \func{accept} ritorna e l'errore sarà
+\textit{connected socket}. Di norma questo non è un problema, in quanto non
+appena completata la connessione, \func{accept} ritorna e l'errore sarà
rilevato in seguito, dal processo che gestisce la connessione, alla prima
chiamata di una funzione che opera sul socket.
-È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
+È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
del tipo di quello mostrato in fig.~\ref{fig:TCP_early_abort}, in cui la
connessione viene abortita sul lato client per un qualche errore di rete con
l'invio di un segmento RST, prima che nel server sia stata chiamata la
\label{fig:TCP_early_abort}
\end{figure}
-Benché questo non sia un fatto comune, un evento simile può essere osservato
+Benché questo non sia un fatto comune, un evento simile può essere osservato
con dei server molto occupati. In tal caso, con una struttura del server
simile a quella del nostro esempio, in cui la gestione delle singole
-connessioni è demandata a processi figli, può accadere che il \textit{three
+connessioni è demandata a processi figli, può accadere che il \textit{three
way handshake} \itindex{three~way~handshake} venga completato e la relativa
connessione abortita subito dopo, prima che il padre, per via del carico della
macchina, abbia fatto in tempo ad eseguire la chiamata ad \func{accept}. Di
\errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
\errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
-Si tenga presente che questo tipo di terminazione non è riproducibile
+Si tenga presente che questo tipo di terminazione non è riproducibile
terminando il client prima della chiamata ad \func{accept}, come si potrebbe
fare usando l'opzione \texttt{-w} per introdurre una pausa dopo il lancio del
demone, in modo da poter avere il tempo per lanciare e terminare una
connessione usando il programma client. In tal caso infatti, alla terminazione
del client, il socket associato alla connessione viene semplicemente chiuso,
attraverso la sequenza vista in sez.~\ref{sec:TCP_conn_term}, per cui la
-\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
+\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
modifichi il client per fargli gestire l'invio di un segmento di RST alla
chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
\subsection{La terminazione precoce del server}
\label{sec:TCP_server_crash}
-Un secondo caso critico è quello in cui si ha una terminazione precoce del
-server, ad esempio perché il programma ha un crash. In tal caso si suppone che
+Un secondo caso critico è quello in cui si ha una terminazione precoce del
+server, ad esempio perché il programma ha un crash. In tal caso si suppone che
il processo termini per un errore fatale, cosa che potremo simulare
inviandogli un segnale di terminazione. La conclusione del processo comporta
la chiusura di tutti i file descriptor aperti, compresi tutti i socket
relativi a connessioni stabilite; questo significa che al momento del crollo
-del servizio il client riceverà un FIN dal server in corrispondenza della
+del servizio il client riceverà un FIN dal server in corrispondenza della
chiusura del socket.
Vediamo allora cosa succede nel nostro caso, facciamo partire una connessione
con il server e scriviamo una prima riga, poi terminiamo il server con un
\texttt{C-c}. A questo punto scriviamo una seconda riga e poi un'altra riga
-ancora. Il risultato finale della sessione è il seguente:
+ancora. Il risultato finale della sessione è il seguente:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.141
Prima riga
anche un'altra riga prima di terminare senza riportare nessun
errore.
-Per capire meglio cosa è successo conviene analizzare il flusso dei pacchetti
+Per capire meglio cosa è successo conviene analizzare il flusso dei pacchetti
utilizzando un analizzatore di traffico come \cmd{tcpdump}. Il comando
permette di selezionare, nel traffico di rete generato su una macchina, i
pacchetti che interessano, stampando a video (o salvando su disco) il loro
contenuto. Non staremo qui ad entrare nei dettagli dell'uso del programma, che
sono spiegati dalla pagina di manuale; per l'uso che vogliamo farne quello che
-ci interessa è, posizionandosi sulla macchina che fa da client, selezionare
+ci interessa è, posizionandosi sulla macchina che fa da client, selezionare
tutti i pacchetti che sono diretti o provengono dalla macchina che fa da
server. In questo modo (posto che non ci siano altre connessioni col server,
cosa che avremo cura di evitare) tutti i pacchetti rilevati apparterranno alla
Lanciando il comando prima di ripetere la sessione di lavoro mostrata
nell'esempio precedente potremo allora catturare tutti pacchetti scambiati fra
-il client ed il server; i risultati\footnote{in realtà si è ridotta la
+il client ed il server; i risultati\footnote{in realtà si è ridotta la
lunghezza dell'output rispetto al reale tagliando alcuni dati non necessari
alla comprensione del flusso.} prodotti in questa occasione da \cmd{tcpdump}
sono allora i seguenti:
quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene
espresso in forma relativa per maggiore compattezza. Il campo \texttt{win} in
ogni riga indica la \itindex{advertised~window} \textit{advertised window} di
-cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare
+cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare
dall'output del comando come venga appunto realizzata la sequenza di pacchetti
descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un
primo pacchetto con il SYN che inizia la connessione, a cui il server risponde
nulla fin tanto che non scriveremo una prima riga sul client; al momento in
cui facciamo questo si genera una sequenza di altri quattro pacchetti. Il
primo, dal client al server, contraddistinto da una lettera \texttt{P} che
-significa che il flag PSH è impostato, contiene la nostra riga (che è appunto
+significa che il flag PSH è impostato, contiene la nostra riga (che è appunto
di 11 caratteri), e ad esso il server risponde immediatamente con un pacchetto
-vuoto di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
-inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso
-contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto
-pacchetto. Questo causerà la ricezione dell'eco nel client che lo stamperà a
+vuoto di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
+inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso
+contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto
+pacchetto. Questo causerà la ricezione dell'eco nel client che lo stamperà a
video.
A questo punto noi procediamo ad interrompere l'esecuzione del server con un
-\texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui
+\texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui
facciamo questo vengono immediatamente generati altri due pacchetti. La
terminazione del processo infatti comporta la chiusura di tutti i suoi file
descriptor, il che comporta, per il socket che avevamo aperto, l'inizio della
sequenza di chiusura illustrata in sez.~\ref{sec:TCP_conn_term}. Questo
-significa che dal server partirà un FIN, che è appunto il primo dei due
-pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
+significa che dal server partirà un FIN, che è appunto il primo dei due
+pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
ACK da parte del client.
-A questo punto la connessione dalla parte del server è chiusa, ed infatti se
+A questo punto la connessione dalla parte del server è chiusa, ed infatti se
usiamo \cmd{netstat} per controllarne lo stato otterremo che sul server si ha:
\begin{verbatim}
anarres:/home/piccardi# netstat -ant
... ... ... ... ... ...
tcp 0 0 192.168.1.141:7 192.168.1.2:34626 FIN_WAIT2
\end{verbatim}
-cioè essa è andata nello stato \texttt{FIN\_WAIT2}, che indica l'avvenuta
-emissione del segmento FIN, mentre sul client otterremo che essa è andata
+cioè essa è andata nello stato \texttt{FIN\_WAIT2}, che indica l'avvenuta
+emissione del segmento FIN, mentre sul client otterremo che essa è andata
nello stato \texttt{CLOSE\_WAIT}:
\begin{verbatim}
[root@gont gapil]# netstat -ant
tcp 1 0 192.168.1.2:34582 192.168.1.141:7 CLOSE_WAIT
\end{verbatim}
-Il problema è che in questo momento il client è bloccato dentro la funzione
+Il problema è che in questo momento il client è bloccato dentro la funzione
\texttt{ClientEcho} nella chiamata a \func{fgets}, e sta attendendo dell'input
-dal terminale, per cui non è in grado di accorgersi di nulla. Solo quando
-inseriremo la seconda riga il comando uscirà da \func{fgets} e proverà a
+dal terminale, per cui non è in grado di accorgersi di nulla. Solo quando
+inseriremo la seconda riga il comando uscirà da \func{fgets} e proverà a
scriverla sul socket. Questo comporta la generazione degli ultimi due
pacchetti riportati da \cmd{tcpdump}: il primo, inviato dal client contenente
i 25 caratteri della riga appena letta, e ad esso la macchina server
-risponderà, non essendoci più niente in ascolto sulla porta 7, con un segmento
+risponderà, non essendoci più niente in ascolto sulla porta 7, con un segmento
di RST, contraddistinto dalla lettera \texttt{R}, che causa la conclusione
-definitiva della connessione anche nel client, dove non comparirà più
+definitiva della connessione anche nel client, dove non comparirà più
nell'output di \cmd{netstat}.
-Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
+Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket
-è una operazione lecita, per cui la nostra scrittura avrà comunque successo
-(come si può constatare lanciando usando \cmd{strace}\footnote{il comando
- \cmd{strace} è un comando di debug molto utile che prende come argomento un
+è una operazione lecita, per cui la nostra scrittura avrà comunque successo
+(come si può constatare lanciando usando \cmd{strace}\footnote{il comando
+ \cmd{strace} è un comando di debug molto utile che prende come argomento un
altro comando e ne stampa a video tutte le invocazioni di una system call,
coi relativi argomenti e valori di ritorno, per cui usandolo in questo
contesto potremo verificare che effettivamente la \func{write} ha scritto la
- riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
+ riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
programma non ha a questo punto alcun modo di sapere che dall'altra parte non
-c'è più nessuno processo in grado di leggere quanto scriverà. Questo sarà
+c'è più nessuno processo in grado di leggere quanto scriverà. Questo sarà
chiaro solo dopo il tentativo di scrittura, e la ricezione del segmento RST di
-risposta che indica che dall'altra parte non si è semplicemente chiuso un capo
-del socket, ma è completamente terminato il programma.
+risposta che indica che dall'altra parte non si è semplicemente chiuso un capo
+del socket, ma è completamente terminato il programma.
-Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
-questo è stato chiuso avremo che, come spiegato in
+Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
+questo è stato chiuso avremo che, come spiegato in
sez.~\ref{sec:TCP_conn_term}, la funzione \func{read} ritorna normalmente con
un valore nullo. Questo comporta che la seguente chiamata a \func{fputs} non
ha effetto (viene stampata una stringa nulla) ed il client si blocca di nuovo
nella successiva chiamata a \func{fgets}. Per questo diventa possibile
-inserire una terza riga e solo dopo averlo fatto si avrà la terminazione del
+inserire una terza riga e solo dopo averlo fatto si avrà la terminazione del
programma.
Per capire come questa avvenga comunque, non avendo inserito nel codice nessun
-controllo di errore, occorre ricordare che, a parte la bidirezionalità del
+controllo di errore, occorre ricordare che, a parte la bidirezionalità del
flusso dei dati, dal punto di vista del funzionamento nei confronti delle
funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che
-tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
-aperto il lettura il processo riceve un segnale di \const{SIGPIPE}, e questo è
+tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
+aperto il lettura il processo riceve un segnale di \const{SIGPIPE}, e questo è
esattamente quello che avviene in questo caso, e siccome non abbiamo un
-gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
+gestore per questo segnale, viene eseguita l'azione preimpostata, che è quella
di terminare il processo.
-Per gestire in maniera più corretta questo tipo di evento dovremo allora
-modificare il nostro client perché sia in grado di trattare le varie tipologie
+Per gestire in maniera più corretta questo tipo di evento dovremo allora
+modificare il nostro client perché sia in grado di trattare le varie tipologie
di errore, per questo dovremo riscrivere la funzione \func{ClientEcho}, in
-modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
+modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
\begin{figure}[!htb]
\label{fig:TCP_ClientEcho_second}
\end{figure}
-Come si può vedere in questo caso si controlla il valore di ritorno di tutte
+Come si può vedere in questo caso si controlla il valore di ritorno di tutte
le funzioni, ed inoltre si verifica la presenza di un eventuale end of file in
caso di lettura. Con questa modifica il nostro client echo diventa in grado di
accorgersi della chiusura del socket da parte del server, per cui ripetendo la
Seconda riga dopo il C-c
EOF sul socket
\end{verbatim}%$
-ma di nuovo si tenga presente che non c'è modo di accorgersi della chiusura
+ma di nuovo si tenga presente che non c'è modo di accorgersi della chiusura
del socket fin quando non si esegue la scrittura della seconda riga; il
protocollo infatti prevede che ci debba essere una scrittura prima di ricevere
un RST che confermi la chiusura del file, e solo alle successive scritture si
-potrà ottenere un errore.
+potrà ottenere un errore.
Questa caratteristica dei socket ci mette di fronte ad un altro problema
-relativo al nostro client, e che cioè esso non è in grado di accorgersi di
-nulla fintanto che è bloccato nella lettura del terminale fatta con
-\func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
-avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
-fare con la necessità di lavorare con più descrittori, nel qual caso diventa
+relativo al nostro client, e che cioè esso non è in grado di accorgersi di
+nulla fintanto che è bloccato nella lettura del terminale fatta con
+\func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
+avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
+fare con la necessità di lavorare con più descrittori, nel qual caso diventa
si pone la questione di come fare a non restare bloccati su un socket quando
altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
sez.~\ref{sec:TCP_sock_multiplexing}.
\subsection{Altri scenari di terminazione della connessione}
\label{sec:TCP_conn_crash}
-La terminazione del server è solo uno dei possibili scenari di terminazione
-della connessione, un altro caso è ad esempio quello in cui si ha un crollo
+La terminazione del server è solo uno dei possibili scenari di terminazione
+della connessione, un altro caso è ad esempio quello in cui si ha un crollo
della rete, cosa che potremo simulare facilmente staccando il cavo di rete.
-Un'altra condizione è quella di un blocco della macchina completo della su cui
+Un'altra condizione è quella di un blocco della macchina completo della su cui
gira il server che deve essere riavviata, cosa che potremo simulare sia
premendo il bottone di reset,\footnote{un normale shutdown non va bene; in tal
caso infatti il sistema provvede a terminare tutti i processi, per cui la
situazione sarebbe sostanzialmente identica alla precedente.} che, in
-maniera più gentile, riavviando la macchina dopo aver interrotto la
+maniera più gentile, riavviando la macchina dopo aver interrotto la
connessione di rete.
Cominciamo ad analizzare il primo caso, il crollo della rete. Ripetiamo la
nostra sessione di lavoro precedente, lanciamo il client, scriviamo una prima
riga, poi stacchiamo il cavo e scriviamo una seconda riga. Il risultato che
-otterremo è:
+otterremo è:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.141
Prima riga
Errore in lettura: No route to host
\end{verbatim}%$
-Quello che succede in questo è che il programma, dopo aver scritto la seconda
+Quello che succede in questo è che il programma, dopo aver scritto la seconda
riga, resta bloccato per un tempo molto lungo, prima di dare l'errore
\errcode{EHOSTUNREACH}. Se andiamo ad osservare con \cmd{strace} cosa accade
-nel periodo in cui il programma è bloccato vedremo che stavolta, a differenza
-del caso precedente, il programma è bloccato nella lettura dal socket.
+nel periodo in cui il programma è bloccato vedremo che stavolta, a differenza
+del caso precedente, il programma è bloccato nella lettura dal socket.
Se poi, come nel caso precedente, usiamo l'accortezza di analizzare il
traffico di rete fra client e server con \cmd{tcpdump}, otterremo il seguente
...
\end{verbatim}
-In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso
+In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso
di prima. Solo che stavolta, non appena inviata la seconda riga, il programma
-si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna
-risposta. Quello che succede è che nel frattempo il kernel provvede, come
+si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna
+risposta. Quello che succede è che nel frattempo il kernel provvede, come
richiesto dal protocollo TCP, a tentare la ritrasmissione della nostra riga un
certo numero di volte, con tempi di attesa crescente fra un tentativo ed il
successivo, per tentare di ristabilire la connessione.
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
-preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione,
+preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione,
ma nel nostro caso le cose sono andate diversamente, dato che le
ritrasmissioni registrate da \cmd{tcpdump} sono solo 8; inoltre l'errore
-riportato all'uscita del client non è stato \errcode{ETIMEDOUT}, come dovrebbe
+riportato all'uscita del client non è stato \errcode{ETIMEDOUT}, come dovrebbe
essere in questo caso, ma \errcode{EHOSTUNREACH}.
Per capire l'accaduto continuiamo ad analizzare l'output di \cmd{tcpdump}:
pacchetto sono cessati, per essere sostituiti da una serie di richieste di
protocollo ARP in cui il client richiede l'indirizzo del server.
-Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP è il protocollo
+Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP è il protocollo
che si incarica di trovare le corrispondenze fra indirizzo IP e indirizzo
-hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
-client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
- cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente
+hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
+client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
+ cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente
dal kernel che contiene tutte le corrispondenze fra indirizzi IP e indirizzi
fisici, ottenute appunto attraverso il protocollo ARP; le voci della tabella
hanno un tempo di vita limitato, passato il quale scadono e devono essere
iniziato ad effettuare richieste ARP sulla rete per sapere l'IP di
quest'ultimo, che essendo scollegato non poteva rispondere. Anche per questo
tipo di richieste esiste un timeout, per cui dopo un certo numero di tentativi
-il meccanismo si è interrotto, e l'errore riportato al programma a questo
-punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado di
+il meccanismo si è interrotto, e l'errore riportato al programma a questo
+punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado di
contattare il server.
-Un altro errore possibile in questo tipo di situazione, che si può avere
-quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
+Un altro errore possibile in questo tipo di situazione, che si può avere
+quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
riportato alla ricezione di un pacchetto ICMP di \textit{destination
unreachable} da parte del router che individua l'interruzione della
-connessione. Di nuovo anche qui il risultato finale dipende da quale è il
-meccanismo più veloce ad accorgersi del problema.
+connessione. Di nuovo anche qui il risultato finale dipende da quale è il
+meccanismo più veloce ad accorgersi del problema.
-Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
-un valore di tentativi più basso, possiamo evitare la scadenza della
-\textit{ARP cache} e vedere cosa succede. Così se ad esempio richiediamo 4
-tentativi di ritrasmissione, l'analisi di \cmd{tcpdump} ci riporterà il
+Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
+un valore di tentativi più basso, possiamo evitare la scadenza della
+\textit{ARP cache} e vedere cosa succede. Così se ad esempio richiediamo 4
+tentativi di ritrasmissione, l'analisi di \cmd{tcpdump} ci riporterà il
seguente scambio di pacchetti:
\begin{verbatim}
[root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t
\end{verbatim}
e come si vede in questo caso i tentativi di ritrasmissione del pacchetto
iniziale sono proprio 4 (per un totale di 5 voci con quello trasmesso la prima
-volta), ed in effetti, dopo un tempo molto più breve rispetto a prima ed in
+volta), ed in effetti, dopo un tempo molto più breve rispetto a prima ed in
corrispondenza dell'invio dell'ultimo tentativo, quello che otterremo come
-errore all'uscita del client sarà diverso, e cioè:
+errore all'uscita del client sarà diverso, e cioè:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.141
Prima riga
fa da server. Al solito lanciamo il nostro client, scriviamo una prima riga
per verificare che sia tutto a posto, poi stacchiamo il cavo e riavviamo il
server. A questo punto, ritornato attivo il server, scriviamo una seconda
-riga. Quello che otterremo in questo caso è:
+riga. Quello che otterremo in questo caso è:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.141
Prima riga
Seconda riga dopo l'interruzione
Errore in lettura Connection reset by peer
\end{verbatim}%$
-e l'errore ricevuti da \func{read} stavolta è \errcode{ECONNRESET}. Se al
+e l'errore ricevuti da \func{read} stavolta è \errcode{ECONNRESET}. Se al
solito riportiamo l'analisi dei pacchetti effettuata con \cmd{tcpdump},
avremo:
\begin{verbatim}
\end{verbatim}
Ancora una volta i primi sette pacchetti sono gli stessi; ma in questo caso
-quello che succede dopo lo scambio iniziale è che, non avendo inviato nulla
-durante il periodo in cui si è riavviato il server, il client è del tutto
-ignaro dell'accaduto per cui quando effettuerà una scrittura, dato che la
-macchina server è stata riavviata e che tutti gli stati relativi alle
+quello che succede dopo lo scambio iniziale è che, non avendo inviato nulla
+durante il periodo in cui si è riavviato il server, il client è del tutto
+ignaro dell'accaduto per cui quando effettuerà una scrittura, dato che la
+macchina server è stata riavviata e che tutti gli stati relativi alle
precedenti connessioni sono completamente persi, anche in presenza di una
-nuova istanza del server echo non sarà possibile consegnare i dati in arrivo,
-per cui alla loro ricezione il kernel risponderà con un segmento di RST.
+nuova istanza del server echo non sarà possibile consegnare i dati in arrivo,
+per cui alla loro ricezione il kernel risponderà con un segmento di RST.
-Il client da parte sua, dato che neanche in questo caso non è stato emesso un
-FIN, dopo aver scritto verrà bloccato nella successiva chiamata a \func{read},
-che però adesso ritornerà immediatamente alla ricezione del segmento RST,
+Il client da parte sua, dato che neanche in questo caso non è stato emesso un
+FIN, dopo aver scritto verrà bloccato nella successiva chiamata a \func{read},
+che però adesso ritornerà immediatamente alla ricezione del segmento RST,
riportando appunto come errore \errcode{ECONNRESET}. Occorre precisare che se
si vuole che il client sia in grado di accorgersi del crollo del server anche
-quando non sta effettuando uno scambio di dati, è possibile usare una
+quando non sta effettuando uno scambio di dati, è possibile usare una
impostazione speciale del socket (ci torneremo in
sez.~\ref{sec:sock_generic_options}) che provvede all'esecuzione di questo
controllo.
\label{sec:TCP_sock_multiplexing}
Affronteremo in questa sezione l'utilizzo dell'I/O multiplexing, affrontato in
-sez.~\ref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già
+sez.~\ref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già
in sez.~\ref{sec:TCP_server_crash} era emerso il problema relativo al client
del servizio echo che non era in grado di accorgersi della terminazione
precoce del server, essendo bloccato nella lettura dei dati immessi da
tastiera.
-Abbiamo visto in sez.~\ref{sec:file_multiplexing} quali sono le funzionalità
-del sistema che ci permettono di tenere sotto controllo più file descriptor in
+Abbiamo visto in sez.~\ref{sec:file_multiplexing} quali sono le funzionalità
+del sistema che ci permettono di tenere sotto controllo più file descriptor in
contemporanea; in quella occasione non abbiamo fatto esempi, in quanto quando
si tratta con file normali questa tipologia di I/O normalmente non viene
-usata, è invece un caso tipico delle applicazioni di rete quello di dover
+usata, è invece un caso tipico delle applicazioni di rete quello di dover
gestire varie connessioni da cui possono arrivare dati comuni in maniera
asincrona, per cui riprenderemo l'argomento in questa sezione.
\label{sec:TCP_sock_select}
Iniziamo con la prima delle funzioni usate per l'I/O multiplexing,
-\func{select}; il suo funzionamento è già stato descritto in dettaglio in
-sez.~\ref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì;
-sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
-sotto controllo è pronto per la relativa operazione.
+\func{select}; il suo funzionamento è già stato descritto in dettaglio in
+sez.~\ref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì;
+sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
+sotto controllo è pronto per la relativa operazione.
-In quell'occasione non abbiamo però definito cosa si intende per pronto,
+In quell'occasione non abbiamo però definito cosa si intende per pronto,
infatti per dei normali file, o anche per delle pipe, la condizione di essere
-pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
+pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
dei socket, visto che possono intervenire tutte una serie di possibili
condizioni di errore dovute alla rete. Occorre allora specificare chiaramente
quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}''
\textit{file descriptor set} usati da \func{select}.
Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
-che un socket (che sarà riportato nel primo insieme di file descriptor) è
+che un socket (che sarà riportato nel primo insieme di file descriptor) è
pronto per la lettura sono le seguenti:
\begin{itemize*}
-\item nel buffer di ricezione del socket sono arrivati dei dati in quantità
+\item nel buffer di ricezione del socket sono arrivati dei dati in quantità
sufficiente a superare il valore di una \textsl{soglia di basso livello} (il
- cosiddetto \textit{low watermark}). Questo valore è espresso in numero di
- byte e può essere impostato con l'opzione del socket \const{SO\_RCVLOWAT}
+ cosiddetto \textit{low watermark}). Questo valore è espresso in numero di
+ byte e può essere impostato con l'opzione del socket \const{SO\_RCVLOWAT}
(tratteremo l'uso di questa opzione in sez.~\ref{sec:sock_generic_options});
- il suo valore di default è 1 per i socket TCP e UDP. In questo caso una
- operazione di lettura avrà successo e leggerà un numero di byte maggiore di
+ il suo valore di default è 1 per i socket TCP e UDP. In questo caso una
+ operazione di lettura avrà successo e leggerà un numero di byte maggiore di
zero.
-\item il lato in lettura della connessione è stato chiuso; si è cioè ricevuto
+\item il lato in lettura della connessione è stato chiuso; si è cioè ricevuto
un segmento FIN (si ricordi quanto illustrato in
sez.~\ref{sec:TCP_conn_term}) sulla connessione. In questo caso una
- operazione di lettura avrà successo, ma non risulteranno presenti dati (in
- sostanza \func{read} ritornerà con un valore nullo) per indicare la
+ operazione di lettura avrà successo, ma non risulteranno presenti dati (in
+ sostanza \func{read} ritornerà con un valore nullo) per indicare la
condizione di end-of-file.
-\item c'è stato un errore sul socket. In questo caso una operazione di lettura
- non si bloccherà ma restituirà una condizione di errore (ad esempio
- \func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
+\item c'è stato un errore sul socket. In questo caso una operazione di lettura
+ non si bloccherà ma restituirà una condizione di errore (ad esempio
+ \func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
valore. Vedremo in sez.~\ref{sec:sock_generic_options} come sia possibile
estrarre e cancellare gli errori pendenti su un socket senza usare
\func{read} usando l'opzione \const{SO\_ERROR}.
\item quando si sta utilizzando un \textit{listening socket} ed ci sono delle
connessioni completate. In questo caso la funzione \func{accept} non si
- bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
- sez.~\ref{sec:TCP_conn_early_abort} una connessione può essere abortita
- dalla ricezione di un segmento RST una volta che è stata completata,
- allora se questo avviene dopo che \func{select} è ritornata, ma prima
+ bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
+ sez.~\ref{sec:TCP_conn_early_abort} una connessione può essere abortita
+ dalla ricezione di un segmento RST una volta che è stata completata,
+ allora se questo avviene dopo che \func{select} è ritornata, ma prima
della chiamata ad \func{accept}, quest'ultima, in assenza di altre
- connessioni, potrà bloccarsi.}
+ connessioni, potrà bloccarsi.}
\end{itemize*}
Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
-che un socket (che sarà riportato nel secondo insieme di file descriptor) è
+che un socket (che sarà riportato nel secondo insieme di file descriptor) è
pronto per la scrittura sono le seguenti:
\begin{itemize*}
-\item nel buffer di invio è disponibile una quantità di spazio superiore al
+\item nel buffer di invio è disponibile una quantità di spazio superiore al
valore della \textsl{soglia di basso livello} in scrittura ed inoltre o il
- socket è già connesso o non necessita (ad esempio è UDP) di connessione. Il
- valore della soglia è espresso in numero di byte e può essere impostato con
+ socket è già connesso o non necessita (ad esempio è UDP) di connessione. Il
+ valore della soglia è espresso in numero di byte e può essere impostato con
l'opzione del socket \const{SO\_SNDLOWAT} (trattata in
- sez.~\ref{sec:sock_generic_options}); il suo valore di default è 2048 per i
+ sez.~\ref{sec:sock_generic_options}); il suo valore di default è 2048 per i
socket TCP e UDP. In questo caso una operazione di scrittura non si
- bloccherà e restituirà un valore positivo pari al numero di byte accettati
+ bloccherà e restituirà un valore positivo pari al numero di byte accettati
dal livello di trasporto.
-\item il lato in scrittura della connessione è stato chiuso. In questo caso
- una operazione di scrittura sul socket genererà il segnale \const{SIGPIPE}.
-\item c'è stato un errore sul socket. In questo caso una operazione di
- scrittura non si bloccherà ma restituirà una condizione di errore ed
- imposterà opportunamente la variabile \var{errno}. Vedremo in
+\item il lato in scrittura della connessione è stato chiuso. In questo caso
+ una operazione di scrittura sul socket genererà il segnale \const{SIGPIPE}.
+\item c'è stato un errore sul socket. In questo caso una operazione di
+ scrittura non si bloccherà ma restituirà una condizione di errore ed
+ imposterà opportunamente la variabile \var{errno}. Vedremo in
sez.~\ref{sec:sock_generic_options} come sia possibile estrarre e cancellare
errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
\end{itemize*}
-Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
-che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
-condizione di eccezione pendente, e cioè la ricezione sul socket di
+Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
+che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
+condizione di eccezione pendente, e cioè la ricezione sul socket di
\textsl{dati urgenti} (o \itindex{out-of-band} \textit{out-of-band}), una
caratteristica specifica dei socket TCP su cui torneremo in
sez.~\ref{sec:TCP_urgent_data}.
Si noti come nel caso della lettura \func{select} si applichi anche ad
operazioni che non hanno nulla a che fare con l'I/O di dati come il
riconoscimento della presenza di connessioni pronte, in modo da consentire
-anche l'utilizzo di \func{accept} in modalità non bloccante. Si noti infine
+anche l'utilizzo di \func{accept} in modalità non bloccante. Si noti infine
come in caso di errore un socket venga sempre riportato come pronto sia per la
lettura che per la scrittura.
-Lo scopo dei due valori di soglia per i buffer di ricezione e di invio è
-quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
-dei programmi, se infatti si sa che una applicazione non è in grado di fare
-niente fintanto che non può ricevere o inviare una certa quantità di dati, si
+Lo scopo dei due valori di soglia per i buffer di ricezione e di invio è
+quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
+dei programmi, se infatti si sa che una applicazione non è in grado di fare
+niente fintanto che non può ricevere o inviare una certa quantità di dati, si
possono utilizzare questi valori per far si che \func{select} ritorni solo
-quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
- controllo è utile di norma solo per la lettura, in quanto in genere le
- operazioni di scrittura sono già controllate dall'applicazione, che sa
- sempre quanti dati invia, mentre non è detto possa conoscere la quantità di
+quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
+ controllo è utile di norma solo per la lettura, in quanto in genere le
+ operazioni di scrittura sono già controllate dall'applicazione, che sa
+ sempre quanti dati invia, mentre non è detto possa conoscere la quantità di
dati in ricezione; per cui, nella situazione in cui si conosce almeno un
valore minimo, per evitare la penalizzazione dovuta alla ripetizione delle
- operazioni di lettura per accumulare dati sufficienti, si può lasciare al
+ operazioni di lettura per accumulare dati sufficienti, si può lasciare al
kernel il compito di impostare un minimo al di sotto del quale il socket,
pur avendo disponibili dei dati, non viene dato per pronto in lettura.}
di rendersi conto di errori sulla connessione essendo impegnato nella attesa
di dati in ingresso dallo standard input.
-In questo caso il problema è quello di dover tenere sotto controllo due
+In questo caso il problema è quello di dover tenere sotto controllo due
diversi file descriptor, lo standard input, da cui viene letto il testo che
vogliamo inviare al server, e il socket connesso con il server su cui detto
-testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
+testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
dell'I/O multiplexing consente di tenere sotto controllo entrambi, senza
restare bloccati.
-Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
+Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
standard input in caso di errori sulla connessione o chiusura della stessa da
parte del server. Entrambi questi casi possono essere rilevati usando
\func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select}, mettendo
sotto osservazione i file descriptor per la condizione di essere pronti in
lettura: sia infatti che si ricevano dati, che la connessione sia chiusa
regolarmente (con la ricezione di un segmento FIN) che si riceva una
-condizione di errore (con un segmento RST) il socket connesso sarà pronto in
-lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
+condizione di errore (con un segmento RST) il socket connesso sarà pronto in
+lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
nostri scopi).
\begin{figure}[!htb]
\end{figure}
Riprendiamo allora il codice del client, modificandolo per l'uso di
-\func{select}. Quello che dobbiamo modificare è la funzione \func{ClientEcho}
+\func{select}. Quello che dobbiamo modificare è la funzione \func{ClientEcho}
di fig.~\ref{fig:TCP_ClientEcho_second}, dato che tutto il resto, che riguarda
-le modalità in cui viene stabilita la connessione con il server, resta
+le modalità in cui viene stabilita la connessione con il server, resta
assolutamente identico. La nostra nuova versione di \func{ClientEcho}, la
-terza della serie, è riportata in fig.~\ref{fig:TCP_ClientEcho_third}, il
+terza della serie, è riportata in fig.~\ref{fig:TCP_ClientEcho_third}, il
codice completo si trova nel file \file{TCP\_echo\_third.c} dei sorgenti
allegati alla guida.
l'impostazione del valore \var{maxfd}, da passare a \func{select} come massimo
per il numero di file descriptor. Per determinare quest'ultimo si usa la macro
\code{max} definita nel nostro file \file{macro.h} che raccoglie una
-collezione di macro di preprocessore di varia utilità.
+collezione di macro di preprocessore di varia utilità.
La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
(\texttt{\small 11--12}) il \itindex{file~descriptor~set} \textit{file
descriptor set}, impostando i valori per il file descriptor associato al
socket \var{socket} e per lo standard input (il cui valore si recupera con la
-funzione \func{fileno}). Questo è necessario in quanto la successiva
+funzione \func{fileno}). Questo è necessario in quanto la successiva
(\texttt{\small 13}) chiamata a \func{select} comporta una modifica dei due
bit relativi, che quindi devono essere reimpostati all'inizio di ogni ciclo.
Si noti come la chiamata a \func{select} venga eseguita usando come primo
argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
il solo \itindex{file~descriptor~set} \textit{file descriptor set} per il
-controllo dell'attività in lettura, negli altri argomenti sono passati tutti
-puntatori nulli, non interessando né il controllo delle altre attività, né
+controllo dell'attività in lettura, negli altri argomenti sono passati tutti
+puntatori nulli, non interessando né il controllo delle altre attività, né
l'impostazione di un valore di timeout.
Al ritorno di \func{select} si provvede a controllare quale dei due file
-descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
-con il file descriptor associato allo standard input. In caso di attività
-(quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
+descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
+con il file descriptor associato allo standard input. In caso di attività
+(quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
(\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati presenti;
se non ve ne sono (e la funzione restituisce pertanto un puntatore nullo) si
-ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
+ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
chiuso lo standard input e quindi concluso l'utilizzo del client; altrimenti
(\texttt{\small 18--22}) si scrivono i dati appena letti sul socket,
prevedendo una uscita immediata in caso di errore di scrittura.
Controllato lo standard input si passa a controllare (\texttt{\small 25--40})
-il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
-una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
-(\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
-immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
+il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
+una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
+(\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
+immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
il server ha chiuso la connessione, e di nuovo si esce con stampando prima un
messaggio di avviso, altrimenti (\texttt{\small 35--39}) si effettua la
terminazione della stringa e la si stampa a sullo standard output (uscendo in
Con questo meccanismo il programma invece di essere bloccato in lettura sullo
standard input resta bloccato sulla \func{select}, che ritorna soltanto quando
-viene rilevata attività su uno dei due file descriptor posti sotto controllo.
-Questo di norma avviene solo quando si è scritto qualcosa sullo standard
+viene rilevata attività su uno dei due file descriptor posti sotto controllo.
+Questo di norma avviene solo quando si è scritto qualcosa sullo standard
input, o quando si riceve dal socket la risposta a quanto si era appena
scritto. Ma adesso il client diventa capace di accorgersi immediatamente della
-terminazione del server; in tal caso infatti il server chiuderà il socket
-connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
+terminazione del server; in tal caso infatti il server chiuderà il socket
+connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
illustrato in sez.~\ref{sec:TCP_sock_select}) segnalando una condizione di end
-of file, per cui il nostro client potrà uscire immediatamente.
+of file, per cui il nostro client potrà uscire immediatamente.
Riprendiamo la situazione affrontata in sez.~\ref{sec:TCP_server_crash},
terminando il server durante una connessione, in questo caso quello che
otterremo, una volta scritta una prima riga ed interrotto il server con un
-\texttt{C-c}, sarà:
+\texttt{C-c}, sarà:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.1
Prima riga
EOF sul socket
\end{verbatim}%$
dove l'ultima riga compare immediatamente dopo aver interrotto il server. Il
-nostro client infatti è in grado di accorgersi immediatamente che il socket
-connesso è stato chiuso ed uscire immediatamente.
+nostro client infatti è in grado di accorgersi immediatamente che il socket
+connesso è stato chiuso ed uscire immediatamente.
Veniamo allora agli altri scenari di terminazione anomala visti in
-sez.~\ref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
+sez.~\ref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
connessione; in questo caso avremo un comportamento analogo al precedente, in
cui si scrive una riga e non si riceve risposta dal server e non succede
niente fino a quando non si riceve un errore di \errcode{EHOSTUNREACH} o
\errcode{ETIMEDOUT} a seconda dei casi.
-La differenza è che stavolta potremo scrivere più righe dopo l'interruzione,
-in quanto il nostro client dopo aver inviato i dati non si bloccherà più nella
-lettura dal socket, ma nella \func{select}; per questo potrà accettare
-ulteriore dati che scriverà di nuovo sul socket, fintanto che c'è spazio sul
-buffer di uscita (ecceduto il quale si bloccherà in scrittura). Si ricordi
-infatti che il client non ha modo di determinare se la connessione è attiva o
-meno (dato che in molte situazioni reali l'inattività può essere temporanea).
+La differenza è che stavolta potremo scrivere più righe dopo l'interruzione,
+in quanto il nostro client dopo aver inviato i dati non si bloccherà più nella
+lettura dal socket, ma nella \func{select}; per questo potrà accettare
+ulteriore dati che scriverà di nuovo sul socket, fintanto che c'è spazio sul
+buffer di uscita (ecceduto il quale si bloccherà in scrittura). Si ricordi
+infatti che il client non ha modo di determinare se la connessione è attiva o
+meno (dato che in molte situazioni reali l'inattività può essere temporanea).
Tra l'altro se si ricollega la rete prima della scadenza del timeout, potremo
anche verificare come tutto quello che si era scritto viene poi effettivamente
trasmesso non appena la connessione ridiventa attiva, per cui otterremo
Lo stesso comportamento visto in sez.~\ref{sec:TCP_server_crash} si riottiene
nel caso di un crollo completo della macchina su cui sta il server. In questo
-caso di nuovo il client non è in grado di accorgersi di niente dato che si
+caso di nuovo il client non è in grado di accorgersi di niente dato che si
suppone che il programma server non venga terminato correttamente, ma si
-blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
+blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
segnala la terminazione della connessione. Di nuovo fintanto che la
connessione non si riattiva (con il riavvio della macchina del server) il
-client non è in grado di fare altro che accettare dell'input e tentare di
-inviarlo. La differenza in questo caso è che non appena la connessione
-ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
+client non è in grado di fare altro che accettare dell'input e tentare di
+inviarlo. La differenza in questo caso è che non appena la connessione
+ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
informazioni relative alle precedenti connessioni ai tentativi di scrittura
-del client sarà risposto con un segmento RST che provocherà il ritorno di
+del client sarà risposto con un segmento RST che provocherà il ritorno di
\func{select} per la ricezione di un errore di \errcode{ECONNRESET}.
\label{sec:TCP_shutdown}
Come spiegato in sez.~\ref{sec:TCP_conn_term} il procedimento di chiusura di un
-socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
+socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
pertanto del tutto normale dal punto di vista del protocollo che uno dei due
capi chiuda la connessione, quando l'altro capo la lascia
aperta.\footnote{abbiamo incontrato questa situazione nei vari scenari critici
di sez.~\ref{sec:TCP_echo_critical}.}
-È pertanto possibile avere una situazione in cui un capo della connessione non
-avendo più nulla da scrivere, possa chiudere il socket, segnalando così
-l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
-end-of-file in lettura) mentre dall'altra parte si potrà proseguire la
-trasmissione dei dati scrivendo sul socket che da quel lato è ancora aperto.
-Questa è quella situazione in cui si dice che il socket è \textit{half
+È pertanto possibile avere una situazione in cui un capo della connessione non
+avendo più nulla da scrivere, possa chiudere il socket, segnalando così
+l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
+end-of-file in lettura) mentre dall'altra parte si potrà proseguire la
+trasmissione dei dati scrivendo sul socket che da quel lato è ancora aperto.
+Questa è quella situazione in cui si dice che il socket è \textit{half
closed}.
-Il problema che si pone è che se la chiusura del socket è effettuata con la
+Il problema che si pone è che se la chiusura del socket è effettuata con la
funzione \func{close}, come spiegato in sez.~\ref{sec:TCP_func_close}, si perde
-ogni possibilità di poter rileggere quanto l'altro capo può continuare a
-scrivere. Per poter permettere allora di segnalare che si è concluso con la
-scrittura, continuando al contempo a leggere quanto può provenire dall'altro
-capo del socket si può allora usare la funzione \funcd{shutdown}, il cui
-prototipo è:
+ogni possibilità di poter rileggere quanto l'altro capo può continuare a
+scrivere. Per poter permettere allora di segnalare che si è concluso con la
+scrittura, continuando al contempo a leggere quanto può provenire dall'altro
+capo del socket si può allora usare la funzione \funcd{shutdown}, il cui
+prototipo è:
\begin{prototype}{sys/socket.h}
{int shutdown(int sockfd, int how)}
Chiude un lato della connessione fra due socket.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ENOTSOCK}] il file descriptor non corrisponde a un socket.
- \item[\errcode{ENOTCONN}] il socket non è connesso.
+ \item[\errcode{ENOTCONN}] il socket non è connesso.
\end{errlist}
ed inoltre \errval{EBADF}.}
\end{prototype}
La funzione prende come primo argomento il socket \param{sockfd} su cui si
vuole operare e come secondo argomento un valore intero \param{how} che indica
-la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
+la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
valori:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\macro{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
+\item[\macro{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
possibile leggere dati da esso, tutti gli eventuali dati trasmessi
dall'altro capo del socket saranno automaticamente scartati dal kernel, che,
- in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
+ in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
ACK.
-\item[\macro{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
+\item[\macro{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
possibile scrivere dati su di esso. Nel caso di socket TCP la chiamata causa
l'emissione di un segmento FIN, secondo la procedura chiamata
\itindex{half-close} \textit{half-close}. Tutti i dati presenti nel buffer
di scrittura prima della chiamata saranno inviati, seguiti dalla sequenza di
chiusura illustrata in sez.~\ref{sec:TCP_conn_term}.
\item[\macro{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
- scrittura del socket. È equivalente alla chiamata in sequenza con
+ scrittura del socket. È equivalente alla chiamata in sequenza con
\macro{SHUT\_RD} e \macro{SHUT\_WR}.
\end{basedescript}
-Ci si può chiedere quale sia l'utilità di avere introdotto \macro{SHUT\_RDWR}
+Ci si può chiedere quale sia l'utilità di avere introdotto \macro{SHUT\_RDWR}
quando questa sembra rendere \funcd{shutdown} del tutto equivalente ad una
-\func{close}. In realtà non è così, esiste infatti un'altra differenza con
-\func{close}, più sottile. Finora infatti non ci siamo presi la briga di
+\func{close}. In realtà non è così, esiste infatti un'altra differenza con
+\func{close}, più sottile. Finora infatti non ci siamo presi la briga di
sottolineare in maniera esplicita che, come per i file e le fifo, anche per i
-socket possono esserci più riferimenti contemporanei ad uno stesso socket. Per
+socket possono esserci più riferimenti contemporanei ad uno stesso socket. Per
cui si avrebbe potuto avere l'impressione che sia una corrispondenza univoca
-fra un socket ed il file descriptor con cui vi si accede. Questo non è
-assolutamente vero, (e lo abbiamo già visto nel codice del server di
-fig.~\ref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
-che, come per gli altri oggetti, ci possano essere più file descriptor che
+fra un socket ed il file descriptor con cui vi si accede. Questo non è
+assolutamente vero, (e lo abbiamo già visto nel codice del server di
+fig.~\ref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
+che, come per gli altri oggetti, ci possano essere più file descriptor che
fanno riferimento allo stesso socket.
-Allora se avviene uno di questi casi quello che succederà è che la chiamata a
-\func{close} darà effettivamente avvio alla sequenza di chiusura di un socket
-soltanto quando il numero di riferimenti a quest'ultimo diventerà nullo.
+Allora se avviene uno di questi casi quello che succederà è che la chiamata a
+\func{close} darà effettivamente avvio alla sequenza di chiusura di un socket
+soltanto quando il numero di riferimenti a quest'ultimo diventerà nullo.
Fintanto che ci sono file descriptor che fanno riferimento ad un socket l'uso
-di \func{close} si limiterà a deallocare nel processo corrente il file
-descriptor utilizzato, ma il socket resterà pienamente accessibile attraverso
+di \func{close} si limiterà a deallocare nel processo corrente il file
+descriptor utilizzato, ma il socket resterà pienamente accessibile attraverso
tutti gli altri riferimenti. Se torniamo all'esempio originale del server di
fig.~\ref{fig:TCP_echo_server_first_code} abbiamo infatti che ci sono due
\func{close}, una sul socket connesso nel padre, ed una sul socket in ascolto
Questo non avviene affatto se si usa \func{shutdown} con argomento
\macro{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
chiusura del socket viene effettuata immediatamente, indipendentemente dalla
-presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
+presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
gli altri file descriptor con cui, nello stesso o in altri processi, si fa
riferimento allo stesso socket.
-Il caso più comune di uso di \func{shutdown} è comunque quello della chiusura
-del lato in scrittura, per segnalare all'altro capo della connessione che si è
+Il caso più comune di uso di \func{shutdown} è comunque quello della chiusura
+del lato in scrittura, per segnalare all'altro capo della connessione che si è
concluso l'invio dei dati, restando comunque in grado di ricevere quanto
-questi potrà ancora inviarci. Questo è ad esempio l'uso che ci serve per
+questi potrà ancora inviarci. Questo è ad esempio l'uso che ci serve per
rendere finalmente completo il nostro esempio sul servizio \textit{echo}. Il
nostro client infatti presenta ancora un problema, che nell'uso che finora ne
-abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena
+abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena
usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo standard
-input e standard output. Così se eseguiamo:
+input e standard output. Così se eseguiamo:
\begin{verbatim}
[piccardi@gont sources]$ ./echo 192.168.1.1 < ../fileadv.tex > copia
\end{verbatim}%$
Per capire cosa avviene in questo caso occorre tenere presente come avviene la
comunicazione via rete; quando redirigiamo lo standard input il nostro client
-inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
+inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
dimensione massima pari a \texttt{MAXLINE} per poi scriverlo, alla massima
-velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
-una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
+velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
+una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
-di processo, questo tempo è quello impiegato nella trasmissione via rete, che
+di processo, questo tempo è quello impiegato nella trasmissione via rete, che
viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time}
-\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
+\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
\cmd{ping}.
A questo punto, se torniamo al codice mostrato in
fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
sono in transito sulla rete il client continua a leggere e a scrivere fintanto
-che il file in ingresso finisce. Però non appena viene ricevuto un end-of-file
+che il file in ingresso finisce. Però non appena viene ricevuto un end-of-file
in ingresso il nostro client termina. Nel caso interattivo, in cui si
inviavano brevi stringhe una alla volta, c'era sempre il tempo di eseguire la
lettura completa di quanto il server rimandava indietro. In questo caso
invece, quando il client termina, essendo la comunicazione saturata e a piena
-velocità, ci saranno ancora pacchetti in transito sulla rete che devono
+velocità, ci saranno ancora pacchetti in transito sulla rete che devono
arrivare al server e poi tornare indietro, ma siccome il client esce
immediatamente dopo la fine del file in ingresso, questi non faranno a tempo a
completare il percorso e verranno persi.
Per evitare questo tipo di problema, invece di uscire una volta completata la
lettura del file in ingresso, occorre usare \func{shutdown} per effettuare la
-chiusura del lato in scrittura del socket. In questo modo il client segnalerà
-al server la chiusura del flusso dei dati, ma potrà continuare a leggere
+chiusura del lato in scrittura del socket. In questo modo il client segnalerà
+al server la chiusura del flusso dei dati, ma potrà continuare a leggere
quanto il server gli sta ancora inviando indietro, fino a quando anch'esso,
riconosciuta la chiusura del socket in scrittura da parte del client,
-effettuerà la chiusura dalla sua parte. Solo alla ricezione della chiusura del
-socket da parte del server il client potrà essere sicuro della ricezione di
+effettuerà la chiusura dalla sua parte. Solo alla ricezione della chiusura del
+socket da parte del server il client potrà essere sicuro della ricezione di
tutti i dati e della terminazione effettiva della connessione.
\begin{figure}[!htb]
\label{fig:TCP_ClientEcho}
\end{figure}
-Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
+Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
della nostra funzione \func{ClientEcho}, in grado di gestire correttamente
l'intero flusso di dati fra client e server. Il codice completo del client,
comprendente la gestione delle opzioni a riga di comando e le istruzioni per
la creazione della connessione, si trova nel file
\texttt{TCP\_echo\_fourth.c}, distribuito coi sorgenti allegati alla guida.
-La nuova versione è molto simile alla precedente di
-fig.~\ref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
+La nuova versione è molto simile alla precedente di
+fig.~\ref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
(\texttt{\small 7}) della variabile \var{eof}, inizializzata ad un valore
nullo, che serve a mantenere traccia dell'avvenuta conclusione della lettura
del file in ingresso.
-La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
+La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
subordinato ad un valore nullo di \var{eof} l'impostazione del file descriptor
set per l'osservazione dello standard input. Se infatti il valore di \var{eof}
-è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
+è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
pertanto inutile continuare a tenere sotto controllo lo standard input nella
successiva (\texttt{\small 16}) chiamata a \func{select}.
usa la macro \macro{FD\_CLR} per togliere lo standard input dal
\itindex{file~descriptor~set} \textit{file descriptor set}.
-In questo modo anche se la lettura del file in ingresso è conclusa, la
+In questo modo anche se la lettura del file in ingresso è conclusa, la
funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
ad eseguirlo ripetendo la chiamata a \func{select} per tenere sotto controllo
soltanto il socket connesso, dal quale possono arrivare altri dati, che
Il ritorno della funzione, e la conseguente terminazione normale del client,
viene invece adesso gestito all'interno (\texttt{\small 30--49}) della lettura
dei dati dal socket; se infatti dalla lettura del socket si riceve una
-condizione di end-of-file, la si tratterà (\texttt{\small 36--43}) in maniera
-diversa a seconda del valore di \var{eof}. Se infatti questa è diversa da zero
+condizione di end-of-file, la si tratterà (\texttt{\small 36--43}) in maniera
+diversa a seconda del valore di \var{eof}. Se infatti questa è diversa da zero
(\texttt{\small 37--39}), essendo stata completata la lettura del file in
-ingresso, vorrà dire che anche il server ha concluso la trasmissione dei dati
-restanti, e si potrà uscire senza errori, altrimenti si stamperà
+ingresso, vorrà dire che anche il server ha concluso la trasmissione dei dati
+restanti, e si potrà uscire senza errori, altrimenti si stamperà
(\texttt{\small 40--42}) un messaggio di errore per la chiusura precoce della
connessione.
connessione.\footnote{ne faremo comunque una implementazione diversa rispetto
a quella presentata da Stevens in \cite{UNP1}.}
-La struttura del nuovo server è illustrata in
+La struttura del nuovo server è illustrata in
fig.~\ref{fig:TCP_echo_multiplex}, in questo caso avremo un solo processo che
ad ogni nuova connessione da parte di un client sul socket in ascolto si
-limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
-utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
+limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
+utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
file descriptor attivi, operando direttamente su ciascuno di essi.
\begin{figure}[htb]
\label{fig:TCP_echo_multiplex}
\end{figure}
-La sezione principale del codice del nuovo server è illustrata in
-fig.~\ref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
-opzioni, che è identica alla versione precedente. Resta invariata anche tutta
+La sezione principale del codice del nuovo server è illustrata in
+fig.~\ref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
+opzioni, che è identica alla versione precedente. Resta invariata anche tutta
la parte relativa alla gestione dei segnali, degli errori, e della cessione
-dei privilegi, così come è identica la gestione della creazione del socket (si
-può fare riferimento al codice già illustrato in
-sez.~\ref{sec:TCPsimp_server_main}); al solito il codice completo del server è
+dei privilegi, così come è identica la gestione della creazione del socket (si
+può fare riferimento al codice già illustrato in
+sez.~\ref{sec:TCPsimp_server_main}); al solito il codice completo del server è
disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}.
\begin{figure}[!htbp]
\end{figure}
In questo caso, una volta aperto e messo in ascolto il socket, tutto quello
-che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove
+che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove
connessioni o di dati in arrivo, e processarli immediatamente. Per
implementare lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il
programma usa una tabella dei socket connessi mantenuta nel vettore
\var{fd\_open} dimensionato al valore di \const{FD\_SETSIZE}, ed una variabile
-\var{max\_fd} per registrare il valore più alto dei file descriptor aperti.
+\var{max\_fd} per registrare il valore più alto dei file descriptor aperti.
Prima di entrare nel ciclo principale (\texttt{\small 6--56}) la nostra
tabella viene inizializzata (\texttt{\small 2}) a zero (valore che
-utilizzeremo come indicazione del fatto che il relativo file descriptor non è
+utilizzeremo come indicazione del fatto che il relativo file descriptor non è
aperto), mentre il valore massimo (\texttt{\small 3}) per i file descriptor
aperti viene impostato a quello del socket in ascolto,\footnote{in quanto esso
- è l'unico file aperto, oltre i tre standard, e pertanto avrà il valore più
- alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
+ è l'unico file aperto, oltre i tre standard, e pertanto avrà il valore più
+ alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
La prima sezione (\texttt{\small 7--10}) del ciclo principale esegue la
costruzione del \itindex{file~descriptor~set} \textit{file descriptor set}
-\var{fset} in base ai socket connessi in un certo momento; all'inizio ci sarà
+\var{fset} in base ai socket connessi in un certo momento; all'inizio ci sarà
soltanto il socket in ascolto, ma nel prosieguo delle operazioni, verranno
utilizzati anche tutti i socket connessi registrati nella tabella
\var{fd\_open}. Dato che la chiamata di \func{select} modifica il valore del
-\itindex{file~descriptor~set} \textit{file descriptor set}, è necessario
+\itindex{file~descriptor~set} \textit{file descriptor set}, è necessario
ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi procedere
con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket trovati
attivi.
Per far questo si usa la caratteristica dei file descriptor, descritta in
sez.~\ref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file
-il file descriptor con il valore più basso disponibile. Questo fa sì che si
+il file descriptor con il valore più basso disponibile. Questo fa sì che si
possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo, che
-sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
+sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
valore massimo di \var{max\_fd} che dovremo aver cura di tenere aggiornato.
-Dopo di che basterà controllare (\texttt{\small 9}) nella nostra tabella se il
-file descriptor è in uso o meno,\footnote{si tenga presente che benché il
+Dopo di che basterà controllare (\texttt{\small 9}) nella nostra tabella se il
+file descriptor è in uso o meno,\footnote{si tenga presente che benché il
kernel assegni sempre il primo valore libero, dato che nelle operazioni i
socket saranno aperti e chiusi in corrispondenza della creazione e
conclusione delle connessioni, si potranno sempre avere dei \textsl{buchi}
set} potremo chiamare \func{select} per fargli osservare lo stato degli
stessi (in lettura, presumendo che la scrittura sia sempre consentita). Come
per il precedente esempio di sez.~\ref{sec:TCP_child_hand}, essendo questa
-l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
+l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
eseguiremo (\texttt{\small 11--12}) all'interno di un ciclo di \code{while}
che la ripete indefinitamente qualora esca con un errore di \errcode{EINTR}.
Nel caso invece di un errore normale si provvede (\texttt{\small 13--16}) ad
Se invece la funzione ritorna normalmente avremo in \var{n} il numero di
socket da controllare. Nello specifico si danno due possibili casi diversi per
-cui \func{select} può essere ritornata: o si è ricevuta una nuova connessione
-ed è pronto il socket in ascolto, sul quale si può eseguire \func{accept} o
-c'è attività su uno dei socket connessi, sui quali si può eseguire
+cui \func{select} può essere ritornata: o si è ricevuta una nuova connessione
+ed è pronto il socket in ascolto, sul quale si può eseguire \func{accept} o
+c'è attività su uno dei socket connessi, sui quali si può eseguire
\func{read}.
Il primo caso viene trattato immediatamente (\texttt{\small 17--26}): si
\var{n}; poi, inizializzata (\texttt{\small 19}) la lunghezza della struttura
degli indirizzi, si esegue \func{accept} per ottenere il nuovo socket connesso
controllando che non ci siano errori (\texttt{\small 20--23}). In questo caso
-non c'è più la necessità di controllare per interruzioni dovute a segnali, in
-quanto siamo sicuri che \func{accept} non si bloccherà. Per completare la
+non c'è più la necessità di controllare per interruzioni dovute a segnali, in
+quanto siamo sicuri che \func{accept} non si bloccherà. Per completare la
trattazione occorre a questo punto aggiungere (\texttt{\small 24}) il nuovo
-file descriptor alla tabella di quelli connessi, ed inoltre, se è il caso,
+file descriptor alla tabella di quelli connessi, ed inoltre, se è il caso,
aggiornare (\texttt{\small 25}) il valore massimo in \var{max\_fd}.
Una volta controllato l'arrivo di nuove connessioni si passa a verificare se
vi sono dati sui socket connessi, per questo si ripete un ciclo
(\texttt{\small 29--55}) fintanto che il numero di socket attivi \var{n} resta
-diverso da zero; in questo modo se l'unico socket con attività era quello
-connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
-saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
+diverso da zero; in questo modo se l'unico socket con attività era quello
+connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
+saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
\itindex{file~descriptor~set} \textit{file descriptor set} con i nuovi valori
-nella tabella) alla chiamata di \func{accept}. Se il socket attivo non è
+nella tabella) alla chiamata di \func{accept}. Se il socket attivo non è
quello in ascolto, o ce ne sono comunque anche altri, il valore di \var{n} non
-sarà nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque
+sarà nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque
si inizializza (\texttt{\small 28}) il valore della variabile \var{i} che
useremo come indice nella tabella \var{fd\_open} al valore minimo,
corrispondente al file descriptor del socket in ascolto.
-Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
+Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
dell'indice \var{i} per posizionarsi sul primo valore possibile per un file
descriptor associato ad un eventuale socket connesso, dopo di che si controlla
-(\texttt{\small 31}) se questo è nella tabella dei socket connessi, chiedendo
+(\texttt{\small 31}) se questo è nella tabella dei socket connessi, chiedendo
la ripetizione del ciclo in caso contrario. Altrimenti si passa a verificare
(\texttt{\small 32}) se il file descriptor corrisponde ad uno di quelli
attivi, e nel caso si esegue (\texttt{\small 33}) una lettura, uscendo con un
messaggio in caso di errore (\texttt{\small 34--38}).
-Se (\texttt{\small 39}) il numero di byte letti \var{nread} è nullo si è in
+Se (\texttt{\small 39}) il numero di byte letti \var{nread} è nullo si è in
presenza del caso di un \textit{end-of-file}, indice che una connessione che
-si è chiusa, che deve essere trattato (\texttt{\small 39--48}) opportunamente.
-Il primo passo è chiudere (\texttt{\small 40}) anche il proprio capo del
+si è chiusa, che deve essere trattato (\texttt{\small 39--48}) opportunamente.
+Il primo passo è chiudere (\texttt{\small 40}) anche il proprio capo del
socket e rimuovere (\texttt{\small 41}) il file descriptor dalla tabella di
quelli aperti, inoltre occorre verificare (\texttt{\small 42}) se il file
-descriptor chiuso è quello con il valore più alto, nel qual caso occorre
+descriptor chiuso è quello con il valore più alto, nel qual caso occorre
trovare (\texttt{\small 42--46}) il nuovo massimo, altrimenti (\texttt{\small
- 47}) si può ripetere il ciclo da capo per esaminare (se ne restano)
+ 47}) si può ripetere il ciclo da capo per esaminare (se ne restano)
ulteriori file descriptor attivi.
-Se però è stato chiuso il file descriptor più alto, dato che la scansione dei
-file descriptor attivi viene fatta a partire dal valore più basso, questo
+Se però è stato chiuso il file descriptor più alto, dato che la scansione dei
+file descriptor attivi viene fatta a partire dal valore più basso, questo
significa che siamo anche arrivati alla fine della scansione, per questo
possiamo utilizzare direttamente il valore dell'indice \var{i} con un ciclo
all'indietro (\texttt{\small 43}) che trova il primo valore per cui la tabella
\code{break}, e rieseguire \func{select}.
Se infine si sono effettivamente letti dei dati dal socket (ultimo caso
-rimasto) si potrà invocare immediatamente (\texttt{\small 49})
+rimasto) si potrà invocare immediatamente (\texttt{\small 49})
\func{FullWrite} per riscriverli indietro sul socket stesso, avendo cura di
uscire con un messaggio in caso di errore (\texttt{\small 50--53}). Si noti
che nel ciclo si esegue una sola lettura, contrariamente a quanto fatto con la
precedente versione (si riveda il codice di fig.~\ref{fig:TCP_ServEcho_second})
in cui si continuava a leggere fintanto che non si riceveva un
-\textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si
+\textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si
vuole essere bloccati in lettura. L'uso di \func{select} ci permette di
-trattare automaticamente anche il caso in cui la \func{read} non è stata in
+trattare automaticamente anche il caso in cui la \func{read} non è stata in
grado di leggere tutti i dati presenti sul socket, dato che alla iterazione
-successiva \func{select} ritornerà immediatamente segnalando l'ulteriore
-disponibilità.
+successiva \func{select} ritornerà immediatamente segnalando l'ulteriore
+disponibilità.
-Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo
-\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}. Il problema è
+Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo
+\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}. Il problema è
che in caso di blocco di una qualunque delle funzioni di I/O, non avendo usato
-processi separati, tutto il server si ferma e non risponde più a nessuna
+processi separati, tutto il server si ferma e non risponde più a nessuna
richiesta. Abbiamo scongiurato questa evenienza per l'I/O in ingresso con
l'uso di \func{select}, ma non vale altrettanto per l'I/O in uscita. Il
-problema pertanto può sorgere qualora una delle chiamate a \func{write}
+problema pertanto può sorgere qualora una delle chiamate a \func{write}
effettuate da \func{FullWrite} si blocchi. Con il funzionamento normale questo
non accade in quanto il server si limita a scrivere quanto riceve in ingresso,
ma qualora venga utilizzato un client malevolo che esegua solo scritture e non
Le possibili soluzioni in questo caso sono quelle di ritornare ad eseguire il
ciclo di risposta alle richieste all'interno di processi separati, utilizzare
un timeout per le operazioni di scrittura, o eseguire queste ultime in
-modalità non bloccante, concludendo le operazioni qualora non vadano a buon
+modalità non bloccante, concludendo le operazioni qualora non vadano a buon
fine.
\label{sec:TCP_serv_poll}
Finora abbiamo trattato le problematiche risolubili con l'I/O multiplexing
-impiegando la funzione \func{select}; questo è quello che avviene nella
-maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare
-queste problematiche con i socket. Abbiamo però visto in
+impiegando la funzione \func{select}; questo è quello che avviene nella
+maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare
+queste problematiche con i socket. Abbiamo però visto in
sez.~\ref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo
delle limitazioni dovute all'uso dei \itindex{file~descriptor~set}
sez.~\ref{sec:TCP_urgent_data}) su un socket TCP vengono considerati
traffico prioritario e vengono rilevati da una condizione \const{POLLIN},
\const{POLLPRI} o \const{POLLRDBAND}.
-\item la chiusura di una connessione (cioè la ricezione di un segmento FIN)
+\item la chiusura di una connessione (cioè la ricezione di un segmento FIN)
viene considerato traffico normale, pertanto viene rilevato da una
condizione \const{POLLIN} o \const{POLLRDNORM}, ma una conseguente chiamata
- a \func{read} restituirà 0.
-\item la disponibilità di spazio sul socket per la scrittura di dati viene
+ a \func{read} restituirà 0.
+\item la disponibilità di spazio sul socket per la scrittura di dati viene
segnalata con una condizione \const{POLLOUT}.
\item quando uno dei due capi del socket chiude un suo lato della connessione
con \func{shutdown} si riceve una condizione di \const{POLLHUP}.
\item la presenza di un errore sul socket (sia dovuta ad un segmento RST che a
timeout) viene considerata traffico normale, ma viene segnalata anche dalla
condizione \const{POLLERR}.
-\item la presenza di una nuova connessione su un socket in ascolto può essere
+\item la presenza di una nuova connessione su un socket in ascolto può essere
considerata sia traffico normale che prioritario, nel caso di Linux
l'implementazione la classifica come normale.
\end{itemize}
\label{fig:TCP_PollEchod}
\end{figure}
-In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
-versione del server, la versione completa del codice è riportata nel file
+In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
+versione del server, la versione completa del codice è riportata nel file
\texttt{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella
figura si sono tralasciate la gestione delle opzioni, la creazione del socket
in ascolto, la cessione dei privilegi e le operazioni necessarie a far
programma.
Come per il precedente server basato su \func{select} il primo passo
-(\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato
+(\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato
che in questo caso dovremo usare un vettore di strutture occorre anzitutto
(\texttt{\small 2}) allocare la memoria necessaria utilizzando il numero
massimo \var{n} di socket osservabili, che viene impostato attraverso
l'opzione \texttt{-n} ed ha un valore di default di 256.
Dopo di che si preimposta (\texttt{\small 3}) il valore \var{max\_fd} del file
-descriptor aperto con valore più alto a quello del socket in ascolto (al
+descriptor aperto con valore più alto a quello del socket in ascolto (al
momento l'unico), e si provvede (\texttt{\small 4--7}) ad inizializzare le
strutture, disabilitando (\texttt{\small 5}) l'osservazione con un valore
negativo del campo \var{fd} ma predisponendo (\texttt{\small 6}) il campo
\var{events} per l'osservazione dei dati normali con \const{POLLRDNORM}.
Infine (\texttt{\small 8}) si attiva l'osservazione del socket in ascolto
inizializzando la corrispondente struttura. Questo metodo comporta, in
-modalità interattiva, lo spreco di tre strutture (quelle relative a standard
-input, output ed error) che non vengono mai utilizzate in quanto la prima è
+modalità interattiva, lo spreco di tre strutture (quelle relative a standard
+input, output ed error) che non vengono mai utilizzate in quanto la prima è
sempre quella relativa al socket in ascolto.
Una volta completata l'inizializzazione tutto il lavoro viene svolto
all'interno del ciclo principale \texttt{\small 10--55}) che ha una struttura
sostanzialmente identica a quello usato per il precedente esempio basato su
-\func{select}. La prima istruzione (\texttt{\small 11--12}) è quella di
+\func{select}. La prima istruzione (\texttt{\small 11--12}) è quella di
eseguire \func{poll} all'interno di un ciclo che la ripete qualora venisse
interrotta da un segnale, da cui si esce soltanto quando la funzione ritorna,
restituendo nella variabile \var{n} il numero di file descriptor trovati
13--16}) alla terminazione immediata del processo provvedendo a stampare una
descrizione dello stesso.
-Una volta ottenuta dell'attività su un file descriptor si hanno di nuovo due
-possibilità. La prima possibilità è che ci sia attività sul socket in ascolto,
+Una volta ottenuta dell'attività su un file descriptor si hanno di nuovo due
+possibilità. La prima possibilità è che ci sia attività sul socket in ascolto,
indice di una nuova connessione, nel qual caso si controlla (\texttt{\small
- 17}) se il campo \var{revents} della relativa struttura è attivo; se è così
+ 17}) se il campo \var{revents} della relativa struttura è attivo; se è così
si provvede (\texttt{\small 18}) a decrementare la variabile \var{n} (che
assume il significato di numero di file descriptor attivi rimasti da
controllare) per poi (\texttt{\small 19--23}) effettuare la chiamata ad
(\texttt{\small 24}) infine quando necessario il valore massimo dei file
descriptor aperti mantenuto in \var{max\_fd}.
-La seconda possibilità è che vi sia dell'attività su uno dei socket aperti in
+La seconda possibilità è che vi sia dell'attività su uno dei socket aperti in
precedenza, nel qual caso si inizializza (\texttt{\small 27}) l'indice \var{i}
del vettore delle strutture \struct{pollfd} al valore del socket in ascolto,
dato che gli ulteriori socket aperti avranno comunque un valore superiore. Il
ciclo (\texttt{\small 28--54}) prosegue fintanto che il numero di file
-descriptor attivi, mantenuto nella variabile \var{n}, è diverso da zero. Se
+descriptor attivi, mantenuto nella variabile \var{n}, è diverso da zero. Se
pertanto ci sono ancora socket attivi da individuare si comincia con
l'incrementare (\texttt{\small 30}) l'indice e controllare (\texttt{\small
31}) se corrisponde ad un file descriptor in uso analizzando il valore del
campo \var{fd} della relativa struttura e chiudendo immediatamente il ciclo
-qualora non lo sia. Se invece il file descriptor è in uso si verifica
-(\texttt{\small 31}) se c'è stata attività controllando il campo
+qualora non lo sia. Se invece il file descriptor è in uso si verifica
+(\texttt{\small 31}) se c'è stata attività controllando il campo
\var{revents}.
-Di nuovo se non si verifica la presenza di attività il ciclo si chiude subito,
-altrimenti si provvederà (\texttt{\small 32}) a decrementare il numero \var{n}
+Di nuovo se non si verifica la presenza di attività il ciclo si chiude subito,
+altrimenti si provvederà (\texttt{\small 32}) a decrementare il numero \var{n}
di file descriptor attivi da controllare e ad eseguire (\texttt{\small 33}) la
lettura, ed in caso di errore (\texttt{\small 34--37}) al solito lo si
-notificherà uscendo immediatamente. Qualora invece si ottenga una condizione
-di end-of-file (\texttt{\small 38--47}) si provvederà a chiudere
+notificherà uscendo immediatamente. Qualora invece si ottenga una condizione
+di end-of-file (\texttt{\small 38--47}) si provvederà a chiudere
(\texttt{\small 39}) anche il nostro capo del socket e a marcarlo
(\texttt{\small 40}) nella struttura ad esso associata come inutilizzato.
-Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo
-valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il
-ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro
+Infine dovrà essere ricalcolato (\texttt{\small 41--45}) un eventuale nuovo
+valore di \var{max\_fd}. L'ultimo passo è (\texttt{\small 46}) chiudere il
+ciclo in quanto in questo caso non c'è più niente da riscrivere all'indietro
sul socket.
Se invece si sono letti dei dati si provvede (\texttt{\small 48}) ad
effettuarne la riscrittura all'indietro, con il solito controllo ed eventuale
uscita e notifica in caso si errore (\texttt{\small 49--52}).
-Come si può notare la logica del programma è identica a quella vista in
+Come si può notare la logica del programma è identica a quella vista in
fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select};
-la sola differenza significativa è che in questo caso non c'è bisogno di
+la sola differenza significativa è che in questo caso non c'è bisogno di
rigenerare i \itindex{file~descriptor~set} \textit{file descriptor set} in
-quanto l'uscita è indipendente dai dati in ingresso. Si applicano comunque
+quanto l'uscita è indipendente dai dati in ingresso. Si applicano comunque
anche a questo server le considerazioni finali di
sez.~\ref{sec:TCP_serv_select}.
quello dei \textit{thread}, alternativo al modello classico dei processi,
tipico di Unix. Ne esamineremo le caratteristiche, vantaggi e svantaggi, e le
diverse realizzazioni che sono disponibili per Linux; nella seconda parte
-tratteremo in dettaglio quella che è l'implementazione principale, che fa
+tratteremo in dettaglio quella che è l'implementazione principale, che fa
riferimento all'interfaccia standardizzata da POSIX.1e.
\label{sec:thread_intro}
Questa prima sezione costituisce una introduzione ai \textit{thread} e
-tratterà i concetti principali del relativo modello di programmazione,
+tratterà i concetti principali del relativo modello di programmazione,
esamineremo anche quali modelli sono disponibili per Linux, dando una breve
panoramica sulle implementazioni alternative.
% http://www.humanfactor.com/pthreads/
Il modello classico dell'esecuzione dei programmi nei sistemi Unix, illustrato
-in sez.~\ref{cha:process_interface}, è fondato sui processi. Il modello nasce
-per assicurare la massima stabilità al sistema e prevede una rigida
+in sez.~\ref{cha:process_interface}, è fondato sui processi. Il modello nasce
+per assicurare la massima stabilità al sistema e prevede una rigida
separazione fra i diversi processi, in modo che questi non possano disturbarsi
a vicenda.
-Le applicazioni moderne però sono altamente concorrenti, e necessitano quindi
+Le applicazioni moderne però sono altamente concorrenti, e necessitano quindi
di un gran numero di processi; questo ha portato a scontrarsi con alcuni
limiti dell'architettura precedente. In genere i fautori del modello di
programmazione a \texttt{thread} sottolineano due problemi connessi all'uso
Tratteremo in questa sezione l'interfaccia di programmazione con i
-\textit{thread} standardizzata dallo standard POSIX 1.c, che è quella che è
+\textit{thread} standardizzata dallo standard POSIX 1.c, che è quella che è
stata seguita anche dalle varie implementazioni dei \textit{thread} realizzate
-su Linux, ed in particolare dalla \textit{Native Thread Posix Library} che è
+su Linux, ed in particolare dalla \textit{Native Thread Posix Library} che è
stata integrata con i kernel della serie 2.6 e che fa parte a pieno titolo
delle \acr{glibc}.
In questa appendice tratteremo i vari protocolli relativi al livello di
trasporto.\footnote{al solito per la definizione dei livelli si faccia
riferimento alle spiegazioni fornite in sez.~\ref{sec:net_protocols}.} In
-particolare gran parte del capitolo sarà dedicato al più importante di questi,
-il TCP, che è pure il più complesso ed utilizzato su internet.
+particolare gran parte del capitolo sarà dedicato al più importante di questi,
+il TCP, che è pure il più complesso ed utilizzato su internet.
\section{Il protocollo TCP}
\label{sec:tcp_protocol}
In questa sezione prenderemo in esame i vari aspetti del protocollo TCP, il
-protocollo più comunemente usato dalle applicazioni di rete.
+protocollo più comunemente usato dalle applicazioni di rete.
\subsection{Gli stati del TCP}
\label{sec:TCP_states}
-In sez.~\ref{sec:TCP_connession} abbiamo descritto in dettaglio le modalità con
+In sez.~\ref{sec:TCP_connession} abbiamo descritto in dettaglio le modalità con
cui il protocollo TCP avvia e conclude una connessione, ed abbiamo accennato
alla presenza dei vari stati del protocollo. In generale infatti il
funzionamento del protocollo segue una serie di regole, che possono essere
riassunte nel comportamento di una macchina a stati, il cui diagramma di
-transizione è riportato in fig.~\ref{fig:TCP_state_diag}.
+transizione è riportato in fig.~\ref{fig:TCP_state_diag}.
\begin{figure}[htb]
\label{sec:udp_protocol}
In questa sezione prenderemo in esame i vari aspetti del protocollo UDP, che
-dopo il TCP è il protocollo più usato dalle applicazioni di rete.
+dopo il TCP è il protocollo più usato dalle applicazioni di rete.
\begin{figure}[htb]
projects / gapil.git / commitdiff