(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});
\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
% 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
\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:
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
\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}]
%TODO trattare unshare
+%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
+% https://lwn.net/Articles/478111/
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}