X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=prochand.tex;h=c7186d530391897d2d8b052d2d90a09ec37d9fd6;hb=1eb95e2a35acc78407e7d988604719bb92da7253;hp=d82076ea45dfe0d0b7e71a0e708e28a163715f5b;hpb=82438d2b3eca2b4807e7faec6699432dd76d8577;p=gapil.git diff --git a/prochand.tex b/prochand.tex index d82076e..c7186d5 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1,6 +1,6 @@ %% 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", @@ -80,10 +80,8 @@ posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come \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 @@ -115,7 +113,7 @@ init-+-keventd |-5*[getty] |-snort `-wwwoffled -\end{Terminal} +\end{Console} %$ \caption{L'albero dei processi, così come riportato dal comando \cmd{pstree}.} @@ -400,11 +398,8 @@ Se eseguiamo il comando, che è preceduto dall'istruzione \code{export 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 @@ -418,7 +413,8 @@ Child 3 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 @@ -488,11 +484,9 @@ se buona parte dei concetti relativi ai file verranno trattati più avanti (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 @@ -515,7 +509,7 @@ Spawned 2 child, pid 1969 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 @@ -614,8 +608,9 @@ comune dopo l'esecuzione di una \func{fork} è la seguente: (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}); @@ -781,10 +776,8 @@ stato di terminazione. 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 @@ -796,10 +789,10 @@ Child 3 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 @@ -830,11 +823,8 @@ condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi 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 @@ -842,7 +832,8 @@ terminale (prima dello scadere dei 10 secondi) otterremo: 570 pts/0 Z 0:00 [forktest ] 571 pts/0 Z 0:00 [forktest ] 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 @@ -1254,7 +1245,7 @@ primo, quale processo o quale gruppo di processi selezionare. \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 @@ -1375,7 +1366,7 @@ Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata famiglia di funzioni) che possono essere usate per questo compito, in realtà (come mostrato in fig.~\ref{fig:proc_exec_relat}), 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}{ @@ -1556,7 +1547,8 @@ seguente: % 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 @@ -1663,14 +1655,16 @@ nella forma: \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 +\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}.\footnote{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 è @@ -2571,7 +2565,7 @@ l'utente correnti. \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} @@ -2774,9 +2768,9 @@ corrente. \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 @@ -2834,7 +2828,7 @@ errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la priorità dinamica determinata dal valore di \textit{nice}, che deve essere impostato con le funzioni viste in precedenza. -Lo standard POSIX.1b prevede comunque che 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: @@ -3771,6 +3765,11 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. 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 @@ -3894,6 +3893,10 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. \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} @@ -3969,13 +3972,13 @@ Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la memoria, la \textit{system call}, a differenza della funzione di libreria che vedremo a breve, consente anche di passare per \param{child\_stack} il valore \val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un -processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è - sottinteso cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo - a breve.} ed in questo caso si applica la semantica del -\itindex{copy~on~write} \textit{copy on write} illustrata in -sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno -automaticamente copiate come le altre e il nuovo processo avrà un suo -\textit{stack} totalmente indipendente da quello del padre. +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 @@ -4035,7 +4038,7 @@ utilizzati soltanto se si sono specificati rispettivamente i flag 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 @@ -4048,9 +4051,28 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa \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}] @@ -4072,8 +4094,11 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa \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} @@ -4081,6 +4106,9 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa 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} @@ -4119,6 +4147,15 @@ Da fare % 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}