La richiesta di un \textit{file lock} prevede una scansione della lista per
determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
-un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
+un nuovo elemento.\footnote{cioè una nuova struttura \kstruct{file\_lock}.}
Nel caso dei blocchi creati con \func{flock} la semantica della funzione
prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un
\textit{file lock} quanto piuttosto degli ulteriori riferimenti allo
stesso. Questo viene realizzato dal kernel secondo lo schema di
fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock}
un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
- \struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
+ \kstruct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file
table} da cui si è richiesto il blocco, che così ne identifica il titolare.
kernel. Lo schema delle strutture utilizzate è riportato in
fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
- sono evidenziati solo i campi di \struct{file\_lock} significativi per la
+ sono evidenziati solo i campi di \kstruct{file\_lock} significativi per la
semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
\ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene
bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
Quando si richiede un \textit{file lock} il kernel effettua una scansione di
tutti i blocchi presenti sul file\footnote{scandisce cioè la
\itindex{linked~list} \textit{linked list} delle strutture
- \struct{file\_lock}, scartando automaticamente quelle per cui
+ \kstruct{file\_lock}, scartando automaticamente quelle per cui
\var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
ben separate.} per verificare se la regione richiesta non si sovrappone ad
una già bloccata, in caso affermativo decide in base al tipo di blocco, in
versioni diverse della \textit{system call}; una prima versione,
\func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
\acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
- versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
+ 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
argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
maschera dei segnali, il cui valore viene impostato automaticamente dalle
partire dal kernel 2.6.30 sono state introdotte anche per l'\textsl{I/O
vettorizzato} le analoghe delle funzioni \func{pread} e \func{pwrite} (vedi
sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
-\funcd{preadv} e \func{pwritev} ed i rispettivi prototipi sono:\footnote{le
+\funcd{preadv} e \funcd{pwritev} ed i rispettivi prototipi sono:\footnote{le
due funzioni sono analoghe alle omonime presenti in BSD; le \textit{system
call} usate da Linux (introdotte a partire dalla versione 2.6.30)
utilizzano degli argomenti diversi per problemi collegati al formato a 64
un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
sorgente e \param{fd\_out} il capo in scrittura della \textit{pipe}
destinazione; a differenza di quanto avviene con \func{read} i dati letti con
-\func{tee} da \func{fd\_in} non vengono \textsl{consumati} e restano
+\func{tee} da \param{fd\_in} non vengono \textsl{consumati} e restano
disponibili sulla \textit{pipe} per una successiva lettura (di nuovo per il
comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al
momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio
dovrà creare anche la relativa versione della funzione \code{mount}.
\itindbeg{pathname}
-\itindbeg{pathname!resolution}
+\itindbeg{pathname~resolution}
Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
filesystem.
\itindend{pathname}
-\itindend{pathname!resolution}
+\itindend{pathname~resolution}
% Un secondo effetto della chiamata funzione \texttt{mount} di
% \kstruct{file\_system\_type} è quello di allocare una struttura
funzione \texttt{open} che invece è citata in
tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
invocata dato che nella struttura \kstruct{inode} è presente anche il
- puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
- fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
-file richiede comunque un'altra operazione che mette in gioco l'omonimo
-oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
-viene associata ad ogni file aperto nel sistema.
+ puntatore \var{i\_fop} alla struttura \kstruct{file\_operation} che fornisce
+ detta funzione.} Questo avviene perché su Linux l'apertura di un file
+richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
+VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
+ad ogni file aperto nel sistema.
I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
dei file descriptor il cui significato emergerà più avanti, il puntatore
-\struct{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga
-per i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
+\var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
+i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
fornite dal VFS per i file. Si sono riportate in
tab.~\ref{tab:file_file_operations} le più significative.
Per aggiungere ad una directory una voce che faccia riferimento ad un
\itindex{inode} \textit{inode} già esistente si utilizza la funzione
-\func{link}; si suole chiamare questo tipo di associazione un collegamento
+\funcd{link}; si suole chiamare questo tipo di associazione un collegamento
diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
\begin{funcproto}{
stream}.
Di questa funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \func{readdir\_r},\footnote{per usarla è necessario definire una
+rientrante, \funcd{readdir\_r},\footnote{per usarla è necessario definire una
qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
\macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
\struct{dirent}) come argomento della funzione di selezione specificata da
\param{filter}; se questa ritorna un valore diverso da zero il puntatore viene
inserito in un vettore che viene allocato dinamicamente con \func{malloc}.
-Qualora si specifichi un valore \val{NULL} per l'argomento \func{filter} non
+Qualora si specifichi un valore \val{NULL} per l'argomento \param{filter} non
viene fatta nessuna selezione e si ottengono tutte le voci presenti.
-Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
-del riordinamento possono essere personalizzate usando la funzione
-\param{compar} come criterio di ordinamento di \func{qsort}, la funzione
+Le voci selezionate possono essere riordinate tramite \funcm{qsort}, le
+modalità del riordinamento possono essere personalizzate usando la funzione
+\param{compar} come criterio di ordinamento di \funcm{qsort}, la funzione
prende come argomenti le due strutture \struct{dirent} da confrontare
restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
- \func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
+ \funcm{strcoll} al posto di \funcm{strcmp}.} anche \func{versionsort}, che
ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
\texttt{file10} viene comunque dopo \texttt{file4}.)
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ù
+ della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
precisamente nel campo \texttt{pwd} della sotto-struttura
- \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
+ \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
\textsl{directory di lavoro} (in inglese \textit{current working directory}).
La directory di lavoro è quella da cui si parte quando un
\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
\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.
+\funcm{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
il file esplicitamente, il suo prototipo è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
dello standard POSIX (la POSIX.1-2008); sono state introdotte a partire dal
kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta
- la funzione \func{futimesat} seguendo una bozza della revisione dello
+ la funzione \funcm{futimesat} seguendo una bozza della revisione dello
standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
essere più utilizzata: pertanto non la tratteremo.} La prima è
permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
$222$ nel secondo). Per questo motivo il sistema associa ad ogni
processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
- \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
-bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+ \kstruct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera
+di bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
bit indicati nella maschera vengono infatti cancellati dai permessi quando un
nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
perché la funzione abbia successo la ACL dovrà essere valida, e contenere
tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL
vuota per cancellare la ACL di default associata a
-\func{path}.\footnote{questo però è una estensione della implementazione delle
+\param{path}.\footnote{questo però è una estensione della implementazione delle
ACL di Linux, la bozza di standard POSIX.1e prevedeva l'uso della apposita
funzione \funcd{acl\_delete\_def\_file}, che prende come unico argomento il
\textit{pathname} della directory di cui si vuole cancellare l'ACL di
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
\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
+ \var{pwd} e \var{root}) di \kstruct{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
\noindent in genere si usa questa funzione una volta che si sia identificata e
corretta la causa di un errore per evitare di mantenere i flag attivi, così da
poter rilevare una successiva ulteriore condizione di errore. Di questa
-funzione esiste una analoga \func{clearerr\_unlocked} che non esegue il blocco
-dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}).
+funzione esiste una analoga \funcm{clearerr\_unlocked} che non esegue il
+blocco dello \textit{stream} (vedi sez.~\ref{sec:file_stream_thread}).
\subsection{Input/output binario}
% TODO verificare se mettere prototipi di \func{dprintf} e \func{vdprintf}
-Infine una ulteriore estensione GNU definisce le due funzioni \func{dprintf} e
-\func{vdprintf}, che prendono un file descriptor al posto dello
+Infine una ulteriore estensione GNU definisce le due funzioni \funcm{dprintf} e
+\funcm{vdprintf}, che prendono un file descriptor al posto dello
\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
di errore o fine del file viene invece restituito \val{EOF}.}
\end{functions}
\noindent e come per le analoghe funzioni di scrittura esistono le relative
-\func{vscanf}, \func{vfscanf} \func{vsscanf} che usano un puntatore ad una
-lista di argomenti.
+\funcm{vscanf}, \funcm{vfscanf} e \funcm{vsscanf} che usano un puntatore ad
+una lista di argomenti.
Tutte le funzioni della famiglia delle \func{scanf} vogliono come argomenti i
puntatori alle variabili che dovranno contenere le conversioni; questo è un
posizione sul file viene espressa con un valore a 64 bit come accade nei
sistemi più moderni.
+% TODO: mettere prototipi espliciti fseeko e ftello o menzione?
\section{Funzioni avanzate}
\macro{\_SVID\_SOURCE} o \macro{\_GNU\_SOURCE}.} che non effettua il blocco
dello stream.
+% TODO aggiungere prototipo \func{fflush\_unlocked}?
+
Se \param{stream} è \val{NULL} lo scarico dei dati è forzato per tutti gli
\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
La \itindex{file~table} \textit{file table} è una tabella che contiene una
voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
-strutture di tipo \struct{file}; in ciascuna di esse sono tenute varie
-informazioni relative al file, fra cui:
+puntatori alle strutture di tipo \kstruct{file} di fig.~\ref{fig:kstruct_file}
+che come illustrano mantengono varie informazioni relative al file, fra cui:
\begin{itemize*}
\item lo stato del file (nel campo \var{f\_flags}).
\item il valore della posizione corrente (l'\textit{offset}) nel file (nel
campo \var{f\_pos}).
\item un puntatore \itindex{inode} all'inode\footnote{nel kernel 2.4.x si è in
- realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
- a sua volta \itindex{inode} all'inode passando per la nuova struttura del
- VFS.} del file.
-%\item un puntatore alla tabella delle funzioni \footnote{la struttura
-% \var{f\_op} descritta in sez.~\ref{sec:file_vfs_work}} che si possono usare
-% sul file.
+ realtà passati ad un puntatore ad una struttura \kstruct{dentry} che punta
+ a sua volta \itindex{inode} all'\textit{inode} passando per la nuova
+ struttura del VFS.} del file.
+\item un puntatore \var{f\_op} alla tabella delle funzioni \footnote{quelle
+ della struttura \kstruct{file\_operation}, descritte in
+ tab.~\ref{tab:file_file_operations}.} che si possono usare sul file.
\end{itemize*}
In fig.~\ref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
La funzione apre il file usando il primo file descriptor libero, e crea
-l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
+l'opportuna voce, cioè la struttura \kstruct{file}, nella \itindex{file~table}
\textit{file table} del processo. Viene sempre restituito come valore di
ritorno il file descriptor con il valore più basso disponibile.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
-campo \var{f\_flags} della struttura \struct{file} (al solito si veda lo schema
+campo \var{f\_flags} della struttura \kstruct{file} (al solito si veda lo schema
di fig.~\ref{fig:file_proc_file}). Essi sono divisi in tre categorie
principali:
\begin{itemize*}
Come già accennato in sez.~\ref{sec:file_fd} a ciascun file aperto è associata
una \textsl{posizione corrente nel file} (il cosiddetto \textit{file offset},
-mantenuto nel campo \var{f\_pos} di \struct{file}) espressa da un numero intero
+mantenuto nel campo \var{f\_pos} di \kstruct{file}) espressa da un numero intero
positivo come numero di byte dall'inizio del file. Tutte le operazioni di
lettura e scrittura avvengono a partire da questa posizione che viene
automaticamente spostata in avanti del numero di byte letti o scritti.
\end{prototype}
La funzione prende esattamente gli stessi argomenti di \func{read} con lo
-stesso significato, a cui si aggiunge l'argomento \func{offset} che indica una
-posizione sul file. Identico è il comportamento ed il valore di ritorno. La
-funzione serve quando si vogliono leggere dati dal file senza modificare la
-posizione corrente.
+stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
+una posizione sul file. Identico è il comportamento ed il valore di
+ritorno. La funzione serve quando si vogliono leggere dati dal file senza
+modificare la posizione corrente.
L'uso di \func{pread} è equivalente all'esecuzione di una \func{read} seguita
da una \func{lseek} che riporti al valore precedente la posizione corrente sul
disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
processo avrà una sua voce nella \textit{file table} referenziata da un
-diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
+diverso file descriptor nella sua \kstruct{file\_struct}. Entrambe le voci
nella \itindex{file~table} \textit{file table} faranno però riferimento allo
stesso \itindex{inode} inode su disco.
prima impostata alla dimensione corrente del file letta \itindex{inode}
dall'inode. Dopo la scrittura il file viene automaticamente esteso.
\item l'effetto di \func{lseek} è solo quello di cambiare il campo
- \var{f\_pos} nella struttura \struct{file} della \itindex{file~table}
+ \var{f\_pos} nella struttura \kstruct{file} della \itindex{file~table}
\textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
si usa per porsi alla fine del file la posizione viene impostata leggendo la
dimensione corrente \itindex{inode} dall'inode.
sez.~\ref{sec:proc_fork}). La situazione è illustrata in
fig.~\ref{fig:file_acc_child}; dato che il processo figlio riceve una copia
dello spazio di indirizzi del padre, riceverà anche una copia di
-\struct{file\_struct} e relativa tabella dei file aperti.
+\kstruct{file\_struct} e relativa tabella dei file aperti.
In questo modo padre e figlio avranno gli stessi file descriptor che faranno
riferimento alla stessa voce nella \textit{file table}, condividendo così la
Si noti inoltre che anche i flag di stato del file (quelli impostati
dall'argomento \param{flag} di \func{open}) essendo tenuti nella voce della
\textit{file table}\footnote{per la precisione nel campo \var{f\_flags} di
- \struct{file}.}, vengono in questo caso condivisi. Ai file però sono
+ \kstruct{file}.}, vengono in questo caso condivisi. Ai file però sono
associati anche altri flag, dei quali l'unico usato al momento è
\const{FD\_CLOEXEC}, detti \textit{file descriptor flags}. Questi ultimi sono
-tenuti invece in \struct{file\_struct}, e perciò sono specifici di ciascun
+tenuti invece in \kstruct{file\_struct}, e perciò sono specifici di ciascun
processo e non vengono modificati dalle azioni degli altri anche in caso di
condivisione della stessa voce della \textit{file table}.
interscambiati nell'uso. Per capire meglio il funzionamento della funzione si
può fare riferimento a fig.~\ref{fig:file_dup}: l'effetto della funzione è
semplicemente quello di copiare il valore nella struttura
-\struct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
+\kstruct{file\_struct}, cosicché anche il nuovo file descriptor fa riferimento
alla stessa voce nella \textit{file table}; per questo si dice che il nuovo
file descriptor è \textsl{duplicato}, da cui il nome della funzione.
\func{fstatat} &$\bullet$&\func{stat},\func{lstat} \\
\func{utimensat} &$\bullet$&\func{utimes},\func{lutimes}\\
\func{linkat} &$\bullet$\footnotemark&\func{link} \\
- \func{mkdirat} & -- &\func{mkdir} \\
- \func{mknodat} & -- &\func{mknod} \\
+ \funcm{mkdirat} & -- &\func{mkdir} \\
+ \funcm{mknodat} & -- &\func{mknod} \\
\func{openat} & -- &\func{open} \\
- \func{readlinkat}& -- &\func{readlink}\\
- \func{renameat} & -- &\func{rename} \\
- \func{symlinkat} & -- &\func{symlink} \\
+ \funcm{readlinkat}& -- &\func{readlink}\\
+ \funcm{renameat} & -- &\func{rename} \\
+ \funcm{symlinkat}& -- &\func{symlink} \\
\func{unlinkat} &$\bullet$&\func{unlink},\func{rmdir} \\
- \func{mkfifoat} & -- &\func{mkfifo} \\
+ \funcm{mkfifoat} & -- &\func{mkfifo} \\
\hline
\end{tabular}
\caption{Corrispondenze fra le nuove funzioni ``\textit{at}'' e le
\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed
utilizzabile solo a partire dal kernel 2.6.18.}
-% TODO manca prototipo di fchmodat
+% TODO manca prototipo di fchmodat, verificare se metterlo o metter menzione
+% TODO manca prototipo di fstatat, verificare se metterlo o metter menzione
+% TODO manca prototipo di linkat, verificare se metterlo o metter menzione
+% TODO manca prototipo di utimensat, verificare se metterlo o metter menzione
Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e
\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire
\funcdecl{int fchownat(int dirfd, const char *pathname, uid\_t owner, gid\_t
group, int flags)}
- .Modifica la proprietà di un file.
+ Modifica la proprietà di un file.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
errore di \func{chown}, ed in più:
caso \param{pathname} deve essere una directory, che sarà rimossa qualora
risulti vuota.
+% TODO manca prototipo e motivazione di fexecve, da trattare qui in quanto
+% inserita nello stesso standard e da usare con openat, vedi
+% http://pubs.opengroup.org/onlinepubs/9699939699/toc.pdf
+
+
+
\subsection{La funzione \func{fcntl}}
\label{sec:file_fcntl}
\conffile{/etc/passwd} e \conffile{/etc/group}.\footnote{in realtà negli
sistemi più moderni, come vedremo in sez.~\ref{sec:sys_user_group} queste
informazioni possono essere mantenute, con l'uso del
- \itindex{Name~Service~Switch} \textit{Name Service Switch}, su varie
+ \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch}, su varie
tipologie di supporti, compresi server centralizzati come LDAP.} Questi
identificativi sono l'\textit{user identifier}, detto in breve
\textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il \textit{group
sta in cima all'albero, essa viene indicata semplicemente con il
\textit{pathname} \file{/}.
-\itindbeg{pathname!resolution}
+\itindbeg{pathname~resolution}
Un file può essere indicato rispetto ad una directory semplicemente
specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
alla radice stessa.
\itindend{pathname}
-\itindend{pathname!resolution}
+\itindend{pathname~resolution}
\subsection{I tipi di file}
Le funzionalità implementate sono principalmente il meccanismo di
intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
-\func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
+\funcm{hsearch} e \funcm{drand48}, \funcm{fmtmsg} e svariate funzioni
matematiche.
a 64 bit nelle funzioni di gestione dei file (non supportati in certi
sistemi), caratterizzate dal suffisso \texttt{64} aggiunto ai vari nomi di
tipi di dato e funzioni (come \type{off64\_t} al posto di \type{off\_t} o
- \func{lseek64} al posto di \func{lseek}).
+ \funcm{lseek64} al posto di \func{lseek}).
Le funzioni di questa interfaccia alternativa sono state proposte come una
estensione ad uso di transizione per le \textit{Single UNIX Specification},
Le funzioni di libreria che vengono messe sotto controllo quando questa
funzionalità viene attivata sono, al momento della stesura di queste note,
- le seguenti: \func{memcpy}, \func{mempcpy}, \func{memmove}, \func{memset},
- \func{stpcpy}, \func{strcpy}, \func{strncpy}, \func{strcat}, \func{strncat},
- \func{sprintf}, \func{snprintf}, \func{vsprintf}, \func{vsnprintf}, e
- \func{gets}.
+ le seguenti: \funcm{memcpy}, \funcm{mempcpy}, \funcm{memmove},
+ \funcm{memset}, \funcm{stpcpy}, \funcm{strcpy}, \funcm{strncpy},
+ \funcm{strcat}, \funcm{strncat}, \func{sprintf}, \func{snprintf},
+ \func{vsprintf}, \func{vsnprintf}, e \func{gets}.
La macro prevede due valori, con \texttt{1} vengono eseguiti dei controlli
di base che non cambiano il comportamento dei programmi se si richiede una
\struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
richiede una operazione viene anzitutto verificato che tutte le operazioni
possono avere successo; se una di esse comporta il blocco del processo il
-kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
+kernel crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo alla
coda di attesa associata a ciascun insieme di semafori\footnote{che viene
referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
di \struct{semid\_ds}.}.
viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
svuotata la coda. Per gestire il meccanismo del ripristino tutte le volte che
per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
-per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
+per ciascun insieme di semafori una apposita struttura \kstruct{sem\_undo} che
contiene (nel vettore puntato dal campo \var{semadj}) un valore di
aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
per l'operazione.
strutture se questo viene cancellato o per azzerarle se si è eseguita una
operazione con \func{semctl}; l'altra associata al processo che ha eseguito
l'operazione;\footnote{attraverso il campo \var{semundo} di
- \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
+ \kstruct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
processo termina, la lista ad esso associata viene scandita e le operazioni
applicate al semaforo. Siccome un processo può accumulare delle richieste di
ripristino per semafori differenti chiamate attraverso diverse chiamate a
il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
il messaggio. È pertanto opportuno eseguire sempre una chiamata a
-\func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
+\func{mq\_getattr} prima di eseguire una ricezione, in modo da ottenere la
dimensione massima dei messaggi sulla coda, per poter essere in grado di
allocare dei buffer sufficientemente ampi per la lettura.
\const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
\const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
-un puntatore ad una struttura \struct{sigval\_t} (definita in
+un puntatore ad una struttura \struct{sigval} (definita in
fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale
un valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali
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 \headfile{semaphore.h}, la funzione è
-\func{sem\_timedwait}, ed il suo prototipo è:
+\funcd{sem\_timedwait}, ed il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
\index{funzione!{#1}@{{\tt {#1}}}!definizione di}\texttt{#1}%
%\index{#1@{{\tt {#1}} (funzione)}!definizione di}\texttt{#1}%
}
+\newcommand{\funcm}[1]{%
+\index{funzione!{#1}@{{\tt {#1}}}!menzione di}\texttt{#1}%
+%\index{#1@{{\tt {#1}} (funzione)}!definizione di}\texttt{#1}%
+}
\newcommand{\macro}[1]{%
\index{macro!{#1}@{{\tt {#1}}}}\texttt{#1}%
frammentazione di pacchetti troppo grandi potrà essere gestita solo ai
capi della comunicazione (usando un'apposita estensione vedi
sez.~\ref{sec:IP_ipv6_extens}).
-\item IPv6 richiede il supporto per il \itindex{Maximum~Transfer~Unit}
+\item IPv6 richiede il supporto per il \itindex{Maximum~Transfer~Unit~(MTU)}
\textit{path MTU discovery} (cioè il protocollo per la selezione della
massima lunghezza del pacchetto); seppure questo sia in teoria opzionale,
senza di esso non sarà possibile inviare pacchetti più larghi della
Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
del tempo di andata e ritorno dei pacchetti fra un client e un server (il
-cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
-rende in grado di adattarsi alle condizioni della rete per non generare
+cosiddetto RTT, \itindex{Round~Trip~Time~(RTT)} \textit{Round Trip Time}), che
+lo rende in grado di adattarsi alle condizioni della rete per non generare
inutili ritrasmissioni o cadere facilmente in timeout.
Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
un pacchetto usando la \textit{jumbo payload option}.
-\item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit}
+\item Molte reti fisiche hanno una MTU \itindex{Maximum~Transfer~Unit~(MTU)}
(\textit{Maximum Transfer Unit}) che dipende dal protocollo specifico usato
al livello di connessione fisica. Il più comune è quello di ethernet che è
pari a 1500 byte, una serie di altri valori possibili sono riportati in
tab.~\ref{tab:net_mtu_values}.
\end{itemize}
-\itindbeg{Maximum~Transfer~Unit}
+\itindbeg{Maximum~Transfer~Unit~(MTU)}
Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
dimensioni eccedono la MTU viene eseguita la cosiddetta
\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
conoscere da subito il \textit{path MTU}.
-Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
- Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
-capo della connessione la dimensione massima dimensione del segmento di dati
-che può essere ricevuto, così da evitare la frammentazione. Di norma viene
-impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
-intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
-\const{TCP\_MSS} è 512.
+Infine il TCP definisce una \itindex{Maximum~Segment~Size~(MSS)}
+\textit{Maximum Segment Size} (da qui in avanti abbreviata in MSS) che
+annuncia all'altro capo della connessione la dimensione massima dimensione del
+segmento di dati che può essere ricevuto, così da evitare la
+frammentazione. Di norma viene impostato alla dimensione della MTU
+dell'interfaccia meno la lunghezza delle intestazioni di IP e TCP, in Linux il
+default, mantenuto nella costante \const{TCP\_MSS} è 512.
-\itindend{Maximum~Transfer~Unit}
+\itindend{Maximum~Transfer~Unit~(MTU)}
%%% Local Variables:
Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
-per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
-TCP: non essendovi il concetto di connessione le funzioni \func{listen} ed
+per mettersi in ascolto dei dati, questa è l'unica parte comune con un server
+TCP. Non essendovi il concetto di connessione le funzioni \func{listen} ed
\func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
eventuale risposta sarà inviata con la funzione \func{sendto}.
\funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
flags, const struct sockaddr *from, socklen\_t *fromlen)}
- Riceve un messaggio ad un socket.
+ Riceve un messaggio da un socket.
\bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
sez.~3.1.2 di \cite{AGL}.
Una volta completate le operazioni di inizializzazione di \cmd{ld-linux.so}, il
-sistema fa partire qualunque programma chiamando la funzione \func{main}. Sta
+sistema fa partire qualunque programma chiamando la funzione \code{main}. Sta
al programmatore chiamare così la funzione principale del programma da cui si
suppone che inizi l'esecuzione. In ogni caso senza questa funzione lo stesso
\textit{link-loader} darebbe luogo ad errori. Lo standard ISO C specifica che
-la funzione \func{main} può non avere argomenti o prendere due argomenti che
+la funzione \code{main} può non avere argomenti o prendere due argomenti che
rappresentano gli argomenti passati da linea di comando (su cui torneremo in
sez.~\ref{sec:proc_par_format}), in sostanza un prototipo che va sempre bene è
il seguente:
\itindend{link-loader}
In realtà nei sistemi Unix esiste un altro modo per definire la funzione
-\func{main}, che prevede la presenza di un terzo argomento, \code{char
+\code{main}, che prevede la presenza di un terzo argomento, \code{char
*envp[]}, che fornisce l'\textsl{ambiente} del programma; questa forma però
non è prevista dallo standard POSIX.1 per cui se si vogliono scrivere
programmi portabili è meglio evitarla. Per accedere all'ambiente, come vedremo
viene sempre definita automaticamente.
Ogni programma viene fatto partire mettendo in esecuzione il codice contenuto
-nella funzione \func{main}, ogni altra funzione usata dal programma, che sia
+nella funzione \code{main}, ogni altra funzione usata dal programma, che sia
ottenuta da una libreria condivisa, o che sia direttamente definita nel
-codice, dovrà essere invocata a partire dal codice di \func{main}. Nel caso di
+codice, dovrà essere invocata a partire dal codice di \code{main}. Nel caso di
funzioni definite nel programma occorre tenere conto che, nel momento stesso
in cui si usano le librerie di sistema (vale a dire la \acr{glibc}) alcuni
nomi sono riservati e non possono essere utilizzati.
\label{sec:proc_conclusion}
Normalmente un programma conclude la sua esecuzione quando si fa ritornare la
-funzione \func{main}, si usa cioè l'istruzione \instruction{return} del
+funzione \code{main}, si usa cioè l'istruzione \instruction{return} del
linguaggio C all'interno della stessa, o se si richiede esplicitamente la
chiusura invocando direttamente la funzione \func{exit}. Queste due modalità
sono assolutamente equivalenti, dato che \func{exit} viene chiamata in maniera
-trasparente anche quando \func{main} ritorna, passandogli come argomento il
+trasparente anche quando \code{main} ritorna, passandogli come argomento il
valore di ritorno (che essendo .
La funzione \funcd{exit}, che è completamente generale, essendo definita dallo
\itindbeg{exit~status}
-Il valore dell'argomento \param{status} o il valore di ritorno di \func{main},
+Il valore dell'argomento \param{status} o il valore di ritorno di \code{main},
costituisce quello che viene chiamato lo \textsl{stato di uscita}
(l'\textit{exit status}) del processo. In generale si usa questo valore per
fornire al processo padre (come vedremo in sez.~\ref{sec:proc_wait}) delle
informazioni generiche sulla riuscita o il fallimento del programma appena
terminato.
-Anche se l'argomento \param{status} (ed il valore di ritorno di \func{main})
+Anche se l'argomento \param{status} (ed il valore di ritorno di \code{main})
sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
dello stato di uscita viene comunque troncato ad 8 bit,
per cui deve essere sempre compreso fra 0 e 255. Si tenga presente che se si
-raggiunge la fine della funzione \func{main} senza ritornare esplicitamente si
+raggiunge la fine della funzione \code{main} senza ritornare esplicitamente si
ha un valore di uscita indefinito, è pertanto consigliabile di concludere
sempre in maniera esplicita detta funzione.
richiede che siano registrabili almeno \const{ATEXIT\_MAX} funzioni (il
valore può essere ottenuto con \func{sysconf}, vedi
sez.~\ref{sec:sys_sysconf}).} sia per la chiamata ad \func{exit} che per il
-ritorno di \func{main}. La prima funzione che si può utilizzare a tal fine è
+ritorno di \code{main}. La prima funzione che si può utilizzare a tal fine è
\funcd{atexit}, il cui prototipo è:
\begin{funcproto}{ \fhead{stdlib.h} \fdecl{void (*function)(void)}
volontariamente la propria esecuzione è attraverso una chiamata alla
\textit{system call} \func{\_exit}, sia che questa venga fatta esplicitamente,
o in maniera indiretta attraverso l'uso di \func{exit} o il ritorno di
-\func{main}.
+\code{main}.
Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
inizializzata.
Una volta che non sia più necessaria la memoria allocata dinamicamente deve
-essere esplicitamente rilasciata usando la funzione \func{free},\footnote{le
- glibc provvedono anche una funzione \func{cfree} definita per compatibilità
+essere esplicitamente rilasciata usando la funzione \funcd{free},\footnote{le
+ glibc provvedono anche una funzione \funcm{cfree} definita per compatibilità
con SunOS, che è deprecata.} il suo prototipo è:
\begin{funcproto}{
Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando
vengono lanciati e come accennato in sez.~\ref{sec:proc_main} questo viene
effettuato attraverso gli argomenti \param{argc} e \param{argv} ricevuti nella
-funzione \func{main} all'avvio del programma. Questi argomenti vengono passati
+funzione \code{main} all'avvio del programma. Questi argomenti vengono passati
al programma dalla shell o dal processo che esegue la \func{exec} (secondo le
modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo viene messo in
esecuzione.
\fhead{unistd.h}
\fdecl{int getopt(int argc, char * const argv[], const char *optstring)}
\fdesc{Esegue la scansione delle opzioni negli argomenti della funzione
- \func{main}.}
+ \code{main}.}
}
{Ritorna il carattere che segue l'opzione, ``\texttt{:}'' se manca un
parametro all'opzione, ``\texttt{?}'' se l'opzione è sconosciuta, e $-1$ se
\end{funcproto}
Questa funzione prende come argomenti le due variabili \param{argc} e
-\param{argv} che devono essere quelle passate come argomenti di \func{main}
+\param{argv} che devono essere quelle passate come argomenti di \code{main}
all'esecuzione del programma, ed una stringa \param{optstring} che indica
quali sono le opzioni valide. La funzione effettua la scansione della lista
degli argomenti ricercando ogni stringa che comincia con il carattere
\end{itemize*}
Una seconda funzione storica usata per la creazione di un nuovo processo è
-\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
+\funcm{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
semantica e gli stessi errori; la sola differenza è che non viene creata la
tabella delle pagine né la struttura dei task per il nuovo processo. Il
processo padre è posto in attesa fintanto che il figlio non ha eseguito una
Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
programma viene terminato in maniera normale: la chiamata di \func{exit}, che
esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
-esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente alla
+esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
direttamente alle operazioni di terminazione del processo da parte del kernel.
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
-valore di ritorno per \func{main}. Ma se il processo viene concluso in
+valore di ritorno per \code{main}. Ma se il processo viene concluso in
maniera anomala il programma non può specificare nessun \textit{exit status},
ed è il kernel che deve generare autonomamente il \textit{termination status}
per indicare le ragioni della conclusione anomala.
significativi dello stato di uscita del
processo (passato attraverso
\func{\_exit}, \func{exit} o come valore
- di ritorno di \func{main}); può essere
+ di ritorno di \code{main}); può essere
valutata solo se \val{WIFEXITED} ha
restituito un valore non nullo.\\
\macro{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
da \param{argv} e come ambiente la lista di stringhe indicata
da \param{envp}. Entrambe le liste devono essere terminate da un puntatore
nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal
-nuovo programma quando la sua funzione \func{main} è dichiarata nella forma
+nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
\code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
torneremo in sez.~\ref{sec:sys_res_limits}).
La prima differenza fra le funzioni riguarda le modalità di passaggio dei
valori che poi andranno a costituire gli argomenti a linea di comando (cioè i
-valori di \param{argv} e \param{argc} visti dalla funzione \func{main} del
+valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
e \textit{list}.
impostato ad 1. Una volta abilitato il \itindex{secure~computing~mode}
\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
+ \func{write}, \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system
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
tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
Per questo l'interfaccia per la creazione di un nuovo processo è stata
-delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di
-reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più
-che di nuovi processi si può parlare della creazioni di nuovi
+delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
+di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
+più che di nuovi processi si può parlare della creazioni di nuovi
``\textit{task}'' del kernel che possono assumere la veste sia di un processo
classico isolato dagli altri come quelli trattati finora, che di un
\textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
\end{basedescript}
+%TODO trattare unshare
+
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
poi porsi in attesa dell'immissione del nome di un utente.
Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
-il programma \cmd{login} con una \func{exevle}, passando come argomento la
+il programma \cmd{login} con una \func{execle}, 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 \envvar{TERM} per identificare il terminale su cui si
\textit{syslog} è anche il kernel, che a sua volta può avere necessità di
inviare messaggi verso l'\textit{user space}. I messaggi del kernel sono
mantenuti in un apposito buffer circolare e generati all'interno del kernel
-tramite la funzione \func{printk}, analoga alla \func{printf} usata in
+tramite la funzione \texttt{printk}, analoga alla \func{printf} usata in
\textit{user space}.\footnote{una trattazione eccellente dell'argomento si
trova nel quarto capitolo di \cite{LinDevDri}.}
\label{fig:printk_priority}
\end{figure}
-Dato che i messaggi generati da \func{printk} hanno un loro specifico formato
-tradizionalmente si usava un demone ausiliario, \cmd{klogd}, per leggerli,
-rimappare le priorità sui valori di tab.~\ref{tab:sess_syslog_priority} e
-inviarli al sistema del \textit{syslog} nella facility \const{LOG\_KERN}.
-Oggi i nuovi demoni più avanzati che realizzano il servizio (come
-\texttt{rsyslog} o \texttt{syslog-ng}) sono in grado di fare tutto questo da
-soli.
+Dato che i messaggi generati da \texttt{printk} hanno un loro specifico
+formato tradizionalmente si usava un demone ausiliario, \cmd{klogd}, per
+leggerli, rimappare le priorità sui valori di
+tab.~\ref{tab:sess_syslog_priority} e inviarli al sistema del \textit{syslog}
+nella facility \const{LOG\_KERN}. Oggi i nuovi demoni più avanzati che
+realizzano il servizio (come \texttt{rsyslog} o \texttt{syslog-ng}) sono in
+grado di fare tutto questo da soli.
Ma i messaggi del kernel non sono necessariamente connessi al sistema del
\textit{syslog}; ad esempio possono anche essere letti direttamente dal buffer
\item[\errcode{ERESTARTSYS}] l'operazione è stata interrotta da un segnale.
\item[\errcode{EPERM}] non si hanno i privilegi richiesti per l'operazione
richiesta.
- \item[\errcode{ENOSYS}] il supporto per \func{printk} non è stato compilato
+ \item[\errcode{ENOSYS}] il supporto per \texttt{printk} non è stato compilato
nel kernel.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{ENOSYS}.
% LocalWords: NOCTTY TIOCSCTTY error tcsetpgrp termios fd pgrpid descriptor VT
% LocalWords: ENOTTY ENOSYS EBADF SIGTTIN SIGTTOU EIO tcgetpgrp crypt SIGTSTP
% LocalWords: SIGINT SIGQUIT SIGTERM SIGHUP hungup kill orphaned SIGCONT exit
-% LocalWords: init Slackware run level inittab fig device getty exevle TERM at
+% LocalWords: init Slackware run level inittab fig device getty TERM at
% LocalWords: getpwnam chdir home chown chmod setuid setgid initgroups SIGCHLD
% LocalWords: daemon like daemons NdT Stevens Programming FAQ filesystem umask
% LocalWords: noclose syslog syslogd socket UDP klogd printk printf facility
\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
-chiamando \func{sysv\_signal}, una volta che si sia definita la macro
+chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro
\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
\func{signal}, che tra l'altro ha un comportamento indefinito in caso di
processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi
\func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill},
\func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir},
\func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe},
- \func{poll}, \func{posix\_trace\_event}, \func{pselect}, \func{raise},
+ \func{poll}, \funcm{posix\_trace\_event}, \func{pselect}, \func{raise},
\func{read}, \func{readlink}, \func{recv}, \func{recvfrom},
\func{recvmsg}, \func{rename}, \func{rmdir}, \func{select},
\func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto},
\func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset},
\func{sigdelset}, \func{sigemptyset}, \func{sigfillset},
\func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending},
- \func{sigprocmask}, \func{sigqueue}, \func{sigset}, \func{sigsuspend},
+ \func{sigprocmask}, \func{sigqueue}, \funcm{sigset}, \func{sigsuspend},
\func{sleep}, \func{socket}, \func{socketpair}, \func{stat},
\func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow},
\func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak},
fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico,
se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma
\var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da
-vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è
+vari meccanismi di notifica\footnote{un campo di tipo \type{sigval\_t} è
presente anche nella struttura \struct{sigevent} (definita in
fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica
come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O
predefinito e non modificabile (a meno di una ricompilazione delle librerie
stesse).}
-\itindbeg{Name~Service~Switch}
+\itindbeg{Name~Service~Switch~(NSS)}
Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
quelle che tratteremo nelle sezioni successive.
-\itindend{Name~Service~Switch}
+\itindend{Name~Service~Switch~(NSS)}
\subsection{Le funzioni di interrogazione del \textit{resolver}}
\noindent e come si può vedere la funzione è estremamente semplice, non
richiedendo nessun argomento.
+% TODO manca gethostent (e gethostent_r) e altro ? (vedi man page)
Infine si può richiedere la risoluzione inversa di un indirizzo IP od IPv6,
per ottenerne il nome a dominio ad esso associato, per fare questo si può
generale infatti ci sono una serie di funzioni nella forma
\texttt{getXXXbyname} e \texttt{getXXXbyaddr} (dove \texttt{XXX} indica il
servizio) per ciascuna delle informazioni di rete mantenute dal
-\itindex{Name~Service~Switch} \textit{Name Service Switch} che permettono
+\itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} che permettono
rispettivamente di trovare una corrispondenza cercando per nome o per numero.
L'elenco di queste funzioni è riportato nelle colonne finali di
al tipo di informazione che forniscono (riportato in prima colonna). Nella
tabella si è anche riportato il file su cui vengono ordinariamente mantenute
queste informazioni, che però può essere sostituito da un qualunque supporto
-interno al \itindex{Name~Service~Switch} \textit{Name Service Switch} (anche
-se usualmente questo avviene solo per la risoluzione degli indirizzi).
+interno al \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch}
+(anche se usualmente questo avviene solo per la risoluzione degli indirizzi).
Ciascuna funzione fa riferimento ad una sua apposita struttura che contiene i
relativi dati, riportata in terza colonna.
indirizzo &\conffile{/etc/hosts}&\struct{hostent}&\func{gethostbyname}&
\func{gethostbyaddr}\\
servizio &\conffile{/etc/services}&\struct{servent}&\func{getservbyname}&
- \func{getservbyaddr}\\
- rete &\conffile{/etc/networks}&\struct{netent}&\func{getnetbyname}&
- \func{getnetbyaddr}\\
+ \func{getservbyport}\\
+ rete &\conffile{/etc/networks}&\struct{netent}&\funcm{getnetbyname}&
+ \funcm{getnetbyaddr}\\
protocollo&\conffile{/etc/protocols}&\struct{protoent}&
- \func{getprotobyname}&\func{getprotobyaddr}\\
+ \funcm{getprotobyname}&\funcm{getprotobyaddr}\\
\hline
\end{tabular}
\caption{Funzioni di risoluzione dei nomi per i vari servizi del
- \itindex{Name~Service~Switch} \textit{Name Service Switch}.}
+ \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch}.}
\label{tab:name_resolution_functions}
\end{table}
finora soltanto quelle relative alla risoluzione dei nomi, dato che sono le
più usate, e prevedono praticamente da sempre la necessità di rivolgersi ad
una entità esterna; per le altre invece, estensioni fornite dal
-\itindex{Name~Service~Switch} NSS a parte, si fa sempre riferimento ai dati
-mantenuti nei rispettivi file.
+\itindex{Name~Service~Switch~(NSS)} NSS a parte, si fa sempre riferimento ai
+dati mantenuti nei rispettivi file.
Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
sui nomi dei servizi di rete più comuni (cioè \texttt{http}, \texttt{smtp},
ecc.) da associare alle rispettive porte. Le due funzioni da utilizzare per
-questo sono \funcd{getservbyname} e \funcd{getservbyaddr}, che permettono
+questo sono \funcd{getservbyname} e \funcd{getservbyport}, che permettono
rispettivamente di ottenere il numero di porta associato ad un servizio dato
il nome e viceversa; i loro prototipi sono:
\begin{functions}
specificato tramite la stringa \param{name}, mentre \func{getservbyport}
richiede il numero di porta in \param{port}. Entrambe le funzioni eseguono una
ricerca sul file \conffile{/etc/services}\footnote{il
- \itindex{Name~Service~Switch} \textit{Name Service Switch} astrae il
+ \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} astrae il
concetto a qualunque supporto su cui si possano mantenere i suddetti dati.}
ed estraggono i dati dalla prima riga che corrisponde agli argomenti
specificati; se la risoluzione ha successo viene restituito un puntatore ad
Oltre alle funzioni di ricerca esistono delle ulteriori funzioni che prevedono
una lettura sequenziale delle informazioni mantenute nel
-\itindex{Name~Service~Switch} \textit{Name Service Switch} (in sostanza
+\itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} (in sostanza
permettono di leggere i file contenenti le informazioni riga per riga), che
sono analoghe a quelle elencate in tab.~\ref{tab:sys_passwd_func} per le
informazioni relative ai dati degli utenti e dei gruppi. Nel caso specifico
aperto riporta la posizione di lettura alla prima voce del file, in questo
modo si può far ricominciare da capo una lettura sequenziale. L'argomento
\param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
-diverse chiamate a \func{getservbyname} e \func{getservbyaddr}.\footnote{di
+diverse chiamate a \func{getservbyname} e \func{getservbyport}.\footnote{di
default dopo una chiamata a queste funzioni il file viene chiuso, cosicché
una successiva chiamata a \func{getservent} riparte dall'inizio.} La terza
funzione, \funcd{endservent}, provvede semplicemente a chiudere il file.
\hline
indirizzo &\func{sethostent} &\func{gethostent} &\func{endhostent} \\
servizio &\func{setservent} &\func{getservent} &\func{endservent}\\
- rete &\func{setnetent} &\func{getnetent} &\func{endnetent}\\
- protocollo&\func{setprotoent}&\func{getprotoent}&\func{endprotoent}\\
+ rete &\funcm{setnetent} &\funcm{getnetent} &\funcm{endnetent}\\
+ protocollo&\funcm{setprotoent}&\funcm{getprotoent}&\funcm{endprotoent}\\
\hline
\end{tabular}
\caption{Funzioni lettura sequenziale dei dati del
- \itindex{Name~Service~Switch} \textit{Name Service Switch}.}
+ \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch}.}
\label{tab:name_sequential_read}
\end{table}
Come per i codici di errore di \func{gethostbyname} anche in questo caso è
fornita una apposita funzione, analoga di \func{strerror}, che consente di
utilizzarli direttamente per stampare a video un messaggio esplicativo; la
-funzione è \func{gai\_strerror} ed il suo prototipo è:
+funzione è \funcd{gai\_strerror} ed il suo prototipo è:
\begin{functions}
\headdecl{netdb.h}
Anche la nuova interfaccia definita da POSIX prevede una nuova funzione per
eseguire la risoluzione inversa e determinare nomi di servizi e di dominio
dati i rispettivi valori numerici. La funzione che sostituisce le varie
-\func{gethostbyname}, \func{getipnodebyname} e \func{getservname} è
+\func{gethostbyname}, \func{getipnodebyname} e \func{getservbyname} è
\funcd{getnameinfo}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/socket.h}
connessione al server, e quello in cui si specifica nel server un indirizzo
locale su cui porsi in ascolto.
-La prima funzione della nostra interfaccia semplificata è \func{sockconn} che
-permette di ottenere un socket, connesso all'indirizzo ed al servizio
+La prima funzione della nostra interfaccia semplificata è \texttt{sockconn}
+che permette di ottenere un socket, connesso all'indirizzo ed al servizio
specificati. Il corpo della funzione è riportato in
fig.~\ref{fig:sockconn_code}, il codice completo è nel file \file{SockUtil.c}
dei sorgenti allegati alla guida, che contiene varie funzioni di utilità per
\includecodesample{listati/sockconn.c}
\end{minipage}
\normalsize
- \caption{Il codice della funzione \func{sockconn}.}
+ \caption{Il codice della funzione \texttt{sockconn}.}
\label{fig:sockconn_code}
\end{figure}
avremo una semplificazione per cui il corpo principale del nostro client
diventerà quello illustrato in fig.~\ref{fig:TCP_echo_fifth}, in cui le
chiamate a \func{socket}, \func{inet\_pton} e \func{connect} sono sostituite
-da una singola chiamata a \func{sockconn}. Inoltre il nuovo client (il cui
+da una singola chiamata a \texttt{sockconn}. Inoltre il nuovo client (il cui
codice completo è nel file \file{TCP\_echo\_fifth.c} dei sorgenti allegati)
consente di utilizzare come argomento del programma un nome a dominio al posto
dell'indirizzo numerico, e può utilizzare sia indirizzi IPv4 che IPv6.
\includecodesample{listati/sockbind.c}
\end{minipage}
\normalsize
- \caption{Il codice della funzione \func{sockbind}.}
+ \caption{Il codice della funzione \texttt{sockbind}.}
\label{fig:sockbind_code}
\end{figure}
-La seconda funzione di ausilio è \func{sockbind}, il cui corpo principale è
+La seconda funzione di ausilio è \texttt{sockbind}, il cui corpo principale è
riportato in fig.~\ref{fig:sockbind_code} (al solito il sorgente completo è
nel file \file{sockbind.c} dei sorgenti allegati alla guida). Come si può
-notare la funzione è del tutto analoga alla precedente \func{sockconn}, e
+notare la funzione è del tutto analoga alla precedente \texttt{sockconn}, e
prende gli stessi argomenti, però invece di eseguire una connessione con
\func{connect} si limita a chiamare \func{bind} per collegare il socket ad una
porta.
del valore \const{AI\_PASSIVE} serve ad ottenere il valore generico nella
rispettiva struttura degli indirizzi.
-Come già detto la funzione è analoga a \func{sockconn} ed inizia azzerando ed
-inizializzando (\texttt{\small 6-11}) opportunamente la struttura \var{hint}
-con i valori ricevuti come argomenti, soltanto che in questo caso si è usata
-(\texttt{\small 8}) una impostazione specifica dei flag di \var{hint} usando
-\const{AI\_PASSIVE} per indicare che il socket sarà usato per una apertura
-passiva. Per il resto la chiamata (\texttt{\small 12-18}) a \func{getaddrinfo}
-e ed il ciclo principale (\texttt{\small 20--42}) sono identici, solo che si è
-sostituita (\texttt{\small 31}) la chiamata a \func{connect} con una chiamata
-a \func{bind}. Anche la conclusione (\texttt{\small 43--44}) della funzione è
-identica.
+Come già detto la funzione è analoga a \texttt{sockconn} ed inizia azzerando
+ed inizializzando (\texttt{\small 6-11}) opportunamente la struttura
+\var{hint} con i valori ricevuti come argomenti, soltanto che in questo caso
+si è usata (\texttt{\small 8}) una impostazione specifica dei flag di
+\var{hint} usando \const{AI\_PASSIVE} per indicare che il socket sarà usato
+per una apertura passiva. Per il resto la chiamata (\texttt{\small 12-18}) a
+\func{getaddrinfo} e ed il ciclo principale (\texttt{\small 20--42}) sono
+identici, solo che si è sostituita (\texttt{\small 31}) la chiamata a
+\func{connect} con una chiamata a \func{bind}. Anche la conclusione
+(\texttt{\small 43--44}) della funzione è identica.
Si noti come anche in questo caso si siano inserite le stampe degli errori
sullo standard error, nonostante la funzione possa essere invocata da un
server \textit{echo}, che rispetto a quanto illustrato nella versione iniziale
di fig.~\ref{fig:TCP_echo_server_first_code} viene modificato nella forma
riportata in fig.~\ref{fig:TCP_echod_third}. In questo caso il socket su cui
-porsi in ascolto viene ottenuto (\texttt{\small 15--18}) da \func{sockbind}
+porsi in ascolto viene ottenuto (\texttt{\small 15--18}) da \texttt{sockbind}
che si cura anche della eventuale risoluzione di un indirizzo specifico sul
quale si voglia far ascoltare il server.
finire fra quelli di una nuova.
Come esempio di uso di questa connessione abbiamo predisposto una nuova
-versione della funzione \func{sockbind} (vedi fig.~\ref{fig:sockbind_code})
+versione della funzione \texttt{sockbind} (vedi fig.~\ref{fig:sockbind_code})
che consenta l'impostazione di questa opzione. La nuova funzione è
-\func{sockbindopt}, e le principali differenze rispetto alla precedente sono
+\texttt{sockbindopt}, e le principali differenze rispetto alla precedente sono
illustrate in fig.~\ref{fig:sockbindopt_code}, dove si sono riportate le
sezioni di codice modificate rispetto alla versione precedente. Il codice
completo della funzione si trova, insieme alle altre funzioni di servizio dei
\includecodesample{listati/sockbindopt.c}
\end{minipage}
\normalsize
- \caption{Le sezioni della funzione \func{sockbindopt} modificate rispetto al
- codice della precedente \func{sockbind}.}
+ \caption{Le sezioni della funzione \texttt{sockbindopt} modificate rispetto al
+ codice della precedente \texttt{sockbind}.}
\label{fig:sockbindopt_code}
\end{figure}
\end{minipage}
\normalsize
\caption{Il nuovo codice per l'apertura passiva del server \textit{echo} che
- usa la nuova funzione \func{sockbindopt}.}
+ usa la nuova funzione \texttt{sockbindopt}.}
\label{fig:TCP_echod_fifth}
\end{figure}
\const{IP\_RECVERR} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Abilita la gestione degli errori.\\
\const{IP\_MTU\_DISCOVER} &$\bullet$&$\bullet$& &\texttt{int}&
- Imposta il Path MTU \itindex{Maximum~Transfer~Unit} Discovery.\\
+ Imposta il Path MTU \itindex{Maximum~Transfer~Unit~(MTU)} Discovery.\\
\const{IP\_MTU} &$\bullet$& & &\texttt{int}&
- Legge il valore attuale della \itindex{Maximum~Transfer~Unit} MTU.\\
+ Legge il valore attuale della \itindex{Maximum~Transfer~Unit~(MTU)} MTU.\\
\const{IP\_ROUTER\_ALERT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Imposta l'opzione \textit{IP router alert} sui pacchetti.\\
\const{IP\_MULTICAST\_TTL} &$\bullet$&$\bullet$& &\texttt{int}&
come valore logico e non è applicabile a socket di tipo
\const{SOCK\_STREAM}.
-\itindbeg{Maximum~Transfer~Unit}
+\itindbeg{Maximum~Transfer~Unit~(MTU)}
\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
della serie 2.2.x, ed è specifica di Linux. L'opzione permette di scrivere
o leggere le impostazioni della modalità usata per la determinazione della
ricerca è disabilitata ed è responsabilità del programma creare pacchetti di
dimensioni appropriate e ritrasmettere eventuali pacchetti persi. Se
l'opzione viene abilitata, il kernel si incaricherà di tenere traccia
- automaticamente della \itindex{Maximum~Transfer~Unit} \textit{Path MTU}
- verso ciascuna destinazione, e rifiuterà immediatamente la trasmissione di
- pacchetti di dimensioni maggiori della MTU con un errore di
- \errval{EMSGSIZE}.\footnote{in caso contrario la trasmissione del pacchetto
- sarebbe effettuata, ottenendo o un fallimento successivo della
- trasmissione, o la frammentazione dello stesso.}
+ automaticamente della \textit{Path MTU} verso ciascuna destinazione, e
+ rifiuterà immediatamente la trasmissione di pacchetti di dimensioni maggiori
+ della MTU con un errore di \errval{EMSGSIZE}.\footnote{in caso contrario la
+ trasmissione del pacchetto sarebbe effettuata, ottenendo o un fallimento
+ successivo della trasmissione, o la frammentazione dello stesso.}
\item[\const{IP\_MTU}] Permette di leggere il valore della \textit{Path MTU}
di percorso del socket. L'opzione richiede per \param{optval} un intero che
esplicitamente connesso con \func{connect}.
Ad esempio con i socket UDP si potrà ottenere una stima iniziale della
- \itindex{Maximum~Transfer~Unit} \textit{Path MTU} eseguendo prima una
- \func{connect} verso la destinazione, e poi usando \func{getsockopt} con
- questa opzione. Si può anche avviare esplicitamente il procedimento di
- scoperta inviando un pacchetto di grosse dimensioni (che verrà scartato) e
- ripetendo l'invio coi dati aggiornati. Si tenga infine conto che durante il
- procedimento i pacchetti iniziali possono essere perduti, ed è compito
- dell'applicazione gestirne una eventuale ritrasmissione.
+ \textit{Path MTU} eseguendo prima una \func{connect} verso la destinazione,
+ e poi usando \func{getsockopt} con questa opzione. Si può anche avviare
+ esplicitamente il procedimento di scoperta inviando un pacchetto di grosse
+ dimensioni (che verrà scartato) e ripetendo l'invio coi dati aggiornati. Si
+ tenga infine conto che durante il procedimento i pacchetti iniziali possono
+ essere perduti, ed è compito dell'applicazione gestirne una eventuale
+ ritrasmissione.
-\itindend{Maximum~Transfer~Unit}
+\itindend{Maximum~Transfer~Unit~(MTU)}
\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
kernel della serie 2.2.x, ed è specifica di Linux. Prende per
del \textit{multicast}, ed utilizza come \param{optval} le stesse strutture
\struct{ip\_mreqn} o \struct{ip\_mreq} delle due precedenti opzioni.
+% TODO chiarire quale è la struttura \struct{ip\_mreq}
+
+
\itindend{multicast}
\end{basedescript}
\const{TCP\_NODELAY} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Spedisce immediatamente i dati in segmenti singoli.\\
\const{TCP\_MAXSEG} &$\bullet$&$\bullet$& &\texttt{int}&
- Valore della \itindex{Maximum~Segment~Size} MSS per i segmenti in
+ Valore della \itindex{Maximum~Segment~Size~(MSS)} MSS per i segmenti in
uscita.\\
\const{TCP\_CORK} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Accumula i dati in un unico segmento.\\
kernel 2.5.71.}
\item[\const{TCP\_MAXSEG}] con questa opzione si legge o si imposta il valore
- della \itindex{Maximum~Segment~Size} MSS (\textit{Maximum~Segment~Size},
- vedi sez.~\ref{sec:net_lim_dim} e sez.~\ref{sec:tcp_protocol_xxx}) dei
- segmenti TCP uscenti. Se l'opzione è impostata prima di stabilire la
- connessione, si cambia anche il valore della \itindex{Maximum~Segment~Size}
- MSS annunciata all'altro capo della connessione. Se si specificano valori
- maggiori della \itindex{Maximum~Transfer~Unit} MTU questi verranno ignorati,
- inoltre TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
+ della \itindex{Maximum~Segment~Size~(MSS)} MSS
+ (\textit{Maximum~Segment~Size}, vedi sez.~\ref{sec:net_lim_dim} e
+ sez.~\ref{sec:tcp_protocol_xxx}) dei segmenti TCP uscenti. Se l'opzione è
+ impostata prima di stabilire la connessione, si cambia anche il valore della
+ \itindex{Maximum~Segment~Size~(MSS)} MSS annunciata all'altro capo della
+ connessione. Se si specificano valori maggiori della
+ \itindex{Maximum~Transfer~Unit~(MTU)} MTU questi verranno ignorati, inoltre
+ TCP imporrà anche i suoi limiti massimo e minimo per questo valore.
\item[\const{TCP\_CORK}] questa opzione è il complemento naturale di
\const{TCP\_NODELAY} e serve a gestire a livello applicativo la situazione
\struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
socket, questa operazione può essere utilizzata per effettuare delle
misurazioni precise del tempo di andata e ritorno\footnote{il
- \itindex{Round~Trip~Time} \textit{Round Trip Time} cui abbiamo già
+ \itindex{Round~Trip~Time~(RTT)} \textit{Round Trip Time} cui abbiamo già
accennato in sez.~\ref{sec:net_tcp}.} dei pacchetti sulla rete.
\item[\const{SIOCSPGRP}] imposta il processo o il \itindex{process~group}
non ancora implementato, restituisce un errore di \errval{EOPNOTSUPP}.
\item[\const{SIOCGIFMTU}] permette di leggere il valore della
- \itindex{Maximum~Transfer~Unit} \textit{Maximum Transfer Unit} del
+ \itindex{Maximum~Transfer~Unit~(MTU)} \textit{Maximum Transfer Unit} del
dispositivo nel campo \var{ifr\_mtu}.
\item[\const{SIOCSIFMTU}] permette di impostare il valore della
- \itindex{Maximum~Transfer~Unit} \textit{Maximum Transfer Unit} del
+ \itindex{Maximum~Transfer~Unit~(MTU)} \textit{Maximum Transfer Unit} del
dispositivo al valore specificato campo \var{ifr\_mtu}. L'operazione è
privilegiata, e si tenga presente che impostare un valore troppo basso può
causare un blocco del kernel.
\item[\sysctlrelfile{net/ipv4}{ip\_no\_pmtu\_disc}] permette di
disabilitare per i socket \const{SOCK\_STREAM} la ricerca automatica della
- \itindex{Maximum~Transfer~Unit} \textit{Path MTU} (vedi
+ \itindex{Maximum~Transfer~Unit~(MTU)} \textit{Path MTU} (vedi
sez.~\ref{sec:net_lim_dim} e sez.~\ref{sec:sock_ipv4_options}). Prende un
valore logico, e di default è disabilitato (cioè la ricerca viene eseguita).
In genere si abilita questo parametro quando per qualche motivo il
- procedimento del \itindex{Maximum~Transfer~Unit} \textit{Path MTU discovery}
- fallisce; dato che questo può avvenire a causa di router\footnote{ad
- esempio se si scartano tutti i pacchetti ICMP, il problema è affrontato
- anche in sez.~3.4.4 di \cite{SGL}.} o interfacce\footnote{ad esempio se i
- due capi di un collegamento \textit{point-to-point} non si accordano sulla
- stessa MTU.} mal configurati è opportuno correggere le configurazioni,
- perché disabilitare globalmente il procedimento con questo parametro ha
- pesanti ripercussioni in termini di prestazioni di rete.
+ procedimento del \itindex{Maximum~Transfer~Unit~(MTU)} \textit{Path MTU
+ discovery} fallisce; dato che questo può avvenire a causa di
+ router\footnote{ad esempio se si scartano tutti i pacchetti ICMP, il
+ problema è affrontato anche in sez.~3.4.4 di \cite{SGL}.} o
+ interfacce\footnote{ad esempio se i due capi di un collegamento
+ \textit{point-to-point} non si accordano sulla stessa MTU.} mal
+ configurati è opportuno correggere le configurazioni, perché disabilitare
+ globalmente il procedimento con questo parametro ha pesanti ripercussioni in
+ termini di prestazioni di rete.
\item[\sysctlrelfile{net/ipv4}{ip\_always\_defrag}] fa si che tutti i
pacchetti IP frammentati siano riassemblati, anche in caso in successivo
negativo. Il default è 2 che significa che al buffer dell'applicazione
viene riservato un quarto del totale.
-\item[\sysctlrelfile{net/ipv4}{tcp\_app\_win}] indica la frazione
- della finestra TCP che viene riservata per gestire l'overhaed dovuto alla
+\item[\sysctlrelfile{net/ipv4}{tcp\_app\_win}] indica la frazione della
+ finestra TCP che viene riservata per gestire l'overhaed dovuto alla
bufferizzazione. Prende un valore valore intero che consente di calcolare la
- dimensione in byte come il massimo fra la \itindex{Maximum~Segment~Size}
- MSS e $\texttt{window}/2^\texttt{tcp\_app\_win}$. Un valore nullo significa
- che non viene riservato nessuno spazio; il valore di default è 31.
+ dimensione in byte come il massimo fra la
+ \itindex{Maximum~Segment~Size~(MSS)} MSS e
+ $\texttt{window}/2^\texttt{tcp\_app\_win}$. Un valore nullo significa che
+ non viene riservato nessuno spazio; il valore di default è 31.
% vecchi, presumibilmente usati quando gli algoritmi di congestione non erano
% modularizzabili
% LocalWords: ERANGE sethostent stayopen endhostent gethostbyaddr order pton
% LocalWords: getipnodebyname getipnodebyaddr flags num MAPPED ALL ADDRCONFIG
% LocalWords: freehostent ip getXXXbyname getXXXbyaddr servent getservbyname
-% LocalWords: getservbyaddr netent getnetbyname getnetbyaddr protoent smtp udp
+% LocalWords: netent getnetbyname getnetbyaddr protoent smtp udp
% LocalWords: getprotobyname getprotobyaddr getservbyport port tcp setservent
% LocalWords: getservent endservent setXXXent getXXXent endXXXent gethostent
% LocalWords: setnetent getnetent endnetent setprotoent getprotoent POSIX RFC
informazioni degli utenti e dei gruppi per insiemi di macchine, in modo da
mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare
e memorizzare dette informazioni su supporti diversi, introducendo il sistema
-del \itindex{Name~Service~Switch} \textit{Name Service Switch} che tratteremo
-brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior
-parte delle sua applicazioni sono relative alla risoluzioni di nomi di rete.
+del \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} che
+tratteremo brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la
+maggior parte delle sua applicazioni sono relative alla risoluzioni di nomi di
+rete.
In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche
per la lettura delle informazioni relative a utenti e gruppi tralasciando
Le funzioni viste finora sono in grado di leggere le informazioni sia
direttamente dal file delle password in \conffile{/etc/passwd} che tramite il
-sistema del \itindex{Name~Service~Switch} \textit{Name Service Switch} e sono
-completamente generiche. Si noti però che non c'è una funzione che permetta di
-impostare direttamente una password.\footnote{in realtà questo può essere
- fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che POSIX non
-prevede questa possibilità esiste un'altra interfaccia che lo fa, derivata da
-SVID le cui funzioni sono riportate in tab.~\ref{tab:sys_passwd_func}. Questa
-però funziona soltanto quando le informazioni sono mantenute su un apposito
-file di \textsl{registro} di utenti e gruppi, con il formato classico di
-\conffile{/etc/passwd} e \conffile{/etc/group}.
+sistema del \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} e
+sono completamente generiche. Si noti però che non c'è una funzione che
+permetta di impostare direttamente una password.\footnote{in realtà questo può
+ essere fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che
+POSIX non prevede questa possibilità esiste un'altra interfaccia che lo fa,
+derivata da SVID le cui funzioni sono riportate in
+tab.~\ref{tab:sys_passwd_func}. Questa però funziona soltanto quando le
+informazioni sono mantenute su un apposito file di \textsl{registro} di utenti
+e gruppi, con il formato classico di \conffile{/etc/passwd} e
+\conffile{/etc/group}.
\begin{table}[htb]
\footnotesize
\textbf{Funzione} & \textbf{Significato}\\
\hline
\hline
- \func{fgetpwent} & Legge una voce dal file di registro degli utenti
+ \funcm{fgetpwent} & Legge una voce dal file di registro degli utenti
+ specificato.\\
+ \funcm{fgetpwent\_r}& Come la precedente, ma \index{funzioni!rientranti}
+ rientrante.\\
+ \funcm{putpwent} & Immette una voce in un file di registro degli
+ utenti.\\
+ \funcm{getpwent} & Legge una voce da \conffile{/etc/passwd}.\\
+ \funcm{getpwent\_r} & Come la precedente, ma \index{funzioni!rientranti}
+ rientrante.\\
+ \funcm{setpwent} & Ritorna all'inizio di \conffile{/etc/passwd}.\\
+ \funcm{endpwent} & Chiude \conffile{/etc/passwd}.\\
+ \funcm{fgetgrent} & Legge una voce dal file di registro dei gruppi
specificato.\\
- \func{fgetpwent\_r}& Come la precedente, ma \index{funzioni!rientranti}
- rientrante.\\
- \func{putpwent} & Immette una voce in un file di registro degli
- utenti.\\
- \func{getpwent} & Legge una voce da \conffile{/etc/passwd}.\\
- \func{getpwent\_r} & Come la precedente, ma \index{funzioni!rientranti}
- rientrante.\\
- \func{setpwent} & Ritorna all'inizio di \conffile{/etc/passwd}.\\
- \func{endpwent} & Chiude \conffile{/etc/passwd}.\\
- \func{fgetgrent} & Legge una voce dal file di registro dei gruppi
- specificato.\\
- \func{fgetgrent\_r}& Come la precedente, ma \index{funzioni!rientranti}
- rientrante.\\
- \func{putgrent} & Immette una voce in un file di registro dei gruppi.\\
- \func{getgrent} & Legge una voce da \conffile{/etc/group}.\\
- \func{getgrent\_r} & Come la precedente, ma \index{funzioni!rientranti}
- rientrante.\\
- \func{setgrent} & Ritorna all'inizio di \conffile{/etc/group}.\\
- \func{endgrent} & Chiude \conffile{/etc/group}.\\
+ \funcm{fgetgrent\_r}& Come la precedente, ma \index{funzioni!rientranti}
+ rientrante.\\
+ \funcm{putgrent} & Immette una voce in un file di registro dei gruppi.\\
+ \funcm{getgrent} & Legge una voce da \conffile{/etc/group}.\\
+ \funcm{getgrent\_r} & Come la precedente, ma \index{funzioni!rientranti}
+ rientrante.\\
+ \funcm{setgrent} & Ritorna all'inizio di \conffile{/etc/group}.\\
+ \funcm{endgrent} & Chiude \conffile{/etc/group}.\\
\hline
\end{tabular}
\caption{Funzioni per la manipolazione dei campi di un file usato come
Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende
inutili queste nuove strutture; pertanto esse e le relative funzioni di
-gestione (\func{getutxent}, \func{getutxid}, \func{getutxline},
-\func{pututxline}, \func{setutxent} e \func{endutxent}) sono ridefinite come
+gestione (\funcm{getutxent}, \funcm{getutxid}, \funcm{getutxline},
+\funcm{pututxline}, \funcm{setutxent} e \funcm{endutxent}) sono ridefinite come
sinonimi delle funzioni appena viste.
+% TODO (verificare le funzioni di cui sopra )
+
Come visto in sez.~\ref{sec:sys_user_group}, l'uso di strutture allocate
staticamente rende le funzioni di lettura non \index{funzioni!rientranti}
rientranti; per questo motivo le \acr{glibc} forniscono anche delle versioni
-\index{funzioni!rientranti} rientranti: \func{getutent\_r}, \func{getutid\_r},
-\func{getutline\_r}, che invece di restituire un puntatore restituiscono un
+\index{funzioni!rientranti} rientranti: \funcm{getutent\_r}, \funcm{getutid\_r},
+\funcm{getutline\_r}, che invece di restituire un puntatore restituiscono un
intero e prendono due argomenti aggiuntivi. Le funzioni si comportano
esattamente come le analoghe non \index{funzioni!rientranti} rientranti, solo
che restituiscono il risultato all'indirizzo specificato dal primo argomento
(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
-\func{strerror\_r}, il cui prototipo è:
+\funcd{strerror\_r}, il cui prototipo è:
\begin{prototype}{string.h}
{char * strerror\_r(int errnum, char *buf, size\_t size)}
gestione delle opzioni e tutte le definizioni necessarie ad associare il
valore numerico alla costante simbolica. In particolare si è riportata la
sezione che converte la stringa passata come argomento in un intero
-(\texttt{\small 1--2}), controllando con i valori di ritorno di \func{strtol}
+(\texttt{\small 1--2}), controllando con i valori di ritorno di \funcm{strtol}
che la conversione sia avvenuta correttamente (\texttt{\small 4--10}), e poi
stampa, a seconda dell'opzione scelta il messaggio di errore (\texttt{\small
11--14}) o la macro (\texttt{\small 15--17}) associate a quel codice.
connessione. Normalmente vengono usate le seguenti opzioni:
\begin{itemize}
-\item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
- \textit{Maximum Segment Size}, con questa opzione ciascun capo della
- connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
- accettare per ciascun segmento nella connessione corrente. È possibile
- leggere e scrivere questo valore attraverso l'opzione del socket
- \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}).
+\item \textit{MSS option}, dove MMS sta per
+ \itindex{Maximum~Segment~Size~(MSS)} \textit{Maximum Segment Size}, con
+ questa opzione ciascun capo della connessione annuncia all'altro il massimo
+ ammontare di dati che vorrebbe accettare per ciascun segmento nella
+ connessione corrente. È possibile leggere e scrivere questo valore
+ attraverso l'opzione del socket \const{TCP\_MAXSEG} (vedi
+ sez.~\ref{sec:sock_tcp_udp_options}).
\item \textit{window scale option}, il protocollo TCP implementa il controllo
di flusso attraverso una \itindex{advertised~window} \textit{advertised
\end{itemize}
-La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
-le implementazioni del protocollo, le ultime due opzioni (trattate
+La MSS \itindex{Maximum~Segment~Size~(MSS)} è generalmente supportata da quasi
+tutte le implementazioni del protocollo, le ultime due opzioni (trattate
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
vengono anche dette \textit{long fat pipe options} dato che questo è il nome
che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
\end{figure}
La connessione viene iniziata dal client che annuncia una
-\itindex{Maximum~Segment~Size} MSS di 1460, un valore tipico con Linux per
-IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe essere
-anche un valore diverso).
+\itindex{Maximum~Segment~Size~(MSS)} MSS di 1460, un valore tipico con Linux
+per IPv4 su Ethernet, il server risponde con lo stesso valore (ma potrebbe
+essere anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
di processo, questo tempo è quello impiegato nella trasmissione via rete, che
-viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time}
+viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time~(RTT)}
\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
\cmd{ping}.
\label{fig:TCP_header}
\end{figure}
-\itindbeg{Maximum~Segment~Size|(}
+\itindbeg{Maximum~Segment~Size~(MSS)}
% TODO trattare la MSS
-\itindend{Maximum~Segment~Size|)}
+\itindend{Maximum~Segment~Size~(MSS)}
-\itindbeg{advertised~window|(}
+\itindbeg{advertised~window}
% TODO trattare la advertised window
-\itindend{advertised~window|)}
+\itindend{advertised~window}
projects / gapil.git / commitdiff