From: Simone Piccardi Date: Sat, 10 Jul 2004 21:55:13 +0000 (+0000) Subject: Risistemati i font di tutte le figure, piu qualche aggiunta al resolver X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=ac964c5d51a316d519c5a6319b46e962c947d025;p=gapil.git Risistemati i font di tutte le figure, piu qualche aggiunta al resolver --- diff --git a/img/IP_AH_packet.dia b/img/IP_AH_packet.dia index 65c6fbd..f95f16d 100644 Binary files a/img/IP_AH_packet.dia and b/img/IP_AH_packet.dia differ diff --git a/img/dir_links.dia b/img/dir_links.dia index 7eaf5a3..82ac44f 100644 Binary files a/img/dir_links.dia and b/img/dir_links.dia differ diff --git a/img/dir_struct.dia b/img/dir_struct.dia index 0c5b0ff..0c8dd86 100644 Binary files a/img/dir_struct.dia and b/img/dir_struct.dia differ diff --git a/img/disk_struct.dia b/img/disk_struct.dia index c86d957..0c248c1 100644 Binary files a/img/disk_struct.dia and b/img/disk_struct.dia differ diff --git a/img/environ_var.dia b/img/environ_var.dia index bd352e8..318629b 100644 Binary files a/img/environ_var.dia and b/img/environ_var.dia differ diff --git a/img/esp_option.dia b/img/esp_option.dia index 5ffbf47..39a560b 100644 Binary files a/img/esp_option.dia and b/img/esp_option.dia differ diff --git a/img/exec_rel.dia b/img/exec_rel.dia index 7daeb1d..f06e934 100644 Binary files a/img/exec_rel.dia and b/img/exec_rel.dia differ diff --git a/img/fifoserver.dia b/img/fifoserver.dia index 4ce7c8b..93b3496 100644 Binary files a/img/fifoserver.dia and b/img/fifoserver.dia differ diff --git a/img/file_flock.dia b/img/file_flock.dia index 7c30fd8..5a10b25 100644 Binary files a/img/file_flock.dia and b/img/file_flock.dia differ diff --git a/img/file_lock_dead.dia b/img/file_lock_dead.dia index a414a5d..c7d2699 100644 Binary files a/img/file_lock_dead.dia and b/img/file_lock_dead.dia differ diff --git a/img/file_posix_lock.dia b/img/file_posix_lock.dia index bb7c248..89a610a 100644 Binary files a/img/file_posix_lock.dia and b/img/file_posix_lock.dia differ diff --git a/img/filedup.dia b/img/filedup.dia index 06e0e35..1477173 100644 Binary files a/img/filedup.dia and b/img/filedup.dia differ diff --git a/img/filemultacc.dia b/img/filemultacc.dia index 587c3c2..5393ff1 100644 Binary files a/img/filemultacc.dia and b/img/filemultacc.dia differ diff --git a/img/fileperm.dia b/img/fileperm.dia index 19474b5..47b6ee8 100644 Binary files a/img/fileperm.dia and b/img/fileperm.dia differ diff --git a/img/fileshar.dia b/img/fileshar.dia index 97eb289..077ceb0 100644 Binary files a/img/fileshar.dia and b/img/fileshar.dia differ diff --git a/img/filesys_struct.dia b/img/filesys_struct.dia index 49ac773..f956256 100644 Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ diff --git a/img/ipv6_head.dia b/img/ipv6_head.dia index 4fe96fb..34ce587 100644 Binary files a/img/ipv6_head.dia and b/img/ipv6_head.dia differ diff --git a/img/iso_tcp_comp.dia b/img/iso_tcp_comp.dia index 501183d..b7a9b18 100644 Binary files a/img/iso_tcp_comp.dia and b/img/iso_tcp_comp.dia differ diff --git a/img/memory_layout.dia b/img/memory_layout.dia index a2b20df..87189ae 100644 Binary files a/img/memory_layout.dia and b/img/memory_layout.dia differ diff --git a/img/mmap_boundary.dia b/img/mmap_boundary.dia index edff5d4..29956d3 100644 Binary files a/img/mmap_boundary.dia and b/img/mmap_boundary.dia differ diff --git a/img/mmap_exceed.dia b/img/mmap_exceed.dia index 2a77fa3..8630e39 100644 Binary files a/img/mmap_exceed.dia and b/img/mmap_exceed.dia differ diff --git a/img/mmap_layout.dia b/img/mmap_layout.dia index 7978d5a..bfb34bf 100644 Binary files a/img/mmap_layout.dia and b/img/mmap_layout.dia differ diff --git a/img/mqstruct.dia b/img/mqstruct.dia index 07c5127..f3ebe0a 100644 Binary files a/img/mqstruct.dia and b/img/mqstruct.dia differ diff --git a/img/pipe.dia b/img/pipe.dia index 349b393..8be4c57 100644 Binary files a/img/pipe.dia and b/img/pipe.dia differ diff --git a/img/pipefork.dia b/img/pipefork.dia index d8e57da..e64a081 100644 Binary files a/img/pipefork.dia and b/img/pipefork.dia differ diff --git a/img/pipeuse.dia b/img/pipeuse.dia index 9f4d609..e3f62ae 100644 Binary files a/img/pipeuse.dia and b/img/pipeuse.dia differ diff --git a/img/port_alloc.dia b/img/port_alloc.dia index a116b97..90885d2 100644 Binary files a/img/port_alloc.dia and b/img/port_alloc.dia differ diff --git a/img/proc_beginend.dia b/img/proc_beginend.dia index 75a5da1..181bf26 100644 Binary files a/img/proc_beginend.dia and b/img/proc_beginend.dia differ diff --git a/img/proc_exit.dia b/img/proc_exit.dia index b2f2e82..86c75ca 100644 Binary files a/img/proc_exit.dia and b/img/proc_exit.dia differ diff --git a/img/procfile.dia b/img/procfile.dia index adff9e7..d4a21ca 100644 Binary files a/img/procfile.dia and b/img/procfile.dia differ diff --git a/img/semtruct.dia b/img/semtruct.dia index 0744183..80856c3 100644 Binary files a/img/semtruct.dia and b/img/semtruct.dia differ diff --git a/img/sh_memory_layout.dia b/img/sh_memory_layout.dia index 5d64ed2..9e7f500 100644 Binary files a/img/sh_memory_layout.dia and b/img/sh_memory_layout.dia differ diff --git a/img/struct_sys.dia b/img/struct_sys.dia index 96ef2d5..cc9c1a0 100644 Binary files a/img/struct_sys.dia and b/img/struct_sys.dia differ diff --git a/img/task_struct.dia b/img/task_struct.dia index 2095dec..5859390 100644 Binary files a/img/task_struct.dia and b/img/task_struct.dia differ diff --git a/img/tcp_client_early_abort.dia b/img/tcp_client_early_abort.dia index 6c0472b..72ca2f8 100644 Binary files a/img/tcp_client_early_abort.dia and b/img/tcp_client_early_abort.dia differ diff --git a/img/tcp_close.dia b/img/tcp_close.dia index 1be6432..94b132e 100644 Binary files a/img/tcp_close.dia and b/img/tcp_close.dia differ diff --git a/img/tcp_connection.dia b/img/tcp_connection.dia index 0605752..e827544 100644 Binary files a/img/tcp_connection.dia and b/img/tcp_connection.dia differ diff --git a/img/tcp_data_flux.dia b/img/tcp_data_flux.dia index f760045..f587f39 100644 Binary files a/img/tcp_data_flux.dia and b/img/tcp_data_flux.dia differ diff --git a/img/tcpip_overview.dia b/img/tcpip_overview.dia index 26b2254..d82bb4b 100644 Binary files a/img/tcpip_overview.dia and b/img/tcpip_overview.dia differ diff --git a/img/term_struct.dia b/img/term_struct.dia index e3d833a..0643f34 100644 Binary files a/img/term_struct.dia and b/img/term_struct.dia differ diff --git a/img/three_way_handshake.dia b/img/three_way_handshake.dia index 2b4cdad..03578c5 100644 Binary files a/img/three_way_handshake.dia and b/img/three_way_handshake.dia differ diff --git a/img/tty_login.dia b/img/tty_login.dia index e6d222f..096e50c 100644 Binary files a/img/tty_login.dia and b/img/tty_login.dia differ diff --git a/img/udp_connection.dia b/img/udp_connection.dia index d44c6c3..d19630a 100644 Binary files a/img/udp_connection.dia and b/img/udp_connection.dia differ diff --git a/img/vfs.dia b/img/vfs.dia index d296836..1052b79 100644 Binary files a/img/vfs.dia and b/img/vfs.dia differ diff --git a/process.tex b/process.tex index 39e0101..b21dc6b 100644 --- a/process.tex +++ b/process.tex @@ -63,7 +63,7 @@ linea di comando, in sostanza un prototipo che va sempre bene In realtà nei sistemi Unix esiste un'altro modo per definire la funzione \func{main}, che prevede la presenza di un terzo parametro, \code{char - *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ}) + *envp[]}, che fornisce l'\textsl{ambiente} (vedi sez.~\ref{sec:proc_environ}) del programma; questa forma però non è prevista dallo standard POSIX.1 per cui se si vogliono scrivere programmi portabili è meglio evitarla. @@ -81,7 +81,7 @@ controllo direttamente alla routine di conclusione dei processi del kernel. Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un segnale (si veda \capref{cha:signals}) o della chiamata alla funzione -\func{abort}; torneremo su questo in \secref{sec:proc_termination}. +\func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}. Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o @@ -107,7 +107,7 @@ universalmente seguita Si tenga presente inoltre che non è una buona idea usare il codice di errore restituito dalla variabile \var{errno} (per i dettagli si veda -\secref{sec:sys_errors}) come stato di uscita. In generale infatti una shell +sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell non si cura del valore se non per vedere se è diverso da zero; inoltre il valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe @@ -134,9 +134,9 @@ dallo standard ANSI C ed il cui prototipo La funzione \func{exit} è pensata per eseguire una conclusione pulita di un programma che usi le librerie standard del C; essa esegue tutte le funzioni che sono state registrate con \func{atexit} e \func{on\_exit} (vedi -\secref{sec:proc_atexit}), e chiude tutti gli stream effettuando il +sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il salvataggio dei dati sospesi (chiamando \func{fclose}, vedi -\secref{sec:file_fopen}), infine passa il controllo al kernel chiamando +sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando \func{\_exit} e restituendo il valore di \param{status} come stato di uscita. La system call \funcd{\_exit} restituisce direttamente il controllo al kernel, @@ -152,10 +152,10 @@ non vengono salvati e le eventuali funzioni registrate con \func{atexit} e La funzione chiude tutti i file descriptor appartenenti al processo (si tenga presente che questo non comporta il salvataggio dei dati bufferizzati degli stream), fa sì che ogni figlio del processo sia ereditato da \cmd{init} (vedi -\secref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo -padre (vedi \secref{sec:sig_job_control}) ed infine ritorna lo stato di uscita +sez.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo +padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di uscita specificato in \param{status} che può essere raccolto usando la funzione -\func{wait} (vedi \secref{sec:proc_wait}). +\func{wait} (vedi sez.~\ref{sec:proc_wait}). \subsection{Le funzioni \func{atexit} e \func{on\_exit}} @@ -220,7 +220,7 @@ Data l'importanza dell'argomento in un sistema Unix l'unico modo in cui un programma può essere eseguito dal kernel è attraverso la chiamata alla system call \func{execve} (o attraverso una delle funzioni della famiglia \func{exec} che vedremo in -\secref{sec:proc_exec}). +sez.~\ref{sec:proc_exec}). Allo stesso modo l'unico modo in cui un programma può concludere volontariamente la sua esecuzione è attraverso una chiamata alla system call @@ -228,18 +228,18 @@ volontariamente la sua esecuzione \func{exit} o il ritorno di \func{main}. Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude -normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}. +normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}. \begin{figure}[htb] \centering - \includegraphics[width=12cm]{img/proc_beginend} + \includegraphics[width=14cm]{img/proc_beginend} \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 -\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in +fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in \capref{cha:signals}. @@ -380,7 +380,7 @@ seguenti segmenti: 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 + sez.~\ref{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 @@ -400,13 +400,13 @@ seguenti segmenti: \begin{figure}[htb] \centering - \includegraphics[width=5cm]{img/memory_layout} + \includegraphics[height=12cm]{img/memory_layout} \caption{Disposizione tipica dei segmenti di memoria di un processo.} \label{fig:proc_mem_layout} \end{figure} Una disposizione tipica di questi segmenti è riportata in -\figref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se +fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se ne può stampare le dimensioni dei segmenti di testo e di dati (inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul file che contiene l'eseguibile, dato che viene sempre inizializzato a zero al @@ -545,7 +545,7 @@ tollerante nei confronti di piccoli errori come quello di chiamate doppie a \begin{itemize} \item se la variabile è posta a zero gli errori vengono ignorati. \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error} - (vedi \secref{sec:file_std_stream}). + (vedi sez.~\ref{sec:file_std_stream}). \item se è posta a 2 viene chiamata \func{abort}, che in genere causa l'immediata conclusione del programma. \end{itemize} @@ -634,7 +634,7 @@ Come evitare alla radice i problemi di memory leak\index{memory leak}, dato che non serve più la deallocazione esplicita; inoltre la deallocazione automatica funziona anche quando si usa \func{longjmp} per uscire da una subroutine con -un salto non locale da una funzione (vedi \secref{sec:proc_longjmp}). +un salto non locale da una funzione (vedi sez.~\ref{sec:proc_longjmp}). Un altro vantaggio è che in Linux la funzione è molto più veloce di \func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un @@ -661,7 +661,7 @@ che deve poi essere usata anche al di fuori della funzione in cui essa viene chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni. Questo è lo stesso problema che si può avere con le variabili automatiche, su -cui torneremo in \secref{sec:proc_auto_var}. +cui torneremo in sez.~\ref{sec:proc_auto_var}. \subsection{Le funzioni \func{brk} e \func{sbrk}} @@ -670,8 +670,8 @@ cui torneremo in \secref{sec:proc_auto_var}. Queste due funzioni vengono utilizzate soltanto quando è necessario effettuare direttamente la gestione della memoria associata allo spazio dati di un processo, ad esempio qualora si debba implementare la propria versione delle -routine di allocazione della memoria viste in \secref{sec:proc_mem_malloc}. La -prima funzione è \funcd{brk}, ed il suo prototipo è: +routine di allocazione della memoria viste in sez.~\ref{sec:proc_mem_malloc}. +La prima funzione è \funcd{brk}, ed il suo prototipo è: \begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)} Sposta la fine del segmento dei dati. @@ -683,7 +683,7 @@ La funzione l'indirizzo finale del segmento dati di un processo all'indirizzo specificato da \param{end\_data\_segment}. Quest'ultimo deve essere un valore ragionevole, ed inoltre la dimensione totale del segmento non deve comunque eccedere un -eventuale limite (si veda \secref{sec:sys_resource_limit}) imposto sulle +eventuale limite (si veda sez.~\ref{sec:sys_resource_limit}) imposto sulle dimensioni massime dello spazio dati del processo. La seconda funzione per la manipolazione delle dimensioni del segmento @@ -713,7 +713,7 @@ standard descritte in precedenza, che sono costruite su di esse. \subsection{Il controllo della memoria virtuale\index{memoria virtuale}} \label{sec:proc_mem_lock} -Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria +Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da parte dei vari processi. @@ -737,7 +737,7 @@ motivi per cui si possono avere di queste necessit quali pagine di memoria è opportuno che restino in memoria per un aumento delle prestazioni. In genere queste sono esigenze particolari e richiedono anche un aumento delle priorità in esecuzione del processo (vedi - \secref{sec:proc_real_time}). + sez.~\ref{sec:proc_real_time}). \item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro in memoria queste possono essere portate su disco dal meccanismo della @@ -766,7 +766,7 @@ memoria bloccata non la sblocca. Chiaramente la terminazione del processo comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di tutti i suoi \textit{memory lock}. Infine \textit{memory lock} non sono ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on - write}\index{copy on write} (vedi \secref{sec:proc_fork}) gli indirizzi + write}\index{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio sono mantenuti sullo stesso segmento di RAM del padre, quindi fintanto che un figlio non scrive su un segmento, può usufruire del memory lock del padre.} @@ -774,7 +774,7 @@ ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce la memoria fisica disponibile nel sistema, questo ha un evidente impatto su tutti gli altri processi, per cui solo un processo con i privilegi di -amministratore (vedremo in \secref{sec:proc_perms} cosa significa) ha la +amministratore (vedremo in sez.~\ref{sec:proc_perms} cosa significa) ha la capacità di bloccare una pagina. Ogni processo può però sbloccare le pagine relative alla propria memoria. @@ -873,8 +873,8 @@ Tutti i programmi hanno la possibilit vengono lanciati. Il passaggio dei parametri è effettuato attraverso gli argomenti \param{argc} e \param{argv} della funzione \func{main}, che vengono passati al programma dalla shell (o dal processo che esegue la \func{exec}, -secondo le modalità che vedremo in \secref{sec:proc_exec}) quando questo viene -messo in esecuzione. +secondo le modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo +viene messo in esecuzione. Oltre al passaggio dei parametri, un'altra modalità che permette di passare delle informazioni che modifichino il comportamento di un programma è quello @@ -906,7 +906,7 @@ Nella scansione viene costruito il vettore di puntatori \param{argv} inserendo in successione il puntatore alla stringa costituente l'$n$-simo parametro; la variabile \param{argc} viene inizializzata al numero di parametri trovati, in questo modo il primo parametro è sempre il nome del programma; un esempio di -questo meccanismo è mostrato in \figref{fig:proc_argv_argc}. +questo meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}. \subsection{La gestione delle opzioni} @@ -919,7 +919,7 @@ che non sia un singolo \texttt{'-'} o un \texttt{'--'} viene considerato un'opzione. In genere le opzioni sono costituite da una lettera singola (preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro associato; un comando tipico può essere quello mostrato in -\figref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m} +fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m} e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un argomento del programma, non un parametro di \cmd{-m}). @@ -945,7 +945,7 @@ trova un'opzione valida. La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è costituita da tutti i caratteri usati per identificare le singole opzioni, se l'opzione ha un parametro al carattere deve essere fatto seguire un segno di -due punti \texttt{':'}; nel caso di \figref{fig:proc_argv_argc} ad esempio la +due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}. La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la @@ -980,7 +980,7 @@ carattere, in questo modo si possono eseguire azioni specifiche usando uno \item \var{int optopt} contiene il carattere dell'opzione non riconosciuta. \end{itemize*} -In \figref{fig:proc_options_code} è mostrata la sezione del programma +In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma \file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di comando. @@ -1041,7 +1041,7 @@ dichiarazione del tipo: \includecodesnip{listati/env_ptr.c} un esempio della struttura di questa lista, contenente alcune delle variabili più comuni che normalmente sono definite dal sistema, è riportato in -\figref{fig:proc_envirno_list}. +fig.~\ref{fig:proc_envirno_list}. \begin{figure}[htb] \centering \includegraphics[width=11cm]{img/environ_var} @@ -1051,7 +1051,7 @@ pi Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate -in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate +in fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di usare nomi espressi in caratteri maiuscoli.\footnote{la convenzione vuole che si usino dei nomi maiuscoli per le variabili di ambiente di uso generico, i @@ -1064,19 +1064,19 @@ costituiscono un modo comodo per definire un comportamento specifico senza dover ricorrere all'uso di opzioni a linea di comando o di file di configurazione. É di norma cura della shell, quando esegue un comando, passare queste variabili al programma messo in esecuzione attraverso un uso opportuno -delle relative chiamate (si veda \secref{sec:proc_exec}). +delle relative chiamate (si veda sez.~\ref{sec:proc_exec}). La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per -i dettagli si veda \secref{sec:sess_login}). In genere è cura +i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura dell'amministratore definire le opportune variabili di ambiente in uno script di avvio. Alcune servono poi come riferimento generico per molti programmi (come \var{EDITOR} che indica l'editor preferito da invocare in caso di necessità). Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più -comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta +comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta tutte e ne definisce anche altre: per una lista più completa si può controllare \cmd{man environ}. @@ -1129,7 +1129,7 @@ Oltre a questa funzione di lettura, che C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema delle funzioni previste nei vari standard e disponibili in Linux è riportato -in \tabref{tab:proc_env_func}. +in tab.~\ref{tab:proc_env_func}. \begin{table}[htb] \centering @@ -1158,7 +1158,7 @@ in \tabref{tab:proc_env_func}. In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono -definite tutte le funzioni elencate in \tabref{tab:proc_env_func}. La prima, +definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima, \func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due, \funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di ambiente, i loro prototipi sono i seguenti: @@ -1208,7 +1208,7 @@ invece esiste il suo valore sar variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a questa funzione una variabile automatica (per evitare i problemi esposti in -\secref{sec:proc_auto_var}). +sez.~\ref{sec:proc_auto_var}). Si tenga infine presente che se si passa a \func{putenv} solo il nome di una variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un @@ -1218,8 +1218,8 @@ versione del vettore \var{environ} questo sar corrente sarà deallocata solo se anch'essa è risultante da un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi -\secref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi -\figref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato. +sez.~\ref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi +fig.~\ref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato. Inoltre la memoria associata alle variabili di ambiente eliminate non viene liberata. @@ -1289,7 +1289,7 @@ funzione chiamante un valore relativo ad uno dei suoi parametri. Per far questo si usa il cosiddetto \textit{value result argument}, si passa cioè, invece di una normale variabile, un puntatore alla stessa; vedremo alcuni esempi di questa modalità nelle funzioni che gestiscono i socket (in -\secref{sec:TCP_functions}), in cui, per permettere al kernel di restituire +sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire informazioni sulle dimensioni delle strutture degli indirizzi utilizzate, viene usato questo meccanismo. @@ -1321,7 +1321,7 @@ Lo standard ISO C prevede che una \textit{variadic function}\index{variadic} abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di dichiarazione è il prototipo della funzione \func{execl} che vedremo in -\secref{sec:proc_exec}: +sez.~\ref{sec:proc_exec}: \includecodesnip{listati/exec_sample.c} in questo caso la funzione prende due parametri fissi ed un numero variabile di altri parametri (che verranno a costituire gli elementi successivi al primo diff --git a/sockctrl.tex b/sockctrl.tex index 7a7d12f..eec51ec 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -170,13 +170,12 @@ carattere ``\texttt{:}'' e prosegue con la lista dei \textsl{servizi} su cui le relative informazioni sono raggiungibili, scritti nell'ordine in cui si vuole siano interrogati. -Ciascun servizio è specificato a sua volta da un nome, come \texttt{file}, +Ogni servizio è specificato a sua volta da un nome, come \texttt{file}, \texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che -realizza l'interfaccia con esso, che per ciascuno di essi sarà realizzata in -un file \texttt{libnss\_NAME} dove \texttt{NAME} è appunto il nome - - - +realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il +nome utilizzato dentro \file{/etc/nsswitch.conf}, dovrà essere presente +(usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne +implementa le funzioni. In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive @@ -188,6 +187,54 @@ disposizione,\footnote{ quelle che tratteremo nelle sezioni successive. +\subsection{Le funzioni di interrogazione del \textit{resolver}} +\label{sec:sock_resolver_functions} + +Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a +dominio conviene trattare in maniera più dettagliata il meccanismo principale +da esse utilizzato e cioè quello del servizio DNS. Come accennato questo, +benché in teoria sia solo uno dei possibili supporti su cui mantenere le +relative informazioni, in pratica costituisce il meccanismo principale + + +Per questo motivo il \textit{resolver} prevede delle funzioni che permettono +sia di eseguire direttamente delle interrogazione ad un server DNS, che di +controllare le modalità con cui queste vengono eseguite; diventa così +possibile modificare da programma buona parte dei parametri controllati da +\file{/etc/resolv.conf}. + + + +Per capire meglio il contenuto della struttura \struct{hostent} conviene +spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un +database distribuito organizzato in maniera gerarchica, interrogando il quale +si possono avere una serie di informazioni, la principale delle quali è la +corrispondenza fra un nome (a dominio) ed indirizzo IP. Un server DNS +contiene comunque una serie di altre informazioni; ciascuna voce nel database +viene chiamata \textit{resource record} e vi è associato un certo +\textsl{tipo}, identificato da una sigla. Per quanto ci interessa i tipi di +\textit{resource record} che vengono utilizzati dal \textit{resolver} sono +sostanzialmente i seguenti: +\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}} +\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un + indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it} + e l'indirizzo IP \texttt{62.48.34.25}. +\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro + volte quella di un indirizzo IPv4, questo record contiene la corrispondenza + fra un nome a dominio ed un indirizzo IPv6. +\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed + un nome a dominio si utilizza invece questo tipo di record (il cui nome sta + per \textit{pointer}). +\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia + indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o + \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla + macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per + creare degli \textit{alias} in modo da associare un qualunque altro nome al + \textsl{nome canonico} della macchina (quello associato al record + \texttt{A}). +\end{basedescript} + + \subsection{La risoluzione dei nomi a dominio} \label{sec:sock_gethostbyname} @@ -246,35 +293,6 @@ ed i valori che pu di un server DNS, si può ritentare l'interrogazione in un secondo tempo. \end{basedescript} -Per capire meglio il contenuto della struttura \struct{hostent} conviene -spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un -database distribuito organizzato in maniera gerarchica, interrogando il quale -si possono avere una serie di informazioni, la principale delle quali è la -corrispondenza fra un nome (a dominio) ed indirizzo IP. Un server DNS -contiene comunque una serie di altre informazioni; ciascuna voce nel database -viene chiamata \textit{resource record} e vi è associato un certo -\textsl{tipo}, identificato da una sigla. Per quanto ci interessa i tipi di -\textit{resource record} che vengono utilizzati dal \textit{resolver} sono -sostanzialmente i seguenti: -\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}} -\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un - indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it} - e l'indirizzo IP \texttt{62.48.34.25}. -\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro - volte quella di un indirizzo IPv4, questo record contiene la corrispondenza - fra un nome a dominio ed un indirizzo IPv6. -\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed - un nome a dominio si utilizza invece questo tipo di record (il cui nome sta - per \textit{pointer}). -\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia - indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o - \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla - macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per - creare degli \textit{alias} in modo da associare un qualunque altro nome al - \textsl{nome canonico} della macchina (quello associato al record - \texttt{A}). -\end{basedescript} - Quando un programma chiama \func{gethostbyname} e questa usa il DNS per effettuare la risoluzione del nome, è con i valori di questi record che vengono riempite le varie parti della struttura \struct{hostent}. Il primo @@ -289,14 +307,14 @@ DNS vengono inseriti come record di tipo \texttt{CNAME}). Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la -lunghezza dell'indirizzo stesso in byte. Infine il campo \var{h\_addr\_list} è -il puntatore ad un vettore di puntatori ai singoli indirizzi; il vettore è -terminato da un puntatore nullo. Inoltre, come illustrato in -fig.~\ref{fig:sock_hostent_struct}, viene definito il campo \var{h\_addr} come -sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento diretto al primo -indirizzo della lista. - - +lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una +struttura + +Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori +ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre, +come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo +\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento +diretto al primo indirizzo della lista. Oltre ai normali nomi a dominio la funzione accetta come argomento \param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o