%% prochand.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2013 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",
Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni \textit{system call} ed ad ogni interrupt e in una serie di
-altre occasioni, ma può essere anche attivato esplicitamente. Il timer di
-sistema provvede comunque a che esso sia invocato periodicamente; generando un
-interrupt periodico secondo la frequenza specificata dalla costante
-\const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
- tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
- portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
- compilazione del kernel, con un default di 250 e valori possibili di 100,
- 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
- refresh della televisione); occorre fare attenzione a non confondere questo
- valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
- sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.
+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.
+
A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
completamente diverso, detto \textit{tickless}, in cui non c'è più una
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 argomento su cui torneremo
-in sez.~\ref{sec:sys_resource_limit}, (vedi in particolare
-tab.~\ref{tab:sys_rlimit_values}).
+sul numero totale di processi permessi all'utente, argomento che tratteremo in
+dettaglio in sez.~\ref{sec:sys_resource_limit}.
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
(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 \index{maschera~dei~segnali} 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});
lo \itindex{exit~status} stato di uscita del processo, e gli altri per
indicare il segnale che ha causato la terminazione (in caso di conclusione
anomala), uno per indicare se è stato generato un \itindex{core~dump}
-\textit{core dump}, ecc.\footnote{le definizioni esatte si possono trovare in
- \file{<bits/waitstatus.h>} ma questo file non deve mai essere usato
- direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
+\textit{core dump} (vedi sez.~\ref{sec:sig_standard}), ecc.\footnote{le
+ definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
+ questo file non deve mai essere usato direttamente, esso viene incluso
+ attraverso \file{<sys/wait.h>}.}
\begin{table}[!htb]
\centering
\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
\const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
\const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
significato è, nell'ordine: uscita normale, terminazione da segnale,
- processo fermato, processo riavviato, processo terminato in \textit{core
- dump}.
+ processo fermato, processo riavviato, processo terminato in
+ \itindex{core~dump} \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
\end{basedescript}
Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
% TODO ===========Importante=============
% TODO questo sotto è incerto, verificare
% TODO ===========Importante=============
-\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
+\item la \index{maschera~dei~segnali} maschera dei segnali (si veda
+ sez.~\ref{sec:sig_sigmask}).
\end{itemize*}
Una serie di proprietà del processo originale, che non avrebbe senso mantenere
\item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
\item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
-\item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
+\item i \itindex{memory~locking} \textit{memory lock} (vedi
+ sez.~\ref{sec:proc_mem_lock});
\item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
\item i semafori e le code di messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
gruppi supplementari cui un utente può appartenere. Ogni processo può avere
almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
gruppi secondari può essere ottenuto con \func{sysconf} (vedi
- sez.~\ref{sec:sys_sysconf}), leggendo il parametro
+ sez.~\ref{sec:sys_limits}), leggendo il parametro
\texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
ereditati dal processo padre e possono essere cambiati con queste funzioni.
\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}
\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
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:
\hline
\hline
\macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della classe.\\
\macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della priorità.\\
\macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
- & dato un valore di priorità ed una classe
+ & Dato un valore di priorità ed una classe
ottiene il valore numerico da passare a
\func{ioprio\_set}.\\
\hline
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
+
+
\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
memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
partire dal kernel 2.6.32.
+% TODO: verificare questa parte
+\item[\const{PR\_SET\_CHILD\_SUBREAPER}] Imposta il processo indicato con il
+ \ids{PID} specificato da \param{arg2} come nuovo ``\textsl{genitore
+ adottivo}'' per tutti i processi discendenti del chiamante che
+ diventeranno orfani, sostituendo in questo ruolo \cmd{init} (si ricordi
+ quanto illustrato in sez.~\ref{sec:proc_termination}). Introdotta a partire
+ dal kernel 3.4.
+\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/
+
\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/)
+
\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