From: Simone Piccardi Date: Thu, 24 May 2001 17:20:03 +0000 (+0000) Subject: Correzioni minime per tutti i file. X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=b65121906b3a8fff20f19fa84d3a42c0877477ac;p=gapil.git Correzioni minime per tutti i file. Completata prima parte dei capitolo sui processi (interfaccia di base). --- diff --git a/elemtcp.tex b/elemtcp.tex index efc956f..6707447 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -1194,7 +1194,7 @@ certo socket; la prima restituisce l'indirizzo locale, la seconda quello remoto. \begin{prototype}{sys/socket.h} -{int getsockname(int sockfd, struct sockaddr * name, socklen_t * namelen)} +{int getsockname(int sockfd, struct sockaddr * name, socklen\_t * namelen)} La funzione restituisce 0 in caso di successo e -1 in caso di errore. I codici di errore restituiti in \texttt{errno} sono i seguenti: @@ -1223,7 +1223,7 @@ quella connessione. \begin{prototype}{sys/socket.h} -{int getpeername(int sockfd, struct sockaddr * name, socklen_t * namelen)} +{int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)} La funzione restituisce 0 in caso di successo e -1 in caso di errore. I codici di errore restituiti in \texttt{errno} sono i seguenti: diff --git a/filestd.tex b/filestd.tex index 58126b4..b854154 100644 --- a/filestd.tex +++ b/filestd.tex @@ -66,6 +66,8 @@ nell'header \texttt{stdio.h} e sono: \subsection{Input/output formattato} \label{sec:filestd_formatted_io} +\subsection{Chiusura di uno stream} +\label{sec:filestd_close} \section{Funzioni avanzate} \label{sec:filestd_adv_func} diff --git a/main.tex b/main.tex index 19e3539..7d33ac8 100644 --- a/main.tex +++ b/main.tex @@ -1,6 +1,6 @@ %% %% GaPiL : Guida alla Programmazione in Linux -%% +%% %% S. Piccardi Feb. 2001 %% %% main.tex: file principale, gli altri vanno inclusi da questo. diff --git a/pref.tex b/pref.tex index 98ef59f..8024653 100644 --- a/pref.tex +++ b/pref.tex @@ -1,10 +1,11 @@ \chapter{Prefazione} Nelle motivazioni in cui si introduce la GNU Free Documentation License (FDL) -(reperibili su http://www.gnu.org/philosophy/free-doc.html) si dà -una grande rilevanza all'importanza di disporre di buoni manuali, in quanto un -buon software senza un buon manuale liberamente disponibile pure la -fruibilità del software libero viene diminuita. +(reperibili su http://www.gnu.org/philosophy/free-doc.html) si dà una grande +rilevanza all'importanza di disporre di buoni manuali, in quanto la fruibilità +e la possilità di usare appieno il software libero, vengono notevolemte +ridotte senza la presenza di un valido manuale altrettanto liberamente +disponibile. E come per il software libero è anche in questo caso è di fondamentale importanza la libertà di accedere ai sorgenti (e non solo al risultato @@ -15,29 +16,42 @@ Per questo la Free Software Foundation ha approntato una licenza apposita per la documentazione, che tiene conto delle differenze che restano fra un testo e un programma. -Esiste però un altro campo, diverso dalla documentazione e dai manuali, in -cui avere a disposizione testi liberi, aperti e modificabili è essenziale ed -estremamente utile, quello della didattica e dell'educazione. E benché questo +Esiste però un altro campo, diverso dalla documentazione e dai manuali, in cui +avere a disposizione testi liberi, aperti e modificabili è essenziale ed +estremamente utile, quello della didattica e dell'educazione. E benché questo sia citato dalla FDL non è altrettanto comune trovarlo messo in pratica. In particolare sarebbe di grande interesse poter disporre di testi didattici in grado di crescere, essere adattati alle diverse esigenze, modificati e -ampliati nello stesso modo in cui si fa per il software libero. +ampliati, o anche ridotti per usi specifici, nello stesso modo in cui si fa +per il software libero. Questo progetto mira alla stesura di un libro il più completo e chiaro -possible sulla programmazione in GNU/Linux (da qui in avanti Linux per -brevità). Ovviamente essendo i concetti in gran parte gli stessi, esso -dovrebbe restare valido anche per la programmazione in ambito Unix generico, -l'idea è comunque quella di approfondire anche la caratteristiche peculiari di -GNU/Linux. +possibile sulla programmazione in GNU/Linux (che da qui in avanti spesso +chiameremo semplicemante linux per brevità). Ovviamente essendo i concetti in +gran parte gli stessi, esso dovrebbe restare valido anche per la +programmazione in ambito Unix generico, pur restando l'intenzione di +approfondire in maniera specifica le caratteristiche peculiari di GNU/Linux. L'idea è quella di riuscire a ottenere alla fine un testo utilizzabile per -apprendere la programmazione di rete sotto GNU/Linux della stessa qualità (è -un progetto molto ambizioso ...) dei testi del compianto R. W. Stevens. +apprendere la programmazione sotto GNU/Linux della stessa qualità (è un +progetto molto ambizioso ...) dei testi del compianto R. W. Stevens. + +Infatti benché le man pages e il manuale delle librerie del C della GNU siano +una fonte enorme di informazioni (da cui si è costantemente attinto nella +stesura di tutto il testo) la loro struttura li rende totalmente inadatti ad +una trattazione che vada oltre la descrizione delle caratteristiche +particolari dell'argomento in esame (in particolare il manuale delle glibc non +brilla certo per chiarezza espositiva). + +Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di +R. Stevens (in particolare Advanced Programming in the Unix Environment e Unix +Network Programming) per rendere in una sequenza logica il più esplicativa +possibile la trattazione dei vari argomenti. Il progetto prevede il rilascio del testo sotto licenza FDL, ed una modalità -di realizzazione aperta che permetta di accogliere i contributi di chiunque sia -interessato. +di realizzazione aperta che permetta di accogliere i contributi di chiunque +sia interessato. Dato che lo scopo del progetto è la produzione di un libro si è scelto di usare latex come "ambiente di sviluppo" del medesimo, sia per l'impareggiabile @@ -51,4 +65,3 @@ Il testo sar - diff --git a/process.tex b/process.tex index 2bde867..84cd0fe 100644 --- a/process.tex +++ b/process.tex @@ -11,8 +11,9 @@ esecuzione. In genere un programma viene eseguito quando un processo lo fa partire eseguendo una funzione della famiglia \texttt{exec}; torneremo su questo e sulla la creazione e gestione dei processi nel prossimo capitolo, in questo -affronteremo l'avvio e il funzionamento di un programma dal punto di vista del -programma posto in esecuzione. +affronteremo l'avvio e il funzionamento di un singolo processo partendo dal +punto di vista del programma posto in esecuzione. + \section{Esecuzione e conclusione di un programma} @@ -31,51 +32,388 @@ posto in esecuzione esso apparir discorso dei \textit{thread} comunque in linux necessita di una trattazione a parte per la peculiarità dell'implementazione). - \section{La funzione \texttt{main}} \label{sec:proc_main} -Quando un programma viene lanciato dal kernel viene eseguito il -programma \texttt{ld-linux.so}, è questo programma che prima carica le -librerie condivise che servono al programma, effettua il link dinamico del -codice e poi alla fine lo esegue. La procedura è controllata da alcune -variabili di ambiente e dai settaggi di +Quando un programma viene lanciato il kernel esegue una opportuna routine di +avvio, usando il programma \texttt{ld-linux.so}, è questo programma che prima +carica le librerie condivise che servono al programma, effettua il link +dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver +specificato il flag \texttt{-static} durante la compilazione, tutti i +programmi in linux sono incompleti e necessitano di essere linkati alle +librerie condivise quando vengono avviati. La procedura è controllata da +alcune variabili di ambiente e dal contenuto di \texttt{/etc/ld.so.conf}, i +dettagli sono riportati nella man page di \texttt{ld.so}. Il sistema fa partire qualunque programma chiamando la funzione \texttt{main}; -sta al programmatore chiamare così la funzione principale del programma, se -così non fosse lo stesso linker darebbe luogo ad errori. +sta al programmatore chiamare così la funzione principale del programma da cui +si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso +linker darebbe luogo ad errori. -Lo stadard ISO C specifica che detta funzione può non avere argomenti o -prendere due argomenti che rappresentano gli argomenti passati da linea di -comando, in sostanza un prototipo che va sempre bene è il seguente: +Lo stadard ISO C specifica che la funzione \texttt{main} può o non avere +argomenti o prendere due argomenti che rappresentano gli argomenti passati da +linea di comando, in sostanza un prototipo che va sempre bene è il seguente: \begin{verbatim} int main (int argc, char *argv[]) \end{verbatim} - In realtà nei sistemi unix esiste un'altro modo per definire la funzione -\texttt{main}, che prende un terzo parametro, \texttt{char *envp[]}, che -fornisce l'ambiente (vedi \secref{proc_environ}) del programma; questa forma -però non è prevista dallo standard POSIX.1 per cui se si vogliono scrivere -programmi portabili è meglio evitarla. +\texttt{main}, che prevede la presenza di un terzo parametro, \texttt{char + *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{proc_environ}) del +programma; questa forma però non è prevista dallo standard POSIX.1 per cui se +si vogliono scrivere programmi portabili è meglio evitarla. + + +\subsection{Come chiudere un programma} +\label{sec:proc_termination} + +La via normale per la quale un programma finisce è quando la funzione main +ritorna, una modalità equivalente di conclusione è quella di chiamare +direttamente la funzione \texttt{exit} (che viene comunque chiamata dalla +routine di avvio del programma quando la funzione main ritorna). Una forma +alternativa è quella di chiamare direttamente la system call \texttt{\_exit} +che passa il controllo direttamente al kernel. + +Oltre alla conclusione ``normale'' esiste anche la possibilità di una +conclusione ``anomala'' del programma a causa di segnali o della chiamata alla +funzione \texttt{abort} (che comunque genera un segnale che termina il +programma); torneremo su questo in \secref{sec:sig_abort}. + +Il valore di ritorno della funzione main, o quello usato nelle chiamate ad +\texttt{exit} e \texttt{\_exit}, viene chiamato \textit{exit status} e passato +al processo padre che aveva lanciato il programma (in genere la shell). In +generale si usa questo valore per fornire un'informazione generica sulla +riuscita o il fallimento del programma; l'informazione è necessariamente +generica, ed il valore deve essere compreso fra 0 e 255. + +In generale si usa la convenzione di restituire 0 in caso di successo e 1 in +caso di fallimento, i programmi che effettuano dei confronti (come +\texttt{diff}) usano invece una notazione leggermente diversa, usando 0 per +indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per +indicare l'incapacità di effettuare il confronto. È opportuno adottare una di +queste convenzioni a seconda dei casi. Si tenga presente che se si raggiunge +la fine della funzione \texttt{main} senza ritornare esplicitamente si ha un +valore di uscita indefinito, è pertanto consigliabile di concludere sempre in +maniera esplicita detta funzione. + +Una altra convenzione riserva i valori da 128 in sù per usi speciali, ad +esempio 128 viene usato per indicare l'incapacità di eseguire un altro +programma in un sottoprocesso. Benché anche questa convenzione non sia +universalmente seguita è una buona idea tenerne conto. + +Si tenga presente inoltre che non è una buona idea usare il valore dell'errore +restituito dalla variabile \texttt{errno} come stato di uscita, in generale +una shell non si cura di tutto questo e comunque il valore dello stato di +uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in +cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In +\texttt{stdlib.h} sono definite due macro \texttt{EXIT\_SUCCESS} e +\texttt{EXIT\_FAILURE}, che in linux sono poste rispettivamente ai valori 0 e +1 (di tipo \texttt{int}), seguendo lo standard POSIX. + +Infine occorre distinguere fra lo stato di uscita di un programma +(l'\textit{exit status}) e lo stato di conclusione di un processo (il +\textit{termination status}), abbiamo già accennato infatti che è comunque +possibile un processo possa essere terminato (da un segnale) prima che il +programma in esecuzione si sia concluso. In caso di conclusione normale del +programma però lo stato di uscita diventa parte dello stato di conclusione del +processo (vedi \secref{sec:prochand_XXX}). + + +\subsection{Le funzioni \texttt{exit} e \texttt{\_exit}} +\label{sec:proc_exit} +Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la +prima è la funzione \texttt{exit} che è definita dallo standard ANSI C, il +prototipo della funzione è il seguente: +\begin{prototype}{stdlib.h}{void exit(int status)} + Causa la conclusione ordinaria del programma restituendo il valore + \texttt{status} al processo padre. + + La funzione non ritorna. Il processo viene terminato +\end{prototype} + +La funzione \texttt{exit} è pensata per una conclusione pulita di un programma +che usa le librerie standard del C; essa esegue tutte le funzioni che sono +state registrate con \texttt{atexit} e \texttt{on\_exit} (vedi +\secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il +salvataggio dei dati sospesi (chiamando \texttt{fclose}, vedi +\secref{sec:filestd_close}), infine ripassa il controllo al kernel chiamando +\texttt{\_exit} e passando il valore \texttt{status} come stato di uscita. + +La system call \texttt{\_exit} restituisce direttamente il controllo al +kernel, concludendo immediatamente il processo, le eventuali funzioni +registrate con \texttt{atexit} e \texttt{on\_exit} non vengono eseguite. Il +prototipo della funzione è il seguente: +\begin{prototype}{unistd.h}{void \_exit(int status)} + Causa la conclusione immediata del programma restituendo il valore + \texttt{status} al processo padre. + + La funzione non ritorna. Il processo viene terminato. +\end{prototype} + +La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga +presente che questo non comporta il salvataggio dei dati bufferizzati degli +stream), fa si che ogni figlio del processo sia ereditato da \texttt{init} +(vedi \secref{cha:process_handling}), manda un segnale \texttt{SIGCHLD} al +processo padre (vedi \ref{sec:sig_sigchild}) ed infine ritorna lo stato di +uscita specificato in \texttt{status} che può essere raccolto usando la +funzione \texttt{wait} (vedi \secref{sec:prochand_wait}). + + +\subsection{Le funzioni \texttt{atexit} e \texttt{on\_exit}} +\label{sec:proc_atexit} + +Come accennato l'uso di \texttt{exit} al posto della \texttt{\_exit} è fatto +principalmente per permettere una uscita pulita dalle funzioni delle librerie +standard del C (in particolare per quel che riguarda la chiusura degli +stream). + +Quando si realizza una libreria da usare in varie applicazioni può essere +perciò utile evitare di richiedere di chiamare esplicitamente un funzione di +uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella +di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e +completamente trasparente all'utente poter effettuare una chiamata automatica +di una funzione che effettui tali operazioni all'uscita dal programma. + +A questo scopo lo standard ANSI C prevede la possibilità di registrare un +certo numero funzioni che verranno eseguite all'uscita dal programma (sia per +la chiamata ad \textit{exit} che per il ritorno di \texttt{main}). La prima +funzione che si può utilizzare a tal fine è: +\begin{prototype}{stdlib.h}{void atexit(void (*function)(void))} + Registra la funzione \texttt{function} per essere chiamata all'uscita dal + programma. + + La funzione restituisce 0 in caso di successo e -1 in caso di fallimento, + \texttt{errno} non viene settata. +\end{prototype} + +La funzione richiede come argomento l'indirizzo della opportuna da chiamare +all'uscita che non deve prendere argomenti e non deve ritornare niente. Una +estensione di \texttt{atexit} è la funzione \texttt{on\_exit} (che la glibc +include per compatibilità con SunOS e che non è detta sia definita su altri +sistemi), il cui prototipo è: +\begin{prototype}{stdlib.h} +{void on\_exit(void (*function)(int status, void *arg), void *arg)} + Registra la funzione \texttt{function} per essere chiamata all'uscita dal + programma. Tutte le funzioni registrate vengono chiamate in ordine inverso + rispetto a quello di registrazione. + + La funzione restituisce 0 in caso di successo e -1 in caso di fallimento, + \texttt{errno} non viene settata. +\end{prototype} + +In questo caso la funzione da chiamare prende due parametri, il primo dei +quali sarà inizializzato allo stato di uscita con cui è stata chiamata +\texttt{exit} ed il secondo al puntatore generico specificato come secondo +argomento nella chiamata di \texttt{on\_exit}. + +Tutte le funzioni registrate vengono chiamate in ordine inverso rispetto a +quello di registrazione (ed una stessa funzione registrata più volte sarà +chiamata più volte); poi vengono chiusi tutti gli stream aperti, infine viene +chiamata \texttt{\_exit}. + + +\subsection{Conclusioni} +\label{sec:proc_term_conclusion} + +Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che +in un sistema unix l'unico modo in cui un programma può essere eseguito dal +kernel è attraverso la chiamata alla system call \texttt{execve} (in genere +attraveso una delle funzioni \texttt{exec} che vedremo in +\secref{sec:prochand_exec}). + +Allo stesso modo l'unico modo in cui un programma può concludere +volontariamente la sua esecuzione è attraverso una chiamata alla system call +\texttt{\_exec} sia esplicitamnte o che in maniera indiretta attraverso l'uso +di \texttt{exit} o il ritorno della funzione \texttt{main}. + +Lo schema delle modalità con cui si avvia e conclude normalmente un programma +è riportato in \nfig. + +\begin{figure}[htb] + \centering + + \caption{Schema dell'avvio e della conclusione di un programma.} + \label{fig:proc_prog_start_stop} +\end{figure} +Si ricordi infine che un programma può anche essere interrotto dall'esterno +attraverso l'uso di un segnale (modalità di conclusione non mostrata in +\curfig); torneremo su questo aspetto in \secref{cha:signals}. + + + +\section{I processi e l'uso della memoria} +\label{sec:proc_memory} + +Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed +uno degli aspetti più complessi di un sistema unix (ed in particolar modo di +linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la +memoria viene vista dal punto di vista di un programma in esecuzione in un +processo. + + +\subsection{I concetti generali} +\label{sec:proc_mem_gen} + +Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli +di basso livello dipendono in maniera diretta dall'architettura +dell'hardware), ma quello più tipico, usato da unix (e da linux) è quello di +assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in +cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di +linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il +kernel 2.4 il limite è stato esteso). + +Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non +corrisponde all'effettiva posizione dei dati nella ram del computer; in genere +detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono +utilizzabili e/o utilizzati). + +La memoria virtuale viene divisa in pagine (che ad esempio sono di 4kb su +macchine a 32 bit e 8kb sulle alpha, valori strettamente connessi all'hardware +di gestione della memoria) di dimensione fissa, e ciascuna pagina della +memoria virtuale è associata ad un supporto che può essere una pagina di +memoria reale o ad un dipositivo di stoccaggio secondario (in genere lo spazio +disco riservato alla swap, o i file che contengono il codice). + +Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a +diverse pagine di memoria virtuale appartenenti a processi diversi (come +accade in genere per le pagine che contengono il codice delle librerie +condivise). Ad esempio il codice della fuzione \texttt{printf} starà su una +sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria +virtuale di tutti i processi hanno detta funzione nel loro codice. + +La corrispondenza fra le pagine della memoria virtuale e quelle della memoria +fisica della macchina viene gestita in maniera trasparente dall'hardware di +gestione della memoria (dalla \textit{Memory Management Unit} del processore), +ma poiché in genere quest'ultima è solo una piccola frazione della memoria +virtuale è necessario un meccanismo che permetta di trasferire le pagine +virtuali che servono dal supporto su cui si trovano in memoria eliminando +quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno +dei compiti principali del kernel. + +Quando un processo cerca di accedere ad una pagina che non è nella memoria +reale avviene quello che viene chiamato un \textit{page fault}, l'hardware di +gestione della memoria (la MMU del processore) genera una interruzione e passa +il controllo al kernel il quale sospende il processo e si incarica di mettere +in ram la pagina richiesta (effettuando tutte le operazioni necessarie per +reperire lo spazio necessario), per poi restituire il controllo al +processo. + +Dal punto di vista di un processo questo meccanismo è completamente +trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili +in memoria. L'unica differenza avvertibile è quella dei tempi di esecuzione, +che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più +lunghi, dovuti all'intervento del kernel. Normalemente questo è il prezzo da +pagare per avere un multitasking reale, ed in genere il sistema è molto +efficiente in questo lavoro; quando però ci siano esigenze specifiche di +prestazioni è possibile usare delle funzioni che permettono di bloccare il +meccanismo del paging e mantenere fisse delle pagine in memoria (vedi +\ref{sec:proc_mem_lock}). + + +\subsection{La struttura della memoria di un processo} +\label{sec:proc_mem_layout} + +Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo +una parte di essi è effettivamente allocato ed utilizzabile dal processo; il +tentativo di accedere ad un indirizzo non allocato è un tipico errore che si +commette quando si è manipolato male un puntatore e genera quello che viene +chiamato un \textit{segmentation fault}, si tenta cioè di leggere e scrivere +da un indirizzo per il quale non esiste una associazione della pagina virtuale +ed il kernel riponde al relativo \textit{page fault} mandando un segnale +\texttt{SIGSEGV} al processo, che normalmente ne causa la terminazione +immediata. + +È pertanto importante capire come viene strutturata la memoria virtuale di un +processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di +indirizzi virtuali ai quali il processo può accedere. Storicamente un +programma C viene suddiviso nei seguenti segmenti: + +\begin{enumerate} +\item Il segmento di testo (\textit{text segment}). Contiene il codice + macchina del programma e le costanti statiche. Normalente viene condiviso + così che più processi (anche diversi nel caso di librerie) possano + utilizzarlo e marcato in sola lettura per evitare sovrascritture accidentali + (o maliziose) che ne modifichino le istruzioni. + + Viene allocato da \texttt{exec} all'avvio del programma e resta invariato + per tutto il tempo dell'esecuzione. + +\item Il segmento dei dati (\textit{data segment}). Contiene le varibili + globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è + diviso in due parti. + + La prima è il segmento dei dati inizializzati, che contiene le variabili + globali il cui valore è stato assegnato esplicitamente. Ad esempio se si + definisce: +\begin{verbatim} + double pi = 3.14; +\end{verbatim} + questo valore sarà immagazzinato in questo segmento. La memoria di questo + segmento viene preallocato dalla \texttt{exec} e inizializzata ai valori + specificati. + + La seconda è il segmento dei dati non inizializzati, che contiene le + variabili globali il cui valore è stato non è assegnato esplicitamente. Ad + esempio se si definisce: +\begin{verbatim} + int vect[100]; +\end{verbatim} + questo valore sarà immagazzinato in questo segmento. Anch'esso viene + allocato all'avvio, e tutte le varibili vengono inizializzate a + zero (ed i puntatori a \texttt{NULL}). + + Storicamente questo segmento viene chiamato BBS (da \textit{block started by + symbol}. La sua dimensione è fissa. + +\item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del + segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene + l'allocazione dinamica della memoria; può essere ridimensionato allocando e + disallocando la memoria dinamica con le apposite funzioni (vedi + \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente + al segmento dati) ha una posizione fissa. + +\item Il segmento di \textit{stack}, che contiene lo \textit{stack} del + programma. Tutte le volte che si effettua una chiamata ad una funzione è + qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato + del chiamante (tipo il contenuto di alcuni registri della CPU); poi la + funzione chiamata alloca qui lo spazio per le sue variabili locali, in + questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno + della funzione lo spazio è automaticamente rilasciato. + + La dimensione di questo segmento aumenta seguendo la crescita dello stack + del programma, ma non viene ridotta quando quest'ultimo si restringe. +\end{enumerate} + +\begin{figure}[htb] + \centering + + \caption{Disposizione tipica dei segmenti di memoria di un processo} + \label{fig:proc_mem_layout} +\end{figure} -\subsection{} -\label{sec:proc_} +Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il +comando \texttt{size} su un programma se ne può stampare le dimensioni dei +segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai +salvato sul file, in quanto viene inizializzato a zero al caricamento del +programma. + + +\subsection{La librerie condivise} +\label{sec:proc_mem_shlib} -\subsection{La funzione \texttt{exit}} -\label{sec:proc_exit} +\subsection{Allocazione e disallocazione della memoria} +\label{sec:proc_mem_alloc} -\section{La gestione della memoria} -\label{sec:proc_mem_manag} -\section{Gestione di parametri e opzioni} + +\section{La gestione di parametri e opzioni} \label{sec:parameter_options} Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando @@ -212,9 +550,3 @@ versione estesa di \texttt{getopt}. \subsection{Le variabili di ambiente} \label{sec:proc_env_var} -Questo va fatto. - - - -\section{La gestione della memoria} -\label{sec:proc_memory_manag} \ No newline at end of file diff --git a/prochand.tex b/prochand.tex index 390b072..40a880d 100644 --- a/prochand.tex +++ b/prochand.tex @@ -12,7 +12,7 @@ funzioni a questo connesse. \section{Una panoramica sui concetti base} -\label{sec:proc_gen} +\label{sec:prochand_gen} Una delle caratteristiche essenziali di unix (che esamineremo in dettaglio più avanti) è che ogni processo può a sua volta generare altri processi figli @@ -31,7 +31,7 @@ questo caso c' \section{Gli identificatori dei processi} -\label{sec:proc_id} +\label{sec:prochand_id} Ogni processo viene identificato dal sistema da un numero identificativo unico, il \textit{process id} o \textit{pid}. Questo viene assegnato in forma @@ -62,7 +62,7 @@ gli header files \texttt{unistd.h} e \texttt{sys/types.h}). \section{Il controllo dei processi} -\label{sec:proc_control} +\label{sec:prochand_control} Esamineremo in questa sezione le varie funzioni per il controllo dei processi: la lore creazione, la terminazione, l'esecuzione di altri programmi. Prima di @@ -70,7 +70,7 @@ trattare in dettaglio le singole funzioni, faremo un'introduzione generale ai contetti che stanno alla base della gestione dei processi in unix. \subsection{Una panoramica} -\label{sec:proc_control_overview} +\label{sec:prochand_control_overview} I processi vengono creati dalla funzione \texttt{fork}; in genere questa è una system call, ma linux però usa un'altra nomenclatura, e la funzione fork è @@ -113,7 +113,7 @@ non ritorna mai (in quanto con essa viene eseguito un altro programma). \subsection{La funzione \texttt{fork}} -\label{sec:proc_fork} +\label{sec:prochand_fork} Dopo l'esecuzione di una fork sia il processo padre che il processo figlio @@ -127,29 +127,22 @@ viene eseguito dal padre o dal figlio. \subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} -\label{sec:proc_wait} +\label{sec:prochand_wait} \subsection{Le funzioni \texttt{exec}} -\label{sec:proc_exec} - - - - +\label{sec:prochand_exec} \section{Il controllo di accesso} -\label{sec:process_perms} +\label{sec:prochand_perms} Va messo qui tutta la storia su effective, real, saved uid, e pure le cose di linux come il filesystem uid. - \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} -\label{sec:proc_setuid} +\label{sec:prochand_setuid} \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} -\label{sec:proc_setuid} - - +\label{sec:prochand_setuid}