From 758b135b7f04cdcebc4fe2726dc540cb24d116ba Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 30 Mar 2003 00:35:20 +0000 Subject: [PATCH] Un monte di correzioni fatte su indicazioni di Mirko Maischberger. Che ha fatto una favolosa versione HTML --- fileadv.tex | 7 +- filedir.tex | 210 ++++++++++++++++++++++++------------------ fileintro.tex | 20 ++-- filestd.tex | 6 +- fileunix.tex | 16 ++-- gapil.tex | 1 + img/tcp_data_flux.dia | Bin 2637 -> 4040 bytes network.tex | 68 +++++++++----- process.tex | 4 +- prochand.tex | 153 +++++++++++++++--------------- ringraziamenti.tex | 3 + system.tex | 13 ++- 12 files changed, 279 insertions(+), 222 deletions(-) diff --git a/fileadv.tex b/fileadv.tex index 75bc689..5203d17 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -405,9 +405,10 @@ di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata -completamente in user space. Esistono comunque vari progetti sperimentali -(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un -supporto diretto da parte del kernel. +completamente in user space, ed accessibile linkando i programmi con la +libreria \file{librt}. Esistono comunque vari progetti sperimentali (come il +KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un supporto +diretto da parte del kernel. Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per diff --git a/filedir.tex b/filedir.tex index 481ef53..191179b 100644 --- a/filedir.tex +++ b/filedir.tex @@ -319,12 +319,15 @@ possibile effettuare link anche attraverso filesystem diversi, a file posti in filesystem che non supportano i link diretti, a delle directory, ed anche a file che non esistono ancora. -Il sistema funziona in quanto i link simbolici sono contrassegnati come tali -al kernel (analogamente a quanto avviene per le directory) per cui per alcune -funzioni di libreria (come \func{open} o \func{stat}) dare come parametro un -link simbolico comporta l'applicazione della funzione al file da esso -specificato. La funzione che permette di creare un nuovo link simbolico è -\funcd{symlink}; il suo prototipo è: +Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal +kernel\footnote{è uno dei diversi tipi di file visti in + \tabref{tab:file_file_types}, contrassegnato come tale nell'inode, e + riconoscibile dal valore del campo \var{st\_mode} della struttura + \struct{stat} (vedi \secref{sec:file_stat}).} per cui alcune funzioni di +libreria (come \func{open} o \func{stat}) quando ricevono come argomento un +link simbolico vengono automaticamente applicate al file da esso specificato. +La funzione che permette di creare un nuovo link simbolico è \funcd{symlink}, +ed il suo prototipo è: \begin{prototype}{unistd.h} {int symlink(const char *oldpath, const char *newpath)} Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è @@ -1107,10 +1110,10 @@ concluse con successo. \label{sec:file_work_dir} A ciascun processo è associata una directory nel filesystem che è chiamata -directory corrente o directory di lavoro (\textit{current working directory}) -che è quella a cui si fa riferimento quando un pathname è espresso in forma -relativa, dove il ``\textsl{relativa}'' fa riferimento appunto a questa -directory. +\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese +\textit{current working directory}) che è quella a cui si fa riferimento +quando un pathname è espresso in forma relativa, dove il ``\textsl{relativa}'' +fa riferimento appunto a questa directory. Quando un utente effettua il login, questa directory viene impostata alla \textit{home directory} del suo account. Il comando \cmd{cd} della shell @@ -1121,8 +1124,8 @@ resta la stessa quando viene creato un processo figlio (vedi directory corrente di qualunque comando da essa lanciato. In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode} -della directory di lavoro corrente, per ottenere il pathname occorre usare una -apposita funzione di libreria, \funcd{getcwd}, il cui prototipo è: +della directory di lavoro, per ottenere il pathname occorre usare una apposita +funzione di libreria, \funcd{getcwd}, il cui prototipo è: \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)} Legge il pathname della directory di lavoro corrente. @@ -1140,12 +1143,12 @@ apposita funzione di libreria, \funcd{getcwd}, il cui prototipo \end{errlist}} \end{prototype} -La funzione restituisce il pathname completo della directory di lavoro -corrente nella stringa puntata da \param{buffer}, che deve essere -precedentemente allocata, per una dimensione massima di \param{size}. Il -buffer deve essere sufficientemente lungo da poter contenere il pathname -completo più lo zero di terminazione della stringa. Qualora esso ecceda le -dimensioni specificate con \param{size} la funzione restituisce un errore. +La funzione restituisce il pathname completo della directory di lavoro nella +stringa puntata da \param{buffer}, che deve essere precedentemente allocata, +per una dimensione massima di \param{size}. Il buffer deve essere +sufficientemente lungo da poter contenere il pathname completo più lo zero di +terminazione della stringa. Qualora esso ecceda le dimensioni specificate con +\param{size} la funzione restituisce un errore. Si può anche specificare un puntatore nullo come \param{buffer},\footnote{questa è un'estensione allo standard POSIX.1, @@ -1171,11 +1174,11 @@ dei link simbolici. Usando \func{getcwd} infatti, essendo il pathname ricavato risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio attraverso eventuali link simbolici. -Per cambiare la directory di lavoro corrente si può usare la funzione -\funcd{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta -appunto per \textit{change directory}, il suo prototipo è: +Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir} +(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per +\textit{change directory}, il suo prototipo è: \begin{prototype}{unistd.h}{int chdir(const char *pathname)} - Cambia la directory di lavoro corrente in \param{pathname}. + Cambia la directory di lavoro in \param{pathname}. \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore, nel qual caso \var{errno} assumerà i valori: @@ -1320,11 +1323,11 @@ il suo prototipo funzione non si può usare una stringa costante. Tutte le avvertenze riguardo alle possibili \textit{race condition}\index{race condition} date per \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni -il valore di usato per sostituire le \code{XXXXXX} viene formato con il -\acr{pid} del processo più una lettera, il che mette a disposizione solo 26 -possibilità diverse per il nome del file, e rende il nome temporaneo facile da -indovinare. Per tutti questi motivi la funzione è deprecata e non dovrebbe mai -essere usata. +il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid} +del processo più una lettera, il che mette a disposizione solo 26 possibilità +diverse per il nome del file, e rende il nome temporaneo facile da indovinare. +Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere +usata. La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a \func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo @@ -1406,7 +1409,7 @@ seguenti: \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono - lette le informazioni relativa ad esso e non al file a cui fa riferimento. + lette le informazioni relativae ad esso e non al file a cui fa riferimento. \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat} eccetto che si usa con un file aperto, specificato tramite il suo file @@ -1466,7 +1469,7 @@ primitivi del sistema (di quelli definiti in Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e alle directory esistono altri oggetti che possono stare su un filesystem. Il tipo di file è ritornato dalla \func{stat} come maschera binaria nel campo -\var{st\_mode} (che che contiene anche le informazioni relative ai permessi). +\var{st\_mode} (che contiene anche le informazioni relative ai permessi). Dato che il valore numerico può variare a seconda delle implementazioni, lo standard POSIX definisce un insieme di macro per verificare il tipo di file, @@ -2063,7 +2066,7 @@ Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un programma il comportamento normale del kernel è quello di impostare gli identificatori del gruppo \textit{effective} del nuovo processo al valore dei corrispondenti del gruppo \textit{real} del processo corrente, che normalmente -corrispondono dell'utente con cui si è entrati nel sistema. +corrispondono a quelli dell'utente con cui si è entrati nel sistema. Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} @@ -2074,13 +2077,13 @@ il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali -di usare programmi che abbisognano di privilegi speciali; l'esempio classico è -il comando \cmd{passwd} che ha la necessità di modificare il file delle -password, quest'ultimo ovviamente può essere scritto solo dall'amministratore, -ma non è necessario chiamare l'amministratore per cambiare la propria -password. Infatti il comando \cmd{passwd} appartiene a root ma ha il bit -\acr{suid} impostato per cui quando viene lanciato da un utente normale parte -con i privilegi di root. +di usare programmi che richiedono privilegi speciali; l'esempio classico è il +comando \cmd{passwd} che ha la necessità di modificare il file delle password, +quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è +necessario chiamare l'amministratore per cambiare la propria password. Infatti +il comando \cmd{passwd} appartiene a root ma ha il bit \acr{suid} impostato +per cui quando viene lanciato da un utente normale parte con i privilegi di +root. Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di @@ -2165,7 +2168,7 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. Vedremo in \secref{sec:file_base_func} con quali funzioni si possono creare nuovi file, in tale occasione vedremo che è possibile specificare in sede di creazione quali permessi applicare ad un file, però non si può indicare a -quale utente e gruppo esso deve appartenere. Lo stesso problema di presenta +quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta per la creazione di nuove directory (procedimento descritto in \secref{sec:file_dir_creat_rem}). @@ -2384,9 +2387,29 @@ perdita di questo privilegio. \subsection{La funzione \func{umask}} \label{sec:file_umask} -Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai -nuovi file sono controllati anche da una maschera di bit impostata con la -funzione \funcd{umask}, il cui prototipo è: +Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i +permessi di un file, resta però il problema di quali sono i permessi assegnati +quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come +vedremo in \secref{sec:file_open}, permettono di indicare esplicitamente i +permessi di creazione di un file, ma questo non è possibile per le funzioni +dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e +gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i +permessi non vengono indicati esplicitamente. + +In tutti questi casi l'unico riferimento possibile è quello della modalità di +apertura del nuovo file (lettura/scrittura o sola lettura), che però può +fornire un valore che è lo stesso per tutti e tre i permessi di +\secref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel +secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è + infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct}, + vedi \figref{fig:proc_task_struct}.} una maschera di bit, la cosiddetta +\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano +essere assegnati ai nuovi file in sede di creazione. I bit indicati nella +maschera vengono infatti cancellati dai permessi quando un nuovo file viene +creato. + +La funzione che permette di impostare il valore di questa maschera di +controllo è \funcd{umask}, ed il suo prototipo è: \begin{prototype}{stat.h} {mode\_t umask(mode\_t mask)} @@ -2397,27 +2420,12 @@ Imposta la maschera dei permessi dei bit al valore specificato da \param{mask} delle poche funzioni che non restituisce codici di errore.} \end{prototype} -Questa maschera è una caratteristica di ogni processo\footnote{è infatti - contenuta nel campo \param{umask} di \struct{fs\_struct}, vedi - \figref{fig:proc_task_struct}.} e viene utilizzata per impedire che alcuni -permessi possano essere assegnati ai nuovi file in sede di creazione. I bit -indicati nella maschera vengono infatti esclusi quando un nuovo file viene -creato. - -In genere questa maschera serve per impostare un valore predefinito dei -permessi che ne escluda alcuni (usualmente quello di scrittura per il gruppo e -gli altri, corrispondente ad un valore di $022$). Essa è utile perché le -routine dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei -permessi, e pertanto tutti i nuovi file vengono sempre creati con un valore di -$666$ (cioè permessi di lettura e scrittura per tutti, si veda -\tabref{tab:file_permission_const} per un confronto); in questo modo è -possibile cancellare automaticamente i permessi non voluti, senza doverlo fare -esplicitamente. - -In genere il valore di \func{umask} viene stabilito una volta per tutte al -login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però -si vuole che un processo possa creare un file che chiunque possa leggere -allora occorrerà cambiare il valore di \func{umask}. +In genere si usa questa maschera per impostare un valore predefinito che +escluda preventivamente alcuni permessi (usualmente quello di scrittura per il +gruppo e gli altri, corrispondente ad un valore per \param{mask} pari a +$022$). In questo modo è possibile cancellare automaticamente i permessi non +voluti. Di norma questo valore viene impostato una volta per tutte al login a +$022$, e gli utenti non hanno motivi per modificarlo. \subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}} @@ -2534,7 +2542,7 @@ Per compattezza, nella tabella si sono specificati i bit di \acr{suid}, In \tabref{tab:file_dirperm_bits} si sono invece riassunti gli effetti dei vari bit dei permessi per una directory; anche in questo caso si sono -specificati i bit di \acr{suid}, \acr{sgid} e \acr{stiky} con la notazione +specificati i bit di \acr{suid}, \acr{sgid} e \acr{sticky} con la notazione compatta illustrata in \figref{fig:file_perm_bit}. \begin{table}[!htb] @@ -2585,17 +2593,29 @@ programma ad una sezione limitata del filesystem, per cui ne parleremo in questa sezione. Come accennato in \secref{sec:proc_fork} ogni processo oltre ad una directory -di lavoro corrente, ha anche una directory radice,\footnote{entrambe sono - contenute in due campi di \struct{fs\_struct}, vedi - \figref{fig:proc_task_struct}.} che è la directory che per il processo -costituisce la radice dell'albero dei file e rispetto alla quale vengono -risolti i pathname assoluti (si ricordi quanto detto in -\secref{sec:file_organization}). La radice viene ereditata dal padre per ogni -processo figlio, e quindi di norma coincide con la \file{/} del sistema. - -In certe situazioni però per motivi di sicurezza non si vuole che un processo -possa accedere a tutto il filesystem; per questo si può cambiare la directory -radice con la funzione \funcd{chroot}, il cui prototipo è: +di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe sono + contenute in due campi (rispettivamente \var{pwd} e \var{root}) di + \struct{fs\_struct}; vedi \figref{fig:proc_task_struct}.} che, pur essendo +di norma corrispondente alla radice dell'albero di file e directory come visto +dal kernel (ed illustrato in \secref{sec:file_organization}), ha per il +processo il significato specifico di directory rispetto alla quale vengono +risolti i pathname assoluti.\footnote{cioè quando un processo chiede la + risoluzione di un pathname, il kernel usa sempre questa directory come punto + di partenza.} Il fatto che questo valore sia specificato per ogni processo +apre allora la possibilità di modificare le modalità di risoluzione dei +pathname assoluti da parte di un processo cambiando questa directory, così +come si fa coi pathname relativi cambiando la directory di lavoro. + +Normalmente la directory radice di un processo coincide anche con la radice +del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal +padre da ogni processo figlio, in generale i processi risolvono i pathname +assoluti a partire sempre dalla stessa directory, che corrisponde alla +\file{/} del sistema. + +In certe situazioni però, per motivi di sicurezza, è utile poter impedire che +un processo possa accedere a tutto il filesystem; per far questo si può +cambiare la sua directory radice con la funzione \funcd{chroot}, il cui +prototipo è: \begin{prototype}{unistd.h}{int chroot(const char *path)} Cambia la directory radice del processo a quella specificata da \param{path}. @@ -2610,25 +2630,33 @@ radice con la funzione \funcd{chroot}, il cui prototipo \errval{EROFS} e \errval{EIO}.} \end{prototype} \noindent in questo modo la directory radice del processo diventerà -\param{path} (che ovviamente deve esistere) ed ogni pathname assoluto sarà -risolto a partire da essa, rendendo impossibile accedere alla parte di albero -sovrastante; si ha cioè quella che viene chiamata una \textit{chroot jail}. - -Solo l'amministratore può usare questa funzione, e la nuova radice, per quanto -detto in \secref{sec:proc_fork}, sarà ereditata da tutti i processi figli. Si -tenga presente che la funzione non cambia la directory di lavoro corrente, che -potrebbe restare fuori dalla \textit{chroot jail}. +\param{path} (che ovviamente deve esistere) ed ogni pathname assoluto usato +dalle funzioni chiamate nel processo sarà risolto a partire da essa, rendendo +impossibile accedere alla parte di albero sovrastante. Si ha così quella che +viene chiamata una \textit{chroot jail}, in quanto il processo non può più +accedere a file al di fuori della sezione di albero in cui è stato +\textsl{imprigionato}. + +Solo un processo con i privilegi di amministratore può usare questa funzione, +e la nuova radice, per quanto detto in \secref{sec:proc_fork}, sarà ereditata +da tutti i suoi processi figli. Si tenga presente però che la funzione non +cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot + jail}. Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita -si cedono i privilegi di root. Infatti se in qualche modo il processo ha una -directory di lavoro corrente fuori dalla \textit{chroot jail}, potrà comunque -accedere a tutto il filesystem usando pathname relativi. - -Ma quando ad un processo restano i privilegi di root esso potrà sempre portare -la directory di lavoro corrente fuori dalla \textit{chroot jail} creando una -sotto-directory ed eseguendo una \func{chroot} su di essa. Per questo motivo -l'uso di questa funzione non ha molto senso quando un processo necessita dei -privilegi di root per le sue normali operazioni. +si cedono i privilegi di root. Infatti se per un qualche motivo il processo +resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà +comunque accedere a tutto il resto del filesystem usando pathname relativi, i +quali, partendo dalla directory di lavoro che è fuori della \textit{chroot + jail}, potranno (con l'uso di \texttt{..}) risalire fino alla radice +effettiva del filesystem. + +Ma se ad un processo restano i privilegi di amministratore esso potrà comunque +portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si +trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di +\func{chroot} su una qualunque directory contenuta nell'attuale directory di +lavoro. Per questo motivo l'uso di questa funzione non ha molto senso quando +un processo necessita dei privilegi di root per le sue normali operazioni. Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in questo caso infatti si vuole che il server veda solo i file che deve diff --git a/fileintro.tex b/fileintro.tex index 026325f..bb3ab7e 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -346,12 +346,12 @@ portabilit \section{L'architettura della gestione dei file} \label{sec:file_arch_func} -Per capire fino in fondo le proprietà di file e directory in un sistema -unix-like ed il comportamento delle relative funzioni di manipolazione, -occorre una breve introduzione al funzionamento gestione dei file da parte del -kernel e sugli oggetti su cui è basato un filesystem. In particolare occorre -tenere presente dov'è che si situa la divisione fondamentale fra kernel space -e user space che tracciavamo al \capref{cha:intro_unix}. +%% Per capire fino in fondo le proprietà di file e directory in un sistema +%% unix-like ed il comportamento delle relative funzioni di manipolazione, +%% occorre una breve introduzione al funzionamento della gestione dei file da +%% parte del kernel e sugli oggetti su cui è basato un filesystem. In particolare +%% occorre tenere presente dov'è che si situa la divisione fondamentale fra +%% kernel space e user space che tracciavamo al \capref{cha:intro_unix}. In questa sezione esamineremo come viene implementato l'accesso ai file in Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo @@ -531,9 +531,9 @@ astratta del VFS. Qualora se ne voglia eseguire una, il kernel andr utilizzare l'opportuna routine dichiarata in \struct{f\_ops} appropriata al tipo di file in questione. -Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su -normale un file di dati; ovviamente certe operazioni (nel caso della seriale -ad esempio la \code{seek}) non saranno disponibili, però con questo sistema +Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un +normale file di dati; ovviamente certe operazioni (nel caso della seriale ad +esempio la \code{seek}) non saranno disponibili, però con questo sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è immediato e (relativamente) trasparente per l'utente ed il programmatore. @@ -654,7 +654,7 @@ adesso sar Il filesystem standard usato da Linux è il cosiddetto \textit{second extended filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di -file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di +file lunghi (256 caratteri, estensibili a 1012) con una dimensione massima di 4~Tb. Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che diff --git a/filestd.tex b/filestd.tex index eb62d0a..c8ae3c2 100644 --- a/filestd.tex +++ b/filestd.tex @@ -514,7 +514,7 @@ struct histogram { int WriteStruct(FILE *stream, struct histogram *histo) { - if ( fwrite(vec, sizeof(*histo), 1, stream) !=1) { + if ( fwrite(histo, sizeof(*histo), 1, stream) !=1) { perror("Write error"); } return nread; @@ -1002,7 +1002,7 @@ si \cmd{\%X} &\ctyp{unsigned int}& Stampano un intero in formato esadecimale, rispettivamente con lettere minuscole e maiuscole. \\ - \cmd{\%f} &\ctyp{unsigned int}& Stampa un numero in virgola mobile con la + \cmd{\%f} &\ctyp{double} & Stampa un numero in virgola mobile con la notazione a virgola fissa \\ \cmd{\%e}, \cmd{\%E} &\ctyp{double} & Stampano un numero in virgola mobile con la @@ -1620,7 +1620,7 @@ accade per \func{getc} e \func{putc}) sono realizzate come macro. La sostituzione di tutte le funzioni di I/O con le relative versioni \code{\_unlocked} in un programma che non usa i thread è però un lavoro -abbastanza noioso; per questo motivo le \acr{glibc} provvedono al +abbastanza noioso; per questo motivo le \acr{glibc} forniscono al programmatore pigro un'altra via\footnote{anche questa mutuata da estensioni introdotte in Solaris.} da poter utilizzare per disabilitare in blocco il locking degli stream: l'uso della funzione \funcd{\_\_fsetlocking}, il cui diff --git a/fileunix.tex b/fileunix.tex index 543c967..5decd49 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -50,10 +50,10 @@ Quando un file viene aperto la funzione \func{open} restituisce questo numero, tutte le ulteriori operazioni saranno compiute specificando questo stesso valore come argomento alle varie funzioni dell'interfaccia. -Per capire come funziona il meccanismo occorre spiegare a grandi linee come è -che il kernel gestisce l'interazione fra processi e file. Il kernel mantiene -sempre un elenco dei processi attivi nella cosiddetta \textit{process table} -ed un elenco dei file aperti nella \textit{file table}. +Per capire come funziona il meccanismo occorre spiegare a grandi linee come il +kernel gestisce l'interazione fra processi e file. Il kernel mantiene sempre +un elenco dei processi attivi nella cosiddetta \textit{process table} ed un +elenco dei file aperti nella \textit{file table}. La \textit{process table} è una tabella che contiene una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è costituita da una @@ -300,7 +300,7 @@ usato sempre il file descriptor con il valore pi \func{write} bloccherà fino al completamento della scrittura di tutti dati sul sull'hardware sottostante.\\ \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\ - \const{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei + \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è disponibile per il singolo file ma come opzione per il filesystem in fase di montaggio.\\ @@ -462,7 +462,7 @@ ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo \funcdecl{off\_t lseek(int fd, off\_t offset, int whence)} Imposta la posizione attuale nel file. - \bodydesc{La funzione ritorna valore della posizione corrente in caso di + \bodydesc{La funzione ritorna il valore della posizione corrente in caso di successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} @@ -522,7 +522,7 @@ indefinito. \label{sec:file_read} -Una volta che un file è stato aperto (con il permesso in lettura) su possono +Una volta che un file è stato aperto (con il permesso in lettura) si possono leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui prototipo è: \begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)} @@ -713,7 +713,7 @@ confronti dell'accesso allo stesso file da parte di processi diversi. \label{fig:file_mult_acc} \end{figure} -Il primo caso è quello in cui due processi diversi che aprono lo stesso file +Il primo caso è quello in cui due processi diversi aprono lo stesso file su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun processo avrà una sua voce nella \textit{file table} referenziata da un diff --git a/gapil.tex b/gapil.tex index ab1bf2c..6f3560d 100644 --- a/gapil.tex +++ b/gapil.tex @@ -15,6 +15,7 @@ %% gapil.tex: file principale, gli altri vanno inclusi da questo. %% \documentclass[a4paper,11pt,twoside,italian]{book} +%\usepackage{tex4ht} \usepackage[latin1]{inputenc} \usepackage[bookmarks=true]{hyperref} \usepackage{makeidx} diff --git a/img/tcp_data_flux.dia b/img/tcp_data_flux.dia index 39329096027206e3523e87f88b592f0a51517478..f760045c614b7bdccf7cd0b2e172ecf6dc8eb05c 100644 GIT binary patch literal 4040 zcmV;(4>#~1iwFP!000001MOW|bK^D=exF~VQeI`64UhmB#gj^=cB@jg$5dwa*+omV z%?&N8C^{bJVSoDql&pgybr6T8QQI|6C{bvEM1Sb7FaGrNx2LT4XHv}4d~(wV&+qq= z$tWMElZTuBf4=_xO7wsJ_~EB<8viK&Jrwa%Pkv%DQ%5)b$FiLMczyly^5SK$v$)I) zFH4`jS#tfqILqQ|dD3D_ag^d|9Ba?`(yM}IsN`SWDl zpP#ijZtFfBCXseL&DJ~w;$+ny#iL?2IAf6zEyj_RmMcmmJk=Ykf z*cXw`Zl`%s7I9i`i@D45EQu#`NoDbzbeA(5#hF|(yQTu&N54vH_vGq>2Yz|^}dPM&pUJm^OtHHRV5;eUz1`n{I9Dms<*ht3&mf% z3i;iClTo>t-j_0-jN@Y5yXt+;v)6y5lcc}ecIBpc1VVSc zPsIKcI$tvh)yZvz5!=^og%7^Y=(F-QOX{O1ljo-`?LB7baXfp>lF7sFFHXA+J}cv* zyp4+@e`){X`eWbjpFpTDWbfVWC?lDSEnTAJ$o4MKN`$G)Gs-6u2{jT8XSKmr@AMue zhAO0$a9QROF1hIUR&U?**_NI+e3&ji%%JtdZ<|H!E6rb?!}mzm z1bFbGaG?GSg~Y8v*crT%EP1*e<;7&1OqrNWHT<5%$25k1OwxzPvVH81x|zx)Roqrg zw!gJhSM)Xs)o(}edX#F}z@hhZm1CsL@9b?6kJIOw&K`24QneUPL|3ciQn#p8fky{{ z7Y##?54Zrnh;wFCaIj(X=jiWr*1{p~$&gBHV!`!q3?f;npn? zZqX8f4u%LUJ{xR)7EIeAUz2ZT17uQt$fO>(iJHV?Oh_R>iC{zSQA*@dq>j2tE!CCS zx-px6h}t==dRf%HbTuFF=OR}wgr~U06}-ch)8@R(CuNgF_4?wJPx*6^N`vcKN6wb% z)2K~CPsrxdI%Iiuky1Cb8jUT#`q2{!SY)4GsEo1^NVkWRBXaX2DL2823#AyD81~mcyeYiC8<4Vp z-~`?xC&WeMgzSl&5R9B4JwbY6G^xwCoFU#qF+e|?)q?>Dj|v7BL6CZW5HaPQ;Vc?* z4?;gss7Tovu#CTzkBQv#$`9irm3IIsM@P!hw9=4v*rXlWiJJthmXJuA@m51ZxRW9h zz$y}?9VTdpei~$8wT^_)MIi|ZoK%u*PN(sGjEW%bK-yuHc2J$L2z#Hf2!sZp({?=x zY!s9bh7~0j#Z|Ue81fXGJcSwHDcm|wVJn_uzpMnXt^|pS38KOc?6y`bODd)ky)hLB zwI#I)HJ^Yn5+o}~R*aGrrbAYucOomo0DM}mFp&VdQDUNS6l+W_hNxhXi94ba86Ya) zAfmDsQUM1s6|6Ktu41A!mv4frSdXf}GOPkl;wrE&u!8j_NLG-nm?bNb23aBGeaH#{ z6ZlE3vz3jS6A7ePbaF9d1*=Znu@yp0uoe4p6<7n) zY)_SjY11LWy@-bcIwYW;P&EiFn@F|kG%}RV6Mjb<$>yW00*m$+;M1inU82i*x>W6% z4#82GEwvneYT9;d17@ZV%)$XMi#K47tOK*y3(Nw68G#vr`D}nW&;e%lPQc9dff-zw z%&@eX!M@Q9`>kd`vl-DD(fN!X%Bq9T(L15DFo4c3>}FUR&S2kihW(~9pzVz4jOctu zP7PlJp6d}Q>MA0oouLnb7Y>M3fQ~#7aW()?h!DsSA`g5O826YuKK*diw8+bRlxJDq z8>hW^I?d8i{Fl5BiOa~;*YqiwUHzUv#gp$MI<>vPZVi6%|(OV<`U{ zMZlC;b`~JU zcKWS9U>4!v%CC~TLY3q-1X3L^_1CgRzA>u?gPe4o^(m)!8QNmBa|XeeH{7OMSa>3m zw=k$8N0R1&2cZyBC_j&slvzId1AW3;E}z;G!(GPeE~B5P#;tBMswoqH+h$1QY@6Af zR)Z-N;Xc#0&je;Nnh4m9G7urz4Dpvy2F@gzQQpO~h%!`(t5rr*(z{P*=_tlsM>o)b zd4r)wH#2o&WlrMSl zht#|;FKIb??0tECy34aB71U1?qISD-0$FwClz&}x<2>9F(=ziuOQ*Mw zd6E7lO^7(#Ddj%SW;$ZzN-w1~WKGC49*;L|v+c&8Aq_)nRGoj%P$_jGqJDE zuu^C1j|9<}5~?$*vqg3OrT5QtoR;~E)alQkn)Ep^pwHC0I+K+)NA{JOo~JG|)aCC_ zmk)4*X=nF9WI5add^6r64Q!0JT$tx8!gz~@<4a-lbVD7EdpJhG>Z-CICbn@3&DR5f1(NLG@a9(arn6m032L0$XZFGzB!Mc1;3wmvEOC z3E%Unwv=tn-uu9gV3ET-1_>@OVAvq8j z`in#GC=iYH-E11{H6V^LA&z+N@6J8ya4X`#hW1^gHQEskXu$MEZCeuuFTrjCn+%Hs zO^Yt#+RTf62F7kfrrF3ahbS$Eg)jjqzAL+;vM1im3hLCX@Eutd6s?NGt%`f9ejQj9 z_n>~y-KuE8fasjb1^qtBMTjtPqRLtGJet$amMoaiKi@6d4D)YIjX7+ZEoXtw#i*yr z>`0V3cId`r8N;g8*zt9@{d$~$aXfq6%9m-HL{$A8E~v3N=mD+uYwht#!vfjSAhiB* zzWs$8zL+W2AA$)4051}A&c!&h4g=tkfKvBcKgcn3;HkPe|zdP~Frp z1p8Zm6>O+_g|mnd6?~XP-NM;5D{IRqYF2cYyj?z7AZ~yz?W8wJO&}? zIhrlMA+(rFVr*T7h%44`r7cUsNFrn4#!Erx(Fv1IiX(C)wkO$m4#WJ2%gK)jsaAeO z{o|JMBieM|NCKmyAceoK``}vl;Q-wS)cwoS{a{mh;Yi)DeVjSfedeEUgwjx!!V&6! zb%_37Apl$$01&;+pP1SF?W8d=BgvCQD#XAALP$Z%6FvtB5>*7#QT$SWj#%M@bw@|| z0-2EvLn7p@P)Y)fhxUDegsXUhQWWJ1grOAAIal(PD-bY*d9fkP)^&*9z*Ea@W=8TF zN$9GmiiGP`RfIdOc{DIhY^Z|Cji+gX1jg8bqlPL{8zV+w*-%A-0d`bD^P_DIqV3_h zqY5*Vl*yf$7JQ?pirZdo2BwKV2kfeHiggo=oioL7jRPUJRl(v3r)^ajKj(egkPG05 z&|%|D+fKvYDi;(!WO}(njJ{`Y6($VDAY3+Ak>WPHt3=pd1)Tsp*CF}=PA&!!nIQ;n zGM7lOp0`Mt)5>b?Nn(E$?5}c)P6FuX0!b zgv(wl`cuTZC#*&~#wlo~N21eKEBAaH6MXwMOC1GEi}u??spXMsc0K}S66&Kq95wv>%lAcWd<(NYN|UPr5OZLJ z$ute3WOg<9>&tH+-N7%{7e5D)|C9KgW&XktpGflZ=xQ)8iset2mk$pQB!0~OBF#t~ z-IF}L{GT7k{-tPiIk>(sjOPXdzwpb~Hm~|ckwugHA~X_z5nc@@{`BiCOYf6lux_Su7dF>_h5bHw)2Uxr!T>|&Ybk!VspF87)ouv7kh)@IWx7mbqH z^@m@r59_bAd0}U(>5Cq8QY`#z7A5O_V z6`3Cu`)(#_8i#(e_Eco|VS7LM)Q`oKIo1_uZ~ZPRiuAv^ZepAqtB5`1`TpGKt-Oz}EI3wb}m`<#b)Ztn}3uvFMF=0@h0$}jY2y4JDe7q?tL!& zB=EDq_-Ndw@#DXvBpmFPU9sp!!PVfuW_66}y%H7$3hfQjGToj`KD6q6-ana#Oiw0t z%bDnapUmQLZQUmJkP*+ZN0f>Gia#c`+xc6HK^U*T_}SfQdYiIi?^AZVLCf(HARUfZ z=&(O#J7h3z3F~?B7>9N1VRFCNi`$o&&I>;)#(tKi4~K0tY1`vCOlHRi$Ch_;@&vT> z5hj7AA=+BjH$XcV(!;ZUaSdc=Als+(djqI}EU3YdY6LZtc=iy)pOGWtb!fK^+At0m z<7t{D`}9FYXIAD9r{9ZIbCXzgJw>3tT7eC|@l&t7KL7)`F6lj_tuXL_~qQctuRlPz=gBj?DEqgk>D zn@`XVN8wB_jhBCPk{(N*^f@;qtKQ>SaERP?x&G%bNNK`~-)J!=7-TFE_WydfKuc z7gudyx3NdE(4C)h+wLlkP*i(0%9$-G`#?gX{;{kJ24)=0WtsMN-+<0u$t#xQK7vVhBQbg4dM!DkfWUj@f{7) zUeeRPL&$@W2X)AU90iNH)~cQr5%QjhPzQBAwGK5mK!pdn5ON`W{(*7_h9LN2713waV;h|<^LLKIZsC(}-bD)l}BNU`AO-EbkS`00)eQL2Ir z=~so|nJh#*kcF`72gy(m$PiPom{aY#5Nw4Z+KDhkPYFX<`h#Q$$&gYqROd5YmHto# zTZFr*{b7~jAL?NB&%2~ISpK7p;vCA7q_@I4Lq>F7@8IPF$%bqs(j!x(Czj?Esn(rF z0@S+0ub3n0d{mjGG5-R5RGFqB>er*n6h3UkdeOd|T7d&oox2?ZW-brRZU?~ZJ^{0* z9hlvd!0aM0BQPT{_Xe0P8DQqG1k8>+Fhdt9Gi-Ba(4REJ>8u$rZANrPbnXv2J2L3( zy%IXR3edTWycxEMGw9Ep;dJT@m^&jnBRco!qJ}8}&viwLb)`s2*B5|A>>nF; zhYx|c%mz9FkAO`r;nZ>MwuJy)%2CTKEz)Tk$EguShQD0K(bWG(oQJSWW$H_`2=kAB zrVBs$A=Ih;iHFLR5@qVp1QnnLDnM&mQJQD&3LVPCVgwGc0ch#g=>=N+o)oKX zE(j6IAObL-=nN#N8j#?6L4py}bj!z+Z9sw((}LB`IJ*}hvE2)Y;2;YQ9KoS8aF8w* z06`8doxnhe#RS)&j4*eTJ#fJ_s70U`!0=mqpXaF&gpm>WMTGDm0T0!=hR~pMhb)uc zL~pjPsW}T7KAHr|x*Z^NR2BuVYIvScLM@_FwNnjql=ZTbNTZAA`z82O8V5hhqc?H=?I<

r@7wI2))sxu7nKx;nk$mio+Z#rJ?>axpSUL#m< z@#5uQ?Fl(Qnvc`Ay?)F4yA&-k(whc7alUn47Iuj1i8E+DZAlT7&vsqmv?p6q@^tz& zEby97`z59}!*Gq!y2i+FQ**Q~GO*r6yk2Ce*V!Ud?N&n~iynex(NFEobLuGQ6crqH;H@@VSgk|QTGAg$?W$+6`3Fmb&)L%Aiv z+2{<+>`G^-^=iKXGvAZYa9(+d*F}Aa+d+Ma3c2AwVeyb=Uq$GBeu#?c-1z*sn51!2 z49ag2VtQ}*33PYE&vI)}2RHnb=+Zei{A6$MhM(QsF7qyqmg9MvMgNEl!jF%7x%1;( z#*LWig-C|9Ia&HaP)*JDZ~AF7+h$6``Oj2*Fgp^?Ohq_T{oxF|aMu1X6NxTiIAb_# z4Ch~sKcXNi(gzXKw>M4kY$=FmraheLE}A|4!OZ#@%N%3*$BX4Nu7SxvdEL}3wSZgI vS_I!kt>t}P_^Qt_yz+G(CajNR|1r$2FV+X*cb55!>x=&b=sGwSiOK)~C|)dV diff --git a/network.tex b/network.tex index 2427690..ed310b1 100644 --- a/network.tex +++ b/network.tex @@ -192,7 +192,7 @@ dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection} Livello 4&\textit{Transport} &\textsl{Trasporto} \\ Livello 3&\textit{Network} &\textsl{Rete}\\ Livello 2&\textit{DataLink} &\textsl{Collegamento Dati} \\ - Livello 1&\textit{Connection} &\textsl{Connessione Fisica} \\ + Livello 1&\textit{Physical} &\textsl{Connessione Fisica} \\ \hline \end{tabular} \caption{I sette livelli del protocollo ISO/OSI.} @@ -200,14 +200,41 @@ dal 1984 il Modello di Riferimento \textit{Open Systems Interconnection} \end{table} Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della -serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante il -lavoro dettagliato di standardizzazione il modello si è rivelato -sostanzialmente troppo complesso e poco flessibile rispetto a quello -precedente, il TCP/IP, su cui si basa internet, che è diventato uno standard -de facto. Il modello di quest'ultimo viene chiamato anche modello DoD (sigla -che sta per \textit{Department of Defense}), dato che fu sviluppato -dall'agenzia ARPA per il Dipartimento della Difesa Americano. +serie di protocolli X.25 per la commutazione di pacchetto; come si vede è un +modello abbastanza complesso\footnote{infatti per memorizzarne i vari livelli + è stata creata la frase \texttt{All people seem to need data processing}, in + cui ciascuna parola corrisponde all'iniziale di uno dei livelli.}, tanto che +usualmente si tende a suddividerlo in due parti, secondo lo schema mostrato in +\figref{fig:net_osi_tcpip_comp}, con un \textit{upper layer} che riguarda solo +le applicazioni, che viene realizzato in user space, ed un \textit{lower + layer} in cui si mescolano la gestione fatta dal kernel e le funzionalità +fornite dall'hardware. + +Il modello ISO/OSI mira ad effettuare una classificazione completamente +generale di ogni tipo di protocollo di rete; nel frattempo però era stato +sviluppato anche un altro modello, relativo al protocollo TCP/IP, che è quello +su cui è basata internet, che è diventato uno standard de facto. Questo +modello viene talvolta chiamato anche modello \textit{DoD} (sigla che sta per +\textit{Department of Defense}), dato che fu sviluppato dall'agenzia ARPA per +il Dipartimento della Difesa Americano. +\begin{figure}[!htb] + \centering + \includegraphics[width=13cm]{img/iso_tcp_comp} + \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la + relative corrispondenze e la divisione fra kernel e user space.} + \label{fig:net_osi_tcpip_comp} +\end{figure} + +La scelta fra quale dei due modelli utilizzare dipende per lo più dai gusti +personali. Come caratteristiche generali il modello ISO/OSI è più teorico e +generico, basato separazioni funzionali, mentre il modello TCP/IP è più vicino +alla separazione concreta dei vari strati del sistema operativo; useremo +pertanto quest'ultimo, anche per la sua maggiore semplicità.\footnote{questa + semplicità ha un costo quando si fa riferimento agli strati più bassi, che + sono in effetti descritti meglio dal modello ISO/OSI, in quanto gran parte + dei protocolli di trasmissione hardware sono appunto strutturati sui due + livelli di \textit{Data Link} e \textit{Connection}.} \subsection{Il modello TCP/IP (o DoD)} \label{sec:net_tcpip_overview} @@ -216,10 +243,11 @@ Cos (riassunti in \tabref{tab:net_layers}); un confronto fra i due è riportato in \figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno -ad inserirsi all'interno di un sistema rispetto alla divisione fra user space -e kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà - è possibile accedere, attraverso una opportuna interfaccia (come vedremo in - \secref{sec:sock_sa_packet}), anche ai livelli inferiori.} +ad inserirsi all'interno del sistema rispetto alla divisione fra user space e +kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà è + sempre possibile accedere dallo user space, attraverso una opportuna + interfaccia (come vedremo in \secref{sec:sock_sa_packet}), ai livelli + inferiori del protocollo.} \begin{table}[htb] \centering @@ -267,14 +295,6 @@ copre il livello 2. Le funzioni dei vari livelli sono le seguenti: l'invio e la ricezione dei pacchetti da e verso l'hardware. \end{basedescript} -\begin{figure}[!htb] - \centering - \includegraphics[width=13cm]{img/iso_tcp_comp} - \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la - relative corrispondenze e la divisione fra kernel e user space.} - \label{fig:net_osi_tcpip_comp} -\end{figure} - La comunicazione fra due stazioni remote avviene secondo le modalità illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso dei dati reali e i protocolli usati per lo scambio di informazione su ciascun @@ -282,7 +302,7 @@ livello. Si se in realtà i protocolli di trasmissione usati possono essere molti altri. \begin{figure}[!htb] - \centering \includegraphics[width=12cm]{img/tcp_data_flux} + \centering \includegraphics[width=13cm]{img/tcp_data_flux} \caption{Strutturazione del flusso dei dati nella comunicazione fra due applicazioni attraverso i protocolli della suite TCP/IP.} \label{fig:net_tcpip_data_flux} @@ -304,7 +324,7 @@ la procedura si pu \item I dati delle applicazioni vengono inviati al livello di trasporto usando un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo in dettaglio in \capref{cha:socket_intro}). Qui verranno spezzati in - pacchetti di dimensione opportuna e incapsulati nel protocollo di trasporto, + pacchetti di dimensione opportuna e inseriti nel protocollo di trasporto, aggiungendo ad ogni pacchetto le informazioni necessarie per la sua gestione. Questo processo viene svolto direttamente nel kernel, ad esempio dallo stack TCP, nel caso il protocollo di trasporto usato sia questo. @@ -393,8 +413,8 @@ per il ruolo centrale che svolge nella maggior parte delle applicazioni. Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da molti membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che -mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni -reciproche e con alcune dalle principali applicazioni che li usano. +mostra un panorama sui principali protocolli della famiglia, e delle loro +relazioni reciproche e con alcune dalle principali applicazioni che li usano. \begin{figure}[!htbp] \centering diff --git a/process.tex b/process.tex index 1fbfc06..b484b17 100644 --- a/process.tex +++ b/process.tex @@ -1581,7 +1581,7 @@ un punto precedentemente stabilito con \func{setjmp} si usa la funzione \end{functions} La funzione ripristina il contesto dello stack salvato da una chiamata a -\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione +\func{setjmp} nell'argomento \param{env}. Dopo l'esecuzione della funzione il programma prosegue nel codice successivo al ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà il valore \param{val} invece di zero. Il valore di \param{val} specificato nella chiamata deve essere diverso @@ -1631,7 +1631,7 @@ e statiche mantengono i valori che avevano al momento della chiamata di Quello che succede infatti è che i valori delle variabili che sono tenute in memoria manterranno il valore avuto al momento della chiamata di \func{longjmp}, mentre quelli tenuti nei registri del processore (che nella -chiamata ad un'altra funzioni vengono salvati nel contesto nello stack) +chiamata ad un'altra funzione vengono salvati nel contesto nello stack) torneranno al valore avuto al momento della chiamata di \func{setjmp}; per questo quando si vuole avere un comportamento coerente si può bloccare l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come diff --git a/prochand.tex b/prochand.tex index 6beef58..97eeb50 100644 --- a/prochand.tex +++ b/prochand.tex @@ -196,7 +196,7 @@ coi processi che Il programma che un processo sta eseguendo si chiama immagine del processo (o \textit{process image}), le funzioni della famiglia \func{exec} permettono di -caricare un'altro programma da disco sostituendo quest'ultimo all'immagine +caricare un altro programma da disco sostituendo quest'ultimo all'immagine corrente; questo fa sì che l'immagine precedente venga completamente cancellata. Questo significa che quando il nuovo programma termina, anche il processo termina, e non si può tornare alla precedente immagine. @@ -240,9 +240,9 @@ disponibile a partire da un minimo di 300,\footnote{questi valori, fino al e direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato.} che serve a riservare i \acr{pid} più bassi -ai processi eseguiti dal direttamente dal kernel. Per questo motivo, come -visto in \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha -sempre il \acr{pid} uguale a uno. +ai processi eseguiti direttamente dal kernel. Per questo motivo, come visto +in \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il +\acr{pid} uguale a uno. Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui sono stati creati, questo viene chiamato in genere \acr{ppid} (da @@ -269,7 +269,7 @@ Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un candidato per generare ulteriori indicatori associati al processo di cui diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} -per generare un pathname univoco, che non potrà essere replicato da un'altro +per generare un pathname univoco, che non potrà essere replicato da un altro processo che usi la stessa funzione. Tutti i processi figli dello stesso processo padre sono detti @@ -307,7 +307,7 @@ prototipo della funzione zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di errore; \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un'altro + \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro processo (per allocare la tabella delle pagine e le strutture del task) o si è esaurito il numero di processi disponibili. \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le @@ -495,7 +495,7 @@ ciclo successivo), mentre la terza volta (fino alla conclusione) e poi il padre. In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di -scheduling usato dal kernel, dalla particolare situazione in si trova la +scheduling usato dal kernel, dalla particolare situazione in cui si trova la macchina al momento della chiamata, risultando del tutto impredicibile. Eseguendo più volte il programma di prova e producendo un numero diverso di figli, si sono ottenute situazioni completamente diverse, compreso il caso in @@ -572,7 +572,7 @@ figlio, troveremo nel file anche tutto quello che il processo padre aveva scritto prima della sua creazione. E alla fine del file (dato che in questo caso il padre esce per ultimo) troveremo anche l'output completo del padre. -L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file, +L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file, valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non solo processi diversi possono scrivere in contemporanea sullo stesso file (l'argomento della condivisione dei file è trattato in dettaglio in @@ -1105,8 +1105,8 @@ famiglia di funzioni) che possono essere usate per questo compito, in realt \begin{errlist} \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è montato in \cmd{noexec}, oppure non è un file regolare o un interprete. - \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non - è root, e o il processo viene tracciato, o il filesystem è montato con + \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente + non è root, il processo viene tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}. \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non riconosciuto come tale, o compilato per un'altra architettura. @@ -1208,7 +1208,7 @@ La seconda differenza fra le funzioni riguarda le modalit specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si indicano le due funzioni che replicano il comportamento della shell nello specificare il comando da eseguire; quando il parametro \param{file} non -contiene una \file{/} esso viene considerato come un nome di programma, e +contiene una ``\file{/}'' esso viene considerato come un nome di programma, e viene eseguita automaticamente una ricerca fra i file presenti nella lista di directory specificate dalla variabile di ambiente \var{PATH}. Il file che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore @@ -1299,8 +1299,8 @@ in genere questo \acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le \acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato -deve esse un valido programma (binario, non un altro script) che verrà -chiamato come se si fosse eseguito il comando \cmd{interpreter [arg] +deve esse un programma valido (binario, non un altro script) che verrà +chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti] filename}. Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è @@ -1429,7 +1429,7 @@ Questi identificatori normalmente sono identici ai corrispondenti del gruppo in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno impostati all'utente e al gruppo proprietari del file. Questo consente, per programmi in cui ci sia necessità, di dare a qualunque utente normale -privilegi o permessi di un'altro (o dell'amministratore). +privilegi o permessi di un altro (o dell'amministratore). Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi identificatori possono essere letti attraverso le rispettive funzioni: @@ -1460,11 +1460,11 @@ maggiori privilegi necessari, una volta che si siano effettuate le operazioni per i quali erano richiesti, e a poterli eventualmente recuperare in caso servano di nuovo. -Questo in Linux viene fatto usando altri gli altri due gruppi di -identificatori, il \textit{saved} ed il \textit{filesystem}. Il primo gruppo è -lo stesso usato in SVr4, e previsto dallo standard POSIX quando è definita la -costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la - portabilità del programma su altri Unix è buona norma controllare sempre la +Questo in Linux viene fatto usando altri due gruppi di identificatori, il +\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in +SVr4, e previsto dallo standard POSIX quando è definita la costante +\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità + del programma su altri Unix è buona norma controllare sempre la disponibilità di queste funzioni controllando se questa costante è definita.} il secondo gruppo è specifico di Linux e viene usato per migliorare la sicurezza con NFS. @@ -1473,7 +1473,7 @@ L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo, come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} -dopo che questo sono stati impostati tenendo conto di eventuali \acr{suid} o +dopo che questi sono stati impostati tenendo conto di eventuali \acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma. @@ -1578,22 +1578,23 @@ funzione avr consentendo l'accesso a \file{/var/log/utmp}. Occorre però tenere conto che tutto questo non è possibile con un processo con -i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid} -comporta il cambiamento di tutti gli identificatori associati al processo, -rendendo impossibile riguadagnare i privilegi di amministratore. Questo -comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea -una nuova shell per l'utente; ma quando si vuole cambiare soltanto +i privilegi di amministratore, in tal caso infatti l'esecuzione di una +\func{setuid} comporta il cambiamento di tutti gli identificatori associati al +processo, rendendo impossibile riguadagnare i privilegi di amministratore. +Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che +crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}). -\subsection{Le funzioni \func{setreuid} e \func{setresuid}} +\subsection{Le funzioni \func{setreuid} e \func{setregid}} \label{sec:proc_setreuid} -Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino - alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} gli -identificatori del gruppo \textit{saved}, le usa per poter scambiare fra di -loro \textit{effective} e \textit{real}. I loro prototipi sono: +Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non +supportando\footnote{almeno fino alla versione 4.3+BSD TODO, FIXME verificare + e aggiornare la nota.} gli identificatori del gruppo \textit{saved}, le usa +per poter scambiare fra di loro \textit{effective} e \textit{real}. I +rispettivi prototipi sono: \begin{functions} \headdecl{unistd.h} \headdecl{sys/types.h} @@ -1642,12 +1643,13 @@ corrente, l'user-ID salvato viene automaticamente uniformato al valore dell'user-ID effettivo. -\subsection{Le funzioni \funcd{seteuid} e \funcd{setegid}} +\subsection{Le funzioni \func{seteuid} e \func{setegid}} \label{sec:proc_seteuid} -Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque -supportate dalla maggior parte degli Unix) e vengono usate per cambiare gli -identificatori del gruppo \textit{effective}; i loro prototipi sono: +Le due funzioni \funcd{seteuid} e \funcd{setegid} sono un'estensione allo +standard POSIX.1 (ma sono comunque supportate dalla maggior parte degli Unix) +e vengono usate per cambiare gli identificatori del gruppo \textit{effective}; +i loro prototipi sono: \begin{functions} \headdecl{unistd.h} \headdecl{sys/types.h} @@ -1670,12 +1672,13 @@ all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli identificatori. -\subsection{Le funzioni \funcd{setresuid} e \funcd{setresgid}} +\subsection{Le funzioni \func{setresuid} e \func{setresgid}} \label{sec:proc_setresuid} -Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44, -e permettono un completo controllo su tutti gli identificatori (\textit{real}, -\textit{effective} e \textit{saved}), i prototipi sono: +Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono un'estensione +introdotta in Linux,\footnote{a partire dal kernel 2.1.44.} e permettono un +completo controllo su tutti e tre i gruppi di identificatori (\textit{real}, +\textit{effective} e \textit{saved}), i loro prototipi sono: \begin{functions} \headdecl{unistd.h} \headdecl{sys/types.h} @@ -1722,7 +1725,7 @@ corrente. Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono nessun privilegio. I valori sono restituiti negli argomenti, che vanno -specificati come puntatori (è un'altro esempio di \textit{value result +specificati come puntatori (è un altro esempio di \textit{value result argument}). Si noti che queste funzioni sono le uniche in grado di leggere gli identificatori del gruppo \textit{saved}. @@ -1730,25 +1733,26 @@ gli identificatori del gruppo \textit{saved}. \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}} \label{sec:proc_setfsuid} -Queste funzioni sono usate per impostare gli identificatori del gruppo -\textit{filesystem} che usati da Linux per il controllo dell'accesso ai file. -Come già accennato in \secref{sec:proc_access_id} Linux definisce questo -ulteriore gruppo di identificatori, che di norma sono assolutamente -equivalenti a quelli del gruppo \textit{effective}, dato che ogni cambiamento -di questi ultimi viene immediatamente riportato su di essi. +Queste funzioni servono per impostare gli identificatori del gruppo +\textit{filesystem} che sono usati da Linux per il controllo dell'accesso ai +file. Come già accennato in \secref{sec:proc_access_id} Linux definisce +questo ulteriore gruppo di identificatori, che in circostanze normali sono +assolutamente equivalenti a quelli del gruppo \textit{effective}, dato che +ogni cambiamento di questi ultimi viene immediatamente riportato su di essi. C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per ovviare ad un problema di sicurezza che si presenta quando si deve -implementare un server NFS. Il server NFS infatti deve poter cambiare -l'identificatore con cui accede ai file per assumere l'identità del singolo -utente remoto, ma se questo viene fatto cambiando l'user-ID effettivo o -l'user-ID reale il server si espone alla ricezione di eventuali segnali ostili -da parte dell'utente di cui ha temporaneamente assunto l'identità. Cambiando -solo l'user-ID di filesystem si ottengono i privilegi necessari per accedere ai -file, mantenendo quelli originari per quanto riguarda tutti gli altri -controlli di accesso, così che l'utente non possa inviare segnali al server -NFS. +implementare un server NFS. + +Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai +file per assumere l'identità del singolo utente remoto, ma se questo viene +fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla +ricezione di eventuali segnali ostili da parte dell'utente di cui ha +temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si +ottengono i privilegi necessari per accedere ai file, mantenendo quelli +originari per quanto riguarda tutti gli altri controlli di accesso, così che +l'utente non possa inviare segnali al server NFS. Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid} e \funcd{setfsgid}, ovviamente sono specifiche di Linux e non devono essere @@ -1807,7 +1811,7 @@ specifica un valore di \param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il numero di gruppi supplementari. Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per -ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è: +ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{grp.h} @@ -1819,12 +1823,12 @@ ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo restituisce 0 in caso di successo e -1 in caso di fallimento.} \end{functions} -La funzione legge i gruppi supplementari dell'utente \param{user} eseguendo -una scansione del database dei gruppi (si veda \secref{sec:sys_user_group}) e -ritorna in \param{groups} la lista di quelli a cui l'utente appartiene. Si -noti che \param{ngroups} è passato come puntatore perché qualora il valore -specificato sia troppo piccolo la funzione ritorna -1, passando indietro il -numero dei gruppi trovati. +La funzione legge i gruppi supplementari dell'utente specificato da +\param{user}, eseguendo una scansione del database dei gruppi (si veda +\secref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di quelli +a cui l'utente appartiene. Si noti che \param{ngroups} è passato come +puntatore perché, qualora il valore specificato sia troppo piccolo, la +funzione ritorna -1, passando indietro il numero dei gruppi trovati. Per impostare i gruppi supplementari di un processo ci sono due funzioni, che possono essere usate solo se si hanno i privilegi di amministratore. La prima @@ -1876,7 +1880,8 @@ con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche \func{setgroups}. Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si -compila con il flag \cmd{-ansi}. +compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole +scrivere codice portabile. \section{La gestione della priorità di esecuzione} @@ -1944,7 +1949,7 @@ fintanto che esso si trova in uno qualunque degli altri stati. \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad essere eseguito (cioè è in attesa che gli venga assegnata la CPU). \\ - \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un + \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un risposta dal sistema, ma può essere interrotto da un segnale. \\ \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in @@ -2026,7 +2031,7 @@ essere eseguito, e quando un processo potr nell'esecuzione. Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è -assegnata una \textit{time-slice}, cioè in intervallo di tempo (letteralmente +assegnata una \textit{time-slice}, cioè un intervallo di tempo (letteralmente una fetta) per il quale esso deve essere eseguito. Il valore della \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o \textit{niceness}) del processo. Essa è contenuta nel campo \var{nice} di @@ -2050,13 +2055,13 @@ verranno messi in esecuzione. La priorità di un processo è così controllata attraverso il valore di \var{nice}, che stabilisce la durata della \textit{time-slice}; per il -meccanismo appena descritto infatti un valore più lungo infatti assicura una -maggiore attribuzione di CPU. L'origine del nome di questo parametro sta nel -fatto che generalmente questo viene usato per diminuire la priorità di un -processo, come misura di cortesia nei confronti degli altri. I processi -infatti vengono creati dal sistema con lo stesso valore di \var{nice} (nullo) -e nessuno è privilegiato rispetto agli altri; il valore può essere modificato -solo attraverso la funzione \funcd{nice}, il cui prototipo è: +meccanismo appena descritto infatti un valore più lungo assicura una maggiore +attribuzione di CPU. L'origine del nome di questo parametro sta nel fatto che +generalmente questo viene usato per diminuire la priorità di un processo, come +misura di cortesia nei confronti degli altri. I processi infatti vengono +creati dal sistema con lo stesso valore di \var{nice} (nullo) e nessuno è +privilegiato rispetto agli altri; il valore può essere modificato solo +attraverso la funzione \funcd{nice}, il cui prototipo è: \begin{prototype}{unistd.h} {int nice(int inc)} Aumenta il valore di \var{nice} per il processo corrente. @@ -2193,7 +2198,7 @@ Quando c' metterà in esecuzione prima di ogni processo normale. In caso di più processi sarà eseguito per primo quello con priorità assoluta più alta. Quando ci sono più processi con la stessa priorità assoluta questi vengono tenuti in una coda -tocca al kernel decidere quale deve essere eseguito. +e tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui vengono gestiti questi processi dipende dalla politica di scheduling che si è scelto; lo standard ne prevede due: @@ -2326,7 +2331,7 @@ La priorit \end{errlist}} \end{prototype} -La funzione restituisce il valore (secondo la quanto elencato in +La funzione restituisce il valore (secondo quanto elencato in \tabref{tab:proc_sched_policy}) della politica di scheduling per il processo specificato; se \param{pid} è nullo viene restituito quello del processo chiamante. @@ -2475,7 +2480,7 @@ processo che accede alla stessa risorsa quando ancora non tutti i passi sono stati completati. Dato che in un sistema multitasking ogni processo può essere interrotto in -qualunque momento per farne subentrare un'altro in esecuzione, niente può +qualunque momento per farne subentrare un altro in esecuzione, niente può assicurare un preciso ordine di esecuzione fra processi diversi o che una sezione di un programma possa essere eseguita senza interruzioni da parte di altri. Queste situazioni comportano pertanto errori estremamente subdoli e diff --git a/ringraziamenti.tex b/ringraziamenti.tex index 12a76c0..9861b1f 100644 --- a/ringraziamenti.tex +++ b/ringraziamenti.tex @@ -21,6 +21,9 @@ GaPiL. In ordine rigorosamente alfabetico desidero citare: correzioni, i consigli sull'esposizione ed i contributi relativi alle calling convention dei linguaggi e al confronto delle diverse tecniche di gestione della memoria. +\item[\textbf{Mirko Maischberger}] per la rilettura, le numerose correzioni, + la segnalazione dei passi poco chiari ed il grande lavoro svolto per + produrre una versione della guida in un HTML piacevole ed accurato. \end{description} Infine, ultimo, ma primo per importanza, voglio ringraziare il Firenze Linux diff --git a/system.tex b/system.tex index a8174db..924935a 100644 --- a/system.tex +++ b/system.tex @@ -42,7 +42,7 @@ quelle della gestione dei file. \subsection{Limiti e parametri di sistema} \label{sec:sys_limits} -Quando si devono determinare le le caratteristiche generali del sistema ci si +Quando si devono determinare le caratteristiche generali del sistema ci si trova di fronte a diverse possibilità; alcune di queste infatti possono dipendere dall'architettura dell'hardware (come le dimensioni dei tipi interi), o dal sistema operativo (come la presenza o meno del gruppo degli @@ -606,7 +606,7 @@ Legge o scrive uno dei parametri di sistema. \end{functions} I parametri a cui la funzione permettere di accedere sono organizzati in -maniera gerarchica all'interno un albero;\footnote{si tenga presente che +maniera gerarchica all'interno di un albero;\footnote{si tenga presente che includendo solo \file{unistd.h}, saranno definiti solo i parametri generici; dato che ce ne sono molti specifici dell'implementazione, nel caso di Linux occorrerà includere anche i file \file{linux/unistd.h} e @@ -620,7 +620,7 @@ arriva ad identificare un parametro specifico attraverso l'array \param{name}, di lunghezza \param{nlen}, che contiene la sequenza dei vari nodi da attraversare. Ogni parametro ha un valore in un formato specifico che può essere un intero, una stringa o anche una struttura -complessa, per questo motivo il valori vengono passati come puntatori +complessa, per questo motivo i valori vengono passati come puntatori \ctyp{void}. L'indirizzo a cui il valore corrente del parametro deve essere letto è @@ -1467,7 +1467,7 @@ detto \textsl{duro} (o \textit{hard limit}), in quanto un processo normale non può modificarne il valore. Il valore di questi limiti è mantenuto in una struttura \struct{rlimit}, la cui definizione è riportata in \figref{fig:sys_rlimit_struct}, ed i cui campi corrispondono appunto a limite -corrente e massimo. +corrente e limite massimo. \begin{figure}[!htb] \footnotesize @@ -1836,7 +1836,6 @@ lo stato di terminazione di tutti i suoi figli, questi processi ``nipoti'' non verranno considerati nel calcolo di questi tempi. - \subsection{Le funzioni per il \textit{calendar time}} \label{sec:sys_time_base} @@ -1845,8 +1844,8 @@ mantenuto dal kernel in una variabile di tipo \type{time\_t}, che usualmente corrisponde ad un tipo elementare (in Linux è definito come \ctyp{long int}, che di norma corrisponde a 32 bit). Il valore corrente del \textit{calendar time}, che indicheremo come \textsl{tempo di sistema}, può essere ottenuto -con la funzione \funcd{time} che lo restituisce in nel suddetto formato; il -suo prototipo è: +con la funzione \funcd{time} che lo restituisce nel suddetto formato; il suo +prototipo è: \begin{prototype}{time.h}{time\_t time(time\_t *t)} Legge il valore corrente del \textit{calendar time}. -- 2.30.2