Risistemati i font di tutte le figure, piu qualche aggiunta al resolver
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 10 Jul 2004 21:55:13 +0000 (21:55 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 10 Jul 2004 21:55:13 +0000 (21:55 +0000)
46 files changed:
img/IP_AH_packet.dia
img/dir_links.dia
img/dir_struct.dia
img/disk_struct.dia
img/environ_var.dia
img/esp_option.dia
img/exec_rel.dia
img/fifoserver.dia
img/file_flock.dia
img/file_lock_dead.dia
img/file_posix_lock.dia
img/filedup.dia
img/filemultacc.dia
img/fileperm.dia
img/fileshar.dia
img/filesys_struct.dia
img/ipv6_head.dia
img/iso_tcp_comp.dia
img/memory_layout.dia
img/mmap_boundary.dia
img/mmap_exceed.dia
img/mmap_layout.dia
img/mqstruct.dia
img/pipe.dia
img/pipefork.dia
img/pipeuse.dia
img/port_alloc.dia
img/proc_beginend.dia
img/proc_exit.dia
img/procfile.dia
img/semtruct.dia
img/sh_memory_layout.dia
img/struct_sys.dia
img/task_struct.dia
img/tcp_client_early_abort.dia
img/tcp_close.dia
img/tcp_connection.dia
img/tcp_data_flux.dia
img/tcpip_overview.dia
img/term_struct.dia
img/three_way_handshake.dia
img/tty_login.dia
img/udp_connection.dia
img/vfs.dia
process.tex
sockctrl.tex

index 65c6fbd..f95f16d 100644 (file)
Binary files a/img/IP_AH_packet.dia and b/img/IP_AH_packet.dia differ
index 7eaf5a3..82ac44f 100644 (file)
Binary files a/img/dir_links.dia and b/img/dir_links.dia differ
index 0c5b0ff..0c8dd86 100644 (file)
Binary files a/img/dir_struct.dia and b/img/dir_struct.dia differ
index c86d957..0c248c1 100644 (file)
Binary files a/img/disk_struct.dia and b/img/disk_struct.dia differ
index bd352e8..318629b 100644 (file)
Binary files a/img/environ_var.dia and b/img/environ_var.dia differ
index 5ffbf47..39a560b 100644 (file)
Binary files a/img/esp_option.dia and b/img/esp_option.dia differ
index 7daeb1d..f06e934 100644 (file)
Binary files a/img/exec_rel.dia and b/img/exec_rel.dia differ
index 4ce7c8b..93b3496 100644 (file)
Binary files a/img/fifoserver.dia and b/img/fifoserver.dia differ
index 7c30fd8..5a10b25 100644 (file)
Binary files a/img/file_flock.dia and b/img/file_flock.dia differ
index a414a5d..c7d2699 100644 (file)
Binary files a/img/file_lock_dead.dia and b/img/file_lock_dead.dia differ
index bb7c248..89a610a 100644 (file)
Binary files a/img/file_posix_lock.dia and b/img/file_posix_lock.dia differ
index 06e0e35..1477173 100644 (file)
Binary files a/img/filedup.dia and b/img/filedup.dia differ
index 587c3c2..5393ff1 100644 (file)
Binary files a/img/filemultacc.dia and b/img/filemultacc.dia differ
index 19474b5..47b6ee8 100644 (file)
Binary files a/img/fileperm.dia and b/img/fileperm.dia differ
index 97eb289..077ceb0 100644 (file)
Binary files a/img/fileshar.dia and b/img/fileshar.dia differ
index 49ac773..f956256 100644 (file)
Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ
index 4fe96fb..34ce587 100644 (file)
Binary files a/img/ipv6_head.dia and b/img/ipv6_head.dia differ
index 501183d..b7a9b18 100644 (file)
Binary files a/img/iso_tcp_comp.dia and b/img/iso_tcp_comp.dia differ
index a2b20df..87189ae 100644 (file)
Binary files a/img/memory_layout.dia and b/img/memory_layout.dia differ
index edff5d4..29956d3 100644 (file)
Binary files a/img/mmap_boundary.dia and b/img/mmap_boundary.dia differ
index 2a77fa3..8630e39 100644 (file)
Binary files a/img/mmap_exceed.dia and b/img/mmap_exceed.dia differ
index 7978d5a..bfb34bf 100644 (file)
Binary files a/img/mmap_layout.dia and b/img/mmap_layout.dia differ
index 07c5127..f3ebe0a 100644 (file)
Binary files a/img/mqstruct.dia and b/img/mqstruct.dia differ
index 349b393..8be4c57 100644 (file)
Binary files a/img/pipe.dia and b/img/pipe.dia differ
index d8e57da..e64a081 100644 (file)
Binary files a/img/pipefork.dia and b/img/pipefork.dia differ
index 9f4d609..e3f62ae 100644 (file)
Binary files a/img/pipeuse.dia and b/img/pipeuse.dia differ
index a116b97..90885d2 100644 (file)
Binary files a/img/port_alloc.dia and b/img/port_alloc.dia differ
index 75a5da1..181bf26 100644 (file)
Binary files a/img/proc_beginend.dia and b/img/proc_beginend.dia differ
index b2f2e82..86c75ca 100644 (file)
Binary files a/img/proc_exit.dia and b/img/proc_exit.dia differ
index adff9e7..d4a21ca 100644 (file)
Binary files a/img/procfile.dia and b/img/procfile.dia differ
index 0744183..80856c3 100644 (file)
Binary files a/img/semtruct.dia and b/img/semtruct.dia differ
index 5d64ed2..9e7f500 100644 (file)
Binary files a/img/sh_memory_layout.dia and b/img/sh_memory_layout.dia differ
index 96ef2d5..cc9c1a0 100644 (file)
Binary files a/img/struct_sys.dia and b/img/struct_sys.dia differ
index 2095dec..5859390 100644 (file)
Binary files a/img/task_struct.dia and b/img/task_struct.dia differ
index 6c0472b..72ca2f8 100644 (file)
Binary files a/img/tcp_client_early_abort.dia and b/img/tcp_client_early_abort.dia differ
index 1be6432..94b132e 100644 (file)
Binary files a/img/tcp_close.dia and b/img/tcp_close.dia differ
index 0605752..e827544 100644 (file)
Binary files a/img/tcp_connection.dia and b/img/tcp_connection.dia differ
index f760045..f587f39 100644 (file)
Binary files a/img/tcp_data_flux.dia and b/img/tcp_data_flux.dia differ
index 26b2254..d82bb4b 100644 (file)
Binary files a/img/tcpip_overview.dia and b/img/tcpip_overview.dia differ
index e3d833a..0643f34 100644 (file)
Binary files a/img/term_struct.dia and b/img/term_struct.dia differ
index 2b4cdad..03578c5 100644 (file)
Binary files a/img/three_way_handshake.dia and b/img/three_way_handshake.dia differ
index e6d222f..096e50c 100644 (file)
Binary files a/img/tty_login.dia and b/img/tty_login.dia differ
index d44c6c3..d19630a 100644 (file)
Binary files a/img/udp_connection.dia and b/img/udp_connection.dia differ
index d296836..1052b79 100644 (file)
Binary files a/img/vfs.dia and b/img/vfs.dia differ
index 39e0101..b21dc6b 100644 (file)
@@ -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
index 7a7d12f..eec51ec 100644 (file)
@@ -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