Dato che tutti i processi attivi nel sistema sono comunque generati da
\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
- vero, in Linux ci sono alcuni processi che pur comparendo come figli di
- init, o con \acr{pid} successivi, sono in realtà generati direttamente dal
- kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
-processi con la relazione padre/figlio in un'organizzazione gerarchica ad
-albero, in maniera analoga a come i file sono organizzati in un albero di
-directory (si veda \secref{sec:file_organization}); in \curfig\ si è mostrato
-il risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
-processi.
-
+ vero, in Linux ci sono alcuni processi speciali che pur comparendo come
+ figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
+ direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
+possono classificare i processi con la relazione padre/figlio in
+un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
+organizzati in un albero di directory (si veda
+\secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
+comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
+base c'è \cmd{init} che è progenitore di tutti gli altri processi.
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
\textit{process table}; per ciascun processo viene mantenuta una voce nella
tabella dei processi costituita da una struttura \type{task\_struct}, che
contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
-uno schema semplificato che riporta la struttura delle principali informazioni
+uno schema semplificato, che riporta la struttura delle principali informazioni
contenute nella \type{task\_struct} (che in seguito incontreremo a più
riprese), è mostrato in \nfig.
Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
-system call ed ad ogni interrupt, (ma può essere anche attivato
+system call ed ad ogni interrupt,\footnote{più in una serie di altre
+ occasioni. NDT completare questa parte.} (ma può essere anche attivato
esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
periodicamente, generando un interrupt periodico secondo la frequenza
-specificata dalla costante \macro{HZ}, definita in \file{asm/param.h} Il
-valore usuale è 100 (è espresso in Hertz), si ha cioè un interrupt dal timer
-ogni centesimo di secondo.
+specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}, ed il
+cui valore è espresso in Hertz.\footnote{Il valore usuale di questa costante è
+ 100, per tutte le architetture eccetto l'alpha, per la quale è 1000. Occorre
+ fare attenzione a non confondere questo valore con quello dei clock tick
+ (vedi \secref{sec:sys_unix_time}).}
+%Si ha cioè un interrupt dal timer ogni centesimo di secondo.
Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
priorità dei vari processi attivi (torneremo su questo in
da un numero identificativo unico, il \textit{process id} o \acr{pid};
quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
-\type{int}).
+\ctyp{int}).
Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
-processo viene creato, fino ad un limite massimo (in genere essendo detto
-numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si
-riparte dal numero più basso disponibile\footnote{FIXME: verificare, non sono
- sicuro}. Per questo motivo, come visto in \secref{sec:proc_hierarchy}, il
-processo di avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
+processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
+positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
+Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
+partire da un minimo di 300,\footnote{questi valori sono definiti dalla macro
+ \macro{PID\_MAX} in \file{threads.h} e direttamente in \file{fork.c} nei
+ sorgenti del kernel.} che serve a riservare i \acr{pid} più bassi ai processi
+eseguiti dal direttamente dal kernel. Per questo motivo, come visto in
+\secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
+\acr{pid} uguale a uno.
Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
sono stati creati, questo viene chiamato in genere \acr{ppid} (da
\textit{parent process id}). Questi due identificativi possono essere
ottenuti da programma usando le funzioni:
\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{unistd.h}
-\funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente.
-\funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo
- corrente.
+ \headdecl{sys/types.h} \headdecl{unistd.h} \funcdecl{pid\_t getpid(void)}
+ Restituisce il \acr{pid} del processo corrente. \funcdecl{pid\_t
+ getppid(void)} Restituisce il \acr{pid} del padre del processo corrente.
\bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
\end{functions}
Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
sono già troppi processi nel sistema (il che di solito è sintomo che
qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
-sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}).
+sul numero totale di processi permessi all'utente (vedi
+\secref{sec:sys_resource_limit}, ed in particolare
+\tabref{tab:sys_rlimit_values}).
L'uso di \func{fork} avviene secondo due modalità principali; la prima è
quella in cui all'interno di un programma si creano processi figli cui viene
affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
-ne esegue un'altra. È il caso tipico dei server di rete in cui il padre riceve
-ed accetta le richieste da parte dei client, per ciascuna delle quali pone in
-esecuzione un figlio che è incaricato di fornire il servizio.
+ne esegue un'altra. È il caso tipico dei server (il modello
+\textit{client-server} è illustrato in \secref{sec:net_cliserv}) di rete in
+cui il padre riceve ed accetta le richieste da parte dei client, per ciascuna
+delle quali pone in esecuzione un figlio che è incaricato di fornire il
+servizio.
La seconda modalità è quella in cui il processo vuole eseguire un altro
programma; questo è ad esempio il caso della shell. In questo caso il processo
aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
seconda modalità d'uso, avere le due funzioni separate permette al figlio di
cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, \textit{user id}) prima della \func{exec}, rendendo così
+dell'output, identificatori) prima della \func{exec}, rendendo così
relativamente facile intervenire sulle le modalità di esecuzione del nuovo
programma.
-In \curfig\ si è riportato il corpo del codice del programma di esempio
-\cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso
-della funzione \func{fork}. Il programma permette di creare un numero di figli
-specificato da linea di comando, e prende anche alcune opzioni per indicare
-degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
-\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
-descrizione delle opzioni); il codice completo, compresa la parte che gestisce
-le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
-distribuito insieme agli altri sorgenti degli esempi su
-\href{http://firenze.linux.it/~piccardi/gapil_source.tgz}
-{\texttt{http://firenze.linux.it/\~~\hspace{-2.0mm}piccardi/gapil\_source.tgz}}.
+In \figref{fig:proc_fork_code} si è riportato il corpo del codice del
+programma di esempio \cmd{forktest}, che ci permette di illustrare molte
+caratteristiche dell'uso della funzione \func{fork}. Il programma permette di
+creare un numero di figli specificato da linea di comando, e prende anche
+alcune opzioni per indicare degli eventuali tempi di attesa in secondi
+(eseguiti tramite la funzione \func{sleep}) per il padre ed il figlio (con
+\cmd{forktest -h} si ottiene la descrizione delle opzioni); il codice
+completo, compresa la parte che gestisce le opzioni a riga di comando, è
+disponibile nel file \file{ForkTest.c}, distribuito insieme agli altri
+sorgenti degli esempi su \href{http://gapil.firenze.linux.it/gapil_source.tgz}
+{\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
Decifrato il numero di figli da creare, il ciclo principale del programma
(\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
periodo di attesa.
Se eseguiamo il comando senza specificare attese (come si può notare in
-\texttt{\small 17--19} i valori di default specificano di non attendere),
+\texttt{\small 17--19} i valori predefiniti specificano di non attendere),
otterremo come output sul terminale:
\footnotesize
primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
mantenere la portabilità è opportuno non fare comunque affidamento su questo
- comportamento} dopo la chiamata a \func{fork}; dall'esempio si può notare
+ comportamento.} dopo la chiamata a \func{fork}; dall'esempio si può notare
infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
-rischio di incorrere nelle cosiddette \textit{race condition} \index{race
- condition} (vedi \secref{sec:proc_race_cond}.
+rischio di incorrere nelle cosiddette
+\textit{race condition}\index{race condition}
+(vedi \secref{sec:proc_race_cond}).
Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
processi completamente separati, le modifiche delle variabili nei processi
proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
-\item i file aperti e gli eventuali flag di \textit{close-on-exec} settati
+\item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
(vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
-\item gli identificatori per il controllo di accesso: il \textit{real user
- id}, il \textit{real group id}, l'\textit{effective user id},
- l'\textit{effective group id} ed i \textit{supplementary group id} (vedi
+\item gli identificatori per il controllo di accesso: l'\textsl{userid reale},
+ il \textsl{groupid reale}, l'\textsl{userid effettivo}, il \textsl{groupid
+ effettivo} ed i \textit{groupid supplementari} (vedi
\secref{sec:proc_access_id}).
\item gli identificatori per il controllo di sessione: il \textit{process
- group id} e il \textit{session id} ed il terminale di controllo (vedi
+ groupid} e il \textit{session id} ed il terminale di controllo (vedi
\secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
\item la directory di lavoro e la directory radice (vedi
\secref{sec:file_work_dir} e \secref{sec:file_chroot}).
\item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
-\item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigpending}) e le
+\item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
azioni installate (vedi \secref{sec:sig_gen_beha}).
\item i segmenti di memoria condivisa agganciati al processo (vedi
-\secref{sec:ipc_xxx}).
-\item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).
+ \secref{sec:ipc_sysv_shm}).
+\item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
\item le variabili di ambiente (vedi \secref{sec:proc_environ}).
\end{itemize*}
le differenze fra padre e figlio dopo la \func{fork} invece sono:
\begin{itemize*}
\item il valore di ritorno di \func{fork}.
-\item il \textit{process id}.
-\item il \textit{parent process id} (quello del figlio viene settato al
- \acr{pid} del padre).
-\item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che
- nel figlio sono posti a zero.
+\item il \acr{pid} (\textit{process id}).
+\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
+ impostato al \acr{pid} del padre.
+\item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
+ \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
\item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
vengono ereditati dal figlio.
\item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
\func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
venne introdotta in BSD per migliorare le prestazioni.
-Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
-assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
-speciale della funzione \func{clone}), è deprecato; per questo eviteremo di
-trattarla ulteriormente.
+Dato che Linux supporta il \textit{copy on write}\index{copy on write} la
+perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
+funzione (che resta un caso speciale della funzione \func{clone}), è
+deprecato; per questo eviteremo di trattarla ulteriormente.
\subsection{La conclusione di un processo.}
\item ad ogni processo figlio viene assegnato un nuovo padre (in genere
\cmd{init}).
\item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
- \secref{sec:sig_xxx}).
+ \secref{sec:sig_sigchld}).
\item se il processo è un leader di sessione viene mandato un segnale di
\macro{SIGHUP} a tutti i processi in background e il terminale di
controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
creare molti figli. In questo caso si deve sempre avere cura di far leggere
l'eventuale stato di uscita di tutti i figli (in genere questo si fa
attraverso un apposito \textit{signal handler}, che chiama la funzione
-\func{wait}, vedi \secref{sec:sig_xxx} e \secref{sec:proc_wait}). Questa
+\func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
operazione è necessaria perché anche se gli \textit{zombie} non consumano
risorse di memoria o processore, occupano comunque una voce nella tabella dei
processi, che a lungo andare potrebbe esaurirsi.
processo figlio termina. Se un figlio è già terminato la funzione ritorna
immediatamente.
-Al ritorno lo stato di termininazione del processo viene salvato nella
+Al ritorno lo stato di terminazione del processo viene salvato nella
variabile puntata da \var{status} e tutte le informazioni relative al
processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel
caso un processo abbia più figli il valore di ritorno permette di
\begin{table}[!htb]
\centering
\footnotesize
- \begin{tabular}[c]{|c|p{10cm}|}
+ \begin{tabular}[c]{|c|c|p{8cm}|}
\hline
- \textbf{Valore} & \textbf{Significato}\\
+ \textbf{Valore} & \textbf{Macro} &\textbf{Significato}\\
\hline
\hline
- $<-1$& attende per un figlio il cui \textit{process group} è uguale al
+ $<-1$& -- & attende per un figlio il cui \textit{process group} è uguale al
valore assoluto di \var{pid}. \\
- $-1$ & attende per un figlio qualsiasi, usata in questa maniera è
- equivalente a \func{wait}.\\
- $0$ & attende per un figlio il cui \textit{process group} è uguale a
- quello del processo chiamante. \\
- $>0$ & attende per un figlio il cui \acr{pid} è uguale al
+ $-1$ & \macro{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
+ questa maniera è equivalente a \func{wait}.\\
+ $0$ & \macro{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
+ group} è uguale a quello del processo chiamante. \\
+ $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
valore di \var{pid}.\\
\hline
\end{tabular}
rispetto all'esecuzione di un programma e può avvenire in un qualunque
momento. Per questo motivo, come accennato nella sezione precedente, una delle
azioni prese dal kernel alla conclusione di un processo è quella di mandare un
-segnale di \macro{SIGCHLD} al padre. L'azione di default (si veda
+segnale di \macro{SIGCHLD} al padre. L'azione predefinita (si veda
\secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
generazione costituisce il meccanismo di comunicazione asincrona con cui il
kernel avverte il processo padre che uno dei suoi figli è terminato.
conclusione di un processo per proseguire, specie se tutto questo serve solo
per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
per questo la modalità più usata per chiamare queste funzioni è quella di
-utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e
-su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}). In questo
-caso infatti, dato che il segnale è generato dalla terminazione di un figlio,
-avremo la certezza che la chiamata a \func{wait} non si bloccherà.
+utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
+come gestire \macro{SIGCHLD} con i segnali in \secref{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{wait} non si bloccherà.
\begin{table}[!htb]
\centering
\macro{WIFSIGNALED} ha restituito un valore non nullo.\\
\macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
file si \textit{core dump}. Può essere valutata solo se
- \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa
+ \macro{WIFSIGNALED} ha restituito un valore non nullo.\footnote{questa
macro non è definita dallo standard POSIX.1, ma è presente come estensione
- sia in Linux che in altri unix}.\\
+ sia in Linux che in altri Unix.}\\
\macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
\func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
l'opzione \macro{WUNTRACED}. \\
analizzare lo stato di uscita. Esse sono definite sempre in
\file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
presente che queste macro prendono come parametro la variabile di tipo
-\type{int} puntata da \var{status}).
+\ctyp{int} puntata da \var{status}).
Si tenga conto che nel caso di conclusione anomala il valore restituito da
\macro{WTERMSIG} può essere confrontato con le costanti definite in
queste funzioni, che diventano accessibili definendo la costante
\macro{\_USE\_BSD}, sono:
\begin{functions}
- \headdecl{sys/times.h}
- \headdecl{sys/types.h}
- \headdecl{sys/wait.h}
- \headdecl{sys/resource.h}
+ \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 dei parametri, ma restituisce in \param{rusage} un sommario delle
- risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx})
+ * rusage)}
+ È identica a \func{waitpid} sia per comportamento che per i valori dei
+ parametri, 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)} è
\end{functions}
\noindent
la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
-utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx})
-per ottenere le risorse di sistema usate da un processo; la sua definizione è
-riportata in \figref{fig:sys_rusage_struct}.
-
-In genere includere esplicitamente \file{<sys/time.h>} non è più
-necessario, ma aumenta la portabilità, e serve in caso si debba accedere
-ai campi di \var{rusage} definiti come \type{struct timeval}. La
-struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli
-campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
-\var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}.
+utilizzata anche dalla funzione \func{getrusage} (vedi
+\secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
+processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
\subsection{Le funzioni \func{exec}}
{int execve(const char *filename, char *const argv[], char *const envp[])}
Esegue il programma contenuto nel file \param{filename}.
- \bodydesc{La funzione ritorna -1 solo in caso di errore, nel qual caso
- caso la \var{errno} può assumere i valori:
+ \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
+ qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
- montato in \cmd{noexec}, oppure non è un file normale o un interprete.
+ montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
\item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
è root, e o il processo viene tracciato, o il filesystem è montato con
l'opzione \cmd{nosuid}.
\begin{itemize*}
\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
(\acr{ppid}).
-\item il \textit{real user id} ed il \textit{real group id} (vedi
- \secref{sec:proc_access_id}).
-\item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}).
-\item il \textit{session id} ed il \textit{process group id} (vedi
+\item l'\textsl{userid reale}, il \textit{groupid reale} ed i \textsl{groupid
+ supplementari} (vedi \secref{sec:proc_access_id}).
+\item il \textit{session id} ed il \textit{process groupid} (vedi
\secref{sec:sess_xxx}).
\item il terminale di controllo (vedi \secref{sec:sess_xxx}).
-\item il tempo restante ad un allarme (vedi \secref{sec:sig_xxx}).
+\item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
\item la directory radice e la directory di lavoro corrente (vedi
\secref{sec:file_work_dir}).
\item la maschera di creazione dei file (\var{umask}, vedi
\secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
\secref{sec:file_locking}).
\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
- \secref{sec:sig_sigpending}).
-\item i limiti sulle risorse (vedi \secref{sec:sys_limits}).
+ \secref{sec:sig_sigmask}).
+\item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
- \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
+ \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
\end{itemize*}
-Inoltre i segnali che sono stati settati per essere ignorati nel processo
-chiamante mantengono lo stesso settaggio pure nel nuovo programma, tutti gli
-altri segnali vengono settati alla loro azione di default. Un caso speciale è
-il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}, può anche
-non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_gen_beha}).
+Inoltre i segnali che sono stati impostati per essere ignorati nel processo
+chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
+gli altri segnali vengono impostati alla loro azione predefinita. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando impostato a
+\macro{SIG\_IGN}, può anche non essere reimpostato a \macro{SIG\_DFL} (si veda
+\secref{sec:sig_gen_beha}).
La gestione dei file aperti dipende dal valore che ha il flag di
\textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
-descriptor. I file per cui è settato vengono chiusi, tutti gli altri file
-restano aperti. Questo significa che il comportamento di default è che i file
+descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
+restano aperti. Questo significa che il comportamento predefinito è che i file
restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
-\func{fcntl} che setti il suddetto flag.
+\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 \secref{sec:file_dir_read}) che effettua da sola il
-settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
+\func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola
+l'impostazione del flag di \textit{close-on-exec} sulle directory che apre, in
maniera trasparente all'utente.
-Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
-restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
-l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
-il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
-settato, in questo caso l'\textit{effective user id} e l'\textit{effective
- group id} vengono settati rispettivamente all'utente o al gruppo cui il file
-appartiene (per i dettagli vedi \secref{sec:proc_perms}).
+Abbiamo detto che l'\textsl{userid reale} ed il \textsl{groupid reale} restano
+gli stessi all'esecuzione di \func{exec}; lo stesso vale per l'\textsl{userid
+ effettivo} ed il \textsl{groupid effettivo} (il significato di questi
+identificatori è trattato in \secref{sec:proc_access_id}), tranne quando il
+file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
+impostato, in questo caso l'\textsl{userid effettivo} ed il \textsl{groupid
+ effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
+file appartiene (per i dettagli vedi \secref{sec:proc_perms}).
Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
-\emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
-\emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
+\acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
+\acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
deve esse un valido programma (binario, non un altro script) che verrà
chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
\func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
-altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
+altre funzioni sono ausiliarie e servono la lettura e l'impostazione dei vari
parametri connessi ai processi.
Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
realtà già esistono estensioni di questo modello base, che lo rendono più
flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
- o il \textit{Mandatory Access Control} di SELinux} di sicurezza di un
+ o il \textit{Mandatory Access Control} di 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
%notevole flessibilità,
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
-identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel
-per identificare uno specifico utente o un gruppo di utenti, per poi poter
+identificatori univoci, lo userid ed il groupid; 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 \secref{sec:file_access_control} vedremo come ad ogni file vengano
associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
anche poter identificare chi è che ha lanciato un certo programma, e pertanto
-anche a ciascun processo è associato un utente e a un gruppo.
+anche a ciascun processo dovrà essere associato ad un utente e ad un gruppo.
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}.
+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 \tabref{tab:proc_uid_gid}.
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|c|l|p{6.5cm}|}
+ \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
\hline
- \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\
+ \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
+ & \textbf{Significato} \\
\hline
\hline
- \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato
- il programma\\
- \acr{gid} & \textit{real group id} & indica il gruppo dell'utente
- che ha lanciato il programma \\
+ \acr{uid} & \textit{real} & \textsl{userid reale}
+ & indica l'utente che ha lanciato il programma\\
+ \acr{gid} & '' &\textsl{groupid reale}
+ & indica il gruppo principale dell'utente che ha lanciato
+ il programma \\
\hline
- \acr{euid} & \textit{effective user id} & indica l'utente usato
- dal programma nel controllo di accesso \\
- \acr{egid} & \textit{effective group id} & indica il gruppo
- usato dal programma nel controllo di accesso \\
- -- & \textit{supplementary group id} & indica i gruppi cui
- l'utente appartiene \\
+ \acr{euid} & \textit{effective} &\textsl{userid effettivo}
+ & indica l'utente usato nel controllo di accesso \\
+ \acr{egid} & '' & \textsl{groupid effettivo}
+ & indica il gruppo usato nel controllo di accesso \\
+ -- & -- & \textsl{groupid supplementari}
+ & indicano gli ulteriori gruppi cui l'utente appartiene \\
\hline
- -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\
- -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\
+ -- & \textit{saved} & \textsl{userid salvato}
+ & è una copia dell'\acr{euid} iniziale\\
+ -- & '' & \textsl{groupid salvato}
+ & è una copia dell'\acr{egid} iniziale \\
\hline
- \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
- il filesystem \\
- \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
- per il filesystem \\
+ \acr{fsuid} & \textit{filesystem} &\textsl{userid di filesystem}
+ & indica l'utente effettivo per l'accesso al filesystem \\
+ \acr{fsgid} & '' & \textsl{groupid di filesystem}
+ & indica il gruppo effettivo per l'accesso al filesystem \\
\hline
\end{tabular}
\caption{Identificatori di utente e gruppo associati a ciascun processo con
- indicazione dei suffissi usate dalle varie funzioni di manipolazione.}
+ indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
\label{tab:proc_uid_gid}
\end{table}
-Al primo gruppo appartengono il \textit{real user id} e il \textit{real group
- id}: questi vengono settati al login ai valori corrispondenti all'utente con
-cui si accede al sistema (e relativo gruppo di default). Servono per
-l'identificazione dell'utente e normalmente non vengono mai cambiati. In
-realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
-solo ad un processo che abbia i privilegi di amministratore; questa
-possibilità è usata ad esempio da \cmd{login} che, una volta completata la
-procedura di autenticazione, lancia una shell per la quale setta questi
-identificatori ai valori corrispondenti all'utente che entra nel sistema.
-
-Al secondo gruppo appartengono l'\textit{effective user id} e
-l'\textit{effective group id} (a cui si aggiungono gli eventuali
-\textit{supplementary group id} dei gruppi dei quali l'utente fa parte).
-Questi sono invece gli identificatori usati nella verifiche dei permessi del
-processo e per il controllo di accesso ai file (argomento affrontato in
-dettaglio in \secref{sec:file_perm_overview}).
+Al primo gruppo appartengono l'\textsl{userid reale} ed il \textsl{groupid
+ 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 \secref{sec:proc_setuid}) che è possibile
+modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
+questa possibilità è usata proprio dal programma \cmd{login} che, una volta
+completata la procedura di autenticazione, lancia una shell per la quale
+imposta questi identificatori ai valori corrispondenti all'utente che entra
+nel sistema.
+
+Al secondo gruppo appartengono l'\textsl{userid effettivo} e l'\textsl{groupid
+ effettivo} (a cui si aggiungono gli eventuali \textsl{groupid supplementari}
+dei gruppi dei quali l'utente fa parte). Questi sono invece gli
+identificatori usati nella verifiche dei permessi del processo e per il
+controllo di accesso ai file (argomento affrontato in dettaglio in
+\secref{sec:file_perm_overview}).
Questi identificatori normalmente sono identici ai corrispondenti del gruppo
\textit{real} tranne nel caso in cui, come accennato in
\secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
-\acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
-dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
-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).
+\acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato
+in dettaglio in \secref{sec:file_suid_sgid}). 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).
Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
possono essere letti dal processo attraverso delle opportune funzioni, i cui
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
- \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del
- processo corrente.
-
- \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del
+ \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{userid reale} del
processo corrente.
- \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del
+ \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{userid effettivo} del
processo corrente.
- \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del
+ \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{groupid reale} del
processo corrente.
+ \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{groupid effettivo}
+ del processo corrente.
+
\bodydesc{Queste funzioni non riportano condizioni di errore.}
\end{functions}
per i quali erano richiesti, e a poterli eventualmente recuperare in caso
servano di nuovo.
-Questo in Linux viene fatto usando altri due gruppi di identificatori, il
-\textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
-gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
-definita la costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a
- cuore la portabilità del programma su altri Unix è buona norma controllare
- sempre la disponibilità di queste funzioni controllando se questa costante è
+Questo in Linux viene fatto usando altri gli altri due gruppi di
+identificatori, il \textit{saved} ed il \textit{filesystem}. Il primo gruppo è
+lo stesso usato in SVr4, e previsto dallo standard POSIX quando è definita la
+costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la
+ portabilità del programma su altri Unix è buona norma controllare sempre la
+ disponibilità di queste funzioni controllando se questa costante è
definita.} il secondo gruppo è specifico di Linux e viene usato per
migliorare la sicurezza con NFS.
-Il \textit{saved user id} e il \textit{saved group id} sono copie
-dell'\textit{effective user id} e dell'\textit{effective group id} del
-processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
-processo, come copie dell'\textit{effective user id} e dell'\textit{effective
- group id} dopo che questo sono stati settati tenendo conto di eventuali
-\acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale
-fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
-programma.
-
-Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
-estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
-sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
-corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
-operazioni di verifica dei permessi relativi ai file (trattate in
-\secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli
-\textit{effective id} viene automaticamente riportato su di essi, per cui in
-condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
-saranno del tutto equivalenti ai precedenti.
-
-Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
-di utente e gruppo associati dal kernel ad ogni processo, è riportato in
-\tabref{tab:proc_uid_gid}.
+L'\textsl{userid salvato} ed il \textsl{groupid salvato} sono copie
+dell'\textsl{userid effettivo} e del \textsl{groupid effettivo} del processo
+padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
+come copie dell'\textsl{userid effettivo} e del \textsl{groupid effettivo}
+dopo che questo sono stati impostati tenendo conto di eventuali \acr{suid} o
+\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{userid di filesystem} e il \textsl{groupid di filesystem} sono
+un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
+(torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
+replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
+quali si sostituiscono per tutte le operazioni di verifica dei permessi
+relativi ai file (trattate in \secref{sec:file_perm_overview}). Ogni
+cambiamento effettuato sugli identificatori effettivi viene automaticamente
+riportato su di essi, per cui in condizioni normali si può tranquillamente
+ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
\subsection{Le funzioni \func{setuid} e \func{setgid}}
Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
di appartenenza) ad un processo sono rispettivamente \func{setuid} e
\func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
-seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
-e del \textit{saved group id}; i loro prototipi sono:
+seguono la semantica POSIX che prevede l'esistenza dell'\textit{userid
+ salvato} e del \textit{groupid salvato}; i loro prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
-\funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo
+\funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{userid} del processo
corrente.
-\funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo
+\funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{groupid} del processo
corrente.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima; la seconda si comporta esattamente allo stesso modo facendo
-riferimento al \textit{group id} invece che all'\textit{user id}. Gli
-eventuali \textit{supplementary group id} non vengono modificati.
-
+riferimento al \textsl{groupid} invece che all'\textsl{userid}. Gli
+eventuali \textsl{groupid supplementari} non vengono modificati.
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
-sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}
-e \textit{saved}) vengono settati al valore specificato da \var{uid},
-altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
-valore specificato corrisponde o al \textit{real user id} o al \textit{saved
- user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).
+l'\textsl{userid 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 \var{uid},
+altrimenti viene impostato solo l'\textsl{userid effettivo}, e soltanto se il
+valore specificato corrisponde o all'\textsl{userid reale} o
+all'\textsl{userid salvato}. Negli altri casi viene segnalato un errore (con
+\macro{EPERM}).
Come accennato l'uso principale di queste funzioni è quello di poter
-consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di
-riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
+consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati di
+riportare l'\textsl{userid effettivo} a quello dell'utente che ha lanciato il
programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
eventualmente tornare indietro.
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} settato.
+il bit \acr{sgid} impostato.
Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
situazione degli identificatori è la seguente:
\begin{eqnarray*}
\label{eq:1}
- \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\
- \textit{effective group id} &=& \textrm{\acr{utmp}} \\
- \textit{saved group id} &=& \textrm{\acr{utmp}}
+ \textsl{groupid reale} &=& \textrm{\acr{gid} (del chiamante)} \\
+ \textsl{groupid effettivo} &=& \textrm{\acr{utmp}} \\
+ \textsl{groupid salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
-in questo modo, dato che l'\textit{effective group id} è quello giusto, il
+in questo modo, dato che il \textsl{groupid effettivo} è quello giusto, il
programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
-questo punto il programma può eseguire una \code{setgid(getgid())} per settare
-l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
- group id} corrisponde la funzione avrà successo), in questo modo non sarà
-possibile lanciare dal terminale programmi che modificano detto file, in tal
-caso infatti la situazione degli identificatori sarebbe:
+questo punto il programma può eseguire una \code{setgid(getgid())} per
+impostare il \textsl{groupid effettivo} a quello dell'utente (e dato che il
+\textsl{groupid reale} corrisponde la funzione avrà successo), in questo modo
+non sarà possibile lanciare dal terminale programmi che modificano detto file,
+in tal caso infatti la situazione degli identificatori sarebbe:
\begin{eqnarray*}
\label{eq:2}
- \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
- \textit{effective group id} &=& \textrm{\acr{gid}} \\
- \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
+ \textsl{groupid reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{groupid effettivo} &=& \textrm{\acr{gid}} \\
+ \textsl{groupid salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
-\textit{effective group id}. All'uscita dal terminale, per poter di nuovo
+\textsl{groupid effettivo}. All'uscita dal terminale, per poter di nuovo
aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
\acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
-in questo caso il valore richiesto corrisponde al \textit{saved group id} la
+in questo caso il valore richiesto corrisponde al \textsl{groupid salvato} la
funzione avrà successo e riporterà la situazione a:
\begin{eqnarray*}
\label{eq:3}
- \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
- \textit{effective group id} &=& \textrm{\acr{utmp}} \\
- \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
+ \textsl{groupid reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{groupid effettivo} &=& \textrm{\acr{utmp}} \\
+ \textsl{groupid salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
consentendo l'accesso a \file{/var/log/utmp}.
rendendo impossibile riguadagnare i privilegi di amministratore. Questo
comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
una nuova shell per l'utente; ma quando si vuole cambiare soltanto
-l'\textit{effective user id} del processo per cedere i privilegi occorre
+l'\textsl{userid effettivo} del processo per cedere i privilegi occorre
ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
\label{sec:proc_setreuid}
Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
- alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i
-\textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
-e \textit{real id}. I loro prototipi sono:
+ alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} gli
+identificatori del gruppo \textit{saved}, le usa per poter scambiare fra di
+loro \textit{effective} e \textit{real}. I loro prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
-\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Setta il \textit{real user
- id} e l'\textit{effective user id} del processo corrente ai valori
+\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{userid
+ reale} e l'\textsl{userid effettivo} del processo corrente ai valori
specificati da \var{ruid} e \var{euid}.
-\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Setta il \textit{real group
- id} e l'\textit{effective group id} del processo corrente ai valori
+\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{groupid
+ reale} ed il \textsl{groupid effettivo} del processo corrente ai valori
specificati da \var{rgid} e \var{egid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
di fallimento: l'unico errore possibile è \macro{EPERM}.}
\end{functions}
-I processi non privilegiati possono settare i \textit{real id} soltanto ai
-valori dei loro \textit{effective id} o \textit{real id} e gli
-\textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
- id} o \textit{saved id}; valori diversi comportano il fallimento della
-chiamata; l'amministratore invece può specificare un valore qualunque.
-Specificando un valore di -1 l'identificatore corrispondente viene lasciato
-inalterato.
+La due funzioni sono analoghe ed il loro comportamento è identico; quanto
+detto per la prima prima riguardo l'userid, si applica immediatamente alla
+seconda per il groupid. I processi non privilegiati possono impostare solo i
+valori del loro userid 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 funzione si possono scambiare fra loro \textit{real id} e
-\textit{effective id}, 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.
+Con queste funzione si possono scambiare fra loro gli userid reale e
+effettivo, e pertanto è possibile implementare un comportamento simile a
+quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
+scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
+scambio.
In questo caso però occorre porre molta attenzione quando si creano nuovi
processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
+questo caso infatti essi avranno un userid 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 i \textit{real id} agli
-\textit{effective id}) in caso contrario quest'ultimo 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'userid reale a quello effettivo) in
+caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
+e riottenere privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
-si porrebbe per i \textit{saved id}: queste funzioni derivano da
-un'implementazione che non ne prevede la presenza, e quindi non è possibile
-usarle per correggere la situazione come nel caso precedente. Per questo
-motivo in Linux tutte le volte che vengono usate per modificare uno degli
-identificatori ad un valore diverso dal \textit{real id} precedente, il
-\textit{saved id} viene sempre settato al valore dell'\textit{effective id}.
-
+si pone per l'userid 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'userid reale
+corrente, l'userid salvato viene automaticamente uniformato al valore
+dell'userid effettivo.
\subsection{Le funzioni \func{seteuid} e \func{setegid}}
\label{sec:proc_seteuid}
Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
-supportate dalla maggior parte degli Unix) e usate per cambiare gli
-\textit{effective id}; i loro prototipi sono:
+supportate dalla maggior parte degli Unix) e vengono usate per cambiare gli
+identificatori del gruppo \textit{effective}; i loro prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
-\funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del
-processo corrente a \var{uid}.
+\funcdecl{int seteuid(uid\_t uid)} Imposta l'userid effettivo del processo
+corrente a \var{uid}.
-\funcdecl{int setegid(gid\_t gid)} Setta l'\textit{effective group id} del
-processo corrente a \var{gid}.
+\funcdecl{int setegid(gid\_t gid)} Imposta il groupid effettivo del processo
+corrente a \var{gid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
di fallimento: l'unico errore possibile è \macro{EPERM}.}
\end{functions}
-Gli utenti normali possono settare l'\textit{effective id} solo al valore del
-\textit{real id} o del \textit{saved id}, l'amministratore può specificare
-qualunque valore. Queste funzioni sono usate per permettere a root di settare
-solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
-il settaggio di tutti gli identificatori.
+Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
+la prima. Gli utenti normali possono impostare l'userid effettivo solo al
+valore dell'userid reale o dell'userid salvato, l'amministratore può
+specificare qualunque valore. Queste funzioni sono usate per permettere
+all'amministratore di impostare solo l'userid effettivo, dato che l'uso
+normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
\subsection{Le funzioni \func{setresuid} e \func{setresgid}}
\headdecl{unistd.h}
\headdecl{sys/types.h}
-\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Setta il
-\textit{real user id}, l'\textit{effective user id} e il \textit{saved user
- id} del processo corrente ai valori specificati rispettivamente da
-\var{ruid}, \var{euid} e \var{suid}.
+\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
+l'userid reale, l'userid effettivo e l'userid salvato del processo corrente
+ai valori specificati rispettivamente da \var{ruid}, \var{euid} e \var{suid}.
-\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Setta il
-\textit{real group id}, l'\textit{effective group id} e il \textit{saved group
- id} del processo corrente ai valori specificati rispettivamente da
-\var{rgid}, \var{egid} e \var{sgid}.
+\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
+groupid reale, il groupid effettivo ed il groupid salvato del processo
+corrente ai valori specificati rispettivamente da \var{rgid}, \var{egid} e
+\var{sgid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
di fallimento: l'unico errore possibile è \macro{EPERM}.}
\end{functions}
-I processi non privilegiati possono cambiare uno qualunque degli
-identificatori usando uno qualunque dei valori correnti di \textit{real id},
-\textit{effective id} o \textit{saved id}, l'amministratore può specificare i
-valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
-l'identificatore corrispondente.
+Le due funzioni sono identiche, quanto detto per la prima riguardo gli userid
+si applica alla seconda per i groupid. I processi non privilegiati possono
+cambiare uno qualunque degli userid solo ad un valore corripondente o
+all'userid reale, o a quello effettivo o a quello salvato, l'amministratore
+può specificare i valori che vuole; un valore di -1 per un qualunque parametro
+lascia inalterato l'identificatore corrispondente.
Per queste funzioni esistono anche due controparti che permettono di leggere
in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
\headdecl{unistd.h}
\headdecl{sys/types.h}
-\funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il
-\textit{real user id}, l'\textit{effective user id} e il \textit{saved user
- id} del processo corrente.
+\funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
+l'userid reale, l'userid effettivo e l'userid salvato del processo corrente.
\funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
-\textit{real group id}, l'\textit{effective group id} e il \textit{saved group
- id} del processo corrente.
+groupid reale, il groupid effettivo e il groupid salvato del processo
+corrente.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
nessun privilegio. I valori sono restituiti negli argomenti, che vanno
specificati come puntatori (è un'altro esempio di \textit{value result
- argument}). Si noti che queste funzioni sono le uniche in grado di leggere i
-\textit{saved id}.
+ argument}). Si noti che queste funzioni sono le uniche in grado di leggere
+gli identificatori del gruppo \textit{saved}.
\subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
\label{sec:proc_setfsuid}
-Queste funzioni sono usate per settare gli identificatori usati da Linux per
-il controllo dell'accesso ai file. Come già accennato in
-\secref{sec:proc_access_id} in Linux è definito questo ulteriore gruppo di
-identificatori, che di norma sono assolutamente equivalenti agli
-\textit{effective id}, dato che ogni cambiamento di questi ultimi viene
-immediatamente riportato sui \textit{filesystem id}.
-
-C'è un solo caso in cui si ha necessità di introdurre una differenza fra
-\textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
-problema di sicurezza che si presenta quando si deve implementare un server
-NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
-ai file per assumere l'identità del singolo utente remoto, ma se questo viene
-fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
-espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
-ha temporaneamente assunto l'identità. Cambiando solo il \textit{filesystem
- id} 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.
+Queste funzioni sono usate per impostare gli identificatori del gruppo
+\textit{filesystem} che usati da Linux per il controllo dell'accesso ai file.
+Come già accennato in \secref{sec:proc_access_id} Linux definisce questo
+ulteriore gruppo di identificatori, che di norma sono assolutamente
+equivalenti a quelli del gruppo \textit{effective}, dato che ogni cambiamento
+di questi ultimi viene immediatamente riportato su di essi.
+
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
+identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
+ovviare ad un problema di sicurezza che si presenta quando si deve
+implementare un server NFS. Il server NFS infatti deve poter cambiare
+l'identificatore con cui accede ai file per assumere l'identità del singolo
+utente remoto, ma se questo viene fatto cambiando l'userid effettivo o
+l'userid 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'userid 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 \func{setfsuid}
e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
\begin{functions}
\headdecl{sys/fsuid.h}
-\funcdecl{int setfsuid(uid\_t fsuid)} Setta il \textit{filesystem user id} del
+\funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'userid di filesystem del
processo corrente a \var{fsuid}.
-\funcdecl{int setfsgid(gid\_t fsgid)} Setta l'\textit{filesystem group id} del
+\funcdecl{int setfsgid(gid\_t fsgid)} Imposta il groupid di filesystem del
processo corrente a \var{fsgid}.
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
\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 \textit{real}, \textit{effective} o \textit{saved id}.
+coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
+\textit{saved}.
\subsection{Le funzioni \func{setgroups} e \func{getgroups}}
\bodydesc{La funzione restituisce il numero di gruppi letti in caso di
successo e -1 in caso di fallimento, nel qual caso \var{errno} viene
- settata a:
+ impostata a:
\begin{errlist}
\item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
\item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
\end{errlist}}
\end{functions}
\noindent non è specificato se la funzione inserisca o meno nella lista
-l'\textit{effective user id} 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.
+il groupid effettivo del processo. Se si specifica un valore di \param{size}
+uguale a 0 \param{list} non viene modificato, ma si ottiene il numero di
+gruppi supplementari.
Una seconda funzione, \func{getgrouplist}, può invece essere usata per
ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
perché qualora il valore specificato sia troppo piccolo la funzione ritorna
-1, passando indietro il numero dei gruppi trovati.
-Per settare i gruppi supplementari di un processo ci sono due funzioni, che
+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 è \func{setgroups}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
- \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi
+ \funcdecl{int setgroups(size\_t size, gid\_t *list)} Imposta i gruppi
supplementari del processo ai valori specificati in \param{list}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} viene settata a:
+ fallimento, nel qual caso \var{errno} viene impostata a:
\begin{errlist}
\item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
\item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}}
\end{functions}
-Se invece si vogliono settare i gruppi supplementari del processo a quelli di
+Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
un utente specifico, si può usare \func{initgroups} il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{grp.h}
- \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi
+ \funcdecl{int initgroups(const char *user, gid\_t group)} Imposta i gruppi
supplementari del processo a quelli di cui è membro l'utente \param{user},
aggiungendo il gruppo addizionale \param{group}.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} viene settata agli stessi valori di
+ fallimento, nel qual caso \var{errno} viene impostata agli stessi valori di
\func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
allocare lo spazio per informazioni dei gruppi.}
\end{functions}
La funzione esegue la scansione del database dei gruppi (usualmente
\file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
-poi setta usando \func{setgroups}.
-
+poi imposta usando \func{setgroups}.
Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
\label{sec:proc_priority}
In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-lo \textit{scheduler}\footnote{che è la parte del kernel che si occupa di
- stabilire quale processo dovrà essere posto in esecuzione.} assegna la CPU
-ai vari processi attivi. In particolare prendremo in esame i vari meccanismi
-con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le
-varie funzioni di gestione.
+lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
+prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
+tempo di CPU, ed illustreremo le varie funzioni di gestione.
\subsection{I meccanismi di \textit{scheduling}}
La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
-ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera
-essenziale anche dal tipo di utilizzo che deve essere fatto del sistema.
+ed oggetto di numerose ricerche; in generale essa dipende in maniera
+essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
+cui non esiste un meccanismo che sia valido per tutti gli usi.
+
+La caratteristica specifica di un sistema multitasking come Linux è quella del
+cosiddetto \textit{prehemptive multitasking}: questo significa che al
+contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
+ multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
+quando la CPU deve essere passata ad un altro processo. Come accennato in
+\secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
+apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
+distribuire al meglio il tempo di CPU fra i vari processi.
La cosa è resa ancora più complicata dal fatto che con le architetture
-multi-processore si introduce anche la problematica dovuta alla scelta di
-quale sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni
- la presenza di ampie cache può rendere poco efficiente trasferire
- l'esecuzione di un processo da una CPU ad un'altra, per cui occorrono
- meccanismi per determininare quale è la migliore scelta fra le diverse CPU.}
-Tutto questo comunque appartiene alle sottigliezze dell'implementazione del
-kernel, e dal punto di vista dei programmi che girano in user space anche
-quando si hanno più processori, e quindi potenzialmente anche dei processi che
-sono eseguiti davvero in contemporanea, si può pensare alle politiche di
-scheduling come concernenti la risorsa \textsl{tempo di esecuzione}, la cui
-assegnazione sarà governata dagli stessi meccanismi di scelta di priorità,
-solo che nel caso di più processori sarà a disposizione di più di un processo
-alla volta.
-
-Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle
-risorse (insieme alla memoria e all'accesso alle periferiche) che sono
-necessarie per l'esecuzione di un programma, e spesso non è neanche la più
-importante. Per questo non è affatto detto che dare ad un programma la massima
-priorità di esecuzione abbia risultati significativi in termini di
-prestazioni.
-
-La politica tradizionale di scheduling di Unix (che tratteremo in
-\secref{sec:proc_sched_stand}) è sempre stata basata su delle priorità
-dinamiche, che assicurassero che tutti i processi, anche i meno importanti,
-potessero ricevere un po' di tempo di CPU.
-
-Lo standard POSIX però per tenere conto dei sistemi real-time,\footnote{per
- sistema real-time si intende un sistema in grado di eseguire operazioni in
- tempo reale; 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 processi che non hanno questa necessità, ha introdotto il concetto di
-\textsl{priorità assoluta}, chimata anche \textsl{priorità statica}, in
-contrapposizione con la normale priorità dinamica.
-
-Il concetto di prorità assoluta dice che quando due processi si contendono
-l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche,
-grazie al \textit{prehemptive scheduling}, se l'altro è in esecuzione.
-Ovviamente questo avviene solo per i processi che sono pronti per essere
-eseguiti (cioè nello stato \textit{runnable}\footnote{lo stato di un processo
- è riportato nel campo \texttt{STAT} dell'output del comando \cmd{ps},
- abbiamo già visto che lo stato di \textit{zombie} è indicato con \texttt{Z},
- gli stati \textit{runnable}, \textit{sleep} e di I/O (\textit{uninteruttible
- sleep}) sono invece indicati con \texttt{R}, \texttt{S} e \texttt{D}.}),
-la priorità assoluta viene invece ignorata per quelli che sono bloccati su una
-richiesta di I/O o in stato di \textit{sleep}.
+multi-processore si deve anche scegliere quale sia la CPU più opportuna da
+utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
+ rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
+ un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
+ 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.
+
+Si tenga conto poi che i processi non devono solo eseguire del codice: ad
+esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
+venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
+tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
+kernel provvedere a mettere in esecuzione un altro processo.
+
+Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
+processo, in Linux un processo può trovarsi in uno degli stati riportati in
+\tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
+\textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
+sia la sua priorità, un processo non potrà mai essere messo in esecuzione
+fintanto che esso si trova in uno qualunque degli altri stati.
-Questa viene in genere indicata con un numero
+\begin{table}[htb]
+ \centering
+ \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
+ \hline
+ \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \textbf{Runnable} & \texttt{R} & Il processo è in esecuzione o è pronto ad
+ essere eseguito (cioè è in attesa che gli venga assegnata la CPU). \\
+ \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un
+ risposta dal sistema, ma può essere interrotto da un segnale. \\
+ \textbf{Uninterrutible Sleep} & \texttt{D} & Il processo è in
+ attesa di un risposta dal sistema (in genere per I/O), e non può essere
+ interrotto in nessuna circostanza. \\
+ \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
+ \macro{SIGSTOP}, o è tracciato.\\
+ \textbf{Zombie} & \texttt{Z} & Il processo è terminato ma il suo stato di
+ terminazione non è ancora stato letto dal padre. \\
+ \hline
+ \end{tabular}
+ \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
+ \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
+ \cmd{ps} nell'omonimo campo.}
+ \label{tab:proc_proc_states}
+\end{table}
+Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
+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.
+
+Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
+\secref{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.
+
+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à.
+
+Il concetto di priorità assoluta dice che quando due processi si contendono
+l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
+quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).
+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
+\secref{sec:proc_real_time}.
+In generale quello che succede in tutti gli Unix moderni è che ai processi
+normali viene sempre data una priorità assoluta pari a zero, e la decisione di
+assegnazione della CPU è fatta solo con il meccanismo tradizionale della
+priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
+assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
+priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
+bisogno della CPU.
\subsection{Il meccanismo di \textit{scheduling} standard}
\label{sec:proc_sched_stand}
-In Linux tutti i processi hanno sostanzialmente la stessa priorità; benché sia
-possibile specificare una priorità assoluta secondo lo standard POSIX
-(argomento che tratteremo più avanti) l'uso comune segue quello che è il
-meccanismo tradizionale con cui i sistemi
+A meno che non si abbiano esigenze 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 tutti i processi ordinari hanno la stessa priorità
+assoluta. Quello che determina quale, fra tutti i processi in attesa di
+esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
+così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
+questo la priorità dinamica determina quanto a lungo un processo continuerà ad
+essere eseguito, e quando un processo potrà subentrare ad un altro
+nell'esecuzione.
+
+Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
+assegnata una \textit{time-slice}, cioè in intervallo di tempo (letteralmente
+una fetta) per il quale esso deve essere eseguito. Il valore della
+\textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
+\textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di
+\var{task\_struct}; tutti i processi vengono creati con lo stesso valore, ed
+essa specifica il valore della durata iniziale della \textit{time-slice} che
+viene assegnato ad un altro campo della struttura (\var{counter}) quando il
+processo viene eseguito per la prima volta e diminuito progressivamente ad
+ogni interruzione del timer.
+
+Quando lo scheduler viene eseguito scandisce la coda dei processi in stato
+\textit{runnable} associando, sulla base del valore di \var{counter}, un peso
+a ciascun processo in attesa di esecuzione,\footnote{il calcolo del peso in
+ realtà è un po' più complicato, ad esempio nei sistemi multiprocessore viene
+ favorito un processo che è eseguito sulla stessa CPU, e a parità del valore
+ di \var{counter} viene favorito chi ha una priorità più elevata.} chi ha il
+peso più alto verrà posto in esecuzione, ed il precedente processo sarà
+spostato in fondo alla coda. Dato che ad ogni interruzione del timer il
+valore di \var{counter} del processo corrente viene diminuito, questo assicura
+che anche i processi con priorità più bassa verranno messi in esecuzione.
+
+La priorità di un processo è così controllata attraverso il valore di
+\var{nice}, che stabilisce la durata della \textit{time-slice}; per il
+meccanismo appena descritto infatti un valore più lungo infatti assicura una
+maggiore attribuzione di CPU. L'origine del nome di questo parametro sta nel
+fatto che in genere esso viene generalmente usato per diminuire la priorità di
+un processo, come misura di cortesia nei confronti degli altri.
+I processi infatti vengono creati dal sistema con lo stesso valore di
+\var{nice} (nullo) e nessuno è privilegiato rispetto agli altri; il valore può
+essere modificato solo attraverso la funzione \func{nice}, il cui prototipo è:
+\begin{prototype}{unistd.h}
+{int nice(int inc)}
+ Aumenta il valore di \var{nice} per il processo corrente.
+
+ \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
+ specificato un valore di \param{inc} negativo.
+ \end{errlist}}
+\end{prototype}
+
+L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
+quest'ultimo può assumere valori compresi fra \macro{PRIO\_MIN} e
+\macro{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
+\param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
+sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
+positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
+priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
+l'amministratore può specificare valori negativi che permettono di aumentare
+la priorità di un processo.
+
+In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
+questa convenzione, e per leggere il nuovo valore occorre invece usare la
+funzione \func{getpriority}, derivata da BSD, il cui 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[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
+ \item[\macro{EINVAL}] il valore di \param{which} non è valido.
+ \end{errlist}}
+\end{prototype}
+\noindent (in 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 di leggere la priorità di un processo, di un gruppo di
+processi (vedi \secref{sec:sess_proc_group}) o di un utente, a seconda del
+valore di \param{which}, secondo la legenda di \tabref{tab:proc_getpriority},
+specificando un corrispondente valore per \param{who}; un valore nullo di
+quest'ultimo indica il processo, il gruppo di processi o l'utente correnti.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \param{which} & \param{who} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{PRIO\_PROCESS} & \type{pid\_t} & processo \\
+ \macro{PRIO\_PRGR} & \type{pid\_t} & process group \\
+ \macro{PRIO\_USER} & \type{uid\_t} & utente \\
+ \hline
+ \end{tabular}
+ \caption{Legenda del valore dell'argomento \param{which} e del tipo
+ dell'argomento \param{who} delle funzioni \func{getpriority} e
+ \func{setpriority} per le tre possibili scelte.}
+ \label{tab:proc_getpriority}
+\end{table}
+
+La funzione restituisce la priorità più alta (cioè il valore più basso) fra
+quelle dei processi specificati; dato che -1 è un valore possibile, per poter
+rilevare una condizione di errore è necessario cancellare sempre \var{errno}
+prima della chiamata alla funzione, per verificare che essa resti uguale a
+zero.
+
+Analoga a \func{getpriority} la funzione \func{setpriority} 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 la priorità in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
+ \item[\macro{EINVAL}] il valore di \param{which} non è valido.
+ \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
+ specificato un valore di \param{inc} negativo.
+ \item[\macro{EACCESS}] un processo senza i privilegi di amministratore ha
+ cercato di modificare la priorità di un processo di un altro utente.
+ \end{errlist}}
+\end{prototype}
+
+La funzione imposta la priorità al valore specificato da \param{prio} per
+tutti i processi indicati dagli argomenti \param{which} e \param{who}. La
+gestione dei permessi dipende dalle varie implementazioni; in Linux, secondo
+le specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
+derivano da SYSV, è richiesto che l'userid reale o effettivo del processo
+chiamante corrispondano al real user id (e solo quello) del processo di cui si
+vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
+Ultrix, *BSD) la corrispondenza può essere anche con l'userid effettivo.
+
+
\subsection{Il meccanismo di \textit{scheduling real-time}}
\label{sec:proc_real_time}
-Per settare le
+Come spiegato in \secref{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
+ siano installate le patch di RTLinux o RTAI, con i quali è possibile
+ ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
+ interrupt vengono intercettati dall'interfaccia real-time, e gestiti
+ 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
+page fault\index{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 \secref{sec:proc_mem_lock}), il primo
+non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
+esecuzione di qualunque processo.
+
+In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
+ad un processo una priorità assoluta e questo finisce in un loop infinito,
+nessun altro processo potrà essere eseguito, ed esso sarà mantenuto in
+esecuzione permanentemente assorbendo tutta la CPU e senza nessuna possibilità
+di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno,
+quando si lavora con processi che usano priorità assolute, tenere attiva una
+shell cui si sia assegnata la massima priorità assoluta, in modo da poter
+essere comunque in grado di rientrare nel sistema.
+
+Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
+esecuzione prima di ogni processo normale. In caso di più processi sarà
+eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
+processi con la stessa priorità assoluta questi vengono tenuti in una coda
+tocca al kernel decidere quale deve essere eseguito.
+
+
+
+Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
+di scheduling che si è scelto; lo standard ne prevede due:
+\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{FIFO}] il processo viene eseguito fintanto che non cede
+ volontariamente la CPU, si blocca, finisce o viene interrotto da un processo
+ a priorità più alta.
+\item[\textit{Round Robin}] ciascun processo viene eseguito a turno per un
+ certo periodo di tempo (una \textit{time slice}). Solo i processi con la
+ stessa priorità ed in stato \textit{runnable} entrano nel circolo.
+\end{basedescript}
+
+La funzione per impostare le politiche di scheduling (sia real-time che
+ordinarie) ed i relativi parametri è \func{sched\_setscheduler}; 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 per il processo \param{pid}.
+
+ \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[\macro{ESRCH}] il processo \param{pid} non esiste.
+ \item[\macro{EINVAL}] il valore di \param{policy} non esiste o il relativo
+ valore di \param{p} non è valido.
+ \item[\macro{EPERM}] il processo non ha i privilegi per attivare la
+ politica richiesta (vale solo per \macro{SCHED\_FIFO} e
+ \macro{SCHED\_RR}).
+ \end{errlist}}
+\end{prototype}
+
+La funzione esegue l'impostazione per il processo specificato; un valore nullo
+di \param{pid} esegue l'impostazione per il processo corrente, solo un
+processo con i privilegi di amministratore può impostare delle priorità
+assolute diverse da zero. La politica di scheduling è specificata
+dall'argomento \param{policy} i cui possibili valori sono riportati in
+\tabref{tab:proc_sched_policy}; un valore negativo per \param{policy} mantiene
+la politica di scheduling corrente.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|l|}
+ \hline
+ \textbf{Policy} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
+ \macro{SCHED\_RR} & Scheduling real-time con politica \textit{Round
+ Robin} \\
+ \macro{SCHED\_OTHER}& Scheduling ordinario\\
+ \hline
+ \end{tabular}
+ \caption{Valori dell'argomento \param{policy} per la funzione
+ \func{sched\_setscheduler}. }
+ \label{tab:proc_sched_policy}
+\end{table}
+
+Il valore della priorità è passato attraverso la struttura \var{sched\_param}
+(riportata in \figref{fig:sig_sched_param}), il cui solo campo attualmente
+definito è \var{sched\_priority}, che nel caso delle priorità assolute deve
+essere specificato nell'intervallo fra un valore massimo ed uno minimo, che
+nel caso sono rispettivamente 1 e 99 (il valore zero è legale, ma indica i
+processi normali).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct sched_param {
+ int sched_priority;
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \var{sched\_param}.}
+ \label{fig:sig_sched_param}
+\end{figure}
+
+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 realtime, tramite le due funzioni \func{sched\_get\_priority\_max}
+e \func{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[\macro{EINVAL}] il valore di \param{policy} è invalido.
+ \end{errlist}}
+\end{functions}
+
+
+I processi con politica di scheduling \macro{SCHED\_OTHER} devono specificare
+un valore nullo (altrimenti si avrà un errore \macro{EINVAL}), questo valore
+infatti non ha niente a che vedere con la priorità dinamica determinata dal
+valore di \var{nice}, che deve essere impostato con le funzioni viste in
+precedenza.
+
+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 \textit{runnable} viene sempre inserito in coda alla lista. Se la
+politica scelta è \macro{SCHED\_FIFO} quando il processo viene eseguito viene
+automaticamente rimesso in coda alla lista, e la sua esecuzione continua
+fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
+volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
+sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
+nel caso che esso sia stato interrotto da un processo a priorità più alta.
+
+La priorità assoluta può essere riletta indietro dalla funzione
+\func{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}
+ \item[\macro{ESRCH}] il processo \param{pid} non esiste.
+ \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
+ \end{errlist}}
+\end{prototype}
+
+La funzione restituisce il valore (secondo la quanto elencato in
+\tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
+specificato; se \param{pid} è nullo viene restituito quello del processo
+chiamante.
+
+Se si intende operare solo sulla priorità assoluta di un processo si possono
+usare le funzioni \func{sched\_setparam} e \func{sched\_getparam}, i cui
+prototipi sono:
+
+\begin{functions}
+ \headdecl{sched.h}
+
+ \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
+ Imposta la priorità assoluta del processo \param{pid}.
+
+
+ \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
+ Legge la priorità assoluta del processo \param{pid}.
+
+ \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[\macro{ESRCH}] il processo \param{pid} non esiste.
+ \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
+ \end{errlist}}
+\end{functions}
+
+L'uso di \func{sched\_setparam} che è del tutto equivalente a
+\func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
+\func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
+sul processo corrente. La disponibilità di entrambe le funzioni può essere
+verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
+definita nell'header \macro{sched.h}.
+
+L'ultima funzione che permette di leggere le informazioni relative ai processi
+real-time è \func{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 0in caso di successo e -1 in caso di errore,
+ nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] il processo \param{pid} non esiste.
+ \item[\macro{ENOSYS}] la system call non è stata implementata.
+ \end{errlist}}
+\end{prototype}
+
+La funzione restituisce il valore dell'intervallo di tempo usato per la
+politica \textit{round robin} in una struttura \var{timespec}, (la cui
+definizione si può trovare in \figref{fig:sys_timeval_struct}).
+
+
+Come accennato ogni processo che usa lo scheduling real-time può rilasciare
+volontariamente la CPU; questo viene fatto attraverso la funzione
+\func{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}
+
+La funzione fa si che il processo rilasci la CPU, in modo da essere rimesso in
+coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
+altro processo; se però il processo è l'unico ad essere presente sulla coda
+l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
+in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
+con pari priorità quando la sezione più urgente è finita.
+
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
In un ambiente multitasking il concetto è essenziale, dato che un processo può
essere interrotto in qualunque momento dal kernel che mette in esecuzione un
altro processo o dalla ricezione di un segnale; occorre pertanto essere
-accorti nei confronti delle possibili \textit{race condition} (vedi
+accorti nei confronti delle possibili
+\textit{race condition}\index{race condition} (vedi
\secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
cui non erano ancora state completate.
qualunque momento, e le operazioni di un eventuale \textit{signal handler}
sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
il solo accesso o l'assegnazione di una variabile possono non essere più
-operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
+operazioni atomiche (torneremo su questi aspetti in
+\secref{sec:sig_control}).
In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
il cui accesso è assicurato essere atomico. In pratica comunque si può
assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
-\type{int}, gli altri interi di dimensione inferiore ed i puntatori sono
+\ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
le strutture. In tutti questi casi è anche opportuno marcare come
-\type{volatile} le variabili che possono essere interessate ad accesso
+\ctyp{volatile} le variabili che possono essere interessate ad accesso
condiviso, onde evitare problemi con le ottimizzazioni del codice.
-\subsection{Le \textit{race condition} e i \textit{deadlock}}
+
+\subsection{Le \textit{race condition}\index{race condition} e i
+ \textit{deadlock}}
\label{sec:proc_race_cond}
Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
-gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
+gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
\textit{race condition} si hanno quando diversi processi accedono allo stesso
file, o nell'accesso a meccanismi di intercomunicazione come la memoria
condivisa. In questi casi, se non si dispone della possibilità di eseguire
cui si compiono le operazioni sulle risorse condivise (le cosiddette
\textsl{sezioni critiche}) del programma, siano opportunamente protette da
meccanismi di sincronizzazione (torneremo su queste problematiche di questo
-tipo in \secref{sec:ipc_semaph}).
+tipo in \capref{cha:IPC}).
Un caso particolare di \textit{race condition} sono poi i cosiddetti
\textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
ogni volta e ritornato indietro la funzione può essere rientrante, se invece
-esso viene individuato dalla funzione stessa, due chiamate alla stessa
-funzione potranno interferire quando entrambe faranno riferimento allo stesso
-oggetto. Allo stesso modo una funzione può non essere rientrante se usa e
-modifica un oggetto che le viene fornito dal chiamante: due chiamate possono
-interferire se viene passato lo stesso oggetto; in tutti questi casi occorre
-molta cura da parte del programmatore.
+esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
+potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
+Allo stesso modo una funzione può non essere rientrante se usa e modifica un
+oggetto che le viene fornito dal chiamante: due chiamate possono interferire
+se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
+parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
esempio utilizzano variabili statiche, le \acr{glibc} però mettono a