X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=a43b44bfb2045c658543fd6f0742220b20dfd277;hp=fa6e1d50969b63087422d86a5b12a7a3865e21e7;hb=435c9a12b63a7893ae5bb05d29a4a4b95b5ff86f;hpb=3cf93b3dfc49fbf8b16f908bee85fa2ecaea4e3f diff --git a/prochand.tex b/prochand.tex index fa6e1d5..a43b44b 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-2014 %% 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}.} @@ -157,19 +155,15 @@ in fig.~\ref{fig:proc_task_struct}. 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 @@ -335,9 +329,8 @@ valore nullo, che non è il \ids{PID} di nessun processo. 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 @@ -390,26 +383,23 @@ distribuito insieme agli altri sorgenti degli esempi su \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 @@ -423,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 @@ -493,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 @@ -520,31 +509,34 @@ 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 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 @@ -555,17 +547,17 @@ avviene per le variabili in memoria, la posizione corrente sul file è 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 @@ -607,10 +599,10 @@ 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}); + 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} @@ -619,8 +611,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}); @@ -786,10 +779,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 @@ -801,10 +792,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 @@ -835,11 +826,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 @@ -847,7 +835,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 @@ -855,18 +844,18 @@ sono terminati (la scritta \texttt{defunct}). 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 @@ -882,9 +871,16 @@ provvede a completarne la terminazione. 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} @@ -1128,9 +1124,10 @@ tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare 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{} ma questo file non deve mai essere usato - direttamente, esso viene incluso attraverso \file{}.} +\textit{core dump} (vedi sez.~\ref{sec:sig_standard}), ecc.\footnote{le + definizioni esatte si possono trovare in \file{} ma + questo file non deve mai essere usato direttamente, esso viene incluso + attraverso \file{}.} \begin{table}[!htb] \centering @@ -1258,7 +1255,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 @@ -1319,8 +1316,8 @@ campi: \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 @@ -1379,7 +1376,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}{ @@ -1504,7 +1501,7 @@ convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato 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} @@ -1540,7 +1537,7 @@ seguente: \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}); @@ -1560,7 +1557,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 @@ -1578,7 +1576,8 @@ seguenti proprietà non vengano preservate: \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}); @@ -1622,7 +1621,7 @@ nell'esecuzione della funzione \func{exec}, queste sono: 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}) per ciascun +\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 @@ -1650,13 +1649,13 @@ file appartiene. 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 @@ -1666,15 +1665,17 @@ 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 - \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 @@ -2154,7 +2155,7 @@ Le ultime funzioni che esamineremo sono quelle che permettono di operare sui 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. @@ -2574,7 +2575,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} @@ -2777,9 +2778,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 @@ -2787,6 +2788,10 @@ corrente. \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 @@ -2823,7 +2828,7 @@ rispettivamente 1 e 99. \begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.5\textwidth} \includestruct{listati/sched_param.c} \end{minipage} \normalsize @@ -2837,7 +2842,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: @@ -3466,15 +3471,15 @@ della priorità da impostare con l'argomento \param{ioprio} di \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 @@ -3566,6 +3571,7 @@ questo caso non ci sono effetti sugli altri processi questo limite è stato 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} @@ -3774,6 +3780,14 @@ 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 +% 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 @@ -3887,6 +3901,30 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. 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/ + + +% 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} @@ -3962,13 +4000,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 @@ -4028,7 +4066,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 @@ -4041,9 +4079,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}] @@ -4065,8 +4122,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} @@ -4074,6 +4134,11 @@ 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/) +% TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il +% kernel 3.11 + \subsection{La gestione delle operazioni in virgola mobile} @@ -4112,6 +4177,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} @@ -4307,7 +4381,7 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale. % 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