e poi il padre.
In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
-\itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione
-in cui si trova la macchina al momento della chiamata, risultando del tutto
-impredicibile. Eseguendo più volte il programma di prova e producendo un
-numero diverso di figli, si sono ottenute situazioni completamente diverse,
-compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
-prima che uno dei figli venisse messo in esecuzione.
+\itindex{scheduler} \textit{scheduling} usato dal kernel, dalla particolare
+situazione in cui si trova la macchina al momento della chiamata, risultando
+del tutto impredicibile. Eseguendo più volte il programma di prova e
+producendo un numero diverso di figli, si sono ottenute situazioni
+completamente diverse, compreso il caso in cui il processo padre ha eseguito
+più di una \func{fork} prima che uno dei figli venisse messo in esecuzione.
Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
-processi figli tutti i file descriptor (vedi sez.~\ref{sec:file_fd}) dei file
-aperti nel processo padre (allo stesso modo in cui lo fa la funzione
+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:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
\item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
- sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i file descriptor,
- questo significa che entrambi condivideranno gli stessi flag.
+ sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i \textit{file
+ descriptor}, questo significa che entrambi condivideranno gli stessi flag.
\end{itemize*}
Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
rilascia la memoria che stava usando, e così via; l'elenco completo delle
operazioni eseguite alla chiusura di un processo è il seguente:
\begin{itemize*}
-\item tutti i file descriptor sono chiusi;
+\item tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd}) sono
+ chiusi;
\item viene memorizzato lo stato di terminazione del processo;
\item ad ogni processo figlio viene assegnato un nuovo padre (in genere
\cmd{init});
colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
il padre effettuerà la lettura dello stato di terminazione anche questa
informazione, non più necessaria, verrà scartata ed il processo potrà
-considerarso completamente concluso.
+considerarsi completamente concluso.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
specificare in maniera flessibile quale processo attendere, sulla base del
valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
-sono riportate anche le costanti definite per indicare alcuni di essi.
+sono riportate anche le costanti definite per indicare alcuni di essi.
\begin{table}[!htb]
\centering
$<-1$& -- & Attende per un figlio il cui
\itindex{process~group} \textit{process group}
(vedi sez.~\ref{sec:sess_proc_group}) è uguale
- al valore assoluto di \param{pid}. \\
+ al valore assoluto di \param{pid}.\\
$-1$&\const{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
questa maniera senza specificare nessuna opzione
è equivalente a \func{wait}.\\
$ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui
\itindex{process~group} \textit{process group}
(vedi sez.~\ref{sec:sess_proc_group}) è
- uguale a quello del processo chiamante. \\
+ uguale a quello del processo chiamante.\\
$>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
al valore di \param{pid}.\\
\hline
deve essere specificato come maschera binaria delle costanti riportati nella
prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
-tabella si sono riportati anche alcuni valori non standard specifici di Linux,
-che consentono un controllo più dettagliato per i processi creati con la
-\textit{system call} generica \func{clone} (vedi sez.~\ref{sec:process_clone})
-usati principalmente per la gestione della terminazione dei \itindex{thread}
-\textit{thread} (vedi sez.~\ref{sec:thread_xxx}).
+tabella si sono riportati anche alcune opzioni non standard specifiche di
+Linux, che consentono un controllo più dettagliato per i processi creati con
+la \textit{system call} generica \func{clone} (vedi
+sez.~\ref{sec:process_clone}) e che vengono usati principalmente per la
+gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
+sez.~\ref{sec:thread_xxx}).
\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Valore} & \textbf{Descrizione}\\
+ \textbf{Costante} & \textbf{Descrizione}\\
\hline
\hline
\const{WNOHANG} & La funzione ritorna immediatamente anche se non è
- terminato nessun processo figlio. \\
- \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
+ terminato nessun processo figlio.\\
+ \const{WUNTRACED} & Ritorna anche quando un processo figlio è stato
+ fermato.\\
\const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
- fermato ha ripreso l'esecuzione.\footnotemark \\
+ fermato ha ripreso l'esecuzione (disponibile solo a
+ partire dal kernel 2.6.10).\\
\hline
\const{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
(vedi sez.~\ref{sec:process_clone}), vale a dire
processi che non emettono nessun segnale
o emettono un segnale diverso da \signal{SIGCHLD} alla
- terminazione. \\
- \const{\_\_WALL} & Attende per qualunque processo figlio. \\
+ terminazione, il default è attendere soltanto i
+ processi figli ordinari ignorando quelli creati da
+ \func{clone}.\\
+ \const{\_\_WALL} & Attende per qualunque figlio, sia ordinario che creato
+ con \func{clone}, se specificata insieme a
+ \const{\_\_WCLONE} quest'ultima viene ignorata. \\
\const{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
- dello stesso gruppo. \\
+ dello stesso \textit{thread group}, questo era il
+ comportamento di default del kernel 2.4 che non
+ supportava la possibilità, divenuta il default a
+ partire dal 2.6, di attendere un qualunque figlio
+ appartenente allo stesso \textit{thread group}. \\
\hline
\end{tabular}
\caption{Costanti che identificano i bit dell'argomento \param{options}
\label{tab:proc_waitpid_options}
\end{table}
-\footnotetext{disponibile solo a partire dal kernel 2.6.10.}
L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
-funzione qualora nessun figlio sia uscito (o non si siano verificate le altre
-condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
-valore nullo anziché positivo.\footnote{anche in questo caso un valore
- positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
- ed un valore negativo un errore.}
+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
+positivo) ritornerà un valore nullo.
-Le altre due opzioni \const{WUNTRACED} e \const{WCONTINUED} consentono
+Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
rispettivamente di tracciare non la terminazione di un processo, ma il fatto
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}).
mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato
\textit{stopped} riprende l'esecuzione per la ricezione del segnale
\signal{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
-dettagliato in sez.~\ref{sec:sess_ctrl_term}).
+trattato in sez.~\ref{sec:sess_ctrl_term}).
La terminazione di un processo figlio (così come gli altri eventi osservabili
con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
-standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1
- che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.}
-e come da esso richiesto se \signal{SIGCHLD} viene ignorato, o se si imposta il
-flag di \const{SA\_NOCLDSTOP} nella ricezione dello stesso (si veda
-sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano
-\textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che
-tutti i processi figli non sono terminati, dopo di che falliscono con un
-errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
- opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto
- qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale
- \signal{SIGCHLD}.}
+standard POSIX.1-2001 e come da esso richiesto se \signal{SIGCHLD} viene
+ignorato, o se si imposta il flag di \const{SA\_NOCLDSTOP} nella ricezione
+dello stesso (si veda sez.~\ref{sec:sig_sigaction}) i processi figli che
+terminano non diventano \textit{zombie} e sia \func{wait} che \func{waitpid}
+si bloccano fintanto che tutti i processi figli non sono terminati, dopo di
+che falliscono con un errore di \errcode{ENOCHLD}.\footnote{questo è anche il
+ motivo per cui le opzioni \const{WUNTRACED} e \const{WCONTINUED} sono
+ utilizzabili soltanto qualora non si sia impostato il flag di
+ \const{SA\_NOCLDSTOP} per il segnale \signal{SIGCHLD}.}
Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe
-le funzioni di attesa ignorano questa prescrizione\footnote{lo standard POSIX.1
- originale infatti lascia indefinito il comportamento di queste funzioni
- quando \signal{SIGCHLD} viene ignorato.} e si comportano sempre nello stesso
-modo, indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
+le funzioni di attesa ignorano questa prescrizione e si comportano sempre
+nello stesso modo,\footnote{lo standard POSIX.1 originale infatti lascia
+ 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}.
+In generale in un programma non si vuole essere forzati ad attendere la
+conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
+questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
+la presenza di \itindex{zombie} \textit{zombie}). Per questo la modalità più
+comune di chiamare queste funzioni è quella di utilizzarle all'interno di un
+\textit{signal handler} (vedremo un esempio di come gestire \signal{SIGCHLD}
+con i segnali in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che
+il segnale è generato dalla terminazione di un figlio, avremo la certezza che
+la chiamata a \func{waitpid} non si bloccherà.
+
+Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
+terminazione del processo tramite il puntatore \param{status}, e se non
+interessa memorizzare lo stato si può passare un puntatore nullo. Il valore
+restituito da entrambe le funzioni dipende dall'implementazione, ma
+tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare
+lo \itindex{exit~status} stato di uscita del processo, e gli altri per
+indicare il segnale che ha causato la terminazione (in caso di conclusione
+anomala), uno per indicare se è stato generato un \itindex{core~dump}
+\textit{core dump}, ecc.\footnote{le definizioni esatte si possono trovare in
+ \file{<bits/waitstatus.h>} ma questo file non deve mai essere usato
+ direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
+
\begin{table}[!htb]
\centering
\footnotesize
\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}.\footnotemark \\
+ 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
\label{tab:proc_status_macro}
\end{table}
-\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
+\footnotetext{questa macro non è definita dallo standard POSIX.1-2001, ma è
presente come estensione sia in Linux che in altri Unix, deve essere
pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
-\footnotetext{è presente solo a partire dal kernel 2.6.10.}
-
-In generale in un programma non si vuole essere forzati ad attendere la
-conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
-questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
-la presenza di \itindex{zombie} \textit{zombie}).
-
-Per questo la modalità più comune di chiamare queste funzioni è quella di
-utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
-come gestire \signal{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
-questo caso infatti, dato che il segnale è generato dalla terminazione di un
-figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
-
-Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
-terminazione del processo tramite il puntatore \param{status} (se non
-interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
-restituito da entrambe le funzioni dipende dall'implementazione, ma
-tradizionalmente alcuni bit (in genere 8) sono riservati per memorizzare lo
-stato di uscita, e altri per indicare il segnale che ha causato la
-terminazione (in caso di conclusione anomala), uno per indicare se è stato
-generato un \itindex{core~dump} \textit{core dump}, ecc.\footnote{le
- definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
- questo file non deve mai essere usato direttamente, esso viene incluso
- attraverso \file{<sys/wait.h>}.}
-
Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
analizzare lo stato di uscita. Esse sono definite sempre in
-\file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro}; si tenga
+\file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro}. Si tenga
presente che queste macro prevedono che gli si passi come parametro la
variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito
da \func{wait} o \func{waitpid}.
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:
+definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/times.h}
\fhead{sys/resource.h}
\fhead{sys/wait.h}
-\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage))}
+\fdecl{int wait3(int *status, int options, struct rusage *rusage)}
+\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage)}
\fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
- delle risorsr.}
+ delle risorse.}
}
{La funzione ha gli stessi valori di ritorno e codici di errore di
\func{waitpid}. }
\end{funcproto}
+La funzione \func{wait4} è identica \func{waitpid} sia nel comportamento che
+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
+\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
+funzione \func{wait3} è semplicemente un caso particolare di (e con Linux
+viene realizzata con la stessa \textit{system call}), ed è equivalente a
+chiamare \code{wait4(-1, \&status, opt, rusage)}, per questo motivo è ormai
+deprecata in favore di \func{wait4}.
-\begin{functions}
- \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
- \headdecl{sys/resource.h}
-
- \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
- *rusage)}
- È identica a \func{waitpid} sia per comportamento che per i valori degli
- argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
- dal processo.
-
- \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
- Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
- ormai deprecata in favore di \func{wait4}.
-\end{functions}
-\noindent
-la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
-utilizzata anche dalla funzione \func{getrusage} (vedi
-sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
-processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
-
-
-\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
+
+
+\subsection{La famiglia delle funzioni \func{exec} per l'esecuzione dei
+ programmi}
\label{sec:proc_exec}
Abbiamo già detto che una delle modalità principali con cui si utilizzano i
processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
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 \acr{pid} del processo non cambia, dato che non viene
creato un nuovo processo, la funzione semplicemente rimpiazza lo
-\itindex{stack} \textit{stack}, lo \itindex{heap} \textit{heap}, i
-\index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
-corrente con un nuovo programma letto da disco.
+\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il
+\index{segmento!testo} testo del processo corrente con un nuovo programma
+letto da disco, eseguendo il \itindex{link-loader} \textit{link-loader} con
+gli effetti illustrati in sez.~\ref{sec:proc_main}.
Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
famiglia di funzioni) che possono essere usate per questo compito, in realtà
-(come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
-\funcd{execve}. Il prototipo di quest'ultima è:
-\begin{prototype}{unistd.h}
-{int execve(const char *filename, char *const argv[], char *const envp[])}
- Esegue il programma contenuto nel file \param{filename}.
-
- \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
- qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
- montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
+(come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
+tutte varianti che consentono di invocare in modi diversi, semplificando il
+passaggio degli argomenti, la \textit{system call} \funcd{execve}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int execve(const char *filename, char *const argv[], char *const envp[])}
+\fdesc{Esegue un programma.}
+}
+{La funzione ritorna solo in caso di errore, restituendo $-1$, nel qual
+ caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+ \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}, l'utente non è root, il processo viene
- tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
+ \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{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
riconoscibile.
\item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
\end{errlist}
- ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
- \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
- \errval{EMFILE}.}
-\end{prototype}
-
-La funzione \func{exec} esegue il file o lo script indicato da
-\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
+ ed inoltre \errval{EFAULT}, \errval{ENOMEM},
+ \errval{EIO}, \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR},
+ \errval{EISDIR}, \errval{ENFILE}, \errval{EMFILE} 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
+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[])}.
-Le altre funzioni della famiglia servono per fornire all'utente una serie di
-possibili diverse interfacce per la creazione di un nuovo processo. I loro
-prototipi sono:
-\begin{functions}
-\headdecl{unistd.h}
-\funcdecl{int execl(const char *path, const char *arg, ...)}
-\funcdecl{int execv(const char *path, char *const argv[])}
-\funcdecl{int execle(const char *path, const char *arg, ..., char
-* const envp[])}
-\funcdecl{int execlp(const char *file, const char *arg, ...)}
-\funcdecl{int execvp(const char *file, char *const argv[])}
-
-Sostituiscono l'immagine corrente del processo con quella indicata nel primo
-argomento. Gli argomenti successivi consentono di specificare gli argomenti a
-linea di comando e l'ambiente ricevuti dal nuovo processo.
-
-\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
- nel qual caso \var{errno} assumerà i valori visti in precedenza per
- \func{execve}.}
-\end{functions}
-
-Per capire meglio le differenze fra le funzioni della famiglia si può fare
-riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
-prima differenza riguarda le modalità di passaggio dei valori che poi andranno
-a costituire gli argomenti a linea di comando (cioè i valori di
-\param{argv} e \param{argc} visti dalla funzione \func{main} del programma
-chiamato).
-
-Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
-che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
-gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
-stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
-questo vettore \emph{deve} essere terminato da un puntatore nullo.
-
-Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
-lista di puntatori, nella forma:
-\includecodesnip{listati/char_list.c}
-che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
-convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
-per indicare il nome del file che contiene il programma che verrà eseguito.
+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
+il processo corrente è tracciato con \func{ptrace} (vedi
+sez.~\ref{sec:process_ptrace}) in caso di successo viene emesso il segnale
+\signal{SIGTRAP}.
+
+Le altre funzioni della famiglia (\funcd{execl}, \funcd{execv},
+\funcd{execle}, \funcd{execlp}, \funcd{execvp}) servono per fornire all'utente
+una serie di possibili diverse interfacce nelle modalità di passaggio degli
+argomenti all'esecuzione del nuovo programma. I loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int execl(const char *path, const char *arg, ...)}
+\fdecl{int execv(const char *path, char *const argv[])}
+\fdecl{int execle(const char *path, const char *arg, ..., char * const envp[])}
+\fdecl{int execlp(const char *file, const char *arg, ...)}
+\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
+ errore sono gli stessi di \func{execve}.
+}
+\end{funcproto}
+
+Tutte le funzioni mettono in esecuzione nel processo corrente il programma
+indicati nel primo argomento. Gli argomenti successivi consentono di
+specificare gli argomenti e l'ambiente che saranno ricevuti dal nuovo
+processo. Per capire meglio le differenze fra le funzioni della famiglia si può
+fare riferimento allo specchietto riportato in
+tab.~\ref{tab:proc_exec_scheme}. La relazione fra le funzioni è invece
+illustrata in fig.~\ref{fig:proc_exec_relat}.
\begin{table}[!htb]
\footnotesize
\label{tab:proc_exec_scheme}
\end{table}
+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
+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}.
+
+Nel primo caso gli argomenti sono passati tramite il vettore di puntatori
+\var{argv[]} a stringhe terminate con zero che costituiranno gli argomenti a
+riga di comando, questo vettore \emph{deve} essere terminato da un puntatore
+nullo. Nel secondo caso le stringhe degli argomenti sono passate alla funzione
+come lista di puntatori, nella forma:
+\includecodesnip{listati/char_list.c}
+che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
+convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
+per indicare il nome del file che contiene il programma che verrà eseguito.
+
+
+\begin{figure}[!htb]
+ \centering \includegraphics[width=12cm]{img/exec_rel}
+ \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
+ \label{fig:proc_exec_relat}
+\end{figure}
+
La seconda differenza fra le funzioni riguarda le modalità con cui si
-specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
-indicano le due funzioni che replicano il comportamento della shell nello
+specifica il programma che si vuole eseguire. Con lo mnemonico ``\texttt{p}''
+si indicano le due funzioni che replicano il comportamento della shell nello
specificare il comando da eseguire; quando l'argomento \param{file} non
contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
e viene eseguita automaticamente una ricerca fra i file presenti nella lista
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
-\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.
-
-\begin{figure}[!htb]
- \centering \includegraphics[width=12cm]{img/exec_rel}
- \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
- \label{fig:proc_exec_relat}
-\end{figure}
+\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.
La terza differenza è come viene passata la lista delle variabili di ambiente.
-Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
-di un vettore di parametri \var{envp[]} analogo a quello usato per gli
-argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
+Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
+necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per
+gli argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
usano il valore della variabile \var{environ} (vedi
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
-\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
-lista delle più significative è la seguente:
+Oltre a mantenere lo stesso \acr{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 l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group}
- \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
-\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
-\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
\item la directory radice e la 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});
+\item il valori di \textit{nice}, le priorità real-time e le affinità di
+ processore (vedi sez.~\ref{sec:proc_sched_stand};
+ sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
+\item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group}
+ \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
+\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
+\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
\var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
Una serie di proprietà del processo originale, che non avrebbe senso mantenere
in un programma che esegue un codice completamente diverso in uno spazio di
indirizzi totalmente indipendente e ricreato da zero, vengono perse con
-l'esecuzione di \func{exec}; lo standard POSIX.1-2001 prevede che le seguenti
-proprietà non vengano preservate:
+l'esecuzione di una \func{exec}. Lo standard POSIX.1-2001 prevede che le
+seguenti proprietà non vengano preservate:
\begin{itemize*}
\item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
viene cancellato;
\item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
\item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
-\item i blocchi sulla memoria (vedi sez.~\ref{sec:proc_mem_lock});
+\item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
\item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
\item i semafori e le code di messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
\item i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}).
\end{itemize*}
-I segnali che sono stati impostati per essere ignorati nel processo chiamante
-mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri
-segnali, ed in particolare quelli per i quali è stato installato un gestore
-vengono impostati alla loro azione predefinita (vedi
+Inoltre i segnali che sono stati impostati per essere ignorati nel processo
+chiamante mantengono la stessa impostazione pure nel nuovo programma, ma tutti
+gli altri segnali, ed in particolare quelli per i quali è stato installato un
+gestore vengono impostati alla loro azione predefinita (vedi
sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD}
che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
-\const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard
- POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola
- implementazione, quella di Linux è di non modificare l'impostazione
- precedente.}
+\const{SIG\_DFL}. Lo standard POSIX.1-2001 prevede che questo comportamento
+sia deciso dalla singola implementazione, quella di Linux è di non modificare
+l'impostazione precedente.
-Oltre alle precedenti che sono completamente generali e disponibili anche su
-altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
+Oltre alle precedenti, che sono completamente generali e disponibili anche su
+altri sistemi unix-like, esistono altre proprietà dei processi, attinenti alle
caratteristiche specifiche di Linux, che non vengono preservate
nell'esecuzione della funzione \func{exec}, queste sono:
\begin{itemize*}
-\item le operazione di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
+\item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
pendenti vengono cancellate;
\item le \itindex{capabilities} \textit{capabilities} vengono modificate come
illustrato in sez.~\ref{sec:proc_capabilities};
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
-\textit{close-on-exec} (vedi anche sez.~\ref{sec:file_fcntl}) per ciascun file
-descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
-restano aperti. Questo significa che il comportamento predefinito è che i file
-restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
-\func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
-POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
-questo è fatto dalla funzione \func{opendir} (vedi
+\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl}) 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
+esplicita a \func{fcntl} che imposti il suddetto flag. Per le directory, lo
+standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec},
+in genere questo è fatto dalla funzione \func{opendir} (vedi
sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
\itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
maniera trasparente all'utente.
come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il
-\textsl{group-ID effettivo}, questi ultimi normalmente non vengono modificati,
+\textsl{group-ID effettivo}. Questi ultimi normalmente non vengono modificati,
a meno che il file di cui viene chiesta l'esecuzione non abbia o il
\itindex{suid~bit} \acr{suid} bit o lo \itindex{sgid~bit} \acr{sgid} bit
impostato, in questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID
collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
collegati con le \acr{glibc}.
-Infine nel caso il file sia uno script esso deve iniziare con una linea nella
-forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato
-deve essere un programma valido (binario, non un altro script) che verrà
-chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
- filename}.\footnote{si tenga presente che con Linux quanto viene scritto
- come \texttt{argomenti} viene passato all'interprete come un unico argomento
- con una unica stringa di lunghezza massima di 127 caratteri e se questa
- dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
- dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
- esegue la scansione della riga e la divide nei vari argomenti e se è troppo
- lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
- vari comportamenti si trova su
- \href{http://www.in-ulm.de/~mascheck/various/shebang/}
- {\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
+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]
+\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
+\cmd{interpreter [argomenti] filename}.\footnote{si tenga presente che con
+ Linux quanto viene scritto come \texttt{argomenti} viene passato
+ all'interprete come un unico argomento con una unica stringa di lunghezza
+ massima di 127 caratteri e se questa dimensione viene ecceduta la stringa
+ viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
+ comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
+ nei vari argomenti e se è troppo lunga restituisce un errore di
+ \const{ENAMETOOLONG}, una comparazione dei vari comportamenti si trova su
+ \url{http://www.in-ulm.de/~mascheck/various/shebang/}.}
Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
-basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
-processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
-\func{wait} si effettua e verifica la conclusione dei processi. Tutte le
-altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
-vari parametri connessi ai processi.
+basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
+un nuovo processo, con \func{exec} si lancia un nuovo programma, con
+\func{exit} e \func{wait} si effettua e verifica la conclusione dei
+processi. Tutte le altre funzioni sono ausiliarie e servono per la lettura e
+l'impostazione dei vari parametri connessi ai processi.
infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
\textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
a livello del kernel per modularizzare tutti i possibili controlli di
- accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
-utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root},
-detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
-il resto degli utenti, per i quali invece vengono effettuati i vari controlli
-di accesso.
+ accesso, cosa che ha permesso di realizzare diverse alternative a
+ \index{SELinux} SELinux.} di sicurezza di un sistema unix-like è fondato sui
+concetti di utente e gruppo, e sulla separazione fra l'amministratore
+(\textsl{root}, detto spesso anche \textit{superuser}) che non è sottoposto a
+restrizioni, ed il resto degli utenti, per i quali invece vengono effettuati i
+vari controlli di accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
-identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
+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.
+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.
Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
Un semplice controllo di una corrispondenza fra identificativi non garantisce
però sufficiente flessibilità per tutti quei casi in cui è necessario poter
disporre di privilegi diversi, o dover impersonare un altro utente per un
-limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
-prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
-rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
-\textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
-\textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
- filesystem}), secondo la situazione illustrata in
-tab.~\ref{tab:proc_uid_gid}.
+limitato insieme di operazioni. Per questo motivo in generale tutti i sistemi
+unix-like prevedono che i processi abbiano almeno due gruppi di
+identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}
+(cioè \textsl{reali} ed \textsl{effettivi}). Nel caso di Linux si aggiungono
+poi altri due gruppi, il \textit{saved} (\textsl{salvati}) ed il
+\textit{filesystem} (\textsl{di filesystem}), secondo la situazione illustrata
+in tab.~\ref{tab:proc_uid_gid}.
\begin{table}[htb]
\footnotesize
\label{tab:proc_uid_gid}
\end{table}
-Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID
- reale}: questi vengono impostati al login ai valori corrispondenti
+Al primo gruppo appartengono l'\acr{uid} \textsl{reale} ed il \acr{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
cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
imposta questi identificatori ai valori corrispondenti all'utente che entra
nel sistema.
-Al secondo gruppo appartengono lo \textsl{user-ID effettivo} ed il
-\textsl{group-ID effettivo} (a cui si aggiungono gli eventuali \textsl{group-ID
- 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
+Al secondo gruppo appartengono l'\acr{uid} \textsl{effettivo} e il \acr{gid}
+\textsl{effettivo}, a cui si aggiungono gli eventuali \acr{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
sez.~\ref{sec:file_perm_overview}).
Questi identificatori normalmente sono identici ai corrispondenti del gruppo
(il significato di questi bit è affrontato in dettaglio in
sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
all'utente e al gruppo proprietari del file. Questo consente, per programmi in
-cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
-di un altro (o dell'amministratore).
+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
-identificatori possono essere letti attraverso le rispettive funzioni:
-\funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, i loro
-prototipi sono:
-\begin{functions}
- \headdecl{unistd.h}
- \headdecl{sys/types.h}
- \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{user-ID reale} del
- processo corrente.
+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:
- \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{user-ID effettivo} del
- processo corrente.
-
- \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{group-ID reale} del
- processo corrente.
-
- \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{group-ID effettivo}
- del processo corrente.
-
- \bodydesc{Queste funzioni non riportano condizioni di errore.}
-\end{functions}
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{uid\_t getuid(void)}
+\fdesc{Legge l'\textsl{user-ID reale} del processo corrente.}
+\fdecl{uid\_t geteuid(void)}
+\fdesc{Legge l'\textsl{user-ID effettivo} del processo corrente.}
+\fdecl{gid\_t getgid(void)}
+\fdesc{Legge il \textsl{group-ID reale} del processo corrente.}
+\fdecl{gid\_t getegid(void)}
+\fdesc{Legge il \textsl{group-ID 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 deve essere limitato il più
+In generale l'uso di privilegi superiori, ottenibile con un \acr{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
maggiori privilegi necessari, una volta che si siano effettuate le operazioni
del programma su altri Unix è buona norma controllare sempre la
disponibilità di queste funzioni controllando se questa costante è
definita.} il secondo gruppo è specifico di Linux e viene usato per
-migliorare la sicurezza con NFS.
-
-L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
-dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo
-padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
-come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID 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
+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
+processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
+processo, come copie dell'\acr{uid} \textsl{effettivo} e del \acr{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'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
+L'\acr{uid} \textsl{di filesystem} e il \acr{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
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:
-\begin{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-\funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{user-ID} del processo
-corrente.
-
-\funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{group-ID} del processo
-corrente.
-
-\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
-\end{functions}
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int setuid(uid\_t uid)}
+\fdesc{Imposta l'\acr{uid} del processo corrente.}
+\fdecl{int setgid(gid\_t gid)}
+\fdesc{Imposta il \acr{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}.
+}
+\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 \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
-eventuali \textsl{group-ID supplementari} non vengono modificati.
+la prima, la seconda si comporta esattamente allo stesso modo facendo
+riferimento al \acr{gid} invece che all'\acr{uid}. Gli eventuali \acr{gid}
+supplementari non vengono modificati.
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
-sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
+l'\acr{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'\textsl{user-ID effettivo}, e soltanto se il
-valore specificato corrisponde o all'\textsl{user-ID reale} o
-all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
-\errcode{EPERM}).
+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
+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'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
-il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi,
-ed eventualmente tornare indietro.
+\itindex{sgid~bit} \acr{sgid} impostati (vedi
+sez.~\ref{sec:file_special_perm}) di riportare l'\acr{uid} effettivo a quello
+dell'utente che ha lanciato il programma, effettuare il lavoro che non
+necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
-viene gestito l'accesso al file \sysfile{/var/log/utmp}. In questo file viene
+viene gestito l'accesso al file \sysfile{/var/run/utmp}. In questo file viene
registrato chi sta usando il sistema al momento corrente; chiaramente non può
essere lasciato aperto in scrittura a qualunque utente, che potrebbe
falsificare la registrazione. Per questo motivo questo file (e l'analogo
\sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
-ad un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
-esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
-crea terminali multipli su una console) appartengono a questo gruppo ed hanno
-il bit \acr{sgid} impostato.
+ad un gruppo dedicato (in genere \acr{utmp}) ed i programmi che devono
+accedervi (ad esempio tutti i programmi di terminale in X, o il programma
+\cmd{screen} che crea terminali multipli su una console) appartengono a questo
+gruppo ed hanno il bit \acr{sgid} impostato.
Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
situazione degli identificatori è la seguente:
\textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
-programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
+programma può accedere a \sysfile{/var/run/utmp} in scrittura ed aggiornarlo.
A questo punto il programma può eseguire una \code{setgid(getgid())} per
impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
\textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
\end{eqnarray*}
e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
-aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
+aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
\acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
-consentendo l'accesso a \sysfile{/var/log/utmp}.
+consentendo l'accesso a \sysfile{/var/run/utmp}.
Occorre però tenere conto che tutto questo non è possibile con un processo con
i privilegi di amministratore, in tal caso infatti l'esecuzione di una
\func{setuid} comporta il cambiamento di tutti gli identificatori associati al
processo, rendendo impossibile riguadagnare i privilegi di amministratore.
Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
-crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
+crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto
l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
ricorrere ad altre funzioni.
Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
-supportando\footnote{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{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-
-\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{user-ID
- reale} e l'\textsl{user-ID effettivo} del processo corrente ai valori
-specificati da \param{ruid} e \param{euid}.
-
-\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{group-ID
- reale} ed il \textsl{group-ID effettivo} del processo corrente ai valori
-specificati da \param{rgid} e \param{egid}.
-
-\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
-\end{functions}
-
-La due funzioni sono analoghe ed il loro comportamento è identico; quanto
-detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda
-per il group-ID. I processi non privilegiati possono impostare solo i valori
-del loro user-ID effettivo o reale; valori diversi comportano il fallimento
-della chiamata; l'amministratore invece può specificare un valore qualunque.
-Specificando un argomento di valore -1 l'identificatore corrispondente verrà
-lasciato inalterato.
-
-Con queste funzioni si possono scambiare fra loro gli user-ID reale e
+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.}
+\fdecl{int setregid(gid\_t rgid, gid\_t egid)}
+\fdesc{Imposta \acr{gid} reale e \acr{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}.
+}
+\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}
+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
+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
effettivo, e pertanto è possibile implementare un comportamento simile a
quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
-scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
-scambio.
+scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
+un secondo scambio.
In questo caso però occorre porre molta attenzione quando si creano nuovi
processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
+questo caso infatti essi avranno un \acr{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'user-ID reale a quello effettivo) in
-caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
-e riottenere privilegi non previsti.
+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,
+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 per l'user-ID salvato: questa funzione deriva da un'implementazione che
-non ne prevede la presenza, e quindi non è possibile usarla per correggere la
-situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
-che si imposta un qualunque valore diverso da quello dall'user-ID reale
-corrente, l'user-ID salvato viene automaticamente uniformato al valore
-dell'user-ID effettivo.
+si pone anche per l'\acr{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.
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
+Unix, esse vengono usate per cambiare gli identificatori del gruppo
\textit{effective} ed i loro prototipi sono:
-\begin{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-
-\funcdecl{int seteuid(uid\_t uid)} Imposta l'user-ID effettivo del processo
-corrente a \param{uid}.
-
-\funcdecl{int setegid(gid\_t gid)} Imposta il group-ID effettivo del processo
-corrente a \param{gid}.
-
-\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore è \errval{EPERM}.}
-\end{functions}
-
-Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
-la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
-valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
-specificare qualunque valore. Queste funzioni sono usate per permettere
-all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
-normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
-
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/types.h}
+\fdecl{int seteuid(uid\_t uid)}
+\fdesc{Imposta l'\acr{uid} effettivo del processo corrente.}
+\fdecl{int setegid(gid\_t gid)}
+\fdesc{Imposta il \acr{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}.
+}
+\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,
+l'amministratore può specificare qualunque valore. Queste funzioni sono usate
+per permettere all'amministratore di impostare solo l'\acr{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
-un'estensione introdotta in Linux,\footnote{per essere precisi 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:
-\begin{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-
-\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
-l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente
-ai valori specificati rispettivamente da \param{ruid}, \param{euid} e
-\param{suid}.
-
-\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
-group-ID reale, il group-ID effettivo ed il group-ID salvato del processo
-corrente ai valori specificati rispettivamente da \param{rgid}, \param{egid} e
-\param{sgid}.
-
-\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore è \errval{EPERM}.}
-\end{functions}
-
-Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
-si applica alla seconda per i group-ID. I processi non privilegiati possono
-cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
-all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
-può specificare i valori che vuole; un valore di -1 per un qualunque argomento
-lascia inalterato l'identificatore corrispondente.
-
-Per queste funzioni esistono anche due controparti che permettono di leggere
-in blocco i vari identificatori: \funcd{getresuid} e \funcd{getresgid}; i loro
-prototipi sono:
-\begin{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-
-\funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
-l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente.
-
-\funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
-group-ID reale, il group-ID effettivo e il group-ID salvato del processo
-corrente.
+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:
-\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
- fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
- variabili di ritorno non sono validi.}
-\end{functions}
+\begin{funcproto}{
+\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.}
+\fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
+\fdesc{Imposta il \acr{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}.
+}
+\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
+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
+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
+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.}
+\fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
+\fdesc{Legge il \acr{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
+ indirizzi delle variabili di ritorno non sono validi. }
+\end{funcproto}
Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
nessun privilegio. I valori sono restituiti negli argomenti, che vanno
queste funzioni sono le uniche in grado di leggere gli identificatori del
gruppo \textit{saved}.
-
Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
controllo dell'accesso ai file. Come già accennato in
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'user-ID effettivo o l'user-ID reale il server si espone alla
-ricezione di eventuali segnali ostili da parte dell'utente di cui ha
-temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
-ottengono i privilegi necessari per accedere ai file, mantenendo quelli
+fatto cambiando l'\acr{uid} effettivo o l'\acr{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
+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}, ovviamente sono specifiche di Linux e non devono essere
+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{functions}
-\headdecl{sys/fsuid.h}
-\funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'user-ID di filesystem del
-processo corrente a \param{fsuid}.
-
-\funcdecl{int setfsgid(gid\_t fsgid)} Imposta il group-ID di filesystem del
-processo corrente a \param{fsgid}.
+\begin{funcproto}{
+\fhead{sys/fsuid.h}
+\fdecl{int setfsuid(uid\_t fsuid)}
+\fdesc{Imposta l'\acr{uid} di filesystem del processo corrente.}
+\fdecl{int setfsgid(gid\_t fsgid)}
+\fdesc{Legge il \acr{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ò
+ impostato nessun codice di errore in \var{errno}.}
+\end{funcproto}
-\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
- di fallimento: l'unico errore possibile è \errval{EPERM}.}
-\end{functions}
-\noindent queste funzioni hanno successo solo se il processo chiamante ha i
-privilegi di amministratore o, per gli altri utenti, se il valore specificato
-coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
-\textit{saved}.
+Le due funzioni sono analoghe ed usano il valore passato come argomento per
+effettuare l'impostazione dell'identificativo. Le funzioni hanno successo
+solo se il processo chiamante ha i privilegi di amministratore o, per gli
+altri utenti, se il valore specificato coincide con uno dei di quelli del
+gruppo \textit{real}, \textit{effective} o \textit{saved}.
\subsection{Le funzioni per la gestione dei gruppi associati a un processo}
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 è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{unistd.h}
-
- \funcdecl{int getgroups(int size, gid\_t list[])}
-
- Legge gli identificatori dei gruppi supplementari.
-
- \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
- successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
- i valori:
- \begin{errlist}
- \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
- \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
- minore del numero di gruppi supplementari del processo.
- \end{errlist}}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{unistd.h}
+\fdecl{int getgroups(int size, gid\_t list[])}
+\fdesc{Legge gli identificatori dei gruppi supplementari.}
+}
+{La funzione ritorna il numero di gruppi letti in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
+\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
+\item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
+ minore del numero di gruppi supplementari del processo.
+\end{errlist}}
+\end{funcproto}
La funzione legge gli identificatori dei gruppi supplementari del processo sul
-vettore \param{list} di dimensione \param{size}. Non è specificato se la
-funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
-specifica un valore di \param{size} uguale a 0 \param{list} non viene
-modificato, ma si ottiene il numero di gruppi supplementari.
+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
+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.
Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
-ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{grp.h}
-
- \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
- int *ngroups)} Legge i gruppi supplementari.
-
- \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
- restituisce 0 in caso di successo e -1 in caso di fallimento.}
-\end{functions}
-
-La funzione legge i gruppi supplementari dell'utente specificato da
-\param{user}, eseguendo una scansione del database dei gruppi (si veda
-sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di
-quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
-puntatore perché, qualora il valore specificato sia troppo piccolo, la
-funzione ritorna -1, passando indietro il numero dei gruppi trovati.
-
-Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
-possono essere usate solo se si hanno i privilegi di amministratore. La prima
-delle due è \funcd{setgroups}, ed il suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{grp.h}
-
- \funcdecl{int setgroups(size\_t size, gid\_t *list)}
-
- Imposta i gruppi supplementari del processo.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà i valori:
- \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.
- \end{errlist}}
-\end{functions}
+ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{grp.h}
+\fdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, int
+ *ngroups)}
+\fdesc{Legge i gruppi cui appartiene un utente.}
+}
+{La funzione ritorna il numero di gruppi ottenuto in caso di successo e $-1$
+ per un errore, che avviene solo quando il numero di gruppi è maggiore di
+ quelli specificati con \param{ngroups}.}
+\end{funcproto}
+
+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
+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},
+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
+comunque indietro il numero dei gruppi trovati, in modo da poter ripetere la
+chiamata con un vettore di dimensioni adeguate.
+
+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
+ poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
+il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{grp.h}
+\fdecl{int setgroups(size\_t size, gid\_t *list)}
+\fdesc{Imposta i gruppi supplementari del 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{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.
+\end{errlist}}
+\end{funcproto}
La funzione imposta i gruppi supplementari del processo corrente ai valori
specificati nel vettore passato con l'argomento \param{list}, di dimensioni
-date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
-un parametro di sistema, che può essere ricavato con le modalità spiegate in
-sez.~\ref{sec:sys_characteristics}.
+date dall'argomento \param{size}. Il numero massimo di gruppi supplementari
+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 è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{grp.h}
- \funcdecl{int initgroups(const char *user, gid\_t group)}
-
- Inizializza la lista dei gruppi supplementari.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
- \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
- per allocare lo spazio per informazioni dei gruppi.}
-\end{functions}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{grp.h}
+\fdecl{int initgroups(const char *user, gid\_t group)}
+\fdesc{Inizializza la lista dei gruppi supplementari.}
+}
+{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.
+\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}
-con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
+(di nuovo specificato per nome e non per \acr{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
\func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
banale.} Tutto questo comunque appartiene alle sottigliezze
dell'implementazione del kernel; dal punto di vista dei programmi che girano
-in user space, anche quando si hanno più processori (e dei processi che sono
-eseguiti davvero in contemporanea), le politiche di scheduling riguardano
-semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
-assegnazione sarà governata dai meccanismi di scelta delle priorità che
-restano gli stessi indipendentemente dal numero di processori.
+in \textit{user space}, anche quando si hanno più processori (e dei processi
+che sono eseguiti davvero in contemporanea), le politiche di
+\textit{scheduling} riguardano semplicemente l'allocazione della risorsa
+\textsl{tempo di esecuzione}, la cui assegnazione sarà governata dai
+meccanismi di scelta delle priorità che restano gli stessi indipendentemente
+dal numero di processori.
Si tenga conto poi che i processi non devono solo eseguire del codice: ad
esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
risorse che sono necessarie per l'esecuzione di un programma, e a seconda
-dello scopo del programma non è detto neanche che sia la più importante (molti
-programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
-non è affatto detto che dare ad un programma la massima priorità di esecuzione
-abbia risultati significativi in termini di prestazioni.
+dello scopo del programma non è detto neanche che sia la più importante, dato
+che molti programmi dipendono in maniera molto più critica dall'I/O. Per
+questo motivo non è affatto detto che dare ad un programma la massima priorità
+di esecuzione abbia risultati significativi in termini di prestazioni.
-Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
+Il meccanismo tradizionale di \textit{scheduling} di Unix (che tratteremo in
sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
\textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
-i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando
-un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
-alla fine, anche un processo con priorità iniziale molto bassa, finisce per
-avere una priorità sufficiente per essere eseguito.
+i meno importanti, potessero ricevere un po' di tempo di CPU. In sostanza
+quando un processo ottiene la CPU la sua priorità viene diminuita. In questo
+modo alla fine, anche un processo con priorità iniziale molto bassa, finisce
+per avere una priorità sufficiente per essere eseguito.
Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
alla normale priorità dinamica), per tenere conto dei sistemi
-real-time,\footnote{per sistema real-time si intende un sistema in grado di
- eseguire operazioni in un tempo ben determinato; in genere si tende a
- distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
- esecuzione di un programma siano determinabili con certezza assoluta (come
- nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
- tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
- occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
-processi che devono essere eseguiti in un determinato momento non debbano
-aspettare la conclusione di altri che non hanno questa necessità.
+\textit{real-time},\footnote{per sistema \textit{real-time} si intende un
+ sistema in grado di eseguire operazioni in un tempo ben determinato; in
+ genere si tende a distinguere fra l'\textit{hard real-time} in cui è
+ necessario che i tempi di esecuzione di un programma siano determinabili con
+ certezza assoluta (come nel caso di meccanismi di controllo di macchine,
+ dove uno sforamento dei tempi avrebbe conseguenze disastrose), e
+ \textit{soft-real-time} in cui un occasionale sforamento è ritenuto
+ accettabile.} in cui è vitale che i processi che devono essere eseguiti in
+un determinato momento non debbano aspettare la conclusione di altri che non
+hanno questa necessità.
Il concetto di priorità assoluta dice che quando due processi si contendono
l'esecuzione, vince sempre quello con la priorità assoluta più alta.
Ovviamente questo avviene solo per i processi che sono pronti per essere
eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
genere indicata con un numero intero, ed un valore più alto comporta una
-priorità maggiore. Su questa politica di scheduling torneremo in
+priorità maggiore. Su questa politica di \textit{scheduling} torneremo in
sez.~\ref{sec:proc_real_time}.
In generale quello che succede in tutti gli Unix moderni è che ai processi
A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
sono state introdotte delle varianti specifiche.} l'unico meccanismo di
-scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
-solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
-nella programmazione. Come accennato in Linux i processi ordinari hanno tutti
-una priorità assoluta nulla; quello che determina quale, fra tutti i processi
-in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
+\textit{scheduling} con il quale si avrà a che fare è quello tradizionale, che
+prevede solo priorità dinamiche. È di questo che, di norma, ci si dovrà
+preoccupare nella programmazione. Come accennato in Linux i processi ordinari
+hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti
+i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
\texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
varia nel corso dell'esecuzione di un processo.
tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
calcolata dallo scheduler a partire da un valore iniziale che viene
-\textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
+\textsl{diminuito} tutte le volte che un processo è in stato \textit{runnable}
ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
dinamica e la conseguente scelta di quale processo mettere in esecuzione
avviene con un algoritmo molto più complicato, che tiene conto anche della
trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
funzionamento dello scheduler si legga il quarto capitolo di
\cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
-tutti i processi in stato \textbf{Runnable}, quello che ha il valore di
+tutti i processi in stato \textit{runnable}, quello che ha il valore di
priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
del valore numerico ad esse associato è infatti invertito, un valore più
basso significa una priorità maggiore.} Il fatto che questo valore venga
questo parametro sta nel fatto che generalmente questo viene usato per
\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
confronti degli altri. I processi infatti vengono creati dal sistema con un
-valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
-specificando un valore positivo si avrà una \textit{time-slice} più breve ed
+valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
+valore di \textit{nice} positivo si avrà una \textit{time-slice} più breve ed
un valore di priorità dinamica iniziale più alto, mentre un valore negativo
darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
iniziale più basso.
-Esistono diverse funzioni che consentono di modificare la \textit{niceness} di
-un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
-corrente, il suo prototipo è:
-\begin{prototype}{unistd.h}
-{int nice(int inc)}
- Aumenta il valore di \var{nice} per il processo corrente.
-
- \bodydesc{La funzione ritorna zero o il nuovo valore di \var{nice} in caso
- di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
- i valori:
- \begin{errlist}
+Esistono diverse funzioni che consentono di indicare un valore di
+\textit{nice} di un processo; la più semplice è \funcd{nice}, che opera sul
+processo corrente, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int nice(int inc)}
+\fdesc{Aumenta il valore di \textit{nice} del processo corrente.}
+}
+{La funzione ritorna il nuovo valore di \textit{nice} in caso di successo e
+ $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+\begin{errlist}
\item[\errcode{EPERM}] non si ha il permesso di specificare un valore
di \param{inc} negativo.
- \end{errlist}}
-\end{prototype}
+\end{errlist}}
+\end{funcproto}
L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
-di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
+di \textit{nice} corrente, che può assumere valori compresi fra
\const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
$19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
il risultato nell'intervallo consentito. Valori positivi comportano maggiore
\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
-comportano invece un aumento della priorità. Con i kernel precedenti il
-2.6.12 solo l'amministratore\footnote{o un processo con la
- \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_NICE}, vedi
+comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
+solo l'amministratore\footnote{o un processo con la \itindex{capabilities}
+ \textit{capability} \const{CAP\_SYS\_NICE}, vedi
sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
di \param{inc} che permettono di aumentare la priorità di un processo, a
partire da questa versione è consentito anche agli utenti normali alzare
-(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
+(entro certi limiti, che vedremo in sez.~\ref{sec:sys_resource_limit}) la
+priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
-di \var{nice} del processo; tuttavia la \textit{system call} di Linux non
-segue questa convenzione e restituisce sempre 0 in caso di successo e $-1$ in
-caso di errore; questo perché $-1$ è un valore di \var{nice} legittimo e
-questo comporta una confusione con una eventuale condizione di errore. La
-\textit{system call} originaria inoltre non consente, se non dotati di
-adeguati privilegi, di diminuire un valore di \var{nice} precedentemente
+di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
+segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$
+in caso di errore; questo perché $-1$ è anche un valore di \textit{nice}
+legittimo e questo comporta una confusione con una eventuale condizione di
+errore. La \textit{system call} originaria inoltre non consente, se non dotati
+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
\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
reimplementata e non viene più chiamata la omonima \textit{system call}, con
questa versione viene restituito come valore di ritorno il valore di
-\var{nice}, come richiesto dallo standard.\footnote{questo viene fatto
+\textit{nice}, come richiesto dallo standard.\footnote{questo viene fatto
chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
questo caso l'unico modo per rilevare in maniera affidabile una condizione di
errore è quello di azzerare \var{errno} prima della chiamata della funzione e
Per leggere il valore di \textit{nice} di un processo occorre usare la
funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
-\begin{prototype}{sys/resource.h}
-{int getpriority(int which, int who)}
-
-Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
- \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{sys/resource.h}
+\fdecl{int getpriority(int which, int who)}
+\fdesc{Legge un valore di \textit{nice}.}
+}
+{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 è valido.
- \end{errlist}}
-\end{prototype}
-\noindent nelle vecchie versioni può essere necessario includere anche
-\file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
-librerie, ma è comunque utile per portabilità.
-
-La funzione permette, a seconda del valore di \param{which}, di leggere la
-priorità di un processo, di un gruppo di processi (vedi
-sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente
-valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority};
-un valore nullo di quest'ultimo indica il processo, il gruppo di processi o
+\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
+ elencati in tab.~\ref{tab:proc_getpriority}.
+\end{errlist}}
+\end{funcproto}
+
+La funzione permette, a seconda di quanto specificato
+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ù
+necessario con versioni recenti delle librerie, ma è comunque utile per
+portabilità.
+
+I valori possibili per \param{which}, ed il tipo di valore che occorre usare
+in corrispondenza per \param{who} solo elencati nella legenda di
+tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un
+valore nullo per \param{who} indica, a seconda della corrispondente
+indicazione usata per \param{which} il processo, il gruppo di processi o
l'utente correnti.
\begin{table}[htb]
\label{tab:proc_getpriority}
\end{table}
-La funzione restituisce la priorità più alta (cioè il valore più basso) fra
-quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
-possibile, per poter rilevare una condizione di errore è necessario cancellare
-sempre \var{errno} prima della chiamata alla funzione per verificare che essa
+In caso di una indicazione che faccia riferimento a più processi, la funzione
+restituisce la priorità più alta (cioè il valore più basso) fra quelle dei
+processi corrispondenti. Come per \func{nice} $-1$ è un valore possibile
+corretto, per cui di nuovo per poter rilevare una condizione di errore è
+necessario cancellare sempre \var{errno} prima della chiamata alla funzione e
+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 è:
-\begin{prototype}{sys/resource.h}
-{int setpriority(int which, int who, int prio)}
- Imposta la priorità per l'insieme dei processi specificati.
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{sys/resource.h}
+\fdecl{int setpriority(int which, int who, int prio)}
+\fdesc{Imposta un valore di \textit{nice}.}
+}
+{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 è valido.
+\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{prototype}
+\end{errlist}}
+\end{funcproto}
+
+La funzione imposta la priorità dinamica al valore specificato da \param{prio}
+per tutti i processi indicati dagli argomenti \param{which} e \param{who}, per
+i quali valgono le stesse considerazioni fatte per \func{getpriority} e lo
+specchietto di tab.~\ref{tab:proc_getpriority}.
-La funzione imposta la priorità al valore specificato da \param{prio} per
-tutti i processi indicati dagli argomenti \param{which} e \param{who}. In
-questo caso come valore di \param{prio} deve essere specificato il valore di
-\textit{nice} da assegnare, e non un incremento (positivo o negativo) come nel
-caso di \func{nice}. La funzione restituisce il valore di \textit{nice}
+In questo caso come valore di \param{prio} deve essere specificato il valore
+di \textit{nice} da assegnare, e non un incremento (positivo o negativo) come
+nel caso di \func{nice}, nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
+\const{PRIO\_MAX} ($19$). La funzione restituisce il valore di \textit{nice}
assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
anche in questo caso per rilevare un errore occorre sempre porre a zero
\var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
-\textit{nice} valido.
+\textit{nice} valido.
Si tenga presente che solo l'amministratore\footnote{o più precisamente un
processo con la \itindex{capabilities} \textit{capability}
processo. Un utente normale infatti può modificare solo la priorità dei suoi
processi ed in genere soltanto diminuirla. Fino alla versione di kernel
2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
-sistemi derivati da SysV veniva richiesto che l'user-ID reale o quello
-effettivo del processo chiamante corrispondessero all'user-ID reale (e solo a
-quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
-versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
-da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
-l'user-ID effettivo.
+sistemi derivati da SysV veniva richiesto che l'\acr{uid} reale o quello
+effettivo del processo chiamante corrispondessero all'\acr{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.
Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
ordinari poter aumentare la priorità dei propri processi specificando un
nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
(torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
+Infine nonostante i valori siano sempre rimasti gli stessi, il significato del
+valore di \textit{nice} è cambiato parecchio nelle progressive riscritture
+dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel
+2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte
+nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata
+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à
+di essere eseguito in presenza di processi attivi a priorità più alta.
+
+
\subsection{Il meccanismo di \textit{scheduling real-time}}
\label{sec:proc_real_time}
Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
le priorità assolute per permettere la gestione di processi real-time. In
-realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
-presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
-processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
+realtà nel caso di Linux non si tratta di un vero \textit{hard real-time}, in
+quanto in presenza di eventuali interrupt il kernel interrompe l'esecuzione di
+un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
- ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
- interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
- Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
- direttamente qualora ci sia la necessità di avere un processo con priorità
- più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
-\itindex{page~fault} \textit{page fault} si possono avere ritardi non
-previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
-funzioni di controllo della memoria virtuale (vedi
-sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
-ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
+ ottenere un sistema effettivamente \textit{hard real-time}. In tal caso
+ infatti gli interrupt vengono intercettati dall'interfaccia
+ \textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
+ in modo da poterli controllare direttamente qualora ci sia la necessità di
+ avere un processo con priorità più elevata di un \textit{interrupt
+ handler}.} mentre con l'incorrere in un \itindex{page~fault} \textit{page
+ fault} si possono avere ritardi non previsti. Se l'ultimo problema può
+essere aggirato attraverso l'uso delle funzioni di controllo della memoria
+virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può
+comportare ritardi non prevedibili riguardo ai tempi di esecuzione di
+qualunque processo.
Nonostante questo, ed in particolare con una serie di miglioramenti che sono
stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
essere fatto, ottenibili attivando in fase di compilazione una fra le
opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
-approssimazione di sistema real-time usando le priorità assolute; occorre
-farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
-e questo finisce in un loop infinito, nessun altro processo potrà essere
-eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
-tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
+approssimazione di sistema \textit{real-time} usando le priorità assolute.
+Occorre farlo però con molta attenzione: se si dà ad un processo una priorità
+assoluta e questo finisce in un loop infinito, nessun altro processo potrà
+essere eseguito, ed esso sarà mantenuto in esecuzione permanentemente
+assorbendo tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
massima priorità assoluta, in modo da poter essere comunque in grado di
rientrare nel sistema.
-Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
-esecuzione prima di ogni processo normale. In caso di più processi sarà
+Quando c'è un processo con priorità assoluta lo \textit{scheduler} lo metterà
+in esecuzione prima di ogni processo normale. In caso di più processi sarà
eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
processi con la stessa priorità assoluta questi vengono tenuti in una coda e
tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
-vengono gestiti questi processi dipende dalla politica di scheduling che si è
-scelta; lo standard ne prevede due:
+vengono gestiti questi processi dipende dalla politica di \textit{scheduling}
+che si è scelta; lo standard ne prevede due:
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\textsf{FIFO}] \textit{First In First Out}. Il processo viene eseguito
- fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si
- blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
- processo viene interrotto da uno a priorità più alta esso resterà in cima
- alla lista e sarà il primo ad essere eseguito quando i processi a priorità
- più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
- posto in coda alla lista (ed altri processi con la stessa priorità potranno
- essere eseguiti).
-\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
- a quello precedente, con la sola differenza che ciascun processo viene
- eseguito al massimo per un certo periodo di tempo (la cosiddetta
- \textit{time-slice}) dopo di che viene automaticamente posto in fondo alla
- coda dei processi con la stessa priorità. In questo modo si ha comunque una
- esecuzione a turno di tutti i processi, da cui il nome della politica. Solo
- i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
+\item[\textit{First In First Out} (FIFO)] Il processo viene eseguito
+ fintanto che non cede volontariamente la CPU (con la funzione
+ \func{sched\_yield}), si blocca, finisce o viene interrotto da un processo a
+ priorità più alta. Se il processo viene interrotto da uno a priorità più
+ alta esso resterà in cima alla lista e sarà il primo ad essere eseguito
+ quando i processi a priorità più alta diverranno inattivi. Se invece lo si
+ blocca volontariamente sarà posto in coda alla lista (ed altri processi con
+ la stessa priorità potranno essere eseguiti).
+\item[\textit{Round Robin} (RR)] Il comportamento è del tutto analogo a quello
+ precedente, con la sola differenza che ciascun processo viene eseguito al
+ massimo per un certo periodo di tempo (la cosiddetta \textit{time-slice})
+ dopo di che viene automaticamente posto in fondo alla coda dei processi con
+ la stessa priorità. In questo modo si ha comunque una esecuzione a turno di
+ tutti i processi, da cui il nome della politica. Solo i processi con la
+ stessa priorità ed in stato \textit{runnable} entrano nel
\textsl{girotondo}.
\end{basedescript}
Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
-le politiche di scheduling, passando da real-time a ordinarie o viceversa, che
-di specificare, in caso di politiche real-time, la eventuale priorità statica;
-la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
-\begin{prototype}{sched.h}
-{int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
- Imposta priorità e politica di scheduling.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e $-$1 in caso di
- errore, nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
+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 è
+\funcd{sched\_setscheduler} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_setscheduler(pid\_t pid, int policy, const struct
+ sched\_param *p)}
+\fdesc{Imposta priorità e politica di \textit{scheduling}.}
+}
+{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.
+ 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.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}}
+\end{funcproto}
La funzione esegue l'impostazione per il processo specificato dall'argomento
-\param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
-processo corrente. La politica di scheduling è specificata
+\param{pid}, un valore nullo di questo argomento esegue l'impostazione per il
+processo corrente. La politica di \textit{scheduling} è specificata
dall'argomento \param{policy} i cui possibili valori sono riportati in
tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
-politiche real-time, quella bassa le politiche ordinarie. Un valore negativo
-per \param{policy} mantiene la politica di scheduling corrente.
+politiche \textit{real-time}, quella bassa le politiche ordinarie. Un valore
+negativo per \param{policy} mantiene la politica di \textit{scheduling}
+corrente.
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}[c]{|l|l|}
+ \begin{tabular}[c]{|l|p{6cm}|}
\hline
- \textbf{Policy} & \textbf{Significato} \\
+ \textbf{Politica} & \textbf{Significato} \\
\hline
\hline
- \const{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO}. \\
- \const{SCHED\_RR} & Scheduling real-time con politica \textit{Round
- Robin}. \\
+ \const{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
+ \textit{FIFO}. \\
+ \const{SCHED\_RR} & \textit{Scheduling real-time} con politica
+ \textit{Round Robin}. \\
\hline
- \const{SCHED\_OTHER}& Scheduling ordinario.\\
- \const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di
- lavoro \textit{CPU intensive}.\footnotemark\\
- \const{SCHED\_IDLE} & Scheduling di priorità estremamente
- bassa.\footnotemark\\
+ \const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
+ \const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
+ ulteriore di lavoro \textit{CPU
+ intensive} (dal kernel 2.6.16)\\
+ \const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
+ bassa (dal kernel 2.6.23)\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{policy} per la funzione
\label{tab:proc_sched_policy}
\end{table}
-\footnotetext[44]{introdotto con il kernel 2.6.16.}
-\footnotetext{introdotto con il kernel 2.6.23.}
-
Con le versioni più recenti del kernel sono state introdotte anche delle
-varianti sulla politica di scheduling tradizionale per alcuni carichi di
-lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
+varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
+di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
devono essere usate se si vogliono scrivere programmi portabili.
La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
interattività che mira a favorire i processi che si svegliano dallo stato di
-\textbf{Sleep}.\footnote{cosa che accade con grande frequenza per i processi
+\textit{sleep}.\footnote{cosa che accade con grande frequenza per i processi
interattivi, dato che essi sono per la maggior parte del tempo in attesa di
dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
nome, per processi che usano molta CPU (come programmi di calcolo) che in
avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
percentuale molto bassa.
-Qualora si sia richiesta una politica real-time il valore della priorità
-statica viene impostato attraverso la struttura \struct{sched\_param},
-riportata in fig.~\ref{fig:sig_sched_param}, il cui solo campo attualmente
-definito è \var{sched\_priority}. Il campo deve contenere il valore della
-priorità statica da assegnare al processo; lo standard prevede che questo
-debba essere assegnato all'interno di un intervallo fra un massimo ed un
-minimo che nel caso di Linux sono rispettivamente 1 e 99.
+Qualora si sia richiesta una politica \textit{real-time} il valore della
+priorità statica viene impostato attraverso la struttura
+\struct{sched\_param}, riportata in fig.~\ref{fig:sig_sched_param}, il cui
+solo campo attualmente definito è \var{sched\_priority}. Il campo deve
+contenere il valore della priorità statica da assegnare al processo; lo
+standard prevede che questo debba essere assegnato all'interno di un
+intervallo fra un massimo ed un minimo che nel caso di Linux sono
+rispettivamente 1 e 99.
\begin{figure}[!htbp]
\footnotesize \centering
\label{fig:sig_sched_param}
\end{figure}
-I processi con politica di scheduling ordinaria devono sempre specificare un
-valore nullo di \var{sched\_priority} altrimenti si avrà un errore
-\errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la
-priorità dinamica determinata dal valore di \textit{nice}, che deve essere
+I processi con politica di \textit{scheduling} ordinaria devono sempre
+specificare un valore nullo di \var{sched\_priority} altrimenti si avrà un
+errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con
+la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
impostato con le funzioni viste in precedenza.
-Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
-priorità statica possano essere ottenuti, per ciascuna delle politiche di
-scheduling \textit{real-time}, tramite le due funzioni
+Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle
+priorità statiche possa essere ottenuto tramite le due funzioni
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
-\begin{functions}
- \headdecl{sched.h}
-
- \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
- massimo della priorità statica per la politica di scheduling \param{policy}.
-
- \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
- della priorità statica per la politica di scheduling \param{policy}.
-
- \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
- \end{errlist}}
-\end{functions}
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_get\_priority\_max(int policy)}
+\fdesc{Legge il valore massimo di una priorità statica.}
+\fdecl{int sched\_get\_priority\_min(int policy)}
+\fdesc{Legge il valore minimo di una priorità statica.}
+}
+{Le funzioni ritornano il valore della priorità in caso di successo e $-1$ per
+ un errore, nel qual caso \var{errno} assumerà il valore:
+\begin{errlist}
+\item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
+\end{errlist}}
+\end{funcproto}
+
+Le funzioni ritornano rispettivamente i due valori della massima e minima
+priorità statica possano essere ottenuti per una delle politiche di
+\textit{scheduling} \textit{real-time} indicata dall'argomento \param{policy}.
-Si tenga presente che quando si imposta una politica di scheduling real-time
-per un processo o se ne cambia la priorità statica questo viene messo in cima
-alla lista dei processi con la stessa priorità; questo comporta che verrà
-eseguito subito, interrompendo eventuali altri processi con la stessa priorità
-in quel momento in esecuzione.
+Si tenga presente che quando si imposta una politica di \textit{scheduling}
+real-time per un processo o se ne cambia la priorità statica questo viene
+messo in cima alla lista dei processi con la stessa priorità; questo comporta
+che verrà eseguito subito, interrompendo eventuali altri processi con la
+stessa priorità in quel momento in esecuzione.
Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
esegue sempre il primo della lista, mentre un nuovo processo che torna in
-stato \textbf{Runnable} viene sempre inserito in coda alla lista. Se la
+stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
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
sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
-processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
-processo chiamante corrisponda all'user-ID reale o effettivo del processo
+processi che gli appartengono; è cioè richiesto che l'\acr{uid} effettivo del
+processo chiamante corrisponda all'\acr{uid} reale o effettivo del processo
indicato con \param{pid}.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
-real-time o modificare la eventuale priorità statica di un loro processo. A
-partire da questa versione è divenuto possibile anche per gli utenti normali
-usare politiche real-time fintanto che la priorità assoluta che si vuole
-impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
-sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. Unica eccezione a questa
-possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
-politica di scheduling indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
-politica real-time, un utente può sempre, indipendentemente dal valore di
-\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
-ordinaria.
+\textit{real-time} o modificare la eventuale priorità statica di un loro
+processo. A partire da questa versione è divenuto possibile anche per gli
+utenti normali usare politiche \textit{real-time} fintanto che la priorità
+assoluta che si vuole impostare è inferiore al limite \const{RLIMIT\_RTPRIO}
+(vedi sez.~\ref{sec:sys_resource_limit}) ad essi assegnato.
+
+Unica eccezione a questa possibilità sono i processi \const{SCHED\_IDLE}, che
+non possono cambiare politica di \textit{scheduling} indipendentemente dal
+valore di \const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto
+ad una politica \textit{real-time}, un utente può sempre, indipendentemente
+dal valore di \const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una
+politica ordinaria.
Se si intende operare solo sulla priorità statica di un processo si possono
usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che
consentono rispettivamente di impostarne e leggerne il valore, i loro
prototipi sono:
-\begin{functions}
- \headdecl{sched.h}
- \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
- Imposta la priorità statica del processo \param{pid}.
-
- \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
- Legge la priorità statica del processo \param{pid}.
+\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
+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.
+\end{errlist}}
+\end{funcproto}
- \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
- caso di errore, nel qual caso \var{errno} può assumere i valori:
- \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.
- \end{errlist}}
-\end{functions}
+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
+priorità dinamica. Questo è ancora una struttura \struct{sched\_param} ed
+assume gli stessi valori già visti per \func{sched\_setscheduler}.
L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
-argomento \param{policy} uguale a -1. Come per \func{sched\_setscheduler}
-specificando 0 come valore dell'argomento \param{pid} si opera sul processo
+argomento \param{policy} uguale a $-1$. Come per \func{sched\_setscheduler}
+specificando $0$ come valore dell'argomento \param{pid} si opera sul processo
corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
-politica ordinaria essa ha senso soltanto per quelli real-time, dato che per i
-primi la priorità statica può essere soltanto nulla. La disponibilità di
-entrambe le funzioni può essere verificata controllando la macro
-\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
-\file{sched.h}.
-
-Se invece si vuole sapere quale è politica di scheduling di un processo si può
-usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
-\begin{prototype}{sched.h}
-{int sched\_getscheduler(pid\_t pid)}
- Legge la politica di scheduling per il processo \param{pid}.
-
- \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
- e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
+politica ordinaria essa ha senso soltanto per quelli \textit{real-time}, dato
+che per i primi la priorità statica può essere soltanto nulla. La
+disponibilità di entrambe le funzioni può essere verificata controllando la
+macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
+ file} \file{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 è:
+
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_getscheduler(pid\_t pid)}
+\fdesc{Legge la politica di \textit{scheduling}.}
+}
+{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.
- \end{errlist}}
-\end{prototype}
+\end{errlist}}
+\end{funcproto}
La funzione restituisce il valore, secondo quanto elencato in
-tab.~\ref{tab:proc_sched_policy}, della politica di scheduling per il processo
-specificato; se l'argomento \param{pid} è nullo viene restituito il valore
-relativo al processo chiamante.
+tab.~\ref{tab:proc_sched_policy}, della politica di \textit{scheduling} per il
+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 è:
-\begin{prototype}{sched.h}
- {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
- \param{tp} la durata della \textit{time-slice} per il processo \param{pid}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{ENOSYS}] la \textit{system call} non è stata implementata.
- \end{errlist}}
-\end{prototype}
-La funzione restituisce il valore dell'intervallo di tempo usato per la
-politica \textit{round robin} in una struttura \struct{timespec}, (la cui
-definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
-dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
-questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
-specificare il PID di un processo reale.
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)}
+\fdesc{Legge la durata della \textit{time-slice} per lo \textit{scheduling}
+ \textit{round robin}.}
+}
+{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).
+\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
+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.
+
+Con kernel recenti però è possibile ottenere una variazione della
+\textit{time-slice}, modificando il valore di \textit{nice} del processo
+(anche se questo non incide assolutamente sulla priorità statica) che come
+accennato in precedenza modifica il valore assegnato alla \textit{time-slice}
+di un processo ordinario, che però viene usato anche dai processi
+\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 è:
-\begin{prototype}{sched.h}
- {int sched\_yield(void)}
-
- Rilascia volontariamente l'esecuzione.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} viene impostata opportunamente.}
-\end{prototype}
-
-Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling
-real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
-da essere rimesso in coda alla lista dei processi con la stessa priorità per
-permettere ad un altro di essere eseguito; se però il processo è l'unico ad
-essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
-questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere
-l'esecuzione degli altri processi con pari priorità quando la sezione più
-urgente è finita.
-
-La funzione può essere utilizzata anche con processi che usano lo scheduling
-ordinario, ma in questo caso il comportamento non è ben definito, e dipende
-dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi
-venissero messi in fondo alla coda di quelli attivi, con la possibilità di
-essere rimessi in esecuzione entro breve tempo, con l'introduzione del
-\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
-processo che chiama la funzione viene inserito nella lista dei processi
-inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
+
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_yield(void)}
+\fdesc{Rilascia volontariamente l'esecuzione.}
+}
+{La funzione ritorna $0$ in caso di successo e teoricamente $-1$ per un
+ errore, ma su Linux ha sempre successo.}
+\end{funcproto}
+
+
+Questa funzione ha un utilizzo effettivo soltanto quando si usa lo
+\textit{scheduling} \textit{real-time}, e serve a far sì che il processo
+corrente rilasci la CPU, in modo da essere rimesso in coda alla lista dei
+processi con la stessa priorità per permettere ad un altro di essere eseguito;
+se però il processo è l'unico ad essere presente sulla coda l'esecuzione non
+sarà interrotta. In genere usano questa funzione i processi con politica
+\const{SCHED\_FIFO}, per permettere l'esecuzione degli altri processi con pari
+priorità quando la sezione più urgente è finita.
+
+La funzione può essere utilizzata anche con processi che usano lo
+\textit{scheduling} ordinario, ma in questo caso il comportamento non è ben
+definito, e dipende dall'implementazione. Fino al kernel 2.6.23 questo
+comportava che i processi venissero messi in fondo alla coda di quelli attivi,
+con la possibilità di essere rimessi in esecuzione entro breve tempo, con
+l'introduzione del \textit{Completely Fair Scheduler} questo comportamento è
+cambiato ed un processo che chiama la funzione viene inserito nella lista dei
+processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
ripristinare un comportamento analogo al precedente scrivendo il valore 1
nel file \texttt{/proc/sys/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
+una risorsa contesa con altri processi, e si vuole dare agli altri una
+possibilità di approfittarne mettendoli in esecuzione, ma chiamarla senza
+necessità, specie se questo avviene ripetutamente all'interno di un qualche
+ciclo, può avere invece un forte impatto negativo per la generazione di
+\itindex{contest~switch} \textit{contest switch} inutili.
\subsection{Il controllo dello \textit{scheduler} per i sistemi
multiprocessore}
\label{sec:proc_sched_multiprocess}
-Infine con il supporto dei sistemi multiprocessore sono state introdotte delle
+Con il supporto dei sistemi multiprocessore sono state introdotte delle
funzioni che permettono di controllare in maniera più dettagliata la scelta di
quale processore utilizzare per eseguire un certo programma. Uno dei problemi
che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
-scheduler, quando riavvia un processo precedentemente interrotto scegliendo il
-primo processore disponibile, lo faccia eseguire da un processore diverso
-rispetto a quello su cui era stato eseguito in precedenza. Se il processo
-passa da un processore all'altro in questo modo (cosa che avveniva abbastanza
-di frequente con i kernel della seria 2.4.x) si ha l'\textsl{effetto
- ping-pong}.
+\textit{scheduler}, quando riavvia un processo precedentemente interrotto
+scegliendo il primo processore disponibile, lo faccia eseguire da un
+processore diverso rispetto a quello su cui era stato eseguito in
+precedenza. Se il processo passa da un processore all'altro in questo modo,
+cosa che avveniva abbastanza di frequente con i kernel della seria 2.4.x, si
+ha l'\textsl{effetto ping-pong}.
Questo tipo di comportamento può generare dei seri problemi di prestazioni;
infatti tutti i processori moderni utilizzano una memoria interna (la
Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
un processo possa essere assegnato per l'esecuzione sempre allo stesso
-processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa
-\textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong era
-comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
-risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
-stesso processore.
+processore. Lo \textit{scheduler} dei kernel della serie 2.4.x aveva una
+scarsa \textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong
+era comune; con il nuovo \textit{scheduler} dei kernel della 2.6.x questo
+problema è stato risolto ed esso cerca di mantenere il più possibile ciascun
+processo sullo stesso processore.
In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
sempre eseguito dallo stesso processore,\footnote{quella che viene detta
- \textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
- detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
- non un requisito assoluto.} e per poter risolvere questo tipo di
-problematiche nei nuovi kernel\footnote{le due \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 è:
-\begin{prototype}{sched.h}
- {int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
- cpu\_set\_t *cpuset)}
- Imposta la maschera di affinità del processo \param{pid}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{EINVAL}] il valore di \param{cpuset} contiene riferimenti a
- processori non esistenti nel sistema.
- \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
- eseguire l'operazione.
- \end{errlist}
- ed inoltre anche \errval{EFAULT}.}
-\end{prototype}
+ \textit{hard CPU affinity}, in contrasto con quella fornita dallo
+ \textit{scheduler}, detta \textit{soft CPU affinity}, che di norma indica
+ solo una preferenza, non un requisito assoluto.} e per poter risolvere
+questo tipo di problematiche nei nuovi kernel\footnote{le due \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 è:
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_setaffinity (pid\_t pid, size\_t cpusetsize,
+ 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.
+\end{errlist}
+ed inoltre anche \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
-abbastanza complessa, la \textit{system call} prevede l'uso di due ulteriori
-argomenti di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask},
-che corrispondono al fatto che la implementazione effettiva usa una semplice
-maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
-assunsero invece il prototipo appena mostrato. A complicare la cosa si
-aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
-\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
-versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
+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
+\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
+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
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}.}
La funzione imposta, con l'uso del valore contenuto all'indirizzo
-\param{cpuset}, l'insieme dei processori sui quali deve essere eseguito il
+\param{mask}, l'insieme dei processori sui quali deve essere eseguito il
processo identificato tramite il valore passato in \param{pid}. Come in
precedenza il valore nullo di \param{pid} indica il processo corrente. Per
poter utilizzare questa funzione sono richiesti i privilegi di amministratore
funzione non è necessario, in quanto è lo scheduler stesso che provvede a
mantenere al meglio l'affinità di processore. Esistono però esigenze
particolari, ad esempio quando un processo (o un gruppo di processi) è
-utilizzato per un compito importante (ad esempio per applicazioni real-time o
-la cui risposta è critica) e si vuole la massima velocità, con questa
-interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
-maniera esclusiva. Lo stesso dicasi quando l'accesso a certe risorse (memoria
-o periferiche) può avere un costo diverso a seconda del processore, come
-avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).
+utilizzato per un compito importante (ad esempio per applicazioni
+\textit{real-time} o la cui risposta è critica) e si vuole la massima
+velocità, e con questa interfaccia diventa possibile selezionare gruppi di
+processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando
+l'accesso a certe risorse (memoria o periferiche) può avere un costo diverso a
+seconda del processore, come avviene nelle architetture NUMA
+(\textit{Non-Uniform Memory Access}).
Infine se un gruppo di processi accede alle stesse risorse condivise (ad
esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
di processore.
-Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
+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
- \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.
+ \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:
-\begin{functions}
- \headdecl{sched.h}
- \funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
- Inizializza l'insieme (vuoto).
- \funcdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)}
- Inserisce il processore \param{cpu} nell'insieme.
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sched.h}
+\fdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
+\fdesc{Inizializza l'insieme vuoto \param{set}.}
+\fdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)}
+\fdesc{Inserisce il processore \param{cpu} nell'insieme \param{set}.}
+\fdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
+\fdesc{Rimuove il processore \param{cpu} nell'insieme \param{set}.}
+\fdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
+\fdesc{Controlla se il processore \param{cpu} è nell'insieme \param{set}.}
+}
+\end{funcbox}}
+
+% TODO trattare le altre
- \funcdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
- Rimuove il processore \param{cpu} nell'insieme.
-
- \funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
- Controlla se il processore \param{cpu} è nell'insieme.
-\end{functions}
-
-Oltre a queste macro, simili alle analoghe usate per gli insiemi di file
-descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
-\const{CPU\_SETSIZE} che indica il numero massimo di processori che possono
-far parte dell'insieme, e che costituisce un limite massimo al valore
+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}.
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 è:
-\begin{prototype}{sched.h}
- {int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize,
- const cpu\_set\_t *cpuset)}
- Legge la maschera di affinità del processo \param{pid}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
- valido.
- \end{errlist} }
-\end{prototype}
-La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
-della maschera di affinità del processo, così da poterla riutilizzare per una
-successiva reimpostazione. In questo caso non sono necessari privilegi
-particolari.
+\begin{funcproto}{
+\fhead{sched.h}
+\fdecl{int sched\_getaffinity (pid\_t pid, size\_t cpusetsize,
+ 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
+ della maschera di affinità usata dal kernel.
+\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)}.
È 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}
maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
possibile soltanto differenziare le politiche generali di gestione, scegliendo
di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con
-l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
-divenuto possibile, qualora si usi questo scheduler, impostare anche delle
-diverse priorità di accesso per i singoli processi.\footnote{al momento
- (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
- scheduler.}
-
-La scelta dello scheduler di I/O si può fare in maniera generica a livello di
-avvio del kernel assegnando il nome dello stesso al parametro
+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
-scheduler disponibili sono mostrati dal contenuto dello stesso file che
-riporta fra parentesi quadre quello attivo, il default in tutti i kernel
+\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
- scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
-dettagli sulle caratteristiche specifiche degli altri scheduler, la cui
-discussione attiene a problematiche di ambito sistemistico, si consulti la
-documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
-kernel.
-
-Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system
-call, specifiche di Linux, che consentono di leggere ed impostare le priorità
-di I/O.\footnote{se usate in corrispondenza ad uno scheduler diverso il loro
- utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
-diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
-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:
-\begin{functions}
- \headdecl{linux/ioprio.h}
- \funcdecl{int ioprio\_get(int which, int who)}
- \funcdecl{int ioprio\_set(int which, int who, int ioprio)}
-
- Rileva o imposta la priorità di I/O di un processo.
-
- \bodydesc{Le funzioni ritornano rispettivamente un intero positivo
- (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] non esiste il processo indicato.
- \item[\errcode{EINVAL}] i valori di \param{which} e \param{who} non sono
- validi.
- \item[\errcode{EPERM}] non si hanno i privilegi per eseguire
- l'impostazione (solo per \func{ioprio\_set}).
- \end{errlist} }
-\end{functions}
+ \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:
-Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
+\begin{funcproto}{
+\fhead{linux/ioprio.h}
+\fdecl{int ioprio\_get(int which, int who)}
+\fdesc{Legge la priorità di I/O di un processo.}
+\fdecl{int ioprio\_set(int which, int who, int ioprio)}
+\fdesc{Imposta la priorità di I/O di un processo.}
+}
+{Le funzioni ritornano rispettivamente un intero positivo o 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 esiste un processo corrisponente alle indicazioni.
+\item[\errcode{EINVAL}] i valori di \param{which} o di \param{iprio} non
+ sono validi.
+\item[\errcode{EPERM}] non si hanno i privilegi per eseguire
+ l'impostazione (solo per \func{ioprio\_set}).
+\end{errlist}}
+\end{funcproto}
+
+Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
già visto per gli omonimi argomenti di \func{getpriority} e
\func{setpriority}. Anche in questo caso si deve specificare il valore
di \param{which} tramite le opportune costanti riportate in
tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
processi di un \textit{process group} (tratteremo questo argomento in
-sez.~\ref{sec:sess_proc_group}) o tutti o processi di un utente.
+sez.~\ref{sec:sess_proc_group}) o tutti i processi di un utente.
\begin{table}[htb]
\centering
In caso di successo \func{ioprio\_get} restituisce un intero positivo che
esprime il valore della priorità di I/O, questo valore è una maschera binaria
-composta da due parti, una che esprime la \textsl{classe} di scheduling di I/O
-del processo, l'altra che esprime, quando la classe di scheduling lo prevede,
-la priorità del processo all'interno della classe stessa. Questo stesso
-formato viene utilizzato per indicare il valore della priorità da impostare
-con l'argomento \param{ioprio} di \func{ioprio\_set}.
+composta da due parti, una che esprime la \textsl{classe} di
+\textit{scheduling} di I/O del processo, l'altra che esprime, quando la classe
+di \textit{scheduling} lo prevede, la priorità del processo all'interno della
+classe stessa. Questo stesso formato viene utilizzato per indicare il valore
+della priorità da impostare 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
-scheduling\footnote{restituita dalla macro con i valori 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.
\label{tab:IOsched_class_macro}
\end{table}
-Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre
-diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
-anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
-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,
-perché un processo in questa classe può venire completamente bloccato quando
-ci sono altri processi in una qualunque delle altre due classi che stanno
-accedendo al disco. Quando si usa questa classe non ha senso indicare un
-valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
-priorità è identica, la minima possibile, per tutti i processi.
+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}.
\begin{table}[htb]
\centering
\textbf{Classe} & \textbf{Significato} \\
\hline
\hline
- \const{IOPRIO\_CLASS\_RT} & Scheduling di I/O \textit{real time}.\\
- \const{IOPRIO\_CLASS\_BE} & Scheduling di I/O ordinario.\\
- \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
+ \const{IOPRIO\_CLASS\_RT} & \textit{Scheduling} di I/O \textit{real-time}.\\
+ \const{IOPRIO\_CLASS\_BE} & \textit{Scheduling} di I/O ordinario.\\
+ \const{IOPRIO\_CLASS\_IDLE}& \textit{Scheduling} di I/O di priorità minima.\\
\hline
\end{tabular}
- \caption{Costanti che identificano le classi di scheduling di I/O.}
+ \caption{Costanti che identificano le classi di \textit{scheduling} di I/O.}
\label{tab:IOsched_class}
\end{table}
+La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
+questa classe riescono ad accedere a disco soltanto quando nessun altro
+processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
+perché un processo in questa classe può venire completamente bloccato quando
+ci sono altri processi in una qualunque delle altre due classi che stanno
+accedendo al disco. Quando si usa questa classe non ha senso indicare un
+valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
+priorità è identica, la minima possibile, per tutti i processi.
+
La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
per \textit{best-effort}) che è quella usata ordinariamente da tutti
processi. In questo caso esistono priorità diverse che consentono di
dei processi che gli appartengono,\footnote{per la modifica delle priorità di
altri processi occorrono privilegi amministrativi, ed in particolare la
capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
-cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
-chiamante. Data la possibilità di ottenere un blocco totale del sistema, solo
-l'amministratore\footnote{o un processo con la capacità
+cioè quelli il cui \acr{uid} reale corrisponde all'\acr{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ò
impostare un processo ad una priorità di I/O nella classe
\const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la
%TODO verificare http://lwn.net/Articles/355987/
%TODO trattare le funzionalità per il NUMA
-% vedi man numa e le pagine di manuale relative
+% vedi man numa e, mbind, get_mempolicy, set_mempolicy,
+% le pagine di manuale relative
% vedere anche dove metterle...
della guida, si può saltare questa sezione in una prima lettura, tornando su
di essa in un secondo tempo.
-\subsection{La \textit{system call} \func{clone}}
-\label{sec:process_clone}
-
-La funzione tradizionale con cui creare un nuovo processo in un sistema
-Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
-l'introduzione del supporto del kernel per i \textit{thread} (vedi
-cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
-consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
-processi, che poi è stata utilizzata anche per fornire supporto per le
-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
-``\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.
-
-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}.
-
-La \textit{system call} richiede soltanto due argomenti: il
-primo, \param{flags}, consente di controllare le modalità di creazione del
-nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
-dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
-indicato quando si intende creare un \textit{thread}. L'esecuzione del
-programma creato da \func{sys\_clone} riprende, come per \func{fork}, da
-dopo l'esecuzione della stessa.
-
-La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
-quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
-\textit{task} vede esattamente la stessa memoria del \textit{task}
-``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
- il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
- da essa creato, senza nessuna delle implicazioni che il concetto ha per i
- processi.} e nella sua esecuzione alla prima chiamata di una funzione
-andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
-quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
-\textit{stack}).
-
-Per evitare di doversi garantire contro la evidente possibilità di
-\itindex{race~condition} \textit{race condition} che questa situazione
-comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della
-problematica) è necessario che il chiamante allochi preventivamente un'area di
-memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che
-la funzione imposterà come \textit{stack} del nuovo processo, avendo
-ovviamente cura di non utilizzarlo direttamente nel processo chiamante. In
-questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
-non si dovranno affrontare problematiche di \itindex{race~condition}
-\textit{race condition}. Si tenga presente inoltre che in molte architetture
-di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso
-non si dovrà specificare per \param{child\_stack} il puntatore restituito da
-\func{malloc}, ma un puntatore alla fine del buffer da essa allocato.
-
-Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
-memoria, la \textit{system call}, a differenza della funzione di libreria che
-vedremo a breve, consente anche di passare per \param{child\_stack} il valore
-\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
-processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
- sottinteso cioè che non si stia usando il flag \const{CLONE\_VM}.} ed in
-questo caso si applica la semantica del \itindex{copy~on~write} \textit{copy
- on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le pagine dello
-\textit{stack} verranno automaticamente copiate come le altre e il nuovo
-processo avrà un suo \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
-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
- \textit{system call} non è disponibile la chiamata veloce con
- \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
-\funcd{clone} ed il suo prototipo è:
-\begin{functions}
- \headdecl{sys/sched.h}
-
- \funcdecl{int clone(int (*fn)(void *), void *child\_stack, int
- flags, void *arg, ... \\
- /* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */)}
-
- Crea un nuovo processo o \textit{thread} eseguendo la funzione \param{fn}.
-
- \bodydesc{La funzione ritorna al chiamante il \textit{Thread ID} assegnato
- al nuovo processo in caso di successo e $-1$ in caso di errore, nel qual
- caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
- \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
- un valore nullo per \param{child\_stack}.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
- \struct{task\_struct} o per copiare le parti del contesto del chiamante
- necessarie al nuovo \textit{task}.
- \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
- richiesti dai flag indicati.
- \end{errlist}
- }
-\end{functions}
-
-La funzione prende come primo argomento 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} del tipo indicato, 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.
-
-Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
-nuovo processo da essa creato, è controllato dall'argomento \param{flags},
-
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
-
-\item[\const{CLONE\_CHILD\_CLEARTID}]
-\item[\const{CLONE\_CHILD\_SETTID}]
-\item[\const{CLONE\_FILES}]
-\item[\const{CLONE\_FS}]
-\item[\const{CLONE\_IO}]
-\item[\const{CLONE\_NEWIPC}]
-\item[\const{CLONE\_NEWNET}]
-\item[\const{CLONE\_NEWNS}]
-\item[\const{CLONE\_NEWPID}]
-\item[\const{CLONE\_NEWUTS}]
-\item[\const{CLONE\_PARENT}]
-\item[\const{CLONE\_PARENT\_SETTID}]
-\item[\const{CLONE\_PID}]
-\item[\const{CLONE\_PTRACE}]
-\item[\const{CLONE\_SETTLS}]
-\item[\const{CLONE\_SIGHAND}]
-\item[\const{CLONE\_STOPPED}]
-\item[\const{CLONE\_SYSVSEM}]
-\item[\const{CLONE\_THREAD}]
-\item[\const{CLONE\_UNTRACED}]
-\item[\const{CLONE\_VFORK}]
-\item[\const{CLONE\_VM}]
-\end{basedescript}
-
\subsection{La funzione \func{prctl}}
\label{sec:process_prctl}
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.}
-\begin{functions}
- \headdecl{sys/prctl.h}
- \funcdecl{int prctl(int option, unsigned long arg2, unsigned long arg3,
+\begin{funcproto}{
+\fhead{sys/prctl.h}
+\fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5)}
-
- Esegue una operazione speciale sul processo corrente.
-
- \bodydesc{La funzione ritorna 0 o un valore positivo dipendente
- dall'operazione in caso di successo e $-1$ in caso di errore, nel qual
- caso \var{errno} assumerà valori diversi a seconda del tipo di operazione
- richiesta (in genere \errval{EINVAL} o \errval{EPERM}). }
-\end{functions}
+\fdesc{Esegue una operazione speciale sul processo corrente.}
+}
+{La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in
+ caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
+ valori diversi a seconda del tipo di operazione richiesta (in genere
+ \errval{EINVAL} o \errval{EPERM}).}
+\end{funcproto}
La funzione ritorna un valore nullo o positivo in caso di successo e $-1$ in
caso di errore; il significato degli argomenti della funzione successivi al
\end{basedescript}
+\subsection{La \textit{system call} \func{clone}}
+\label{sec:process_clone}
+
+La funzione tradizionale con cui creare un nuovo processo in un sistema
+Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
+l'introduzione del supporto del kernel per i \textit{thread} (vedi
+cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
+consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
+processi, che poi è stata utilizzata anche per fornire supporto per le
+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
+``\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.
+
+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}.
+
+La \textit{system call} richiede soltanto due argomenti: il
+primo, \param{flags}, consente di controllare le modalità di creazione del
+nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
+dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
+indicato quando si intende creare un \textit{thread}. L'esecuzione del
+programma creato da \func{sys\_clone} riprende, come per \func{fork}, da
+dopo l'esecuzione della stessa.
+
+La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
+quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
+\textit{task} vede esattamente la stessa memoria del \textit{task}
+``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
+ il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
+ da essa creato, senza nessuna delle implicazioni che il concetto ha per i
+ processi.} e nella sua esecuzione alla prima chiamata di una funzione
+andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
+quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
+\textit{stack}).
+
+Per evitare di doversi garantire contro la evidente possibilità di
+\itindex{race~condition} \textit{race condition} che questa situazione
+comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della
+problematica) è necessario che il chiamante allochi preventivamente un'area di
+memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che
+la funzione imposterà come \textit{stack} del nuovo processo, avendo
+ovviamente cura di non utilizzarlo direttamente nel processo chiamante.
+
+In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
+non si dovranno affrontare problematiche di \itindex{race~condition}
+\textit{race condition}. Si tenga presente inoltre che in molte architetture
+di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso
+non si dovrà specificare per \param{child\_stack} il puntatore restituito da
+\func{malloc}, ma un puntatore alla fine del buffer da essa allocato.
+
+Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
+memoria, la \textit{system call}, a differenza della funzione di libreria che
+vedremo a breve, consente anche di passare per \param{child\_stack} il valore
+\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
+processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
+ sottinteso cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo
+ a breve.} ed in questo caso si applica la semantica del
+\itindex{copy~on~write} \textit{copy on write} illustrata in
+sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
+automaticamente copiate come le altre e il nuovo processo avrà un suo
+\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
+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
+ \textit{system call} non è disponibile la chiamata veloce con
+ \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
+\funcd{clone} ed il suo prototipo è:
+
+\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 */)}
+\fdesc{Crea un nuovo processo o \textit{thread}.}
+}
+{La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
+ di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
+ valori:
+\begin{errlist}
+ \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
+ \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
+ un valore nullo per \param{child\_stack}.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
+ \struct{task\_struct} o per copiare le parti del contesto del chiamante
+ necessarie al nuovo \textit{task}.
+ \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
+ richiesti dai flag indicati.
+\end{errlist}}
+\end{funcproto}
+
+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.
+
+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}.
+
+Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
+nuovo processo da essa creato, è controllato dall'argomento \param{flags},
+
+\begin{basedescript}{\desclabelstyle{\pushlabel}}
+
+\item[\const{CLONE\_CHILD\_CLEARTID}]
+\item[\const{CLONE\_CHILD\_SETTID}]
+\item[\const{CLONE\_FILES}]
+\item[\const{CLONE\_FS}]
+\item[\const{CLONE\_IO}]
+\item[\const{CLONE\_NEWIPC}]
+\item[\const{CLONE\_NEWNET}]
+\item[\const{CLONE\_NEWNS}]
+\item[\const{CLONE\_NEWPID}]
+\item[\const{CLONE\_NEWUTS}]
+\item[\const{CLONE\_PARENT}]
+\item[\const{CLONE\_PARENT\_SETTID}]
+\item[\const{CLONE\_PID}]
+\item[\const{CLONE\_PTRACE}]
+\item[\const{CLONE\_SETTLS}]
+\item[\const{CLONE\_SIGHAND}]
+\item[\const{CLONE\_STOPPED}]
+\item[\const{CLONE\_SYSVSEM}]
+\item[\const{CLONE\_THREAD}]
+\item[\const{CLONE\_UNTRACED}]
+\item[\const{CLONE\_VFORK}]
+\item[\const{CLONE\_VM}]
+\end{basedescript}
\subsection{La funzione \func{ptrace}}
% TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
+\subsection{La gestione delle operazioni in virgola mobile}
+\label{sec:process_fenv}
+
+Da fare.
+
+% TODO eccezioni ed arrotondamenti per la matematica in virgola mobile
+% consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater,
+% isnan, nan, INFINITY
+
+
\subsection{L'accesso alle porte di I/O}
\label{sec:process_io_port}
% 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 Stopped
-% LocalWords: Uninterrutible SIGSTOP soft slice nice niceness counter which SC
-% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO First
+% 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: 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 Killable PR
+% LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED PR
% 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: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
% 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
+% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
+% LocalWords: loader EISDIR SIGTRAP uninterrutible killable
%%% Local Variables:
%%% mode: latex
projects / gapil.git / commitdiff