+\index{file!filesystem~\texttt {/proc}!definizione|(}
+
+Dato che fin dall'inizio i parametri erano organizzati in una struttura
+albero, è parso naturale rimappare questa organizzazione utilizzando il
+filesystem \file{/proc}. Questo è un filesystem completamente virtuale, il cui
+contenuto è generato direttamente dal kernel, che non fa riferimento a nessun
+dispositivo fisico, ma presenta in forma di file e directory i dati di alcune
+delle strutture interne del kernel stesso. Il suo utilizzo principale, come
+denuncia il nome stesso, è quello di fornire una interfaccia per ottenere i
+dati relativi ai processi (venne introdotto a questo scopo su BSD), ma nel
+corso del tempo il suo uso è stato ampliato.
+
+All'interno di questo filesystem sono pertanto presenti una serie di file che
+riflettono il contenuto dei parametri del kernel (molti dei quali accessibili
+in sola lettura) e in altrettante directory, nominate secondo il relativo
+\ids{PID}, vengono mantenute le informazioni relative a ciascun processo
+attivo nel sistema.
+
+In particolare l'albero dei valori dei parametri di sistema impostabili con
+\func{sysctl} viene presentato in forma di una gerarchia di file e directory a
+partire dalla directory \file{/proc/sys}, cosicché è possibile accedere al
+valore di un parametro del kernel tramite il \textit{pathname} ad un file
+sotto \file{/proc/sys} semplicemente leggendone il contenuto, così come si può
+modificare un parametro scrivendo sul file ad esso corrispondente.
+
+Il kernel si occupa di generare al volo il contenuto ed i nomi dei file
+corrispondenti ai vari parametri che sono presenti, e questo ha il grande
+vantaggio di rendere accessibili gli stessi ad un qualunque comando di shell e
+di permettere la navigazione dell'albero in modo da riconoscere quali
+parametri sono presenti senza dover cercare un valore all'interno di una
+pagina di manuale.
+
+Inizialmente l'uso del filesystem \file{/proc} serviva soltanto a replicare
+l'accesso, con altrettante corrispondenze ai file presenti in
+\file{/proc/sys}, ai parametri impostabili tradizionalmente con \func{sysctl},
+ma vista la assoluta naturalità dell'interfaccia, e la sua maggiore
+efficienza, nelle versioni più recenti del kernel questa è diventata la
+modalità canonica per modificare i parametri del kernel, evitando di dover
+ricorrere all'uso di una \textit{system call} specifica che pur essendo ancora
+presente, prima o poi verrà eliminata.
+
+Nonostante la semplificazione nella gestione ottenuta con l'uso di
+\file{/proc/sys} resta il problema generale di conoscere il significato di
+ciascuno degli innumerevoli parametri che vi si trovano. Purtroppo la
+documentazione degli stessi spesso risulta incompleta e non aggiornata, ma
+buona parte di quelli può importanti sono descritti dalla documentazione
+inclusa nei sorgenti del kernel, nella directory \file{Documentation/sysctl}.
+
+Ma oltre alle informazioni che sostituiscono quelle ottenibili dalla ormai
+deprecata \func{sysctl} dentro \file{/proc} sono disponibili moltissime altre
+informazioni, fra cui ad esempio anche quelle fornite dalla funzione di
+sistema \funcd{uname},\footnote{con Linux ci sono in realtà 3 \textit{system
+ call} diverse per le dimensioni delle stringhe restituite, le prime due
+ usano rispettivamente delle lunghezze di 9 e 65 byte, la terza usa anch'essa
+ 65 byte, ma restituisce anche l'ultimo campo, \var{domainname}, con una
+ lunghezza di 257 byte, la \acr{glibc} provvede a mascherare questi dettagli
+ usando la versione più recente disponibile.} il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/utsname.h}
+\fdecl{int uname(struct utsname *info)}
+\fdesc{Restituisce informazioni generali sul sistema.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} può assumere solo il valore \errval{EFAULT}.}
+\end{funcproto}
+
+La funzione, che viene usata dal comando \cmd{uname}, restituisce una serie di
+informazioni relative al sistema nelle stringhe che costituiscono i campi
+della struttura \struct{utsname} (la cui definizione è riportata in
+fig.~\ref{fig:sys_utsname}) che viene scritta nel buffer puntato
+dall'argomento \param{info}.
+
+\begin{figure}[!ht!b]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.85\textwidth}
+ \includestruct{listati/ustname.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{utsname}.}
+ \label{fig:sys_utsname}
+\end{figure}
+
+Si noti come in fig.~\ref{fig:sys_utsname} le dimensioni delle stringhe di
+\struct{utsname} non sono specificate. Il manuale della \acr{glibc} indica
+due costanti per queste dimensioni, \constd{\_UTSNAME\_LENGTH} per i campi
+standard e \constd{\_UTSNAME\_DOMAIN\_LENGTH} per quello relativo al nome di
+dominio, altri sistemi usano nomi diversi come \constd{SYS\_NMLN} o
+\constd{\_SYS\_NMLN} o \constd{UTSLEN} che possono avere valori diversi. Dato
+che il buffer per \struct{utsname} deve essere preallocato l'unico modo per
+farlo in maniera sicura è allora usare come dimensione il valore ottenuto con
+\code{sizeof(utsname)}.
+
+Le informazioni vengono restituite in ciascuno dei singoli campi di
+\struct{utsname} in forma di stringhe terminate dal carattere NUL. In
+particolare dette informazioni sono:
+\begin{itemize*}
+\item il nome del sistema operativo;
+\item il nome della macchine (l'\textit{hostname});
+\item il nome della release del kernel;
+\item il nome della versione del kernel;
+\item il tipo di hardware della macchina;
+\item il nome del domino (il \textit{domainname});
+\end{itemize*}
+ma l'ultima di queste informazioni è stata aggiunta di recente e non è
+prevista dallo standard POSIX, per questo essa è accessibile, come mostrato in
+fig.~\ref{fig:sys_utsname}, solo se si è definita la macro
+\macro{\_GNU\_SOURCE}.
+
+Come accennato queste stesse informazioni, anche se a differenza di
+\func{sysctl} la funzione continua ad essere mantenuta, si possono ottenere
+direttamente tramite il filesystem \file{/proc}, esse infatti sono mantenute
+rispettivamente nei file \sysctlrelfiled{kernel}{ostype},
+\sysctlrelfiled{kernel}{hostname}, \sysctlrelfiled{kernel}{osrelease},
+\sysctlrelfiled{kernel}{version} e \sysctlrelfiled{kernel}{domainname} che si
+trovano sotto la directory \file{/proc/sys/kernel/}.
+
+\index{file!filesystem~\texttt {/proc}!definizione|)}
+
+
+
+\section{La gestione del sistema}
+\label{sec:sys_management}
+
+In questa sezione prenderemo in esame le interfacce di programmazione messe a
+disposizione per affrontare una serie di tematiche attinenti la gestione
+generale del sistema come quelle relative alla gestione di utenti e gruppi, al
+trattamento delle informazioni relative ai collegamenti al sistema, alle
+modalità per effettuare lo spegnimento o il riavvio di una macchina.
+
+
+\subsection{La gestione delle informazioni su utenti e gruppi}
+\label{sec:sys_user_group}
+
+Tradizionalmente le informazioni utilizzate nella gestione di utenti e gruppi
+(password, corrispondenze fra nomi simbolici e \ids{UID} numerici, home
+directory, ecc.) venivano registrate all'interno dei due file di testo
+\conffiled{/etc/passwd} ed \conffiled{/etc/group}, il cui formato è descritto
+dalle relative pagine del manuale\footnote{nella quinta sezione, quella dei
+ file di configurazione (esistono comandi corrispondenti), una trattazione
+ sistemistica dell'intero argomento coperto in questa sezione si consulti
+ sez.~4.3 di \cite{AGL}.} e tutte le funzioni che richiedevano l'accesso a
+queste informazione andavano a leggere direttamente il contenuto di questi
+file.
+
+In realtà oltre a questi due file da molto tempo gran parte dei sistemi
+unix-like usano il cosiddetto sistema delle \textit{shadow password} che
+prevede anche i due file \conffiled{/etc/shadow} e \conffiled{/etc/gshadow}, in
+cui sono state spostate le informazioni di autenticazione (ed inserite alcune
+estensioni di gestione avanzata) per toglierle dagli altri file che devono
+poter essere letti da qualunque processo per poter effettuare l'associazione
+fra username e \ids{UID}.
+
+Col tempo però questa impostazione ha incominciato a mostrare dei limiti. Da
+una parte il meccanismo classico di autenticazione è stato ampliato, ed oggi
+la maggior parte delle distribuzioni di GNU/Linux usa la libreria PAM (sigla
+che sta per \textit{Pluggable Authentication Method}) che fornisce una
+interfaccia comune per i processi di autenticazione, svincolando completamente
+le singole applicazioni dai dettagli del come questa viene eseguita e di dove
+vengono mantenuti i dati relativi. Si tratta di un sistema modulare, in cui è
+possibile utilizzare anche più meccanismi insieme, diventa così possibile
+avere vari sistemi di riconoscimento (biometria, chiavi hardware, ecc.),
+diversi formati per le password e diversi supporti per le informazioni. Il
+tutto avviene in maniera trasparente per le applicazioni purché per ciascun
+meccanismo si disponga della opportuna libreria che implementa l'interfaccia
+di PAM.
+
+Dall'altra parte, il diffondersi delle reti e la necessità di centralizzare le
+informazioni degli utenti e dei gruppi per insiemi di macchine e servizi
+all'interno di una stessa organizzazione, in modo da mantenere coerenti i
+dati, ha portato anche alla necessità di poter recuperare e memorizzare dette
+informazioni su supporti diversi dai file citati, introducendo il sistema del
+\textit{Name Service Switch} (che tratteremo brevemente in
+sez.~\ref{sec:sock_resolver}) dato che la sua applicazione è cruciale nella
+procedura di risoluzione di nomi di rete.
+
+In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche
+per la lettura delle informazioni relative a utenti e gruppi tralasciando
+completamente quelle relative all'autenticazione.
+% Per questo non tratteremo
+% affatto l'interfaccia di PAM, ma approfondiremo invece il sistema del
+% \textit{Name Service Switch}, un meccanismo messo a disposizione dalla
+% \acr{glibc} per modularizzare l'accesso a tutti i servizi in cui sia
+% necessario trovare una corrispondenza fra un nome ed un numero (od altra
+% informazione) ad esso associato, come appunto, quella fra uno username ed un
+% \ids{UID} o fra un \ids{GID} ed il nome del gruppo corrispondente.
+Le prime funzioni che vedremo sono quelle previste dallo standard POSIX.1;
+queste sono del tutto generiche e si appoggiano direttamente al \textit{Name
+ Service Switch}, per cui sono in grado di ricevere informazioni qualunque
+sia il supporto su cui esse vengono mantenute. Per leggere le informazioni
+relative ad un utente si possono usare due funzioni, \funcd{getpwuid} e
+\funcd{getpwnam}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{pwd.h}
+\fhead{sys/types.h}
+\fdecl{struct passwd *getpwuid(uid\_t uid)}
+\fdecl{struct passwd *getpwnam(const char *name)}
+\fdesc{Restituiscono le informazioni relative all'utente specificato.}
+}
+
+{Le funzioni ritornano il puntatore alla struttura contenente le informazioni
+ in caso di successo e \val{NULL} nel caso non sia stato trovato nessun
+ utente corrispondente a quanto specificato, nel qual caso \var{errno}
+ assumerà il valore riportato dalle funzioni di sistema sottostanti.}
+\end{funcproto}
+
+Le due funzioni forniscono le informazioni memorizzate nel registro degli
+utenti (che nelle versioni più recenti per la parte di credenziali di
+autenticazione vengono ottenute attraverso PAM) relative all'utente
+specificato attraverso il suo \ids{UID} o il nome di login. Entrambe le
+funzioni restituiscono un puntatore ad una struttura di tipo \struct{passwd}
+la cui definizione (anch'essa eseguita in \headfiled{pwd.h}) è riportata in
+fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente illustrato il
+significato dei vari campi.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/passwd.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{passwd} contenente le informazioni relative
+ ad un utente del sistema.}
+ \label{fig:sys_passwd_struct}
+\end{figure}
+
+La struttura usata da entrambe le funzioni è allocata staticamente, per questo
+motivo viene sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la
+memoria dove sono scritte le stringhe a cui i puntatori in essa contenuti
+fanno riferimento. Ovviamente questo implica che dette funzioni non possono
+essere rientranti; per questo motivo ne esistono anche due versioni
+alternative (denotate dalla solita estensione \code{\_r}), i cui prototipi
+sono:
+
+\begin{funcproto}{
+\fhead{pwd.h}
+\fhead{sys/types.h}
+\fdecl{struct passwd *getpwuid\_r(uid\_t uid, struct passwd *password,
+ char *buffer,\\
+\phantom{struct passwd *getpwuid\_r(}size\_t buflen, struct passwd **result)}
+\fdecl{struct passwd *getpwnam\_r(const char *name, struct passwd
+ *password, char *buffer,\\
+\phantom{struct passwd *getpwnam\_r(}size\_t buflen, struct passwd **result)}
+\fdesc{Restituiscono le informazioni relative all'utente specificato.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore riportato dalle di sistema funzioni
+ sottostanti.}
+\end{funcproto}
+
+In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare
+la memoria necessaria a contenere le informazioni. In particolare i valori
+della struttura \struct{passwd} saranno restituiti all'indirizzo
+\param{password} mentre la memoria allocata all'indirizzo \param{buffer}, per
+un massimo di \param{buflen} byte, sarà utilizzata per contenere le stringhe
+puntate dai campi di \param{password}. Infine all'indirizzo puntato da
+\param{result} viene restituito il puntatore ai dati ottenuti, cioè
+\param{buffer} nel caso l'utente esista, o \val{NULL} altrimenti. Qualora i
+dati non possano essere contenuti nei byte specificati da \param{buflen}, la
+funzione fallirà restituendo \errcode{ERANGE} (e \param{result} sarà comunque
+impostato a \val{NULL}).
+
+Sia queste versioni rientranti che precedenti gli errori eventualmente
+riportati in \var{errno} in caso di fallimento dipendono dalla sottostanti
+funzioni di sistema usate per ricavare le informazioni (si veda quanto
+illustrato in sez.~\ref{sec:sys_errno}) per cui se lo si vuole utilizzare è
+opportuno inizializzarlo a zero prima di invocare le funzioni per essere
+sicuri di non avere un residuo di errore da una chiamata precedente. Il non
+aver trovato l'utente richiesto infatti può essere dovuto a diversi motivi (a
+partire dal fatto che non esista) per cui si possono ottenere i valori di
+errore più vari a seconda dei casi.
+
+Del tutto analoghe alle precedenti sono le funzioni \funcd{getgrnam} e
+\funcd{getgrgid} che permettono di leggere le informazioni relative ai gruppi,
+i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{grp.h}
+\fhead{sys/types.h}
+\fdecl{struct group *getgrgid(gid\_t gid)}
+\fdecl{struct group *getgrnam(const char *name)}
+\fdesc{Restituiscono le informazioni relative al gruppo specificato.}
+}
+
+{Le funzioni ritornano il puntatore alla struttura contenente le informazioni
+ in caso di successo e \val{NULL} nel caso non sia stato trovato nessun
+ utente corrispondente a quanto specificato, nel qual caso \var{errno}
+ assumerà il valore riportato dalle funzioni di sistema sottostanti.}
+\end{funcproto}
+
+Come per le precedenti per gli utenti esistono anche le analoghe versioni
+rientranti che di nuovo utilizzano la stessa estensione \code{\_r}; i loro
+prototipi sono:
+
+\begin{funcproto}{
+\fhead{grp.h}
+\fhead{sys/types.h}
+\fdecl{int getgrgid\_r(gid\_t gid, struct group *grp, char *buf,
+ size\_t buflen,\\
+\phantom{int getgrgid\_r(}struct group **result)}
+\fdecl{int getgrnam\_r(const char *name, struct group *grp, char *buf,
+ size\_t buflen,\\
+\phantom{int getgrnam\_r(}struct group **result)}
+\fdesc{Restituiscono le informazioni relative al gruppo specificato.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore riportato dalle funzioni di sistema
+ sottostanti.}
+\end{funcproto}
+
+Il comportamento di tutte queste funzioni è assolutamente identico alle
+precedenti che leggono le informazioni sugli utenti, l'unica differenza è che
+in questo caso le informazioni vengono restituite in una struttura di tipo
+\struct{group}, la cui definizione è riportata in
+fig.~\ref{fig:sys_group_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/group.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{group} contenente le informazioni relative ad
+ un gruppo del sistema.}
+ \label{fig:sys_group_struct}
+\end{figure}
+
+Le funzioni viste finora sono in grado di leggere le informazioni sia
+direttamente dal file delle password in \conffile{/etc/passwd} che tramite il
+sistema del \textit{Name Service Switch} e sono completamente generiche. Si
+noti però che non c'è una funzione che permetta di impostare direttamente una
+password.\footnote{in realtà questo può essere fatto ricorrendo alle funzioni
+ della libreria PAM, ma questo non è un argomento che tratteremo qui.} Dato
+che POSIX non prevede questa possibilità esiste un'altra interfaccia che lo
+fa, derivata da SVID le cui funzioni sono riportate in
+tab.~\ref{tab:sys_passwd_func}. Questa interfaccia però funziona soltanto
+quando le informazioni sono mantenute su un apposito file di \textsl{registro}
+di utenti e gruppi, con il formato classico di \conffile{/etc/passwd} e
+\conffile{/etc/group}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Funzione} & \textbf{Significato}\\
+ \hline
+ \hline
+ \funcm{fgetpwent} & Legge una voce dal file di registro degli utenti
+ specificato.\\
+ \funcm{fgetpwent\_r}& Come la precedente, ma rientrante.\\
+ \funcm{putpwent} & Immette una voce in un file di registro degli
+ utenti.\\
+ \funcm{getpwent} & Legge una voce da \conffile{/etc/passwd}.\\
+ \funcm{getpwent\_r} & Come la precedente, ma rientrante.\\
+ \funcm{setpwent} & Ritorna all'inizio di \conffile{/etc/passwd}.\\
+ \funcm{endpwent} & Chiude \conffile{/etc/passwd}.\\
+ \funcm{fgetgrent} & Legge una voce dal file di registro dei gruppi
+ specificato.\\
+ \funcm{fgetgrent\_r}& Come la precedente, ma rientrante.\\
+ \funcm{putgrent} & Immette una voce in un file di registro dei gruppi.\\
+ \funcm{getgrent} & Legge una voce da \conffile{/etc/group}.\\
+ \funcm{getgrent\_r} & Come la precedente, ma rientrante.\\
+ \funcm{setgrent} & Ritorna all'inizio di \conffile{/etc/group}.\\
+ \funcm{endgrent} & Chiude \conffile{/etc/group}.\\
+ \hline
+ \end{tabular}
+ \caption{Funzioni per la manipolazione dei campi di un file usato come
+ registro per utenti o gruppi nel formato di \conffile{/etc/passwd} e
+ \conffile{/etc/group}.}
+ \label{tab:sys_passwd_func}
+\end{table}
+
+% TODO mancano i prototipi di alcune delle funzioni
+
+Dato che oramai tutte le distribuzioni di GNU/Linux utilizzano le
+\textit{shadow password} (quindi con delle modifiche rispetto al formato
+classico del file \conffile{/etc/passwd}), si tenga presente che le funzioni
+di questa interfaccia che permettono di scrivere delle voci in un
+\textsl{registro} degli utenti (cioè \func{putpwent} e \func{putgrent}) non
+hanno la capacità di farlo specificando tutti i contenuti necessari rispetto a
+questa estensione.
+
+Per questo motivo l'uso di queste funzioni è deprecato, in quanto comunque non
+funzionale rispetto ad un sistema attuale, pertanto ci limiteremo a fornire
+soltanto l'elenco di tab.~\ref{tab:sys_passwd_func}, senza nessuna spiegazione
+ulteriore. Chi volesse insistere ad usare questa interfaccia può fare
+riferimento alle pagine di manuale delle rispettive funzioni ed al manuale
+della \acr{glibc} per i dettagli del funzionamento.
+
+
+
+\subsection{Il registro della \textsl{contabilità} degli utenti}
+\label{sec:sys_accounting}
+
+Un altro insieme di funzioni relative alla gestione del sistema che
+esamineremo è quello che permette di accedere ai dati del registro della
+cosiddetta \textsl{contabilità} (o \textit{accounting}) degli utenti. In esso
+vengono mantenute una serie di informazioni storiche relative sia agli utenti
+che si sono collegati al sistema, tanto per quelli correntemente collegati,
+che per la registrazione degli accessi precedenti, sia relative all'intero
+sistema, come il momento di lancio di processi da parte di \cmd{init}, il
+cambiamento dell'orologio di sistema, il cambiamento di runlevel o il riavvio
+della macchina.
+
+I dati vengono usualmente memorizzati nei due file \file{/var/run/utmp} e
+\file{/var/log/wtmp}. che sono quelli previsti dal \textit{Linux Filesystem
+ Hierarchy Standard}, adottato dalla gran parte delle distribuzioni. Quando
+un utente si collega viene aggiunta una voce a \file{/var/run/utmp} in cui
+viene memorizzato il nome di login, il terminale da cui ci si collega,
+l'\ids{UID} della shell di login, l'orario della connessione ed altre
+informazioni. La voce resta nel file fino al logout, quando viene cancellata
+e spostata in \file{/var/log/wtmp}.
+
+In questo modo il primo file viene utilizzato per registrare chi sta
+utilizzando il sistema al momento corrente, mentre il secondo mantiene la
+registrazione delle attività degli utenti. A quest'ultimo vengono anche
+aggiunte delle voci speciali per tenere conto dei cambiamenti del sistema,
+come la modifica del runlevel, il riavvio della macchina, ecc. Tutte queste
+informazioni sono descritte in dettaglio nel manuale della \acr{glibc}.
+
+Questi file non devono mai essere letti direttamente, ma le informazioni che
+contengono possono essere ricavate attraverso le opportune funzioni di
+libreria. Queste sono analoghe alle precedenti funzioni (vedi
+tab.~\ref{tab:sys_passwd_func}) usate per accedere al registro degli utenti,
+solo che in questo caso la struttura del registro della \textsl{contabilità} è
+molto più complessa, dato che contiene diversi tipi di informazione.
+
+Le prime tre funzioni, \funcd{setutent}, \funcd{endutent} e \funcd{utmpname}
+servono rispettivamente a aprire e a chiudere il file che contiene il registro
+della \textsl{contabilità} degli, e a specificare su quale file esso viene
+mantenuto. I loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{utmp.h}
+\fdecl{void utmpname(const char *file)}
+\fdesc{Specifica il file da usare come registro.}
+\fdecl{void setutent(void)}
+\fdesc{Apre il file del registro.}
+\fdecl{void endutent(void)}
+\fdesc{Chiude il file del registro.}
+}
+
+{Le funzioni non ritornano nulla.}
+\end{funcproto}
+
+Si tenga presente che le funzioni non restituiscono nessun valore, pertanto
+non è possibile accorgersi di eventuali errori, ad esempio se si è impostato
+un nome di file sbagliato con \func{utmpname}.
+
+Nel caso non si sia utilizzata \func{utmpname} per specificare un file di
+registro alternativo, sia \func{setutent} che \func{endutent} operano usando
+il default che è \sysfile{/var/run/utmp} il cui nome, così come una serie di
+altri valori di default per i \textit{pathname} di uso più comune, viene
+mantenuto nei valori di una serie di costanti definite includendo
+\headfiled{paths.h}, in particolare quelle che ci interessano sono:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\constd{\_PATH\_UTMP}] specifica il file che contiene il registro per
+ gli utenti correntemente collegati, questo è il valore che viene usato se
+ non si è utilizzato \func{utmpname} per modificarlo;
+\item[\constd{\_PATH\_WTMP}] specifica il file che contiene il registro per
+ l'archivio storico degli utenti collegati;
+\end{basedescript}
+che nel caso di Linux hanno un valore corrispondente ai file
+\sysfile{/var/run/utmp} e \sysfile{/var/log/wtmp} citati in precedenza.
+
+Una volta aperto il file del registro degli utenti si può eseguire una
+scansione leggendo o scrivendo una voce con le funzioni \funcd{getutent},
+\funcd{getutid}, \funcd{getutline} e \funcd{pututline}, i cui prototipi sono:
+
+
+\begin{funcproto}{
+\fhead{utmp.h}
+\fdecl{struct utmp *getutent(void)}
+\fdesc{Legge una voce dalla posizione corrente nel registro.}
+\fdecl{struct utmp *getutid(struct utmp *ut)}
+\fdesc{Ricerca una voce sul registro.}
+\fdecl{struct utmp *getutline(struct utmp *ut)}
+\fdesc{Ricerca una voce sul registro attinente a un terminale.}
+\fdecl{struct utmp *pututline(struct utmp *ut)}
+\fdesc{Scrive una voce nel registro.}
+}
+
+{Le funzioni ritornano il puntatore ad una struttura \struct{utmp} in caso di
+ successo e \val{NULL} in caso di errore, nel qual caso \var{errno} assumerà
+ il valore riportato dalle funzioni di sistema sottostanti.}
+\end{funcproto}
+
+Tutte queste funzioni fanno riferimento ad una struttura di tipo
+\struct{utmp}, la cui definizione in Linux è riportata in
+fig.~\ref{fig:sys_utmp_struct}. Le prime tre funzioni servono per leggere una
+voce dal registro: \func{getutent} legge semplicemente la prima voce
+disponibile, le altre due permettono di eseguire una ricerca. Aprendo il
+registro con \func{setutent} ci si posiziona al suo inizio, ogni chiamata di
+queste funzioni eseguirà la lettura sulle voci seguenti, pertanto la posizione
+sulla voce appena letta, in modo da consentire una scansione del file. Questo
+vale anche per \func{getutid} e \func{getutline}, il che comporta che queste
+funzioni effettuano comunque una ricerca ``\textsl{in avanti}''.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.9\textwidth}
+ \includestruct{listati/utmp.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{utmp} contenente le informazioni di una voce
+ del registro di \textsl{contabilità}.}
+ \label{fig:sys_utmp_struct}
+\end{figure}
+
+Con \func{getutid} si può cercare una voce specifica, a seconda del valore del
+campo \var{ut\_type} dell'argomento \param{ut}. Questo può assumere i valori
+riportati in tab.~\ref{tab:sys_ut_type}, quando assume i valori
+\const{RUN\_LVL}, \const{BOOT\_TIME}, \const{OLD\_TIME}, \const{NEW\_TIME},
+verrà restituito la prima voce che corrisponde al tipo determinato; quando
+invece assume i valori \const{INIT\_PROCESS}, \const{LOGIN\_PROCESS},
+\const{USER\_PROCESS} o \const{DEAD\_PROCESS} verrà restituita la prima voce
+corrispondente al valore del campo \var{ut\_id} specificato in \param{ut}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \constd{EMPTY} & Non contiene informazioni valide.\\
+ \constd{RUN\_LVL} & Identica il runlevel del sistema.\\
+ \constd{BOOT\_TIME} & Identifica il tempo di avvio del sistema.\\
+ \constd{OLD\_TIME} & Identifica quando è stato modificato l'orologio di
+ sistema.\\
+ \constd{NEW\_TIME} & Identifica da quanto è stato modificato il
+ sistema.\\
+ \constd{INIT\_PROCESS} & Identifica un processo lanciato da \cmd{init}.\\
+ \constd{LOGIN\_PROCESS}& Identifica un processo di login.\\
+ \constd{USER\_PROCESS} & Identifica un processo utente.\\
+ \constd{DEAD\_PROCESS} & Identifica un processo terminato.\\
+% \constd{ACCOUNTING} & ??? \\
+ \hline
+ \end{tabular}
+ \caption{Classificazione delle voci del registro a seconda dei
+ possibili valori del campo \var{ut\_type}.}
+ \label{tab:sys_ut_type}
+\end{table}
+
+La funzione \func{getutline} esegue la ricerca sulle voci che hanno un
+\var{ut\_type} con valore uguale a \const{LOGIN\_PROCESS} o
+\const{USER\_PROCESS}, restituendo la prima che corrisponde al valore di
+\var{ut\_line}, che specifica il dispositivo di terminale che interessa, da
+indicare senza il \file{/dev/} iniziale. Lo stesso criterio di ricerca è usato
+da \func{pututline} per trovare uno spazio dove inserire la voce specificata;
+qualora questo spazio non venga trovato la voce viene aggiunta in coda al
+registro.
+
+In generale occorre però tenere conto che queste funzioni non sono
+completamente standardizzate, e che in sistemi diversi possono esserci
+differenze; ad esempio \func{pututline} restituisce \code{void} in vari
+sistemi (compreso Linux, fino alle \acr{libc5}). Qui seguiremo la sintassi
+fornita dalla \acr{glibc}, ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno
+introdotto delle nuove strutture (e relativi file) di tipo \struct{utmpx}, che
+sono un sovrainsieme della \struct{utmp} usata tradizionalmente ed altrettante
+funzioni che le usano al posto di quelle citate.
+
+La \acr{glibc} utilizzava già una versione estesa di \struct{utmp}, che
+rende inutili queste nuove strutture, per questo su Linux \struct{utmpx} viene
+definita esattamente come \struct{utmp}, con gli stessi campi di
+fig.~\ref{fig:sys_utmp_struct}. Altrettanto dicasi per le nuove funzioni di
+gestione previste dallo standard: \funcm{getutxent}, \funcm{getutxid},
+\funcm{getutxline}, \funcm{pututxline}, \funcm{setutxent} e \funcm{endutxent}.
+
+Tutte queste funzioni, definite con \struct{utmpx} dal file di dichiarazione
+\headfile{utmpx.h}, su Linux sono ridefinite come sinonimi delle funzioni
+appena viste, con argomento di tipo \struct{utmpx} anziché \struct{utmp} ed
+hanno lo stesso identico comportamento. Per completezza viene definita anche
+\funcm{utmpxname} che non è prevista da POSIX.1-2001.
+
+Come già visto in sez.~\ref{sec:sys_user_group}, l'uso di strutture allocate
+staticamente rende le funzioni di lettura dei dati appena illustrate non
+rientranti. Per questo motivo la \acr{glibc} fornisce anche delle versioni
+rientranti: \func{getutent\_r}, \func{getutid\_r}, \func{getutline\_r}, che
+invece di restituire un puntatore restituiscono un intero e prendono due
+argomenti aggiuntivi, i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{utmp.h}
+\fdecl{int *getutent\_r(struct utmp *buffer, struct utmp **result)}
+\fdesc{Legge una voce dalla posizione corrente nel registro.}
+\fdecl{int *getutid\_r(struct utmp *buffer, struct utmp **result, struct utmp
+ *ut)}
+\fdesc{Ricerca una voce sul registro.}
+\fdecl{int *getutline\_r(struct utmp *buffer, struct utmp **result, struct utmp
+ *ut)}
+\fdesc{Ricerca una voce sul registro attinente a un terminale.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà il valore riportato dalle funzioni di sistema
+ sottostanti.}
+\end{funcproto}
+
+Le funzioni si comportano esattamente come le precedenti analoghe non
+rientranti, solo che restituiscono il risultato all'indirizzo specificato dal
+primo argomento aggiuntivo \param{buffer} mentre il secondo, \param{result)}
+viene usato per restituire il puntatore al buffer stesso.
+
+Infine la \acr{glibc} fornisce altre due funzioni, \funcd{updwtmp} e
+\funcd{logwtmp}, come estensione per scrivere direttamente delle voci nel file
+sul registro storico \sysfile{/var/log/wtmp}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{utmp.h}
+\fdecl{void updwtmp(const char *wtmp\_file, const struct utmp *ut)}
+\fdesc{Aggiunge una voce in coda al registro.}
+\fdecl{void logwtmp(const char *line, const char *name, const char *host)}
+\fdesc{Aggiunge nel registro una voce con i valori specificati.}
+}
+
+{Le funzioni non restituiscono nulla.}
+\end{funcproto}
+
+La prima funzione permette l'aggiunta di una voce in coda al file del registro
+storico, indicato dal primo argomento, specificando direttamente una struttura
+\struct{utmp}. La seconda invece utilizza gli argomenti \param{line},
+\param{name} e \param{host} per costruire la voce che poi aggiunge chiamando
+\func{updwtmp}.
+
+Queste funzioni non sono previste da POSIX.1-2001, anche se sono presenti in
+altri sistemi (ad esempio Solaris e NetBSD), per mantenere una coerenza con le
+altre funzioni definite nello standard che usano la struttura \struct{utmpx}
+la \acr{glibc} definisce anche una funzione \funcm{updwtmpx}, che come in
+precedenza è identica a \func{updwtmp} con la sola differenza di richiedere
+l'uso di \headfiled{utmpx.h} e di una struttura \struct{utmpx} come secondo
+argomento.
+
+
+\subsection{La gestione dello spegnimento e del riavvio}
+\label{sec:sys_reboot}
+
+Una delle operazioni di gestione generale del sistema è quella che attiene
+alle modalità con cui se ne può gestire lo spegnimento ed il riavvio. Perché
+questo avvenga in maniera corretta, in particolare per le parti che comportano
+lo spegnimento effettivo della macchina, occorre che il kernel effettui le
+opportune operazioni interagendo con il BIOS ed i dispositivi che controllano
+l'erogazione della potenza.
+
+La funzione di sistema che controlla lo spegnimento ed il riavvio (ed altri
+aspetti della relativa procedura) è \funcd{reboot},\footnote{la funzione
+ illustrata è quella fornita dalla \acr{glibc} che maschera i dettagli di
+ basso livello della \textit{system call} la quale richiede attualmente tre
+ argomenti; fino al kernel 2.1.30 la \textit{system call} richiedeva un
+ ulteriore quarto argomento, i primi due indicano dei \textit{magic number}
+ interi che possono assumere solo alcuni valori predefiniti, il terzo un
+ comando, corrispondente all'unico argomento della funzione della \acr{glibc}
+ ed il quarto argomento aggiuntivo, ora ignorato, un puntatore generico ad
+ ulteriori dati.} il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{sys/reboot.h}
+\fdecl{int reboot(int cmd)}
+\fdesc{Controlla il riavvio o l'arresto della macchina.}
+}
+
+{La funzione non ritorna o ritorna $0$ in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] c'è un indirizzo non valido nel passaggio degli
+ argomenti con il comando \const{LINUX\_REBOOT\_CMD\_RESTART2} (obsoleto).
+ \item[\errcode{EINVAL}] si sono specificati valori non validi per gli
+ argomenti.
+ \item[\errcode{EPERM}] il chiamante non ha i privilegi di amministratore (la
+ \textit{capability} \const{CAP\_SYS\_BOOT}).
+ \end{errlist}
+}
+\end{funcproto}
+
+La funzione, oltre al riavvio ed allo spegnimento, consente anche di
+controllare l'uso della combinazione di tasti tradizionalmente usata come
+scorciatoia da tastiera per richiedere il riavvio (\texttt{Ctrl-Alt-Del},
+denominata in breve nella documentazione CAD) ed i suoi effetti specifici
+dipendono dalla architettura hardware. Se si è richiesto un riavvio o uno
+spegnimento in caso di successo la funzione, non esistendo più il programma,
+ovviamente non ritorna, pertanto bisogna avere cura di aver effettuato tutte
+le operazioni preliminari allo spegnimento prima di eseguirla.
+
+Il comportamento della funzione viene controllato dall'argomento \param{cmd}
+e deve assumere indicato con una delle costanti seguente elenco, che
+illustra i comandi attualmente disponibili:
+
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{LINUX\_REBOOT\_CMD\_CAD\_OFF}] Disabilita l'uso diretto della
+ combinazione \texttt{Ctrl-Alt-Del}, la cui pressione si traduce nell'invio
+ del segnale \signal{SIGINT} a \texttt{init} (o più in generale al processo
+ con \ids{PID} 1) il cui effetto dipende dalla configurazione di
+ quest'ultimo.
+\item[\constd{LINUX\_REBOOT\_CMD\_CAD\_ON}] Attiva l'uso diretto della
+ combinazione \texttt{Ctrl-Alt-Del}, la cui pressione si traduce
+ nell'esecuzione dell'azione che si avrebbe avuto chiamando \func{reboot} con
+ il comando \const{LINUX\_REBOOT\_CMD\_RESTART}.
+\item[\constd{LINUX\_REBOOT\_CMD\_HALT}] Viene inviato sulla console il
+ messaggio ``\textit{System halted.}'' l'esecuzione viene bloccata
+ immediatamente ed il controllo passato al monitor nella ROM (se esiste e
+ l'architettura lo consente). Se non si è eseguita una sincronizzazione dei
+ dati su disco con \func{sync} questi saranno perduti.
+\item[\constd{LINUX\_REBOOT\_CMD\_KEXEC}] viene eseguito direttamente il nuovo
+ kernel che è stato opportunamente caricato in memoria da una
+ \func{kexec\_load} (che tratteremo a breve) eseguita in precedenza. La
+ funzionalità è disponibile solo a partire dal kernel 2.6.13 e se il kernel
+ corrente è stato compilato includendo il relativo supporto.\footnote{deve
+ essere stata abilitata l'opzione di compilazione \texttt{CONFIG\_KEXEC}.}
+ Questo meccanismo consente di eseguire una sorta di riavvio rapido che evita
+ di dover ripassare dalla inizializzazione da parte del BIOS ed il lancio del
+ kernel attraverso un bootloader. Se non si è eseguita una sincronizzazione
+ dei dati su disco con \func{sync} questi saranno perduti.
+\item[\constd{LINUX\_REBOOT\_CMD\_POWER\_OFF}] Viene inviato sulla console il
+ messaggio ``\textit{Power down.}'' l'esecuzione viene bloccata
+ immediatamente e la macchina, se possibile, viene spenta. Se non si è
+ eseguita una sincronizzazione dei dati su disco con \func{sync} questi
+ saranno perduti.
+\item[\constd{LINUX\_REBOOT\_CMD\_RESTART}] Viene inviato sulla console il
+ messaggio ``\textit{Restarting system.}'' ed avviata immediatamente la
+ procedura di riavvio ordinaria. Se non si è eseguita una sincronizzazione
+ dei dati su disco con \func{sync} questi saranno perduti.
+\item[\constd{LINUX\_REBOOT\_CMD\_RESTART2}] Viene inviato sulla console il
+ messaggio ``\textit{Restarting system with command '\%s'.}'' ed avviata
+ immediatamente la procedura di riavvio usando il comando fornito
+ nell'argomento \param{arg} che viene stampato al posto di \textit{'\%s'}
+ (veniva usato per lanciare un altro programma al posto di \cmd{init}). Nelle
+ versioni recenti questo argomento viene ignorato ed il riavvio può essere
+ controllato dall'argomento di avvio del kernel \texttt{reboot=...} Se non
+ si è eseguita una sincronizzazione dei dati su disco con \func{sync} questi
+ saranno perduti.
+\end{basedescript}
+
+
+Come appena illustrato usando il comando \const{LINUX\_REBOOT\_CMD\_KEXEC} si
+può eseguire un riavvio immediato pre-caricando una immagine del kernel, che
+verrà eseguita direttamente. Questo meccanismo consente di evitare la
+reinizializzazione della macchina da parte del BIOS, ed oltre a velocizzare un
+eventuale riavvio, ha il vantaggio poter accedere allo stato corrente della
+macchina e della memoria, per cui viene usato spesso per installare un kernel
+di emergenza da eseguire in caso di crollo del sistema per recuperare il
+maggior numero di informazioni possibili.
+
+La funzione di sistema che consente di caricare questa immagine del kernel è
+\funcd{kexec\_load}, la funzione non viene definita nella \acr{glibc} e deve
+pertanto essere invocata con \func{syscall}, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{linux/kexec.h}
+\fdecl{long kexec\_load(unsigned long entry, unsigned long nr\_segments,
+struct kexec\_segment\\
+\phantom{long kexec\_load(}*segments, unsigned long flags)}
+
+\fdesc{Carica un kernel per un riavvio immediato.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBUSY}] c'è già un caricamento in corso, o un altro kernel è
+ già in uso.
+ \item[\errcode{EINVAL}] il valore di \param{flags} non è valido o si è
+ indicato un valore eccessivo per \param{nr\_segments}.
+ \item[\errcode{EPERM}] il chiamante non ha i privilegi di amministratore (la
+ \textit{capability} \const{CAP\_SYS\_BOOT}).
+ \end{errlist}
+}
+\end{funcproto}
+
+Il primo argomento indica l'indirizzo fisico di esecuzione del nuovo kernel
+questo viene caricato usando un vettore di strutture \struct{kexec\_segment}
+(la cui definizione è riportata in fig.~\ref{fig:kexec_segment}) che
+contengono i singoli segmenti dell'immagine. I primi due campi indicano
+indirizzo e dimensione del segmento di memoria in \textit{user space}, i
+secondi indirizzo e dimensione in \textit{kernel space}.
+
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/kexec_segment.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{kexec\_segment} per il caricamento di un
+ segmento di immagine del kernel.}
+ \label{fig:kexec_segment}
+\end{figure}
+
+L'argomento \param{flags} è una maschera binaria contenente i flag che
+consentono di indicare le modalità con cui dovrà essere eseguito il nuovo
+kernel. La parte meno significativa viene usata per impostare l'architettura
+di esecuzione. Il valore \const{KEXEC\_ARCH\_DEFAULT} indica l'architettura
+corrente, ma se ne può specificare anche una diversa, con i valori della
+seconda parte di tab.~\ref{tab:kexec_load_flags}, e questa verrà usato posto
+che sia effettivamente eseguibile sul proprio processore.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \constd{KEXEC\_ON\_CRASH} & Il kernel caricato sarà eseguito
+ automaticamente in caso di crollo del
+ sistema.\\
+ \constd{KEXEC\_PRESERVE\_CONTEXT}& Viene preservato lo stato dei programmi
+ e dei dispositivi prima dell'esecuzione
+ del nuovo kernel. Viene usato
+ principalmente per l'ibernazione del
+ sistema ed ha senso solo se si è
+ indicato un numero di segmento maggiore
+ di zero.\\
+ \hline
+ \constd{KEXEC\_ARCH\_DEFAULT} & Il kernel caricato verrà eseguito nella
+ architettura corrente. \\
+ \texttt{KEXEC\_ARCH\_XXX} & Il kernel caricato verrà eseguito nella
+ architettura indicata (con \texttt{XXX}
+ che può essere: \texttt{386},
+ \texttt{X86\_64}, \texttt{PPC},
+ \texttt{PPC64}, \texttt{IA\_64},
+ \texttt{ARM}, \texttt{S390},
+ \texttt{SH}\texttt{MIPS}
+ e \texttt{MIPS\_LE}).\\
+% \const{} & \\
+ \hline
+ \end{tabular}
+ \caption{Valori per l'argomento \param{flags} di \func{kexec\_load}.}
+ \label{tab:kexec_load_flags}
+\end{table}
+
+I due valori più importanti sono però quelli della parte più significativa
+(riportati nella prima sezione di tab.~\ref{tab:kexec_load_flags}). Il primo,
+\const{KEXEC\_ON\_CRASH}, consente di impostare l'esecuzione automatica del
+nuovo kernel caricato in caso di crollo del sistema, e viene usato quando si
+carica un kernel di emergenza da utilizzare per poter raccogliere informazioni
+diagnostiche che altrimenti verrebbero perdute non essendo il kernel ordinario
+più in grado di essere eseguito in maniera coerente. Il secondo valore,
+\const{KEXEC\_PRESERVE\_CONTEXT}, indica invece di preservare lo stato dei
+programmi e dei dispositivi, e viene in genere usato per realizzare la
+cosiddetta ibernazione in RAM.
+
+% TODO: introdotta con il kernel 3.17 è stata introdotta
+% kexec_file_load, per caricare immagine firmate per il secure boot,
+% vedi anche http://lwn.net/Articles/603116/
+
+% TODO documentare keyctl ????
+% (fare sezione dedicata ????)
+
+% TODO documentare la Crypto API del kernel
+
+% TODO documentare la syscall getrandom, introdotta con il kernel 3.17, vedi
+% http://lwn.net/Articles/606141/, ed introdotta con le glibc solo con la
+% versione 2.25, vedi https://lwn.net/Articles/711013/
+
+%\subsection{La gestione delle chiavi crittografiche}
+%\label{sec:keyctl_management}
+
+%TODO non è chiaro se farlo qui, ma documentare la syscall bpf aggiunta con il
+% kernel 3.18, vedi http://lwn.net/Articles/612878/; al riguardo vedi anche
+% https://lwn.net/Articles/660331/
+
+\section{Il controllo dell'uso delle risorse}
+\label{sec:sys_res_limits}
+
+
+Dopo aver esaminato in sez.~\ref{sec:sys_management} le funzioni che
+permettono di controllare le varie caratteristiche, capacità e limiti del
+sistema a livello globale, in questa sezione tratteremo le varie funzioni che
+vengono usate per quantificare le risorse (CPU, memoria, ecc.) utilizzate da
+ogni singolo processo e quelle che permettono di imporre a ciascuno di essi
+vincoli e limiti di utilizzo.
+
+
+\subsection{L'uso delle risorse}
+\label{sec:sys_resource_use}
+
+Come abbiamo accennato in sez.~\ref{sec:proc_wait} le informazioni riguardo
+l'utilizzo delle risorse da parte di un processo è mantenuto in una struttura
+di tipo \struct{rusage}, la cui definizione (che si trova in
+\headfiled{sys/resource.h}) è riportata in
+fig.~\ref{fig:sys_rusage_struct}. Si ricordi che questa è una delle
+informazioni preservate attraverso una \func{exec}.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/rusage.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{rusage} per la lettura delle informazioni dei
+ delle risorse usate da un processo.}
+ \label{fig:sys_rusage_struct}
+\end{figure}
+
+La definizione della struttura in fig.~\ref{fig:sys_rusage_struct} è ripresa
+da BSD 4.3,\footnote{questo non ha a nulla a che fare con il cosiddetto
+ \textit{BSD accounting} (vedi sez. \ref{sec:sys_bsd_accounting}) che si
+ trova nelle opzioni di compilazione del kernel (e di norma è disabilitato)
+ che serve per mantenere una contabilità delle risorse usate da ciascun
+ processo in maniera molto più dettagliata.} ma attualmente solo alcuni dei
+campi definiti sono effettivamente mantenuti. Con i kernel della serie 2.4 i
+soli campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
+\var{ru\_minflt} e \var{ru\_majflt}. Con i kernel della serie 2.6 si
+aggiungono anche \var{ru\_nvcsw} e \var{ru\_nivcsw}, a partire dal 2.6.22
+anche \var{ru\_inblock} e \var{ru\_oublock} e dal 2.6.32 anche
+\var{ru\_maxrss}.
+
+In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
+necessario, ma aumenta la portabilità, e serve comunque quando, come nella
+maggior parte dei casi, si debba accedere ai campi di \struct{rusage} relativi
+ai tempi di utilizzo del processore, che sono definiti come strutture di tipo
+\struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct}).
+
+La struttura \struct{rusage} è la struttura utilizzata da \func{wait4} (si
+ricordi quando visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di
+risorse impiegate dal processo di cui si è letto lo stato di terminazione, ma
+essa può anche essere letta direttamente utilizzando la funzione di sistema
+\funcd{getrusage}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{sys/resource.h}
+\fhead{unistd.h}
+\fdecl{int getrusage(int who, struct rusage *usage)}
+
+\fdesc{Legge la quantità di risorse usate da un processo.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] l'argomento \param{who} non è valido
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.
+}
+\end{funcproto}
+
+La funzione ritorna i valori per l'uso delle risorse nella struttura
+\struct{rusage} puntata dall'argomento \param{usage}. L'argomento \param{who}
+permette di specificare il soggetto di cui si vuole leggere l'uso delle
+risorse; esso può assumere solo i valori illustrati in
+tab.~\ref{tab:getrusage_who}, di questi \const{RUSAGE\_THREAD} è specifico di
+Linux ed è disponibile solo a partire dal kernel 2.6.26. La funzione è stata
+recepita nello standard POSIX.1-2001, che però indica come campi di
+\struct{rusage} soltanto \var{ru\_utime} e \var{ru\_stime}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \constd{RUSAGE\_SELF} & Ritorna l'uso delle risorse del processo
+ corrente, che in caso di uso dei
+ \textit{thread} ammonta alla somma delle
+ risorse utilizzate da tutti i \textit{thread}
+ del processo.\\
+ \constd{RUSAGE\_CHILDREN} & Ritorna l'uso delle risorse dell'insieme dei
+ processi figli di cui è ricevuto lo stato di
+ terminazione, che a loro volta comprendono
+ quelle dei loro figli e così via.\\
+ \constd{RUSAGE\_THREAD} & Ritorna l'uso delle risorse del \textit{thread}
+ chiamante.\\
+ \hline
+ \end{tabular}
+ \caption{Valori per l'argomento \param{who} di \func{getrusage}.}
+ \label{tab:getrusage_who}
+\end{table}
+
+I campi più utilizzati sono comunque \var{ru\_utime} e \var{ru\_stime} che
+indicano rispettivamente il tempo impiegato dal processo nell'eseguire le
+istruzioni in \textit{user space}, e quello impiegato dal kernel nelle
+\textit{system call} eseguite per conto del processo (vedi
+sez.~\ref{sec:sys_unix_time}). I campi \var{ru\_minflt} e \var{ru\_majflt}
+servono a quantificare l'uso della memoria virtuale e corrispondono
+rispettivamente al numero di \textit{page fault} (vedi
+sez.~\ref{sec:proc_mem_gen}) avvenuti senza richiedere I/O su disco (i
+cosiddetti \textit{minor page fault}), a quelli che invece han richiesto I/O
+su disco (detti invece \textit{major page
+ fault}).% mentre \var{ru\_nswap} ed al numero di volte che
+% il processo è stato completamente tolto dalla memoria per essere inserito
+% nello swap.
+% TODO verificare \var{ru\_nswap} non citato nelle pagine di manuali recenti e
+% dato per non utilizzato.
+
+I campi \var{ru\_nvcsw} e \var{ru\_nivcsw} indicano il numero di volte che un
+processo ha subito un \textit{context switch} da parte dello
+\textit{scheduler} rispettivamente nel caso un cui questo avviene prima
+dell'esaurimento della propria \textit{time-slice} (in genere a causa di una
+\textit{system call} bloccante), o per averla esaurita o essere stato
+interrotto da un processo a priorità maggiore. I campi \var{ru\_inblock} e
+\var{ru\_oublock} indicano invece il numero di volte che è stata eseguita una
+attività di I/O su un filesystem (rispettivamente in lettura e scrittura) ed
+infine \var{ru\_maxrss} indica il valore più alto della \textit{Resident Set
+ Size} raggiunto dal processo stesso o, nel caso sia stato usato
+\const{RUSAGE\_CHILDREN}, da uno dei suoi figli.
+
+Si tenga conto che per un errore di implementazione nei i kernel precedenti il
+2.6.9, nonostante questo fosse esplicitamente proibito dallo standard POSIX.1,
+l'uso di \const{RUSAGE\_CHILDREN} comportava l'inserimento dell'ammontare
+delle risorse usate dai processi figli anche quando si era impostata una
+azione di \const{SIG\_IGN} per il segnale \signal{SIGCHLD} (per i segnali si
+veda cap.~\ref{cha:signals}). Il comportamento è stato corretto per aderire
+allo standard a partire dal kernel 2.6.9.
+
+
+\subsection{Limiti sulle risorse}
+\label{sec:sys_resource_limit}
+
+Come accennato nell'introduzione il kernel mette a disposizione delle
+funzionalità che permettono non solo di mantenere dati statistici relativi
+all'uso delle risorse, ma anche di imporre dei limiti precisi sul loro
+utilizzo da parte sia dei singoli processi che degli utenti.
+
+Per far questo sono definite una serie di risorse e ad ogni processo vengono
+associati due diversi limiti per ciascuna di esse; questi sono il
+\textsl{limite corrente} (o \textit{current limit}) che esprime un valore
+massimo che il processo non può superare ad un certo momento, ed il
+\textsl{limite massimo} (o \textit{maximum limit}) che invece esprime il
+valore massimo che può assumere il \textsl{limite corrente}. In generale il
+primo viene chiamato anche \textit{soft limit} dato che il suo valore può
+essere aumentato dal processo stesso durante l'esecuzione, ciò può però essere
+fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
+ limit}.
+
+In generale il superamento di un limite corrente comporta o l'emissione di uno
+specifico segnale o il fallimento della \textit{system call} che lo ha
+provocato. A questo comportamento generico fanno eccezione \const{RLIMIT\_CPU}
+in cui si ha in comportamento diverso per il superamento dei due limiti e
+\const{RLIMIT\_CORE} che influenza soltanto la dimensione o l'eventuale
+creazione dei file di \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
+
+Per permettere di leggere e di impostare i limiti di utilizzo delle risorse da
+parte di un processo sono previste due funzioni di sistema, \funcd{getrlimit}
+e \funcd{setrlimit}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{sys/resource.h}
+\fhead{unistd.h}
+\fdecl{int getrlimit(int resource, struct rlimit *rlim)}
+\fdesc{Legge i limiti di una risorsa.}
+\fdecl{int setrlimit(int resource, const struct rlimit *rlim)}
+\fdesc{Imposta i limiti di una risorsa.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] i valori per \param{resource} non sono validi o
+ nell'impostazione si è specificato \var{rlim->rlim\_cur} maggiore di
+ \var{rlim->rlim\_max}.
+ \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
+ cercato di innalzare i propri limiti.
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.
+}
+\end{funcproto}
+
+Entrambe le funzioni permettono di specificare attraverso l'argomento
+\param{resource} su quale risorsa si vuole operare. L'accesso (rispettivamente
+in lettura e scrittura) ai valori effettivi dei limiti viene poi effettuato
+attraverso la struttura \struct{rlimit} puntata da
+\param{rlim}, la cui definizione è riportata in
+fig.~\ref{fig:sys_rlimit_struct}, ed i cui campi corrispondono appunto a
+limite corrente e limite massimo.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/rlimit.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{rlimit} per impostare i limiti di utilizzo
+ delle risorse usate da un processo.}
+ \label{fig:sys_rlimit_struct}
+\end{figure}
+
+Come accennato processo ordinario può alzare il proprio limite corrente fino
+al valore del limite massimo, può anche ridurre, irreversibilmente, il valore
+di quest'ultimo. Nello specificare un limite, oltre a fornire dei valori
+specifici, si può anche usare la costante \const{RLIM\_INFINITY} che permette
+di sbloccare completamente l'uso di una risorsa. Si ricordi però che solo un
+processo con i privilegi di amministratore\footnote{per essere precisi in
+ questo caso quello che serve è la \textit{capability}
+ \const{CAP\_SYS\_RESOURCE} (vedi sez.~\ref{sec:proc_capabilities}).} può
+innalzare un limite al di sopra del valore corrente del limite massimo ed
+usare un valore qualsiasi per entrambi i limiti.
+
+Ciascuna risorsa su cui si possono applicare dei limiti è identificata da uno
+specifico valore dell'argomento \param{resource}, i valori possibili per
+questo argomento, ed il significato della risorsa corrispondente, dei
+rispettivi limiti e gli effetti causati dal superamento degli stessi sono
+riportati nel seguente elenco:
+
+\begin{basedescript}{\desclabelwidth{2.2cm}}%\desclabelstyle{\nextlinelabel}}
+\item[\constd{RLIMIT\_AS}] Questa risorsa indica, in byte, la dimensione
+ massima consentita per la memoria virtuale di un processo, il cosiddetto
+ \textit{Address Space}, (vedi sez.~\ref{sec:proc_mem_gen}). Se il limite
+ viene superato dall'uso di funzioni come \func{brk}, \func{mremap} o
+ \func{mmap} esse falliranno con un errore di \errcode{ENOMEM}, mentre se il
+ superamento viene causato dalla crescita dello \textit{stack} il processo
+ riceverà un segnale di \signal{SIGSEGV}. Dato che il valore usato è un
+ intero di tipo \ctyp{long} nelle macchine a 32 bit questo può assumere un
+ valore massimo di 2Gb (anche se la memoria disponibile può essere maggiore),
+ in tal caso il limite massimo indicabile resta 2Gb, altrimenti la risorsa si
+ dà per non limitata.
+
+\item[\constd{RLIMIT\_CORE}] Questa risorsa indica, in byte, la massima
+ dimensione per un file di \textit{core dump} (vedi
+ sez.~\ref{sec:sig_standard}) creato nella terminazione di un processo. File
+ di dimensioni maggiori verranno troncati a questo valore, mentre con un
+ valore nullo si bloccherà la creazione dei \textit{core dump}.
+
+\item[\constd{RLIMIT\_CPU}] Questa risorsa indica, in secondi, il massimo tempo
+ di CPU (vedi sez.~\ref{sec:sys_cpu_times}) che il processo può usare. Il
+ superamento del limite corrente comporta l'emissione di un segnale di
+ \signal{SIGXCPU}, la cui azione predefinita (vedi
+ sez.~\ref{sec:sig_classification}) è terminare il processo. Il segnale però
+ può essere intercettato e ignorato, in tal caso esso verrà riemesso una
+ volta al secondo fino al raggiungimento del limite massimo. Il superamento
+ del limite massimo comporta comunque l'emissione di un segnale di
+ \signal{SIGKILL}. Si tenga presente che questo è il comportamento presente
+ su Linux dai kernel della serie 2.2 ad oggi, altri kernel possono avere
+ comportamenti diversi per quanto avviene quando viene superato il
+ \textit{soft limit}, pertanto per avere operazioni portabili è suggerito di
+ intercettare sempre \signal{SIGXCPU} e terminare in maniera ordinata il
+ processo con la prima ricezione.
+
+\item[\constd{RLIMIT\_DATA}] Questa risorsa indica, in byte, la massima
+ dimensione del segmento dati di un processo (vedi
+ sez.~\ref{sec:proc_mem_layout}). Il tentativo di allocare più memoria di
+ quanto indicato dal limite corrente causa il fallimento della funzione di
+ allocazione eseguita (\func{brk} o \func{sbrk}) con un errore di
+ \errcode{ENOMEM}.
+
+\item[\constd{RLIMIT\_FSIZE}] Questa risorsa indica, in byte, la massima
+ dimensione di un file che un processo può usare. Se il processo cerca di
+ scrivere o di estendere il file oltre questa dimensione riceverà un segnale
+ di \signal{SIGXFSZ}, che di norma termina il processo. Se questo segnale
+ viene intercettato la \textit{system call} che ha causato l'errore fallirà
+ con un errore di \errcode{EFBIG}.
+
+\item[\constd{RLIMIT\_LOCKS}] Questa risorsa indica il numero massimo di
+ \textit{file lock} (vedi sez.~\ref{sec:file_locking}) e di \textit{file
+ lease} (vedi sez.~\ref{sec:file_asyncronous_lease}) che un processo poteva
+ effettuare. È un limite presente solo nelle prime versioni del kernel 2.4,
+ pertanto non deve essere più utilizzato.
+
+\item[\constd{RLIMIT\_MEMLOCK}] Questa risorsa indica, in byte, l'ammontare
+ massimo di memoria che può essere bloccata in RAM da un processo (vedi
+ sez.~\ref{sec:proc_mem_lock}). Dato che il \textit{memory locking} viene
+ effettuato sulle pagine di memoria, il valore indicato viene automaticamente
+ arrotondato al primo multiplo successivo della dimensione di una pagina di
+ memoria. Il limite comporta il fallimento delle \textit{system call} che
+ eseguono il \textit{memory locking} (\func{mlock}, \func{mlockall} ed anche,
+ vedi sez.~\ref{sec:file_memory_map}, \func{mmap} con l'operazione
+ \const{MAP\_LOCKED}).
+
+ Dal kernel 2.6.9 questo limite comprende anche la memoria che può essere
+ bloccata da ciascun utente nell'uso della memoria condivisa (vedi
+ sez.~\ref{sec:ipc_sysv_shm}) con \func{shmctl}, che viene contabilizzata
+ separatamente ma sulla quale viene applicato questo stesso limite. In
+ precedenza invece questo limite veniva applicato sulla memoria condivisa per
+ processi con privilegi amministrativi, il limite su questi è stato rimosso e
+ la semantica della risorsa cambiata.
+
+
+\item[\constd{RLIMIT\_MSGQUEUE}] Questa risorsa indica il numero massimo di
+ byte che possono essere utilizzati da un utente, identificato con
+ l'\ids{UID} reale del processo chiamante, per le code di messaggi POSIX
+ (vedi sez.~\ref{sec:ipc_posix_mq}). Per ciascuna coda che viene creata viene
+ calcolata un'occupazione pari a:
+\includecodesnip{listati/mq_occupation.c}
+dove \var{attr} è la struttura \struct{mq\_attr} (vedi
+fig.~\ref{fig:ipc_mq_attr}) usata nella creazione della coda. Il primo addendo
+consente di evitare la creazione di una coda con un numero illimitato di
+messaggi vuoti che comunque richiede delle risorse di gestione. Questa risorsa
+è stata introdotta con il kernel 2.6.8.
+
+\item[\constd{RLIMIT\_NICE}] Questa risorsa indica il numero massimo a cui può
+ essere il portato il valore di \textit{nice} (vedi
+ sez.~\ref{sec:proc_sched_stand}). Dato che non possono essere usati numeri
+ negativi per specificare un limite, il valore di \textit{nice} viene
+ calcolato come \code{20-rlim\_cur}. Questa risorsa è stata introdotta con il
+ kernel 2.6.12.
+
+\item[\constd{RLIMIT\_NOFILE}] Questa risorsa indica il numero massimo di file
+ che un processo può aprire. Il tentativo di creazione di un ulteriore file
+ descriptor farà fallire la funzione (\func{open}, \func{dup}, \func{pipe},
+ ecc.) con un errore \errcode{EMFILE}.
+
+\item[\constd{RLIMIT\_NPROC}] Questa risorsa indica il numero massimo di
+ processi che possono essere creati dallo stesso utente, che viene
+ identificato con l'\ids{UID} reale (vedi sez.~\ref{sec:proc_access_id}) del
+ processo chiamante. Se il limite viene raggiunto \func{fork} fallirà con un
+ \errcode{EAGAIN}.
+
+\item[\constd{RLIMIT\_RSS}] Questa risorsa indica, in pagine di memoria, la
+ dimensione massima della memoria residente (il cosiddetto RSS
+ \itindex{Resident~Set~Size~(RSS)} \textit{Resident Set Size}) cioè
+ l'ammontare della memoria associata al processo che risiede effettivamente
+ in RAM e non a quella eventualmente portata sulla \textit{swap} o non ancora
+ caricata dal filesystem per il segmento testo del programma. Ha effetto
+ solo sulle chiamate a \func{madvise} con \const{MADV\_WILLNEED} (vedi
+ sez.~\ref{sec:file_memory_map}). Presente solo sui i kernel precedenti il
+ 2.4.30.
+
+\item[\constd{RLIMIT\_RTPRIO}] Questa risorsa indica il valore massimo della
+ priorità statica che un processo può assegnarsi o assegnare con
+ \func{sched\_setscheduler} e \func{sched\_setparam} (vedi
+ sez.~\ref{sec:proc_real_time}). Il limite è stato introdotto a partire dal
+ kernel 2.6.12 (ma per un bug è effettivo solo a partire dal 2.6.13). In
+ precedenza solo i processi con privilegi amministrativi potevano avere una
+ priorità statica ed utilizzare una politica di \textit{scheduling} di tipo
+ \textit{real-time}.
+
+\item[\constd{RLIMIT\_RTTIME}] Questa risorsa indica, in microsecondi, il tempo
+ massimo di CPU che un processo eseguito con una priorità statica può
+ consumare. Il superamento del limite corrente comporta l'emissione di un
+ segnale di \signal{SIGXCPU}, e quello del limite massimo di \signal{SIGKILL}
+ con le stesse regole viste \const{RLIMIT\_CPU}: se \signal{SIGXCPU} viene
+ intercettato ed ignorato il segnale verrà riemesso ogni secondo fino al
+ superamento del limite massimo. Questo limite è stato introdotto con il
+ kernel 2.6.25 per impedire che un processo \textit{real-time} possa bloccare
+ il sistema.
+
+\item[\constd{RLIMIT\_SIGPENDING}] Questa risorsa indica il numero massimo di
+ segnali che possono essere mantenuti in coda per ciascun utente,
+ identificato per \ids{UID} reale. Il limite comprende sia i segnali normali
+ che quelli \textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) ed è
+ attivo solo per \func{sigqueue}, con \func{kill} si potrà sempre inviare un
+ segnale che non sia già presente su una coda. Questo limite è stato
+ introdotto con il kernel 2.6.8.
+
+\item[\constd{RLIMIT\_STACK}] Questa risorsa indica, in byte, la massima
+ dimensione dello \textit{stack} del processo. Se il processo esegue
+ operazioni che estendano lo \textit{stack} oltre questa dimensione riceverà
+ un segnale di \signal{SIGSEGV}.
+
+ A partire dal kernel 2.6.23 questo stesso limite viene applicato per la gran
+ parte delle architetture anche ai dati che possono essere passati come
+ argomenti e variabili di ambiente ad un programma posto in esecuzione con
+ \func{execve}, nella misura di un quarto del valore indicato per lo
+ \textit{stack}. Questo valore in precedenza era fisso e pari a 32 pagine di
+ memoria, corrispondenti per la gran parte delle architetture a 128kb di
+ dati, dal 2.6.25, per evitare problemi di compatibilità quando
+ \const{RLIMIT\_STACK} è molto basso, viene comunque garantito uno spazio
+ base di 32 pagine qualunque sia l'architettura.
+
+\end{basedescript}
+
+Si tenga conto infine che tutti i limiti eventualmente presenti su un processo
+vengono ereditati dai figli da esso creati attraverso una \func{fork} (vedi
+sez.~\ref{sec:proc_fork}) e mantenuti invariati per i programmi messi in
+esecuzione attraverso una \func{exec} (vedi sez.~\ref{sec:proc_exec}).
+
+Si noti come le due funzioni \func{getrlimit} e \func{setrlimit} consentano di
+operare solo sul processo corrente. Per questo motivo a partire dal kernel
+2.6.36 (e dalla \acr{glibc} 2.13) è stata introdotta un'altra funzione di
+sistema \funcd{prlimit} il cui scopo è quello di estendere e sostituire le
+precedenti. Il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/resource.h}
+\fdecl{int prlimit(pid\_t pid, int resource, const struct rlimit *new\_limit,\\
+\phantom{int prlimit(}struct rlimit *old\_limit}
+\fdesc{Legge e imposta i limiti di una risorsa.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] i valori per \param{resource} non sono validi o
+ nell'impostazione si è specificato \var{rlim->rlim\_cur} maggiore di
+ \var{rlim->rlim\_max}.
+ \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
+ cercato di innalzare i propri limiti o si è cercato di modificare i limiti
+ di un processo di un altro utente.
+ \item [\errcode{ESRCH}] il process \param{pid} non esiste.
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.
+}
+\end{funcproto}
+
+La funzione è specifica di Linux e non portabile; per essere usata richiede
+che sia stata definita la macro \macro{\_GNU\_SOURCE}. Il primo argomento
+indica il \ids{PID} del processo di cui si vogliono cambiare i limiti e si può
+usare un valore nullo per indicare il processo chiamante. Per modificare i
+limiti di un altro processo, a meno di non avere privilegi
+amministrativi,\footnote{anche in questo caso la \textit{capability}
+ necessaria è \const{CAP\_SYS\_RESOURCE} (vedi
+ sez.~\ref{sec:proc_capabilities}).} l'\ids{UID} ed il \ids{GID} reale del
+chiamante devono coincidere con \ids{UID} e \ids{GID} del processo indicato
+per i tre gruppi reale, effettivo e salvato.
+
+Se \param{new\_limit} non è \val{NULL} verrà usato come puntatore alla
+struttura \struct{rlimit} contenente i valori dei nuovi limiti da impostare,
+mentre se \param{old\_limit} non è \val{NULL} verranno letti i valori correnti
+del limiti nella struttura \struct{rlimit} da esso puntata. In questo modo è
+possibile sia leggere che scrivere, anche in contemporanea, i valori dei
+limiti. Il significato dell'argomento \param{resource} resta identico rispetto
+a \func{getrlimit} e \func{setrlimit}, così come i restanti requisiti.
+
+
+\subsection{Le informazioni sulle risorse di memoria e processore}
+\label{sec:sys_memory_res}
+
+La gestione della memoria è già stata affrontata in dettaglio in
+sez.~\ref{sec:proc_memory}; abbiamo visto allora che il kernel provvede il
+meccanismo della memoria virtuale attraverso la divisione della memoria fisica
+in pagine. In genere tutto ciò è del tutto trasparente al singolo processo,
+ma in certi casi, come per l'I/O mappato in memoria (vedi
+sez.~\ref{sec:file_memory_map}) che usa lo stesso meccanismo per accedere ai
+file, è necessario conoscere le dimensioni delle pagine usate dal kernel. Lo
+stesso vale quando si vuole gestire in maniera ottimale l'interazione della
+memoria che si sta allocando con il meccanismo della paginazione.
+
+Un tempo la dimensione delle pagine di memoria era fissata una volta per tutte
+dall'architettura hardware, per cui il relativo valore veniva mantenuto in una
+costante che bastava utilizzare in fase di compilazione. Oggi invece molte
+architetture permettono di variare questa dimensione (ad esempio sui PC
+recenti si possono usare pagine di 4kb e di 4 Mb) per cui per non dover
+ricompilare i programmi per ogni possibile caso e relativa scelta di
+dimensioni, è necessario poter utilizzare una funzione che restituisca questi
+valori quando il programma viene eseguito.
+
+Dato che si tratta di una caratteristica generale del sistema come abbiamo
+visto in sez.~\ref{sec:sys_characteristics} questa dimensione può essere
+ottenuta come tutte le altre attraverso una chiamata a \func{sysconf}, nel
+caso specifico si dovrebbe utilizzare il parametro \const{\_SC\_PAGESIZE}. Ma
+in BSD 4.2 è stata introdotta una apposita funzione di sistema
+\funcd{getpagesize} che restituisce la dimensione delle pagine di memoria. La
+funzione è disponibile anche su Linux (ma richiede che sia definita la macro
+\macro{\_BSD\_SOURCE}) ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int getpagesize(void)}
+\fdesc{Legge la dimensione delle pagine di memoria.}
+}
+
+{La funzione ritorna la dimensione di una pagina in byte, e non sono previsti
+ errori.}
+\end{funcproto}
+
+La funzione è prevista in SVr4, BSD 4.4 e SUSv2, anche se questo ultimo
+standard la etichetta come obsoleta, mentre lo standard POSIX 1003.1-2001 la
+ha eliminata, ed i programmi che intendono essere portabili devono ricorrere
+alla chiamata a \func{sysconf}.
+
+In Linux è implementata come una \textit{system call} nelle architetture in
+cui essa è necessaria, ed in genere restituisce il valore del simbolo
+\const{PAGE\_SIZE} del kernel, che dipende dalla architettura hardware, anche
+se le versioni delle librerie del C precedenti la \acr{glibc} 2.1
+implementavano questa funzione restituendo sempre un valore statico.
+
+% TODO verificare meglio la faccenda di const{PAGE\_SIZE}
+
+La \textsl{glibc} fornisce, come specifica estensione GNU, altre due
+funzioni, \funcd{get\_phys\_pages} e \funcd{get\_avphys\_pages} che permettono
+di ottenere informazioni riguardo le pagine di memoria; i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/sysinfo.h}
+\fdecl{long int get\_phys\_pages(void)}
+\fdesc{Legge il numero totale di pagine di memoria.}
+\fdecl{long int get\_avphys\_pages(void)}
+\fdesc{Legge il numero di pagine di memoria disponibili nel sistema.}
+}
+
+{La funzioni ritornano il numero di pagine, e non sono previsti
+ errori.}
+\end{funcproto}
+
+Queste funzioni sono equivalenti all'uso della funzione \func{sysconf}
+rispettivamente con i parametri \const{\_SC\_PHYS\_PAGES} e
+\const{\_SC\_AVPHYS\_PAGES}. La prima restituisce il numero totale di pagine
+corrispondenti alla RAM della macchina; la seconda invece la memoria
+effettivamente disponibile per i processi.
+
+La \acr{glibc} supporta inoltre, come estensioni GNU, due funzioni che
+restituiscono il numero di processori della macchina (e quello dei processori
+attivi); anche queste sono informazioni comunque ottenibili attraverso
+\func{sysconf} utilizzando rispettivamente i parametri
+\const{\_SC\_NPROCESSORS\_CONF} e \const{\_SC\_NPROCESSORS\_ONLN}.
+
+Infine la \acr{glibc} riprende da BSD la funzione \funcd{getloadavg} che
+permette di ottenere il carico di processore della macchina, in questo modo è
+possibile prendere decisioni su quando far partire eventuali nuovi processi.
+Il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int getloadavg(double loadavg[], int nelem)}
+\fdesc{Legge il carico medio della macchina.}
+}
+
+{La funzione ritorna il numero di campionamenti restituiti e $-1$ se non
+ riesce ad ottenere il carico medio, \var{errno} non viene modificata.}
+\end{funcproto}
+
+La funzione restituisce in ciascun elemento di \param{loadavg} il numero medio
+di processi attivi sulla coda dello \textit{scheduler}, calcolato su diversi
+intervalli di tempo. Il numero di intervalli che si vogliono leggere è
+specificato da \param{nelem}, dato che nel caso di Linux il carico viene
+valutato solo su tre intervalli (corrispondenti a 1, 5 e 15 minuti), questo è
+anche il massimo valore che può essere assegnato a questo argomento.
+
+
+\subsection{La \textsl{contabilità} in stile BSD}
+\label{sec:sys_bsd_accounting}
+
+Una ultima modalità per monitorare l'uso delle risorse è, se si è compilato il
+kernel con il relativo supporto,\footnote{se cioè si è abilitata l'opzione di
+ compilazione \texttt{CONFIG\_BSD\_PROCESS\_ACCT}.} quella di attivare il
+cosiddetto \textit{BSD accounting}, che consente di registrare su file una
+serie di informazioni\footnote{contenute nella struttura \texttt{acct}
+ definita nel file \texttt{include/linux/acct.h} dei sorgenti del kernel.}
+riguardo alla \textsl{contabilità} delle risorse utilizzate da ogni processo
+che viene terminato.
+
+Linux consente di salvare la contabilità delle informazioni relative alle
+risorse utilizzate dai processi grazie alla funzione \funcd{acct}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int acct(const char *filename)}
+\fdesc{Abilita il \textit{BSD accounting}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] non si hanno i permessi per accedere a
+ \param{pathname}.
+ \item[\errcode{ENOSYS}] il kernel non supporta il \textit{BSD accounting}.
+ \item[\errcode{EPERM}] il processo non ha privilegi sufficienti ad
+ abilitare il \textit{BSD accounting}.
+ \item[\errcode{EUSERS}] non sono disponibili nel kernel strutture per il
+ file o si è finita la memoria.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
+ \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOENT}, \errval{ENOMEM},
+ \errval{ENOTDIR}, \errval{EROFS} nel loro significato generico.}
+\end{funcproto}
+
+La funzione attiva il salvataggio dei dati sul file indicato dal
+\textit{pathname} contenuti nella stringa puntata da \param{filename}; la
+funzione richiede che il processo abbia i privilegi di amministratore (è
+necessaria la \textit{capability} \const{CAP\_SYS\_PACCT}, vedi
+sez.~\ref{sec:proc_capabilities}). Se si specifica il valore \val{NULL} per
+\param{filename} il \textit{BSD accounting} viene invece disabilitato. Un
+semplice esempio per l'uso di questa funzione è riportato nel programma
+\texttt{AcctCtrl.c} dei sorgenti allegati alla guida.
+
+Quando si attiva la contabilità, il file che si indica deve esistere; esso
+verrà aperto in sola scrittura e le informazioni verranno registrate in
+\textit{append} in coda al file tutte le volte che un processo termina. Le
+informazioni vengono salvate in formato binario, e corrispondono al contenuto
+della apposita struttura dati definita all'interno del kernel.
+
+Il funzionamento di \func{acct} viene inoltre modificato da uno specifico
+parametro di sistema, modificabile attraverso \sysctlfiled{kernel/acct} (o
+tramite la corrispondente \func{sysctl}). Esso contiene tre valori interi, il
+primo indica la percentuale di spazio disco libero sopra il quale viene
+ripresa una registrazione che era stata sospesa per essere scesi sotto il
+minimo indicato dal secondo valore (sempre in percentuale di spazio disco
+libero). Infine l'ultimo valore indica la frequenza in secondi con cui deve
+essere controllata detta percentuale.
+
+% TODO: bassa priorità, trattare la lettura del file di accounting, da
+% programma, vedi man 5 acct
+
+
+\section{La gestione dei tempi del sistema}
+\label{sec:sys_time}
+
+In questa sezione, una volta introdotti i concetti base della gestione dei
+tempi da parte del sistema, tratteremo le varie funzioni attinenti alla
+gestione del tempo in un sistema unix-like, a partire da quelle per misurare i
+veri tempi di sistema associati ai processi, a quelle per convertire i vari
+tempi nelle differenti rappresentazioni che vengono utilizzate, a quelle della
+gestione di data e ora.
+
+
+\subsection{La misura del tempo in Unix}
+\label{sec:sys_unix_time}
+
+\itindbeg{calendar~time}
+\itindbeg{process~time}
+
+Tradizionalmente nei sistemi unix-like sono sempre stati previsti due tipi
+distinti di tempi, caratterizzati da altrettante modalità di misura ed
+espressi con diversi tipi di dati, chiamati rispettivamente \textit{calendar
+ time} e \textit{process time}, secondo le seguenti definizioni:
+\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\textit{calendar time}] detto anche \textsl{tempo di calendario},
+ \textsl{tempo d'orologio} o \textit{tempo reale}. Si tratta di un
+ tempo assoluto o di un intervallo di tempo come lo intende
+ normalmente per le misure fatte con un orologio. Per esprimere
+ questo tempo è stato riservato il tipo \type{time\_t}, e viene
+ tradizionalmente misurato in secondi a partire dalla mezzanotte del
+ primo gennaio 1970, data che viene chiamata \textit{the Epoch}.
+
+\item[\textit{process time}] detto anche \textsl{tempo di processore} o
+ \textsl{tempo di CPU}. Si tratta del tempo impiegato da un processore
+ nell'esecuzione del codice di un programma all'interno di un processo. Per
+ esprimere questo tempo è stato riservato il tipo \type{clock\_t}, e viene
+ misurato nei cosiddetti \textit{clock tick}, tradizionalmente corrispondenti
+ al numero di interruzioni del processore da parte del timer di sistema. A
+ differenza del precedente indica soltanto un intervallo di durata.
+\end{basedescript}
+
+Il \textit{calendar time} viene sempre mantenuto facendo riferimento
+al cosiddetto \textit{tempo universale coordinato} UTC, anche se
+talvolta viene usato il cosiddetto GMT (\textit{Greenwich Mean Time})
+dato che l'UTC corrisponde all'ora locale di Greenwich. Si tratta del
+tempo su cui viene mantenuto il cosiddetto \textsl{orologio di
+ sistema}, e viene usato per indicare i tempi dei file (quelli di
+sez.~\ref{sec:file_file_times}) o le date di avvio dei processi, ed è
+il tempo che viene usato dai demoni che compiono lavori amministrativi
+ad orari definito, come \cmd{cron}.
+
+Si tenga presente che questo tempo è mantenuto dal kernel e non è detto che
+corrisponda al tempo misurato dall'orologio hardware presente su praticamente
+tutte le piastre madri dei computer moderni (il cosiddetto \textit{hardware
+ clock}), il cui valore viene gestito direttamente dall'hardware in maniera
+indipendente e viene usato dal kernel soltanto all'avvio per impostare un
+valore iniziale dell'orologio di sistema. La risoluzione tradizionale data dal
+tipo di dato \type{time\_t} è di un secondo, ma nei sistemi più recenti sono
+disponibili altri tipi di dati con precisioni maggiori.
+
+Si tenga presente inoltre che a differenza di quanto avviene con altri sistemi
+operativi,\footnote{è possibile, ancorché assolutamente sconsigliabile,
+ forzare l'orologio di sistema all'ora locale per compatibilità con quei
+ sistemi operativi che han fatto questa deprecabile scelta.} l'orologio di
+sistema viene mantenuto sempre in UTC e che la conversione all'ora locale del
+proprio fuso orario viene effettuata dalle funzioni di libreria utilizzando le
+opportune informazioni di localizzazione (specificate in
+\conffiled{/etc/timezone}). In questo modo si ha l'assicurazione che l'orologio
+di sistema misuri sempre un tempo monotono crescente come nella realtà, anche
+in presenza di cambi di fusi orari.
+
+\itindend{calendar~time}
+
+Il \textit{process time} invece indica sempre una misura di un lasso di tempo
+e viene usato per tenere conto dei tempi di esecuzione dei processi. Esso
+viene sempre diviso in \textit{user time} e \textit{system time}, per misurare
+la durata di ciascun processo il kernel infatti calcola tre tempi:
+\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{clock time}] il tempo \textsl{reale}, viene chiamato anche
+ \textit{wall clock time} o \textit{elapsed time}, passato dall'avvio del
+ processo. Questo tempo fa riferimento al
+ \textit{calendar time} e dice la durata effettiva dell'esecuzione del
+ processo, ma chiaramente dipende dal carico del sistema e da quanti altri
+ processi stanno girando nello stesso momento.
+
+\item[\textit{user time}] il tempo effettivo che il processore ha impiegato
+ nell'esecuzione delle istruzioni del programma in \textit{user space}. È
+ anche quello riportato nella risorsa \var{ru\_utime} di \struct{rusage}
+ vista in sez.~\ref{sec:sys_resource_use}.
+
+\item[\textit{system time}] il tempo effettivo che il processore ha impiegato
+ per eseguire codice delle \textit{system call} nel kernel per conto del
+ processo. È anche quello riportato nella risorsa \var{ru\_stime} di
+ \struct{rusage} vista in sez.~\ref{sec:sys_resource_use}.
+\end{basedescript}
+
+La somma di \textit{user time} e \textit{system time} indica il
+\textit{process time}, vale a dire il tempo di processore totale che il
+sistema ha effettivamente utilizzato per eseguire il programma di un certo
+processo. Si può ottenere un riassunto dei valori di questi tempi quando si
+esegue un qualsiasi programma lanciando quest'ultimo come argomento del
+comando \cmd{time}.
+
+\itindend{process~time}
+\itindbeg{clock~tick}
+
+Come accennato il \textit{process time} viene misurato nei cosiddetti
+\textit{clock tick}. Un tempo questo corrispondeva al numero di interruzioni
+effettuate dal timer di sistema, oggi lo standard POSIX richiede che esso sia
+espresso come multiplo della costante \constd{CLOCKS\_PER\_SEC} che deve
+essere definita come 1000000, qualunque sia la risoluzione reale dell'orologio
+di sistema e la frequenza delle interruzioni del timer che, come accennato in
+sez.~\ref{sec:proc_hierarchy} e come vedremo a breve, è invece data dalla
+costante \const{HZ}.
+
+Il tipo di dato usato per questo tempo, \type{clock\_t}, con questa
+convenzione ha una risoluzione del microsecondo. Ma non tutte le funzioni di
+sistema come vedremo seguono questa convenzione, in tal caso il numero di
+\textit{clock tick} al secondo può essere ricavato anche attraverso
+\func{sysconf} richiedendo il valore della costante \const{\_SC\_CLK\_TCK}
+(vedi sez.~\ref{sec:sys_limits}). Il vecchio simbolo \const{CLK\_TCK}
+definito in \headfile{time.h} è ormai considerato obsoleto e non deve essere
+usato.
+
+\constbeg{HZ}
+
+In realtà tutti calcoli dei tempi vengono effettuati dal kernel per il
+cosiddetto \textit{software clock}, utilizzando il \textit{timer di sistema} e
+facendo i conti in base al numero delle interruzioni generate dello stesso, i
+cosiddetti \itindex{jiffies} ``\textit{jiffies}''. La durata di un
+``\textit{jiffy}'' è determinata dalla frequenza di interruzione del timer,
+indicata in Hertz, come accennato in sez.~\ref{sec:proc_hierarchy}, dal valore
+della costante \const{HZ} del kernel, definita in \file{asm/param.h}.
+
+Fino al kernel 2.4 il valore di \const{HZ} era 100 su tutte le architetture
+tranne l'alpha, per cui era 1000. Con il 2.6.0 è stato portato a 1000 su tutte
+le architetture, ma dal 2.6.13 il valore è diventato una opzione di
+compilazione del kernel, con un default di 250 e valori possibili di 100, 250,
+1000. Dal 2.6.20 è stato aggiunto anche il valore 300 che è divisibile per le
+frequenze di refresh della televisione (50 o 60 Hz). Si può pensare che questi
+valori determinino anche la corrispondente durata dei \textit{clock tick}, ma
+in realtà questa granularità viene calcolata in maniera indipendente usando la
+costante del kernel \const{USER\_HZ}.
+
+\constend{HZ}
+
+Fino al kernel 2.6.21 la durata di un \textit{jiffy} costituiva la risoluzione
+massima ottenibile nella misura dei tempi impiegabile in una \textit{system
+ call} (ad esempio per i timeout). Con il 2.6.21 e l'introduzione degli
+\textit{high-resolution timers} (HRT) è divenuto possibile ottenere, per le
+funzioni di attesa ed i timer, la massima risoluzione possibile fornita
+dall'hardware. Torneremo su questo in sez.~\ref{sec:sig_timer_adv}.
+
+\itindend{clock~tick}
+
+
+\subsection{La gestione del \textit{process time}}
+\label{sec:sys_cpu_times}
+
+Di norma tutte le operazioni del sistema fanno sempre riferimento al
+\textit{calendar time}, l'uso del \textit{process time} è riservato a
+quei casi in cui serve conoscere i tempi di esecuzione di un processo
+(ad esempio per valutarne l'efficienza). In tal caso infatti fare
+ricorso al \textit{calendar time} è inutile in quanto il tempo può
+essere trascorso mentre un altro processo era in esecuzione o in
+attesa del risultato di una operazione di I/O.
+
+La funzione più semplice per leggere il \textit{process time} di un processo è
+\funcd{clock}, che da una valutazione approssimativa del tempo di CPU
+utilizzato dallo stesso; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{clock\_t clock(void)}
+\fdesc{Legge il valore corrente del tempo di CPU.}
+}
+
+{La funzione ritorna il tempo di CPU in caso di successo e $-1$ se questo non
+ è ottenibile o rappresentabile in un valore di tipo \type{clock\_t},
+ \var{errno} non viene usata.}
+\end{funcproto}
+
+La funzione restituisce il tempo in \textit{clock tick} ma la \acr{glibc}
+segue lo standard POSIX e quindi se si vuole il tempo in secondi occorre
+dividere il risultato per la costante \const{CLOCKS\_PER\_SEC}. In genere
+\type{clock\_t} viene rappresentato come intero a 32 bit, il che comporta un
+valore massimo corrispondente a circa 72 minuti, dopo i quali il contatore
+riprenderà lo stesso valore iniziale.
+
+La funzione è presente anche nello standard ANSI C, ma in tal caso non è
+previsto che il valore ritornato indichi un intervallo di tempo ma solo un
+valore assoluto, per questo se si vuole la massima portabilità anche al di
+fuori di kernel unix-like, può essere opportuno chiamare la funzione
+all'inizio del programma ed ottenere il valore del tempo con una differenza.
+
+Si tenga presente inoltre che con altri kernel unix-like il valore riportato
+dalla funzione può includere anche il tempo di processore usato dai processi
+figli di cui si è ricevuto lo stato di terminazione con \func{wait} e
+affini. Questo non vale per Linux, in cui questa informazione deve essere
+ottenuta separatamente.
+
+Come accennato in sez.~\ref{sec:sys_unix_time} il tempo di processore è la
+somma di altri due tempi, l'\textit{user time} ed il \textit{system time}, che
+sono quelli effettivamente mantenuti dal kernel per ciascun processo. Questi
+possono essere letti separatamente attraverso la funzione \funcd{times}, il
+cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/times.h}
+\fdecl{clock\_t times(struct tms *buf)}
+\fdesc{Legge il valore corrente dei tempi di processore.}
+}
+
+{La funzione ritorna un numero di \textit{clock tick} in caso di successo e
+ $-1$ per un errore, nel qual caso \var{errno} potrà assumere solo il valore
+ \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+La funzione restituisce i valori di \textit{process time} del processo
+corrente in una struttura di tipo \struct{tms}, la cui definizione è riportata
+in fig.~\ref{fig:sys_tms_struct}. La struttura prevede quattro campi; i primi
+due, \var{tms\_utime} e \var{tms\_stime}, sono l'\textit{user time} ed il
+\textit{system time} del processo, così come definiti in
+sez.~\ref{sec:sys_unix_time}. Gli altri due campi, \var{tms\_cutime} e
+\var{tms\_cstime}, riportano la somma dell'\textit{user time} e del
+\textit{system time} di tutti processi figli di cui si è ricevuto lo stato di
+terminazione.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/tms.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{tms} dei tempi di processore associati a un
+ processo.}
+ \label{fig:sys_tms_struct}
+\end{figure}
+
+
+Si tenga presente che i tempi di processore dei processi figli di un processo
+vengono sempre sommati al valore corrente ogni volta che se ne riceve lo stato
+di terminazione, e detto valore è quello che viene a sua volta ottenuto dal
+processo padre. Pertanto nei campi \var{tms\_cutime} e \var{tms\_cstime} si
+sommano anche i tempi di ulteriori discendenti di cui i rispettivi genitori
+abbiano ricevuto lo stato di terminazione.
+
+Si tenga conto che l'aggiornamento di \var{tms\_cutime} e \var{tms\_cstime}
+viene eseguito solo quando una chiamata a \func{wait} o \func{waitpid} è
+ritornata. Per questo motivo se un processo figlio termina prima di ricevere
+lo stato di terminazione di tutti i suoi figli, questi processi
+``\textsl{nipoti}'' non verranno considerati nel calcolo di questi tempi e
+così via per i relativi ``\textsl{discendenti}''.
+
+Come accennato in sez.~\ref{sec:sys_resource_use} per i kernel precedenti la
+versione 2.6.9 il tempo di processore dei processi figli veniva sommato
+comunque chiedendo di ignorare \signal{SIGCHLD} anche se lo standard POSIX
+richiede esplicitamente che questo avvenga solo quando si riceve lo stato di
+uscita con una funzione della famiglia delle \func{wait}, anche in questo caso
+il comportamento è stato adeguato allo standard a partire dalla versione
+2.6.9.
+
+A differenza di quanto avviene per \func{clock} i valori restituiti nei campi
+di una struttura \struct{tms} sono misurati in numero di \textit{clock tick}
+effettivi e non in multipli di \const{CLOCKS\_PER\_SEC}, pertanto per ottenere
+il valore effettivo del tempo in secondi occorrerà dividere per il risultato
+di \code{sysconf(\_SC\_CLK\_TCK)}.
+
+Lo stesso vale per il valore di ritorno della funzione, il cui significato fa
+riferimento ad un tempo relativo ad un certo punto nel passato la cui
+definizione dipende dalle diverse implementazioni, e varia anche fra diverse
+versioni del kernel. Fino al kernel 2.4 si faceva infatti riferimento al
+momento dell'avvio del kernel. Con il kernel 2.6 si fa riferimento a
+$2^{32}/\mathtt{HZ}-300$ secondi prima dell'avvio.
+
+Considerato che il numero dei \textit{clock tick} per un kernel che è attivo
+da molto tempo può eccedere le dimensioni per il tipo \type{clock\_t} il
+comportamento più opportuno per i programmi è di ignorare comunque il valore
+di ritorno della funzione e ricorrere alle funzioni per il tempo di calendario
+del prossimo paragrafo qualora si voglia calcolare il tempo effettivamente
+trascorso dall'inizio del programma.
+
+Infine si tenga presente che per dei limiti nelle convenzioni per il ritorno
+dei valori delle \textit{system call} su alcune architetture hardware (ed in
+particolare la \texttt{i386} dei PC a 32 bit) nel kernel della serie 2.6 il
+valore di ritorno della funzione può risultare erroneamente uguale a $-1$,
+indicando un errore, nei primi secondi dopo il boot (per la precisione nei
+primi 41 secondi) e se il valore del contatore eccede le dimensione del tipo
+\type{clock\_t}.
+
+
+\subsection{Le funzioni per il \textit{calendar time}}
+\label{sec:sys_time_base}
+
+\itindbeg{calendar~time}
+
+Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time}
+viene espresso normalmente con 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 nel suddetto
+formato, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{time\_t time(time\_t *t)}
+\fdesc{Legge il valore corrente del \textit{calendar time}.}
+}
+
+{La funzione ritorna il valore del \textit{calendar time} in caso di successo
+ e $-1$ per un errore, nel qual caso \var{errno} potrà assumere solo il
+ valore \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+L'argomento \param{t}, se non nullo, deve essere l'indirizzo di una variabile
+su cui duplicare il valore di ritorno.
+
+Analoga a \func{time} è la funzione \funcd{stime} che serve per effettuare
+l'operazione inversa, e cioè per impostare il tempo di sistema qualora questo
+sia necessario; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{int stime(time\_t *t)}
+\fdesc{Imposta il valore corrente del \textit{calendar time}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] non si hanno i permessi di amministrazione.
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+
+Dato che modificare l'ora ha un impatto su tutto il sistema il cambiamento
+dell'orologio è una operazione privilegiata e questa funzione può essere usata
+solo da un processo con i privilegi di amministratore (per la precisione la
+\textit{capability} \const{CAP\_SYS\_TIME}), altrimenti la chiamata fallirà
+con un errore di \errcode{EPERM}.
+
+Data la scarsa precisione nell'uso di \type{time\_t}, che ha una risoluzione
+massima di un secondo, quando si devono effettuare operazioni sui tempi di
+norma l'uso delle due funzioni precedenti è sconsigliato, ed esse sono di
+solito sostituite da \funcd{gettimeofday} e \funcd{settimeofday},\footnote{le
+ due funzioni \func{time} e \func{stime} sono più antiche e derivano da SVr4,
+ \func{gettimeofday} e \func{settimeofday} sono state introdotte da BSD, ed
+ in BSD4.3 sono indicate come sostitute delle precedenti, \func{gettimeofday}
+ viene descritta anche in POSIX.1-2001.} i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fhead{time.h}
+\fdecl{int gettimeofday(struct timeval *tv, struct timezone *tz)}
+\fdesc{Legge il tempo corrente del sistema.}
+\fdecl{int settimeofday(const struct timeval *tv, const struct timezone *tz)}
+\fdesc{Imposta il tempo di sistema.}
+}
+
+{La funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà i valori \errval{EINVAL}, \errval{EFAULT} e per
+ \func{settimeofday} anche \errval{EPERM}, nel loro significato generico.}
+\end{funcproto}
+
+
+Si noti come queste funzioni utilizzino per indicare il tempo una struttura di
+tipo \struct{timeval}, la cui definizione si è già vista in
+fig.~\ref{fig:sys_timeval_struct}, questa infatti permette una espressione
+alternativa dei valori del \textit{calendar time}, con una precisione,
+rispetto a \type{time\_t}, fino al microsecondo, ma la precisione è solo
+teorica, e la precisione reale della misura del tempo dell'orologio di sistema
+non dipende dall'uso di queste strutture.
+
+Come nel caso di \func{stime} anche \func{settimeofday} può essere utilizzata
+solo da un processo coi privilegi di amministratore e più precisamente con la
+capacità \const{CAP\_SYS\_TIME}. Si tratta comunque di una condizione generale
+che continua a valere per qualunque funzione che vada a modificare l'orologio
+di sistema, comprese tutte quelle che tratteremo in seguito.
+
+\itindbeg{timezone}
+
+Il secondo argomento di entrambe le funzioni è una struttura
+\struct{timezone}, che storicamente veniva utilizzata per specificare appunto
+la cosiddetta \textit{timezone}, cioè l'insieme del fuso orario e delle
+convenzioni per l'ora legale che permettevano il passaggio dal tempo
+universale all'ora locale. Questo argomento oggi è obsoleto ed in Linux non è
+mai stato utilizzato; esso non è supportato né dalla vecchia \textsl{libc5},
+né dalla \textsl{glibc}: pertanto quando si chiama questa funzione deve essere
+sempre impostato a \val{NULL}.
+
+\itindbeg{timezone}
+
+Modificare l'orologio di sistema con queste funzioni è comunque problematico,
+in quanto esse effettuano un cambiamento immediato. Questo può creare dei
+buchi o delle ripetizioni nello scorrere dell'orologio di sistema, con
+conseguenze indesiderate. Ad esempio se si porta avanti l'orologio si possono
+perdere delle esecuzioni di \cmd{cron} programmate nell'intervallo che si è
+saltato. Oppure se si porta indietro l'orologio si possono eseguire due volte
+delle operazioni previste nell'intervallo di tempo che viene ripetuto.
+
+Per questo motivo la modalità più corretta per impostare l'ora è quella di
+usare la funzione \funcd{adjtime}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/time.h}
+\fdecl{int adjtime(const struct timeval *delta, struct timeval *olddelta)}
+\fdesc{Aggiusta l'orologio di sistema.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{delta} eccede il massimo
+ consentito.
+ \item[\errcode{EPERM}] il processo non i privilegi di amministratore.
+ \end{errlist}
+}
+\end{funcproto}
+
+
+Questa funzione permette di avere un aggiustamento graduale del tempo di
+sistema in modo che esso sia sempre crescente in maniera monotona. Il valore
+indicato nella struttura \struct{timeval} puntata da \param{delta} esprime il
+valore di cui si vuole spostare l'orologio. Se è positivo l'orologio sarà
+accelerato per un certo tempo in modo da guadagnare il tempo richiesto,
+altrimenti sarà rallentato.
+
+La funzione è intesa per piccoli spostamenti del tempo di sistema, ed esistono
+pertanto dei limiti massimi per i valori che si possono specificare
+per \param{delta}. La \acr{glibc} impone un intervallo compreso fra
+\code{INT\_MIN/1000000 + 2} e \code{INT\_MAX/1000000 - 2}, corrispondente, su
+una architettura PC ordinaria a 32 bit, ad un valore compreso fra $-2145$ e
+$2145$ secondi.
+
+Inoltre se si invoca la funzione prima che una precedente richiesta di
+aggiustamento sia stata completata, specificando un altro valore, il
+precedente aggiustamento viene interrotto, ma la parte dello stesso che è già
+stata completata non viene rimossa. Però è possibile in questo caso farsi
+restituire nella struttura puntata da \param{olddelta} il tempo restante della
+precedente richiesta. Fino al kernel 2.6.26 ed alla \acr{glibc} 2.8 questo
+però era possibile soltanto specificando un diverso aggiustamento
+per \param{delta}, il bug è stato corretto a partire dalle versioni citate e
+si può ottenere l'informazione relativa alla frazione di aggiustamento
+mancante usando il valore \val{NULL} per \param{delta}.
+
+Linux poi prevede una specifica funzione di sistema che consente un
+aggiustamento molto più dettagliato del tempo, permettendo ad esempio anche di
+regolare anche la velocità e le derive dell'orologio di sistema. La funzione
+è \funcd{adjtimex} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/timex.h}
+\fdecl{int adjtimex(struct timex *buf)}
+\fdesc{Regola l'orologio di sistema.}
+}
+
+{La funzione ritorna lo stato dell'orologio (un valore $\ge 0$) in caso di
+ successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
+ valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] si sono indicati valori fuori dall'intervallo
+ consentito per qualcuno dei campi di \param{buf}.
+ \item[\errcode{EPERM}] si è richiesta una modifica dei parametri ed il
+ processo non ha i privilegi di amministratore.
+ \end{errlist}
+ ed inoltre \errval{EFAULT} nel suo significato generico.}
+\end{funcproto}
+
+In caso di successo la funzione restituisce un valore numerico non negativo
+che indica lo stato dell'orologio, che può essere controllato con i valori
+delle costanti elencate in tab.~\ref{tab:adjtimex_return}.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|c|l|}
+ \hline
+ \textbf{Nome} & \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \constd{TIME\_OK} & 0 & Orologio sincronizzato.\\
+ \constd{TIME\_INS} & 1 & Inserimento di un \textit{leap second}.\\
+ \constd{TIME\_DEL} & 2 & Cancellazione di un \textit{leap second}.\\
+ \constd{TIME\_OOP} & 3 & \textit{leap second} in corso.\\
+ \constd{TIME\_WAIT} & 4 & \textit{leap second} avvenuto.\\
+ \constd{TIME\_BAD} & 5 & Orologio non sincronizzato.\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori ritornati da \func{adjtimex} in caso di successo.}
+ \label{tab:adjtimex_return}
+\end{table}
+
+La funzione richiede come argomento il puntatore ad una struttura di tipo
+\struct{timex}, la cui definizione, effettuata in \headfiled{sys/timex.h}, è
+riportata in fig.~\ref{fig:sys_timex_struct} per i campi che interessano la
+possibilità di essere modificati documentati anche nella pagina di manuale. In
+realtà la struttura è stata estesa con ulteriori campi, i cui valori sono
+utilizzabili solo in lettura, la cui definizione si può trovare direttamente
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/timex.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{timex} per il controllo dell'orologio di
+ sistema.}
+ \label{fig:sys_timex_struct}
+\end{figure}
+
+L'azione della funzione dipende dal valore del campo \var{mode}
+di \param{buf}, che specifica quale parametro dell'orologio di sistema,
+specificato nel corrispondente campo di \struct{timex}, deve essere
+impostato. Un valore nullo serve per leggere i parametri correnti, i valori
+diversi da zero devono essere specificati come OR binario delle costanti
+riportate in tab.~\ref{tab:sys_timex_mode}.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|c|p{8cm}|}
+ \hline
+ \textbf{Nome} & \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \constd{ADJ\_OFFSET} & 0x0001 & Imposta la differenza fra il tempo
+ reale e l'orologio di sistema:
+ deve essere indicata in microsecondi
+ nel campo \var{offset} di
+ \struct{timex}.\\
+ \constd{ADJ\_FREQUENCY} & 0x0002 & Imposta la differenza in frequenza
+ fra il tempo reale e l'orologio di
+ sistema: deve essere indicata
+ in parti per milione nel campo
+ \var{frequency} di \struct{timex}.\\
+ \constd{ADJ\_MAXERROR} & 0x0004 & Imposta il valore massimo
+ dell'errore sul tempo, espresso in
+ microsecondi nel campo
+ \var{maxerror} di \struct{timex}.\\
+ \constd{ADJ\_ESTERROR} & 0x0008 & Imposta la stima dell'errore
+ sul tempo, espresso in microsecondi
+ nel campo \var{esterror} di
+ \struct{timex}.\\
+ \constd{ADJ\_STATUS} & 0x0010 & Imposta alcuni valori di stato
+ interni usati dal
+ sistema nella gestione
+ dell'orologio specificati nel campo
+ \var{status} di \struct{timex}.\\
+ \constd{ADJ\_TIMECONST} & 0x0020 & Imposta la larghezza di banda del
+ PLL implementato dal kernel,
+ specificato nel campo
+ \var{constant} di \struct{timex}.\\
+ \constd{ADJ\_TICK} & 0x4000 & Imposta il valore dei \textit{tick}
+ del timer in
+ microsecondi, espresso nel campo
+ \var{tick} di \struct{timex}.\\
+ \constd{ADJ\_OFFSET\_SINGLESHOT}&0x8001&Chiede uno spostamento una tantum
+ dell'orologio secondo il valore del
+ campo \var{offset} simulando il
+ comportamento di \func{adjtime}.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti per l'assegnazione del valore del campo \var{mode} della
+ struttura \struct{timex}.}
+ \label{tab:sys_timex_mode}
+\end{table}
+
+La funzione utilizza il meccanismo di David L. Mills, descritto
+nell'\href{http://www.ietf.org/rfc/rfc1305.txt}{RFC~1305}, che è alla base del
+protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la
+portabilità è un requisito, la \acr{glibc} provvede anche un suo omonimo
+\func{ntp\_adjtime}. La trattazione completa di questa funzione necessita di
+una lettura approfondita del meccanismo descritto nell'RFC~1305, ci limitiamo
+a descrivere in tab.~\ref{tab:sys_timex_mode} i principali valori utilizzabili
+per il campo \var{mode}, un elenco più dettagliato del significato dei vari
+campi della struttura \struct{timex} può essere ritrovato in \cite{GlibcMan}.
+
+Il valore delle costanti per \var{mode} può essere anche espresso, secondo la
+sintassi specificata per la forma equivalente di questa funzione definita come
+\func{ntp\_adjtime}, utilizzando il prefisso \code{MOD} al posto di
+\code{ADJ}.
+
+Si tenga presente infine che con l'introduzione a partire dal kernel 2.6.21
+degli \textit{high-resolution timer} ed il supporto per i cosiddetti POSIX
+\textit{real-time clock}, si può ottenere il \textit{calendar time}
+direttamente da questi, come vedremo in sez.~\ref{sec:sig_timer_adv}, con la
+massima risoluzione possibile per l'hardware della macchina.
+
+
+
+\subsection{La gestione delle date.}
+\label{sec:sys_date}
+
+\itindbeg{broken-down~time}
+
+Le funzioni viste al paragrafo precedente sono molto utili per trattare le
+operazioni elementari sui tempi, però le rappresentazioni del tempo ivi
+illustrate, se han senso per specificare un intervallo, non sono molto
+intuitive quando si deve esprimere un'ora o una data. Per questo motivo è
+stata introdotta una ulteriore rappresentazione, detta \textit{broken-down
+ time}, che permette appunto di \textsl{suddividere} il \textit{calendar
+ time} usuale in ore, minuti, secondi, ecc. e viene usata tenendo conto
+anche dell'eventuale utilizzo di un fuso orario.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{.8\textwidth}
+ \includestruct{listati/tm.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{tm} per una rappresentazione del tempo in
+ termini di ora, minuti, secondi, ecc.}
+ \label{fig:sys_tm_struct}
+\end{figure}
+
+Questo viene effettuato attraverso una opportuna struttura \struct{tm}, la cui
+definizione è riportata in fig.~\ref{fig:sys_tm_struct}, ed è in genere questa
+struttura che si utilizza quando si deve specificare un tempo a partire dai
+dati naturali (ora e data), dato che essa consente anche di tenere conto della
+gestione del fuso orario e dell'ora legale. In particolare gli ultimi due
+campi, \var{tm\_gmtoff} e \var{tm\_zone}, sono estensioni previste da BSD e
+supportate dalla \acr{glibc} quando è definita la macro \macro{\_BSD\_SOURCE}.
+
+Ciascuno dei campi di \struct{tm} ha dei precisi intervalli di valori
+possibili, con convenzioni purtroppo non troppo coerenti. Ad esempio
+\var{tm\_sec} che indica i secondi deve essere nell'intervallo da 0 a 59, ma è
+possibile avere anche il valore 60 per un cosiddetto \textit{leap second} (o
+\textsl{secondo intercalare}), cioè uno di quei secondi aggiunti al calcolo
+dell'orologio per effettuare gli aggiustamenti del calendario per tenere conto
+del disallineamento con il tempo solare.\footnote{per dettagli si consulti
+ \url{http://it.wikipedia.org/wiki/Leap_second}.}
+
+I campi \var{tm\_min} e\var{tm\_hour} che indicano rispettivamente minuti ed
+ore hanno valori compresi rispettivamente fra 0 e 59 e fra 0 e 23. Il campo
+\var{tm\_mday} che indica il giorno del mese prevede invece un valore compreso
+fra 1 e 31, ma la \acr{glibc} supporta pure il valore 0 come indicazione
+dell'ultimo giorno del mese precedente. Il campo \var{tm\_mon} indica il mese
+dell'anno a partire da gennaio con valori compresi fra 0 e 11.
+
+I campi \var{tm\_wday} e \var{tm\_yday} indicano invece rispettivamente il
+giorno della settimana, a partire dalla Domenica, ed il giorno dell'anno, a
+partire del primo gennaio, ed hanno rispettivamente valori compresi fra 0 e 6
+e fra 0 e 365. L'anno espresso da \var{tm\_year} viene contato come numero di
+anni a partire dal 1900. Infine \var{tm\_isdst} è un valore che indica se per
+gli altri campi si intende come attiva l'ora legale ed influenza il
+comportamento di \func{mktime}.
+
+
+Le funzioni per la gestione del \textit{broken-down time} sono varie e vanno
+da quelle usate per convertire gli altri formati in questo, usando o meno
+l'ora locale o il tempo universale, a quelle per trasformare il valore di un
+tempo in una stringa contenente data ed ora. Le prime due funzioni,
+\funcd{asctime} e \funcd{ctime} servono per poter stampare in forma leggibile
+un tempo, i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{char * asctime(const struct tm *tm)}
+\fdesc{Converte un \textit{broken-down time} in una stringa.}
+\fdecl{char * ctime(const time\_t *timep)}
+\fdesc{Converte un \textit{calendar time} in una stringa.}
+}
+
+{Le funzioni ritornano un puntatore al risultato in caso di successo e
+ \val{NULL} per un errore, \var{errno} non viene modificata.}
+\end{funcproto}
+
+Le funzioni prendono rispettivamente come argomenti i puntatori ad una
+struttura \struct{tm} contenente un \textit{broken-down time} o ad una
+variabile di tipo \type{time\_t} che esprime il \textit{calendar time},
+restituendo il puntatore ad una stringa che esprime la data, usando le
+abbreviazioni standard di giorni e mesi in inglese, nella forma:
+\begin{Example}
+Sun Apr 29 19:47:44 2012\n"
+\end{Example}
+
+Nel caso di \func{ctime} la funzione tiene conto della eventuale impostazione
+di una \textit{timezone} e effettua una chiamata preventiva a \func{tzset}
+(che vedremo a breve), in modo che la data espressa tenga conto del fuso
+orario. In realtà \func{ctime} è banalmente definita in termini di
+\func{asctime} come \code{asctime(localtime(t)}.
+
+Dato che l'uso di una stringa statica rende le funzioni non rientranti
+POSIX.1c e SUSv2 prevedono due sostitute rientranti, il cui nome è al solito
+ottenuto aggiungendo un \code{\_r}, che prendono un secondo argomento
+\code{char *buf}, in cui l'utente deve specificare il buffer su cui la stringa
+deve essere copiata (deve essere di almeno 26 caratteri).
+
+Per la conversione fra \textit{broken-down time} e \textit{calendar time} sono
+invece disponibili altre tre funzioni, \funcd{gmtime}, \funcd{localtime} e
+\funcd{mktime} i cui prototipi sono:
+
+\begin{funcproto}{
+\fdecl{struct tm * gmtime(const time\_t *timep)}
+\fdesc{Converte un \textit{calendar time} in un \textit{broken-down time} in
+ UTC.}
+\fdecl{struct tm * localtime(const time\_t *timep)}
+\fdesc{Converte un \textit{calendar time} in un \textit{broken-down time}
+ nell'ora locale.}
+\fdecl{time\_t mktime(struct tm *tm)}
+\fdesc{Converte un \textit{broken-down time} in un \textit{calendar time}.}
+
+}
+
+{Le funzioni ritornano un puntatore al risultato in caso di successo e
+ \val{NULL} per un errore, tranne che \func{mktime} che restituisce
+ direttamente il valore o $-1$ in caso di errore, \var{errno} non viene
+ modificata.}
+\end{funcproto}
+
+Le le prime funzioni, \func{gmtime}, \func{localtime} servono per convertire
+il tempo in \textit{calendar time} specificato da un argomento di tipo
+\type{time\_t} restituendo un \textit{broken-down time} con il puntatore ad
+una struttura \struct{tm}. La prima effettua la conversione senza tenere conto
+del fuso orario, esprimendo la data in tempo coordinato universale (UTC), cioè
+l'ora di Greenwich, mentre \func{localtime} usa l'ora locale e per questo
+effettua una chiamata preventiva a \func{tzset}.
+
+Anche in questo caso le due funzioni restituiscono l'indirizzo di una
+struttura allocata staticamente, per questo sono state definite anche altre
+due versioni rientranti (con la solita estensione \code{\_r}), che prevedono
+un secondo argomento \code{struct tm *result}, fornito dal chiamante, che deve
+preallocare la struttura su cui sarà restituita la conversione. La versione
+rientrante di \func{localtime} però non effettua la chiamata preventiva a
+\func{tzset} che deve essere eseguita a cura dell'utente.
+
+Infine \func{mktime} esegue la conversione di un \textit{broken-down time} a
+partire da una struttura \struct{tm} restituendo direttamente un valore di
+tipo \type{time\_t} con il \textit{calendar time}. La funzione ignora i campi
+\var{tm\_wday} e \var{tm\_yday} e per gli altri campi normalizza eventuali
+valori fuori degli intervalli specificati in precedenza: se cioè si indica un
+12 per \var{tm\_mon} si prenderà il gennaio dell'anno successivo. Inoltre la
+funzione tiene conto del valore di \var{tm\_isdst} per effettuare le
+correzioni relative al fuso orario: un valore positivo indica che deve essere
+tenuta in conto l'ora legale, un valore nullo che non deve essere applicata
+nessuna correzione, un valore negativo che si deve far ricorso alle
+informazioni relative al proprio fuso orario per determinare lo stato dell'ora
+legale.
+
+La funzione inoltre modifica i valori della struttura \struct{tm} in forma di
+\textit{value result argument}, normalizzando i valori dei vari campi,
+impostando i valori risultanti per \var{tm\_wday} e \var{tm\_yday} e
+assegnando a \var{tm\_isdst} il valore (positivo o nullo) corrispondente allo
+stato dell'ora legale. La funzione inoltre provvede ad impostare il valore
+della variabile globale \var{tzname}.
+
+\itindend{calendar~time}
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{.75\textwidth}
+ \includestruct{listati/time_zone_var.c}
+ \end{minipage}
+ \normalsize
+ \caption{Le variabili globali usate per la gestione delle
+ \textit{timezone}.}
+ \label{fig:sys_tzname}
+\end{figure}
+
+Come accennato l'uso del \textit{broken-down time} permette di tenere conto
+anche della differenza fra tempo universale e ora locale, compresa l'eventuale
+ora legale. Questo viene fatto dalle funzioni di conversione grazie alle
+informazioni riguardo la propria \textit{timezone} mantenute nelle tre
+variabili globali mostrate in fig.~\ref{fig:sys_tzname}, cui si può accedere
+direttamente includendo \headfile{time.h}. Come illustrato queste variabili
+vengono impostate internamente da alcune delle precedenti funzioni di
+conversione, ma lo si può fare esplicitamente chiamando direttamente la
+funzione \funcd{tzset}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{void tzset(void)}
+\fdesc{Imposta le variabili globali della \textit{timezone}.}
+}
+
+{La funzione non ritorna niente e non dà errori.}
+\end{funcproto}
+
+La funzione inizializza le variabili di fig.~\ref{fig:sys_tzname} a partire
+dal valore della variabile di ambiente \envvar{TZ}, se quest'ultima non è
+definita verrà usato il file \conffiled{/etc/localtime}. La variabile
+\var{tzname} contiene due stringhe, che indicano i due nomi standard della
+\textit{timezone} corrente. La prima è il nome per l'ora solare, la seconda
+per l'ora legale. Anche se in fig.~\ref{fig:sys_tzname} sono indicate come
+\code{char *} non è il caso di modificare queste stringhe. La variabile
+\var{timezone} indica la differenza di fuso orario in secondi, mentre
+\var{daylight} indica se è attiva o meno l'ora legale.
+
+Benché la funzione \func{asctime} fornisca la modalità più immediata per
+stampare un tempo o una data, la flessibilità non fa parte delle sue
+caratteristiche; quando si vuole poter stampare solo una parte (l'ora, o il
+giorno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime},
+il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{size\_t strftime(char *s, size\_t max, const char *format,
+ const struct tm *tm)}
+\fdesc{Crea una stringa con una data secondo il formato indicato.}
+}
+
+{La funzione ritorna il numero di caratteri inseriti nella stringa \param{s}
+ oppure $0$, \var{errno} non viene modificata.}
+\end{funcproto}
+
+
+La funzione converte il \textit{broken-down time} indicato nella struttura
+puntata dall'argomento \param{tm} in una stringa di testo da salvare
+all'indirizzo puntato dall'argomento \param{s}, purché essa sia di dimensione
+inferiore al massimo indicato dall'argomento \param{max}. Il numero di
+caratteri generati dalla funzione viene restituito come valore di ritorno,
+senza tener però conto del terminatore finale, che invece viene considerato
+nel computo della dimensione. Se quest'ultima è eccessiva viene restituito 0 e
+lo stato di \param{s} è indefinito.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|c|l|p{6cm}|}
+ \hline
+ \textbf{Modificatore} & \textbf{Esempio} & \textbf{Significato}\\
+ \hline
+ \hline
+ \var{\%a}&\texttt{Wed} & Nome del giorno, abbreviato.\\
+ \var{\%A}&\texttt{Wednesday} & Nome del giorno, completo.\\
+ \var{\%b}&\texttt{Apr} & Nome del mese, abbreviato.\\
+ \var{\%B}&\texttt{April} & Nome del mese, completo.\\
+ \var{\%c}&\texttt{Wed Apr 24 18:40:50 2002}& Data e ora.\\
+ \var{\%d}&\texttt{24} & Giorno del mese.\\
+ \var{\%H}&\texttt{18} & Ora del giorno, da 0 a 24.\\
+ \var{\%I}&\texttt{06} & Ora del giorno, da 0 a 12.\\
+ \var{\%j}&\texttt{114} & Giorno dell'anno.\\
+ \var{\%m}&\texttt{04} & Mese dell'anno.\\
+ \var{\%M}&\texttt{40} & Minuto.\\
+ \var{\%p}&\texttt{PM} & AM/PM.\\
+ \var{\%S}&\texttt{50} & Secondo.\\
+ \var{\%U}&\texttt{16} & Settimana dell'anno (partendo dalla
+ domenica).\\
+ \var{\%w}&\texttt{3} & Giorno della settimana.\\
+ \var{\%W}&\texttt{16} & Settimana dell'anno (partendo dal
+ lunedì).\\
+ \var{\%x}&\texttt{04/24/02} & La data.\\
+ \var{\%X}&\texttt{18:40:50} & L'ora.\\
+ \var{\%y}&\texttt{02} & Anno nel secolo.\\
+ \var{\%Y}&\texttt{2002} & Anno.\\
+ \var{\%Z}&\texttt{CEST} & Nome della \textit{timezone}.\\
+ \var{\%\%}&\texttt{\%} & Il carattere \%.\\
+ \hline
+ \end{tabular}
+ \caption{Valori previsti dallo standard ANSI C per modificatore della
+ stringa di formato di \func{strftime}.}
+ \label{tab:sys_strftime_format}
+\end{table}
+
+Il risultato della funzione è controllato dalla stringa di formato
+\param{format}, tutti i caratteri restano invariati eccetto \texttt{\%} che
+viene utilizzato come modificatore. Alcuni dei possibili valori che esso può
+assumere sono riportati in tab.~\ref{tab:sys_strftime_format}.\footnote{per la
+ precisione si sono riportati definiti dallo standard ANSI C, che sono anche
+ quelli ripresi in POSIX.1; la \acr{glibc} fornisce anche le estensioni
+ introdotte da POSIX.2 per il comando \cmd{date}, i valori introdotti da
+ SVID3 e ulteriori estensioni GNU; l'elenco completo dei possibili valori è
+ riportato nella pagina di manuale della funzione.} La funzione tiene conto
+anche delle eventuali impostazioni di localizzazione per stampare i vari nomi
+in maniera adeguata alla lingua scelta, e con le convenzioni nazionali per i
+formati di data ed ora.
+
+Infine per effettuare l'operazione di conversione inversa, da una stringa ad
+un \textit{broken-down time}, si può utilizzare la funzione \funcd{strptime},
+il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{time.h}
+\fdecl{char *strptime(const char *s, const char *format, struct tm *tm)}
+\fdesc{Converte una stringa con in un \textit{broken-down time} secondo un
+ formato.}
+}
+
+{La funzione ritorna il puntatore al primo carattere non processato della
+ stringa o al terminatore finale qualora questa sia processata interamente,
+ \var{errno} non viene modificata.}
+\end{funcproto}
+
+La funzione processa la stringa puntata dall'argomento \param{s} da sinistra a
+destra, utilizzando il formato contenuto nella stringa puntata
+dall'argomento \param{format}, avvalorando volta volta i corrispondenti campi
+della struttura puntata dall'argomento \param{tm}. La scansione si interrompe
+immediatamente in caso di mancata corrispondenza a quanto indicato nella
+stringa di formato, che usa una sintassi analoga a quella già vista per
+\func{strftime}. La funzione supporta i modificatori di
+tab.~\ref{tab:sys_strftime_format} più altre estensioni, ma per i dettagli a
+questo riguardo si rimanda alla lettura della pagina di manuale.
+
+Si tenga presente comunque che anche in caso di scansione completamente
+riuscita la funzione sovrascrive soltanto i campi di \param{tm} indicati dal
+formato, la struttura originaria infatti non viene inizializzati e gli altri
+campi restano ai valori che avevano in precedenza.
+
+
+\itindend{broken-down~time}
+