%% system.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\hline
\const{LINK\_MAX} &8 & numero massimo di link a un file\\
\const{NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\
- \const{PATH\_MAX}& 256 & lunghezza in byte di un pathname.\\
+ \const{PATH\_MAX}& 256 & lunghezza in byte di un
+ \index{\textit{pathname}}\textit{pathname}.\\
\const{PIPE\_BUF}&4096 & byte scrivibili atomicamente in una pipe
(vedi sez.~\ref{sec:ipc_pipes}).\\
\const{MAX\_CANON}&255 & dimensione di una riga di terminale in modo
\hline
\const{\_POSIX\_LINK\_MAX} &8 & numero massimo di link a un file.\\
\const{\_POSIX\_NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\
- \const{\_POSIX\_PATH\_MAX}& 256 & lunghezza in byte di un pathname.\\
+ \const{\_POSIX\_PATH\_MAX}& 256 & lunghezza in byte di un
+ \index{\textit{pathname}}\textit{pathname}.\\
\const{\_POSIX\_PIPE\_BUF}& 512 & byte scrivibili atomicamente in una
- pipe.\\
+ pipe.\\
\const{\_POSIX\_MAX\_CANON}&255 & dimensione di una riga di
- terminale in modo canonico.\\
+ terminale in modo canonico.\\
\const{\_POSIX\_MAX\_INPUT}&255 & spazio disponibile nella coda di input
- del terminale.\\
+ del terminale.\\
% \const{\_POSIX\_MQ\_OPEN\_MAX}& 8& \\
% \const{\_POSIX\_MQ\_PRIO\_MAX}& 32& \\
% \const{\_POSIX\_FD\_SETSIZE}& 16 & \\
E si noti come la funzione in questo caso richieda un parametro che specifichi
a quale file si fa riferimento, dato che il valore del limite cercato può
variare a seconda del filesystem. Una seconda versione della funzione,
-\funcd{fpathconf}, opera su un file descriptor invece che su un pathname. Il
-suo prototipo è:
+\funcd{fpathconf}, opera su un file descriptor invece che su un
+\index{\textit{pathname}}\textit{pathname}. Il suo prototipo è:
\begin{prototype}{unistd.h}{long fpathconf(int fd, int name)}
Restituisce il valore del parametro \param{name} per il file \param{fd}.
\bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor
- invece di un pathname; pertanto gli errori restituiti cambiano di
- conseguenza.}
+ invece di un \index{\textit{pathname}}\textit{pathname}; pertanto gli
+ errori restituiti cambiano di conseguenza.}
\end{prototype}
\noindent ed il suo comportamento è identico a quello di \func{pathconf}.
occorrerà includere anche i file \file{linux/unistd.h} e
\file{linux/sysctl.h}.} per accedere ad uno di essi occorre specificare un
cammino attraverso i vari nodi dell'albero, in maniera analoga a come avviene
-per la risoluzione di un pathname (da cui l'uso alternativo del filesystem
-\file{/proc}, che vedremo dopo).
+per la risoluzione di un \index{\textit{pathname}}\textit{pathname} (da cui
+l'uso alternativo del filesystem \file{/proc}, che vedremo dopo).
Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
arriva ad identificare un parametro specifico è passato alla funzione
In particolare l'albero dei valori di \func{sysctl} viene presentato in forma
di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
-specificando un pathname e leggendo e scrivendo sul file corrispondente al
-parametro scelto. Il kernel si occupa di generare al volo il contenuto ed i
-nomi dei file corrispondenti, e questo ha il grande vantaggio di rendere
-accessibili i vari parametri a qualunque comando di shell e di permettere la
-navigazione dell'albero dei valori.
+specificando un \index{\textit{pathname}}\textit{pathname} e leggendo e
+scrivendo sul file corrispondente al parametro scelto. Il kernel si occupa di
+generare al volo il contenuto ed i nomi dei file corrispondenti, e questo ha
+il grande vantaggio di rendere accessibili i vari parametri a qualunque
+comando di shell e di permettere la navigazione dell'albero dei valori.
Alcune delle corrispondenze dei file presenti in \file{/proc/sys} con i valori
di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
\textit{mount point} o di spostarlo quando \param{target} non è un
\textit{mount point} o è \file{/}.
\item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
- componenti del pathname, o si è cercato di montare un filesystem
- disponibile in sola lettura senza averlo specificato o il device
- \param{source} è su un filesystem montato con l'opzione \const{MS\_NODEV}.
+ componenti del \index{\textit{pathname}}\textit{pathname}, o si è cercato
+ di montare un filesystem disponibile in sola lettura senza averlo
+ specificato o il device \param{source} è su un filesystem montato con
+ l'opzione \const{MS\_NODEV}.
\item[\errcode{ENXIO}] il \textit{major number} del device \param{source} è
sbagliato.
\item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
kernel nelle system call eseguite per conto del processo.
Gli altri tre campi servono a quantificare l'uso della memoria
-virtuale\index{memoria virtuale} e corrispondono rispettivamente al numero di
-\textit{page fault}\index{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}) ed al numero di volte che il processo è stato
-completamente tolto dalla memoria per essere inserito nello swap.
+virtuale\index{memoria~virtuale} e corrispondono rispettivamente al numero di
+\textit{page fault}\index{\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}) ed al numero di volte che il
+processo è stato completamente tolto dalla memoria per essere inserito nello
+swap.
In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
necessario, ma aumenta la portabilità, e serve comunque quando, come nella
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\index{memoria virtuale} attraverso la
+meccanismo della memoria virtuale\index{memoria~virtuale} attraverso la
divisione della memoria fisica in pagine.
In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi
\end{prototype}
La funzione restituisce in ciascun elemento di \param{loadavg} il numero medio
-di processi attivi sulla coda dello scheduler\index{scheduler}, calcolato su
-un diverso 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.
+di processi attivi sulla coda dello scheduler\index{\textit{scheduler}},
+calcolato su un diverso 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.
projects / gapil.git / blobdiff