\label{cha:errors}
Si riportano in questa appendice tutti i codici di errore. Essi sono
-accessibili attraverso l'inclusione del file di header \file{errno.h}, che
+accessibili attraverso l'inclusione del file di header \headfile{errno.h}, che
definisce anche la \index{variabili!globali} variabile globale
\var{errno}. Per ogni errore definito riporteremo la stringa stampata da
\func{perror} ed una breve spiegazione. Si tenga presente che spiegazioni più
inode\itindex{inode},\footnote{in particolare, come accennato in
fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti in una
\itindex{linked~list} \textit{linked list} di strutture
- \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
- mantenuto dal campo \var{i\_flock} della struttura \struct{inode} (per le
- definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
- del kernel). Un bit del campo \var{fl\_flags} di specifica se si tratta di
- un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
-dato che questo è l'unico riferimento in comune che possono avere due processi
-diversi che aprono lo stesso file.
+ \kstruct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+ mantenuto dal campo \var{i\_flock} della struttura \kstruct{inode} (per le
+ definizioni esatte si faccia riferimento al file \file{include/linux/fs.h}
+ nei sorgenti del kernel). Un bit del campo \var{fl\_flags} di specifica se
+ si tratta di un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX
+ (\const{FL\_POSIX}).} dato che questo è l'unico riferimento in comune che
+possono avere due processi diversi che aprono lo stesso file.
\begin{figure}[!htb]
\centering
quando, come nelle versioni più recenti del kernel, questo limite è stato
rimosso, esso indica le dimensioni massime dei numeri usati nei \textit{file
descriptor set}.\footnote{il suo valore, secondo lo standard POSIX
- 1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.}
+ 1003.1-2001, è definito in \headfile{sys/select.h}, ed è pari a 1024.}
Si tenga presente che i \textit{file descriptor set} devono sempre essere
inizializzati con \macro{FD\_ZERO}; passare a \func{select} un valore non
multiplexing}, introdotto solo con le ultime revisioni dello standard (POSIX
1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
-vengano dichiarate nell'header \file{sys/select.h}, che sostituisce i
+vengano dichiarate nell'header \headfile{sys/select.h}, che sostituisce i
precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
\funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
- l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
- 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
- \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
+ l'header \headfile{sys/select.h}, compaiono in Linux a partire dalle
+ \acr{glibc} 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header,
+ le \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
\acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
\acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
in stile SysV (in particolare le ultime due non vengono usate su Linux), e
sono utilizzabili soltanto qualora si sia definita la macro
\macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in testa al
- file, definirla soltanto prima di includere \file{sys/poll.h} non è
+ file, definirla soltanto prima di includere \headfile{sys/poll.h} non è
sufficiente.}
In caso di successo funzione ritorna restituendo il numero di file (un valore
Una volta completata l'inizializzazione verrà eseguito indefinitamente il
ciclo principale del programma (\texttt{\small 2--45}) che si è riportato in
fig.~\ref{fig:fiforeporter_code_body}, fintanto che questo non riceva un
-segnale di \texttt{SIGINT} (ad esempio con la pressione di \texttt{C-c}). Il
+segnale di \signal{SIGINT} (ad esempio con la pressione di \texttt{C-c}). Il
ciclo prevede che si attenda (\texttt{\small 2--3}) la presenza di un file
descriptor pronto in lettura con \func{epoll\_wait},\footnote{si ricordi che
entrambi i file descriptor \var{fifofd} e \var{sigfd} sono stati posti in
ricevuto un segnale e che il file descriptor pronto corrisponda
(\texttt{\small 6}) a \var{sigfd}. Dato che in generale si possono ricevere
anche notifiche relativi a più di un singolo segnale, si è scelto di leggere
-una struttura \const{signalfd\_siginfo} alla volta, eseguendo la lettura
+una struttura \struct{signalfd\_siginfo} alla volta, eseguendo la lettura
all'interno di un ciclo (\texttt{\small 8--24}) che prosegue fintanto che vi
siano dati da leggere.
definizione si è omessa dal codice di fig.~\ref{fig:fiforeporter_code_init}
per brevità.} ed il \textit{pid} del processo da cui lo ha ricevuto; inoltre
(\texttt{\small 21--24}) si controllerà anche se il segnale ricevuto è
-\var{SIGINT}, che si è preso come segnale da utilizzare per la terminazione
+\signal{SIGINT}, che si è preso come segnale da utilizzare per la terminazione
del programma, che verrà eseguita dopo aver rimosso il file della \textit{name
fifo}.
partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
\textsl{comandi} aggiuntivi per la funzione \func{fcntl} (vedi
sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
-definita la macro \macro{\_GNU\_SOURCE} prima di includere \file{fcntl.h}.
+definita la macro \macro{\_GNU\_SOURCE} prima di includere \headfile{fcntl.h}.
\itindbeg{file~lease}
\bodydesc{La funzione restituisce un valore positivo in caso di successo, o
$-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EACCESS}] non si ha accesso in lettura al file indicato.
+ \item[\errcode{EACCES}] non si ha accesso in lettura al file indicato.
\item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd}
non è un file descriptor di \textit{inotify}.
\item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
\textit{asyncronous I/O control block}), che viene passata come argomento a
tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
-\file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
+\headfile{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
disponibilità dell'interfaccia per l'I/O asincrono.
di notifica non verrà invocato. Se si specifica una operazione relativa ad un
altro file descriptor il risultato è indeterminato. In caso di successo, i
possibili valori di ritorno per \func{aio\_cancel} (anch'essi definiti in
-\file{aio.h}) sono tre:
+\headfile{aio.h}) sono tre:
\begin{basedescript}{\desclabelwidth{3.0cm}}
\item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
cancellazione sono state già completate,
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
multiplo di \const{PAGE\_SIZE}.
- \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
+ \item[\errcode{EACCES}] l'operazione non è consentita, ad esempio si è
cercato di marcare con \const{PROT\_WRITE} un segmento di memoria cui si
ha solo accesso in lettura.
% \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
maschera binaria per i flag che controllano il comportamento della funzione.
Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
utilizzare questa costante occorre aver definito \macro{\_GNU\_SOURCE} prima
- di includere \file{sys/mman.h}.} che consente di eseguire l'espansione
+ di includere \headfile{sys/mman.h}.} che consente di eseguire l'espansione
anche quando non è possibile utilizzare il precedente indirizzo. Per questo
motivo, se si è usato questo flag, la funzione può restituire un indirizzo
della nuova zona di memoria che non è detto coincida con \param{old\_address}.
POSIX.1-2001 prevede anche che sia possibile avere un limite al numero di
elementi del vettore \param{vector}. Qualora questo sussista, esso deve essere
indicato dal valore dalla costante \const{IOV\_MAX}, definita come le altre
-costanti analoghe (vedi sez.~\ref{sec:sys_limits}) in \file{limits.h}; lo
+costanti analoghe (vedi sez.~\ref{sec:sys_limits}) in \headfile{limits.h}; lo
stesso valore deve essere ottenibile in esecuzione tramite la funzione
\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
sez.~\ref{sec:sys_sysconf}).
% LocalWords: ENFILE lenght segment violation SIGSEGV FIXED msync munmap copy
% LocalWords: DoS Denial Service EXECUTABLE NORESERVE LOCKED swapping stack fs
% LocalWords: GROWSDOWN ANON POPULATE prefaulting SIGBUS fifo VME fork old SFD
-% LocalWords: exec atime ctime mtime mprotect addr EACCESS mremap address new
+% LocalWords: exec atime ctime mtime mprotect addr mremap address new
% LocalWords: long MAYMOVE realloc VMA virtual Ingo Molnar remap pages pgoff
% LocalWords: dall' fault cache linker prelink advisory discrectionary lock fl
% LocalWords: flock shared exclusive operation dup inode linked NFS cmd ENOLCK
partizioni. In essa per semplicità si è fatto riferimento alla struttura del
filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
group}. All'interno di ciascun \textit{block group} viene anzitutto
-replicato il cosiddetto \textit{superblock}, (la struttura che contiene
-l'indice iniziale del filesystem e che consente di accedere a tutti i dati
-sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
-per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
-torneremo in sez.~\ref{sec:file_ext2}.
+replicato il cosiddetto \itindex{superblock} \textit{superblock}, (la
+struttura che contiene l'indice iniziale del filesystem e che consente di
+accedere a tutti i dati sottostanti) e creata una opportuna suddivisione dei
+dati e delle informazioni per accedere agli stessi. Sulle caratteristiche di
+\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}.
\itindbeg{inode}
Se si va ad esaminare con maggiore dettaglio la strutturazione
dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
dettagli relativi al funzionamento del filesystem stesso come la
-strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
-gestione possiamo esemplificare la situazione con uno schema come quello
-esposto in fig.~\ref{fig:file_filesys_detail}.
+strutturazione in gruppi dei blocchi, il \itindex{superblock}
+\textit{superblock} e tutti i dati di gestione possiamo esemplificare la
+situazione con uno schema come quello esposto in
+fig.~\ref{fig:file_filesys_detail}.
\begin{figure}[!htb]
\centering
in gruppi di blocchi.
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
-affidabilità e possibilità di recupero in caso di corruzione del
-\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
-inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
-distanza fra i dati e la tabella degli \itindex{inode} inode.
+filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati)
+per una maggiore affidabilità e possibilità di recupero in caso di corruzione
+del \itindex{superblock} \textit{superblock} principale. L'utilizzo di
+raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni
+dato che viene ridotta la distanza fra i dati e la tabella degli
+\itindex{inode} inode.
\begin{figure}[!htb]
\centering
o non può essere montato su \param{target} perché la directory è ancora in
uso.
\item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
- \textit{superblock} non valido, o si è cercato di rimontare un filesystem
- non ancora montato, o di montarlo senza che \param{target} sia un
- \itindex{mount~point} \textit{mount point} o di spostarlo
- quando \param{target} non è un \itindex{mount~point} \textit{mount point}
- o è la radice.
+ \itindex{superblock} \textit{superblock} non valido, o si è cercato di
+ rimontare un filesystem non ancora montato, o di montarlo senza
+ che \param{target} sia un \itindex{mount~point} \textit{mount point} o di
+ spostarlo quando \param{target} non è un \itindex{mount~point}
+ \textit{mount point} o è la radice.
\item[\errcode{ELOOP}] si è cercato di spostare un \itindex{mount~point}
\textit{mount point} su una sottodirectory di \param{source} o si sono
incontrati troppi link simolici nella risoluzione di un nome.
dell'amministratore o di un altro utente, che gli consentirebbe di eseguirlo
per conto di quest'ultimo.
-\item[\const{MS\_PRIVATE}] Marca un \textit{mount point} come privato. Si
- tratta di una delle nuove opzioni (insieme a \const{MS\_SHARED},
- \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti parte
- dell'infrastruttura degli \itindex{shared~subtree} \textit{shared subtree}
- introdotta a partire dal kernel 2.6.15, che estendono le funzionalità dei
- \itindex{bind~mount} \textit{bind mount}. In questo caso
+\item[\const{MS\_PRIVATE}] Marca un \itindex{mount~point} \textit{mount point}
+ come privato. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
\param{target} dovrà fare riferimento al \textit{mount point} che si intende
marcare, e tutti gli altri argomenti verranno ignorati.
Di default, finché non lo si marca altrimenti con una delle altre opzioni
dell'interfaccia \itindex{shared~subtree} \textit{shared subtree}, ogni
\textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un
- \textit{mount point} di tipo \textit{private} si comporta come descritto
- nella trattazione di \const{MS\_BIND}. Si usa questo flag principalmente per
- revocare gli effetti delle altre opzioni e riportare il comportamento a
- quello ordinario.
+ \itindex{mount~point} \textit{mount point} di tipo \textit{private} si
+ comporta come descritto nella trattazione di \const{MS\_BIND}. Si usa questo
+ flag principalmente per revocare gli effetti delle altre opzioni e riportare
+ il comportamento a quello ordinario.
\item[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
corrotto). All'avvio di default il kernel monta la radice in questa
modalità.
-\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
- presenti al di sotto del \textit{mount point} indicato gli effetti della
- opzione degli \itindex{shared~subtree} \textit{shared subtree}
- associata. Anche questo caso l'argomento \param{target} deve fare
- riferimento ad un \textit{mount point} e tutti gli altri argomenti sono
- ignorati, ed il flag deve essere indicato assieme ad una fra
- \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \itindex{mount~point}
+ \textit{mount point} presenti al di sotto del \textit{mount point} indicato
+ gli effetti della opzione degli \itindex{shared~subtree} \textit{shared
+ subtree} associata. Anche questo caso l'argomento \param{target} deve fare
+ riferimento ad un \itindex{mount~point} \textit{mount point} e tutti gli
+ altri argomenti sono ignorati, ed il flag deve essere indicato assieme ad
+ una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
\const{MS\_UNBINDABLE}.
\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
\const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
-\item[\const{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
- mount}. Si tratta di una delle nuove opzioni (insieme a
+\item[\const{MS\_SHARED}] Marca un \itindex{mount~point} \textit{mount point}
+ come \textit{shared mount}. Si tratta di una delle nuove opzioni (insieme a
\const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
subtree} introdotta a partire dal kernel 2.6.15, che estendono le
funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
- \param{target} dovrà fare riferimento al \textit{mount point} che si intende
- marcare, e tutti gli altri argomenti verranno ignorati.
+ \param{target} dovrà fare riferimento al \itindex{mount~point} \textit{mount
+ point} che si intende marcare, e tutti gli altri argomenti verranno
+ ignorati.
Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
effettuati da un \textit{mount point} marcato da essa siano di tipo
non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
2.6.12, che aveva lo stesso effetto.
-\item[\const{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
- mount}. Si tratta di una delle nuove opzioni (insieme a
+\item[\const{MS\_SLAVE}] Marca un \itindex{mount~point} \textit{mount point}
+ come \textit{slave mount}. Si tratta di una delle nuove opzioni (insieme a
\const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
subtree} introdotta a partire dal kernel 2.6.15, che estendono le
questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
essi potranno eseguire al loro interno ulteriori montaggi che non saranno
- propagati né negli altri né nel \textit{mount point} originale.
+ propagati né negli altri né nel \itindex{mount~point} \textit{mount point}
+ originale.
\item[\const{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
cui l'\textit{access time} viene aggiornato ad ogni accesso al
compromesso in cui questo comportamento avviene solo per le directory, ed ha
quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
-\item[\const{MS\_UNBINDABLE}] Marca un \textit{mount point} come
- \textit{unbindable mount}. Si tratta di una delle nuove opzioni (insieme a
- \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_SLAVE}) facenti parte
- dell'infrastruttura degli \itindex{shared~subtree} \textit{shared subtree}
- introdotta a partire dal kernel 2.6.15, che estendono le funzionalità dei
- \itindex{bind~mount} \textit{bind mount}. In questo caso
+\item[\const{MS\_UNBINDABLE}] Marca un \itindex{mount~point} \textit{mount
+ point} come \textit{unbindable mount}. Si tratta di una delle nuove
+ opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e
+ \const{MS\_SLAVE}) facenti parte dell'infrastruttura degli
+ \itindex{shared~subtree} \textit{shared subtree} introdotta a partire dal
+ kernel 2.6.15, che estendono le funzionalità dei \itindex{bind~mount}
+ \textit{bind mount}. In questo caso
\param{target} dovrà fare riferimento al \textit{mount point} che si intende
marcare, e tutti gli altri argomenti verranno ignorati.
Un \textit{mount point} marcato in questo modo disabilità la capacità di
eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
- allo stesso modo di un \textit{mount point} ordinario di tipo
- \textit{private} con in più la restrizione che nessuna sua sottodirectory
- (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un
- come sorgente di un \itindex{bind~mount} \textit{bind mount}.
+ allo stesso modo di un \itindex{mount~point} \textit{mount point} ordinario
+ di tipo \textit{private} con in più la restrizione che nessuna sua
+ sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+ utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind
+ mount}.
\end{basedescript}
-
% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
% * http://lwn.net/Articles/159077/ e
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
- processo, o contiene dei file aperti, o un altro mount point.
+ \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
+ directory di lavoro di qualche processo, o contiene dei file aperti, o un
+ altro mount point.
\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
significato generico.}
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
funzione poteva essere usata anche specificando il file di dispositivo.} in
-quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
-punti. Nel caso più di un filesystem sia stato montato sullo stesso
-\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
-montato per ultimo.
+quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
+che è stato montato per ultimo.
Si tenga presente che la funzione fallisce quando il filesystem è
-\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
-filesystem, se questo contiene la directory di lavoro corrente di un qualunque
-processo o il \itindex{mount~point} \textit{mount point} di un altro
-filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
+\textsl{occupato}, cioè quando ci sono ancora dei file aperti sul filesystem,
+se questo contiene la \index{directory~di~lavoro} directory di lavoro corrente
+di un qualunque processo o il \itindex{mount~point} \textit{mount point} di un
+altro filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
casi permette di forzare lo smontaggio di un filesystem, anche quando questo
\item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
non vuota.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
- parte di qualche processo (come directory di lavoro o come radice) o del
- sistema (come \itindex{mount~point} \textit{mount point}).
+ parte di qualche processo (come \index{directory~di~lavoro} directory di
+ lavoro o come radice) o del sistema (come \itindex{mount~point}
+ \textit{mount point}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
- radice di qualche processo.
+ \item[\errcode{EBUSY}] la directory specificata è la
+ \index{directory~di~lavoro} directory di lavoro o la radice di qualche
+ processo.
\item[\errcode{ENOTEMPTY}] la directory non è vuota.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
necessità di specificare il numero tramite delle opportune macro, così da non
avere problemi di compatibilità con eventuali ulteriori estensioni.
-Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
-automaticamente incluso quando si include \file{sys/types.h}; si possono
+Le macro sono definite nel file \headfile{sys/sysmacros.h}, che viene
+automaticamente incluso quando si include \headfile{sys/types.h}; si possono
pertanto ottenere i valori del \itindex{major~number} \textit{major number} e
\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente
con le macro \macro{major} e \macro{minor}:
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la directory di lavoro (vedi
+spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
stream sulla directory passata come primo argomento, stampando un messaggio in
caso di errore.
-Il passo successivo (\texttt{\small 23--24}) è cambiare directory di lavoro
-(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
-\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
-(\texttt{\small 26--30}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
- della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
- \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
- struttura \struct{dirent} sono sempre relativi alla directory in questione,
- e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
- ottenere le dimensioni.}
+Il passo successivo (\texttt{\small 23--24}) è cambiare
+\index{directory~di~lavoro} directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
+\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
+\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
+ 26--30}) sulle singole voci dello stream ci si trovi all'interno della
+directory.\footnote{questo è essenziale al funzionamento della funzione
+ \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
+ quanto i nomi dei file memorizzati all'interno di una struttura
+ \struct{dirent} sono sempre relativi alla directory in questione, e senza
+ questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
+ le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
\label{sec:file_work_dir}
\itindbeg{pathname}
-
+\index{directory~di~lavoro|(}
Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
Una seconda usata per ottenere la directory di lavoro è \code{char
*get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
\code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
-contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
-\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
-all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
-attraverso eventuali link simbolici.
+della variabile di ambiente \envvar{PWD}, che essendo costruita dalla shell
+può contenere un \textit{pathname} comprendente anche dei link
+simbolici. Usando \func{getcwd} infatti, essendo il \textit{pathname} ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
specificata da \param{fd}.
\itindend{pathname}
-
+\index{directory~di~lavoro|)}
\subsection{I file temporanei}
indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
- \file{stdio.h}.}
+ \headfile{stdio.h}.}
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
nome provvisorio. La funzione assegna come directory per il file temporaneo,
verificando che esista e sia accessibile, la prima valida fra le seguenti:
\begin{itemize*}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+\item La variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
questa funzione esiste una variante \funcd{mkostemp}, introdotta
specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
nella versione 2.7 delle librerie e richiede che sia definita la macro
- \const{\_GNU\_SOURCE}.} il cui prototipo è:
+ \macro{\_GNU\_SOURCE}.} il cui prototipo è:
\begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
Genera un file temporaneo.
aperto, specificato tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
Si noti come i vari membri della struttura siano specificati come tipi
primitivi del sistema (di quelli definiti in
-tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h}).
\subsection{I tipi di file}
\label{sec:file_types}
\macro{S\_ISSOCK}\texttt{(m)} & socket.\\
\hline
\end{tabular}
- \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
+ \caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
\label{tab:file_type_macro}
\end{table}
Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
direttamente il valore di \var{st\_mode} per ricavare il tipo di file
controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\headfile{sys/stat.h} sono definite le costanti numeriche riportate in
tab.~\ref{tab:file_mode_flags}.
Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
- \var{st\_mode} (definite in \file{sys/stat.h}).}
+ \var{st\_mode} (definite in \headfile{sys/stat.h}).}
\label{tab:file_mode_flags}
\end{table}
breve descrizione ed il nome delle costanti che le identificano, è riportato
in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
- aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
-riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
-molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+ capabilities}) e dalle definizioni in
+ \texttt{include/linux/capabilities.h}, è aggiornato al kernel 2.6.26.} la
+tabella è divisa in due parti, la prima riporta le \textit{capabilities}
+previste anche nella bozza dello standard POSIX1.e, la seconda quelle
+specifiche di Linux. Come si può notare dalla tabella alcune
+\textit{capabilities} attengono a singole funzionalità e sono molto
+specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
+opportuno dettagliare maggiormente.
\begin{table}[!h!btp]
\centering
indicato che per poterle utilizzare fosse necessario che la macro
\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\texttt{sys/capability.h}) requisito che non risulta più presente.\footnote{e
- non è chiaro neanche quanto sia mai stato davvero necessario.}
+\headfile{sys/capability.h}) requisito che non risulta più
+presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
+ necessario.}
Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
con l'argomento \param{flag}. Questo deve essere specificato con una variabile
di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta
in effetti di un tipo enumerato, come si può verificare dalla sua
- definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
-valori illustrati in tab.~\ref{tab:cap_set_identifier}.
+ definizione che si trova in \headfile{sys/capability.h}.} uno dei valori
+illustrati in tab.~\ref{tab:cap_set_identifier}.
Si possono inoltre confrontare in maniera diretta due diversi
\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
combinare diversi valori in una maschera binaria, una variabile di tipo
\type{cap\_value\_t} può indicare una sola capacità.\footnote{in
- \texttt{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
+ \headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
\ctyp{int}, ma i valori validi sono soltanto quelli di
tab.~\ref{tab:proc_capabilities}.}
prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
ma il valore di ritorno è intero, come si può verificare anche dalla
- dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+ dichiarazione della stessa in \headfile{sys/capability.h}.} è:
\begin{functions}
\headdecl{sys/capability.h}
% TODO riferimenti ai bind mount, link simbolici ecc.
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
- sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
- \struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
-di norma corrispondente alla radice dell'albero di file e directory come visto
-dal kernel (ed illustrato in sez.~\ref{sec:file_pathname}), ha per il processo
-il significato specifico di directory rispetto alla quale vengono risolti i
+\index{directory~di~lavoro} directory di lavoro, ha anche una directory
+\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
+ \var{pwd} e \var{root}) di \struct{fs\_struct}; vedi
+ fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
+alla radice dell'albero di file e directory come visto dal kernel (ed
+illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
+specifico di directory rispetto alla quale vengono risolti i
\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
sempre questa directory come punto di partenza.} Il fatto che questo valore
sia specificato per ogni processo apre allora la possibilità di modificare le
modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la directory
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la \index{directory~di~lavoro} directory
di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
-comunque accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
-(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
-filesystem.
+resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
+\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
+usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
+partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
+potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
+del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
-portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
-trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
-\func{chroot} su una qualunque directory contenuta nell'attuale directory di
-lavoro. Per questo motivo l'uso di questa funzione non ha molto senso quando
-un processo necessita dei privilegi di root per le sue normali operazioni.
+portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
+\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
+\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
+contenuta nell'attuale directory di lavoro. Per questo motivo l'uso di questa
+funzione non ha molto senso quando un processo necessita dei privilegi di root
+per le sue normali operazioni.
Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
(tanto che in certi casi il termine di puntatore a file è diventato sinonimo
di \textit{stream}). Tutte le funzioni della libreria che operano sui file
accettano come argomenti solo variabili di questo tipo, che diventa
-accessibile includendo l'header file \file{stdio.h}.
+accessibile includendo l'header file \headfile{stdio.h}.
\subsection{Gli \textit{stream standard}}
per ogni processo, corrispondono altrettanti \textit{stream}, che
rappresentano i canali standard di input/output prestabiliti; anche questi tre
\textit{stream} sono identificabili attraverso dei nomi simbolici definiti
-nell'header \file{stdio.h} che sono:
+nell'header \headfile{stdio.h} che sono:
\begin{basedescript}{\desclabelwidth{3.0cm}}
\item[\var{FILE *stdin}] Lo \textit{standard input} cioè il \textit{file
maggior parte dei casi questo avviene con la restituzione del valore
intero (di tipo \ctyp{int}) \val{EOF}\footnote{la costante deve essere
negativa, le \acr{glibc} usano -1, altre implementazioni possono avere
- valori diversi.} definito anch'esso nell'header \file{stdlib.h}.
+ valori diversi.} definito anch'esso nell'header \headfile{stdlib.h}.
Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
libreria che si appoggiano a delle system call, esse non impostano
Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
funzioni per la gestione dell'input/output di linea, il cui uso permette di
risolvere questi problemi. L'uso di queste funzioni deve essere attivato
-definendo la macro \macro{\_GNU\_SOURCE} prima di includere \file{stdio.h}. La
-prima delle due, \funcd{getline}, serve per leggere una linea terminata da un
-newline, esattamente allo stesso modo di \func{fgets}, il suo prototipo è:
+definendo la macro \macro{\_GNU\_SOURCE} prima di includere
+\headfile{stdio.h}. La prima delle due, \funcd{getline}, serve per leggere una
+linea terminata da un newline, esattamente allo stesso modo di \func{fgets},
+il suo prototipo è:
\begin{prototype}{stdio.h}
{ssize\_t getline(char **buffer, size\_t *n, FILE *stream)} Legge una linea
dal file \param{stream} copiandola sul buffer indicato da \param{buffer}
\textit{stream}. In genere conviene allocarlo con \func{malloc} e disallocarlo
dopo la chiusura del file; ma fintanto che il file è usato all'interno di una
funzione, può anche essere usata una \index{variabili!automatiche} variabile
-automatica. In \file{stdio.h} è definita la macro \const{BUFSIZ}, che indica
-le dimensioni generiche del buffer di uno \textit{stream}; queste vengono
-usate dalla funzione \func{setbuf}. Non è detto però che tale dimensione
-corrisponda sempre al valore ottimale (che può variare a seconda del
-dispositivo).
+automatica. In \headfile{stdio.h} è definita la macro \const{BUFSIZ}, che
+indica le dimensioni generiche del buffer di uno \textit{stream}; queste
+vengono usate dalla funzione \func{setbuf}. Non è detto però che tale
+dimensione corrisponda sempre al valore ottimale (che può variare a seconda
+del dispositivo).
Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi
(come delle scritture accidentali sul buffer) e non assicura la scelta delle
error}\\
\hline
\end{tabular}
- \caption{Costanti definite in \file{unistd.h} per i file standard aperti
+ \caption{Costanti definite in \headfile{unistd.h} per i file standard aperti
alla creazione di ogni processo.}
\label{tab:file_std_files}
\end{table}
#define _XOPEN_SOURCE 500
\end{verbatim}
e si ricordi di definire questa macro prima dell'inclusione del file di
-dichiarazioni \file{unistd.h}.
+dichiarazioni \headfile{unistd.h}.
Un problema che si pone con l'uso della funzione \func{open}, così come per
molte altre funzioni che accettano come argomenti dei pathname relativi, è
-che, quando un pathname relativo non fa riferimento alla directory di lavoro
-corrente, è possibile che alcuni dei suoi componenti vengano modificati in
-parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
-di una \itindex{race~condition} \textit{race condition}.
-
-Inoltre come già accennato, la directory di lavoro corrente è una proprietà
-del singolo processo; questo significa che quando si lavora con i
-\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
-molti casi in cui sarebbe invece utile che ogni singolo \itindex{thread}
-\textit{thread} avesse la sua directory di lavoro.
+che, quando un pathname relativo non fa riferimento alla
+\index{directory~di~lavoro} directory di lavoro corrente, è possibile che
+alcuni dei suoi componenti vengano modificati in parallelo alla chiamata a
+\func{open}, e questo lascia aperta la possibilità di una
+\itindex{race~condition} \textit{race condition}.
+
+Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
+corrente è una proprietà del singolo processo; questo significa che quando si
+lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
+ma esistono molti casi in cui sarebbe invece utile che ogni singolo
+\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
+directory di lavoro.
Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
seguito, dopo di che si dovrà passare il relativo file descriptor alle varie
funzioni che useranno quella directory come punto di partenza per la
risoluzione.\footnote{in questo modo, anche quando si lavora con i
- \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
- diversa per ciascuno di essi.}
+ \itindex{thread} \textit{thread}, si può mantenere una
+ \index{directory~di~lavoro} directory di lavoro diversa per ciascuno di
+ essi.}
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
\textit{race condition}, consente anche di ottenere aumenti di prestazioni
\funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
mode))}
- Apre un file usando come directory di lavoro corrente \param{dirfd}.
+ Apre un file usando come directory di \index{directory~di~lavoro} lavoro
+ corrente \param{dirfd}.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
errore di \func{open}, ed in più:
directory indicata da \param{dirfd}; qualora invece si usi un pathname
assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
\param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
- come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
+ come le altre costanti \texttt{AT\_*}, è definita in \headfile{fcntl.h},
pertanto se la si vuole usare occorrerà includere comunque questo file,
anche per le funzioni che non sono definite in esso.} la risoluzione sarà
-effettuata rispetto alla directory di lavoro corrente del processo.
+effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
+corrente del processo.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
casi esso può fornire ulteriori indicazioni per modificare il comportamento
delle funzioni, \param{flags} deve comunque essere passato come maschera
binaria, ed impostato usando i valori delle appropriate costanti
-\texttt{AT\_*}, definite in \texttt{fcntl.h}.
+\texttt{AT\_*}, definite in \headfile{fcntl.h}.
Come esempio di questo secondo tipo di funzioni possiamo considerare
\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
In questo caso il valore di \param{flags} stabilisce il comportamento della
funzione quando la si applica ad un link simbolico, e l'unico valore
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
+utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \headfile{fcntl.h} è
definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
link simbolici, essendo questo però il comportamento adottato per un valore
nullo di \param{flags} questo valore non viene mai usato.} che se impostato
il comportamento rispetto a quello ordinario di \func{access}. In questo caso
esso può essere specificato come maschera binaria di due valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo
+\item[\const{AT\_EACCES}] se impostato \funcd{faccessat} esegue il controllo
dei permessi usando l'\ids{UID} effettivo invece di quello reale (il
comportamento di default, che riprende quello di \func{access}).
\item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue
queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
motivo il valore della modalità di accesso corrente si ottiene eseguendo un
AND binario del valore di ritorno di \func{fcntl} con la maschera
-\const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
-accesso dal \textit{file status flag}.
+\const{O\_ACCMODE} (anch'essa definita in \headfile{fcntl.h}), che estrae i
+bit di accesso dal \textit{file status flag}.
In generale ogni dispositivo ha un suo insieme di operazioni specifiche
effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
-file \file{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui fanno
-riferimento. Infatti anche se in genere i valori di \param{request} sono
+file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
+fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
definizione delle macro da usare per \param{request}, in modo da essere
% LocalWords: Drepper path dirfd faccessat unlinkat access fchmodat chmod Di
% LocalWords: fchownat chown fstatat futimesat utimes linkat mknodat mknod uid
% LocalWords: readlinkat readlink renameat rename symlinkat symlink unlink gid
-% LocalWords: mkfifoat mkfifo FDCWD EACCESS dereferenziazione rmdir REMOVEDIR
+% LocalWords: mkfifoat mkfifo FDCWD dereferenziazione rmdir REMOVEDIR
% LocalWords: epoll lsattr chattr FIOQSIZE ATFILE lutimes utimensat lchown
% LocalWords: lstat owner FOLLOW
sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
directory radice dell'albero dei file; in questo caso si parla di un
\textsl{pathname assoluto} \itindsub{pathname}{assoluto}. Altrimenti la
-ricerca parte dalla directory di lavoro corrente del processo (su cui
-torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
-\itindsub{pathname}{relativo} \textsl{pathname relativo}.
+ricerca parte dalla \index{directory~di~lavoro} directory di lavoro corrente
+del processo (su cui torneremo in sez.~\ref{sec:file_work_dir}) ed il
+\textit{pathname} è detto \itindsub{pathname}{relativo} \textsl{pathname
+ relativo}.
Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
dispositivi. L'accesso viene gestito attraverso i \textit{file descriptor} che
sono rappresentati da numeri interi (cioè semplici variabili di tipo
\ctyp{int}). L'interfaccia è definita nell'\textit{header file}
-\file{unistd.h} e la tratteremo in dettaglio in
+\headfile{unistd.h} e la tratteremo in dettaglio in
cap.~\ref{cha:file_unix_interface}.
\itindbeg{file~stream}
Unix. Gli \textit{stream} sono oggetti complessi e sono rappresentati da
puntatori ad un opportuna struttura definita dalle librerie del C, ad essi si
accede sempre in maniera indiretta utilizzando il tipo \code{FILE *}.
-L'interfaccia è definita nell'\textit{header file} \file{stdio.h} e la
+L'interfaccia è definita nell'\textit{header file} \headfile{stdio.h} e la
tratteremo in dettaglio nel cap.~\ref{cha:files_std_interface}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
sez.~\ref{sec:proc_access_id}).\\
\hline
\end{tabular}
- \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.}
+ \caption{Elenco dei tipi primitivi, definiti in \headfile{sys/types.h}.}
\label{tab:intro_primitive_types}
\end{table}
riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
in tab.~\ref{tab:intro_primitive_types}, e definiti nell'\textit{header file}
-\file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
+\headfile{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
compilatore C.
Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
-occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
-in modo che il linker dinamico possa accedervi.
+occorrerà definire la variabile di ambiente \envvar{LD\_LIBRARY\_PATH} in modo
+che il linker dinamico possa accedervi.
In generale questa variabile indica il \itindex{pathname} \textit{pathname}
della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
\end{minipage}
\normalsize
\caption{La struttura \structd{ipc\_perm}, come definita in
- \file{sys/ipc.h}.}
+ \headfile{sys/ipc.h}.}
\label{fig:ipc_ipc_perm}
\end{figure}
propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
ed hanno lo stesso significato di quelli riportati in
tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
- simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
+ simboliche ivi definite occorrerà includere il file \headfile{sys/stat.h},
alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
\const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
\end{figure}
A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
-kernel mantiene le principali informazioni riguardo lo stato corrente della
+definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura
+il kernel mantiene le principali informazioni riguardo lo stato corrente della
coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
sia una differenza con i campi mostrati nello schema di
fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
- \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
- struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono elencati i
-campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
-ultimi tre campi che sono previsti dalla implementazione originale di System
-V, ma non dallo standard Unix98.
+ \file{include/linux/msg.h}, e fanno riferimento alla definizione della
+ omonima struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono
+elencati i campi significativi definiti in \headfile{sys/msg.h}, a cui si sono
+aggiunti gli ultimi tre campi che sono previsti dalla implementazione
+originale di System V, ma non dallo standard Unix98.
Quando si crea una nuova coda con \func{msgget} questa struttura viene
inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
comunque superare il limite \const{MSGMAX}.
La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
-la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
-campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
-La sola cosa che conta è che la struttura abbia come primo membro un campo
-\var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
-messaggio e deve essere sempre specificato come intero positivo di tipo
-\ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
+la definizione contenuta in \headfile{sys/msg.h} usa esplicitamente per il
+secondo campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini
+pratici. La sola cosa che conta è che la struttura abbia come primo membro un
+campo \var{mtype} come nell'esempio; esso infatti serve ad identificare il
+tipo di messaggio e deve essere sempre specificato come intero positivo di
+tipo \ctyp{long}. Il campo \var{mtext} invece può essere di qualsiasi tipo e
dimensione, e serve a contenere il testo del messaggio.
In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
Poi, per verificare che l'argomento specifichi effettivamente una directory,
si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
immediatamente in caso di errore. Questa funzione serve anche per impostare
-la directory di lavoro del programma nella directory da tenere sotto
-controllo, in vista del successivo uso della funzione
-\func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
+la \index{directory~di~lavoro} directory di lavoro del programma nella
+directory da tenere sotto controllo, in vista del successivo uso della
+funzione \func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
particolare scopo del programma, che necessita comunque di restare
all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
con l'esecuzione in background come si conviene ad un programma demone; si
noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-directory di lavoro corrente. Una volta che il programma è andato in
-background l'esecuzione prosegue (\texttt{\small 42--48}) all'interno di un
-ciclo infinito: si inizia (\texttt{\small 43}) bloccando il mutex con
-\func{MutexLock} per poter accedere alla memoria condivisa (la funzione si
-bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
- 44}) si cancellano i valori precedentemente immagazzinati nella memoria
-condivisa con \func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo
-degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
- 46}) si sblocca il mutex con \func{MutexUnlock}, e si attende
-(\texttt{\small 47}) per il periodo di tempo specificato a riga di comando con
-l'opzione \code{-p} con una \func{sleep}.
+\index{directory~di~lavoro} directory di lavoro corrente. Una volta che il
+programma è andato in background l'esecuzione prosegue (\texttt{\small
+ 42--48}) all'interno di un ciclo infinito: si inizia (\texttt{\small 43})
+bloccando il mutex con \func{MutexLock} per poter accedere alla memoria
+condivisa (la funzione si bloccherà automaticamente se qualche client sta
+leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente
+immagazzinati nella memoria condivisa con \func{memset}, e si esegue
+(\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione
+\func{DirScan}; infine (\texttt{\small 46}) si sblocca il mutex con
+\func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo
+specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}.
Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
\var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EACCESS}] il semaforo esiste ma non si hanno permessi
+ \item[\errcode{EACCES}] il semaforo esiste ma non si hanno permessi
sufficienti per accedervi.
\item[\errcode{EEXIST}] si sono specificati \const{O\_CREAT} e
\const{O\_EXCL} ma il semaforo esiste.
La seconda variante di \func{sem\_wait} è una estensione specifica che può
essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
-ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
+ad un valore di 600 prima di includere \headfile{semaphore.h}, la funzione è
\func{sem\_timedwait}, ed il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore; nel quel caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EACCESS}] non si hanno i permessi necessari a cancellare il
+ \item[\errcode{EACCES}] non si hanno i permessi necessari a cancellare il
semaforo.
\item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
\item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
% LocalWords: EBUSY sigev SIGNAL signo value sigval siginfo all'userid MESGQ
% LocalWords: Konstantin Knizhnik futex tmpfs ramfs cache shared swap CONFIG
% LocalWords: lrt blocks PAGECACHE TRUNC CLOEXEC mmap ftruncate munmap FindShm
-% LocalWords: CreateShm RemoveShm LIBRARY Library libmqueue FAILED EACCESS has
+% LocalWords: CreateShm RemoveShm LIBRARY Library libmqueue FAILED has
% LocalWords: ENAMETOOLONG qualchenome RESTART trywait XOPEN SOURCE timedwait
% LocalWords: process getvalue sval execve pshared ENOSYS heap PAGE destroy it
% LocalWords: xffffffff Arrays owner perms Queues used bytes messages device
\newcommand{\ctyp}[1]{\texttt{#1}} % C standard type
\newcommand{\headfile}[1]{%
-\index{file!include!{#1}@{{\tt {#1}}}}\texttt{#1}%
-%\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
+%\index{file!include!{#1}@{{\tt {#1}}}}\texttt{#1}%
+\texttt{#1}%
} % header file name
+
\newcommand{\procfile}[1]{%
\index{file!filesystem~\texttt{/proc}!{#1}@{{\tt {#1}}}}\texttt{#1}%
%\index{#1@{{\tt {#1}} (direttiva)}}\texttt{#1}%
\newcommand{\acr}[1]{\textsl{#1}} % acrostic (for glibc, ext2, ecc.)
\newcommand{\ids}[1]{\textsl{#1}} % Identifier (PID, GID, UID, TID, ecc.)
-
-
-
-
+\newcommand{\envvar}[1]{\texttt{#1}} % environment variable
\newcommand{\itindex}[1]{%
\index{#1@{\textit{#1}}}%
ambiente e dal contenuto del file \conffile{/etc/ld.so.conf}, che consentono
di elencare le directory un cui cercare le librerie e determinare quali
verranno utilizzate. In particolare con la variabile di ambiente
-\texttt{LD\_LIBRARY\_PATH} si possono indicare ulteriori directory rispetto a
+\envvar{LD\_LIBRARY\_PATH} si possono indicare ulteriori directory rispetto a
quelle di sistema in cui inserire versioni personali delle librerie che hanno
la precedenza su quelle di sistema, mentre con la variabile di ambiente
-\texttt{LD\_PRELOAD} si può passare direttamente una lista di file di librerie
+\envvar{LD\_PRELOAD} si può passare direttamente una lista di file di librerie
condivise da usare al posto di quelli di sistema. In questo modo è possibile
effettuare lo sviluppo o il test di nuove librerie senza dover sostituire
quelle di sistema. Ulteriori dettagli sono riportati nella pagina di manuale
il controllo e la conversione del tipo di caratteri,
\item i nomi che iniziano con ``\texttt{LC\_}'' e costituiti
da lettere maiuscole che possono essere usato per macro attinenti la
- localizzazione (vedi sez.~\ref{sec:proc_localization}),
+ localizzazione,% mettere in seguito (vedi sez.~\ref{sec:proc_localization}),
\item nomi che iniziano con ``\texttt{SIG}'' o ``\texttt{SIG\_}'' e costituiti
da lettere maiuscole che potrebbero essere usati per nuovi nomi di segnale
(vedi sez.~\ref{sec:sig_classification}),
& ANSI C& POSIX& \\
\hline
\hline
- \file{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
- programma.\\
- \file{ctype.h} &$\bullet$& -- & Tipi standard.\\
- \file{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
- \file{errno.h} & -- &$\bullet$& Errori di sistema.\\
- \file{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei file.\\
- \file{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
- \file{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
- \file{setjmp.h}&$\bullet$& -- & Salti non locali.\\
- \file{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
- \file{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
- variabili.\\
- \file{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI C.\\
- \file{stdlib.h}&$\bullet$& -- & Definizioni della libreria standard.\\
- \file{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
- \file{time.h} & -- &$\bullet$& Gestione dei tempi.\\
- \file{times.h} &$\bullet$& -- & Gestione dei tempi.\\
- \file{unistd.h}& -- &$\bullet$& Unix standard library.\\
- \file{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
+ \headfile{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
+ programma.\\
+ \headfile{ctype.h} &$\bullet$& -- & Tipi standard.\\
+ \headfile{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
+ \headfile{errno.h} & -- &$\bullet$& Errori di sistema.\\
+ \headfile{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei file.\\
+ \headfile{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
+ \headfile{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
+ \headfile{setjmp.h}&$\bullet$& -- & Salti non locali.\\
+ \headfile{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
+ \headfile{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
+ variabili.\\
+ \headfile{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI
+ C.\\
+ \headfile{stdlib.h}&$\bullet$& -- & Definizioni della libreria
+ standard.\\
+ \headfile{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
+ \headfile{time.h} & -- &$\bullet$& Gestione dei tempi.\\
+ \headfile{times.h} &$\bullet$& -- & Gestione dei tempi.\\
+ \headfile{unistd.h}& -- &$\bullet$& Unix standard library.\\
+ \headfile{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
\hline
\end{tabular}
\caption{Elenco dei principali \textit{header file} definiti dagli standard
riservano degli ulteriori identificativi, il cui uso sarà da evitare, ad
esempio si avrà che:
\begin{itemize*}
-\item in \file{dirent.h} vengono riservati i nomi che iniziano con
+\item in \headfile{dirent.h} vengono riservati i nomi che iniziano con
``\texttt{d\_}'' e costituiti da lettere minuscole,
-\item in \file{fcntl.h} vengono riservati i nomi che iniziano con
+\item in \headfile{fcntl.h} vengono riservati i nomi che iniziano con
``\texttt{l\_}'', ``\texttt{F\_}'',``\texttt{O\_}'' e ``\texttt{S\_}'',
-\item in \file{limits.h} vengono riservati i nomi che finiscono in
+\item in \headfile{limits.h} vengono riservati i nomi che finiscono in
``\texttt{\_MAX}'',
-\item in \file{signal.h} vengono riservati i nomi che iniziano con
+\item in \headfile{signal.h} vengono riservati i nomi che iniziano con
``\texttt{sa\_}'' e ``\texttt{SA\_}'',
-\item in \file{sys/stat.h} vengono riservati i nomi che iniziano con
+\item in \headfile{sys/stat.h} vengono riservati i nomi che iniziano con
``\texttt{st\_}'' e ``\texttt{S\_}'',
-\item in \file{sys/times.h} vengono riservati i nomi che iniziano con
+\item in \headfile{sys/times.h} vengono riservati i nomi che iniziano con
``\texttt{tms\_}'',
-\item in \file{termios.h} vengono riservati i nomi che iniziano con
+\item in \headfile{termios.h} vengono riservati i nomi che iniziano con
``\texttt{c\_}'', ``\texttt{V}'', ``\texttt{I}'', ``\texttt{O}'' e
``\texttt{TC}'' e con ``\texttt{B}'' seguito da un numero,
-\item in \file{grp.h} vengono riservati i nomi che iniziano con
+\item in \headfile{grp.h} vengono riservati i nomi che iniziano con
``\texttt{gr\_}'',
-\item in \file{pwd.h}vengono riservati i nomi che iniziano con
+\item in \headfile{pwd.h}vengono riservati i nomi che iniziano con
``\texttt{pw\_}'',
\end{itemize*}
ciascuna \textit{system call} viene in genere identificata da una costante
nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
corrisponde anche alla omonima funzione di libreria. Queste costanti sono
-definite nel file \texttt{sys/syscall.h}, ma si possono anche usare
+definite nel file \headfile{sys/syscall.h}, ma si possono anche usare
direttamente valori numerici.
usare un multiplo di 256, di avere uno stato di uscita uguale a zero, che
verrebbe interpretato come un successo.
-Per questo motivo in \file{stdlib.h} sono definite, seguendo lo standard
+Per questo motivo in \headfile{stdlib.h} sono definite, seguendo lo standard
POSIX, le due costanti \const{EXIT\_SUCCESS} e \const{EXIT\_FAILURE}, da usare
sempre per specificare lo stato di uscita di un processo. Su Linux, ed in
generale in qualunque sistema POSIX, ad esse sono assegnati rispettivamente i
Una forma alternativa per effettuare una terminazione esplicita di un
programma è quella di chiamare direttamente la \textit{system call}
-\func{\_exit}, che restituisce il controllo direttamente al kernel,
+\funcd{\_exit},\footnote{la stessa è definita anche come \funcd{\_Exit} in
+ \headfile{stdlib.h}.} che restituisce il controllo direttamente al kernel,
concludendo immediatamente il processo, il suo prototipo è:
\begin{funcproto}{ \fhead{unistd.h} \fdecl{void \_exit(int status)}
% \includegraphics[width=9cm]{img/proc_beginend}
\begin{tikzpicture}[>=stealth]
\filldraw[fill=black!35] (-0.3,0) rectangle (12,1);
- \draw(5.5,0.5) node {\large{kernel}};
+ \draw(5.5,0.5) node {\large{\textsf{kernel}}};
\filldraw[fill=black!15] (1.5,2) rectangle (4,3);
\draw (2.75,2.5) node {\texttt{ld-linux.so}};
\draw[->] (4,4.5) -- node[anchor=south]{\texttt{exit}} (exit);
\draw[->] (exit) -- node[anchor=east]{\texttt{\_exit}}(6.75,1);
- \draw (10,4.5) node (exithandler1) [rectangle,fill=black!15,rounded corners, draw]{exit handler};
- \draw (10,5.5) node (exithandler2) [rectangle,fill=black!15,rounded corners, draw]{exit handler};
- \draw (10,3.5) node (stream) [rectangle,fill=black!15,rounded corners, draw]{chiusura stream};
+ \draw (10,4.5) node (exithandler1) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
+ \draw (10,5.5) node (exithandler2) [rectangle,fill=black!15,rounded corners, draw]{\textsf{exit handler}};
+ \draw (10,3.5) node (stream) [rectangle,fill=black!15,rounded corners, draw]{\textsf{chiusura stream}};
\draw[<->, dashed] (exithandler1) -- (exit);
\draw[<->, dashed] (exithandler2) -- (exit);
anche utilizzare pagine di dimensioni maggiori (di 4Mb, dette \textit{huge
page}), per sistemi con grandi quantitativi di memoria in cui l'uso di
pagine troppo piccole comporta una perdita di prestazioni. In alcuni sistemi
-la costante \const{PAGE\_SIZE}, definita in \file{limits.h}, indica la
+la costante \const{PAGE\_SIZE}, definita in \headfile{limits.h}, indica la
dimensione di una pagina in byte, con Linux questo non avviene e per ottenere
questa dimensione si deve ricorrere alla funzione \func{getpagesize} (vedi
sez.~\ref{sec:sys_memory_res}).
La \acr{glibc} ha un'implementazione delle funzioni di allocazione che è
controllabile dall'utente attraverso alcune variabili di ambiente (vedi
sez.~\ref{sec:proc_environ}), in particolare diventa possibile tracciare
-questo tipo di errori usando la variabile di ambiente \val{MALLOC\_CHECK\_}
+questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
che quando viene definita mette in uso una versione meno efficiente delle
funzioni suddette, che però è più tollerante nei confronti di piccoli errori
come quello dei \itindex{double~free} \textit{double~free} o i
Il sistema pone dei limiti all'ammontare di memoria di un processo che può
essere bloccata e al totale di memoria fisica che si può dedicare a questo, lo
-standard POSIX.1 richiede che sia definita in \file{unistd.h} la macro
+standard POSIX.1 richiede che sia definita in \headfile{unistd.h} la macro
\macro{\_POSIX\_MEMLOCK\_RANGE} per indicare la capacità di eseguire il
\textit{memory locking}.
Nessuna delle due funzioni ha una chiara standardizzazione e nessuna delle due
compare in POSIX.1, inoltre ci sono indicazioni discordi sui file che ne
contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
- \texttt{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4} e
- \acr{libc5} la dichiarano in \texttt{malloc.h}, lo stesso vale per
- \func{memalign} che in alcuni sistemi è dichiarata in \texttt{stdlib.h}.}
+ \headfile{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4}
+ e \acr{libc5} la dichiarano in \headfile{malloc.h}, lo stesso vale per
+ \func{memalign} che in alcuni sistemi è dichiarata in \headfile{stdlib.h}.}
per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
prototipo è:
Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
-\var{MALLOC\_CHECK\_}. Una modalità alternativa per effettuare dei controlli
-di consistenza sullo stato delle allocazioni di memoria eseguite con
+\envvar{MALLOC\_CHECK\_}. Una modalità alternativa per effettuare dei
+controlli di consistenza sullo stato delle allocazioni di memoria eseguite con
\func{malloc}, anche questa fornita come estensione specifica (e non standard)
della \acr{glibc}, è quella di utilizzare la funzione \funcd{mcheck}, che deve
essere chiamata prima di eseguire qualunque allocazione con \func{malloc}; il
queste variabili al programma messo in esecuzione attraverso un uso opportuno
delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
-La shell ad esempio ne usa molte per il suo funzionamento, come \texttt{PATH}
+La shell ad esempio ne usa molte per il suo funzionamento, come \envvar{PATH}
per indicare la lista delle directory in cui effettuare la ricerca dei comandi
-o \texttt{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
-\texttt{HOME}, \texttt{USER}, ecc. sono invece definite al login (per i
+o \envvar{PS1} per impostare il proprio \textit{prompt}. Alcune di esse, come
+\envvar{HOME}, \envvar{USER}, ecc. sono invece definite al login (per i
dettagli si veda sez.~\ref{sec:sess_login}), ed in genere è cura della propria
distribuzione definire le opportune variabili di ambiente in uno script di
avvio. Alcune servono poi come riferimento generico per molti programmi, come
-\texttt{EDITOR} che indica l'editor preferito da invocare in caso di
-necessità. Una in particolare, \texttt{LANG}, serve a controllare la
-localizzazione del programma (su cui torneremo in
-sez.~\ref{sec:proc_localization}) per adattarlo alla lingua ed alle convezioni
+\envvar{EDITOR} che indica l'editor preferito da invocare in caso di
+necessità. Una in particolare, \envvar{LANG}, serve a controllare la
+localizzazione del programma
+%(su cui torneremo in sez.~\ref{sec:proc_localization})
+per adattarlo alla lingua ed alle convezioni
dei vari paesi.
Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
\index{variabili!di~ambiente|)}
-\subsection{La localizzazione}
-\label{sec:proc_localization}
+% \subsection{La localizzazione}
+% \label{sec:proc_localization}
-Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
-\texttt{LANG} sia usata per indicare ai processi il valore della cosiddetta
-\textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
-di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
-che consente di gestire in maniera automatica sia la lingua in cui vengono
-stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
-sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
-serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
-alfabetici, le espressioni della valute, ecc.
+% Abbiamo accennato in sez.~\ref{sec:proc_environ} come la variabile di ambiente
+% \envvar{LANG} sia usata per indicare ai processi il valore della cosiddetta
+% \textsl{localizzazione}. Si tratta di una funzionalità fornita dalle librerie
+% di sistema\footnote{prenderemo in esame soltanto il caso della \acr{glibc}.}
+% che consente di gestire in maniera automatica sia la lingua in cui vengono
+% stampati i vari messaggi (come i messaggi associati agli errori che vedremo in
+% sez.~\ref{sec:sys_strerror}) che le convenzioni usate nei vari paesi per una
+% serie di aspetti come il formato dell'ora, quello delle date, gli ordinamenti
+% alfabetici, le espressioni della valute, ecc.
-Da finire.
+% Da finire.
% La localizzazione di un programma si può selezionare con la
Lo standard ISO C prevede che una \textit{variadic function} abbia sempre
almeno un argomento fisso. Prima di effettuare la dichiarazione deve essere
-incluso l'apposito \textit{header file} \file{stdarg.h}; un esempio di
+incluso l'apposito \textit{header file} \headfile{stdarg.h}; un esempio di
dichiarazione è il prototipo della funzione \func{execl} che vedremo in
sez.~\ref{sec:proc_exec}:
\includecodesnip{listati/exec_sample.c}
\textit{stack} secondo l'ordine in cui sono stati scritti nel prototipo della
funzione.
-Per fare questo in \file{stdarg.h} sono definite delle macro specifiche,
+Per fare questo in \headfile{stdarg.h} sono definite delle macro specifiche,
previste dallo standard ISO C89, che consentono di eseguire questa operazione.
La prima di queste macro è \macro{va\_start}, che inizializza opportunamente
una lista degli argomenti, la sua definizione è:
qualunque altro programma, e in casi di emergenza (ad esempio se il file di
\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
- parametro di avvio del kernel, l'argomento è di natura amministrativa e
+ parametro di avvio del kernel, l'argomento è di natura sistemistica e
trattato in sez.~5.3 di \cite{AGL}.}
\begin{figure}[!htb]
\item gli identificatori per il controllo di sessione: il
\itindex{process~group} \textit{process group-ID} e il \textit{session id}
ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
-\item la directory di lavoro e la directory radice (vedi
- sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
+\item la \index{directory~di~lavoro} directory di lavoro e la directory radice
+ (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
Si tenga conto che nel caso di conclusione anomala il valore restituito da
\val{WTERMSIG} può essere confrontato con le costanti che identificano i
-segnali definite in \file{signal.h} ed elencate in
+segnali definite in \headfile{signal.h} ed elencate in
tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
trattate in sez.~\ref{sec:sig_strsignal}.
per i valori dei primi tre argomenti, ma in più restituisce nell'argomento
aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo
argomento è una struttura di tipo \struct{rusage} definita in
-\file{sys/resource.h}, che viene utilizzata anche dalla funzione
+\headfile{sys/resource.h}, che viene utilizzata anche dalla funzione
\func{getrusage} per ottenere le risorse di sistema usate da un processo. La
sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne
tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La
specificare il comando da eseguire; quando l'argomento \param{file} non
contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
e viene eseguita automaticamente una ricerca fra i file presenti nella lista
-di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
-viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
+di directory specificate dalla variabile di ambiente \envvar{PATH}. Il file
+che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
relativo a permessi di accesso insufficienti (cioè l'esecuzione della
sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
-proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
-non viene trovato nessun altro file viene finalmente restituito
+proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
+se non viene trovato nessun altro file viene finalmente restituito
\errcode{EACCES}. Le altre quattro funzioni si limitano invece a cercare di
eseguire il file indicato dall'argomento \param{path}, che viene interpretato
come il \itindex{pathname} \textit{pathname} del programma.
(\ids{PPID});
\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item la directory radice e la directory di lavoro corrente (vedi
- sez.~\ref{sec:file_work_dir});
+\item la directory radice e la \index{directory~di~lavoro} directory di lavoro
+ corrente (vedi sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
-essere necessario includere anche \code{sys/time.h}, questo non è più
+essere necessario includere anche \headfile{sys/time.h}, questo non è più
necessario con versioni recenti delle librerie, ma è comunque utile per
portabilità.
che per i primi la priorità statica può essere soltanto nulla. La
disponibilità di entrambe le funzioni può essere verificata controllando la
macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
- file} \file{sched.h}.
+ file} \headfile{sched.h}.
Se invece si vuole sapere quale è politica di \textit{scheduling} di un
processo si può usare la funzione \funcd{sched\_getscheduler}, il cui
aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
trovare indicazioni diverse, il prototipo illustrato è quello riportato
nella versione corrente (maggio 2008) delle pagine di manuale e
- corrispondente alla definizione presente in \file{sched.h}.}
+ corrispondente alla definizione presente in \headfile{sched.h}.}
La funzione imposta, con l'uso del valore contenuto all'indirizzo
\param{mask}, l'insieme dei processori sui quali deve essere eseguito il
\textit{secure computing mode} il processo potrà utilizzare soltanto un
insieme estremamente limitato di \textit{system call}: \func{read},
\func{write}, \func{\_exit} e \func{sigreturn}. Ogni altra \textit{system
- call} porterà all'emissione di un \func{SIGKILL} (vedi
+ call} porterà all'emissione di un \signal{SIGKILL} (vedi
sez.~\ref{sec:sig_termination}). Il \textit{secure computing mode} è stato
ideato per fornire un supporto per l'esecuzione di codice esterno non fidato
e non verificabile a scopo di calcolo;\footnote{lo scopo è quello di poter
funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
che la chiamata di questa funzione in \itindex{secure~computing~mode}
\textit{secure computing mode} comporterebbe l'emissione di
- \texttt{SIGKILL}, è stata comunque definita per eventuali estensioni future.
+ \signal{SIGKILL}, è stata comunque definita per eventuali estensioni future.
Introdotta a partire dal kernel 2.6.23.
\item[\const{PR\_SET\_SECUREBITS}] Imposta i \itindex{securebits}
per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
visti in sez.~\ref{sec:proc_pid}) che il kernel associa a ciascun
processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
- \var{pgrp} e \var{session} della struttura \struct{task\_struct} definita in
- \file{sched.h}.} l'identificatore del \textit{process group} e
-l'identificatore della \textsl{sessione}, che vengono indicati rispettivamente
-con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo
-\type{pid\_t}. I valori di questi identificatori possono essere visualizzati
-dal comando \cmd{ps} usando l'opzione \cmd{-j}.
+ \var{pgrp} e \var{session} della struttura \kstruct{task\_struct} definita
+ in \file{include/linux/sched.h}.} l'identificatore del \textit{process
+ group} e l'identificatore della \textsl{sessione}, che vengono indicati
+rispettivamente con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in
+variabili di tipo \type{pid\_t}. I valori di questi identificatori possono
+essere visualizzati dal comando \cmd{ps} usando l'opzione \cmd{-j}.
Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
il programma \cmd{login} con una \func{exevle}, passando come argomento la
stringa con il nome, ed un ambiente opportunamente costruito che contenga
quanto necessario; ad esempio di solito viene opportunamente inizializzata la
-variabile di ambiente \texttt{TERM} per identificare il terminale su cui si
+variabile di ambiente \envvar{TERM} per identificare il terminale su cui si
sta operando, a beneficio dei programmi che verranno lanciati in seguito.
A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
rilanciare un'altra istanza di \cmd{getty}.
Se invece la password corrisponde \cmd{login} esegue \func{chdir} per
-impostare come directory di lavoro la \textit{home directory} dell'utente,
-cambia i diritti di accesso al terminale (con \func{chown} e \func{chmod}) per
-assegnarne la titolarità all'utente ed al suo gruppo principale, assegnandogli
-al contempo i diritti di lettura e scrittura.\footnote{oggi queste operazioni,
- insieme ad altre relative alla contabilità ed alla tracciatura degli
- accessi, vengono gestite dalle distribuzioni più recenti in una maniera
- generica appoggiandosi a servizi di sistema come \textit{ConsoleKit}, ma il
- concetto generale resta sostanzialmente lo stesso.} Inoltre il programma
-provvede a costruire gli opportuni valori per le variabili di ambiente, come
-\texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid},
-\func{setgid} e \func{initgroups} verrà cambiata l'identità del proprietario
-del processo, infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo
-invocato tali funzioni con i privilegi di amministratore, tutti gli \ids{UID}
-ed i \ids{GID} (reali, effettivi e salvati) saranno impostati a quelli
-dell'utente.
+impostare come \index{directory~di~lavoro} directory di lavoro la \textit{home
+ directory} dell'utente, cambia i diritti di accesso al terminale (con
+\func{chown} e \func{chmod}) per assegnarne la titolarità all'utente ed al suo
+gruppo principale, assegnandogli al contempo i diritti di lettura e
+scrittura.\footnote{oggi queste operazioni, insieme ad altre relative alla
+ contabilità ed alla tracciatura degli accessi, vengono gestite dalle
+ distribuzioni più recenti in una maniera generica appoggiandosi a servizi di
+ sistema come \textit{ConsoleKit}, ma il concetto generale resta
+ sostanzialmente lo stesso.} Inoltre il programma provvede a costruire gli
+opportuni valori per le variabili di ambiente, come \envvar{HOME},
+\envvar{SHELL}, ecc. Infine attraverso l'uso di \func{setuid}, \func{setgid}
+e \func{initgroups} verrà cambiata l'identità del proprietario del processo,
+infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo invocato tali
+funzioni con i privilegi di amministratore, tutti gli \ids{UID} ed i \ids{GID}
+(reali, effettivi e salvati) saranno impostati a quelli dell'utente.
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
non potrà ottenere automaticamente un terminale di controllo.
-\item Eseguire una \func{chdir} per impostare la directory di lavoro del
- processo (su \file{/} o su una directory che contenga dei file necessari per
- il programma), per evitare che la directory da cui si è lanciato il processo
- resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
- contiene.
+\item Eseguire una \func{chdir} per impostare la \index{directory~di~lavoro}
+ directory di lavoro del processo (su \file{/} o su una directory che
+ contenga dei file necessari per il programma), per evitare che la directory
+ da cui si è lanciato il processo resti in uso e non sia possibile rimuoverla
+ o smontare il filesystem che la contiene.
\item Impostare la \itindex{umask} maschera dei permessi (di solito con
\code{umask(0)}) in modo da non essere dipendenti dal valore ereditato da
chi ha lanciato originariamente il processo.
padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
\func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
-directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
-vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
-di valori non nulli non viene eseguita nessuna altra azione.
+\index{directory~di~lavoro} directory di lavoro su \file{/},
+se \param{noclose} è nullo i file standard vengono rediretti su
+\file{/dev/null} (corrispondenti ai passi 4 e 6); in caso di valori non nulli
+non viene eseguita nessuna altra azione.
Dato che un programma demone non può più accedere al terminale, si pone il
problema di come fare per la notifica di eventuali errori, non potendosi più
\normalsize
\caption{Definizione delle stringhe coi relativi valori numerici che
indicano le priorità dei messaggi del kernel (ripresa da
- \texttt{linux/kernel.h}).}
+ \file{include/linux/kernel.h}).}
\label{fig:printk_priority}
\end{figure}
\texttt{syslog}, ma dato il conflitto di nomi questa viene rimappata su
un'altra funzione di libreria, in particolare nelle \acr{glibc} essa viene
invocata tramite la funzione \funcd{klogctl},\footnote{nelle \acr{libc4} e
- nelle \acr{libc5} la funzione invece era \func{SYS\_klog}.} il cui prototipo
+ nelle \acr{libc5} la funzione invece era \code{SYS\_klog}.} il cui prototipo
è:
\begin{prototype}{sys/klog.h}{int klogctl(int op, char *buffer, int len)}
Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso
diretto di questo numero da parte dei programmi è da evitare, in quanto esso
può variare a seconda dell'implementazione del sistema, e nel caso di Linux,
-anche a seconda dell'architettura hardware.
-Per questo motivo ad ogni segnale viene associato un nome, definendo con una
-macro di preprocessore una costante uguale al suddetto numero. Sono questi
-nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie
-implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
-che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
+anche a seconda dell'architettura hardware. Per questo motivo ad ogni segnale
+viene associato un nome, definendo con una macro di preprocessore una costante
+uguale al suddetto numero. Sono questi nomi, che sono standardizzati e
+sostanzialmente uniformi rispetto alle varie implementazioni, che si devono
+usare nei programmi. Tutti i nomi e le funzioni che concernono i segnali sono
+definiti nell'header di sistema \headfile{signal.h}.
Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
segnale può condurre ad un ciclo infinito.
% Per questo segnale le cose sono complicate dal fatto che possono esserci
-% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
+% molte diverse eccezioni che \signal{SIGFPE} non distingue, mentre lo
% standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
% aritmetiche e richiede che esse siano notificate.
% TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni
Una modalità alternativa per utilizzare le descrizioni restituite da
\func{strsignal} e \func{psignal} è quello di usare la variabile
-\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
-con la dichiarazione:
+\var{sys\_siglist}, che è definita in \headfile{signal.h} e può essere
+acceduta con la dichiarazione:
\includecodesnip{listati/siglist.c}
L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie
librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle
\acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al
- posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene
+ posto di \headfile{signal.h}, nel qual caso la funzione \func{signal} viene
ridefinita per seguire la semantica affidabile usata da BSD.}
Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale
di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i
-programmi che le usano devono essere collegati con la libreria delle estensioni
-\textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}. Si tenga
-presente inoltre che la disponibilità di queste funzionalità avanzate può
-essere controllato dalla definizione della macro \macro{\_POSIX\_TIMERS} ad un
-valore maggiore di 0, e che le ulteriori macro
+programmi che le usano devono essere collegati con la libreria delle
+estensioni \textit{real-time} usando esplicitamente l'opzione
+\texttt{-lrt}. Si tenga presente inoltre che la disponibilità di queste
+funzionalità avanzate può essere controllato dalla definizione della macro
+\macro{\_POSIX\_TIMERS} ad un valore maggiore di 0, e che le ulteriori macro
\macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e
\macro{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi
di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e
\const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{tutte queste macro sono definite
- in \texttt{unistd.h}, che pertanto deve essere incluso per poterle
+ in \headfile{unistd.h}, che pertanto deve essere incluso per poterle
controllarle.} Infine se il kernel ha il supporto per gli \textit{high
resolution timer} un elenco degli orologi e dei timer può essere ottenuto
tramite il file \procfile{/proc/timer\_list}.
\label{fig:struct_sigevent}
\end{figure}
-La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è
+La struttura \struct{sigevent} (accessibile includendo \headfile{time.h}) è
riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva
dipende dall'implementazione, quella mostrata è la versione descritta nella
- pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il
-più importante essendo quello che indica le modalità della notifica, gli altri
-dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono
-riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del meccanismo di
-notifica viene fatta impostando uno dei valori di
+ pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è
+il più importante essendo quello che indica le modalità della notifica, gli
+altri dipendono dal valore che si è specificato per \var{sigev\_notify}, si
+sono riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del
+meccanismo di notifica viene fatta impostando uno dei valori di
tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli
eventuali ulteriori argomenti necessari a secondo della scelta
effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione
\end{enumerate*}
In genere il primo passo viene effettuato allocando un'opportuna area di
-memoria con \code{malloc}; in \file{signal.h} sono definite due costanti,
+memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti,
\const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per
allocare una quantità di spazio opportuna, in modo da evitare overflow. La
prima delle due è la dimensione canonica per uno \itindex{stack}
sono specificati server verrà utilizzato l'indirizzo locale, e se non è
definito un dominio di default sarà usato quello associato con l'indirizzo
locale (ma questo può essere sovrascritto con l'uso della variabile di
-ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
+ambiente \envvar{LOCALDOMAIN}). In genere non è necessario eseguire questa
funzione direttamente in quanto viene automaticamente chiamata la prima volta
che si esegue una delle altre.
Le impostazioni e lo stato del \textit{resolver} vengono mantenuti in una
serie di variabili raggruppate nei campi di una apposita struttura \var{\_res}
-usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
-utilizzata internamente alle funzioni essendo definita come variabile globale;
-questo consente anche di accedervi direttamente all'interno di un qualunque
-programma, una volta che la sia opportunamente dichiarata come:
+usata da tutte queste funzioni. Essa viene definita in \headfile{resolv.h} ed
+è utilizzata internamente alle funzioni essendo definita come variabile
+globale; questo consente anche di accedervi direttamente all'interno di un
+qualunque programma, una volta che la sia opportunamente dichiarata come:
\includecodesnip{listati/resolv_option.c}
Tutti i campi della struttura sono ad uso interno, e vengono usualmente
\const{RES\_INSECURE1} & Blocca i controlli di sicurezza di tipo 1.\\
\const{RES\_INSECURE2} & Blocca i controlli di sicurezza di tipo 2.\\
\const{RES\_NOALIASES} & Blocca l'uso della variabile di ambiente
- \texttt{HOSTALIASES}.\\
+ \envvar{HOSTALIASES}.\\
\const{RES\_USE\_INET6} & Restituisce indirizzi IPv6 con
\func{gethostbyname}. \\
\const{RES\_ROTATE} & Ruota la lista dei server DNS dopo ogni
modificarli direttamente; gran parte di essi sono infatti impostati dal
contenuto dei file di configurazione, mentre le funzionalità controllate da
alcuni di esse possono essere modificate con l'uso delle opportune variabili
-di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
-\texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
+di ambiente come abbiamo visto per \envvar{LOCALDOMAIN}. In particolare con
+\envvar{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
controlla quante volte viene ripetuto il tentativo di connettersi ad un server
DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
-significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
+significa bloccare l'uso del DNS. Infine con \envvar{RES\_TIMEOUT} si
soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
- della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
-valore preso come base (in numero di secondi) per definire la scadenza di una
-richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
-il tempo di scadenza per il numero massimo di volte stabilito da
+ della omonima costante \const{RES\_TIMEOUT} di \headfile{resolv.h}.} che è
+il valore preso come base (in numero di secondi) per definire la scadenza di
+una richiesta, ciascun tentativo di richiesta fallito viene ripetuto
+raddoppiando il tempo di scadenza per il numero massimo di volte stabilito da
\texttt{RES\_RETRY}.
La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
eseguire una richiesta ad un server DNS per un nome a dominio
-\textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
- Qualified Domain Name}); il suo prototipo è:
+\textsl{completamente specificato} (quello che si chiama
+\itindex{Fully~Qualified~Domain~Name~(FQDN)} FQDN, \textit{Fully Qualified
+ Domain Name}); il suo prototipo è:
\begin{functions}
\headdecl{netinet/in.h}
Come accennato le tipologie di dati che sono mantenibili su un server DNS sono
diverse, ed a ciascuna di essa corrisponde un diverso tipo di \textit{resource
record}. L'elenco delle costanti\footnote{ripreso dai file di dichiarazione
- \file{arpa/nameser.h} e \file{arpa/nameser\_compat.h}.} che definiscono i
-valori che si possono usare per l'argomento \param{type} per specificare il
-tipo di \textit{resource record} da richiedere è riportato in
+ \headfile{arpa/nameser.h} e \headfile{arpa/nameser\_compat.h}.} che
+definiscono i valori che si possono usare per l'argomento \param{type} per
+specificare il tipo di \textit{resource record} da richiedere è riportato in
tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
hanno gli stessi nomi usati per identificare i record nei file di zona di
BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
implementazione di un server DNS, ed, essendo utilizzata nella stragrande
- maggioranza dei casi, fa da riferimento; i dati relativi ad un certo
- dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
- che sono usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo
- di dominio è identificato da un nome che è appunto identico a quello delle
- costanti di tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.}
-e che normalmente sono anche usati come nomi per indicare i record.
+ maggioranza dei casi, fa da riferimento; i dati relativi ad un certo dominio
+ (cioè i suoi \textit{resource record} vengono mantenuti in quelli che sono
+ usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo di dominio
+ è identificato da un nome che è appunto identico a quello delle costanti di
+ tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.} e che
+normalmente sono anche usati come nomi per indicare i record.
\begin{table}[!htb]
\centering
In questo caso la funzione prende un secondo argomento \param{af} che indica
(i soli valori consentiti sono \const{AF\_INET} o \const{AF\_INET6}, per
-questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
+questo è necessario l'uso di \headfile{sys/socket.h}) la famiglia di indirizzi
che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
suoi risultati.
\end{figure}
Come illustrato la struttura \struct{addrinfo}, la cui definizione\footnote{la
- definizione è ripresa direttamente dal file \texttt{netdb.h} in questa
+ definizione è ripresa direttamente dal file \headfile{netdb.h} in questa
struttura viene dichiarata, la pagina di manuale riporta \type{size\_t} come
tipo di dato per il campo \var{ai\_addrlen}, qui viene usata quanto previsto
dallo standard POSIX, in cui viene utilizzato \type{socklen\_t}; i due tipi
qualora la loro dimensione ecceda quelle specificate dagli argomenti
\param{hostlen} e \param{servlen}. Sono comunque definite le due costanti
\const{NI\_MAXHOST} e \const{NI\_MAXSERV}\footnote{in Linux le due costanti
- sono definite in \file{netdb.h} ed hanno rispettivamente il valore 1024 e
- 12.} che possono essere utilizzate come limiti massimi. In caso di errore
-viene restituito invece un codice che assume gli stessi valori illustrati in
-tab.~\ref{tab:addrinfo_error_code}.
+ sono definite in \headfile{netdb.h} ed hanno rispettivamente il valore 1024
+ e 12.} che possono essere utilizzate come limiti massimi. In caso di
+errore viene restituito invece un codice che assume gli stessi valori
+illustrati in tab.~\ref{tab:addrinfo_error_code}.
A questo punto possiamo fornire degli esempi di utilizzo della nuova
interfaccia, adottandola per le precedenti implementazioni del client e del
connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
modifica il comportamento delle funzioni \func{close} e \func{shutdown}.
L'opzione richiede che l'argomento \param{optval} sia una struttura di tipo
- \struct{linger}, definita in \texttt{sys/socket.h} ed illustrata in
+ \struct{linger}, definita in \headfile{sys/socket.h} ed illustrata in
fig.~\ref{fig:sock_linger_struct}. Maggiori dettagli sul suo funzionamento
sono forniti in sez.~\ref{sec:sock_options_main}.
livello da utilizzare è \const{SOL\_IP} (o l'equivalente \const{IPPROTO\_IP});
si è riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_iplevel}.
Le costanti indicanti le opzioni e tutte le altre costanti ad esse collegate
-sono definite in \file{netinet/ip.h}, ed accessibili includendo detto file.
+sono definite in \headfile{netinet/ip.h}, ed accessibili includendo detto
+file.
\begin{table}[!htb]
\centering
dove sono elencate le rispettive costanti da utilizzare come valore per
l'argomento \param{optname}. Dette costanti e tutte le altre costanti e
strutture collegate all'uso delle opzioni TCP sono definite in
-\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
- questo è il file usato dalle librerie; la definizione delle opzioni
- effettivamente supportate da Linux si trova nel file \texttt{linux/tcp.h},
- dal quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
+\headfile{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in
+ realtà questo è il file usato dalle librerie; la definizione delle opzioni
+ effettivamente supportate da Linux si trova nel file
+ \texttt{include/linux/tcp.h} dei sorgenti del kernel, dal quale si sono
+ estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
\begin{table}[!htb]
\centering
questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
\const{IPPROTO\_UDP}). Le costanti che identificano dette opzioni sono
-definite in \file{netinet/udp.h}, ed accessibili includendo detto
+definite in \headfile{netinet/udp.h}, ed accessibili includendo detto
file.\footnote{come per TCP, la definizione delle opzioni effettivamente
- supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
- quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_udplevel}.}
+ supportate dal kernel si trova in realtà nel file
+ \texttt{include/linux/udp.h}, dal quale si sono estratte le costanti di
+ tab.~\ref{tab:sock_opt_udplevel}.}
\begin{table}[!htb]
\centering
lo stesso nome.}
I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
-indirizzi, sono definiti dall'header \texttt{socket.h}. Un elenco delle
-famiglie di protocolli disponibili in Linux è riportato in
+indirizzi, sono definiti dall'\textit{header file} \headfile{socket.h}. Un
+elenco delle famiglie di protocolli disponibili in Linux è riportato in
tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
I tipi di dati che compongono la struttura sono stabiliti dallo standard
POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
rispettivi file di include in cui sono definiti; la struttura è invece
-definita nell'include file \file{sys/socket.h}.
+definita nell'include file \headfile{sys/socket.h}.
\begin{table}[!htb]
\centering
\multicolumn{1}{|c|}{\textbf{Header}} \\
\hline
\hline
- \type{int8\_t} & intero a 8 bit con segno & \file{sys/types.h}\\
- \type{uint8\_t} & intero a 8 bit senza segno & \file{sys/types.h}\\
- \type{int16\_t} & intero a 16 bit con segno & \file{sys/types.h}\\
- \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
- \type{int32\_t} & intero a 32 bit con segno & \file{sys/types.h}\\
- \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
+ \type{int8\_t} & intero a 8 bit con segno & \headfile{sys/types.h}\\
+ \type{uint8\_t} & intero a 8 bit senza segno & \headfile{sys/types.h}\\
+ \type{int16\_t} & intero a 16 bit con segno & \headfile{sys/types.h}\\
+ \type{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\
+ \type{int32\_t} & intero a 32 bit con segno & \headfile{sys/types.h}\\
+ \type{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\
\hline
- \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
+ \type{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\
\type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
- un socket& \file{sys/socket.h}\\
+ un socket& \headfile{sys/socket.h}\\
\hline
\type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
- \file{netinet/in.h}\\
+ \headfile{netinet/in.h}\\
\type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
- \file{netinet/in.h}\\
+ \headfile{netinet/in.h}\\
\hline
\end{tabular}
\caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
attraverso internet; la struttura per gli indirizzi per un socket internet (se
si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
-\file{netinet/in.h} ed ha la forma mostrata in
+\headfile{netinet/in.h} ed ha la forma mostrata in
fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
\begin{figure}[!htb]
Il membro \var{sin\_addr} contiene un indirizzo internet, e viene acceduto sia
come struttura (un resto di una implementazione precedente in cui questa era
una \direct{union} usata per accedere alle diverse classi di indirizzi) che
-direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
-costanti che identificano alcuni indirizzi speciali, riportati in
+direttamente come intero. In \headfile{netinet/in.h} vengono definite anche
+alcune costanti che identificano alcuni indirizzi speciali, riportati in
tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
sostanzialmente identici ai precedenti; la parte in cui si trovano
praticamente tutte le differenze fra i due socket è quella della struttura
-degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
-in fig.~\ref{fig:sock_sa_ipv6_struct}.
+degli indirizzi; la sua definizione, presa da \headfile{netinet/in.h}, è
+riportata in fig.~\ref{fig:sock_sa_ipv6_struct}.
\begin{figure}[!htb]
\footnotesize \centering
\includestruct{listati/sockaddr_un.h}
\end{minipage}
\caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
- locali (detti anche \textit{unix domain}) definita in \file{sys/un.h}.}
+ locali (detti anche \textit{unix domain}) definita in
+ \headfile{sys/un.h}.}
\label{fig:sock_sa_local_struct}
\end{figure}
Gli indirizzi AppleTalk devono essere specificati tramite una struttura
\struct{sockaddr\_atalk}, la cui definizione è riportata in
fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
-il file \file{netatalk/at.h}.
+il file \headfile{netatalk/at.h}.
\begin{figure}[!htb]
\footnotesize \centering
questo crea una ambiguità che non è sempre possibile risolvere in maniera
chiara; in generale quello che succede è che quando i limiti del sistema sono
fissi essi vengono definiti come macro di preprocessore nel file
-\file{limits.h}, se invece possono variare, il loro valore sarà ottenibile
+\headfile{limits.h}, se invece possono variare, il loro valore sarà ottenibile
tramite la funzione \func{sysconf} (che esamineremo in
sez.~\ref{sec:sys_sysconf}).
Lo standard ANSI C definisce dei limiti che sono tutti fissi, pertanto questo
saranno sempre disponibili al momento della compilazione. Un elenco, ripreso
-da \file{limits.h}, è riportato in tab.~\ref{tab:sys_ansic_macro}. Come si può
-vedere per la maggior parte questi limiti attengono alle dimensioni dei dati
-interi, che sono in genere fissati dall'architettura hardware (le analoghe
-informazioni per i dati in virgola mobile sono definite a parte, ed
-accessibili includendo \file{float.h}). Lo standard prevede anche un'altra
+da \headfile{limits.h}, è riportato in tab.~\ref{tab:sys_ansic_macro}. Come si
+può vedere per la maggior parte questi limiti attengono alle dimensioni dei
+dati interi, che sono in genere fissati dall'architettura hardware (le
+analoghe informazioni per i dati in virgola mobile sono definite a parte, ed
+accessibili includendo \headfile{float.h}). Lo standard prevede anche un'altra
costante, \const{FOPEN\_MAX}, che può non essere fissa e che pertanto non è
-definita in \file{limits.h}; essa deve essere definita in \file{stdio.h} ed
-avere un valore minimo di 8.
+definita in \headfile{limits.h}; essa deve essere definita in
+\headfile{stdio.h} ed avere un valore minimo di 8.
\begin{table}[htb]
\centering
\const{ULONG\_MAX}& 4294967295 & Massimo di \ctyp{unsigned long}.\\
\hline
\end{tabular}
- \caption{Costanti definite in \file{limits.h} in conformità allo standard
+ \caption{Costanti definite in \headfile{limits.h} in conformità allo standard
ANSI C.}
\label{tab:sys_ansic_macro}
\end{table}
Massimo di \ctyp{unsigned long long}.\\
\hline
\end{tabular}
- \caption{Macro definite in \file{limits.h} in conformità allo standard
+ \caption{Macro definite in \headfile{limits.h} in conformità allo standard
ISO C90.}
\label{tab:sys_isoc90_macro}
\end{table}
\label{tab:sys_generic_macro}
\end{table}
-Lo standard dice che queste macro devono essere definite in \file{limits.h}
-quando i valori a cui fanno riferimento sono fissi, e altrimenti devono essere
-lasciate indefinite, ed i loro valori dei limiti devono essere accessibili
-solo attraverso \func{sysconf}. In realtà queste vengono sempre definite ad
-un valore generico. Si tenga presente poi che alcuni di questi limiti possono
-assumere valori molto elevati (come \const{CHILD\_MAX}), e non è pertanto il
-caso di utilizzarli per allocare staticamente della memoria.
+Lo standard dice che queste macro devono essere definite in
+\headfile{limits.h} quando i valori a cui fanno riferimento sono fissi, e
+altrimenti devono essere lasciate indefinite, ed i loro valori dei limiti
+devono essere accessibili solo attraverso \func{sysconf}. In realtà queste
+vengono sempre definite ad un valore generico. Si tenga presente poi che
+alcuni di questi limiti possono assumere valori molto elevati (come
+\const{CHILD\_MAX}), e non è pertanto il caso di utilizzarli per allocare
+staticamente della memoria.
A complicare la faccenda si aggiunge il fatto che POSIX.1 prevede una serie di
altre costanti (il cui nome inizia sempre con \code{\_POSIX\_}) che
199009L).\\
\hline
\end{tabular}
- \caption{Alcune macro definite in \file{limits.h} in conformità allo standard
- POSIX.1.}
+ \caption{Alcune macro definite in \headfile{limits.h} in conformità allo
+ standard POSIX.1.}
\label{tab:sys_posix1_other}
\end{table}
tab.~\ref{tab:sys_posix1_file}), che devono essere obbligatoriamente definiti,
lo standard POSIX.1 ne prevede parecchi altri. La lista completa si trova
dall'header file \file{bits/posix1\_lim.h} (da non usare mai direttamente, è
-incluso automaticamente all'interno di \file{limits.h}). Di questi vale la
+incluso automaticamente all'interno di \headfile{limits.h}). Di questi vale la
pena menzionare alcune macro di uso comune, (riportate in
tab.~\ref{tab:sys_posix1_other}), che non indicano un valore specifico, ma
denotano la presenza di alcune funzionalità nel sistema (come il supporto del
\label{tab:sys_posix1_file}
\end{table}
-Tutti questi limiti sono definiti in \file{limits.h}; come nel caso precedente
-il loro uso è di scarsa utilità in quanto ampiamente superati in tutte le
-implementazioni moderne.
+Tutti questi limiti sono definiti in \headfile{limits.h}; come nel caso
+precedente il loro uso è di scarsa utilità in quanto ampiamente superati in
+tutte le implementazioni moderne.
\subsection{La funzione \func{pathconf}}
La funzione, che viene usata dal comando \cmd{uname}, restituisce le
informazioni richieste nella struttura \param{info}; anche questa struttura è
-definita in \file{sys/utsname.h}, secondo quanto mostrato in
+definita in \headfile{sys/utsname.h}, secondo quanto mostrato in
fig.~\ref{fig:sys_utsname}, e le informazioni memorizzate nei suoi membri
indicano rispettivamente:
\begin{itemize*}
I parametri a cui la funzione permettere di accedere sono organizzati in
maniera gerarchica all'interno di un albero;\footnote{si tenga presente che
- includendo solo \file{unistd.h}, saranno definiti solo i parametri generici;
- dato che ce ne sono molti specifici dell'implementazione, nel caso di Linux
- occorrerà includere anche i file \file{linux/unistd.h} e
+ includendo solo \headfile{unistd.h}, saranno definiti solo i parametri
+ generici; dato che ce ne sono molti specifici dell'implementazione, nel caso
+ di Linux occorrerà includere anche i file \file{linux/unistd.h} e
\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 \itindex{pathname} \textit{pathname} (da cui l'uso
valore letto restituito dalla funzione è quello precedente alla scrittura.
I parametri accessibili attraverso questa funzione sono moltissimi, e possono
-essere trovati in \file{sysctl.h}, essi inoltre dipendono anche dallo stato
-corrente del kernel (ad esempio dai moduli che sono stati caricati nel
+essere trovati in \headfile{sysctl.h}, essi inoltre dipendono anche dallo
+stato corrente del kernel (ad esempio dai moduli che sono stati caricati nel
sistema) e in genere i loro nomi possono variare da una versione di kernel
all'altra; per questo è sempre il caso di evitare l'uso di \func{sysctl}
quando esistono modalità alternative per ottenere le stesse informazioni.
utenti (che nelle versioni più recenti possono essere 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 \file{pwd.h}) è
-riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente
-illustrato il significato dei vari campi.
+tipo \struct{passwd} la cui definizione (anch'essa eseguita in
+\headfile{pwd.h}) è riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure
+brevemente illustrato il significato dei vari campi.
\begin{figure}[!htb]
\footnotesize
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 è \file{/var/run/utmp}. Il nome di questo file, 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
-\file{paths.h}, in particolare quelle che ci interessano sono:
+il default che è \sysfile{/var/run/utmp}. Il nome di questo file, 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 \headfile{paths.h}, in particolare quelle che ci interessano sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{\_PATH\_UTMP}] specifica il file che contiene il registro per gli
utenti correntemente collegati; questo è il valore che viene usato se non si
l'archivio storico degli utenti collegati.
\end{basedescript}
che nel caso di Linux hanno un valore corrispondente ai file
-\file{/var/run/utmp} e \file{/var/log/wtmp} citati in precedenza.
+\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},
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
-\file{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}.
+\headfile{sys/resource.h}) è riportata in fig.~\ref{fig:sys_rusage_struct}.
\begin{figure}[!htb]
\footnotesize
\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}
- \item[\errcode{EACCESS}] non si hanno i permessi per accedere a
+ \item[\errcode{EACCES}] non si hanno i permessi per accedere a
\param{pathname}.
\item[\errcode{EPERM}] il processo non ha privilegi sufficienti ad
abilitare il \textit{BSD accounting}.
\item[\errcode{ENOSYS}] il kernel non supporta il \textit{BSD accounting}.
- \item[\errcode{EUSER}] non sono disponibili nel kernel strutture per il
+ \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},
\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_sysconf}). Il vecchio
- simbolo \const{CLK\_TCK} definito in \file{time.h} è ormai considerato
+ simbolo \const{CLK\_TCK} definito in \headfile{time.h} è ormai considerato
obsoleto.
\end{basedescript}
\end{prototype}
La funzione richiede una struttura di tipo \struct{timex}, la cui definizione,
-così come effettuata in \file{sys/timex.h}, è riportata in
-fig.~\ref{fig:sys_timex_struct}. L'azione della funzione dipende dal valore del
-campo \var{mode}, che specifica quale parametro dell'orologio di sistema,
+così come effettuata in \headfile{sys/timex.h}, è riportata in
+fig.~\ref{fig:sys_timex_struct}. L'azione della funzione dipende dal valore
+del campo \var{mode}, che specifica quale parametro dell'orologio di sistema,
specificato in un opportuno 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
locale, compresa l'eventuale ora legale. Questo viene fatto attraverso le tre
\index{variabili!globali} variabili globali mostrate in
fig.~\ref{fig:sys_tzname}, cui si accede quando si include
-\file{time.h}. Queste variabili vengono impostate quando si chiama una delle
-precedenti funzioni di conversione, oppure invocando direttamente la funzione
-\funcd{tzset}, il cui prototipo è:
+\headfile{time.h}. Queste variabili vengono impostate quando si chiama una
+delle precedenti funzioni di conversione, oppure invocando direttamente la
+funzione \funcd{tzset}, il cui prototipo è:
\begin{prototype}{sys/timex.h}
{void tzset(void)}
\bodydesc{La funzione non ritorna niente e non dà errori.}
\end{prototype}
-La funzione inizializza le variabili di fig.~\ref{fig:sys_tzname} a partire dal
-valore della variabile di ambiente \const{TZ}, se quest'ultima non è definita
-verrà usato il file \conffile{/etc/localtime}.
+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 \conffile{/etc/localtime}.
\begin{figure}[!htb]
\footnotesize
\textit{thread}) ma lo standard ISO C consente anche di definire \var{errno}
come un \textit{modifiable lvalue}, quindi si può anche usare una macro, e
questo è infatti il modo usato da Linux per renderla locale ai singoli
- \itindex{thread} \textit{thread}.} definita nell'header \file{errno.h}; la
-variabile è in genere definita come \direct{volatile} dato che può essere
+ \itindex{thread} \textit{thread}.} definita nell'header \headfile{errno.h};
+la variabile è in genere definita come \direct{volatile} dato che può essere
cambiata in modo asincrono da un segnale (si veda sez.~\ref{sec:sig_sigchld}
per un esempio, ricordando quanto trattato in sez.~\ref{sec:proc_race_cond}),
ma dato che un gestore di segnale scritto bene salva e ripristina il valore
normale.
I valori che può assumere \var{errno} sono riportati in app.~\ref{cha:errors},
-nell'header \file{errno.h} sono anche definiti i nomi simbolici per le
+nell'header \headfile{errno.h} sono anche definiti i nomi simbolici per le
costanti numeriche che identificano i vari errori; essi iniziano tutti per
-\val{E} e si possono considerare come nomi riservati. In seguito faremo
-sempre riferimento a tali valori, quando descriveremo i possibili errori
-restituiti dalle funzioni. Il programma di esempio \cmd{errcode} stampa il
-codice relativo ad un valore numerico con l'opzione \cmd{-l}.
+\val{E} e si possono considerare come nomi riservati. In seguito faremo sempre
+riferimento a tali valori, quando descriveremo i possibili errori restituiti
+dalle funzioni. Il programma di esempio \cmd{errcode} stampa il codice
+relativo ad un valore numerico con l'opzione \cmd{-l}.
Il valore di \var{errno} viene sempre impostato a zero all'avvio di un
programma, gran parte delle funzioni di libreria impostano \var{errno} ad un
In generale \func{strerror} viene usata passando \var{errno} come argomento,
ed il valore di quest'ultima non verrà modificato. La funzione inoltre tiene
-conto del valore della variabile di ambiente \val{LC\_MESSAGES} per usare le
-appropriate traduzioni dei messaggi d'errore nella localizzazione presente.
+conto del valore della variabile di ambiente \envvar{LC\_MESSAGES} per usare
+le appropriate traduzioni dei messaggi d'errore nella localizzazione presente.
La funzione utilizza una stringa statica che non deve essere modificata dal
programma; essa è utilizzabile solo fino ad una chiamata successiva a
non \index{funzioni!rientranti} rientrante, per cui nel caso si usino i
\itindex{thread} \textit{thread} le librerie forniscono\footnote{questa
funzione è la versione prevista dalle \acr{glibc}, ed effettivamente
- definita in \file{string.h}, ne esiste una analoga nello standard SUSv3
+ definita in \headfile{string.h}, ne esiste una analoga nello standard SUSv3
(quella riportata dalla pagina di manuale), che restituisce \code{int} al
posto di \code{char *}, e che tronca la stringa restituita a
\param{size}.} una apposita versione \index{funzioni!rientranti} rientrante
Il messaggio può essere riportato anche usando le due
\index{variabili!globali} variabili globali:
\includecodesnip{listati/errlist.c}
-dichiarate in \file{errno.h}. La prima contiene i puntatori alle stringhe di
-errore indicizzati da \var{errno}; la seconda esprime il valore più alto per
-un codice di errore, l'utilizzo di questa stringa è sostanzialmente
+dichiarate in \headfile{errno.h}. La prima contiene i puntatori alle stringhe
+di errore indicizzati da \var{errno}; la seconda esprime il valore più alto
+per un codice di errore, l'utilizzo di questa stringa è sostanzialmente
equivalente a quello di \func{strerror}.
\begin{figure}[!htbp]
% 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 SC
+% LocalWords: dall'header posix lim nell'header glibc run unistd name errno
% 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: domainname sysctl BSD nlen void oldval size oldlenp newval EPERM
-% LocalWords: newlen ENOTDIR EINVAL ENOMEM linux l'array oldvalue paging stack
+% 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 superblock point EACCES NODEV ENXIO major xC
+% LocalWords: device EBUSY only EACCES NODEV ENXIO major
% 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: line libc XPG utmpx getutxent getutxid getutxline pututxline who
% LocalWords: setutxent endutxent wmtp updwtmp logwtmp wtmp host rusage utime
% LocalWords: minflt majflt nswap fault swap timeval wait getrusage usage SELF
-% LocalWords: CHILDREN current limit soft RLIMIT Address brk mremap mmap dump
+% LocalWords: CHILDREN current limit soft RLIMIT address brk mremap mmap dump
% 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: phys pages avphys NPROCESSORS CONF ONLN getloadavg stdlib double
-% LocalWords: loadavg nelem scheduler CONFIG ACCT acct filename EACCESS EUSER
+% LocalWords: loadavg nelem scheduler CONFIG ACCT acct filename EUSER
% 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 dell' cutime cstime waitpid gettimeofday settimeofday timex
-% LocalWords: timespec adjtime olddelta adjtimex David Mills nell' RFC NTP ntp
+% LocalWords: tms cutime cstime waitpid gettimeofday settimeofday timex
+% LocalWords: timespec adjtime olddelta adjtimex David Mills RFC NTP ntp
% 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
che solo l'amministratore possa allocare queste porte per far partire i
relativi servizi.
-Le \textsl{glibc} definiscono (in \texttt{netinet/in.h})
+Le \textsl{glibc} definiscono in \headfile{netinet/in.h}
\const{IPPORT\_RESERVED} e \const{IPPORT\_USERRESERVED}, in cui la prima (che
vale 1024) indica il limite superiore delle porte riservate, e la seconda (che
vale 5000) il limite inferiore delle porte a disposizione degli utenti. La
associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
\cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
-definito in \file{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
+definito in \headfile{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
esterna non sono specificati; in questo caso la \textit{socket pair} associata
con una struttura, perché il linguaggio C non consente l'uso di una struttura
costante come operando a destra in una assegnazione.
-Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
+Per questo motivo nell'header \headfile{netinet/in.h} è definita una variabile
\macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
projects / gapil.git / commitdiff