%% prochand.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2015 by Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\begin{figure}[!htb]
\footnotesize
-\begin{Command}
-[piccardi@gont piccardi]$ pstree -n
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+[piccardi@gont piccardi]$ \textbf{pstree -n}
init-+-keventd
|-kapm-idled
|-kreiserfsd
|-5*[getty]
|-snort
`-wwwoffled
-\end{Terminal}
+\end{Console}
%$
\caption{L'albero dei processi, così come riportato dal comando
\cmd{pstree}.}
% http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
% TODO completare la parte su quando viene chiamato lo scheduler.
-Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
-\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito in occasione di dell'invocazione di ogni \textit{system call} ed per
-ogni interrupt dall'hardware oltre che in una serie di altre occasioni, e può
-essere anche attivato esplicitamente. Il timer di sistema provvede comunque a
-che esso sia invocato periodicamente, generando un interrupt periodico secondo
-una frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
-(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
-che lo \textit{scheduler} scheduler venga comunque eseguito ad intervalli
-regolari e possa prendere le sue decisioni.
+\itindbeg{scheduler}
+Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler} che
+decide quale processo mettere in esecuzione; esso viene eseguito in occasione
+di dell'invocazione di ogni \textit{system call} ed per ogni interrupt
+dall'hardware oltre che in una serie di altre occasioni, e può essere anche
+attivato esplicitamente. Il timer di sistema provvede comunque a che esso sia
+invocato periodicamente, generando un interrupt periodico secondo una
+frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
+(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
+che lo \textit{scheduler} venga comunque eseguito ad intervalli regolari e
+possa prendere le sue decisioni.
A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
completamente diverso, detto \textit{tickless}, in cui non c'è più una
sospensione anche per lunghi periodi di tempo.
Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
-viene eseguito lo \itindex{scheduler} \textit{scheduler} effettua il calcolo
-delle priorità dei vari processi attivi (torneremo su questo in
-sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
-esecuzione fino alla successiva invocazione.
+viene eseguito lo \textit{scheduler} effettua il calcolo delle priorità dei
+vari processi attivi (torneremo su questo in sez.~\ref{sec:proc_priority}) e
+stabilisce quale di essi debba essere posto in esecuzione fino alla successiva
+invocazione.
+\itindend{scheduler}
\subsection{Gli identificatori dei processi}
\label{sec:proc_pid}
\url{http://gapil.truelite.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
+(\texttt{\small 24-40}) esegue in successione la creazione dei processi figli
controllando il successo della chiamata a \func{fork} (\texttt{\small
- 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
+ 25-29}); ciascun figlio (\texttt{\small 31-34}) si limita a stampare il
suo numero di successione, eventualmente attendere il numero di secondi
specificato e scrivere un messaggio prima di uscire. Il processo padre invece
-(\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
+(\texttt{\small 36-38}) stampa un messaggio di creazione, eventualmente
attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
alla conclusione del ciclo, prima di uscire, può essere specificato un altro
periodo di attesa.
Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
-specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
+specificare attese (come si può notare in (\texttt{\small 17-19}) i valori
predefiniti specificano di non attendere), otterremo come risultato sul
terminale:
-\begin{Command}
-[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3}
Process 1963: forking 3 child
Spawned 1 child, pid 1964
Child 1 successfully executing
Child 3, parent 1963, exiting
Spawned 3 child, pid 1966
Go to next child
-\end{Terminal}
+\end{Console}
+%$
Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
si può dire quale processo fra il padre ed il figlio venga eseguito per primo
e poi il padre.
In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
-\itindex{scheduler} \textit{scheduling} usato dal kernel, dalla particolare
-situazione in cui si trova la macchina al momento della chiamata, risultando
-del tutto impredicibile. Eseguendo più volte il programma di prova e
-producendo un numero diverso di figli, si sono ottenute situazioni
-completamente diverse, compreso il caso in cui il processo padre ha eseguito
-più di una \func{fork} prima che uno dei figli venisse messo in esecuzione.
+\textit{scheduling} usato dal kernel, dalla particolare situazione in cui si
+trova la macchina al momento della chiamata, risultando del tutto
+impredicibile. Eseguendo più volte il programma di prova e producendo un
+numero diverso di figli, si sono ottenute situazioni completamente diverse,
+compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
+prima che uno dei figli venisse messo in esecuzione.
Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}).
-In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler}
-\textit{scheduler} è stato modificato per eseguire sempre per primo il
-figlio.\footnote{i risultati precedenti infatti sono stati ottenuti usando un
- kernel della serie 2.4.} Questa è una ottimizzazione adottata per evitare
-che il padre, effettuando per primo una operazione di scrittura in memoria,
-attivasse il meccanismo del \itindex{copy~on~write} \textit{copy on write},
-operazione inutile qualora il figlio venga creato solo per eseguire una
-\func{exec} su altro programma che scarta completamente lo spazio degli
-indirizzi e rende superflua la copia della memoria modificata dal
-padre. Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata
-subito, con la certezza di utilizzare \itindex{copy~on~write} \textit{copy on
- write} solo quando necessario.
+In realtà con l'introduzione dei kernel della serie 2.6 lo \textit{scheduler}
+è stato modificato per eseguire sempre per primo il figlio.\footnote{i
+ risultati precedenti infatti sono stati ottenuti usando un kernel della
+ serie 2.4.} Questa è una ottimizzazione adottata per evitare che il padre,
+effettuando per primo una operazione di scrittura in memoria, attivasse il
+meccanismo del \itindex{copy~on~write} \textit{copy on write}, operazione
+inutile qualora il figlio venga creato solo per eseguire una \func{exec} su
+altro programma che scarta completamente lo spazio degli indirizzi e rende
+superflua la copia della memoria modificata dal padre. Eseguendo sempre per
+primo il figlio la \func{exec} verrebbe effettuata subito, con la certezza di
+utilizzare \itindex{copy~on~write} \textit{copy on write} solo quando
+necessario.
Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
(principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
quello che avviene si può redirigere su un file l'output del programma di
test, quello che otterremo è:
-\begin{Command}
-[piccardi@selidor sources]$ ./forktest 3 > output
-[piccardi@selidor sources]$ cat output
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{./forktest 3 > output}
+[piccardi@selidor sources]$ \textbf{cat output}
Process 1967: forking 3 child
Child 1 successfully executing
Child 1, parent 1967, exiting
Go to next child
Spawned 3 child, pid 1970
Go to next child
-\end{Terminal}
+\end{Console}
che come si vede è completamente diverso da quanto ottenevamo sul terminale.
Il comportamento delle varie funzioni di interfaccia con i file è analizzato
in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
adottata nelle librerie del linguaggio C e valida per qualunque sistema
-operativo. Qui basta accennare che si sono usate le funzioni standard della
-libreria del C che prevedono l'output bufferizzato. Il punto è che questa
-bufferizzazione (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering})
-varia a seconda che si tratti di un file su disco, in cui il buffer viene
-scaricato su disco solo quando necessario, o di un terminale, in cui il buffer
-viene scaricato ad ogni carattere di a capo.
+operativo.
+
+Qui basta accennare che si sono usate le funzioni standard della libreria del
+C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione
+(che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda
+che si tratti di un file su disco, in cui il buffer viene scaricato su disco
+solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad
+ogni carattere di a capo.
Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
le singole righe comparivano a video subito dopo l'esecuzione della
\func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
-fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una
-copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle
-funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando
-il buffer viene scritto su disco all'uscita del figlio, troveremo nel file
-anche tutto quello che il processo padre aveva scritto prima della sua
-creazione. E alla fine del file (dato che in questo caso il padre esce per
-ultimo) troveremo anche l'output completo del padre.
+fine di ogni riga e l'output resta nel buffer.
+
+Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà
+anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte
+dal padre fino allora. Così quando il buffer viene scritto su disco all'uscita
+del figlio, troveremo nel file anche tutto quello che il processo padre aveva
+scritto prima della sua creazione. E alla fine del file (dato che in questo
+caso il padre esce per ultimo) troveremo anche l'output completo del padre.
L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
condivisa fra il padre e tutti i processi figli.
Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
- così il file su cui un programma scrive i suoi dati in uscita, tratteremo
- l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre viene
-rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
-figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
-processi figli tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd})
-dei file aperti nel processo padre (allo stesso modo in cui lo fa la funzione
-\func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
-figli condividono le stesse voci della \itindex{file~table} \textit{file
- table} (tratteremo in dettaglio questi termini in
-sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione corrente nel
-file.
+ così il file su cui di default un programma scrive i suoi dati in uscita,
+ tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre
+viene rediretto come si è fatto nell'esempio, lo stesso avviene anche per
+tutti i figli. La funzione \func{fork} infatti ha la caratteristica di
+duplicare nei processi figli tutti i \textit{file descriptor} (vedi
+sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
+in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il
+che comporta che padre e figli condividono le stesse voci della
+\itindex{file~table} \textit{file table} (tratteremo in dettaglio questi
+termini in sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione
+corrente nel file.
In questo modo se un processo scrive su un file aggiornerà la posizione
corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
-\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
- \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
- sez.~\ref{sec:file_fcntl_ioctl});
+\item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
+ (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
- \textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
+ \textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
sez.~\ref{sec:proc_access_id});
\item gli identificatori per il controllo di sessione: il
\itindex{process~group} \textit{process group-ID} e il \textit{session id}
(vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
-\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
- azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
+\item la maschera dei segnali bloccati (vedi
+ sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
+ sez.~\ref{sec:sig_gen_beha});
\item i segmenti di memoria condivisa agganciati al processo (vedi
sez.~\ref{sec:ipc_sysv_shm});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
Come verifica di questo comportamento possiamo eseguire il nostro programma
\cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
di uscire, il risultato è:
-\begin{Command}
-[piccardi@selidor sources]$ ./forktest -c2 3
-\end{Command}
-\begin{Terminal}[commandchars=\\\{\}]
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{./forktest -c2 3}
Process 1972: forking 3 child
Spawned 1 child, pid 1973
Child 1 successfully executing
Spawned 3 child, pid 1975
Go to next child
-\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
+[piccardi@selidor sources]$ Child 3, parent 1, exiting
Child 2, parent 1, exiting
Child 1, parent 1, exiting
-\end{Terminal}
+\end{Console}
come si può notare in questo caso il processo padre si conclude prima dei
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
terminale (prima dello scadere dei 10 secondi) otterremo:
-\begin{Command}
-[piccardi@selidor sources]$ ps T
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{ps T}
PID TTY STAT TIME COMMAND
419 pts/0 S 0:00 bash
568 pts/0 S 0:00 ./forktest -e10 3
570 pts/0 Z 0:00 [forktest <defunct>]
571 pts/0 Z 0:00 [forktest <defunct>]
572 pts/0 R 0:00 ps T
-\end{Terminal}
+\end{Console}
+%$
e come si vede, dato che non si è fatto nulla per riceverne lo stato di
terminazione, i tre processi figli sono ancora presenti pur essendosi
conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
tenuta sempre presente quando si scrive un programma che deve essere mantenuto
-in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
-avere cura di far leggere l'eventuale stato di uscita di tutti i figli. In
-genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
-la funzione \func{wait}, (vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}) di cui vedremo un esempio in
-fig.~\ref{fig:sig_sigchld_handl}.
-
-Questa operazione è necessaria perché anche se gli \itindex{zombie}
-\textit{zombie} non consumano risorse di memoria o processore, occupano
-comunque una voce nella tabella dei processi e se li si lascia accumulare a
-lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi
-processi.
+in esecuzione a lungo e creare molti processi figli. In questo caso si deve
+sempre avere cura di far leggere al programma l'eventuale stato di uscita di
+tutti i figli. Una modalità comune di farlo è attraverso l'utilizzo di un
+apposito \textit{signal handler} che chiami la funzione \func{wait}, (vedi
+sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio
+(fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}.
+
+La lettura degli stati di uscita è necessaria perché anche se gli
+\itindex{zombie} \textit{zombie} non consumano risorse di memoria o
+processore, occupano comunque una voce nella tabella dei processi e se li si
+lasciano accumulare a lungo quest'ultima potrebbe esaurirsi, con la
+conseguente impossibilità di lanciare nuovi processi.
Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
-sez.~\ref{sec:sig_termination}). L'unica possibilità di cancellarli dalla
-tabella dei processi è quella di terminare il processo che li ha generati, in
-modo che \cmd{init} possa adottarli e concluderne la terminazione.
+sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+terminare il processo che li ha generati e che non sta facendo il suo lavoro,
+in modo che \cmd{init} possa adottarli e concluderne correttamente la
+terminazione.
+
+Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei
+processi non è sempre indice di un qualche malfunzionamento, in una macchina
+con molto carico infatti può esservi una presenza temporanea dovuta al fatto
+che il processo padre ancora non ha avuto il tempo di gestirli.
\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
\label{tab:proc_waitid_idtype}
\end{table}
-Come per \func{waitpid} anche il comportamento di \func{waitid} viene
+Come per \func{waitpid} anche il comportamento di \func{waitid} è
controllato dall'argomento \param{options}, da specificare come maschera
binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
alcuni di questi siano identici come significato ed effetto ai precedenti di
famiglia di funzioni) che possono essere usate per questo compito, in realtà
(come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
tutte varianti che consentono di invocare in modi diversi, semplificando il
-passaggio degli argomenti, la \textit{system call} \funcd{execve}, il cui
+passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui
prototipo è:
\begin{funcproto}{
per indicare il nome del file che contiene il programma che verrà eseguito.
\begin{figure}[!htb]
- \centering \includegraphics[width=10cm]{img/exec_rel}
+ \centering \includegraphics[width=9cm]{img/exec_rel}
\caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
\label{fig:proc_exec_relat}
\end{figure}
\begin{itemize*}
\item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
(\ids{PPID});
-\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
+\item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
\item la directory radice e la \index{directory~di~lavoro} directory di lavoro
corrente (vedi sez.~\ref{sec:file_work_dir});
\begin{itemize*}
\item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
pendenti vengono cancellate;
-\item le \itindex{capabilities} \textit{capabilities} vengono modificate come
+\item le \textit{capabilities} vengono modificate come
illustrato in sez.~\ref{sec:proc_capabilities};
-\item tutti i \itindex{thread} \textit{thread} tranne il chiamante (vedi
+\item tutti i \textit{thread} tranne il chiamante (vedi
sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
\item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
localizzazione al valore di default POSIX.
\end{itemize*}
+\itindbeg{close-on-exec}
+
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
-\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
-\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun
-\textit{file descriptor}. I file per cui è impostato vengono chiusi, tutti gli
-altri file restano aperti. Questo significa che il comportamento predefinito è
-che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
-esplicita a \func{fcntl} che imposti il suddetto flag. Per le directory, lo
-standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec},
-in genere questo è fatto dalla funzione \func{opendir} (vedi
+\func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}) per ciascun \textit{file descriptor}. I file
+per cui è impostato vengono chiusi, tutti gli altri file restano
+aperti. Questo significa che il comportamento predefinito è che i file restano
+aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
+\func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
+POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
+questo è fatto dalla funzione \func{opendir} (vedi
sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
-\itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
-maniera trasparente all'utente.
+\textit{close-on-exec} sulle directory che apre, in maniera trasparente
+all'utente.
+
+\itindend{close-on-exec}
+
Il comportamento della funzione in relazione agli identificatori relativi al
controllo di accesso verrà trattato in dettaglio in sez.~\ref{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{/lib/ld.so} prima
del programma per caricare le librerie necessarie ed effettuare il link
-dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
- molto probabile che non il relativo supporto non sia disponibile.} Se il
-programma è in formato ELF per caricare le librerie dinamiche viene usato
-l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
-stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
-collegati con la \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
-collegati con la \acr{glibc}.
+dell'eseguibile; il formato è ormai in completo disuso, per cui è molto
+probabile che non il relativo supporto non sia disponibile. Se il programma è
+in formato ELF per caricare le librerie dinamiche viene usato l'interprete
+indicato nel segmento \const{PT\_INTERP} previsto dal formato stesso, in
+genere questo è \sysfile{/lib/ld-linux.so.1} per programmi collegati con la
+\acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi collegati con la
+\acr{glibc}.
Infine nel caso il programma che si vuole eseguire sia uno script e non un
binario, questo deve essere un file di testo che deve iniziare con una linea
\end{Example}
dove l'interprete indicato deve essere un eseguibile binario e non un altro
script, che verrà chiamato come se si fosse eseguito il comando
-\cmd{interpreter [argomenti] filename}.\footnote{si tenga presente che con
- Linux quanto viene scritto come \texttt{argomenti} viene passato
- all'interprete come un unico argomento con una unica stringa di lunghezza
- massima di 127 caratteri e se questa dimensione viene ecceduta la stringa
- viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
- comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
- nei vari argomenti e se è troppo lunga restituisce un errore di
- \const{ENAMETOOLONG}, una comparazione dei vari comportamenti si trova su
- \url{http://www.in-ulm.de/~mascheck/various/shebang/}.}
+\cmd{interpreter [argomenti] filename}.
+
+Si tenga presente che con Linux quanto viene scritto come \texttt{argomenti}
+viene passato all'interprete come un unico argomento con una unica stringa di
+lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la
+stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
+comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
+nei vari argomenti e se è troppo lunga restituisce un errore di
+\const{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
+sistemi unix-like si trova su
+\url{http://www.in-ulm.de/~mascheck/various/shebang/}.
Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
realtà già esistono estensioni di questo modello base, che lo rendono più
- flessibile e controllabile, come le \itindex{capabilities}
- \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
- per i file (vedi sez.~\ref{sec:file_ACL}) o il
- \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
- di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
- SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
- infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
- \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
- a livello del kernel per modularizzare tutti i possibili controlli di
- accesso, cosa che ha permesso di realizzare diverse alternative a
- \index{SELinux} SELinux.} di sicurezza di un sistema unix-like è fondato sui
-concetti di utente e gruppo, e sulla separazione fra l'amministratore
-(\textsl{root}, detto spesso anche \textit{superuser}) che non è sottoposto a
-restrizioni, ed il resto degli utenti, per i quali invece vengono effettuati i
-vari controlli di accesso.
+ flessibile e controllabile, come le \textit{capabilities} illustrate in
+ sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi
+ sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di
+ \textit{SELinux}; inoltre basandosi sul lavoro effettuato con
+ \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+ infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in
+ grado di fornire diversi agganci a livello del kernel per modularizzare
+ tutti i possibili controlli di accesso, cosa che ha permesso di realizzare
+ diverse alternative a \textit{SELinux}.}
+di sicurezza di un sistema unix-like è fondato sui concetti di utente e
+gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso
+anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto
+degli utenti, per i quali invece vengono effettuati i vari controlli di
+accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID}
Infine per impostare i gruppi supplementari di un processo ci sono due
funzioni, che possono essere usate solo se si hanno i privilegi di
-amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
- \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione
-di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4,
- ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
+amministratore.\footnote{e più precisamente se si ha la \textit{capability}
+ \macro{CAP\_SETGID}.} La prima delle due è la funzione di sistema
+\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
+ differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
il suo prototipo è:
\label{sec:proc_priority}
In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
-attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
-gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
-gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
-per l'accesso a disco) divenute disponibili con i kernel più recenti.
+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. Tratteremo infine
+anche le altre priorità dei processi (come quelle per l'accesso a disco)
+divenute disponibili con i kernel più recenti.
\subsection{I meccanismi di \textit{scheduling}}
Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
dipende strettamente dalla versione di kernel; in particolare a partire
- dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
- modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
- ed è stata anche introdotta la possibilità di usare diversi algoritmi,
- selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
- all'avvio (addirittura è stato ideato un sistema modulare che permette di
- cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
-ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
-tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
-viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
-calcolata dallo scheduler a partire da un valore iniziale che viene
-\textsl{diminuito} tutte le volte che un processo è in stato \textit{runnable}
-ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
- dinamica e la conseguente scelta di quale processo mettere in esecuzione
- avviene con un algoritmo molto più complicato, che tiene conto anche della
- \textsl{interattività} del processo, utilizzando diversi fattori, questa è
- una brutale semplificazione per rendere l'idea del funzionamento, per una
- trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
- funzionamento dello scheduler si legga il quarto capitolo di
- \cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
-tutti i processi in stato \textit{runnable}, quello che ha il valore di
-priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
- del valore numerico ad esse associato è infatti invertito, un valore più
- basso significa una priorità maggiore.} Il fatto che questo valore venga
-diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
-significa che la priorità dei processi che non ottengono l'uso del processore
-viene progressivamente incrementata, così che anche questi alla fine hanno la
+ dalla serie 2.6.x lo \textit{scheduler} è stato riscritto completamente, con
+ molte modifiche susseguitesi per migliorarne le prestazioni, per un certo
+ periodo ed è stata anche introdotta la possibilità di usare diversi
+ algoritmi, selezionabili sia in fase di compilazione, che, nelle versioni
+ più recenti, all'avvio (addirittura è stato ideato un sistema modulare che
+ permette di cambiare lo \textit{scheduler} a sistema attivo).} ma a grandi
+linee si può dire che ad ogni processo è assegnata una \textit{time-slice},
+cioè un intervallo di tempo (letteralmente una fetta) per il quale, a meno di
+eventi esterni, esso viene eseguito senza essere interrotto. Inoltre la
+priorità dinamica viene calcolata dallo \textit{scheduler} a partire da un
+valore iniziale che viene \textsl{diminuito} tutte le volte che un processo è
+in stato \textit{runnable} ma non viene posto in esecuzione.\footnote{in
+ realtà il calcolo della priorità dinamica e la conseguente scelta di quale
+ processo mettere in esecuzione avviene con un algoritmo molto più
+ complicato, che tiene conto anche della \textsl{interattività} del processo,
+ utilizzando diversi fattori, questa è una brutale semplificazione per
+ rendere l'idea del funzionamento, per una trattazione più dettagliata, anche
+ se non aggiornatissima, dei meccanismi di funzionamento dello
+ \textit{scheduler} si legga il quarto capitolo di \cite{LinKernDev}.} Lo
+\textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi in
+stato \textit{runnable}, quello che ha il valore di priorità dinamica più
+basso.\footnote{con le priorità dinamiche il significato del valore numerico
+ ad esse associato è infatti invertito, un valore più basso significa una
+ priorità maggiore.} Il fatto che questo valore venga diminuito quando un
+processo non viene posto in esecuzione pur essendo pronto, significa che la
+priorità dei processi che non ottengono l'uso del processore viene
+progressivamente incrementata, così che anche questi alla fine hanno la
possibilità di essere eseguiti.
Sia la dimensione della \textit{time-slice} che il valore di partenza della
che ciascun processo si porta dietro, essa viene ereditata dai processi
figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
- la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
- \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
-questo parametro sta nel fatto che generalmente questo viene usato per
+ la riscrittura dello \textit{scheduler} eseguita nel 2.6 viene mantenuta nel
+ campo \texttt{static\_prio} come per le priorità statiche.} L'origine del
+nome di questo parametro sta nel fatto che generalmente questo viene usato per
\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
confronti degli altri. I processi infatti vengono creati dal sistema con un
valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
il risultato nell'intervallo consentito. Valori positivi comportano maggiore
\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
-solo l'amministratore\footnote{o un processo con la \itindex{capabilities}
- \textit{capability} \const{CAP\_SYS\_NICE}, vedi
- sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
-di \param{inc} che permettono di aumentare la priorità di un processo, a
-partire da questa versione è consentito anche agli utenti normali alzare
-(entro certi limiti, che vedremo in sez.~\ref{sec:sys_resource_limit}) la
-priorità dei propri processi.
+solo l'amministratore\footnote{o un processo con la \textit{capability}
+ \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può
+specificare valori negativi di \param{inc} che permettono di aumentare la
+priorità di un processo, a partire da questa versione è consentito anche agli
+utenti normali alzare (entro certi limiti, che vedremo in
+sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
\hline
\const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
\const{PRIO\_PRGR} & \type{pid\_t} & \itindex{process~group}
- \textit{process group} \\
+ \textit{process group}\\
\const{PRIO\_USER} & \type{uid\_t} & utente \\
\hline
\end{tabular}
\textit{nice} valido.
Si tenga presente che solo l'amministratore\footnote{o più precisamente un
- processo con la \itindex{capabilities} \textit{capability}
- \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
-possibilità di modificare arbitrariamente le priorità di qualunque
-processo. Un utente normale infatti può modificare solo la priorità dei suoi
-processi ed in genere soltanto diminuirla. Fino alla versione di kernel
-2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
-sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello
-effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo
-a quello) del processo di cui si intendeva cambiare la priorità. A partire
-dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi
-derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere
-anche con l'\ids{UID} effettivo.
+ processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi
+ sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare
+arbitrariamente le priorità di qualunque processo. Un utente normale infatti
+può modificare solo la priorità dei suoi processi ed in genere soltanto
+diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le
+specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV
+veniva richiesto che l'\ids{UID} reale o quello effettivo del processo
+chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo
+di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è
+stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS,
+Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID}
+effettivo.
Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
ordinari poter aumentare la priorità dei propri processi specificando un
\const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
\const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
ulteriore di lavoro \textit{CPU
- intensive} (dal kernel 2.6.16)\\
+ intensive} (dal kernel 2.6.16).\\
\const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
- bassa (dal kernel 2.6.23)\\
+ bassa (dal kernel 2.6.23).\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{policy} per la funzione
\label{tab:proc_sched_policy}
\end{table}
+% TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta
+% con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e
+% http://lwn.net/Articles/575497/
+
Con le versioni più recenti del kernel sono state introdotte anche delle
varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
-delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
-interattività che mira a favorire i processi che si svegliano dallo stato di
-\textit{sleep}.\footnote{cosa che accade con grande frequenza per i processi
- interattivi, dato che essi sono per la maggior parte del tempo in attesa di
- dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
-nome, per processi che usano molta CPU (come programmi di calcolo) che in
-questo modo sono leggermente sfavoriti rispetto ai processi interattivi che
-devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di
-\textit{nice}.
+delle priorità dinamiche fatto dallo \textit{scheduler}, il cosiddetto bonus
+di interattività che mira a favorire i processi che si svegliano dallo stato
+di \textit{sleep}.\footnote{cosa che accade con grande frequenza per i
+ processi interattivi, dato che essi sono per la maggior parte del tempo in
+ attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come
+indica il nome, per processi che usano molta CPU (come programmi di calcolo)
+che in questo modo sono leggermente sfavoriti rispetto ai processi interattivi
+che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore
+di \textit{nice}.
La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
si desidera siano eseguiti con la più bassa priorità possibile, ancora più
la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
impostato con le funzioni viste in precedenza.
-Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle
+Lo standard POSIX.1b prevede inoltre che l'intervallo dei valori delle
priorità statiche possa essere ottenuto con le funzioni di sistema
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
nel caso che esso sia stato interrotto da un processo a priorità più alta.
Solo un processo con i privilegi di amministratore\footnote{più precisamente
- con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
+ con la capacità \const{CAP\_SYS\_NICE}, vedi
sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
processore.
Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, l'uso di
-questa funzione non è necessario, in quanto è lo scheduler stesso che provvede
-a mantenere al meglio l'affinità di processore. Esistono però esigenze
-particolari, ad esempio quando un processo (o un gruppo di processi) è
-utilizzato per un compito importante (ad esempio per applicazioni
+questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che
+provvede a mantenere al meglio l'affinità di processore. Esistono però
+esigenze particolari, ad esempio quando un processo (o un gruppo di processi)
+è utilizzato per un compito importante (ad esempio per applicazioni
\textit{real-time} o la cui risposta è critica) e si vuole la massima
velocità, e con questa interfaccia diventa possibile selezionare gruppi di
processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando
utilizzate anche in un sistema con un processore singolo, nel qual caso però
non avranno alcun risultato effettivo.
-
\itindend{scheduler}
\itindend{CPU~affinity}
rimosso a partire dal kernel 2.6.25.
%TODO verificare http://lwn.net/Articles/355987/
+
\section{Funzioni di gestione avanzata}
\label{sec:proc_advanced_control}
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
- \itindex{capabilities} \textit{capabilities} (vedi
- sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità
- specificata nell'argomento \param{arg2} (con una delle costanti di
- tab.~\ref{tab:proc_capabilities}) è presente nel \textit{capabilities
- bounding set} del processo e zero altrimenti, se \param{arg2} non è un
- valore valido si avrà un errore di \errval{EINVAL}. Introdotta a partire
- dal kernel 2.6.25.
+ \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
+ ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
+ delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
+ \textit{capabilities bounding set} del processo e zero altrimenti,
+ se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
+ Introdotta a partire dal kernel 2.6.25.
\item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
- \itindex{capabilities} \textit{capabilities} (vedi
- sez.~\ref{sec:proc_capabilities}) dal processo e da tutti i suoi
- discendenti. La funzione cancella la capacità specificata
+ \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
+ da tutti i suoi discendenti. La funzione cancella la capacità specificata
nell'argomento \param{arg2} con una delle costanti di
- tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set}
- \itindex{capabilities~bounding~set} del processo. L'operazione richiede i
- privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), altrimenti
- la chiamata fallirà con un errore di \errcode{EPERM}; se il valore
- di \param{arg2} non è valido o se il supporto per le \textit{file
- capabilities} non è stato compilato nel kernel la chiamata fallirà con un
- errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25.
+ tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
+ processo. L'operazione richiede i privilegi di amministratore (la capacità
+ \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
+ \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
+ per le \textit{file capabilities} non è stato compilato nel kernel la
+ chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
+ kernel 2.6.25.
\item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
terminazione di un processo a causa di un segnale per il quale è prevista la
a partire dal kernel 2.4.21, solo su PowerPC.
\item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
- \itindex{capabilities} \textit{capabilities} vengono cancellate quando si
- esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda
+ \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
+ \ids{UID} del processo (per i dettagli si veda
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
dal kernel 2.2.18.
\item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
- il valore del flag di controllo delle \itindex{capabilities}
- \textit{capabilities} impostato con \const{PR\_SET\_KEEPCAPS}. Introdotta a
- partire dal kernel 2.2.18.
+ il valore del flag di controllo delle \textit{capabilities} impostato con
+ \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
\item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
Introdotta a partire dal kernel 2.6.23, disponibile solo se si è abilitato
il supporto nel kernel con \texttt{CONFIG\_SECCOMP}.
+% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
+% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
+% Documentation/prctl/seccomp_filter.txt
+% vedi anche http://lwn.net/Articles/600250/
+
+% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
+% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
+
\item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
lo stato corrente del \textit{secure computing mode}, al momento attuale la
funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si
veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
- richiede i privilegi di amministratore (la \itindex{capabilities} capacità
- \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
- \errval{EPERM}. Introdotta a partire dal kernel 2.6.26.
+ richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
+ altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
+ partire dal kernel 2.6.26.
\item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
funzione l'impostazione corrente per i \itindex{securebits}
\item[\const{PR\_GET\_CHILD\_SUBREAPER}] Ottiene il \ids{PID} del processo a
cui vengono assegnati come figli gli orfani del processo
corrente. Introdotta a partire dal kernel 3.4.
+ % TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
+ % * Documentation/prctl/seccomp_filter.txt
+ % * http://lwn.net/Articles/475043/
+
+
+% TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi
+% http://lwn.net/Articles/582712/
+
+% TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i
+% parametri di base del layout dello spazio di indirizzi di un processo (area
+% codice e dati, stack, brack pointer ecc. vedi
+% http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e
+
+
\label{sec:prctl_operation}
\end{basedescript}
memoria, la \textit{system call}, a differenza della funzione di libreria che
vedremo a breve, consente anche di passare per \param{child\_stack} il valore
\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
-processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
- sottinteso cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo
- a breve.} ed in questo caso si applica la semantica del
-\itindex{copy~on~write} \textit{copy on write} illustrata in
-sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
-automaticamente copiate come le altre e il nuovo processo avrà un suo
-\textit{stack} totalmente indipendente da quello del padre.
+processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
+cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
+in questo caso si applica la semantica del \itindex{copy~on~write}
+\textit{copy on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le
+pagine dello \textit{stack} verranno automaticamente copiate come le altre e
+il nuovo processo avrà un suo \textit{stack} totalmente indipendente da quello
+del padre.
Dato che l'uso principale della nuova \textit{system call} è quello relativo
alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
-un processo.
+un processo ordinario e non un \textit{thread}.
Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
nuovo processo da essa creato, è controllato principalmente
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
-\item[\const{CLONE\_CHILD\_SETTID}]
-\item[\const{CLONE\_FILES}]
-\item[\const{CLONE\_FS}]
+ all'indirizzo dato dall'argomento \param{ctid}, eseguendo un riattivazione
+ del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a quell'indirizzo; questo
+ flag viene utilizzato dalla librerie di gestione dei \textit{thread}.
+\item[\const{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
+ figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
+ utilizzato dalla librerie di gestione dei \textit{thread}.
+\item[\const{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
+ padre la \itindex{file~descriptor~table} \textit{file descriptor table}
+ (vedi sez.~\ref{sec:file_fd}), questo significa che ogni \textit{file
+ descriptor} aperto da un processo verrà visto anche dall'altro e che ogni
+ chiusura o cambiamento dei \textit{file descriptor flag} di un \textit{file
+ descriptor} verrà per entrambi.
+
+ Se non viene impostato il processo figlio eredita una copia della
+ \itindex{file~descriptor~table} \textit{file descriptor table} del padre e
+ vale la semantica classica della gestione dei \textit{file descriptor}, che
+ costituisce il comportamento ordinario di un sistema unix-like e che
+ illustreremo in dettaglio in sez.~\ref{sec:file_shared_access}.
+
+\item[\const{CLONE\_FS}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre le informazioni
+
\item[\const{CLONE\_IO}]
\item[\const{CLONE\_NEWIPC}]
\item[\const{CLONE\_NEWNET}]
\end{basedescript}
-%TODO trattare unshare
+%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
+%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
+% https://lwn.net/Articles/478111/
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
Da fare
% TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
+% TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
+% http://lwn.net/Articles/529060/)
+% TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
+% kernel 3.11
+
\subsection{La gestione delle operazioni in virgola mobile}
% le pagine di manuale relative
% vedere anche dove metterle...
+% \subsection{La gestione dei moduli}
+% \label{sec:kernel_modules}
+
+% da fare
+
+%TODO trattare init_module e finit_module (quest'ultima introdotta con il
+%kernel 3.8)
+
+
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
% LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
% LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
% LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
-% LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker
+% LocalWords: list environ NULL umask utime cutime ustime fcntl linker
% LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access
% LocalWords: control MAC SELinux security modules LSM superuser uid gid saved
% LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
projects / gapil.git / blobdiff