e degli errori.
-\section{La gestione di catteristiche e parametri del sistema}
+\section{La gestione di caratteristiche e parametri del sistema}
\label{sec:sys_characteristics}
In questa sezione tratteremo le varie modalità con cui un programma può
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 trattremo qui.} Dato che POSIX non prevede questa possibilità
+ 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
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, portanto la posizione
+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}''.
opportune operazioni interagendo con il BIOS ed i dispositivi che controllano
l'erogazione della potenza.
-Ia funzione di sistema che controlla lo spegnimento ed il riavvio (ed altri
+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
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 inlcudendo il relativo supporto.\footnote{deve
+ 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
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
+ (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
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 direttettamente. Questo meccanismo consente di evitare la
+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
\label{fig:kexec_segment}
\end{figure}
-L'argomento \param{flags} è una maschera binaria che contiene i flag che
-consentono di indicare alcune specifiche relative alle 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.
+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
\end{table}
I due valori più importanti sono però quelli della parte più significativa
-di \param{flags} (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,
+(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.
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}, \var{ru\_majflt}, e \var{ru\_nswap}. Con i kernel della
-serie 2.6 si aggiungono anche \var{ru\_nvcsw} e \var{ru\_nivcsw}, e a partire
-dal 2.6.22 anche \var{ru\_inblock} e \var{ru\_oublock}.
-
-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 user space, e quello impiegato dal kernel nelle \textit{system
- call} eseguite per conto del processo. I campi \var{ru\_minflt} e
-\var{ru\_majflt} servono a quantificare l'uso della memoria
-virtuale\index{memoria~virtuale} e corrispondono rispettivamente al numero di
-\itindex{page~fault} \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
+\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
\begin{errlist}
\item[\errcode{EINVAL}] l'argomento \param{who} non è valido
\end{errlist}
- ed inoltre \errval{EFAULT} nel suo significato generico.
+ ed inoltre \errval{EFAULT} nel suo significato generico.
}
\end{funcproto}
\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\index{memoria~virtuale} e
+corrispondono rispettivamente al numero di \itindex{page~fault} \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
+\itindex{Resident~Set~Size~(RSS)} \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\_ING} per il segnale \const{SIGCHLD} (per i segnali si
+azione di \const{SIG\_IGN} per il segnale \const{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.
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 \itindex{core~dump} \textit{core dump}.
+\const{RLIMIT\_CORE} che influenza soltanto la dimensione o l'eventuale
+creazione dei file di \itindex{core~dump} \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}
\fhead{sys/resource.h}
\fhead{unistd.h}
\fdecl{int getrlimit(int resource, struct rlimit *rlim)}
-\fdesc{Legge il limite corrente di una risorsa.}
+\fdesc{Legge i limiti di una risorsa.}
\fdecl{int setrlimit(int resource, const struct rlimit *rlim)}
-\fdesc{Imposta il limite di una risorsa.}
+\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.
+ \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}
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; ma si ricordi che solo un
+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 \itindex{capabilities} \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.
-Come accennato ciascuna risorsa è 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:
+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[\const{RLIMIT\_AS}] Questa risorsa indica, in byte, la dimensione
\item[\const{RLIMIT\_CORE}] Questa risorsa indica, in byte, la massima
dimensione per un file di \itindex{core~dump} \textit{core dump} (vedi
- sez.~\ref{sec:sig_prog_error}) 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 \itindex{core~dump}
- \textit{core dump}.
+ 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 \itindex{core~dump} \textit{core
+ dump}.
\item[\const{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
\errcode{EAGAIN}.
\item[\const{RLIMIT\_RSS}] Questa risorsa indica, in pagine di memoria, la
- dimensione massima della memoria residente (il codiddetto RSS
+ 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 \index{segmento!testo} segmento testo
- del programma). Ha effetto solo sulle chiamate a \func{madvise} con
+ in RAM e non a quella eventualmente portata sulla \textit{swap} o non ancora
+ caricata dal filesystem per il \index{segmento!testo} 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[\const{RLIMIT\_RTPRIO}] Questa risorsa indica il
+\item[\const{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[\const{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.
% TODO trattare i seguenti...
-% \const{RLIMIT\_RTPRIO}& Il numero massimo di \\
% aggiungere i limiti che mancano come RLIMIT_RTTIME introdotto con il 2.6.25
% vedi file include/asm-generic/resource.h
-\item[\const{RLIMIT\_SIGPENDING}] Il numero massimo di segnali che possono
- essere mantenuti in coda per ciascun utente, considerando sia i segnali
- normali che real-time (vedi sez.~\ref{sec:sig_real_time}). Il limite è
+\item[\const{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.\footnote{il limite su questa
- risorsa è stato introdotto con il kernel 2.6.8.}
-
+ segnale che non sia già presente su una coda. Questo limite è stato
+ introdotto con il kernel 2.6.8.
+
+\item[\const{RLIMIT\_STACK}] Questa risorsa indica, in byte, la massima
+ dimensione dello \itindex{stack} \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.
-\item[\const{RLIMIT\_RSS}] L'ammontare massimo di pagine di memoria dato al
- \index{segmento!testo} testo del processo. Il limite è solo una indicazione
- per il kernel, qualora ci fosse un surplus di memoria questa verrebbe
- assegnata.
-
-\item[\const{RLIMIT\_STACK}] La massima dimensione dello \itindex{stack}
- \textit{stack} del processo. Se il processo esegue operazioni che estendano
- lo \textit{stack} oltre questa dimensione riceverà un segnale di
- \signal{SIGSEGV}.
-
-% TODO dal 2.6.23 il significato è cambiato, vedi anche man execve
-
-% TODO: aggiungere a \const{RLIMIT\_STACK} i dati di execve:
-% Questi fino al kernel 2.6.23 erano fissi e costituiti da
-% 32 pagine di memoria (corrispondenti per la gran parte delle architetture a
-% 128kb di dati). Dal 2.6.23 su molte architettire il limite viene stabilito in
-% base al valore della risorsa \const{RLIMIT\_STACK} (vedi
-% sez.~\ref{sec:sys_resource_limit}), ad un quarto dello spazio da essa
-% indicato). Dal 2.6.25 viene comunque garantito uno spazio base di 32 pagine.
-
-% TODO integrare con la roba di madvise
-% TODO integrare con le ultime aggiunte, vedi pagina di manuale
+\end{basedescript}
-% TODO trattare prlimit64 introdotta con il 2.6.36 che dovrebbe sostituire
-% setrlimit
+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}).
-\end{basedescript}
+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 è:
-Si tenga conto infine che tutti i limiti vengono ereditati dal
-processo padre attraverso una \func{fork} (vedi sez.~\ref{sec:proc_fork}) e
-mantenuti per gli altri programmi eseguiti attraverso una \func{exec} (vedi
-sez.~\ref{sec:proc_exec}).
+\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}
-\subsection{Le risorse di memoria e processore}
+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 \itindex{capabilities}
+ \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 \index{memoria~virtuale} 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 \index{paginazione} paginazione.
-
-Di solito la dimensione delle pagine di memoria è fissata dall'architettura
-hardware, per cui il suo valore di norma veniva mantenuto in una costante che
-bastava utilizzare in fase di compilazione, ma oggi, con la presenza di alcune
-architetture (ad esempio Sun Sparc) che permettono di variare questa
-dimensione, per non dover ricompilare i programmi per ogni possibile modello e
-scelta di dimensioni, è necessario poter utilizzare una funzione.
-
-Dato che si tratta di una caratteristica generale del sistema, questa
-dimensione può essere ottenuta come tutte le altre attraverso una chiamata a
-\func{sysconf}, \footnote{nel caso specifico si dovrebbe utilizzare il
- parametro \const{\_SC\_PAGESIZE}.} ma in BSD 4.2 è stata introdotta una
-apposita funzione, \funcd{getpagesize}, che restituisce la dimensione delle
-pagine di memoria; il suo prototipo è:
-\begin{prototype}{unistd.h}{int getpagesize(void)}
- Legge le dimensioni delle pagine di memoria.
-
- \bodydesc{La funzione ritorna la dimensione di una pagina in byte, e non
- sono previsti errori.}
-\end{prototype}
+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
+\index{paginazione} 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. 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 le \acr{glibc}
-2.1 implementavano questa funzione restituendo sempre un valore statico.
+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 le \acr{glibc} 2.1
+implementavano questa funzione restituendo sempre un valore statico.
% TODO verificare meglio la faccenda di const{PAGE\_SIZE}
Le \textsl{glibc} forniscono, come specifica estensione GNU, altre due
funzioni, \funcd{get\_phys\_pages} e \funcd{get\_avphys\_pages} che permettono
-di ottenere informazioni riguardo la memoria; i loro prototipi sono:
-\begin{functions}
- \headdecl{sys/sysinfo.h}
-
- \funcdecl{long int get\_phys\_pages(void)}
+di ottenere informazioni riguardo le pagine di memoria; i loro prototipi sono:
- Legge il numero totale di pagine di memoria disponibili per il sistema.
-
- \funcdecl{long int get\_avphys\_pages(void)}
-
- Legge il numero di pagine di memoria disponibili nel sistema.
-
- \bodydesc{Le funzioni restituiscono un numero di pagine.}
-\end{functions}
+\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
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{prototype}{stdlib.h}{int getloadavg(double loadavg[], int nelem)}
- Legge il carico medio della macchina.
-
- \bodydesc{La funzione ritorna il numero di elementi scritti o -1 in caso di
- errore.}
-\end{prototype}
+
+\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 \itindex{scheduler} scheduler, calcolato
Linux consente di salvare la contabilità delle informazioni relative alle
risorse utilizzate dai processi grazie alla funzione \funcd{acct}, il cui
prototipo è:
-\begin{prototype}{unistd.h}{int acct(const char *filename)}
- Abilita il \textit{BSD accounting}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo o $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
+
+\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{EPERM}] il processo non ha privilegi sufficienti ad
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
\errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOENT}, \errval{ENOMEM},
- \errval{ENOTDIR}, \errval{EROFS}.}
-\end{prototype}
+ \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
\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; le informazioni verranno registrate in
+verrà aperto in sola scrittura e le informazioni verranno registrate in
\itindex{append~mode} \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 \sysctlfile{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
+parametro di sistema, modificabile attraverso \sysctlfile{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}
\subsection{La misura del tempo in Unix}
\label{sec:sys_unix_time}
-Storicamente i sistemi unix-like hanno sempre mantenuto due distinti tipi di
-dati per la misure dei tempi all'interno del sistema: essi sono
-rispettivamente chiamati \itindex{calendar~time} \textit{calendar time} e
-\itindex{process~time} \textit{process time}, secondo le definizioni:
+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}] \itindex{calendar~time} detto anche
- \textsl{tempo di calendario}. È il numero di secondi dalla mezzanotte del
- primo gennaio 1970, in tempo universale coordinato (o UTC), data che viene
- usualmente indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata \textit{the
- Epoch}. Questo tempo viene anche chiamato anche GMT (Greenwich Mean Time)
- dato che l'UTC corrisponde all'ora locale di Greenwich. È il tempo su cui
- viene mantenuto l'orologio del kernel, e viene usato ad esempio per indicare
- le date di modifica dei file o quelle di avvio dei processi. Per memorizzare
- questo tempo è stato riservato il tipo primitivo \type{time\_t}.
-\item[\textit{process time}] \itindex{process~time} detto talvolta
- \textsl{tempo di processore}. Viene misurato in \itindex{clock~tick}
- \textit{clock tick}. Un tempo questo corrispondeva al numero di interruzioni
- effettuate dal timer di sistema, adesso lo standard POSIX richiede che esso
- sia pari al valore della costante \const{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.\footnote{quest'ultima,
- come accennato in sez.~\ref{sec:proc_hierarchy}, è invece data dalla
- costante \const{HZ}.} Il dato primitivo usato per questo tempo è
- \type{clock\_t}, che ha quindi una risoluzione del microsecondo. Il numero
- di \itindex{clock~tick} \textit{tick} al secondo può essere ricavato anche
- attraverso \func{sysconf} (vedi sez.~\ref{sec:sys_limits}). Il vecchio
- simbolo \const{CLK\_TCK} definito in \headfile{time.h} è ormai considerato
- obsoleto.
+ \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}] \itindex{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 \itindex{clock~tick}
+ \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}
-In genere si usa il \itindex{calendar~time} \textit{calendar time} per
-esprimere le date dei file e le informazioni analoghe che riguardano i
-cosiddetti \textsl{tempi di orologio}, che vengono usati ad esempio per i
-demoni che compiono lavori amministrativi ad ore definite, come \cmd{cron}.
-
-Di solito questo tempo viene convertito automaticamente dal valore in UTC al
-tempo locale, utilizzando le opportune informazioni di localizzazione
-(specificate in \conffile{/etc/timezone}). E da tenere presente che questo
-tempo è mantenuto dal sistema e non è detto che corrisponda al tempo tenuto
-dall'orologio hardware del calcolatore.
-
-Anche il \itindex{process~time} \textit{process time} di solito si esprime in
-secondi, ma fornisce una precisione ovviamente superiore al \textit{calendar
- time} (che è mantenuto dal sistema con una granularità di un secondo) e
-viene usato per tenere conto dei tempi di esecuzione dei processi. Per ciascun
-processo il kernel calcola tre tempi diversi:
-\begin{basedescript}{\desclabelwidth{1.5cm}\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. Chiaramente tale tempo dipende anche dal carico del sistema e da
- quanti altri processi stavano girando nello stesso periodo.
+Il \itindex{calendar~time} \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
+\conffile{/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.
+
+Il \itindex{process~time} \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 \itindex{calendar~time}
+ \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 processo in user space. È quello
- riportato nella risorsa \var{ru\_utime} di \struct{rusage} vista in
- sez.~\ref{sec:sys_resource_use}.
+ 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. È quello riportato nella risorsa \var{ru\_stime} di
+ processo. È anche quello riportato nella risorsa \var{ru\_stime} di
\struct{rusage} vista in sez.~\ref{sec:sys_resource_use}.
\end{basedescript}
-In genere la somma di \textit{user time} e \textit{system time} indica il
-tempo di processore totale che il sistema ha effettivamente utilizzato per
-eseguire un certo processo, questo viene chiamato anche \textit{CPU time} o
-\textsl{tempo di CPU}. 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}.
+La somma di \textit{user time} e \textit{system time} indica il
+\itindex{process~time} \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}.
+
+Come accennato il \itindex{process~time} \textit{process time} viene misurato
+nei cosiddetti \itindex{clock~tick} \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
+\const{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
+\itindex{clock~tick} \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.
+
+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 \itindex{clock~tick}
+\textit{clock tick}, ma in realtà questa granularità viene calcolata in
+maniera indipendente usando la costante del kernel \const{USER\_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}.
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{prototype}{time.h}{clock\_t clock(void)}
- Legge il valore corrente del tempo di CPU.
-
- \bodydesc{La funzione ritorna il tempo di CPU usato dal programma e -1 in
- caso di errore.}
-\end{prototype}
-La funzione restituisce il tempo in \itindex{clock~tick} \texttt{clock tick},
-quindi se si vuole il tempo in secondi occorre dividere il risultato per la
-costante \const{CLOCKS\_PER\_SEC}.\footnote{le \acr{glibc} seguono lo standard
- ANSI C, POSIX richiede che \const{CLOCKS\_PER\_SEC} sia definito pari a
- 1000000 indipendentemente dalla risoluzione del timer di sistema.} 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.
-
-% TODO questi valori sono obsoleti, verificare il tutto.
-
-Come accennato in sez.~\ref{sec:sys_unix_time} il tempo di CPU è 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 attraverso la funzione \funcd{times}, il cui prototipo è:
-\begin{prototype}{sys/times.h}{clock\_t times(struct tms *buf)}
- Legge in \param{buf} il valore corrente dei tempi di processore.
-
- \bodydesc{La funzione ritorna il numero di \itindex{clock~tick}
- \textit{clock tick} dall'avvio del sistema in caso di successo e -1 in
- caso di errore.}
-\end{prototype}
+\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 \itindex{clock~tick} \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}.
+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]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/tms.h}
\end{minipage}
\normalsize
\label{fig:sys_tms_struct}
\end{figure}
-Gli altri due campi mantengono rispettivamente la somma dell'\textit{user
- time} ed del \textit{system time} di tutti i processi figli che sono
-terminati; il kernel cioè somma in \var{tms\_cutime} il valore di
-\var{tms\_utime} e \var{tms\_cutime} per ciascun figlio del quale è stato
-ricevuto lo stato di terminazione, e lo stesso vale per \var{tms\_cstime}.
+
+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.
+``\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 \const{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 \itindex{clock~tick}
+\textit{clock tick} effettivi e non in multipli di \const{CLOCKS\_PER\_SEC},
+pertanto per ottenere il valore effettivo 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 \itindex{clock~tick} \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}.
\itindend{process~time}
\itindbeg{calendar~time}
Come anticipato in sez.~\ref{sec:sys_unix_time} il \textit{calendar time} è
-mantenuto dal kernel in una variabile di tipo \type{time\_t},\footnote{in
- realtà il kernel usa una rappresentazione interna di che fornisce una
- precisione molto maggiore, e consente per questo anche di usare
- rappresentazioni diverse del \textit{calendar time}.} 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
+mantenuto dal kernel in una variabile di tipo \type{time\_t}, che usualmente
+corrisponde ad un tipo elementare; in Linux è definito come \ctyp{long int},
+che di norma corrisponde a 32 bit. Il valore corrente del \textit{calendar
time}, che indicheremo come \textsl{tempo di sistema}, può essere ottenuto
-con la funzione \funcd{time} che lo restituisce nel suddetto formato; il suo
+con la funzione \funcd{time} che lo restituisce nel suddetto formato, il suo
prototipo è:
-\begin{prototype}{time.h}{time\_t time(time\_t *t)}
- Legge il valore corrente del \textit{calendar time}.
-
- \bodydesc{La funzione ritorna il valore del \textit{calendar time} in caso
- di successo e -1 in caso di errore, che può essere solo \errval{EFAULT}.}
-\end{prototype}
-\noindent dove \param{t}, se non nullo, deve essere l'indirizzo di una
-variabile su cui duplicare il valore di ritorno.
+
+\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{prototype}{time.h}{int stime(time\_t *t)}
- Imposta a \param{t} il valore corrente del \textit{calendar time}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
- che può essere \errval{EFAULT} o \errval{EPERM}.}
-\end{prototype}
-\noindent 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,
-altrimenti la chiamata fallirà con un errore di \errcode{EPERM}.
+
+\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 la
+\itindex{capabilities} 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
valere per qualunque funzione che vada a modificare l'orologio di sistema,
quindi anche per quelle che tratteremo in seguito) può essere utilizzata solo
da un processo coi privilegi di amministratore.\footnote{più precisamente la
- capabitity \const{CAP\_SYS\_TIME}.}
+ capability \const{CAP\_SYS\_TIME}.}
Il secondo argomento di entrambe le funzioni è una struttura
\struct{timezone}, che storicamente veniva utilizzata per specificare appunto
% LocalWords: SHRT short USHRT int UINT LONG long ULONG LLONG ULLONG POSIX ARG
% LocalWords: Stevens exec CHILD STREAM stream TZNAME timezone NGROUPS SSIZE
% LocalWords: ssize LISTIO JOB CONTROL job control IDS VERSION YYYYMML bits bc
-% LocalWords: dall'header posix lim nell'header glibc run unistd name errno
+% LocalWords: dall'header posix lim nell'header glibc run unistd name errno SC
% LocalWords: NGROUP CLK TCK clock tick process PATH pathname BUF CANON path
% LocalWords: pathconf fpathconf descriptor fd uname sys struct utsname info
% LocalWords: EFAULT fig SOURCE NUL LENGTH DOMAIN NMLN UTSLEN system call proc
% LocalWords: newlen ENOTDIR EINVAL ENOMEM linux array oldvalue paging stack
% LocalWords: TCP shell Documentation ostype hostname osrelease version mount
% LocalWords: const source filesystemtype mountflags ENODEV ENOTBLK block read
-% LocalWords: device EBUSY only EACCES NODEV ENXIO major
+% LocalWords: device EBUSY only EACCES NODEV ENXIO major RTSIG syscall PID NSS
% LocalWords: number EMFILE dummy ENAMETOOLONG ENOENT ELOOP virtual devfs MGC
% LocalWords: magic MSK RDONLY NOSUID suid sgid NOEXEC SYNCHRONOUS REMOUNT MNT
% LocalWords: MANDLOCK mandatory locking WRITE APPEND append IMMUTABLE NOATIME
% LocalWords: SIGSEGV SIGXCPU SIGKILL sbrk FSIZE SIGXFSZ EFBIG LOCKS lock dup
% LocalWords: MEMLOCK NOFILE NPROC fork EAGAIN SIGPENDING sigqueue kill RSS tv
% LocalWords: resource getrlimit setrlimit rlimit rlim INFINITY capabilities
-% LocalWords: capability CAP l'I Sun Sparc PAGESIZE getpagesize SVr SUSv get
+% LocalWords: capability CAP Sun Sparc PAGESIZE getpagesize SVr SUSv get IGN
% LocalWords: phys pages avphys NPROCESSORS CONF ONLN getloadavg stdlib double
-% LocalWords: loadavg nelem scheduler CONFIG ACCT acct filename EUSER
+% LocalWords: loadavg nelem scheduler CONFIG ACCT acct filename EUSER sizeof
% LocalWords: ENFILE EROFS PACCT AcctCtrl cap calendar UTC Jan the Epoch GMT
% LocalWords: Greenwich Mean l'UTC timer CLOCKS SEC cron wall elapsed times tz
-% LocalWords: tms cutime cstime waitpid gettimeofday settimeofday timex
-% LocalWords: timespec adjtime olddelta adjtimex David Mills RFC NTP ntp
+% LocalWords: tms cutime cstime waitpid gettimeofday settimeofday timex NetBSD
+% LocalWords: timespec adjtime olddelta adjtimex David Mills RFC NTP ntp cmd
% LocalWords: nell'RFC ADJ FREQUENCY frequency MAXERROR maxerror ESTERROR PLL
% LocalWords: esterror TIMECONST constant SINGLESHOT MOD INS insert leap OOP
% LocalWords: second delete progress has occurred BAD broken tm gmtoff asctime
% LocalWords: ctime timep gmtime localtime mktime tzname tzset daylight format
% LocalWords: strftime thread EOF modifiable lvalue app errcode strerror LC at
-% LocalWords: perror string errnum MESSAGES error message ErrCode strtol log
+% LocalWords: perror string errnum MESSAGES error message strtol log jiffy asm
% LocalWords: program invocation argv printf print progname exit count fname
-% LocalWords: lineno one standardese Di page Wed Wednesday Apr April PM AM
-% LocalWords: CEST
-
+% LocalWords: lineno one standardese Di page Wed Wednesday Apr April PM AM CAD
+% LocalWords: CEST utmpxname Solaris updwtmpx reboot RESTART Ctrl OFF SIGINT
+% LocalWords: HALT halted sync KEXEC kexec load bootloader POWER Power with nr
+% LocalWords: Restarting command arg entry segments segment ARCH CRASH CONTEXT
+% LocalWords: PRESERVE PPC IA ARM SH MIPS nvcsw nivcsw inblock oublock maxrss
+% LocalWords: context switch slice Resident SIG SIGCHLD cur Gb lease mlock Hz
+% LocalWords: memory mlockall MAP LOCKED shmctl MSGQUEUE attr NICE nice MADV
+% LocalWords: madvise WILLNEED RTPRIO sched setscheduler setparam scheduling
+% LocalWords: RTTIME execve kb prlimit pid new old ESRCH EUSERS refresh high
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: resolution HRT jiffies
projects / gapil.git / blobdiff