%% prochand.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
ambiente multitasking.
-\section{Le funzioni di base}% della gestione dei processi}
+\section{Le funzioni di base della gestione dei processi}
\label{sec:proc_handling}
In questa sezione tratteremo le problematiche della gestione dei processi
caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
che qualunque processo può a sua volta generarne altri. 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.
+\itindex{Process~ID~(PID)} \textit{Process ID} o, più brevemente, \ids{PID},
+assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid}) quando il
+processo viene creato.
Una seconda caratteristica di un sistema unix-like è che la generazione di un
processo è un'operazione separata rispetto al lancio di un programma. In
di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} 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
+processo lanciato dal sistema ha sempre il \ids{PID} uguale a 1 e non è figlio
di nessun altro processo.
Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
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
posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
- parametro di avvio del kernel, l'argomento è di natura amministrativa e
+ parametro di avvio del kernel, l'argomento è di natura sistemistica e
trattato in sez.~5.3 di \cite{AGL}.}
\begin{figure}[!htb]
del tutto vero, in Linux, specialmente nelle versioni più recenti del
kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
- \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
+ \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
non rientrano in questa classificazione.}
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
\itindex{process~table} \textit{process table}. Per ciascun processo viene
mantenuta una voce in questa tabella, costituita da una struttura
-\struct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
+\kstruct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
processo. Tutte le strutture usate a questo scopo sono dichiarate
nell'\textit{header file} \file{linux/sched.h}, ed uno schema semplificato,
che riporta la struttura delle principali informazioni contenute nella
Come accennato nella sezione precedente ogni processo viene identificato dal
sistema da un numero identificativo univoco, il \textit{process ID} o
-\acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
-intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
+\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
+intero con segno (nel caso di Linux e della \acr{glibc} il tipo usato è
\ctyp{int}).
-Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
+Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
processo viene creato,\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}, \acr{pgid} o \acr{sid} (vedi
+ sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi
sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
-tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16
+tradizionalmente il \ids{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ù basso disponibile a partire da un minimo di
300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
\const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
- \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
+ \textit{thread} anche il meccanismo di allocazione dei \ids{PID} è stato
modificato ed il valore massimo è impostabile attraverso il file
- \procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
+ \sysctlfile{kernel/pid\_max} e di default vale 32768.} che serve a
+riservare i \ids{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.
+avvio (\cmd{init}) ha sempre il \ids{PID} uguale a uno.
-Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
-sono stati creati, questo viene chiamato in genere \acr{ppid} (da
-\textit{parent process ID}). Questi due identificativi possono essere
-ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
-prototipi sono:
+Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
+sono stati creati, questo viene chiamato in genere \ids{PPID} (da
+\itindex{Parent~Process~ID~(PPID)} \textit{Parent Process ID}). Questi due
+identificativi possono essere ottenuti usando le due funzioni di sistema
+\funcd{getpid} e \funcd{getppid}, i cui prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{unistd.h}
\fdecl{pid\_t getpid(void)}
-\fdesc{Restituisce il \acr{pid} del processo corrente..}
+\fdesc{Restituisce il \ids{PID} del processo corrente..}
\fdecl{pid\_t getppid(void)}
-\fdesc{Restituisce il \acr{pid} del padre del processo corrente.}
+\fdesc{Restituisce il \ids{PID} del padre del processo corrente.}
}
{Entrambe le funzioni non riportano condizioni di errore.}
\end{funcproto}
\noindent esempi dell'uso di queste funzioni sono riportati in
-fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
+fig.~\ref{fig:proc_fork_code}, nel programma \file{fork\_test.c}.
-Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
+Il fatto che il \ids{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
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. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti
-è univoco solo fintanto che un processo è attivo, una volta terminato esso
-potrà essere riutilizzato da un processo completamente diverso, e di questo
-bisogna essere ben consapevoli.
+\ids{PID} per generare un \textit{pathname} univoco, che non potrà essere
+replicato da un altro processo che usi la stessa funzione. Questo utilizzo
+però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto
+che un processo è attivo, una volta terminato esso potrà essere riutilizzato
+da un processo completamente diverso, e di questo bisogna essere ben
+consapevoli.
Tutti i processi figli dello stesso processo padre sono detti
\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
un processo e le varie relazioni fra processi utilizzate per definire una
sessione.
-Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
+Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in
sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
processo vengono associati degli ulteriori identificatori ed in particolare
quelli che vengono usati per il controllo di accesso. Questi servono per
\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
+La funzione di sistema \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
\textit{system call} usata da Linux per creare nuovi processi è \func{clone}
- (vedi \ref{sec:process_clone}), anche perché a partire dalle \acr{glibc}
+ (vedi \ref{sec:process_clone}), anche perché a partire dalla \acr{glibc}
2.3.3 non viene più usata la \textit{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
\fdecl{pid\_t fork(void)}
\fdesc{Crea un nuovo processo.}
}
-{La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso
+{La funzione ritorna il \ids{PID} del figlio al padre e $0$ al figlio in caso
di successo e $-1$ al padre senza creare il figlio per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
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
+ritorno della funzione \func{fork} è il \ids{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
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
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 \ids{PID} può sempre essere ottenuto con
\func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
-valore nullo, che non è il \acr{pid} di nessun processo.
+valore nullo, che non è il \ids{PID} di nessun processo.
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
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/ForkTest.c}
+ \includecodesample{listati/fork_test.c}
\end{minipage}
\normalsize
- \caption{Esempio di codice per la creazione di nuovi processi.}
+ \caption{Esempio di codice per la creazione di nuovi processi (da
+ \file{fork\_test.c}).}
\label{fig:proc_fork_code}
\end{figure}
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{fork\_test.c},
distribuito insieme agli altri sorgenti degli esempi su
\url{http://gapil.truelite.it/gapil_source.tgz}.
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
+\ids{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)
Un secondo aspetto molto importante nella creazione dei processi figli è
quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
se buona parte dei concetti relativi ai file verranno trattati più avanti
-(principalmente nel cap.~\ref{cha:file_unix_interface}). Per illustrare meglio
+(principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
quello che avviene si può redirigere su un file l'output del programma di
test, quello che otterremo è:
\begin{Command}
che come si vede è completamente diverso da quanto ottenevamo sul terminale.
Il comportamento delle varie funzioni di interfaccia con i file è analizzato
-in gran dettaglio in cap.~\ref{cha:file_unix_interface} per l'interfaccia
-nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione
+in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
+nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
adottata nelle librerie del linguaggio C e valida per qualunque sistema
operativo. Qui basta accennare che si sono usate le funzioni standard della
libreria del C che prevedono l'output bufferizzato. Il punto è che questa
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
solo processi diversi possono scrivere in contemporanea sullo stesso file
-(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 in memoria, la posizione corrente sul file è condivisa fra il
-padre e tutti i processi figli.
+(l'argomento dell'accesso concorrente ai file è trattato in dettaglio in
+sez.~\ref{sec:file_shared_access}), ma anche che, a differenza di quanto
+avviene per le variabili in memoria, la posizione corrente sul file è
+condivisa fra il padre e tutti i processi figli.
Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
così il file su cui un programma scrive i suoi dati in uscita, tratteremo
- l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
+ l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} 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 \textit{file descriptor} (vedi sez.~\ref{sec:file_fd})
dei file 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} (tratteremo in dettagli questi termini in
-sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file.
+ table} (tratteremo in dettaglio questi termini in
+sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione corrente nel
+file.
In questo modo se un processo scrive su un file aggiornerà la posizione
corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
\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
- sez.~\ref{sec:file_fcntl});
+ sez.~\ref{sec:file_fcntl_ioctl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
\item gli identificatori per il controllo di sessione: il
\itindex{process~group} \textit{process group-ID} e il \textit{session id}
ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
-\item la directory di lavoro e la directory radice (vedi
- sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
+\item la \index{directory~di~lavoro} directory di lavoro e la directory radice
+ (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
-\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
+\item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad
un nuovo valore univoco;
-\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
- impostato al \acr{pid} del padre;
+\item il \ids{PPID} (\textit{parent process id}), quello del figlio viene
+ impostato al \ids{PID} del padre;
\item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
sono posti a zero;
\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
+\funcm{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
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 i \textit{file stream} e
-poi esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente
-alla chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
+esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
+esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
+chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
direttamente alle operazioni di terminazione del processo da parte del kernel.
Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
-valore di ritorno per \func{main}. Ma se il processo viene concluso in
+valore di ritorno per \code{main}. Ma se il processo viene concluso in
maniera anomala 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.
\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
+venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID} 1,
cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
per questo motivo ha un ruolo essenziale nel sistema e non può mai
fatale.}
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 verrà sostituito dal kernel con il \acr{pid} di
+padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID}
+di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di
\cmd{init}, 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.
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
-in precedenza, essi riportano 1 come \acr{ppid}.
+in precedenza, essi riportano 1 come \ids{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
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
+memorizzando alcuni dati essenziali, come il \ids{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.
Si è già sottolineato al paragrafo precedente come in questo caso diventi
necessario gestire esplicitamente la conclusione dei figli onde evitare di
riempire di \itindex{zombie} \textit{zombie} la tabella dei
-processi. Tratteremo in questa sezione le funzioni deputate a questo compito;
-la prima è \funcd{wait} ed il suo prototipo è:
+processi. Tratteremo in questa sezione le funzioni di sistema deputate a
+questo compito; la prima è \funcd{wait} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fdecl{pid\_t wait(int *status)}
\fdesc{Attende la terminazione di un processo.}
}
-{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
+{La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
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 della funzione sarà impostato
-al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
+al \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa
che permette di identificare qual è il figlio che è terminato.
\itindend{termination~status}
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,
- \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
-\funcd{waitpid}, il cui prototipo è:
+ \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione di
+sistema, \funcd{waitpid}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
\fdesc{Attende il cambiamento di stato di un processo figlio.}
}
-{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
+{La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso
di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
assumerà uno dei valori:
\begin{errlist}
- \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{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
\itindex{process~group} \textit{process 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 \ids{PID} è uguale
al valore di \param{pid}.\\
\hline
\end{tabular}
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. In tal caso la funzione,
-invece di restituire il \acr{pid} del processo (che è sempre un intero
+invece di restituire il \ids{PID} del processo (che è sempre un intero
positivo) ritornerà un valore nullo.
Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
-Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
+Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID},
quando un processo figlio entra nello stato \textit{stopped}\footnote{in
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
indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene
ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
attendono la terminazione di un processo figlio e ritornano il relativo
-\acr{pid} e lo stato di terminazione nell'argomento \param{status}.
+\ids{PID} e lo stato di terminazione nell'argomento \param{status}.
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
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
- figlio che sia terminato normalmente. \\
- \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
- stato di uscita del processo (passato attraverso
- \func{\_exit}, \func{exit} o come valore di
- ritorno di \func{main}); può essere valutata solo
- se \val{WIFEXITED} ha restituito un valore non
- nullo.\\
- \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
- in maniera anomala a causa di un segnale che non
- è stato catturato (vedi
- sez.~\ref{sec:sig_notification}).\\
- \macro{WTERMSIG(s)} & Restituisce il numero del segnale che ha causato
- la terminazione anomala del processo; può essere
- valutata solo se \val{WIFSIGNALED} ha restituito
- un valore non nullo.\\
- \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
- file di \itindex{core~dump} \textit{core
- dump}; può essere valutata solo se
- \val{WIFSIGNALED} ha restituito un valore non
- nullo.\footnotemark \\
- \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
- \func{waitpid} è bloccato; l'uso è possibile solo
- con \func{waitpid} avendo specificato l'opzione
- \const{WUNTRACED}.\\
- \macro{WSTOPSIG(s)} & Restituisce il numero del segnale che ha bloccato
- il processo; può essere valutata solo se
- \val{WIFSTOPPED} ha restituito un valore non
- nullo. \\
- \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
- stato riavviato da un \signal{SIGCONT}
- (disponibile solo a partire dal kernel 2.6.10).\\
+ \macro{WIFEXITED}\texttt{(s)} & Condizione vera (valore non nullo) per
+ un processo figlio che sia terminato
+ normalmente. \\
+ \macro{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
+ significativi dello stato di uscita del
+ processo (passato attraverso
+ \func{\_exit}, \func{exit} o come valore
+ di ritorno di \code{main}); può essere
+ valutata solo se \val{WIFEXITED} ha
+ restituito un valore non nullo.\\
+ \macro{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
+ terminato in maniera anomala a causa di
+ un segnale che non è stato catturato
+ (vedi sez.~\ref{sec:sig_notification}).\\
+ \macro{WTERMSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
+ causato la terminazione anomala del
+ processo; può essere valutata solo se
+ \val{WIFSIGNALED} ha restituito un
+ valore non nullo.\\
+ \macro{WCOREDUMP}\texttt{(s)} & Vera se il processo terminato ha
+ generato un file di \itindex{core~dump}
+ \textit{core dump}; può essere valutata
+ solo se \val{WIFSIGNALED} ha restituito
+ un valore non nullo.\footnotemark \\
+ \macro{WIFSTOPPED}\texttt{(s)} & Vera se il processo che ha causato il
+ ritorno di \func{waitpid} è bloccato;
+ l'uso è possibile solo con
+ \func{waitpid} avendo specificato
+ l'opzione \const{WUNTRACED}.\\
+ \macro{WSTOPSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
+ bloccato il processo; può essere
+ valutata solo se \val{WIFSTOPPED} ha
+ restituito un valore non nullo. \\
+ \macro{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
+ ritorno è stato riavviato da un
+ \signal{SIGCONT} (disponibile solo a
+ partire dal kernel 2.6.10).\\
\hline
\end{tabular}
\caption{Descrizione delle varie macro di preprocessore utilizzabili per
Si tenga conto che nel caso di conclusione anomala il valore restituito da
\val{WTERMSIG} può essere confrontato con le costanti che identificano i
-segnali definite in \file{signal.h} ed elencate in
+segnali definite in \headfile{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, è
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 è:
+figli e più dettagli sullo stato di uscita; la funzione di sistema è
+\funcd{waitid} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \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{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
\hline
\hline
\const{P\_PID} & Indica la richiesta di attendere per un processo figlio
- il cui \acr{pid} corrisponda al valore dell'argomento
+ il cui \ids{PID} corrisponda al valore dell'argomento
\param{id}.\\
\const{P\_PGID}& Indica la richiesta di attendere per un processo figlio
appartenente al \textit{process group} (vedi
basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
campi:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\var{si\_pid}] con il \acr{pid} del figlio.
-\item[\var{si\_uid}] con l'user-ID reale (vedi sez.~\ref{sec:proc_perms}) del
- figlio.
+\item[\var{si\_pid}] con il \ids{PID} del figlio.
+\item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
+ sez.~\ref{sec:proc_perms}) del figlio.
\item[\var{si\_signo}] con \signal{SIGCHLD}.
\item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
lo ha terminato, fermato o riavviato.
precedenti ma che prevedono un ulteriore argomento attraverso il quale il
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:
+Le due funzioni di sistema sono \funcd{wait3} e \funcd{wait4}, che diventano
+accessibili definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
per i valori dei primi tre argomenti, ma in più restituisce nell'argomento
aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo
argomento è una struttura di tipo \struct{rusage} definita in
-\file{sys/resource.h}, che viene utilizzata anche dalla funzione
+\headfile{sys/resource.h}, che viene utilizzata anche dalla funzione
\func{getrusage} per ottenere le risorse di sistema usate da un processo. La
sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne
tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La
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
+nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
creato un nuovo processo, la funzione semplicemente rimpiazza lo
\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il
\index{segmento!testo} testo del processo corrente con un nuovo programma
\item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono
eseguibili, o il file è su un filesystem montato con l'opzione
\cmd{noexec}, o manca il permesso di attraversamento di una delle
- directory del pathname.
- \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene
- tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}.
+ directory del \textit{pathname}.
+ \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
+ riconoscibile.
\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{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
+ \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene
+ tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}.
\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
- interprete.
- \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
- riconoscibile.
\item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
\end{errlist}
- ed inoltre \errval{EFAULT}, \errval{ENOMEM},
- \errval{EIO}, \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR},
- \errval{EISDIR}, \errval{ENFILE}, \errval{EMFILE} nel loro significato
- generico.
-}
+ ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{EISDIR}, \errval{ELOOP},
+ \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM},
+ \errval{ENOTDIR} nel loro significato generico. }
\end{funcproto}
La funzione \func{execve} esegue il programma o lo script indicato dal
-pathname \param{filename}, passandogli la lista di argomenti indicata
+\textit{pathname} \param{filename}, passandogli la lista di argomenti indicata
da \param{argv} 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
-\code{main(int argc, char *argv[], char *envp[])}.
+nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
+\code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
+passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
+torneremo in sez.~\ref{sec:sys_res_limits}).
+% TODO aggiungere la parte sul numero massimo di argomenti, da man execve
In caso di successo la funzione non ritorna, in quanto al posto del programma
chiamante viene eseguito il nuovo programma indicato da \param{filename}. Se
\fdecl{int execvp(const char *file, char *const argv[])}
\fdesc{Eseguono un programma.}
}
-{Le funzioni ritorna solo in caso di errore, restituendo $-1$, i codici di
+{Le funzioni ritornano solo in caso di errore, restituendo $-1$, i codici di
errore sono gli stessi di \func{execve}.
}
\end{funcproto}
La prima differenza fra le funzioni 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
+valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
e \textit{list}.
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.
-
\begin{figure}[!htb]
- \centering \includegraphics[width=12cm]{img/exec_rel}
+ \centering \includegraphics[width=10cm]{img/exec_rel}
\caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
\label{fig:proc_exec_relat}
\end{figure}
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
+di directory specificate dalla variabile di ambiente \envvar{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
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
+proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
+se non viene trovato nessun altro file viene finalmente restituito
\errcode{EACCES}. Le altre quattro funzioni si limitano invece a cercare di
eseguire il file indicato dall'argomento \param{path}, che viene interpretato
-come il \itindex{pathname} \textit{pathname} del programma.
+come il \textit{pathname} del programma.
La terza differenza è come viene passata la lista delle variabili di ambiente.
Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
l'ambiente.
-Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da una
+Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una
delle funzioni della famiglia \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 il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
+ (\ids{PPID});
\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item la directory radice e la directory di lavoro corrente (vedi
- sez.~\ref{sec:file_work_dir});
+\item la directory radice e la \index{directory~di~lavoro} directory di lavoro
+ corrente (vedi sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
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 sez.~\ref{sec:file_fcntl}) per ciascun
+\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun
\textit{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
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
-collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
-collegati con le \acr{glibc}.
+collegati con la \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
+collegati con la \acr{glibc}.
Infine nel caso il programma che si vuole eseguire sia uno script e non un
binario, questo deve essere un file di testo che deve iniziare con una linea
nella forma:
\begin{Example}
-\#!/path/to/interpreter [argomenti]
+#!/path/to/interpreter [argomenti]
\end{Example}
dove l'interprete indicato deve essere un eseguibile binario e non un altro
script, che verrà chiamato come se si fosse eseguito il comando
vari controlli di accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
-identificatori univoci, lo \textsl{user-ID} (abbreviato in \acr{uid}) ed il
-\textsl{group-ID} (abbreviato in \acr{gid}). 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
-esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file
-vengano associati un utente ed un gruppo (i suoi \textsl{proprietari},
-indicati appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati
-dal kernel nella gestione dei permessi di accesso.
+identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID}
+(abbreviato in \ids{UID}) ed il \itindex{Group~ID~(PID)} \textsl{Group-ID}
+(abbreviato in \ids{GID}). 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 esempio in
+sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati
+un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite
+un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella
+gestione dei permessi di accesso.
Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
+ \begin{tabular}[c]{|c|c|l|p{7cm}|}
\hline
\textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
& \textbf{Significato} \\
\hline
\hline
- \acr{uid} & \textit{real} & \textsl{user-ID reale}
- & Indica l'utente che ha lanciato il programma.\\
- \acr{gid} & '' &\textsl{group-ID reale}
- & Indica il gruppo principale dell'utente che ha lanciato
- il programma.\\
+ \texttt{uid} & \textit{real} & \textsl{user-ID reale}
+ & Indica l'utente che ha lanciato il programma.\\
+ \texttt{gid} & '' &\textsl{group-ID reale}
+ & Indica il gruppo principale dell'utente che ha lanciato
+ il programma.\\
\hline
- \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
- & Indica l'utente usato nel controllo di accesso.\\
- \acr{egid} & '' & \textsl{group-ID effettivo}
- & Indica il gruppo usato nel controllo di accesso.\\
- -- & -- & \textsl{group-ID supplementari}
- & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
+ \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo}
+ & Indica l'utente usato nel controllo di accesso.\\
+ \texttt{egid}& '' & \textsl{group-ID effettivo}
+ & Indica il gruppo usato nel controllo di accesso.\\
+ -- & -- & \textsl{group-ID supplementari}
+ & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
\hline
- -- & \textit{saved} & \textsl{user-ID salvato}
- & È una copia dell'\acr{euid} iniziale.\\
- -- & '' & \textsl{group-ID salvato}
- & È una copia dell'\acr{egid} iniziale.\\
+ -- & \textit{saved} & \textsl{user-ID salvato}
+ & Mantiene una copia dell'\acr{euid} iniziale.\\
+ -- & '' & \textsl{group-ID salvato}
+ & Mantiene 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. \\
- \acr{fsgid} & '' & \textsl{group-ID di filesystem}
- & Indica il gruppo effettivo per l'accesso al filesystem.\\
+ \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem}
+ & Indica l'utente effettivo per l'accesso al filesystem. \\
+ \texttt{fsgid}& '' & \textsl{group-ID di filesystem}
+ & Indica il gruppo effettivo per l'accesso al filesystem.\\
\hline
\end{tabular}
\caption{Identificatori di utente e gruppo associati a ciascun processo con
\label{tab:proc_uid_gid}
\end{table}
-Al primo gruppo appartengono l'\acr{uid} \textsl{reale} ed il \acr{gid}
+Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID}
\textsl{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
imposta questi identificatori ai valori corrispondenti all'utente che entra
nel sistema.
-Al secondo gruppo appartengono l'\acr{uid} \textsl{effettivo} e il \acr{gid}
-\textsl{effettivo}, a cui si aggiungono gli eventuali \acr{gid}
+Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID}
+\textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID}
\textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono
invece gli identificatori usati nelle verifiche dei permessi del processo e
per il controllo di accesso ai file (argomento affrontato in dettaglio in
cui ci sia questa necessità, di dare a qualunque utente i privilegi o i
permessi di un altro, compreso l'amministratore.
-Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
+Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
identificatori possono essere ottenuti da un programma attraverso altrettante
-funzioni di lettura, queste sono \funcd{getuid}, \funcd{geteuid},
-\funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
+funzioni di sistema dedicate alla loro lettura, queste sono \funcd{getuid},
+\funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{uid\_t getuid(void)}
-\fdesc{Legge l'\textsl{user-ID reale} del processo corrente.}
+\fdesc{Legge l'\ids{UID} reale del processo corrente.}
\fdecl{uid\_t geteuid(void)}
-\fdesc{Legge l'\textsl{user-ID effettivo} del processo corrente.}
+\fdesc{Legge l'\ids{UID} effettivo del processo corrente.}
\fdecl{gid\_t getgid(void)}
-\fdesc{Legge il \textsl{group-ID reale} del processo corrente.}
+\fdesc{Legge il \ids{GID} reale del processo corrente.}
\fdecl{gid\_t getegid(void)}
-\fdesc{Legge il \textsl{group-ID effettivo} del processo corrente.}
+\fdesc{Legge il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano i rispettivi identificativi del processo corrente, e
non sono previste condizioni di errore.}
\end{funcproto}
-In generale l'uso di privilegi superiori, ottenibile con un \acr{uid}
+In generale l'uso di privilegi superiori, ottenibile con un \ids{UID}
\textsl{effettivo} diverso da quello reale, 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
migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo
che consente di accedere ai file via rete).
-L'\acr{uid} \textsl{salvato} ed il \acr{gid} \textsl{salvato} sono copie
-dell'\acr{uid} \textsl{effettivo} e del \acr{gid} \textsl{effettivo} del
+L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie
+dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del
processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
-processo, come copie dell'\acr{uid} \textsl{effettivo} e del \acr{gid}
+processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
\textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
eventuali \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi
quindi consentono di tenere traccia di quale fossero utente e gruppo effettivi
all'inizio dell'esecuzione di un nuovo programma.
-L'\acr{uid} \textsl{di filesystem} e il \acr{gid} \textsl{di filesystem} sono
+L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
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
\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è
-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
-prevede l'esistenza dell'\textit{user-ID salvato} e del \textit{group-ID
- salvato}; i loro prototipi sono:
+Le funzioni di sistema più comuni che vengono usate per cambiare identità
+(cioè utente e gruppo di appartenenza) ad un processo, e che come accennato in
+sez.~\ref{sec:proc_access_id} seguono la semantica POSIX che prevede
+l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato, sono
+rispettivamente \funcd{setuid} e \funcd{setgid}; i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setuid(uid\_t uid)}
-\fdesc{Imposta l'\acr{uid} del processo corrente.}
+\fdesc{Imposta l'\ids{UID} del processo corrente.}
\fdecl{int setgid(gid\_t gid)}
-\fdesc{Imposta il \acr{gid} del processo corrente.}
+\fdesc{Imposta il \ids{GID} del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
-caso \var{errno} può assumere solo il valore \errval{EPERM}.
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
}
\end{funcproto}
Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima, la seconda si comporta esattamente allo stesso modo facendo
-riferimento al \acr{gid} invece che all'\acr{uid}. Gli eventuali \acr{gid}
+riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
supplementari non vengono modificati.
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\acr{uid} effettivo è zero (cioè è quello dell'amministratore di sistema)
+l'\ids{UID} 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'\acr{uid} effettivo, e soltanto se il valore
-specificato corrisponde o all'\acr{uid} reale o all'\acr{uid} salvato. Negli
+altrimenti viene impostato solo l'\ids{UID} effettivo, e soltanto se il valore
+specificato corrisponde o all'\ids{UID} reale o all'\ids{UID} salvato. Negli
altri casi viene segnalato un errore con \errcode{EPERM}.
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'\acr{uid} effettivo a quello
+sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
dell'utente che ha lanciato il programma, effettuare il lavoro che non
necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
situazione degli identificatori è la seguente:
\begin{eqnarray*}
\label{eq:1}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
in tal caso infatti la situazione degli identificatori sarebbe:
\begin{eqnarray*}
\label{eq:2}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
- \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
-e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
+e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
funzione avrà successo e riporterà la situazione a:
\begin{eqnarray*}
\label{eq:3}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
processo, rendendo impossibile riguadagnare i privilegi di amministratore.
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
+l'\ids{UID} effettivo del processo per cedere i privilegi occorre
ricorrere ad altre funzioni.
-Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
-supportando (almeno fino alla versione 4.3+BSD) gli identificatori del gruppo
-\textit{saved}, le usa per poter scambiare fra di loro \textit{effective} e
-\textit{real}; i rispettivi prototipi sono:
+Le due funzioni di sistema \funcd{setreuid} e \funcd{setregid} derivano da BSD
+che, non supportando (almeno fino alla versione 4.3+BSD) gli identificatori
+del gruppo \textit{saved}, le usa per poter scambiare fra di loro
+\textit{effective} e \textit{real}; i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
-\fdesc{Imposta \acr{uid} reale e \acr{uid} effettivo del processo corrente.}
+\fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.}
\fdecl{int setregid(gid\_t rgid, gid\_t egid)}
-\fdesc{Imposta \acr{gid} reale e \acr{gid} effettivo del processo corrente.}
+\fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
-caso \var{errno} può assumere solo il valore \errval{EPERM}.
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
}
\end{funcproto}
Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
-\acr{uid} si applica alla seconda per i \acr{gid}. La funzione
-\func{setreuid} imposta rispettivamente l'\acr{uid} reale e l'\acr{uid}
+\ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
effettivo del processo corrente ai valori specificati da \param{ruid}
e \param{euid}. I processi non privilegiati possono impostare solo valori che
-corrispondano o al loro \acr{uid} effettivo o a quello reale o a quello
+corrispondano o al loro \ids{UID} effettivo o a quello reale o a quello
salvato, 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à lasciato
inalterato.
-Con queste funzioni si possono scambiare fra loro gli \acr{uid} reale ed
+Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
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, una volta eseguito il lavoro non privilegiato, con
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 \acr{uid} reale privilegiato, che dovrà
+questo caso infatti essi avranno un \ids{UID} 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
-prima della \func{exec} per uniformare l'\acr{uid} reale a quello effettivo,
+prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
uno scambio e riottenere dei privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
-si pone anche per l'\acr{uid} salvato. Ma la funzione \func{setreuid} deriva
+si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
da un'implementazione di sistema che 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'\acr{uid} reale corrente, l'\acr{uid} salvato viene
-automaticamente uniformato al valore dell'\acr{uid} effettivo.
+diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
+automaticamente uniformato al valore dell'\ids{UID} effettivo.
-Altre due funzioni, \funcd{seteuid} e \funcd{setegid}, sono un'estensione
-dello standard POSIX.1, ma sono comunque supportate dalla maggior parte degli
-Unix, esse vengono usate per cambiare gli identificatori del gruppo
-\textit{effective} ed i loro prototipi sono:
+Altre due funzioni di sistema, \funcd{seteuid} e \funcd{setegid}, sono
+un'estensione dello standard POSIX.1, ma sono comunque supportate dalla
+maggior parte degli Unix, esse vengono usate per cambiare gli identificatori
+del gruppo \textit{effective} ed i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int seteuid(uid\_t uid)}
-\fdesc{Imposta l'\acr{uid} effettivo del processo corrente.}
+\fdesc{Imposta l'\ids{UID} effettivo del processo corrente.}
\fdecl{int setegid(gid\_t gid)}
-\fdesc{Imposta il \acr{gid} effettivo del processo corrente.}
+\fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
-caso \var{errno} può assumere solo il valore \errval{EPERM}.
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
}
\end{funcproto}
Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
-riguardo gli \acr{uid} si applica allo stesso modo alla seconda per i
-\acr{gid}. Con \func{seteuid} gli utenti normali possono impostare l'\acr{uid}
-effettivo solo al valore dell'\acr{uid} reale o dell'\acr{uid} salvato,
+riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
+\ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
+effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
l'amministratore può specificare qualunque valore. Queste funzioni sono usate
-per permettere all'amministratore di impostare solo l'\acr{uid} effettivo,
+per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
identificatori.
-Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono invece
+Le due funzioni di sistema \funcd{setresuid} e \funcd{setresgid} sono invece
un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono
un completo controllo su tutti e tre i gruppi di identificatori
(\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono:
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
-\fdesc{Imposta l'\acr{uid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.}
\fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
-\fdesc{Imposta il \acr{gid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
-caso \var{errno} può assumere solo il valore \errval{EPERM}.
+caso \var{errno} può assumere solo il valore \errcode{EPERM}.
}
\end{funcproto}
Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
-gli \acr{uid} si applica alla seconda per i \acr{gid}. La funzione
-\func{setresuid} imposta l'\acr{uid} reale, l'\acr{uid} effettivo e
-l'\acr{uid} salvato del processo corrente ai valori specificati
+gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
+l'\ids{UID} salvato del processo corrente ai valori specificati
rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
-processi non privilegiati possono cambiare uno qualunque degli\acr{uid} solo
-ad un valore corrispondente o all'\acr{uid} reale, o a quello effettivo o a
+processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
+ad un valore corrispondente o all'\ids{UID} 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 lascia inalterato l'identificatore
corrispondente.
-Per queste funzioni esistono anche due controparti, \funcd{getresuid} e
-\funcd{getresgid},\footnote{le funzioni non sono standard, anche se appaiono
- in altri kernel, su Linux sono presenti dal kernel 2.1.44 e con le versioni
- della \acr{glibc} a partire dalla 2.3.2, definendo la macro
- \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
+Per queste funzioni di sistema esistono anche due controparti,
+\funcd{getresuid} e \funcd{getresgid},\footnote{le funzioni non sono standard,
+ anche se appaiono in altri kernel, su Linux sono presenti dal kernel 2.1.44
+ e con le versioni della \acr{glibc} a partire dalla 2.3.2, definendo la
+ macro \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
identificatori; i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
-\fdesc{Legge l'\acr{uid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.}
\fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
-\fdesc{Legge il \acr{gid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} può assumere solo il valore \errval{EFAULT} se gli
+ caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
indirizzi delle variabili di ritorno non sono validi. }
\end{funcproto}
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
-fatto cambiando l'\acr{uid} effettivo o l'\acr{uid} reale il server si espone
+fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} 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'\acr{uid} di filesystem
+temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} 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
l'utente non possa inviare segnali al server NFS.
-Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
-e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e non devono essere
-usate se si intendono scrivere programmi portabili; i loro prototipi sono:
+Le due funzioni di sistema usate per cambiare questi identificatori sono
+\funcd{setfsuid} e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e
+non devono essere usate se si intendono scrivere programmi portabili; i loro
+prototipi sono:
\begin{funcproto}{
\fhead{sys/fsuid.h}
\fdecl{int setfsuid(uid\_t fsuid)}
-\fdesc{Imposta l'\acr{uid} di filesystem del processo corrente.}
+\fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.}
\fdecl{int setfsgid(gid\_t fsgid)}
-\fdesc{Legge il \acr{gid} di filesystem del processo corrente.}
+\fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
}
{Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
successo e quello corrente per un errore, in questo caso non viene però
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
- sez.~\ref{sec:sys_sysconf}), leggendo il parametro
+ sez.~\ref{sec:sys_limits}), 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 è:
+La funzione di sistema che permette di leggere i gruppi supplementari
+associati ad un processo è \funcd{getgroups}; questa funzione è definita nello
+standard POSIX.1, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
La funzione legge gli identificatori dei gruppi supplementari del processo sul
vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
-specificato se la funzione inserisca o meno nella lista il \acr{gid} effettivo
+specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
l'argomento \param{list} non viene modificato, ma si ottiene il numero di
gruppi supplementari.
La funzione esegue una scansione del database dei gruppi (si veda
sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
-specificato per nome (e non con un \acr{uid}) nella stringa passata con
+specificato per nome (e non con un \ids{UID}) nella stringa passata con
l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
-\acr{gid} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
+\ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
che in ingresso deve indicare la dimensione di \param{group}, è passato come
\itindex{value~result~argument} \textit{value result argument} perché, qualora
il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando
Infine per impostare i gruppi supplementari di un processo ci sono due
funzioni, che possono essere usate solo se si hanno i privilegi di
-amministratore.\footnote{e più precisamente se si ha la \itindex{capability}
- \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è
-\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
- differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
+amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
+ \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione
+di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4,
+ ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
il suo prototipo è:
caso \var{errno} assumerà uno dei 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
massimo consentito di gruppi supplementari.
+\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}}
\end{funcproto}
che si possono impostare è 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 è:
+Se invece si vogliono impostare i gruppi supplementari del processo a quelli
+di un utente specifico, si può usare la funzione \funcd{initgroups} il cui
+prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
-\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per
informazioni dei gruppi.
+\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}}
\end{funcproto}
La funzione esegue la scansione del database dei gruppi (usualmente
\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
-(di nuovo specificato per nome e non per \acr{uid}) con cui costruisce una
+(di nuovo specificato per nome e non per \ids{UID}) 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
di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente
innalzato.
-Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
+Fino alla \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
risultato dalla \textit{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
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 di sistema \funcd{getpriority}, derivata da BSD; il suo prototipo è:
\begin{funcproto}{
\fhead{sys/time.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
-\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 è uno di quelli
elencati in tab.~\ref{tab:proc_getpriority}.
+\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
\end{errlist}}
\end{funcproto}
nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
-essere necessario includere anche \code{sys/time.h}, questo non è più
+essere necessario includere anche \headfile{sys/time.h}, questo non è più
necessario con versioni recenti delle librerie, ma è comunque utile per
portabilità.
quando si ottiene un valore di ritorno uguale a $-1$ 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 di sistema \funcd{setpriority} che
+permette di impostare la priorità di uno o più processi; il suo prototipo è:
\begin{funcproto}{
\fhead{sys/time.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
+\item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
+ sufficienti privilegi.
+\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
+ elencati in tab.~\ref{tab:proc_getpriority}.
+\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
+ cercato di modificare la priorità di un processo di un altro utente.
\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 è uno di quelli
- elencati in tab.~\ref{tab:proc_getpriority}.
- \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.
\end{errlist}}
\end{funcproto}
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'\acr{uid} reale o quello
-effettivo del processo chiamante corrispondessero all'\acr{uid} reale (e solo
+sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello
+effettivo del processo chiamante corrispondessero all'\ids{UID} 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 l'\acr{uid} effettivo.
+anche con l'\ids{UID} 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
una priorità dinamica per i processi che non ricevono la CPU così che anche
essi possano essere messi in esecuzione, un alto valore di \textit{nice}
corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce
-comunque, per cui un processo a bassa priorità avra davvero scarse possibilità
+comunque, per cui un processo a bassa priorità avrà davvero scarse possibilità
di essere eseguito in presenza di processi attivi a priorità più alta.
Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
le politiche di \textit{scheduling}, passando da \textit{real-time} a
ordinarie o viceversa, che di specificare, in caso di politiche
-\textit{real-time}, la eventuale priorità statica; la funzione è
+\textit{real-time}, la eventuale priorità statica; la funzione di sistema è
\funcd{sched\_setscheduler} ed il suo prototipo è:
\begin{funcproto}{
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei 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 per la politica scelta.
\item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
politica richiesta.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}}
\end{funcproto}
\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.5\textwidth}
\includestruct{listati/sched_param.c}
\end{minipage}
\normalsize
impostato con le funzioni viste in precedenza.
Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle
-priorità statiche possa essere ottenuto tramite le due funzioni
+priorità statiche possa essere ottenuto con le funzioni di sistema
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
automaticamente rimesso in coda alla lista, e la sua esecuzione continua
fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
-volontariamente la CPU (in tal caso, tornando nello stato \textbf{Runnable}
+volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
nel caso che esso sia stato interrotto da un processo a priorità più alta.
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'\acr{uid} effettivo del
-processo chiamante corrisponda all'\acr{uid} reale o effettivo del processo
+processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del
+processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo
indicato con \param{pid}.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
politica ordinaria.
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:
+usare le due funzioni di sistema \funcd{sched\_setparam} e
+\funcd{sched\_getparam} che consentono rispettivamente di impostarne e
+leggerne il valore, i loro prototipi sono:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sched.h}
\fdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
\fdesc{Imposta la priorità statica di un processo.}
\fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
\fdesc{Legge la priorità statica di un processo.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei 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
politica usata dal processo.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
l'operazione.
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}}
\end{funcproto}
Le funzioni richiedono di indicare nell'argomento \param{pid} il processo su
-cui operare e usano l'argomento \param{param} per mantenre il valore della
+cui operare e usano l'argomento \param{param} per mantenere il valore della
priorità dinamica. Questo è ancora una struttura \struct{sched\_param} ed
assume gli stessi valori già visti per \func{sched\_setscheduler}.
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'\textit{header
- file} \file{sched.h}.
+ file} \headfile{sched.h}.
Se invece si vuole sapere quale è politica di \textit{scheduling} di un
-processo si può usare la funzione \funcd{sched\_getscheduler}, il cui
-prototipo è:
+processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
+cui prototipo è:
\begin{funcproto}{
\fhead{sched.h}
{La funzione ritorna la politica di \textit{scheduling} in caso di successo e
$-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
l'operazione.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}}
\end{funcproto}
processo specificato dall'argomento \param{pid}, se questo è 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
-lunghezza della \textit{time-slice} usata dalla politica \textit{round robin};
-il suo prototipo è:
+L'ultima funzione di sistema che permette di leggere le informazioni relative
+ai processi 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 è:
\begin{funcproto}{
\fhead{sched.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
-\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] l'argomento \param{pid} non è valido.
\item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per
kernel arcaici).
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
La funzione restituisce nell'argomento \param{tp} come una struttura
\struct{timespec}, (la cui definizione si può trovare in
fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato
-per la politica \textit{round robin} dal processo indicato da \acr{pid}. Il
+per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il
valore dipende dalla versione del kernel, a lungo infatti questo intervallo di
tempo era prefissato e non modificabile ad un valore di 150 millisecondi,
-restituito indipendentemente dal \acr{pid} indicato.
+restituito indipendentemente dal \ids{PID} indicato.
Con kernel recenti però è possibile ottenere una variazione della
\textit{time-slice}, modificando il valore di \textit{nice} del processo
\textit{real-time}.
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 è:
+consentire agli altri processi di essere eseguiti; la funzione di sistema che
+consente di fare tutto questo è \funcd{sched\_yield}, il cui prototipo è:
\begin{funcproto}{
\fhead{sched.h}
cambiato ed un processo che chiama la funzione viene inserito nella lista dei
processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
ripristinare un comportamento analogo al precedente scrivendo il valore 1
- nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.}
+ nel file \sysctlfile{kernel/sched\_compat\_yield}.}
L'uso delle funzione nella programmazione ordinaria può essere utile e
migliorare le prestazioni generali del sistema quando si è appena rilasciata
solo una preferenza, non un requisito assoluto.} e per poter risolvere
questo tipo di problematiche nei nuovi kernel\footnote{le due \textit{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 l'opportuna infrastruttura ed una nuova \textit{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 è:
+ nel kernel 2.5.8, e le corrispondenti funzioni di sistema nella
+ \textsl{glibc} 2.3.} è stata introdotta l'opportuna infrastruttura ed una
+nuova \textit{system call} che permette di impostare su quali processori far
+eseguire un determinato processo attraverso una \textsl{maschera di
+ affinità}. La corrispondente funzione di sistema è
+\funcd{sched\_setaffinity} ed il suo prototipo è:
+
+\index{insieme~di~processori|(}
\begin{funcproto}{
\fhead{sched.h}
-\fdecl{int sched\_setaffinity (pid\_t pid, size\_t cpusetsize,
+\fdecl{int sched\_setaffinity(pid\_t pid, size\_t setsize,
cpu\_set\_t *mask)}
\fdesc{Imposta la maschera di affinità di un processo.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
-\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a
processori non esistenti nel sistema o a cui non è consentito l'accesso.
\item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
eseguire l'operazione.
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
-Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
+Questa funzione e la corrispondente \func{sched\_getaffinity} hanno una storia
abbastanza complessa, la sottostante \textit{system call} infatti prevede
l'uso di due soli argomenti (per il pid e l'indicazione della maschera dei
processori), che corrispondono al fatto che l'implementazione effettiva usa
-una semplice maschera binaria. Quando le funzioni vennero incluse nelle
+una semplice maschera binaria. Quando le funzioni vennero incluse nella
\acr{glibc} assunsero invece un prototipo simile a quello mostrato però con il
secondo argomento di tipo \ctyp{unsigned int}. A complicare la cosa si
-aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} detto argomento
+aggiunge il fatto che nella versione 2.3.3 della \acr{glibc} detto argomento
venne stato eliminato, per poi essere ripristinato nella versione 2.3.4 nella
forma attuale.\footnote{pertanto se la vostra pagina di manuale non è
- aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
+ aggiornata, o usate quella particolare versione della \acr{glibc}, potrete
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}.}
+ corrispondente alla definizione presente in \headfile{sched.h}.}
La funzione imposta, con l'uso del valore contenuto all'indirizzo
\param{mask}, l'insieme dei processori sui quali deve essere eseguito il
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
+Nell'uso comune, almeno con i kernel successivi alla 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) è
utilizzato per un compito importante (ad esempio per applicazioni
\textit{real-time} o la cui risposta è critica) e si vuole la massima
nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
di processore.
-Per facilitare l'uso dell'argomento \param{mask} le \acr{glibc} hanno
-introdotto un apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una
- estensione specifica delle \acr{glibc}, da attivare definendo la macro
+Dato che il numero di processori può variare a seconda delle architetture, per
+semplificare l'uso dell'argomento \param{mask} la \acr{glibc} ha introdotto un
+apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una estensione
+ specifica della \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 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 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:
+permette di identificare un insieme di processori. Il dato è normalmente una
+maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
+cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
+cui questo numero può non essere sufficiente, e per questo è stato creato
+questo \index{tipo!opaco} tipo opaco e una interfaccia di gestione che
+permette di usare a basso livello un tipo di dato qualunque rendendosi
+indipendenti dal numero di bit e dalla loro disposizione. Per questo le
+funzioni richiedono anche che oltre all'insieme di processori si indichi anche
+la dimensione dello stesso con l'argomento \param{setsize}, per il quale, se
+non si usa l'allocazione dinamica che vedremo a breve, ed è in genere
+sufficiente passare il valore \code{sizeof(cpu\_set\_t)}.
+
+L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
+del tipo \type{cpu\_set\_t}, prevede una serie di macro di preprocessore per
+la manipolazione degli stessi. Quelle di base, che consentono rispettivamente
+di svuotare un insieme, di aggiungere o togliere un processore o di verificare
+se esso è già presente in un insieme, sono le seguenti:
{\centering
\vspace{3pt}
\begin{funcbox}{
\fhead{sched.h}
\fdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
-\fdesc{Inizializza l'insieme vuoto \param{set}.}
+\fdesc{Inizializza un insieme di processori vuoto \param{set}.}
\fdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)}
-\fdesc{Inserisce il processore \param{cpu} nell'insieme \param{set}.}
+\fdesc{Inserisce il processore \param{cpu} nell'insieme di processori \param{set}.}
\fdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
-\fdesc{Rimuove il processore \param{cpu} nell'insieme \param{set}.}
+\fdesc{Rimuove il processore \param{cpu} nell'insieme di processori \param{set}.}
\fdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
-\fdesc{Controlla se il processore \param{cpu} è nell'insieme \param{set}.}
+\fdesc{Controlla se il processore \param{cpu} è nell'insieme di processori \param{set}.}
+}
+\end{funcbox}}
+
+Queste macro che sono ispirate dalle analoghe usate per gli insiemi di
+\textit{file descriptor} (vedi sez.~\ref{sec:file_select}) e sono state
+introdotte con la versione 2.3.3 della \acr{glibc}. Tutte richiedono che si
+specifichi il numero di una CPU nell'argomento \param{cpu}, ed un insieme su
+cui operare. L'unica che ritorna un risultato è \macro{CPU\_ISSET}, che
+restituisce un intero da usare come valore logico (zero se la CPU non è
+presente, diverso da zero se è presente).
+
+Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
+valutato più volte. Questo significa ad esempio che non si può usare al suo
+posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
+volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
+\itindex{side~effects} \textit{side effects}).\footnote{nel linguaggio C si
+ parla appunto di \textit{side effects} quando si usano istruzioni la cui
+ valutazione comporta effetti al di fuori dell'istruzione stessa, come il
+ caso indicato in cui si passa una funzione ad una macro che usa l'argomento
+ al suo interno più volte, o si scrivono espressioni come \code{a=a++} in cui
+ non è chiaro se prima avvenga l'incremento e poi l'assegnazione, ed il cui
+ risultato dipende dall'implementazione del compilatore.}
+
+Le CPU sono numerate da zero (che indica la prima disponibile) fino ad
+un numero massimo che dipende dalla architettura hardware. La costante
+\const{CPU\_SETSIZE} indica il numero massimo di processori che possono far
+parte di un insieme (al momento vale sempre 1024), e costituisce un limite
+massimo al valore dell'argomento \param{cpu}.
+Dalla versione 2.6 della \acr{glibc} alle precedenti macro è stata aggiunta,
+per contare il numero di processori in un insieme, l'ulteriore:
+
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sched.h}
+\fdecl{int \macro{CPU\_COUNT}(cpu\_set\_t *set)}
+\fdesc{Conta il numero di processori presenti nell'insieme \param{set}.}
}
\end{funcbox}}
-% TODO trattare le altre
+A partire dalla versione 2.7 della \acr{glibc} sono state introdotte altre
+macro che consentono ulteriori manipolazioni, in particolare si possono
+compiere delle operazioni logiche sugli insiemi di processori con:
-Oltre a queste macro, simili alle analoghe usate per gli insiemi di
-\textit{file 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}.
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sched.h}
+\fdecl{void \macro{CPU\_AND}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
+\fdesc{Esegue l'AND logico di due insiemi di processori.}
+\fdecl{void \macro{CPU\_OR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
+\fdesc{Esegue l'OR logico di due insiemi di processori.}
+\fdecl{void \macro{CPU\_XOR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
+\fdesc{Esegue lo XOR logico di due insiemi di processori.}
+\fdecl{int \macro{CPU\_EQUAL}(cpu\_set\_t *set1, cpu\_set\_t *set2)}
+\fdesc{Verifica se due insiemi di processori sono uguali.}
+}
+\end{funcbox}}
-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 è:
+Le prime tre macro richiedono due insiemi di partenza, \param{srcset1}
+e \param{srcset2} e forniscono in un terzo insieme \param{destset} (che può
+essere anche lo stesso di uno dei precedenti) il risultato della rispettiva
+operazione logica sui contenuti degli stessi. In sostanza con \macro{CPU\_AND}
+si otterrà come risultato l'insieme che contiene le CPU presenti in entrambi
+gli insiemi di partenza, con \macro{CPU\_OR} l'insieme che contiene le CPU
+presenti in uno qualunque dei due insiemi di partenza, e con \macro{CPU\_XOR}
+l'insieme che contiene le CPU presenti presenti in uno solo dei due insiemi di
+partenza. Infine \macro{CPU\_EQUAL} confronta due insiemi ed è l'unica che
+restituisce un intero, da usare come valore logico che indica se sono
+identici o meno.
+
+Inoltre, sempre a partire dalla versione 2.7 della \acr{glibc}, è stata
+introdotta la possibilità di una allocazione dinamica degli insiemi di
+processori, per poterli avere di dimensioni corrispondenti al numero di CPU
+effettivamente in gioco, senza dover fare riferimento necessariamente alla
+precedente dimensione preimpostata di 1024. Per questo motivo sono state
+definite tre ulteriori macro, che consentono rispettivamente di allocare,
+disallocare ed ottenere la dimensione in byte di un insieme di processori:
+
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sched.h}
+\fdecl{cpu\_set\_t * \macro{CPU\_ALLOC}(num\_cpus)}
+\fdesc{Alloca dinamicamente un insieme di processori di dimensione voluta.}
+\fdecl{void \macro{CPU\_FREE}(cpu\_set\_t *set)}
+\fdesc{Disalloca un insieme di processori allocato dinamicamente.}
+\fdecl{size\_t \macro{CPU\_ALLOC\_SIZE}(num\_cpus)}
+\fdesc{Ritorna la dimensione di un insieme di processori allocato dinamicamente.}
+}
+\end{funcbox}}
+
+La prima macro, \macro{CPU\_ALLOC}, restituisce il puntatore ad un insieme di
+processori in grado di contenere almeno \param{num\_cpus} che viene allocato
+dinamicamente. Ogni insieme così allocato dovrà essere disallocato con
+\macro{CPU\_FREE} passandogli un puntatore ottenuto da una precedente
+\macro{CPU\_ALLOC}. La terza macro, \macro{CPU\_ALLOC\_SIZE}, consente di
+ottenere la dimensione in byte di un insieme allocato dinamicamente che
+contenga \param{num\_cpus} processori.
+
+Dato che le dimensioni effettive possono essere diverse le macro di gestione e
+manipolazione che abbiamo trattato in precedenza non si applicano agli insiemi
+allocati dinamicamente, per i quali dovranno sono state definite altrettante
+macro equivalenti contraddistinte dal suffisso \texttt{\_S}, che effettuano le
+stesse operazioni, ma richiedono in più un argomento
+aggiuntivo \param{setsize} che deve essere assegnato al valore ottenuto con
+\macro{CPU\_ALLOC\_SIZE}. Questo stesso valore deve essere usato per l'omonimo
+argomento delle funzioni \func{sched\_setaffinity} o \func{sched\_getaffinity}
+quando si vuole usare per l'argomento che indica la maschera di affinità un
+insieme di processori allocato dinamicamente.
+
+\index{insieme~di~processori|)}
+
+A meno di non aver utilizzato \func{sched\_setaffinity}, in condizioni
+ordinarie la maschera di affinità di un processo è preimpostata dal sistema in
+modo che esso possa essere eseguito su qualunque processore. Se ne può
+comunque ottenere il valore corrente usando la funzione di sistema
+\funcd{sched\_getaffinity}, il cui prototipo è:
\begin{funcproto}{
\fhead{sched.h}
-\fdecl{int sched\_getaffinity (pid\_t pid, size\_t cpusetsize,
+\fdecl{int sched\_getaffinity (pid\_t pid, size\_t setsize,
cpu\_set\_t *mask)}
\fdesc{Legge la maschera di affinità di un processo.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
-\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
-\item[\errcode{EINVAL}] \param{cpusetsize} è più piccolo delle dimensioni
+\item[\errcode{EINVAL}] \param{setsize} è più piccolo delle dimensioni
della maschera di affinità usata dal kernel.
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
La funzione restituirà all'indirizzo specificato da \param{mask} il valore
della maschera di affinità del processo indicato dall'argomento \param{pid}
(al solito un valore nullo indica il processo corrente) così da poterla
-riutilizzare per una successiva reimpostazione. L'argomento \param{cpusetsize}
-indica la dimensione dell'argomento \param{mask} ed è in genere sufficiente
-passare il valore \code{sizeof(cpu\_set\_t)}.
+riutilizzare per una successiva reimpostazione.
È 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ò
non avranno alcun risultato effettivo.
-% TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati
-% per associare l'uso di gruppi di processori a gruppi di processi (vedi
-% manpage omonima)
-% TODO trattare getcpu, che attiene anche a NUMA
\itindend{scheduler}
\itindend{CPU~affinity}
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
-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 \textit{scheduler} CFQ (\textit{Completely Fair Queuing})
-è divenuto possibile, qualora si usi questo \textit{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 \textit{scheduler}.}
-
-La scelta dello \textit{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
-disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler}
-(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
-\textit{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
- \textit{scheduler} CFQ.} che supporta le priorità. Per i dettagli sulle
-caratteristiche specifiche degli altri \textit{scheduler}, la cui discussione
-attiene a problematiche di ambito sistemistico, si consulti la documentazione
-nella directory \texttt{Documentation/block/} dei sorgenti del kernel.
+per le prestazioni, è quella dell'accesso a disco. Per questo motivo nello
+sviluppo del kernel 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 \textit{scheduler} CFQ
+(\textit{Completely Fair Queuing}) è divenuto possibile, qualora si usi questo
+\textit{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 \textit{scheduler}.}
+
+La scelta di uno \textit{scheduler} di I/O si può fare in maniera generica per
+tutto il sistema all'avvio del kernel con il parametro di avvio
+\texttt{elevator},\footnote{per la trattazione dei parametri di avvio del
+ kernel si rimanda al solito alla sez.~5.3 di \cite{AGL}.} cui assegnare il
+nome dello \textit{scheduler}, ma se ne può anche indicare uno specifico 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 \textit{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 \textit{scheduler} CFQ.} che supporta le priorità. Per i dettagli
+sulle caratteristiche specifiche degli altri \textit{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 \textit{scheduler} CFQ ci sono due
-specifiche system call, specifiche di Linux, che consentono di leggere ed
-impostare le priorità di I/O.\footnote{se usate in corrispondenza ad uno
- \textit{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 la funzione \func{syscall} (come
-illustrato in sez.~\ref{sec:proc_syscall}). Le due funzioni sono
-\funcd{ioprio\_get} ed \funcd{ioprio\_set}; i rispettivi prototipi sono:
+specifiche \textit{system call}, specifiche di Linux, che consentono di
+leggere ed impostare le priorità di I/O.\footnote{se usate in corrispondenza
+ ad uno \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.}
+Dato che non esiste una interfaccia diretta nella \acr{glibc} per queste due
+funzioni\footnote{almeno al momento della scrittura di questa sezione, con la
+ versione 2.11 della \acr{glibc}.} occorrerà invocarle tramite la funzione
+\func{syscall} (come illustrato in sez.~\ref{sec:proc_syscall}). Le due
+\textit{system call} sono \funcd{ioprio\_get} ed \funcd{ioprio\_set}; i
+rispettivi prototipi sono:
\begin{funcproto}{
\fhead{linux/ioprio.h}
successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
-\item[\errcode{ESRCH}] non esiste un processo corrisponente alle indicazioni.
-\item[\errcode{EINVAL}] i valori di \param{which} o di \param{iprio} non
+\item[\errcode{EINVAL}] i valori di \param{which} o di \param{ioprio} non
sono validi.
\item[\errcode{EPERM}] non si hanno i privilegi per eseguire
l'impostazione (solo per \func{ioprio\_set}).
+\item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni.
\end{errlist}}
\end{funcproto}
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
-definite delle opportune macro di preprocessore, riportate in
-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
-\textit{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
-argomento di \func{ioprio\_set} per eseguire una impostazione.
-
\begin{table}[htb]
\centering
\footnotesize
\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à.\\
\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
\label{tab:IOsched_class_macro}
\end{table}
-Le classi di \textit{scheduling} previste dallo \textit{scheduler} CFQ sono
-tre, e ricalcano tre diverse modalità di distribuzione delle risorse analoghe
-a quelle già adottate anche nel funzionamento dello \textit{scheduler} del
-processore. Ciascuna di esse è identificata tramite una opportuna costante,
-secondo quanto riportato in tab.~\ref{tab:IOsched_class}.
+
+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
+impostano usando queste macro. Le prime due si usano con il valore restituito
+da \func{ioprio\_get} e per ottenere rispettivamente la classe di
+\textit{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
+argomento di \func{ioprio\_set} per eseguire una impostazione.
\begin{table}[htb]
\centering
\label{tab:IOsched_class}
\end{table}
+Le classi di \textit{scheduling} previste dallo \textit{scheduler} CFQ sono
+tre, e ricalcano tre diverse modalità di distribuzione delle risorse analoghe
+a quelle già adottate anche nel funzionamento dello \textit{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
questa classe riescono ad accedere a disco soltanto quando nessun altro
processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
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 \acr{uid} reale corrisponde all'\acr{uid} reale o effettivo
+cioè quelli il cui \ids{UID} reale corrisponde all'\ids{UID} reale o effettivo
del chiamante. Data la possibilità di ottenere un blocco totale del sistema,
solo l'amministratore\footnote{o un processo con la capacità
\const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
rimosso a partire dal kernel 2.6.25.
%TODO verificare http://lwn.net/Articles/355987/
-
-%TODO trattare le funzionalità per il NUMA
-% vedi man numa e, mbind, get_mempolicy, set_mempolicy,
-% le pagine di manuale relative
-% vedere anche dove metterle...
-
-
\section{Funzioni di gestione avanzata}
\label{sec:proc_advanced_control}
proprietà e caratteristiche particolari dei processi non coperte da esse, per
la cui gestione è stata predisposta una apposita \textit{system call} che
fornisce una interfaccia generica per tutte le operazioni specialistiche. La
-funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è
- standardizzata ed è specifica di Linux, anche se ne esiste una analoga in
- IRIX; è stata introdotta con il kernel 2.1.57.}
+funzione di sistema è \funcd{prctl} ed il suo prototipo è:\footnote{la
+ funzione non è standardizzata ed è specifica di Linux, anche se ne esiste
+ una analoga in IRIX; è stata introdotta con il kernel 2.1.57.}
\begin{funcproto}{
\fhead{sys/prctl.h}
-\fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3,
- unsigned long arg4, unsigned long arg5)}
+\fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned
+ long arg4, \\
+\phantom{int prctl(}unsigned long arg5)}
\fdesc{Esegue una operazione speciale sul processo corrente.}
}
{La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in
in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
argomento, \param{option}. Questo è un valore intero che identifica
l'operazione, e deve essere specificato con l'uso di una delle costanti
-predefinite del seguente elenco, che illustra quelle disponibili al momento:
+predefinite del seguente elenco, che illustra quelle disponibili al
+momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.}
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
- \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
- ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
- delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
- \textit{capabilities bounding set} del processo e zero altrimenti,
- se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
- Introdotta a partire dal kernel 2.6.25.
+ \itindex{capabilities} \textit{capabilities} (vedi
+ sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità
+ specificata nell'argomento \param{arg2} (con una delle costanti di
+ tab.~\ref{tab:proc_capabilities}) è presente nel \textit{capabilities
+ bounding set} del processo e zero altrimenti, se \param{arg2} non è un
+ valore valido si avrà un errore di \errval{EINVAL}. Introdotta a partire
+ dal kernel 2.6.25.
+
\item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
- \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
- da tutti i suoi discendenti. La funzione cancella la capacità specificata
+ \itindex{capabilities} \textit{capabilities} (vedi
+ sez.~\ref{sec:proc_capabilities}) dal processo e da tutti i suoi
+ discendenti. La funzione cancella la capacità specificata
nell'argomento \param{arg2} con una delle costanti di
- tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
- processo. L'operazione richiede i privilegi di amministratore (la capacità
- \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
- \errval{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
- per le \textit{file capabilities} non è stato compilato nel kernel la
- chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
- kernel 2.6.25.
+ tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set}
+ \itindex{capabilities~bounding~set} del processo. L'operazione richiede i
+ privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), altrimenti
+ la chiamata fallirà con un errore di \errcode{EPERM}; se il valore
+ di \param{arg2} non è valido o se il supporto per le \textit{file
+ capabilities} non è stato compilato nel kernel la chiamata fallirà con un
+ errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25.
+
\item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
terminazione di un processo a causa di un segnale per il quale è prevista la
generazione di un file di \itindex{core~dump} \textit{core dump} (vedi
per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
- degli \textit{user-ID} dei processi (vedi
- sez.~\ref{sec:proc_setuid}). L'operazione è stata introdotta a partire dal
- kernel 2.3.20, fino al kernel 2.6.12 e per i kernel successivi al 2.6.17 era
- possibile usare solo un valore 0 di \param{arg2} per disattivare il flag ed
- un valore 1 per attivarlo, nei kernel dal 2.6.13 al 2.6.17 è stato
- supportato anche il valore 2, che causava la generazione di un
- \itindex{core~dump} \textit{core dump} leggibile solo
- dall'amministratore.\footnote{la funzionalità è stata rimossa per motivi di
- sicurezza, in quanto consentiva ad un utente normale di creare un file di
- \textit{core dump} appartenente all'amministratore in directory dove
- l'utente avrebbe avuto permessi di accesso.}
+ degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
+
+ L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
+ 2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
+ valore 0 di \param{arg2} per disattivare il flag ed un valore 1 per
+ attivarlo. Nei kernel dal 2.6.13 al 2.6.17 è stato supportato anche il
+ valore 2, che causava la generazione di un \itindex{core~dump} \textit{core
+ dump} leggibile solo dall'amministratore, ma questa funzionalità è stata
+ rimossa per motivi di sicurezza, in quanto consentiva ad un utente normale
+ di creare un file di \textit{core dump} appartenente all'amministratore in
+ directory dove l'utente avrebbe avuto permessi di accesso.
+
\item[\const{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
lo stato corrente del flag che controlla la effettiva generazione dei
\itindex{core~dump} \textit{core dump}. Introdotta a partire dal kernel
2.3.20.
-\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
- chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
- sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
- \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
- \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
+
+\item[\const{PR\_SET\_ENDIAN}] Imposta la \itindex{endianness}
+ \textit{endianness} del processo chiamante secondo il valore fornito
+ in \param{arg2}. I valori possibili sono sono: \const{PR\_ENDIAN\_BIG}
+ (\textit{big endian}), \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}),
+ e \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
PowerPC.
-\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
- processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
- essere passata come di tipo \ctyp{(int *)}. Introdotta a partire dal kernel
- 2.6.18, solo su PowerPC.
+
+\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \itindex{endianness}
+ \textit{endianness} del processo chiamante, salvato sulla variabile puntata
+ da \param{arg2} che deve essere passata come di tipo ``\ctyp{int
+ *}''. Introdotta a partire dal kernel 2.6.18, solo su PowerPC.
+
\item[\const{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
della virgola mobile su architettura ia64, secondo il valore
di \param{arg2}, si deve passare \const{PR\_FPEMU\_NOPRINT} per emulare in
maniera trasparente l'accesso alle operazioni in virgola mobile, o
\const{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
\signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
- dal kernel 2.4.18, solo su ia64.
+ dal kernel 2.4.18, solo su architettura ia64.
+
\item[\const{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
dell'emulazione della virgola mobile, salvato all'indirizzo puntato
- da \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
- partire dal kernel 2.4.18, solo su ia64.
+ da \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
+ partire dal kernel 2.4.18, solo su architettura ia64.
+
\item[\const{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
- I valori possibili sono: \const{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per
- le eccezioni, \const{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola
- mobile, \const{PR\_FP\_EXC\_OVF} per gli overflow, \const{PR\_FP\_EXC\_UND}
- per gli underflow, \const{PR\_FP\_EXC\_RES} per risultati non esatti,
- \const{PR\_FP\_EXC\_INV} per operazioni invalide,
- \const{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
- \const{PR\_FP\_EXC\_NONRECOV} per utilizzare la modalità di eccezione
- asincrona non recuperabile, \const{PR\_FP\_EXC\_ASYNC} per utilizzare la
- modalità di eccezione asincrona recuperabile, \const{PR\_FP\_EXC\_PRECISE}
- per la modalità precisa di eccezione.\footnote{trattasi di gestione
- specialistica della gestione delle eccezioni dei calcoli in virgola mobile
- che, i cui dettagli al momento vanno al di là dello scopo di questo
- testo.} Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
+ I valori possibili sono:
+ \begin{itemize*}
+ \item \const{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
+ \item \const{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
+ \item \const{PR\_FP\_EXC\_OVF} per gli overflow,
+ \item \const{PR\_FP\_EXC\_UND} per gli underflow,
+ \item \const{PR\_FP\_EXC\_RES} per risultati non esatti,
+ \item \const{PR\_FP\_EXC\_INV} per operazioni invalide,
+ \item \const{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
+ \item \const{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
+ asincrona non recuperabile,
+ \item \const{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
+ asincrona recuperabile,
+ \item \const{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
+ eccezione.\footnote{trattasi di gestione specialistica della gestione
+ delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
+ momento vanno al di là dello scopo di questo testo.}
+ \end{itemize*}
+Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
+
\item[\const{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
delle operazioni in virgola mobile, salvata all'indirizzo
- puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
- partire dal kernel 2.4.21, solo su PowerPC.
+ puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta
+ a partire dal kernel 2.4.21, solo su PowerPC.
+
\item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
- \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
- \textit{user-ID} del processo (per i dettagli si veda
+ \itindex{capabilities} \textit{capabilities} vengono cancellate quando si
+ esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
flag \const{SECURE\_KEEP\_CAPS} dei \itindex{securebits} \textit{securebits}
(vedi l'uso di \const{PR\_SET\_SECUREBITS} più avanti). Introdotta a partire
dal kernel 2.2.18.
+
\item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
- il valore del flag di controllo impostato con
- \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
+ il valore del flag di controllo delle \itindex{capabilities}
+ \textit{capabilities} impostato con \const{PR\_SET\_KEEPCAPS}. Introdotta a
+ partire dal kernel 2.2.18.
+
\item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
- stringa puntata da \param{arg2}, che deve essere di tipo \code{(char *)}. Il
+ stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
+
\item[\const{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
- stringa puntata da \param{arg2}, che deve essere di tipo \code{(char *)}; si
- devono allocare per questo almeno 16 byte, e il nome sarà terminato da NUL
- se più corto. Introdotta a partire dal kernel 2.6.9.
+ stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}'';
+ si devono allocare per questo almeno 16 byte, e il nome sarà terminato da
+ NUL se più corto. Introdotta a partire dal kernel 2.6.9.
+
\item[\const{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
terminazione del proprio processo padre; in sostanza consente di invertire
numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
automaticamente cancellato per un processo figlio creato con \func{fork}.
Introdotta a partire dal kernel 2.1.57.
+
\item[\const{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
emesso alla terminazione del padre, salvato all'indirizzo
- puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
+ puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
partire dal kernel 2.3.15.
+
\item[\const{PR\_SET\_SECCOMP}] Imposta il cosiddetto
\itindex{secure~computing~mode} \textit{secure computing mode} per il
processo corrente. Prevede come unica possibilità che \param{arg2} sia
- impostato ad 1. Una volta abilitato il \textit{secure computing mode} il
- processo potrà utilizzare soltanto un insieme estremamente limitato di
- \textit{system call}: \func{read}, \func{write}, \func{\_exit} e
- \func{sigreturn}, ogni altra \textit{system call} porterà all'emissione di
- un \func{SIGKILL} (vedi sez.~\ref{sec:sig_termination}). Il \textit{secure
- computing mode} è stato ideato per fornire un supporto per l'esecuzione di
- codice esterno non fidato e non verificabile a scopo di calcolo;\footnote{lo
- scopo è quello di poter vendere la capacità di calcolo della proprio
- macchina ad un qualche servizio di calcolo distribuito senza
- comprometterne la sicurezza eseguendo codice non sotto il proprio
- controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
- una pipe, e per evitare problemi di sicurezza non sono possibili altre
- operazioni se non quelle citate. Introdotta a partire dal kernel 2.6.23,
- disponibile solo se si è abilitato il supporto nel kernel con
- \texttt{CONFIG\_SECCOMP}.
+ impostato ad 1. Una volta abilitato il \itindex{secure~computing~mode}
+ \textit{secure computing mode} il processo potrà utilizzare soltanto un
+ insieme estremamente limitato di \textit{system call}: \func{read},
+ \func{write}, \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system
+ call} porterà all'emissione di un \signal{SIGKILL} (vedi
+ sez.~\ref{sec:sig_termination}). Il \textit{secure computing mode} è stato
+ ideato per fornire un supporto per l'esecuzione di codice esterno non fidato
+ e non verificabile a scopo di calcolo;\footnote{lo scopo è quello di poter
+ vendere la capacità di calcolo della proprio macchina ad un qualche
+ servizio di calcolo distribuito senza comprometterne la sicurezza
+ eseguendo codice non sotto il proprio controllo.} in genere i dati vengono
+ letti o scritti grazie ad un socket o una pipe, e per evitare problemi di
+ sicurezza non sono possibili altre operazioni se non quelle citate.
+ Introdotta a partire dal kernel 2.6.23, disponibile solo se si è abilitato
+ il supporto nel kernel con \texttt{CONFIG\_SECCOMP}.
+
\item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
lo stato corrente del \textit{secure computing mode}, al momento attuale la
funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
- che la chiamata di questa funzione in \textit{secure computing mode}
- comporterebbe l'emissione di \texttt{SIGKILL}, è stata comunque definita per
- eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
+ che la chiamata di questa funzione in \itindex{secure~computing~mode}
+ \textit{secure computing mode} comporterebbe l'emissione di
+ \signal{SIGKILL}, è stata comunque definita per eventuali estensioni future.
+ Introdotta a partire dal kernel 2.6.23.
+
\item[\const{PR\_SET\_SECUREBITS}] Imposta i \itindex{securebits}
\textit{securebits} per il processo chiamante al valore indicato
da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si
veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
- richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
- altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
- partire dal kernel 2.6.26.
+ richiede i privilegi di amministratore (la \itindex{capabilities} capacità
+ \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
+ \errval{EPERM}. Introdotta a partire dal kernel 2.6.26.
+
\item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
funzione l'impostazione corrente per i \itindex{securebits}
\textit{securebits}. Introdotta a partire dal kernel 2.6.26.
+
\item[\const{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
- processo da indicare con il valore di \param{arg2}, con
- \const{PR\_TIMING\_STATISTICAL} si usa il metodo statistico tradizionale,
- con \const{PR\_TIMING\_TIMESTAMP} il più accurato basato su dei
- \textit{timestamp}, quest'ultimo però non è ancora implementato ed il suo
- uso comporta la restituzione di un errore di \errval{EINVAL}. Introdotta a
- partire dal kernel 2.6.0-test4.
+ processo da indicare con il valore di \param{arg2}, attualmente i valori
+ possibili sono due, con \const{PR\_TIMING\_STATISTICAL} si usa il metodo
+ statistico tradizionale, con \const{PR\_TIMING\_TIMESTAMP} il più accurato
+ basato su dei \textit{timestamp}, quest'ultimo però non è ancora
+ implementato ed il suo uso comporta la restituzione di un errore di
+ \errval{EINVAL}. Introdotta a partire dal kernel 2.6.0-test4.
+
\item[\const{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
- il metodo di temporizzazione del processo attualmente in uso. Introdotta a
- partire dal kernel 2.6.0-test4.
+ il metodo di temporizzazione del processo attualmente in uso (uno dei due
+ valori citati per \const{PR\_SET\_TIMING}). Introdotta a partire dal kernel
+ 2.6.0-test4.
+
\item[\const{PR\_SET\_TSC}] Imposta il flag che indica se il processo
chiamante può leggere il registro di processore contenente il contatore dei
\textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
abilitare la lettura o \const{PR\_TSC\_SIGSEGV} per disabilitarla con la
generazione di un segnale di \signal{SIGSEGV} (vedi
sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
- disabilitata se si attiva il \textit{secure computing mode}. Introdotta a
- partire dal kernel 2.6.26, solo su x86.
+ disabilitata se si attiva il \itindex{secure~computing~mode} \textit{secure
+ computing mode}. Introdotta a partire dal kernel 2.6.26, solo su x86.
+
\item[\const{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
- puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
+ puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
partire dal kernel 2.6.26, solo su x86.
% articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
% http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
% http://en.wikipedia.org/wiki/Time_Stamp_Counter
+
\item[\const{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
a indirizzi di memoria non allineati, che in varie architetture risultano
illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
ed il valore \const{PR\_UNALIGN\_SIGBUS} per generare un segnale di
\signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
allineato. Introdotta con diverse versioni su diverse architetture.
+
\item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
Il comportamento di default prevede che per tutti i processi si applichi la
politica generale di sistema definita nel file
- \procfile{/proc/sys/vm/memory\_failure\_early\_kill}, ma specificando
+ \sysctlfile{vm/memory\_failure\_early\_kill}, ma specificando
per \param{arg2} il valore \const{PR\_MCE\_KILL\_SET} è possibile impostare
con il contenuto di \param{arg3} una politica specifica del processo
chiamante. Si può tornare alla politica di default del sistema utilizzando
\end{basedescript}
+
\subsection{La \textit{system call} \func{clone}}
\label{sec:process_clone}
tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
Per questo l'interfaccia per la creazione di un nuovo processo è stata
-delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di
-reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più
-che di nuovi processi si può parlare della creazioni di nuovi
+delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
+di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
+più che di nuovi processi si può parlare della creazioni di nuovi
``\textit{task}'' del kernel che possono assumere la veste sia di un processo
-classico come quelli trattati finora, che di un \textit{thread}, come quelli
-che vedremo in sez.~\ref{sec:linux_thread}, in cui la memoria viene condivisa
-fra il processo chiamante ed il nuovo processo creato. Per evitare confusione
-fra \textit{thread} e processi ordinari, abbiamo deciso di usare la
-nomenclatura \textit{task} per indicare la unità di esecuzione generica messa
-a disposizione del kernel che \texttt{sys\_clone} permette di creare.
+classico isolato dagli altri come quelli trattati finora, che di un
+\textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
+il nuovo processo creato, come quelli che vedremo in
+sez.~\ref{sec:linux_thread}. Per evitare confusione fra \textit{thread} e
+processi ordinari, abbiamo deciso di usare la nomenclatura \textit{task} per
+indicare la unità di esecuzione generica messa a disposizione del kernel che
+\texttt{sys\_clone} permette di creare.
Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
virtualizzazione dei processi, di creare nuovi \textit{namespace} per una
-serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei
-file, dei \textit{mount point}, della rete, ecc.), che consentono di creare
-gruppi di processi che vivono in una sorta di spazio separato dagli altri, che
-costituisce poi quello che viene chiamato un \textit{container}.
+serie di proprietà generali dei processi (come l'elenco dei \ids{PID},
+l'albero dei file, i \itindex{mount~point} \textit{mount point}, la rete,
+ecc.), che consentono di creare gruppi di processi che vivono in una sorta di
+spazio separato dagli altri, che costituisce poi quello che viene chiamato un
+\textit{container}.
La \textit{system call} richiede soltanto due argomenti: il
primo, \param{flags}, consente di controllare le modalità di creazione del
\textit{stack} totalmente indipendente da quello del padre.
Dato che l'uso principale della nuova \textit{system call} è quello relativo
-alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di
+alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
libreria con una sintassi diversa, orientata a questo scopo, e la
\textit{system call} resta accessibile solo se invocata esplicitamente come
visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
\begin{funcproto}{
\fhead{sched.h}
-\fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg, ... /* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */)}
+\fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
+ ... \\
+\phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
\fdesc{Crea un nuovo processo o \textit{thread}.}
}
{La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
\end{errlist}}
\end{funcproto}
+% NOTE: una pagina con la descrizione degli argomenti:
+% * http://www.lindevdoc.org/wiki/Clone
+
La funzione prende come primo argomento \param{fn} il puntatore alla funzione
che verrà messa in esecuzione nel nuovo processo, che può avere un unico
argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
terzo argomento \param{arg}. Per quanto il precedente prototipo possa
intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
-definire una qualunque funzione \param{fn} che restitisce un intero ed ha come
-argomento un puntatore a \ctyp{vois}, e \code{fn(arg)} sarà eseguita in un
-nuovo processo.
+definire una qualunque funzione \param{fn} che restituisce un intero ed ha
+come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
+un nuovo processo.
Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
di ritorno della funzione (o quello specificato con \func{exit}) verrà
utilizzato come stato di uscita della funzione. I tre
argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
-presenti solo a partire dal kernel 2.6 ed usati principalmente per le funzioni
-di gestione dei \textit{thread} presenti nella \acr{glibc}.
+presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
+le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
+ Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
+utilizzati soltanto se si sono specificati rispettivamente i flag
+\const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
+\const{CLONE\_CHILD\_SETTID}.
+
+La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
+\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
+al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
+un processo.
Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
-nuovo processo da essa creato, è controllato dall'argomento \param{flags},
+nuovo processo da essa creato, è controllato principalmente
+dall'argomento \param{flags}, che deve essere specificato come maschera
+binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
+elenco, che illustra quelle attualmente disponibili:\footnote{si fa
+ riferimento al momento della stesura di questa sezione, cioè con il kernel
+ 3.2.}
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{CLONE\_CHILD\_CLEARTID}]
+\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
\item[\const{CLONE\_CHILD\_SETTID}]
\item[\const{CLONE\_FILES}]
\item[\const{CLONE\_FS}]
\end{basedescript}
+%TODO trattare unshare
+
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
%
% TODO l'I/O sulle porte di I/O
% consultare le manpage di ioperm, iopl e outb
+% non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
+% fileintro ?)
Da fare
-% TODO: funzioni varie sparse citate da qualche parte e da trattare forse in
-% una sezione a parte: sigreturn,
+
+%\subsection{La gestione di architetture a nodi multipli}
+%\label{sec:process_NUMA}
+
+% TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati
+% per associare l'uso di gruppi di processori a gruppi di processi (vedi
+% manpage omonima)
+% TODO trattare getcpu, che attiene anche a NUMA, mettere qui anche
+% sched_getcpu, che potrebbe essere indipendente ma richiama getcpu
+
+%TODO trattare le funzionalità per il NUMA
+% vedi man numa e, mbind, get_mempolicy, set_mempolicy,
+% le pagine di manuale relative
+% vedere anche dove metterle...
\section{Problematiche di programmazione multitasking}
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.
+programma alla volta.
-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.
+Per questo motivo, 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, sottolineando come esse
+diventino cogenti quando invece si usano i \textit{thread}.
\subsection{Le operazioni atomiche}
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
+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.
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 \textit{system call} con cui esse sono
-realizzate non possono essere interrotte (o subire interferenze pericolose) da
-altri processi.
+sez.~\ref{sec:file_shared_access}). In questi casi in genere l'uso delle
+appropriate funzioni di libreria per compiere le operazioni necessarie è
+garanzia sufficiente di atomicità in quanto le \textit{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
stesso processo, e pure alcune \textit{system call}, possono essere interrotti
operazioni atomiche (torneremo su questi aspetti in
sez.~\ref{sec:sig_adv_control}).
+Qualora invece si usino i \textit{thread}, in cui lo spazio degli indirizzi è
+condiviso, il problema è sempre presente, perché qualunque \textit{thread} può
+interromperne un altro in qualunque momento e l'atomicità di qualunque
+operazione è messa in discussione, per cui l'assenza di eventuali
+\itindex{race~condition} \textit{race condition} deve essere sempre verificata
+nei minimi dettagli.
+
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
\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
+le strutture di dati. 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.
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
-atomicamente le operazioni necessarie, occorre che quelle parti di codice in
-cui si compiono le operazioni sulle risorse condivise (le cosiddette
+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
opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
problematiche di questo tipo in cap.~\ref{cha:IPC}).
+Nel caso dei \textit{thread} invece la situazione è molto più delicata e
+sostanzialmente qualunque accesso in memoria (a buffer, variabili o altro) può
+essere soggetto a \textit{race condition} dato potrebbe essere interrotto in
+qualunque momento da un altro \textit{thread}. In tal caso occorre pianificare
+con estrema attenzione l'uso delle variabili ed utilizzare i vari meccanismi
+di sincronizzazione che anche in questo caso sono disponibili (torneremo su
+queste problematiche di questo tipo in cap.~\ref{sez:thread_xxx})
+
\itindbeg{deadlock} Un caso particolare di \textit{race condition} sono poi i
-cosiddetti \textit{deadlock} (traducibile in \textsl{condizioni di stallo}),
-particolarmente gravi in quanto comportano spesso il blocco completo di un
+cosiddetti \textit{deadlock} (traducibile in \textsl{condizione di stallo}),
+che 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 una operazione che
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.
+
\itindend{race~condition}
\itindend{deadlock}
parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano \index{variabili!statiche} 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}.}
+esempio utilizzano \index{variabili!statiche} variabili statiche, la
+\acr{glibc} però mette a disposizione due macro di compilatore,
\macro{\_REENTRANT} e \macro{\_THREAD\_SAFE}, la cui definizione attiva le
versioni rientranti di varie funzioni di libreria, che sono identificate
aggiungendo il suffisso \code{\_r} al nome della versione normale.
% LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
% LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
% LocalWords: sid thread Ingo Molnar ppid getpid getppid sys unistd LD threads
-% LocalWords: void ForkTest tempnam pathname sibling cap errno EAGAIN ENOMEM
+% LocalWords: void tempnam pathname sibling cap errno EAGAIN ENOMEM
% LocalWords: stack read only copy write tab client spawn forktest sleep PATH
% LocalWords: source LIBRARY scheduling race condition printf descriptor dup
% LocalWords: close group session tms lock vfork execve BSD stream main abort
% LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
% LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
% LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker
-% LocalWords: opendir libc interpreter FreeBSD capabilities Mandatory Access
-% LocalWords: Control MAC SELinux Security Modules LSM superuser uid gid saved
+% LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access
+% LocalWords: control MAC SELinux security modules LSM superuser uid gid saved
% LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
% LocalWords: getegid IDS NFS setuid setgid all' logout utmp screen xterm TODO
% LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size
% LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
% LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
% LocalWords: capability capget capset header ESRCH undef version obj clear PT
-% LocalWords: pag ssize length proc capgetp preemptive cache runnable
-% LocalWords: SIGSTOP soft slice nice niceness counter which SC
-% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO
+% LocalWords: pag ssize length proc capgetp preemptive cache runnable contest
+% LocalWords: SIGSTOP soft slice nice niceness counter which SC switch side
+% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO COUNT
% LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
% LocalWords: min getparam getscheduler interval robin ENOSYS fifo ping long
% LocalWords: affinity setaffinity unsigned mask cpu NUMA CLR ISSET SETSIZE RR
% LocalWords: waitid NOCLDSTOP ENOCHLD WIFCONTINUED ifdef endif idtype siginfo
% LocalWords: infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page
% LocalWords: CONTINUED sources forking Spawned successfully executing exiting
-% LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED PR
+% LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED PR effects
% LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
% LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT
% LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort
% LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
% LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
-% LocalWords: loader EISDIR SIGTRAP uninterrutible killable
+% LocalWords: loader EISDIR SIGTRAP uninterrutible killable EQUAL sizeof XOR
+% LocalWords: destset srcset ALLOC num cpus setsize emacs pager getty TID
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff