La prima modalità di \textit{file locking} che è stata implementata nei
sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
- come al \textit{record locking}, dizione utilizzata anche dal manuale delle
+ come al \textit{record locking}, dizione utilizzata anche dal manuale della
\acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
mentre questo nome viene usato da Stevens per riferirsi al \textit{file
tutti i sistemi che supportano i socket, compreso le varianti di System V ed
inserita in POSIX.1-2001; il suo prototipo è:\footnote{l'header
\texttt{sys/select.h} è stato introdotto con POSIX.1-2001, è ed presente con
- le \acr{glibc} a partire dalla versione 2.0, in precedenza, con le
- \acr{libc4} e le \acr{libc5}, occorreva includere \texttt{sys/time.h},
+ la \acr{glibc} a partire dalla versione 2.0, in precedenza, con le
+ \acr{libc4} e \acr{libc5}, occorreva includere \texttt{sys/time.h},
\texttt{sys/types.h} e \texttt{unistd.h}.}
\begin{funcproto}{
ricalcolano \param{timeout} tutte le volte. In genere questa caratteristica è
disponibile nei sistemi che derivano da System V e non è disponibile per
quelli che derivano da BSD; lo standard POSIX.1-2001 non permette questo
-comportamento e per questo motivo le \acr{glibc} nascondono il comportamento
+comportamento e per questo motivo la \acr{glibc} nasconde il comportamento
passando alla \textit{system call} una copia dell'argomento \param{timeout}.
Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
vengano dichiarate nell'header \headfiled{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 \headfile{sys/select.h}, compaiono in Linux a partire dalle
+ l'header \headfile{sys/select.h}, compaiono in Linux a partire dalla
\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},
+ la \acr{glibc} 2.0 contiene 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
struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timespec_struct}) per
indicare con maggiore precisione il timeout e non ne aggiorna il valore in
caso di interruzione. In realtà anche in questo caso la \textit{system call}
-di Linux aggiorna il valore al tempo rimanente, ma la funzione fornita dalle
+di Linux aggiorna il valore al tempo rimanente, ma la funzione fornita dalla
\acr{glibc} modifica questo comportamento passando alla \textit{system call}
una variabile locale, in modo da mantenere l'aderenza allo standard POSIX che
richiede che il valore di \param{timeout} non sia modificato.
\param{sigmask} permette di riabilitare la ricezione il segnale
contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
kernel 2.6.16, non era presente la relativa \textit{system call}, e la
- funzione era implementata nelle \acr{glibc} attraverso \func{select} (vedi
+ funzione era implementata nella \acr{glibc} attraverso \func{select} (vedi
\texttt{man select\_tut}) per cui la possibilità di \textit{race condition}
permaneva; in tale situazione si può ricorrere ad una soluzione alternativa,
chiamata \itindex{self-pipe~trick} \textit{self-pipe trick}, che consiste
risultati illustrati in precedenza. Come nel caso di \func{pselect} la
\textit{system call} che implementa \func{ppoll} restituisce, se la funzione
viene interrotta da un segnale, il tempo mancante in \param{timeout}, e come
-per \func{pselect} la funzione di libreria fornita dalle \acr{glibc} maschera
+per \func{pselect} la funzione di libreria fornita dalla \acr{glibc} maschera
questo comportamento non modificando mai il valore di \param{timeout} anche se
in questo caso non esiste nessuno standard che richieda questo comportamento.
servizio è chiamata \textit{epoll},\footnote{l'interfaccia è stata creata da
Davide Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44,
ma la sua forma definitiva è stata raggiunta nel kernel 2.5.66, il supporto
- è stato aggiunto nelle \acr{glibc} a partire dalla versione 2.3.2.} anche se
+ è stato aggiunto nella \acr{glibc} a partire dalla versione 2.3.2.} anche se
sono state in discussione altre interfacce con le quali effettuare lo stesso
tipo di operazioni; \textit{epoll} è in grado di operare sia in modalità
\textit{level triggered} che \textit{edge triggered}.
La funzione di sistema che permette di abilitare la ricezione dei segnali
tramite file descriptor è \funcd{signalfd},\footnote{in realtà quella
- riportata è l'interfaccia alla funzione fornita dalle \acr{glibc}, esistono
+ riportata è l'interfaccia alla funzione fornita dalla \acr{glibc}, esistono
infatti due versioni diverse della \textit{system call}; una prima versione,
- \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
+ \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con la
\acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
- che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
+ che viene sempre usata a partire dalla \acr{glibc} 2.9, che prende un
argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
- maschera dei segnali, il cui valore viene impostato automaticamente dalle
+ maschera dei segnali, il cui valore viene impostato automaticamente dalla
\acr{glibc}.} il cui prototipo è:
\begin{funcproto}{
interfaccia è stata introdotta in forma considerata difettosa con il kernel
2.6.22, per cui è stata immediatamente tolta nel successivo 2.6.23 e
reintrodotta in una forma considerata adeguata nel kernel 2.6.25, il
- supporto nelle \acr{glibc} è stato introdotto a partire dalla versione
+ supporto nella \acr{glibc} è stato introdotto a partire dalla versione
2.8.6, la versione del kernel 2.6.22, presente solo su questo kernel, non è
supportata e non deve essere usata.} La prima funzione di sistema prevista,
quella che consente di creare un timer, è \funcd{timerfd\_create}, il cui
In generale questa interfaccia è completamente astratta e può essere
implementata sia direttamente nel kernel che in \textit{user space} attraverso
l'uso di \textit{thread}. Per le versioni del kernel meno recenti esiste una
-implementazione di questa interfaccia fornita completamente delle \acr{glibc}
+implementazione di questa interfaccia fornita completamente dalla \acr{glibc}
a partire dalla versione 2.1, che è realizzata completamente in \textit{user
space}, ed è accessibile linkando i programmi con la libreria
\file{librt}. A partire dalla versione 2.5.32 è stato introdotto nel kernel
con \const{MAP\_PRIVATE}.\\
\const{MAP\_STACK} & Al momento è ignorato, è stato fornito (dal kernel
2.6.27) a supporto della implementazione dei
- thread nelle \acr{glibc}, per allocare memoria in
- uno spazio utilizzabile come \textit{stack} per le
- architetture hardware che richiedono un
- trattamento speciale di quest'ultimo.\\
+ \textit{thread} nella \acr{glibc}, per allocare
+ memoria in uno spazio utilizzabile come
+ \textit{stack} per le architetture hardware che
+ richiedono un trattamento speciale di
+ quest'ultimo.\\
\constd{MAP\_UNINITIALIZED}& Specifico per i sistemi embedded ed
utilizzabile dal kernel 2.6.33 solo se è stata
abilitata in fase di compilazione dello stesso
L'argomento \param{advice} invece può assumere solo i valori indicati in
tab.~\ref{tab:posix_madvise_advice_values}, che riflettono gli analoghi di
\func{madvise}, con lo stesso effetto per tutti tranne
-\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalle \acr{glibc} 2.6
+\const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalla \acr{glibc} 2.6
\const{POSIX\_MADV\_DONTNEED} viene ignorato, in quanto l'uso del
corrispondente \const{MADV\_DONTNEED} di \func{madvise} ha, per la semantica
imperativa, l'effetto immediato di far liberare le pagine da parte del kernel,
\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
sez.~\ref{sec:sys_limits}).
-Nel caso di Linux il limite di sistema è di 1024, però se si usano le
-\acr{glibc} queste forniscono un \textit{wrapper} per le \textit{system call}
+Nel caso di Linux il limite di sistema è di 1024, però se si usa la
+\acr{glibc} essa fornisce un \textit{wrapper} per le \textit{system call}
che si accorge se una operazione supererà il precedente limite, in tal caso i
dati verranno letti o scritti con le usuali \func{read} e \func{write} usando
-un buffer di dimensioni sufficienti appositamente allocato e sufficiente a
+un buffer di dimensioni sufficienti appositamente allocato in grado di
contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
fra due file descriptor è \func{sendfile}.\footnote{la funzione è stata
- introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
+ introdotta con i kernel della serie 2.2, e disponibile dalla \acr{glibc}
2.1.} La funzione è presente in diverse versioni di Unix (la si ritrova ad
esempio in FreeBSD, HPUX ed altri Unix) ma non è presente né in POSIX.1-2001
né in altri standard (pertanto si eviti di utilizzarla se si devono scrivere
che l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
\textit{sparse file} (vedi sez.~\ref{sec:file_lseek}) senza una effettiva
allocazione dello spazio disco.} In realtà questa è la modalità con cui la
-funzione veniva realizzata nella prima versione fornita dalle \acr{glibc}, per
+funzione veniva realizzata nella prima versione fornita dalla \acr{glibc}, per
cui la funzione costituiva in sostanza soltanto una standardizzazione delle
modalità di esecuzione di questo tipo di allocazioni.
stato introdotto solo a partire dal kernel 2.6.25.} che consente di
realizzare direttamente all'interno del kernel l'allocazione dello spazio
disco così da poter realizzare una versione di \func{posix\_fallocate} con
-prestazioni molto più elevate; nelle \acr{glibc} la nuova \textit{system call}
+prestazioni molto più elevate; nella \acr{glibc} la nuova \textit{system call}
viene sfruttata per la realizzazione di \func{posix\_fallocate} a partire
dalla versione 2.10.
come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
in maniera indiretta con l'ausilio di \func{syscall}, vedi
sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
- loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
+ loff\_t offset, loff\_t len)}.} ma a partire dalla \acr{glibc} 2.10 è
stato fornito un supporto esplicito; il suo prototipo è:
\begin{funcproto}{
La funzione utilizza la funzione \func{unlink} per cancellare i file e la
funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per cancellare
-le directory.\footnote{questo vale usando la \acr{glibc}; nella libc4 e nella
- libc5 la funzione \func{remove} era un semplice alias alla funzione
- \func{unlink} e quindi non poteva essere usata per le directory.} Si tenga
-presente che per alcune implementazioni del protocollo NFS utilizzare questa
-funzione può comportare la scomparsa di file ancora in uso.
+le directory.\footnote{questo vale usando la \acr{glibc}; nella \acr{libc4} e
+ nella \acr{libc5} la funzione \func{remove} era un semplice alias alla
+ funzione \func{unlink} e quindi non poteva essere usata per le directory.}
+Si tenga presente che per alcune implementazioni del protocollo NFS utilizzare
+questa funzione può comportare la scomparsa di file ancora in uso.
Infine per cambiare nome ad un file o a una directory si usa la funzione di
sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
La funzione \func{read} è una delle \textit{system call} fondamentali,
esistenti fin dagli albori di Unix, ma nella seconda versione delle
\textit{Single Unix Specification}\footnote{questa funzione, e l'analoga
- \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nelle
+ \func{pwrite} sono state aggiunte nel kernel 2.1.60, il supporto nella
\acr{glibc}, compresa l'emulazione per i vecchi kernel che non hanno la
\textit{system call}, è stato aggiunto con la versione 2.1, in versioni
precedenti sia del kernel che delle librerie la funzione non è disponibile.}
Queste funzioni di libreria, insieme alle altre funzioni definite dallo
standard (che sono state implementate la prima volta da Ritchie nel 1976 e da
allora sono rimaste sostanzialmente immutate), vengono a costituire il nucleo
-delle \acr{glibc} per la gestione dei file.
+della \acr{glibc} per la gestione dei file.
Esamineremo in questa sezione le funzioni base dell'interfaccia degli
\textit{stream}, analoghe a quelle di sez.~\ref{sec:file_unix_interface} per i
distinzione non esiste e il valore viene accettato solo per
compatibilità, ma non ha alcun effetto.
-Le \acr{glibc} supportano alcune estensioni, queste devono essere sempre
+La \acr{glibc} supporta alcune estensioni, queste devono essere sempre
indicate dopo aver specificato il \param{mode} con uno dei valori di
tab.~\ref{tab:file_fopen_mode}. L'uso del carattere \texttt{x} serve per
evitare di sovrascrivere un file già esistente (è analoga all'uso dell'opzione
tutti i dati presenti nei buffer di uscita e scarta tutti i dati in ingresso;
se era stato allocato un buffer per lo \textit{stream} questo verrà
rilasciato. La funzione effettua lo scarico solo per i dati presenti nei
-buffer in \textit{user space} usati dalle \acr{glibc}; se si vuole essere
+buffer in \textit{user space} usati dalla \acr{glibc}; se si vuole essere
sicuri che il kernel forzi la scrittura su disco occorrerà effettuare una
\func{sync} (vedi sez.~\ref{sec:file_sync}).
-Linux supporta anche una altra funzione, \funcd{fcloseall}, come estensione
-GNU implementata dalle \acr{glibc}, accessibile avendo definito
+Linux supporta anche un'altra funzione, \funcd{fcloseall}, come estensione
+GNU implementata dalla \acr{glibc}, accessibile avendo definito
\macro{\_GNU\_SOURCE}, il suo prototipo è:
\begin{funcproto}{
funzioni. Nella maggior parte dei casi questo avviene con la restituzione del
valore intero (di tipo \ctyp{int}) \val{EOF} definito anch'esso nell'header
\headfile{stdlib.h}. La costante deve essere negativa perché in molte funzioni
-un valore positivo indica la quantità di dati scritti, le \acr{glibc} usano il
+un valore positivo indica la quantità di dati scritti, la \acr{glibc} usa il
valore $-1$, ma altre implementazioni possono avere valori diversi.
Dato che le funzioni dell'interfaccia degli \textit{stream} sono funzioni di
diverse del programma siano in grado di rileggere i dati, tenendo conto delle
eventuali differenze.
-Le \acr{glibc} definiscono infine due ulteriori funzioni per l'I/O binario,
+La \acr{glibc} definisce infine due ulteriori funzioni per l'I/O binario,
\funcd{fread\_unlocked} e \funcd{fwrite\_unlocked}, che evitano il lock
implicito dello \textit{stream} usato per dalla librerie per la gestione delle
applicazioni \textit{multi-thread} (si veda sez.~\ref{sec:file_stream_thread}
ritorno è sempre un intero; in caso di errore o fine del file il valore di
ritorno è \val{EOF}.
-Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
-provvedono come estensione, per ciascuna delle funzioni precedenti,
+Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} la \acr{glibc}
+provvede come estensione, per ciascuna delle funzioni precedenti,
un'ulteriore funzione, il cui nome è ottenuto aggiungendo un
\code{\_unlocked}, che esegue esattamente le stesse operazioni, evitando però
il lock implicito dello \textit{stream}.
caratteri massimo, terminatore della stringa, \textit{newline}) è espresso in
termini di caratteri estesi anziché di normali caratteri ASCII.
-Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea le
-\acr{glibc} supportano una serie di altre funzioni, estensioni di tutte quelle
+Come per l'I/O binario e quello a caratteri, anche per l'I/O di linea la
+\acr{glibc} supporta una serie di altre funzioni, estensioni di tutte quelle
illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono
esattamente le stesse operazioni delle loro equivalenti, evitando però il lock
implicito dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}). Come
complicazione ulteriore della logica del programma. Lo stesso dicasi quando si
deve gestire il caso di stringa che eccede le dimensioni del buffer.
-Per questo motivo le \acr{glibc} prevedono, come estensione GNU, due nuove
+Per questo motivo la \acr{glibc} prevede, 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
Dettagli ulteriori sulle varie opzioni di stampa e su tutte le casistiche
dettagliate dei vari formati possono essere trovati nella pagina di manuale di
-\func{printf} e nella documentazione delle \acr{glibc}.
+\func{printf} e nella documentazione della \acr{glibc}.
\begin{table}[htb]
\centering
\textit{stream}. Altre estensioni permettono di scrivere con caratteri
estesi. Anche queste funzioni, il cui nome è generato dalle precedenti
funzioni aggiungendo una \texttt{w} davanti a \texttt{print}, sono trattate in
-dettaglio nella documentazione delle \acr{glibc}.
+dettaglio nella documentazione della \acr{glibc}.
In corrispondenza alla famiglia di funzioni \func{printf} che si usano per
l'output formattato, l'input formattato viene eseguito con le funzioni della
qualunque di caratteri di separazione (che possono essere spazi, tabulatori,
virgole ecc.), mentre caratteri diversi richiedono una corrispondenza
esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e
-si trovano descritte in dettaglio nelle pagine di manuale e nel manuale delle
+si trovano descritte in dettaglio nelle pagine di manuale e nel manuale della
\acr{glibc}.
Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
In questo modo diventa possibile usare direttamente \func{fcntl} sul file
descriptor sottostante, ma anche se questo permette di accedere agli attributi
del file descriptor sottostante lo \textit{stream}, non ci dà nessuna
-informazione riguardo alle proprietà dello \textit{stream} medesimo. Le
-\acr{glibc} però supportano alcune estensioni derivate da Solaris, che
+informazione riguardo alle proprietà dello \textit{stream} medesimo. La
+\acr{glibc} però supporta alcune estensioni derivate da Solaris, che
permettono di ottenere informazioni utili relative allo \textit{stream}.
Ad esempio in certi casi può essere necessario sapere se un certo
specifichi la modalità non bufferizzata i valori di \param{buf} e \param{size}
vengono sempre ignorati.
-Oltre a \func{setvbuf} le \acr{glibc} definiscono altre tre funzioni per la
+Oltre a \func{setvbuf} la \acr{glibc} definisce altre tre funzioni per la
gestione della bufferizzazione di uno \textit{stream}: \funcd{setbuf},
\funcd{setbuffer} e \funcd{setlinebuf}, i rispettivi prototipi sono:
vecchie librerie BSD, pertanto non è il caso di usarle se non per la
portabilità su vecchi sistemi.
-Infine le \acr{glibc} provvedono le funzioni non standard, anche queste
+Infine la \acr{glibc} provvede le funzioni non standard, anche queste
originarie di Solaris, \funcd{\_\_flbf} e \funcd{\_\_fbufsize} che permettono
di leggere le proprietà di bufferizzazione di uno \textit{stream}; i cui
prototipi sono:
\textit{stream} aperti. Esistono però circostanze, ad esempio quando si vuole
essere sicuri che sia stato eseguito tutto l'output su terminale, in cui serve
poter effettuare lo scarico dei dati solo per gli \textit{stream} in modalità
-\textit{line buffered}. Per fare questo le \acr{glibc} supportano una
+\textit{line buffered}. Per fare questo la \acr{glibc} supporta una
estensione di Solaris, la funzione \funcd{\_flushlbf}, il cui prototipo è:
\begin{funcproto}{
Per questo motivo abbiamo visto come alle usuali funzioni di I/O non
formattato siano associate delle versioni \code{\_unlocked} (alcune previste
-dallo stesso standard POSIX, altre aggiunte come estensioni dalle \acr{glibc})
+dallo stesso standard POSIX, altre aggiunte come estensioni dalla \acr{glibc})
che possono essere usate quando il locking non serve\footnote{in certi casi
dette funzioni possono essere usate, visto che sono molto più efficienti,
anche in caso di necessità di locking, una volta che questo sia stato
La sostituzione di tutte le funzioni di I/O con le relative versioni
\code{\_unlocked} in un programma che non usa i \textit{thread} è però un
-lavoro abbastanza noioso. Per questo motivo le \acr{glibc} forniscono al
+lavoro abbastanza noioso. Per questo motivo la \acr{glibc} fornisce al
programmatore pigro un'altra via, anche questa mutuata da estensioni
introdotte in Solaris, da poter utilizzare per disabilitare in blocco il
locking degli \textit{stream}: l'uso della funzione \funcd{\_\_fsetlocking},
\itindbeg{file~descriptor}
In Linux le interfacce di programmazione per l'I/O su file due. La prima è
-l'interfaccia nativa del sistema, quella che il manuale delle \textsl{glibc}
+l'interfaccia nativa del sistema, quella che il manuale della \textsl{glibc}
chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
\textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
sistemi unix-like che fornisce un accesso non bufferizzato.
kernel negli Unix derivati da \textit{System V}, come strato di astrazione
per file e socket; in Linux questa interfaccia, che comunque ha avuto poco
successo, non esiste, per cui facendo riferimento agli \textit{stream}
- useremo il significato adottato dal manuale delle \acr{glibc}.} Essa
+ useremo il significato adottato dal manuale della \acr{glibc}.} Essa
fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
implementazione fatta nella \acr{glibc}. Questa è l'interfaccia specificata
dallo standard ANSI C e perciò si trova anche su tutti i sistemi non Unix. Gli
\textit{System V Interface Description}, che va sotto la denominazione di SVID
4.
-Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
+Linux e la \acr{glibc} implementano le principali funzionalità richieste dalle
specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
definito una di queste macro, l'effetto sarà quello di dare la precedenza
alle funzioni in forma BSD. Questa macro, essendo ricompresa in
\macro{\_DEFAULT\_SOURCE} che è definita di default, è stata deprecata a
- partire dalle \acr{glibc} 2.20.
+ partire dalla \acr{glibc} 2.20.
\item[\macrod{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
precedenza. Questa macro, essendo ricompresa in \macro{\_DEFAULT\_SOURCE}
- che è definita di default, è stata deprecata a partire dalle \acr{glibc}
+ che è definita di default, è stata deprecata a partire dalla \acr{glibc}
2.20.
\item[\macrod{\_DEFAULT\_SOURCE}] questa macro abilita le definizioni
meno di non aver richiesto delle definizioni più restrittive sia con altre
macro che con i flag del compilatore, nel qual caso abilita le funzioni che
altrimenti sarebbero disabilitate. Questa macro è stata introdotta a partire
- dalle \acr{glibc} 2.19 e consente di deprecare \macro{\_SVID\_SOURCE} e
+ dalla \acr{glibc} 2.19 e consente di deprecare \macro{\_SVID\_SOURCE} e
\macro{\_BSD\_SOURCE}.
\item[\macrod{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
le estensioni delle funzioni di creazione, accesso e modifica di file e
directory che risolvono i problemi di sicurezza insiti nell'uso di
\textit{pathname} relativi con programmi \textit{multi-thread} illustrate in
- sez.~\ref{sec:file_openat}. Dalle \acr{glibc} 2.10 questa macro viene
+ sez.~\ref{sec:file_openat}. Dalla \acr{glibc} 2.10 questa macro viene
definita implicitamente se si definisce \macro{\_POSIX\_C\_SOURCE} ad un
valore maggiore o uguale di ``\texttt{200809L}''.
funzioni sono anche previste nello standard POSIX.1c, ma ve ne sono altre
che sono disponibili soltanto su alcuni sistemi, o specifiche della
\acr{glibc}, e possono essere utilizzate una volta definita la macro. Oggi
- la macro è obsoleta, già dalle \acr{glibc} 2.3 le librerie erano già
- completamente rientranti e dalle \acr{glibc} 2.25 la macro è equivalente ad
+ la macro è obsoleta, già dalla \acr{glibc} 2.3 le funzioni erano già
+ completamente rientranti e dalla \acr{glibc} 2.25 la macro è equivalente ad
definire \macro{\_POSIX\_C\_SOURCE} con un valore di ``\texttt{199606L}''
mentre se una qualunque delle altre macro che richiede un valore di
conformità più alto è definita, la sua definizione non ha alcun effetto.
\end{figure}
Della funzione di sistema esiste una seconda versione, \funcd{pipe2},
-introdotta con il kernel 2.6.27 e le \acr{glibc} 2.9 e specifica di Linux
+introdotta con il kernel 2.6.27 e la \acr{glibc} 2.9 e specifica di Linux
(utilizzabile solo definendo la macro \macro{\_GNU\_SOURCE}), che consente di
impostare atomicamente le caratteristiche dei file descriptor restituiti, il
suo prototipo è:
\textit{pipe} creata, che sarà aperto in sola lettura (e quindi associato allo
\textit{standard output} del programma indicato) in caso si sia indicato
\code{r}, o in sola scrittura (e quindi associato allo \textit{standard
- input}) in caso di \code{w}. A partire dalla versione 2.9 delle \acr{glibc}
+ input}) in caso di \code{w}. A partire dalla versione 2.9 della \acr{glibc}
(questa è una estensione specifica di Linux) all'argomento \param{type} può
essere aggiunta la lettera ``\texttt{e}'' per impostare automaticamente il
flag di \textit{close-on-exec} sul file descriptor sottostante (si ricordi
\struct{semun}, la cui definizione, con i possibili valori che può assumere, è
riportata in fig.~\ref{fig:ipc_semun}.
-Nelle versioni più vecchie delle \acr{glibc} questa unione veniva definita in
+Nelle versioni più vecchie della \acr{glibc} questa unione veniva definita in
\file{sys/sem.h}, ma nelle versioni più recenti questo non avviene più in
quanto lo standard POSIX.1-2001 richiede che sia sempre definita a cura del
-chiamante. In questa seconda evenienza le \acr{glibc} definiscono però la
+chiamante. In questa seconda evenienza la \acr{glibc} definisce però la
macro \macrod{\_SEM\_SEMUN\_UNDEFINED} che può essere usata per controllare la
situazione.
Con lo standard POSIX.1-2001 è stata introdotta una variante di \func{semop}
che consente di specificare anche un tempo massimo di attesa. La nuova
-funzione di sistema, disponibile a partire dal kernel 2.4.22 e dalle
+funzione di sistema, disponibile a partire dal kernel 2.4.22 e dalla
\acr{glibc} 2.3.3, ed utilizzabile solo dopo aver definito la macro
\macro{\_GNU\_SOURCE}, è \funcd{semtimedop}, ed il suo prototipo è:
L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
- come il valore di ritorno della funzione; in Linux è stato così con le
- \acr{libc4} e le \acr{libc5}, con il passaggio alla \acr{glibc} il tipo di
+ come il valore di ritorno della funzione; in Linux è stato così con la
+ \acr{libc4} e la \acr{libc5}, con il passaggio alla \acr{glibc} il tipo di
\param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
ritorno un \ctyp{void *} seguendo POSIX.1-2001.} deve essere associato il
segmento, se il valore specificato è \val{NULL} è il sistema a scegliere
La funzione è analoga a \func{close},\footnote{su Linux, dove le code sono
implementate come file su un filesystem dedicato, è esattamente la stessa
funzione, per cui non esiste una \textit{system call} autonoma e la funzione
- viene rimappata su \func{close} dalle \acr{glibc}.} dopo la sua esecuzione
+ viene rimappata su \func{close} dalla \acr{glibc}.} dopo la sua esecuzione
il processo non sarà più in grado di usare il descrittore della coda, ma
quest'ultima continuerà ad esistere nel sistema e potrà essere acceduta con
un'altra chiamata a \func{mq\_open}. All'uscita di un processo tutte le code
prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
- prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
+ prototipo illustrato è quello utilizzato dalla \acr{glibc}, che segue le
\textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
\ctyp{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
usato un \texttt{unsigned int}; l'argomento \param{len} era \ctyp{int} nei
- vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5};
- infine l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.* nelle
- \acr{libc4} e nelle \acr{libc5}.} è:
+ vari BSD4.* e nella \acr{libc4}, ma \type{size\_t} nella \acr{libc5}; infine
+ l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.*, nella \acr{libc4} e
+ nella \acr{libc5}.} è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
La seconda funzione utilizzata nella comunicazione fra socket UDP è
\funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
-suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
- \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le
+suo prototipo\footnote{il prototipo è quello della \acr{glibc} che segue le
+ \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e la
\acr{libc5} usano un \ctyp{int} come valore di ritorno; per gli argomenti
\param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
- infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, le
- \acr{libc4} e le \acr{libc5}.} è:
+ infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, la
+ \acr{libc4} e la \acr{libc5}.} è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
Una forma alternativa per effettuare una terminazione esplicita di un
programma è quella di chiamare direttamente la \textit{system call}
\funcd{\_exit},\footnote{la stessa è definita anche come \funcd{\_Exit} in
- \headfile{stdlib.h}, inoltre a partire dalle \acr{glibc} 2.3 usando questa
+ \headfile{stdlib.h}, inoltre a partire dalla \acr{glibc} 2.3 usando questa
funzione viene invocata \func{exit\_group} che termina tutti i
\textit{thread} del processo e non solo quello corrente (fintanto che non si
usano i \textit{thread}\unavref{, vedi sez.~\ref{cha:threads},} questo non
deve prendere argomenti e non deve ritornare niente. In sostanza deve la
funzione di pulizia dovrà essere definita come \code{void function(void)}.
-Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
-\acr{glibc} includono per compatibilità con SunOS ma che non è detto sia
-definita su altri sistemi,\footnote{la funzione è disponibile dalle
+Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che la
+\acr{glibc} include per compatibilità con SunOS ma che non è detto sia
+definita su altri sistemi,\footnote{la funzione è disponibile dalla
\acr{glibc} 2.19 definendo la macro \macro{\_DEFAULT\_SOURCE}, mentre in
precedenza erano necessarie \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE};
non essendo prevista dallo standard POSIX è in generale preferibile evitarne
In genere si usano \func{malloc} e \func{calloc} per allocare dinamicamente
un'area di memoria.\footnote{queste funzioni presentano un comportamento
- diverso fra le \acr{glibc} e le \acr{uClib} quando il valore di \param{size}
+ diverso fra la \acr{glibc} e la \acr{uClib} quando il valore di \param{size}
è nullo. Nel primo caso viene comunque restituito un puntatore valido,
anche se non è chiaro a cosa esso possa fare riferimento, nel secondo caso
viene restituito \val{NULL}. Il comportamento è analogo con
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
- \headfile{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4}
+ \headfile{stdlib.h}, mentre sia la \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 e
-disponibile dalle \acr{glibc} 2.1.91; il suo prototipo è:
+disponibile dalla \acr{glibc} 2.1.91; il suo prototipo è:
\begin{funcproto}{
\fhead{stdlib.h}
allocata con \func{posix\_memalign} deve essere disallocata con \func{free},
che in questo caso però è quanto richiesto dallo standard.
-Dalla versione 2.16 delle \acr{glibc} è stata aggiunta anche la funzione
+Dalla versione 2.16 della \acr{glibc} è stata aggiunta anche la funzione
\funcd{aligned\_alloc}, prevista dallo standard C11 (e disponibile definendo
\const{\_ISOC11\_SOURCE}), il cui prototipo è:
vecchie \acr{libc4} e \acr{libc5}; nella \acr{glibc}, dalla versione 2.0
alla 2.1.1, veniva invece fatta una copia, seguendo il comportamento di
BSD4.4; dato che questo può dar luogo a perdite di memoria e non rispetta lo
- standard il comportamento è stato modificato a partire dalle 2.1.2,
+ standard il comportamento è stato modificato a partire dalla 2.1.2,
eliminando anche, sempre in conformità a SUSv2, l'attributo \direct{const}
dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
%\label{sec:proc_opt_extended}
%Oltre alla modalità ordinaria di gestione delle opzioni trattata in
-%sez.~\ref{sec:proc_opt_handling} le \acr{glibc} forniscono una modalità
+%sez.~\ref{sec:proc_opt_handling} la \acr{glibc} fornisce una modalità
%alternativa costituita dalle cosiddette \textit{long-options}, che consente di
%esprimere le opzioni in una forma più descrittiva che nel caso più generale è
%qualcosa del tipo di ``\texttt{-{}-option-name=parameter}''.
all'\ids{UID} reale o all'\ids{UID} salvato, ottenendo un errore di
\errcode{EPERM} negli altri casi.
-E' importante notare che la funzione può fallire con \errval{EAGAIN} anche
-quando viene invocata da un processo con privilegi di amministratore per
-cambiare il proprio l'\ids{UID} reale, sia per una temporanea indisponibilità
-di risorse del kernel, sia perché l'utente di cui si vuole assumere
-l'\ids{UID} andrebbe a superare un eventuale limite sul numero di processi (il
-limite \const{RLIMIT\_NPROC}, che tratteremo in
-sez.~\ref{sec:sys_resource_limit}),\footnote{non affronteremo qui l'altro caso
- di errore, che può avvenire solo quando si esegue la funzione all'interno di
- un diverso \textit{user namespace}, argomento su cui torneremo in
- sez.~\ref{sec:process_namespaces}.} pertanto occorre sempre verificare lo
-stato di uscita della funzione.
+E' importante notare che la funzione può fallire, con
+\errval{EAGAIN},\footnote{non affronteremo qui l'altro caso di errore, che può
+ avvenire solo quando si esegue la funzione all'interno di un diverso
+ \textit{user namespace}, argomento su cui torneremo in
+ sez.~\ref{sec:process_namespaces} ma la considerazione di controllare sempre
+ lo stato di uscita si applica allo stesso modo.} anche quando viene invocata
+da un processo con privilegi di amministratore per cambiare il proprio
+l'\ids{UID} reale, sia per una temporanea indisponibilità di risorse del
+kernel, sia perché l'utente di cui si vuole assumere l'\ids{UID} andrebbe a
+superare un eventuale limite sul numero di processi (il limite
+\const{RLIMIT\_NPROC}, che tratteremo in sez.~\ref{sec:sys_resource_limit}),
+pertanto occorre sempre verificare lo stato di uscita della funzione.
Non controllare questo tipo di errori perché si presume che la funzione abbia
sempre successo quando si hanno i privilegi di amministratore può avere
\fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
-caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}.
+ caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}
+ tranne \errval{EAGAIN}.
}
\end{funcproto}
\fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
-caso \var{errno} può assumere solo il valore \errcode{EPERM}.
+caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}.
}
\end{funcproto}
\func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
l'\ids{UID} salvato del processo corrente ai valori specificati
rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
-processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
+processi non privilegiati possono cambiare uno qualunque degli \ids{UID} solo
ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
quello salvato, l'amministratore può specificare i valori che vuole. Un valore
di $-1$ per un qualunque argomento lascia inalterato l'identificatore
\fdecl{int setfsgid(gid\_t fsgid)}
\fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
}
-{Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
- successo e quello corrente per un errore, in questo caso non viene però
- impostato nessun codice di errore in \var{errno}.}
+
+{Le funzioni restituiscono sia in caso di successo che di errore il valore
+ corrente dell'identificativo, e in caso di errore non viene impostato nessun
+ codice in \var{errno}.}
\end{funcproto}
Le due funzioni sono analoghe ed usano il valore passato come argomento per
altri utenti, se il valore specificato coincide con uno dei di quelli del
gruppo \textit{real}, \textit{effective} o \textit{saved}.
+Il problema di queste funzioni è che non restituiscono un codice di errore e
+non c'è modo di sapere (con una singola chiamata) di sapere se hanno avuto
+successo o meno, per verificarlo occorre eseguire una chiamata aggiuntiva
+passando come argomento $-1$ (un valore impossibile per un identificativo),
+così fallendo si può di ottenere il valore corrente e verificare se è
+cambiato.
\subsection{Le funzioni per la gestione dei gruppi associati a un processo}
\label{sec:proc_setgroups}
vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
-l'argomento \param{list} non viene modificato, ma si ottiene il numero di
-gruppi supplementari.
+l'argomento \param{list} non viene modificato, ma si ottiene dal valore di
+ritorno il numero di gruppi supplementari.
Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo
kernel provvedere a mettere in esecuzione un altro processo.
Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
-processo, in Linux un processo può trovarsi in uno degli stati riportati in
+processo; in Linux un processo può trovarsi in uno degli stati riportati in
tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
\textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
sia la sua priorità, un processo non potrà mai essere messo in esecuzione
\hline
\hline
\textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
- essere eseguito (cioè è in attesa che gli
+ essere eseguito (in attesa che gli
venga assegnata la CPU).\\
\textit{sleep} & \texttt{S} & Il processo è in attesa di un
risposta dal sistema, ma può essere
preoccupare nella programmazione. Come accennato in Linux i processi ordinari
hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti
i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
-\textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
- \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
-varia nel corso dell'esecuzione di un processo.
+\textsl{priorità dinamica}, quella che viene mostrata nella colonna
+\texttt{PR} del comando \texttt{top}, che è chiamata così proprio perché varia
+nel corso dell'esecuzione di un processo.
Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
dipende strettamente dalla versione di kernel; in particolare a partire
processo mettere in esecuzione avviene con un algoritmo molto più
complicato, che tiene conto anche della \textsl{interattività} del processo,
utilizzando diversi fattori, questa è una brutale semplificazione per
- rendere l'idea del funzionamento, per una trattazione più dettagliata, anche
- se non aggiornatissima, dei meccanismi di funzionamento dello
- \textit{scheduler} si legga il quarto capitolo di \cite{LinKernDev}.} Lo
-\textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi in
-stato \textit{runnable}, quello che ha il valore di priorità dinamica più
-basso.\footnote{con le priorità dinamiche il significato del valore numerico
- ad esse associato è infatti invertito, un valore più basso significa una
- priorità maggiore.} Il fatto che questo valore venga diminuito quando un
-processo non viene posto in esecuzione pur essendo pronto, significa che la
-priorità dei processi che non ottengono l'uso del processore viene
-progressivamente incrementata, così che anche questi alla fine hanno la
-possibilità di essere eseguiti.
+ rendere l'idea del funzionamento, per una trattazione più dettagliata dei
+ meccanismi di funzionamento dello \textit{scheduler}, anche se non
+ aggiornatissima, si legga il quarto capitolo di \cite{LinKernDev}.}
+
+Lo \textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi
+in stato \textit{runnable}, quello che ha il valore di priorità dinamica più
+basso; con le priorità dinamiche il significato del valore numerico ad esse
+associato è infatti invertito, un valore più basso significa una priorità
+maggiore. Il fatto che questo valore venga diminuito quando un processo non
+viene posto in esecuzione pur essendo pronto, significa che la priorità dei
+processi che non ottengono l'uso del processore viene progressivamente
+incrementata, così che anche questi alla fine hanno la possibilità di essere
+eseguiti.
Sia la dimensione della \textit{time-slice} che il valore di partenza della
priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
\end{errlist}}
\end{funcproto}
-La funzione permette, a seconda di quanto specificato
-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 \headfiled{sys/time.h}, questo non è più
-necessario con versioni recenti delle librerie, ma è comunque utile per
-portabilità.
+La funzione permette, a seconda di quanto specificato nell'argomento
+\param{which}, di leggere il valore di \textit{nice} o di un processo, o di un
+gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di un utente,
+indicati con l'argomento \param{who}. Nelle vecchie versioni può essere
+necessario includere anche \headfiled{sys/time.h}, questo non è più necessario
+con versioni recenti delle librerie, ma è comunque utile per portabilità.
I valori possibili per \param{which}, ed il tipo di valore che occorre usare
-in corrispondenza per \param{who} solo elencati nella legenda di
+in corrispondenza per \param{who}, solo elencati nella legenda di
tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un
valore nullo per \param{who} indica, a seconda della corrispondente
-indicazione usata per \param{which} il processo, il gruppo di processi o
+indicazione usata per \param{which}, il processo, il gruppo di processi o
l'utente correnti.
\begin{table}[htb]
In caso di una indicazione che faccia riferimento a più processi, la funzione
restituisce la priorità più alta (cioè il valore più basso) fra quelle dei
-processi corrispondenti. Come per \func{nice} $-1$ è un valore possibile
+processi corrispondenti. Come per \func{nice}, $-1$ è un possibile valore
corretto, per cui di nuovo per poter rilevare una condizione di errore è
necessario cancellare sempre \var{errno} prima della chiamata alla funzione e
quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa
specchietto di tab.~\ref{tab:proc_getpriority}.
In questo caso come valore di \param{prio} deve essere specificato il valore
-di \textit{nice} da assegnare, e non un incremento (positivo o negativo) come
-nel caso di \func{nice}, nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
-\const{PRIO\_MAX} ($19$). La funzione restituisce il valore di \textit{nice}
+di \textit{nice} da assegnare nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
+\const{PRIO\_MAX} ($19$), e non un incremento (positivo o negativo) come nel
+caso di \func{nice}. La funzione restituisce il valore di \textit{nice}
assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
anche in questo caso per rilevare un errore occorre sempre porre a zero
\var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel
2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte
nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata
-una priorità dinamica per i processi che non ricevono la CPU così che anche
+una priorità dinamica per i processi che non ricevono la CPU, così che anche
essi possano essere messi in esecuzione, un alto valore di \textit{nice}
corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce
comunque, per cui un processo a bassa priorità avrà davvero scarse possibilità
di essere eseguito in presenza di processi attivi a priorità più alta.
-
\subsection{Il meccanismo di \textit{scheduling real-time}}
\label{sec:proc_real_time}
Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
-le priorità assolute per permettere la gestione di processi real-time. In
-realtà nel caso di Linux non si tratta di un vero \textit{hard real-time}, in
-quanto in presenza di eventuali interrupt il kernel interrompe l'esecuzione di
-un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
- siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
- ottenere un sistema effettivamente \textit{hard real-time}. In tal caso
- infatti gli interrupt vengono intercettati dall'interfaccia
- \textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
- in modo da poterli controllare direttamente qualora ci sia la necessità di
- avere un processo con priorità più elevata di un \textit{interrupt
- handler}.} mentre con l'incorrere in un \textit{page fault} si possono
-avere ritardi non previsti. Se l'ultimo problema può essere aggirato
-attraverso l'uso delle funzioni di controllo della memoria virtuale (vedi
-sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
-ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
+le priorità assolute per permettere la gestione di processi
+\textit{real-time}. In realtà nel caso di Linux non si tratta di un vero
+\textit{hard real-time}, in quanto in presenza di eventuali interrupt il
+kernel interrompe l'esecuzione di un processo, qualsiasi sia la sua
+priorità,\footnote{questo a meno che non si siano installate le patch di
+ RTLinux, RTAI o Adeos, con i quali è possibile ottenere un sistema
+ effettivamente \textit{hard real-time}. In tal caso infatti gli interrupt
+ vengono intercettati dall'interfaccia \textit{real-time} (o nel caso di
+ Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
+ direttamente qualora ci sia la necessità di avere un processo con priorità
+ più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
+\textit{page fault} si possono avere ritardi non previsti. Se l'ultimo
+problema può essere aggirato attraverso l'uso delle funzioni di controllo
+della memoria virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo non è
+superabile e può comportare ritardi non prevedibili riguardo ai tempi di
+esecuzione di qualunque processo.
Nonostante questo, ed in particolare con una serie di miglioramenti che sono
stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
- relativo valore di \param{p} non è valido per la politica scelta.
+ valore di \param{p} non è valido per la politica scelta.
\item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
politica richiesta.
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \end{errlist}}
+ \end{errlist}}
\end{funcproto}
La funzione esegue l'impostazione per il processo specificato dall'argomento
-\param{pid}, un valore nullo di questo argomento esegue l'impostazione per il
+\param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
processo corrente. La politica di \textit{scheduling} è specificata
dall'argomento \param{policy} i cui possibili valori sono riportati in
tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
% TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta
% con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e
% http://lwn.net/Articles/575497/
+% vedi anche man 7 sched, man sched_setattr
Con le versioni più recenti del kernel sono state introdotte anche delle
varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
processi interattivi, dato che essi sono per la maggior parte del tempo in
attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come
indica il nome, per processi che usano molta CPU (come programmi di calcolo)
-che in questo modo sono leggermente sfavoriti rispetto ai processi interattivi
-che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore
-di \textit{nice}.
+che in questo modo, pur non perdendo il loro valore di \textit{nice}, sono
+leggermente sfavoriti rispetto ai processi interattivi che devono rispondere a
+dei dati in ingresso.
La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
si desidera siano eseguiti con la più bassa priorità possibile, ancora più
intervallo fra un massimo ed un minimo che nel caso di Linux sono
rispettivamente 1 e 99.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{0.5\textwidth}
\includestruct{listati/sched_param.c}
\end{errlist}}
\end{funcproto}
-Le funzioni ritornano rispettivamente i due valori della massima e minima
-priorità statica possano essere ottenuti per una delle politiche di
-\textit{scheduling} \textit{real-time} indicata dall'argomento \param{policy}.
+Le funzioni ritornano rispettivamente il valore massimo e minimo usabile per
+la priorità statica di una delle politiche di \textit{scheduling}
+\textit{real-time} indicata dall'argomento \param{policy}.
Si tenga presente che quando si imposta una politica di \textit{scheduling}
real-time per un processo o se ne cambia la priorità statica questo viene
automaticamente rimesso in coda alla lista, e la sua esecuzione continua
fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
-sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
-nel caso che esso sia stato interrotto da un processo a priorità più alta.
+sarà in coda alla lista); l'esecuzione viene ripresa subito solo nel caso che
+esso sia stato interrotto da un processo a priorità più alta.
Solo un processo con i privilegi di amministratore\footnote{più precisamente
con la capacità \const{CAP\_SYS\_NICE}, vedi
con la possibilità di essere rimessi in esecuzione entro breve tempo, con
l'introduzione del \textit{Completely Fair Scheduler} questo comportamento è
cambiato ed un processo che chiama la funzione viene inserito nella lista dei
-processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
+processi inattivi, con un tempo molto maggiore.\footnote{è comunque possibile
ripristinare un comportamento analogo al precedente scrivendo il valore 1
nel file \sysctlfiled{kernel/sched\_compat\_yield}.}
possibile legare automaticamente un gruppo di processi ad un singolo
processore.
-Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, l'uso di
+Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, utilizzare
questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che
provvede a mantenere al meglio l'affinità di processore. Esistono però
esigenze particolari, ad esempio quando un processo (o un gruppo di processi)
è utilizzato per un compito importante (ad esempio per applicazioni
\textit{real-time} o la cui risposta è critica) e si vuole la massima
-velocità, e con questa interfaccia diventa possibile selezionare gruppi di
+velocità; con questa interfaccia diventa possibile selezionare gruppi di
processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando
l'accesso a certe risorse (memoria o periferiche) può avere un costo diverso a
seconda del processore, come avviene nelle architetture NUMA
cui questo numero può non essere sufficiente, e per questo è stato creato
questo tipo opaco e una interfaccia di gestione che permette di usare a basso
livello un tipo di dato qualunque rendendosi indipendenti dal numero di bit e
-dalla loro disposizione. Per questo le funzioni richiedono anche che oltre
-all'insieme di processori si indichi anche la dimensione dello stesso con
-l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
-dinamica che vedremo a breve, ed è in genere sufficiente passare il valore
+dalla loro disposizione. Per questo le funzioni di libreria richiedono che
+oltre all'insieme di processori si indichi anche la dimensione dello stesso
+con l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
+dinamica che vedremo a breve, è in genere sufficiente passare il valore
\code{sizeof(cpu\_set\_t)}.
L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
valutato più volte. Questo significa ad esempio che non si può usare al suo
posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
-volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
+volte; l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
\textit{side effects}).\footnote{nel linguaggio C si
parla appunto di \textit{side effects} quando si usano istruzioni la cui
valutazione comporta effetti al di fuori dell'istruzione stessa, come il
\itindend{side~effects}
-Le CPU sono numerate da zero (che indica la prima disponibile) fino ad
-un numero massimo che dipende dalla architettura hardware. La costante
+Le CPU sono numerate da zero (che indica la prima disponibile) fino ad un
+numero massimo che dipende dall'architettura hardware. La costante
\constd{CPU\_SETSIZE} indica il numero massimo di processori che possono far
parte di un insieme (al momento vale sempre 1024), e costituisce un limite
-massimo al valore dell'argomento \param{cpu}.
-Dalla versione 2.6 della \acr{glibc} alle precedenti macro è stata aggiunta,
-per contare il numero di processori in un insieme, l'ulteriore:
+massimo al valore dell'argomento \param{cpu}. Dalla versione 2.6 della
+\acr{glibc} alle precedenti macro è stata aggiunta, per contare il numero di
+processori in un insieme, l'ulteriore:
{\centering
\vspace{3pt}
La versione illustrata è quella usata nella definizione di POSIX.1, in BSD
viene usata una funzione con questo nome, che però è identica a
-\func{setpgid}, che vedremo a breve, negli argomenti e negli effetti. Nelle
+\func{setpgid}, che vedremo a breve, negli argomenti e negli effetti. Nella
\acr{glibc} viene sempre usata sempre questa definizione, a meno di non
richiedere esplicitamente la compatibilità all'indietro con BSD, definendo la
macro \macro{\_BSD\_SOURCE} ed evitando di definire le macro che richiedono
In Linux buona parte di queste azioni possono venire eseguite invocando la
-funzione \funcd{daemon} (fornita dalle \acr{glibc}), introdotta per la prima
+funzione \funcd{daemon} (fornita dalla \acr{glibc}), introdotta per la prima
volta in BSD4.4; il suo prototipo è:
\begin{funcproto}{
amministrazione di sistema.\footnote{l'argomento è ad esempio coperto dal
capitolo 3.2.3 si \cite{AGL}.}
-Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
+La \acr{glibc} definisce una serie di funzioni standard con cui un processo
può accedere in maniera generica al servizio di \textit{syslog}, che però
funzionano solo localmente; se si vogliono inviare i messaggi ad un altro
sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
specificabile attraverso le costanti riportate in
tab.~\ref{tab:sess_syslog_priority}.
-Le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto diverse priorità
+La \acr{glibc}, seguendo POSIX.1-2001, prevede otto diverse priorità
ordinate da 0 a 7, in ordine di importanza decrescente; questo comporta che i
tre bit meno significativi dell'argomento \param{priority} sono occupati da
questo valore, mentre i restanti bit più significativi vengono usati per
Per la lettura dei messaggi del kernel e la gestione del relativo buffer
circolare esiste una apposita \textit{system call} chiamata anch'essa
\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 \code{SYS\_klog}.} il cui prototipo
+ un'altra funzione di libreria, in particolare nella \acr{glibc} essa viene
+ invocata tramite la funzione \funcd{klogctl},\footnote{nella \acr{libc4} e
+ nella \acr{libc5} la funzione invece era \code{SYS\_klog}.} il cui prototipo
è:
\begin{funcproto}{
chiamare \func{tcsetattr}.
Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
-validi; questi possono essere specificati direttamente (le \acr{glibc}
-prevedono che i valori siano indicati in bit per secondo), ma in generale
-altre versioni di librerie possono utilizzare dei valori diversi. Per questo
+validi; questi possono essere specificati direttamente (la \acr{glibc}
+prevede che i valori siano indicati in bit per secondo), ma in generale
+altre versioni di libreria possono utilizzare dei valori diversi. Per questo
POSIX.1 prevede una serie di costanti che però servono solo per specificare le
velocità tipiche delle linee seriali:
\begin{verbatim}
call lenta per ripeterne la chiamata qualora l'errore fosse questo.
Dimenticarsi di richiamare una \textit{system call} interrotta da un segnale è
-un errore comune, tanto che le \acr{glibc} provvedono una macro
+un errore comune, tanto che la \acr{glibc} provvede una macro
\code{TEMP\_FAILURE\_RETRY(expr)} che esegue l'operazione automaticamente,
ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
non è diverso dall'uscita con un errore \errcode{EINTR}.
possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
condizione.
-Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
+Linux e la \acr{glibc} consentono di utilizzare entrambi gli approcci,
attraverso una opportuna opzione di \func{sigaction} (vedi
sez.~\ref{sec:sig_sigaction}). È da chiarire comunque che nel caso di
interruzione nel mezzo di un trasferimento parziale di dati, le \textit{system
In questa definizione per l'argomento \param{handler} che indica il gestore da
installare si è usato un tipo di dato, \type{sighandler\_t}, che è una
-estensione GNU, definita dalle \acr{glibc}, che permette di riscrivere il
+estensione GNU, definita dalla \acr{glibc}, che permette di riscrivere il
prototipo di \func{signal} nella forma appena vista, molto più leggibile di
quanto non sia la versione originaria, che di norma è definita come:
\includecodesnip{listati/signal.c}
ridefinita per seguire la semantica affidabile usata da BSD.}
Al contrario BSD segue la semantica affidabile, non disinstallando il gestore
-e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
+e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo della
\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
comportamento della versione originale della funzione, il cui uso è deprecato
per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto
L'uso di \func{setitimer} consente dunque un controllo completo di tutte le
caratteristiche dei timer, ed in effetti la stessa \func{alarm}, benché
definita direttamente nello standard POSIX.1, può a sua volta essere espressa
-in termini di \func{setitimer}, come evidenziato dal manuale delle \acr{glibc}
+in termini di \func{setitimer}, come evidenziato dal manuale della \acr{glibc}
\cite{GlibcMan} che ne riporta la definizione mostrata in
fig.~\ref{fig:sig_alarm_def}.\footnote{questo comporta anche che non è il caso
di mescolare chiamate ad \func{abort} e a \func{setitimer}.}
quella dell'esempio che vedremo in sez.~\ref{sec:sig_example}. In tal caso
mescolare chiamate di \func{alarm} e \func{sleep} o modificare l'azione
associata \signal{SIGALRM}, può portare a dei risultati indefiniti. Nel caso
-delle \acr{glibc} è stata usata una implementazione completamente indipendente
+della \acr{glibc} è stata usata una implementazione completamente indipendente
e questi problemi non ci sono, ma un programma portabile non può fare questa
assunzione.
La granularità di \func{sleep} permette di specificare attese soltanto in
secondi, per questo sia sotto BSD4.3 che in SUSv2 è stata definita un'altra
funzione con una precisione teorica del microsecondo. I due standard hanno
-delle definizioni diverse, ma le \acr{glibc} seguono (secondo la pagina di
-manuale almeno dalla versione 2.2.2) seguono quella di SUSv2 per cui la
+delle definizioni diverse, ma la \acr{glibc} segue (secondo la pagina di
+manuale almeno dalla versione 2.2.2) quella di SUSv2 per cui la
funzione \funcd{usleep} (dove la \texttt{u} è intesa come sostituzione di
$\mu$), ha il seguente prototipo:
Su Linux di solito il primo valore è 33, mentre il secondo è \code{\_NSIG-1},
che di norma (vale a dire sulla piattaforma i386) è 64. Questo dà un totale di
32 segnali disponibili, contro gli almeno 8 richiesti da POSIX.1b. Si tenga
-presente però che i primi segnali \textit{real-time} disponibili vendono usati
-dalle \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
+presente però che i primi segnali \textit{real-time} disponibili vengono usati
+dalla \acr{glibc} per l'implementazione dei \textit{thread} POSIX (vedi
sez.~\ref{sec:thread_posix_intro}), ed il valore di \const{SIGRTMIN} viene
modificato di conseguenza.\footnote{per la precisione vengono usati i primi
tre per la vecchia implementazione dei \textit{LinuxThread} ed i primi due
% CLOCK_REALTIME_ALARM vedi http://lwn.net/Articles/429925/
% TODO: dal 3.10 anche CLOCK_TAI
-Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la
+Per poter utilizzare queste funzionalità la \acr{glibc} richiede 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
normale ritorno, mentre quella usata da System V no.
Lo standard POSIX.1 non specifica questo comportamento per \func{setjmp} e
-\func{longjmp}, ed il comportamento delle \acr{glibc} dipende da quale delle
+\func{longjmp}, ed il comportamento della \acr{glibc} dipende da quale delle
caratteristiche si sono abilitate con le macro viste in
sez.~\ref{sec:intro_gcc_glibc_std}.
Per questo aspetto il file di configurazione principale del sistema è
\conffile{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi
-IP dei server DNS da contattare; a questo si affiancava (fino alle \acr{glibc}
+IP dei server DNS da contattare; a questo si affiancava (fino alla \acr{glibc}
2.4) il file \conffile{/etc/host.conf} il cui scopo principale era indicare
l'ordine in cui eseguire la risoluzione dei nomi (se usare prima i valori di
\conffile{/etc/hosts} o quelli del DNS). Tralasciamo i dettagli relativi alle
associate chiamato \textit{Name Service Switch}, cui abbiamo accennato anche in
sez.~\ref{sec:sys_user_group} per quanto riguarda la gestione dei dati
associati a utenti e gruppi. Il sistema è stato introdotto la prima volta
-nelle librerie standard di Solaris e le \acr{glibc} hanno ripreso lo stesso
+nella libreria standard di Solaris e la \acr{glibc} ha ripreso lo stesso
schema; si tenga presente che questo sistema non esiste per altre librerie
-standard come le \acr{libc5} o le \acr{uclib}.
+standard come la \acr{libc5} o la \acr{uClib}.
Il \textit{Name Service Switch} (cui spesso si fa riferimento con l'acronimo
NSS) è un sistema di librerie dinamiche che permette di definire in maniera
fornite dal sistema del \textit{Name Service Switch}, dal punto di vista di un
programma che deve effettuare la risoluzione di un nome a dominio, tutto
quello che conta sono le funzioni classiche che il \textit{resolver} mette a
-disposizione (è cura delle \acr{glibc} tenere conto della presenza del
+disposizione (è cura della \acr{glibc} tenere conto della presenza del
\textit{Name Service Switch}) e sono queste quelle che tratteremo nelle
sezioni successive.
\const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e poi chiamare
\func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per modificare
le opzioni del \textit{resolver}; dato che questo non è molto comodo è stata
-definita (è una estensione fornita dalle \acr{glibc}, disponibile anche in
+definita (è una estensione fornita dalla \acr{glibc}, disponibile anche in
altri sistemi unix-like) un'altra funzione, \funcd{gethostbyname2}, il cui
prototipo è:
contenuti in essa (e così via se vi sono altre sotto-strutture con altri
puntatori) e copiare anche i dati da questi referenziati.}
-Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
+Per ovviare a questi problemi nella \acr{glibc} sono definite anche delle
versioni rientranti delle precedenti funzioni, al solito queste sono
caratterizzate dall'avere un suffisso \texttt{\_r}, pertanto avremo le due
funzioni \funcd{gethostbyname\_r} e \funcd{gethostbyname2\_r} i cui prototipi
Dato che \func{gethostbyaddr} usa un buffer statico, anche di questa funzione
esiste una versione rientrante \funcd{gethostbyaddr\_r} fornita come
-estensione dalle \acr{glibc}, il cui prototipo è:
+estensione dalla \acr{glibc}, il cui prototipo è:
\begin{funcproto}{
\fhead{netdb.h}
lettura delle voci presenti in quest'ultimo, come avviene anche in altri
sistemi unix-like, ed inoltre ignora le voci relative ad indirizzi IPv6.
-Della stessa funzione le \acr{glibc} forniscono anche una versione rientrante
+Della stessa funzione la \acr{glibc} fornisce anche una versione rientrante
\funcd{gethostent\_r}, il cui prototipo è:
\begin{funcproto}{
è stata successivamente proposta,
nell'\href{http://www.ietf.org/rfc/rfc2553.txt}{RFC~2553} un diversa
interfaccia con l'introduzione due nuove funzioni di
-risoluzione,\footnote{dette funzioni sono presenti nelle \acr{glibc} versione
- 2.1.96, ma essendo considerate deprecate (vedi
+risoluzione,\footnote{dette funzioni sono presenti nella \acr{glibc} 2.1.96,
+ ma essendo considerate deprecate (vedi
sez.~\ref{sec:sock_advanced_name_services}) sono state rimosse nelle
versioni successive.} \funcd{getipnodebyname} e \funcd{getipnodebyaddr}, i
cui prototipi sono:
maschera.
Nella seconda parte della tabella si sono riportati i valori delle costanti
-aggiunte a partire dalle \acr{glibc} 2.3.4 per gestire la
+aggiunte a partire dalla \acr{glibc} 2.3.4 per gestire la
internazionalizazione dei nomi a dominio (IDN o \textit{Internationalized
Domain Names}) secondo quanto specificato
nell'\href{http://www.ietf.org/rfc/rfc3490.txt}{RFC~3490} (potendo cioè usare
impostare le modalità con cui viene eseguita la ricerca, e deve essere
specificato attraverso l'OR aritmetico dei valori illustrati in
tab.~\ref{tab:getnameinfo_flags}, nella seconda parte della tabella si sono
-aggiunti i valori introdotto con le \acr{glibc} 2.3.4 per gestire la
+aggiunti i valori introdotto con la \acr{glibc} 2.3.4 per gestire la
internazionalizzione dei nomi a dominio.
\begin{table}[!htb]
in realtà sempre di tipo \ctyp{int}, come era nelle \acr{libc4} e
\acr{libc5}; l'uso di \type{socklen\_t} è stato introdotto da POSIX (valgono
le stesse considerazioni per l'uso di questo tipo di dato fatte in
- sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
+ sez.~\ref{sec:TCP_func_accept}) ed adottato dalla \acr{glibc}.} è la
dimensione in byte dei dati presenti all'indirizzo indicato da \param{optval}.
Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
individuare qual è quello che deve essere usato, ed utilizzare le opportune
situazione.} utilizzare per il singolo socket. L'opzione è stata
introdotta con il kernel 2.6.13,\footnote{alla data di stesura di queste
note (Set. 2006) è pure scarsamente documentata, tanto che non è neanche
- definita nelle intestazioni delle \acr{glibc} per cui occorre definirla a
+ definita nelle intestazioni della \acr{glibc} per cui occorre definirla a
mano al suo valore che è 13.} e prende come per \param{optval} il
puntatore ad un buffer contenente il nome dell'algoritmo di controllo che
si vuole usare.
associato ad una costante, che inizia invece per \texttt{AF\_} (da
\textit{address family}) che identifica il formato degli indirizzi usati in
quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
-anche come \textit{name space}, (nome che invece il manuale delle \acr{glibc}
+anche come \textit{name space}, (nome che invece il manuale della \acr{glibc}
riserva a quello che noi abbiamo chiamato domini) dato che identificano il
formato degli indirizzi usati in quel dominio per identificare i capi della
comunicazione.
espressioni regolari o del comando \cmd{bc}, non li tratteremo esplicitamente,
se ne trova una menzione completa nell'header file \file{bits/posix2\_lim.h},
e alcuni di loro sono descritti nella pagina di manuale di \func{sysconf} e
-nel manuale delle \acr{glibc}.
+nel manuale della \acr{glibc}.
Quando uno dei limiti o delle caratteristiche del sistema può variare, per non
dover essere costretti a ricompilare un programma tutte le volte che si
vuole conoscere. Uno specchietto contenente i principali valori disponibili in
Linux è riportato in tab.~\ref{tab:sys_sysconf_par}, l'elenco completo è
contenuto in \file{bits/confname.h}, ed una lista più esaustiva, con le
-relative spiegazioni, si può trovare nel manuale delle \acr{glibc}.
+relative spiegazioni, si può trovare nel manuale della \acr{glibc}.
\begin{table}[htb]
\centering
\end{figure}
Si noti come in fig.~\ref{fig:sys_utsname} le dimensioni delle stringhe di
-\struct{utsname} non sono specificate. Il manuale delle \acr{glibc} indica
+\struct{utsname} non sono specificate. Il manuale della \acr{glibc} indica
due costanti per queste dimensioni, \constd{\_UTSNAME\_LENGTH} per i campi
standard e \constd{\_UTSNAME\_DOMAIN\_LENGTH} per quello relativo al nome di
dominio, altri sistemi usano nomi diversi come \constd{SYS\_NMLN} o
completamente quelle relative all'autenticazione.
% Per questo non tratteremo
% affatto l'interfaccia di PAM, ma approfondiremo invece il sistema del
-% \textit{Name Service Switch}, un meccanismo messo a disposizione dalle
+% \textit{Name Service Switch}, un meccanismo messo a disposizione dalla
% \acr{glibc} per modularizzare l'accesso a tutti i servizi in cui sia
% necessario trovare una corrispondenza fra un nome ed un numero (od altra
% informazione) ad esso associato, come appunto, quella fra uno username ed un
soltanto l'elenco di tab.~\ref{tab:sys_passwd_func}, senza nessuna spiegazione
ulteriore. Chi volesse insistere ad usare questa interfaccia può fare
riferimento alle pagine di manuale delle rispettive funzioni ed al manuale
-delle \acr{glibc} per i dettagli del funzionamento.
+della \acr{glibc} per i dettagli del funzionamento.
registrazione delle attività degli utenti. A quest'ultimo vengono anche
aggiunte delle voci speciali per tenere conto dei cambiamenti del sistema,
come la modifica del runlevel, il riavvio della macchina, ecc. Tutte queste
-informazioni sono descritte in dettaglio nel manuale delle \acr{glibc}.
+informazioni sono descritte in dettaglio nel manuale della \acr{glibc}.
Questi file non devono mai essere letti direttamente, ma le informazioni che
contengono possono essere ricavate attraverso le opportune funzioni di
completamente standardizzate, e che in sistemi diversi possono esserci
differenze; ad esempio \func{pututline} restituisce \code{void} in vari
sistemi (compreso Linux, fino alle \acr{libc5}). Qui seguiremo la sintassi
-fornita dalle \acr{glibc}, ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno
+fornita dalla \acr{glibc}, ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno
introdotto delle nuove strutture (e relativi file) di tipo \struct{utmpx}, che
sono un sovrainsieme della \struct{utmp} usata tradizionalmente ed altrettante
funzioni che le usano al posto di quelle citate.
-Le \acr{glibc} utilizzavano già una versione estesa di \struct{utmp}, che
+La \acr{glibc} utilizzava già una versione estesa di \struct{utmp}, che
rende inutili queste nuove strutture, per questo su Linux \struct{utmpx} viene
definita esattamente come \struct{utmp}, con gli stessi campi di
fig.~\ref{fig:sys_utmp_struct}. Altrettanto dicasi per le nuove funzioni di
Come già visto in sez.~\ref{sec:sys_user_group}, l'uso di strutture allocate
staticamente rende le funzioni di lettura dei dati appena illustrate non
-rientranti. Per questo motivo le \acr{glibc} forniscono anche delle versioni
+rientranti. Per questo motivo la \acr{glibc} fornisce anche delle versioni
rientranti: \func{getutent\_r}, \func{getutid\_r}, \func{getutline\_r}, che
invece di restituire un puntatore restituiscono un intero e prendono due
argomenti aggiuntivi, i rispettivi prototipi sono:
primo argomento aggiuntivo \param{buffer} mentre il secondo, \param{result)}
viene usato per restituire il puntatore al buffer stesso.
-Infine le \acr{glibc} forniscono altre due funzioni, \funcd{updwtmp} e
+Infine la \acr{glibc} fornisce altre due funzioni, \funcd{updwtmp} e
\funcd{logwtmp}, come estensione per scrivere direttamente delle voci nel file
sul registro storico \sysfile{/var/log/wtmp}; i rispettivi prototipi sono:
In Linux è implementata come una \textit{system call} nelle architetture in
cui essa è necessaria, ed in genere restituisce il valore del simbolo
\const{PAGE\_SIZE} del kernel, che dipende dalla architettura hardware, anche
-se le versioni delle librerie del C precedenti le \acr{glibc} 2.1
+se le versioni delle librerie del C precedenti la \acr{glibc} 2.1
implementavano questa funzione restituendo sempre un valore statico.
% TODO verificare meglio la faccenda di const{PAGE\_SIZE}
-Le \textsl{glibc} forniscono, come specifica estensione GNU, altre due
+La \textsl{glibc} fornisce, come specifica estensione GNU, altre due
funzioni, \funcd{get\_phys\_pages} e \funcd{get\_avphys\_pages} che permettono
di ottenere informazioni riguardo le pagine di memoria; i loro prototipi sono:
corrispondenti alla RAM della macchina; la seconda invece la memoria
effettivamente disponibile per i processi.
-Le \acr{glibc} supportano inoltre, come estensioni GNU, due funzioni che
+La \acr{glibc} supporta inoltre, come estensioni GNU, due funzioni che
restituiscono il numero di processori della macchina (e quello dei processori
attivi); anche queste sono informazioni comunque ottenibili attraverso
\func{sysconf} utilizzando rispettivamente i parametri
\const{\_SC\_NPROCESSORS\_CONF} e \const{\_SC\_NPROCESSORS\_ONLN}.
-Infine le \acr{glibc} riprendono da BSD la funzione \funcd{getloadavg} che
+Infine la \acr{glibc} riprende da BSD la funzione \funcd{getloadavg} che
permette di ottenere il carico di processore della macchina, in questo modo è
possibile prendere decisioni su quando far partire eventuali nuovi processi.
Il suo prototipo è:
la cosiddetta \textit{timezone}, cioè l'insieme del fuso orario e delle
convenzioni per l'ora legale che permettevano il passaggio dal tempo
universale all'ora locale. Questo argomento oggi è obsoleto ed in Linux non è
-mai stato utilizzato; esso non è supportato né dalle vecchie \textsl{libc5},
-né dalle \textsl{glibc}: pertanto quando si chiama questa funzione deve essere
+mai stato utilizzato; esso non è supportato né dalla vecchia \textsl{libc5},
+né dalla \textsl{glibc}: pertanto quando si chiama questa funzione deve essere
sempre impostato a \val{NULL}.
\itindbeg{timezone}
La funzione utilizza il meccanismo di David L. Mills, descritto
nell'\href{http://www.ietf.org/rfc/rfc1305.txt}{RFC~1305}, che è alla base del
protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la
-portabilità è un requisito, le \acr{glibc} provvedono anche un suo omonimo
+portabilità è un requisito, la \acr{glibc} provvede anche un suo omonimo
\func{ntp\_adjtime}. La trattazione completa di questa funzione necessita di
una lettura approfondita del meccanismo descritto nell'RFC~1305, ci limitiamo
a descrivere in tab.~\ref{tab:sys_timex_mode} i principali valori utilizzabili
viene utilizzato come modificatore. Alcuni dei possibili valori che esso può
assumere sono riportati in tab.~\ref{tab:sys_strftime_format}.\footnote{per la
precisione si sono riportati definiti dallo standard ANSI C, che sono anche
- quelli ripresi in POSIX.1; le \acr{glibc} forniscono anche le estensioni
+ quelli ripresi in POSIX.1; la \acr{glibc} fornisce anche le estensioni
introdotte da POSIX.2 per il comando \cmd{date}, i valori introdotti da
SVID3 e ulteriori estensioni GNU; l'elenco completo dei possibili valori è
riportato nella pagina di manuale della funzione.} La funzione tiene conto
\subsection{Alcune estensioni GNU}
\label{sec:sys_err_GNU}
-Le precedenti funzioni sono quelle definite ed usate nei vari standard; le
-\acr{glibc} hanno però introdotto una serie di estensioni ``GNU'' che
+Le precedenti funzioni sono quelle definite ed usate nei vari standard; la
+\acr{glibc} ha però introdotto una serie di estensioni ``GNU'' che
forniscono alcune funzionalità aggiuntive per una gestione degli errori
semplificata e più efficiente.
informazioni. Ad esempio negli standard di programmazione GNU si richiede che
ogni messaggio di errore sia preceduto dal nome del programma, ed in generale
si può voler stampare il contenuto di qualche variabile per facilitare la
-comprensione di un eventuale problema. Per questo le \acr{glibc} definiscono
+comprensione di un eventuale problema. Per questo la \acr{glibc} definisce
la funzione \funcd{error}, il cui prototipo è:
\begin{funcproto}{
stata seguita anche dalle varie implementazioni dei \textit{thread} realizzate
su Linux, ed in particolare dalla \textit{Native Thread Posix Library} che è
stata integrata con i kernel della serie 2.6 e che fa parte a pieno titolo
-delle \acr{glibc}.
+della \acr{glibc}.
\subsection{Una panoramica}
projects / gapil.git / commitdiff