OPTnote = {},
OPTannote = {}
}
-@Book{glibc,
+@Book{GlibcMan,
author = {Sandra Loosemore, Richard M. Stallman, Roland McGrath, Andrew Oram and Ulrich Drepper},
editor = {Free Software Foundation},
title = {The GNU C Library Reference Manual},
In presenza di dati invece il programma proseguirà l'esecuzione stampando
(\texttt{\small 19--20}) il nome del segnale ottenuto all'interno della
-struttura \const{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
+struttura \struct{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
stampa si è usato il vettore \var{sig\_names} a ciascun elemento del quale
corrisponde il nome del segnale avente il numero corrispondente, la cui
definizione si è omessa dal codice di fig.~\ref{fig:fiforeporter_code_init}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{BUSY}] \param{target} è la \index{directory~di~lavoro}
+ \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
directory di lavoro di qualche processo, o contiene dei file aperti, o un
altro mount point.
\item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
due, si marca il \itindex{mount~point} \textit{mount point} di un filesystem
non occupato come ``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna
con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si
-sarebbe ricevuto \errcode{BUSY}. Una volta marcato, se nel frattempo non
+sarebbe ricevuto \errcode{EBUSY}. Una volta marcato, se nel frattempo non
viene fatto nessun uso del filesystem, ad una successiva chiamata con
\const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare
un meccanismo che smonti automaticamente i filesystem che restano inutilizzati
misura di sicurezza introdotta per evitare, per quei filesystem per il quale è
prevista una gestione diretta da parte degli utenti, come quelli basati su
FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
- interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
- di implementare le funzioni del \textit{Virtual File System} in user space,
- così da rendere possibile agli utenti l'implementazione di un loro filesytem
- qualunque (con applicazioni di grande interesse come il filesystem cifrato
- \textit{encfs} o il filesystem di rete \textit{sshfs}).} che si possano
-passare ai programmi che effettuano lo smontaggio dei filesystem, che in
-genere sono privilegiati ma consentono di agire solo sui propri \textit{mount
- point}, dei link simbolici che puntano ad altri \textit{mount point},
-ottenendo così la possibilità di smontare qualunque filesystem.
+ interessanti applicazioni del \itindex{Virtual~File~System} VFS che
+ consente, tramite un opportuno modulo, di implementarne le funzioni in
+ \textit{user space}, così da rendere possibile l'implementazione di un
+ qualunque filesytem (con applicazioni di grande interesse come il filesystem
+ cifrato \textit{encfs} o il filesystem di rete \textit{sshfs}) che possa
+ essere usato direttamente per conto degli utenti.} che si possano passare
+ai programmi che effettuano lo smontaggio dei filesystem, che in genere sono
+privilegiati ma consentono di agire solo sui propri \textit{mount point}, dei
+link simbolici che puntano ad altri \textit{mount point}, ottenendo così la
+possibilità di smontare qualunque filesystem.
Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
\end{figure}
Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
-file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono
-usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le
-informazioni riguardo ai filesystem da montare e a quelli correntemente
-montati. Le funzioni servono a leggere il contenuto di questi file in
-opportune strutture \struct{fstab} e \struct{mntent}, e, nel caso di
-\conffile{/etc/mtab}, per inserire e rimuovere le voci presenti nel file.
+file \conffile{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
+ \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
+ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
+ \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
+ \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
+sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
+filesystem da montare e a quelli correntemente montati. Le funzioni servono a
+leggere il contenuto di questi file in opportune strutture \struct{fstab} e
+\struct{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e rimuovere
+le voci presenti nel file.
In generale si dovrebbero usare queste funzioni, in particolare quelle
relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
aggiornato correttamente (cosa che è impossibile se la radice è montata in
sola lettura) il suo contenuto diventa fuorviante.
-Pe questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
+Per questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
oggi sostituito da un link simbolico a \procfile{/proc/mounts}, che contiene
una versione degli stessi contenuti (vale a dire l'elenco dei filesystem
montati) generata direttamente dal kernel, e quindi sempre disponibile e
sempre aggiornata. Per questo motivo tralasceremo la trattazione, di queste
-funzioni, rimandando al manuale delle \acr{glibc} \cite{glibc} per la
+funzioni, rimandando al manuale delle \acr{glibc} \cite{GlibcMan} per la
documentazione completa.
% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
% TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...)
+
\section{La gestione di file e directory}
\label{sec:file_dir}
\label{fig:ipc_msqid_ds}
\end{figure}
-A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
+A ciascuna coda è associata una struttura \struct{msqid\_ds}, la cui
definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura
il kernel mantiene le principali informazioni riguardo lo stato corrente della
coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
attivare un meccanismo di ripristino attraverso l'uso del flag
\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
-\struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
+\kstruct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
strutture disallocate. Per mantenere coerente il comportamento queste
strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
immediatamente, dopo di che il kernel esegue una scansione della coda di
attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
operazioni sospese in precedenza può essere eseguita, nel qual caso la
-struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
+struttura \kstruct{sem\_queue} viene rimossa e lo stato del processo associato
all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
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
un'altra funzione, per cui se l'errore avviene in una funzione, e la sua
gestione ordinaria è in un'altra, occorre usare quello che viene chiamato un
\textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
-citato sia in \cite{APUE} che in \cite{glibc}, è quello di un programma nel
+citato sia in \cite{APUE} che in \cite{GlibcMan}, è quello di un programma nel
cui corpo principale vengono letti dei dati in ingresso sui quali viene
eseguita, tramite una serie di funzioni di analisi, una scansione dei
contenuti, da cui si ottengono le indicazioni per l'esecuzione di opportune
all'indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi
successive. Questo comporterebbe una notevole complessità, mentre sarebbe
molto più comodo poter tornare direttamente al ciclo di lettura principale,
-scartando l'input come errato.\footnote{a meno che, come precisa \cite{glibc},
- alla chiusura di ciascuna fase non siano associate operazioni di pulizia
- specifiche (come deallocazioni, chiusure di file, ecc.), che non potrebbero
- essere eseguite con un salto non-locale.}
+scartando l'input come errato.\footnote{a meno che, come precisa
+ \cite{GlibcMan}, alla chiusura di ciascuna fase non siano associate
+ operazioni di pulizia specifiche (come deallocazioni, chiusure di file,
+ ecc.), che non potrebbero essere eseguite con un salto non-locale.}
Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
norma viene realizzato salvando il contesto dello \itindex{stack}
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
-\itindex{side!effects} \textit{side effects}).\footnote{nel linguaggio C si
+\itindex{side~effects} \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
caso indicato in cui si passa una funzione ad una macro che usa l'argomento
socket permette di scegliere lo stile di comunicazione indicando il tipo di
socket con l'argomento \param{type} di \func{socket}. Linux mette a
disposizione vari tipi di socket (che corrispondono a quelli che il manuale
-della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
+della \acr{glibc} \cite{GlibcMan} chiama \textit{styles}) identificati dalle
seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
tre tipi, Linux supporta anche gli altri, come si può verificare nel file
\texttt{include/linux/net.h} dei sorgenti del kernel.}
una lettura approfondita del meccanismo descritto nell'RFC~1305, ci limitiamo
a descrivere in tab.~\ref{tab:sys_timex_mode} i principali valori utilizzabili
per il campo \var{mode}, un elenco più dettagliato del significato dei vari
-campi della struttura \struct{timex} può essere ritrovato in \cite{glibc}.
+campi della struttura \struct{timex} può essere ritrovato in \cite{GlibcMan}.
\begin{table}[!htb]
\footnotesize
projects / gapil.git / commitdiff