% NOTE articolo interessante:
% http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
-\itindbeg{Virtual~File~System}
+\itindbeg{Virtual~File~System~(VFS)}
Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
concetto di \textit{everything is a file} è stato implementato attraverso il
sez.~\ref{sec:file_dir_creat_rem}).\\
\textsl{\code{rmdir}} & Rimuove una directory (vedi
sez.~\ref{sec:file_dir_creat_rem}).\\
- \textsl{\code{mknod}} & Crea un \index{file!speciali} file speciale (vedi
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
sez.~\ref{sec:file_mknod}).\\
\textsl{\code{rename}} & Cambia il nome di un file (vedi
sez.~\ref{sec:link_symlink_rename}).\\
possono esserci negli oggetti a cui si applicano.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
% NOTE: documentazione interessante:
% * sorgenti del kernel: Documentation/filesystems/vfs.txt
indicati con la stringa contenente il loro \textit{pathname}.
Normalmente un filesystem è contenuto su un disco o una partizione, ma come
-illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
-\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente
-flessibile e può essere usata anche per oggetti diversi da un disco. Ad
-esempio usando il \textit{loop device} si può montare un file qualunque (come
-l'immagine di un CD-ROM o di un floppy) che contiene l'immagine di un
-filesystem, inoltre alcuni tipi di filesystem, come \texttt{proc} o
-\texttt{sysfs} sono virtuali e non hanno un supporto che ne contenga i dati,
-che invece sono generati al volo ad ogni lettura, e passati indietro al kernel
-ad ogni scrittura.\footnote{costituiscono quindi un meccanismo di
- comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel.}
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del \textit{Virtual
+ File System} è estremamente flessibile e può essere usata anche per oggetti
+diversi da un disco. Ad esempio usando il \textit{loop device} si può montare
+un file qualunque (come l'immagine di un CD-ROM o di un floppy) che contiene
+l'immagine di un filesystem, inoltre alcuni tipi di filesystem, come
+\texttt{proc} o \texttt{sysfs} sono virtuali e non hanno un supporto che ne
+contenga i dati, che invece sono generati al volo ad ogni lettura, e passati
+indietro al kernel ad ogni scrittura.\footnote{costituiscono quindi un
+ meccanismo di comunicazione, attraverso l'ordinaria interfaccia dei file,
+ con il kernel.}
Il tipo di filesystem che si vuole montare è specificato
dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
della serie 2.2.x i 16 più significativi avevano un valore riservato che
doveva essere specificato obbligatoriamente,\footnote{il valore era il
- \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
- costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
- riservata al \textit{magic number}, mentre per specificarlo si può dare un
- OR aritmetico con la costante \const{MS\_MGC\_VAL}.} e si potevano usare
-solo i 16 meno significativi. Oggi invece, con un numero di opzioni superiore,
-sono utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia
-presente detto valore, che non esprime una combinazione valida, esso viene
-ignorato. Il valore dell'argomento deve essere espresso come maschera binaria
-e i vari bit che lo compongono, detti anche \textit{mount flags}, devono
-essere impostati con un OR aritmetico dei valori dalle costanti riportate
-nell'elenco seguente:
+ \textit{magic number} \code{0xC0ED}, si può usare la costante
+ \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
+ al \textit{magic number}, mentre per specificarlo si può dare un OR
+ aritmetico con la costante \const{MS\_MGC\_VAL}.} e si potevano usare solo i
+16 meno significativi. Oggi invece, con un numero di opzioni superiore, sono
+utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia presente
+detto valore, che non esprime una combinazione valida, esso viene ignorato. Il
+valore dell'argomento deve essere espresso come maschera binaria e i vari bit
+che lo compongono, detti anche \textit{mount flags}, devono essere impostati
+con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\itindbeg{bind~mount}
nell'altro, visto che entrambi faranno riferimento agli stessi
\textit{inode}.
- Dal punto di vista del \itindex{Virtual~File~System} VFS l'operazione è
- analoga al montaggio di un filesystem proprio nel fatto che anche in questo
- caso si inserisce in corrispondenza della \textit{dentry} di \texttt{target}
- un diverso \itindex{inode} \textit{inode}, che stavolta, invece di essere
- quello della radice del filesystem indicato da un file di dispositivo, è
- quello di una directory già montata.
+ Dal punto di vista del VFS l'operazione è analoga al montaggio di un
+ filesystem proprio nel fatto che anche in questo caso si inserisce in
+ corrispondenza della \textit{dentry} di \texttt{target} un diverso
+ \itindex{inode} \textit{inode}, che stavolta, invece di essere quello della
+ radice del filesystem indicato da un file di dispositivo, è quello di una
+ directory già montata.
Si tenga presente che proprio per questo sotto \param{target} comparirà il
contenuto che è presente sotto \param{source} all'interno del filesystem in
sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
che è stato montato per ultimo. Si tenga presente che la funzione fallisce se
il filesystem è ``\textsl{occupato}'', cioè quando ci sono ancora dei file
-aperti sul filesystem, se questo contiene la \index{directory~di~lavoro}
-directory di lavoro di un qualunque processo o il \itindex{mount~point}
-\textit{mount point} di un altro filesystem.
+aperti sul filesystem, se questo contiene la directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il
+\itindex{mount~point} \textit{mount point} di un altro filesystem.
Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
consente un maggior controllo delle operazioni, come forzare lo smontaggio di
\begin{errlist}
\item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
ed il filesystem non era occupato.
- \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{EINVAL}] \param{target} non è un \itindex{mount~point}
- \textit{mount point} o si è usato \const{MNT\_EXPIRE} con
- \const{MNT\_FORCE} o \const{MNT\_DETACH} o si è specificato un flag non
- esistente.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro \textit{mount point}.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
+ è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
+ \const{MNT\_DETACH} o si è specificato un flag non esistente.
\end{errlist}
e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
\end{funcproto}
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 \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 filesystem (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 collegamenti simbolici che puntano ad altri \textit{mount
- point}, ottenendo così la possibilità di smontare qualunque filesystem.
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementarne le funzioni in \textit{user space}, così da rendere
+ possibile l'implementazione di un qualunque filesystem (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 collegamenti simbolici che puntano ad
+altri \textit{mount point}, ottenendo così la possibilità di smontare
+qualunque filesystem.
Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
directory che lo contiene e decrementa il numero di riferimenti nel relativo
\itindex{inode} \textit{inode}.\footnote{come per \func{link} queste due
operazioni sono effettuate all'interno della \textit{system call} in maniera
- atomica.} Nel caso di socket, fifo o file di dispositivo
-\index{file!di~dispositivo} rimuove il nome, ma come per i file normali i
-processi che hanno aperto uno di questi oggetti possono continuare ad
-utilizzarli. Nel caso di cancellazione di un collegamento simbolico, che
-consiste solo nel rimando ad un altro file, questo viene immediatamente
-eliminato.
+ atomica.} Nel caso di socket, fifo o file di dispositivo rimuove il nome, ma
+come per i file normali i processi che hanno aperto uno di questi oggetti
+possono continuare ad utilizzarli. Nel caso di cancellazione di un
+collegamento simbolico, che consiste solo nel rimando ad un altro file, questo
+viene immediatamente eliminato.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
se questa è una directory.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
- parte di qualche processo (come \index{directory~di~lavoro} directory di
- lavoro o come radice) o del sistema (come \itindex{mount~point}
- \textit{mount point}) ed il sistema non riesce a risolvere la situazione.
+ parte di qualche processo (come directory di lavoro o come radice) o del
+ sistema (come \textit{mount point}) ed il sistema non riesce a risolvere
+ la situazione.
\item[\errcode{EEXIST}] \param{newpath} è una directory già esistente e
non è vuota (anche \errcode{ENOTEMPTY}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
non è possibile trattarle come file ordinari e devono essere create
direttamente dal kernel attraverso una opportuna \textit{system
call}.\footnote{questo è quello che permette anche, attraverso l'uso del
- \itindex{Virtual~File~System} VFS, l'utilizzo di diversi formati per la
- gestione dei suddetti elenchi, dalle semplici liste a strutture complesse
- come alberi binari, hash, ecc. che consentono una ricerca veloce quando il
- numero di file è molto grande.} La funzione di sistema usata per creare una
-directory è \funcd{mkdir}, ed il suo prototipo è:
+ VFS, l'utilizzo di diversi formati per la gestione dei suddetti elenchi,
+ dalle semplici liste a strutture complesse come alberi binari, hash,
+ ecc. che consentono una ricerca veloce quando il numero di file è molto
+ grande.} La funzione di sistema usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/stat.h}
che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la
- \index{directory~di~lavoro} directory di lavoro o la radice di qualche
- processo o un \itindex{mount~point} \textit{mount point}.
+ \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o
+ la radice di qualche processo o un \textit{mount point}.
\item[\errcode{EINVAL}] si è usato ``\texttt{.}'' come ultimo componente
di \param{dirname}.
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
fosse un file, anche se solo in sola lettura) in generale il formato con cui
esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
-riportato in tab.~\ref{tab:file_file_operations}, il
-\itindex{Virtual~File~System} VFS prevede una apposita funzione per la lettura
-delle directory.
+riportato in tab.~\ref{tab:file_file_operations}, il VFS prevede una apposita
+funzione per la lettura delle directory.
\itindbeg{directory~stream}
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
+spostare su di essa la directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
una struttura allocata staticamente, che viene sovrascritta tutte le volte che
si ripete la lettura di una voce sullo stesso \textit{directory stream}.
-Di questa funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \funcd{readdir\_r},\footnote{per usarla è necessario definire una
- qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
+Di questa funzione esiste anche una versione 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
può essere utilizzata anche con i \itindex{thread} \textit{thread}, il suo
18-22}) uno \textit{stream} sulla directory passata come primo argomento,
stampando un messaggio in caso di errore.
-Il passo successivo (\texttt{\small 23-24}) è cambiare
-\index{directory~di~lavoro} directory di lavoro (vedi
-sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
-\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
-\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
- 26-30}) sulle singole voci dello \textit{stream} ci si trovi all'interno
-della directory.\footnote{questo è essenziale al funzionamento della funzione
- \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
- quanto i nomi dei file memorizzati all'interno di una struttura
- \struct{dirent} sono sempre relativi alla directory in questione, e senza
- questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
- le dimensioni.}
+Il passo successivo (\texttt{\small 23-24}) è cambiare directory di lavoro
+(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
+\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
+\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
+(\texttt{\small 26-30}) sulle singole voci dello \textit{stream} ci si trovi
+all'interno della directory.\footnote{questo è essenziale al funzionamento
+ della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
+ \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
+ struttura \struct{dirent} sono sempre relativi alla directory in questione,
+ e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
+ ottenere le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
\headfile{stdio.h}.}
-Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
+Di questa funzione esiste una versione \ rientrante,
\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 è:
\end{funcproto}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+per cui è sempre \ rientrante, occorre però
ricordarsi di disallocare con \code{free} il puntatore che restituisce.
L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
nome provvisorio. La funzione assegna come directory per il file temporaneo,
che viene automaticamente cancellato alla sua chiusura o all'uscita dal
programma. Lo standard non specifica in quale directory verrà aperto il file,
ma la \acr{glibc} prima tenta con \const{P\_tmpdir} e poi con
-\file{/tmp}. Questa funzione è \index{funzioni!rientranti} rientrante e non
-soffre di problemi di \itindex{race~condition} \textit{race condition}.
+\file{/tmp}. Questa funzione è rientrante e non soffre di problemi di
+\itindex{race~condition} \textit{race condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
anche alla chiamata di \func{utime}. Questo serve anche come misura di
sicurezza per evitare che si possa modificare un file nascondendo
completamente le proprie tracce. In realtà la cosa resta possibile se si è in
-grado di accedere al \index{file!di~dispositivo} file di dispositivo,
-scrivendo direttamente sul disco senza passare attraverso il filesystem, ma
-ovviamente in questo modo la cosa è più complicata da
-realizzare.\footnote{esistono comunque molti programmi che consentono di farlo
- con relativa semplicità per cui non si dia per scontato che il valore sia
- credibile in caso di macchina compromessa.}
+grado di accedere al file di dispositivo, scrivendo direttamente sul disco
+senza passare attraverso il filesystem, ma ovviamente in questo modo la cosa è
+più complicata da realizzare.\footnote{esistono comunque molti programmi che
+ consentono di farlo con relativa semplicità per cui non si dia per scontato
+ che il valore sia credibile in caso di macchina compromessa.}
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
notazione illustrata in fig.~\ref{fig:file_perm_bit}.
Si ricordi infine che i permessi non hanno alcun significato per i
-collegamenti simbolici, mentre per i \index{file!di~dispositivo} file di
-dispositivo hanno senso soltanto i permessi di lettura e scrittura, che si
-riflettono sulla possibilità di compiere dette operazioni sul dispositivo
-stesso.
+collegamenti simbolici, mentre per i file di dispositivo hanno senso soltanto
+i permessi di lettura e scrittura, che si riflettono sulla possibilità di
+compiere dette operazioni sul dispositivo stesso.
Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
bit in questione non è influente rispetto a quanto indicato nella riga della
directory ordinarie, se valesse in generale infatti si avrebbe un serio
problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
quali è normale avere avere il permesso di scrittura consentito a tutti gli
- utenti, come i collegamenti simbolici, o alcuni \index{file!di~dispositivo}
- file di dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di
- essi gli \textit{extended user attributes} un utente qualunque potrebbe
- inserirvi dati a piacere.\footnote{la cosa è stata notata su XFS, dove
- questo comportamento permetteva, non essendovi limiti sullo spazio
- occupabile dagli \textit{Extended Attributes}, di bloccare il sistema
- riempiendo il disco.}
+ utenti, come i collegamenti simbolici, o alcuni file di dispositivo come
+ \texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
+ user attributes} un utente qualunque potrebbe inserirvi dati a
+ piacere.\footnote{la cosa è stata notata su XFS, dove questo comportamento
+ permetteva, non essendovi limiti sullo spazio occupabile dagli
+ \textit{Extended Attributes}, di bloccare il sistema riempiendo il disco.}
La semantica del controllo di accesso indicata inoltre non avrebbe alcun
senso al di fuori di file e directory: i permessi di lettura e scrittura per
- un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
- di accesso al dispositivo sottostante,\footnote{motivo per cui si può
- formattare un disco anche se \texttt{/dev} è su un filesystem in sola
- lettura.} mentre per i collegamenti simbolici questi vengono semplicemente
- ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
- file, e nella discussione relativa all'uso degli \textit{extended user
- attributes} nessuno è mai stato capace di indicare una qualche forma
- sensata di utilizzo degli stessi per collegamenti simbolici o
- \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
+ un file di dispositivo attengono alle capacità di accesso al dispositivo
+ sottostante,\footnote{motivo per cui si può formattare un disco anche se
+ \texttt{/dev} è su un filesystem in sola lettura.} mentre per i
+ collegamenti simbolici questi vengono semplicemente ignorati: in nessuno dei
+ due casi hanno a che fare con il contenuto del file, e nella discussione
+ relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
+ capace di indicare una qualche forma sensata di utilizzo degli stessi per
+ collegamenti simbolici o file di dispositivo, e neanche per le fifo o i
socket. Per questo motivo essi sono stati completamente disabilitati per
tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
\textit{immutable} e \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di
- dispositivo con \func{mknod} (vedi
+ \const{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
\const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
privilegiate sulla rete.\\
questa sezione.
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 \kstruct{fs\_struct}; vedi
- fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
-alla radice dell'albero dei file dell'intero sistema, ha per il processo il
-significato specifico di directory rispetto alla quale vengono risolti i
-\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
- un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
- sempre questa directory come punto di partenza.} Il fatto che questo valore
-sia specificato per ogni processo apre allora la possibilità di modificare le
-modalità di risoluzione dei \itindsub{pathname}{assoluto} \textit{pathname}
-assoluti da parte di un processo cambiando questa directory, così come si fa
-coi \itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
-\index{directory~di~lavoro} 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
+ \kstruct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur
+essendo di norma corrispondente alla radice dell'albero dei file dell'intero
+sistema, ha per il processo il significato specifico di directory rispetto
+alla quale vengono risolti i \itindsub{pathname}{assoluto}\textit{pathname}
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+ \textit{pathname}, il kernel usa sempre questa directory come punto di
+ partenza.} Il fatto che questo valore sia specificato per ogni processo apre
+allora la possibilità di modificare le modalità di risoluzione dei
+\itindsub{pathname}{assoluto} \textit{pathname} assoluti da parte di un
+processo cambiando questa directory, così come si fa coi
+\itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
+directory di lavoro.
Normalmente la directory radice di un processo coincide con la radice generica
dell'albero dei file, che è la directory che viene montata direttamente dal
Questo è il motivo per cui la funzione è efficace nel restringere un processo
ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
amministratore. Infatti se per un qualunque motivo il processo resta con la
-sua \index{directory~di~lavoro} directory di lavoro al di fuori dalla
-\textit{chroot jail}, potrà accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo} dei \textit{pathname} relativi, dato che in tal
-caso è possibile, grazie all'uso di ``\texttt{..}'', risalire all'indietro
-fino alla radice effettiva dell'albero dei file.
+sua directory di lavoro al di fuori dalla \textit{chroot jail}, potrà accedere
+a tutto il resto del filesystem usando \itindsub{pathname}{relativo} dei
+\textit{pathname} relativi, dato che in tal caso è possibile, grazie all'uso
+di ``\texttt{..}'', risalire all'indietro fino alla radice effettiva
+dell'albero dei file.
Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
eseguire preventivamente anche una \func{chdir} sulla directory su cui si
andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
lavoro sia all'interno della \textit{chroot jail}. Ma se ad un processo
restano i privilegi di amministratore esso potrà comunque portare la sua
-\index{directory~di~lavoro} directory di lavoro fuori dalla \textit{chroot
- jail} in cui si trova. Basterà infatti eseguire di nuovo \func{chroot} su
-una qualunque directory contenuta nell'attuale directory di lavoro perché
-quest'ultima risulti al di fuori della nuova \textit{chroot jail}. Per questo
-motivo l'uso di questa funzione non ha molto senso quando un processo di cui
-si vuole limitare l'accesso necessita comunque dei privilegi di amministratore
-per le sue normali operazioni.
+directory di lavoro fuori dalla \textit{chroot jail} in cui si trova. Basterà
+infatti eseguire di nuovo \func{chroot} su una qualunque directory contenuta
+nell'attuale directory di lavoro perché quest'ultima risulti al di fuori della
+nuova \textit{chroot jail}. Per questo motivo l'uso di questa funzione non ha
+molto senso quando un processo di cui si vuole limitare l'accesso necessita
+comunque dei privilegi di amministratore per le sue normali operazioni.
Nonostante queste limitazioni la funzione risulta utile qualora la si possa
applicare correttamente cedendo completamente i privilegi di amministratore
Come visto in sez.~\ref{sec:file_vfs_work} il kernel mette a disposizione
-tramite il \itindex{Virtual~File~System} \textit{Virtual File System} una
-serie di \textit{system call} che consentono di operare sui file in maniera
-generale. Abbiamo trattato quelle relative alla gestione delle proprietà dei
-file nel precedente capitolo, vedremo quelle che si applicano al contenuto dei
-file in questa sezione, iniziando con una breve introduzione sull'architettura
-dei \textit{file descriptor} per poi trattare le funzioni di base e le
-modalità con cui consentono di gestire i dati memorizzati sui file.
+tramite il \textit{Virtual File System} una serie di \textit{system call} che
+consentono di operare sui file in maniera generale. Abbiamo trattato quelle
+relative alla gestione delle proprietà dei file nel precedente capitolo,
+vedremo quelle che si applicano al contenuto dei file in questa sezione,
+iniziando con una breve introduzione sull'architettura dei \textit{file
+ descriptor} per poi trattare le funzioni di base e le modalità con cui
+consentono di gestire i dati memorizzati sui file.
\subsection{I \textit{file descriptor}}
fa aprendo il file con la funzione \func{open} (vedi
sez.~\ref{sec:file_open_close}) che provvederà a localizzare \itindex{inode}
l'\textit{inode} del file e inizializzare i puntatori che rendono disponibili
-le funzioni che il \itindex{Virtual~File~System} VFS mette a disposizione
-(quelle di tab.~\ref{tab:file_file_operations}). Una volta terminate le
-operazioni, il file dovrà essere chiuso, e questo chiuderà il canale di
-comunicazione impedendo ogni ulteriore operazione.
+le funzioni che il VFS mette a disposizione (quelle di
+tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
+file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
+impedendo ogni ulteriore operazione.
All'interno di ogni processo i file aperti sono identificati da un numero
intero non negativo, che viene chiamato \textit{file descriptor}. Quando un
non supportano questa funzione, come ad esempio per i file di
terminale.\footnote{altri sistemi, usando \const{SEEK\_SET}, in questo caso
ritornano il numero di caratteri che vi sono stati scritti.} Lo standard
-POSIX però non specifica niente in proposito. Inoltre alcuni
-\index{file!speciali} file speciali, ad esempio \file{/dev/null}, non causano
-un errore ma restituiscono un valore indefinito.
+POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad
+esempio \file{/dev/null}, non causano un errore ma restituiscono un valore
+indefinito.
\itindbeg{sparse~file}
\index{file!\textit{hole}|(}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{fd} è un \index{file!speciali} file speciale
- che non supporta la sincronizzazione.
+ \item[\errcode{EINVAL}] \param{fd} è un file speciale che non supporta la
+ sincronizzazione.
\end{errlist}
ed inoltre \errval{EBADF}, \errval{EIO} e \errval{EROFS} nel loro
significato generico.}
come per le altre funzioni che prendono come argomenti dei
\itindsub{pathname}{relativo} \textit{pathname} relativi, è la possibilità,
quando un \textit{pathname} relativo non fa riferimento ad un file posto
-direttamente nella \index{directory~di~lavoro} directory di lavoro corrente,
-che alcuni dei componenti del \textit{pathname} vengano modificati in
-parallelo alla chiamata a \func{open}, cosa che lascia aperta la possibilità
-di una \itindex{race~condition} \textit{race condition} in cui c'è spazio per
-un \itindex{symlink~attack} \textit{symlink attack} (si ricordi quanto visto
-per \func{access} in sez.~\ref{sec:file_perm_management}).
-
-Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
-corrente è una proprietà del singolo processo; questo significa che quando si
-lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
-ma esistono molti casi in cui sarebbe invece utile che ogni singolo
-\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
-directory di lavoro.
+direttamente nella directory di lavoro corrente, che alcuni dei componenti del
+\textit{pathname} vengano modificati in parallelo alla chiamata a \func{open},
+cosa che lascia aperta la possibilità di una \itindex{race~condition}
+\textit{race condition} in cui c'è spazio per un \itindex{symlink~attack}
+\textit{symlink attack} (si ricordi quanto visto per \func{access} in
+sez.~\ref{sec:file_perm_management}).
+
+Inoltre come già accennato, la directory di lavoro corrente è una proprietà
+del singolo processo; questo significa che quando si lavora con i
+\textit{thread} essa sarà la stessa per tutti, ma esistono molti casi in cui
+sarebbe invece utile che ogni singolo \textit{thread} avesse la sua directory
+di lavoro.
Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
passare il relativo file descriptor alle varie funzioni che useranno quella
directory come punto di partenza per la risoluzione. In questo modo, anche
quando si lavora con i \itindex{thread} \textit{thread}, si può mantenere una
-\index{directory~di~lavoro} directory di lavoro diversa per ciascuno di essi.
+directory di lavoro diversa per ciascuno di essi.
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
\textit{race condition}, consente anche di ottenere aumenti di prestazioni
\fhead{fcntl.h}
\fdecl{int openat(int dirfd, const char *pathname, int flags)}
\fdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t mode)}
-\fdesc{Apre un file a partire da una directory di \index{directory~di~lavoro}
- lavoro.}
+\fdesc{Apre un file a partire da una directory di lavoro.}
}
{La funzione ritorna gli stessi valori e gli stessi codici di errore di
da \param{dirfd}. Qualora invece si usi un \itindsub{pathname}{assoluto}
\textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
se per \param{dirfd} si usa il valore speciale \const{AT\_FDCWD}, la
-risoluzione sarà effettuata rispetto alla directory di
-\index{directory~di~lavoro} lavoro corrente del processo. Si tenga presente
-però che questa, come le altre costanti \texttt{AT\_*}, è definita in
-\headfile{fcntl.h}, pertanto se la si vuole usare occorrerà includere comunque
-questo file, anche per le funzioni che non sono definite in esso.
+risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
+processo. Si tenga presente però che questa, come le altre costanti
+\texttt{AT\_*}, è definita in \headfile{fcntl.h}, pertanto se la si vuole
+usare occorrerà includere comunque questo file, anche per le funzioni che non
+sono definite in esso.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
Come per i file descriptor anche per gli \textit{stream} è possibile spostarsi
all'interno di un file per effettuare operazioni di lettura o scrittura in un
punto prestabilito, sempre che l'operazione di riposizionamento sia supportata
-dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che
-fare con quello che viene detto un file ad \textsl{accesso casuale}. Dato che
-in un sistema Unix esistono vari tipi di file, come le fifo ed i
-\index{file!di~dispositivo} file di dispositivo (ad esempio i terminali), non
-è scontato che questo sia vero in generale, pur essendolo sempre nel caso di
-file di dati.
+dal file sottostante lo \textit{stream}, nel caso cioè in cui si ha a che fare
+con quello che viene detto un file ad \textsl{accesso casuale}. Dato che in un
+sistema Unix esistono vari tipi di file, come le fifo ed i file di dispositivo
+(ad esempio i terminali), non è scontato che questo sia vero in generale, pur
+essendolo sempre nel caso di file di dati.
Con Linux ed in generale in ogni sistema unix-like la posizione nel file, come
abbiamo già visto in sez.~\ref{sec:file_lseek}, è espressa da un intero
\itindend{scheduler}
La memoria viene sempre gestita dal kernel attraverso il meccanismo della
-\index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
-a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
-sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
-gestione della memoria, si incaricherà di rimappare automaticamente sulla
-memoria fisica disponibile, con la possibilità ulteriore di spostare
-temporaneamente su disco (nella cosiddetta area di \textit{swap}) parte di
-detta memoria qualora ci si trovi nella necessità di liberare risorse.
+\textsl{memoria virtuale}, che consente di assegnare a ciascun processo uno
+spazio di indirizzi ``\textsl{virtuale}'' (vedi sez.~\ref{sec:proc_memory})
+che il kernel stesso, con l'ausilio della unità di gestione della memoria, si
+incaricherà di rimappare automaticamente sulla memoria fisica disponibile, con
+la possibilità ulteriore di spostare temporaneamente su disco (nella
+cosiddetta area di \textit{swap}) parte di detta memoria qualora ci si trovi
+nella necessità di liberare risorse.
Le periferiche infine vengono normalmente viste attraverso un'interfaccia
astratta che permette di trattarle come se fossero dei file, secondo uno dei
scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
che consenta di operare sui file, sia che questi corrispondano ai normali file
-di dati, o ai cosiddetti \index{file!speciali} ``\textsl{file speciali}'',
-come \index{file!di~dispositivo} i file di dispositivo (o \textit{device
- file}) che permettono di accedere alle periferiche o le fifo ed i socket che
-forniscono funzionalità di comunicazione fra processi.
+di dati, o ai cosiddetti ``\textsl{file speciali}'', come i file di
+dispositivo (o \textit{device file}) che permettono di accedere alle
+periferiche o le fifo ed i socket che forniscono funzionalità di comunicazione
+fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
Il secondo aspetto è che per poter utilizzare dei normali file di dati il
kernel deve provvedere ad organizzare e rendere accessibile in maniera
``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
sarà accessibile nella forma ordinaria di file e directory.
-\itindbeg{Virtual~File~System}
+\itindbeg{Virtual~File~System~(VFS)}
In Linux il concetto di \textit{everything is a file} è stato implementato
attraverso il \textit{Virtual File System} (che da qui in poi abbrevieremo in
\textit{Virtual File System} eseguirà direttamente il codice del kernel che
permette di accedere alla periferica.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
Come accennato in precedenza una delle funzioni essenziali per il
funzionamento dell'interfaccia dei file è quella che consente di montare un
filesystem, compresa un'altra directory, si ottiene naturalmente
un'organizzazione ad albero inserendo nomi di directory dentro altre
directory. All'interno dello stesso albero si potranno poi inserire anche
-tutti gli altri oggetti previsti l'interfaccia del
-\itindex{Virtual~File~System} VFS (su cui torneremo in
+tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
socket e gli stessi file di dispositivo.
sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
directory radice dell'albero dei file montata dal kernel all'avvio del
sistema; in questo caso si parla di un \textsl{pathname assoluto}
-\itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla
-\index{directory~di~lavoro} directory di lavoro corrente del processo (su cui
-torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla directory di
+lavoro corrente del processo (su cui torneremo in
+sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
\itindsub{pathname}{relativo} \textsl{pathname relativo}.
Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
significa anzitutto chiarire il proprio vocabolario e sottolineare le
differenze che ci sono rispetto ad altri sistemi operativi.
+\index{file!di~dispositivo|(}
+\index{file!speciali|(}
+
Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
-\itindex{Virtual~File~System} \textit{Virtual File System} consente di
-trattare come file oggetti molto diversi fra loro. Oltre ai normali file di
-dati abbiamo già accennato ad altri due di questi oggetti, i file di
-dispositivo e le directory, ma ne esistono altri. In genere quando si parla di
-tipo di file su Linux si fa riferimento a questi, di cui si riportato l'elenco
-completo in tab.~\ref{tab:file_file_types}.
+\textit{Virtual File System} consente di trattare come file oggetti molto
+diversi fra loro. Oltre ai normali file di dati abbiamo già accennato ad altri
+due di questi oggetti, i file di dispositivo e le directory, ma ne esistono
+altri. In genere quando si parla di tipo di file su Linux si fa riferimento a
+questi, di cui si riportato l'elenco completo in
+tab.~\ref{tab:file_file_types}.
\begin{table}[htb]
\footnotesize
\multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
\hline
\hline
- \textit{regular file} & \textsl{file regolare} & Un file che contiene dei dati (l'accezione
- normale di file).\\
- \textit{directory} & \textsl{cartella o direttorio} & Un file che contiene una lista
- di nomi associati a degli
- \textit{inode} (vedi
- sez.~\ref{sec:file_vfs_work}).\\
- \textit{symbolic link} & \textsl{collegamento simbolico} & Un file che contiene un
- riferimento ad un altro
- file/directory.\\
- \textit{char device} & \textsl{dispositivo a caratteri} & Un file \textsl{speciale}
- che identifica una periferica
- ad accesso a caratteri.\\
- \textit{block device} & \textsl{dispositivo a blocchi} & Un file \textsl{speciale}
- che identifica una periferica
- ad accesso a blocchi.\\
- \textit{fifo} & ``\textsl{coda}'' & Un file \textsl{speciale} che
- identifica una linea di comunicazione
- unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
- \textit{socket} & ``\textsl{presa}''& Un file \textsl{speciale} che identifica una linea di
- comunicazione bidirezionale (vedi
- cap.~\ref{cha:socket_intro}).\\
+ \textit{regular file}& \textsl{file regolare}
+ & Un file che contiene dei dati (l'accezione
+ normale di file).\\
+ \textit{directory} &\textsl{cartella o direttorio}
+ & Un file che contiene una lista di nomi associati
+ a degli \textit{inode} (vedi
+ sez.~\ref{sec:file_vfs_work}).\\
+ \textit{symbolic link}&\textsl{collegamento simbolico}
+ & Un file che contiene un riferimento ad un altro
+ file/directory.\\
+ \textit{char device} &\textsl{dispositivo a caratteri}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a caratteri.\\
+ \textit{block device}& \textsl{dispositivo a blocchi}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a blocchi.\\
+ \textit{fifo} & ``\textsl{coda}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione unidirezionale (vedi
+ sez.~\ref{sec:ipc_named_pipe}).\\
+ \textit{socket} & ``\textsl{presa}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione bidirezionale (vedi
+ cap.~\ref{cha:socket_intro}).\\
\hline
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
niente a che fare neanche con le eventuali diverse modalità con cui si
potrebbe accedere al contenuto dei file di dati. La classificazione di
tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
-\itindex{Virtual~File~System} \textit{Virtual File System}, ed è da notare la
-presenza dei cosiddetti file ``\textsl{speciali}''.
+\textit{Virtual File System}, ed è da notare la presenza dei cosiddetti file
+``\textsl{speciali}''.
Alcuni di essi, come le \textit{fifo} (che tratteremo in
sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
alcune funzionalità di comunicazione fornite dal kernel. Gli altri sono
-proprio quei \index{file!di~dispositivo} \textsl{file di dispositivo} che
-costituiscono una interfaccia diretta per leggere e scrivere sui dispositivi
-fisici. Anche se finora li abbiamo chiamati genericamente così, essi sono
-tradizionalmente suddivisi in due grandi categorie, \textsl{a blocchi} e
-\textsl{a caratteri} a seconda delle modalità in cui il dispositivo
-sottostante effettua le operazioni di I/O.
+proprio quei \textsl{file di dispositivo} che costituiscono una interfaccia
+diretta per leggere e scrivere sui dispositivi fisici. Anche se finora li
+abbiamo chiamati genericamente così, essi sono tradizionalmente suddivisi in
+due grandi categorie, \textsl{a blocchi} e \textsl{a caratteri} a seconda
+delle modalità in cui il dispositivo sottostante effettua le operazioni di
+I/O.
I dispositivi a blocchi (ad esempio i dischi) sono quelli corrispondono a
periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi di
dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
ed è completamente trasparente all'utente; inoltre talvolta si parla di
\textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
- fare con tutto ciò, di effettuare, attraverso degli appositi
- \index{file!di~dispositivo} file di dispositivo, operazioni di I/O
- direttamente sui dischi senza passare attraverso un filesystem, il
- cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ma
- ormai in sostanziale disuso.}
+ fare con tutto ciò, di effettuare, attraverso degli appositi file di
+ dispositivo, operazioni di I/O direttamente sui dischi senza passare
+ attraverso un filesystem, il cosiddetto \textit{raw access}, introdotto coi
+ kernel della serie 2.4.x ma ormai in sostanziale disuso.}
+
+\index{file!di~dispositivo|}
+\index{file!speciali|)}
Una differenza che attiene ai contenuti di un file però esiste, ed è relativa
al formato dei file di testo. Nei sistemi unix-like la fine riga è codificata
tipo di processore o architettura è stato adottato da molti sistemi
unix-like e non solo.}
+\itindbeg{magic~number}
+
Nonostante l'assenza di supporto da parte del kernel per la classificazione
del contenuto dei file di dati, molti programmi adottano comunque delle
convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
in file con l'estensione \file{.c}. Inoltre una tecnica molto usata per
classificare i contenuti da parte dei programmi è quella di utilizzare i primi
-byte del file per memorizzare un \itindex{magic~number} ``\textit{magic
- number}''\footnote{il concetto è quello di un numero intero, solitamente fra
- 2 e 10 byte, che identifichi il contenuto seguente, dato che questi sono
- anche caratteri è comune trovare espresso tale numero con stringhe come
- ``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script.} che ne
-classifichi il contenuto. Entrambe queste tecniche, per quanto usate ed
-accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
-demandato alle applicazioni stesse.
+byte del file per memorizzare un ``\textit{magic number}'' che ne classifichi
+il contenuto. Il concetto è quello di un numero intero, solitamente fra 2 e 10
+byte, che identifichi il contenuto seguente, dato che questi sono anche
+caratteri è comune trovare espresso tale numero con stringhe come
+``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script. Entrambe
+queste tecniche, per quanto usate ed accettate in maniera diffusa, restano
+solo delle convenzioni il cui rispetto è demandato alle applicazioni stesse.
+
+\itindend{magic~number}
\subsection{Le due interfacce per l'accesso ai file}
(descritte in sez.~\ref{sec:file_fcntl_ioctl}) su un qualunque tipo di oggetto
del VFS occorre usare l'interfaccia standard di Unix con i file
descriptor. Allo stesso modo devono essere usati i file descriptor se si vuole
-ricorrere a modalità speciali di I/O come il \itindex{file~locking}
-\textit{file locking} o l'I/O non-bloccante (vedi
-cap.~\ref{cha:file_advanced}).
+ricorrere a modalità speciali di I/O come il \textit{file locking} o l'I/O
+non-bloccante (vedi cap.~\ref{cha:file_advanced}).
Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
quella dei \textit{file descriptor}, che permette di poter scegliere tra
Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
libreria, e in seguito sono stati prodotti anche altri standard per la shell e
i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
-\itindex{thread} \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i
-socket (1003.1g) e vari altri. In tab.~\ref{tab:intro_posix_std} è riportata
-una classificazione sommaria dei principali documenti prodotti, e di come sono
-identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
-l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
-parlare di POSIX.4 come di POSIX.1b.
+\textit{thread} (rispettivamente 1003.1d e 1003.1c) per i socket (1003.1g) e
+vari altri. In tab.~\ref{tab:intro_posix_std} è riportata una classificazione
+sommaria dei principali documenti prodotti, e di come sono identificati fra
+IEEE ed ISO; si tenga conto inoltre che molto spesso si usa l'estensione IEEE
+anche come aggiunta al nome POSIX; ad esempio è più comune parlare di POSIX.4
+come di POSIX.1b.
Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
POSIX.2 & 1003.2 & 9945-2& Comandi. \\
POSIX.3 & 2003 &TR13210& Metodi di test. \\
POSIX.4 & 1003.1b & --- & Estensioni real-time. \\
- POSIX.4a& 1003.1c & --- & \itindex{thread} Thread. \\
+ POSIX.4a& 1003.1c & --- & Thread. \\
POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time. \\
POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA. \\
POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza. \\
\item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
- dello standard POSIX.1c per i \itindex{thread} \textit{thread};
+ dello standard POSIX.1c per i \textit{thread};
\item a partire dalla versione 2.3.3 della \acr{glibc} un valore maggiore o
uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
\item[\macro{\_ATFILE\_SOURCE}] definendo questa macro si rendono disponibili
le estensioni delle funzioni di creazione, accesso e modifica di file e
directory che risolvono i problemi di sicurezza insiti nell'uso di
- \textit{pathname} relativi con programmi \itindex{thread}
- \textit{multi-thread} illustrate in sez.~\ref{sec:file_openat}.
+ \textit{pathname} relativi con programmi \textit{multi-thread} illustrate in
+ sez.~\ref{sec:file_openat}.
\item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente
\macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
- versioni \index{funzioni!rientranti} rientranti (vedi
- sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si
- usano i \itindex{thread} \textit{thread}. Alcune di queste funzioni sono
- anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
+ versioni rientranti (vedi sez.~\ref{sec:proc_reentrant}) di alcune funzioni,
+ necessarie quando si usano i \textit{thread}. Alcune di queste funzioni
+ sono anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
disponibili soltanto su alcuni sistemi, o specifiche della \acr{glibc}, e
possono essere utilizzate una volta definita la macro.
Abbiamo già trattato in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
\func{mkfifo} che permettono di creare una \textit{fifo}. Per utilizzarne una
-un processo non avrà che da aprire il relativo \index{file!speciali} file
-speciale o in lettura o scrittura; nel primo caso il processo sarà collegato
-al capo di uscita della \textit{fifo}, e dovrà leggere, nel secondo al capo di
-ingresso, e dovrà scrivere.
+un processo non avrà che da aprire il relativo file speciale o in lettura o
+scrittura; nel primo caso il processo sarà collegato al capo di uscita della
+\textit{fifo}, e dovrà leggere, nel secondo al capo di ingresso, e dovrà
+scrivere.
Il kernel alloca un singolo buffer per ciascuna \textit{fifo} che sia stata
aperta, e questa potrà essere acceduta contemporaneamente da più processi, sia
cosiddetti \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo
in generale i socket in cap.~\ref{cha:socket_intro}, nell'ambito
dell'interfaccia che essi forniscono per la programmazione di rete, e vedremo
-anche (in~sez.~\ref{sec:sock_sa_local}) come si possono utilizzare i
-\index{file!speciali} file speciali di tipo socket, analoghi a quelli
-associati alle \textit{fifo} (si rammenti sez.~\ref{sec:file_file_types}) cui
-si accede però attraverso quella medesima interfaccia; vale però la pena
-esaminare qui una modalità di uso dei socket locali che li rende
-sostanzialmente identici ad una \textit{pipe} bidirezionale.
+anche (in~sez.~\ref{sec:sock_sa_local}) come si possono utilizzare i file
+speciali di tipo socket, analoghi a quelli associati alle \textit{fifo} (si
+rammenti sez.~\ref{sec:file_file_types}) cui si accede però attraverso quella
+medesima interfaccia; vale però la pena esaminare qui una modalità di uso dei
+socket locali che li rende sostanzialmente identici ad una \textit{pipe}
+bidirezionale.
La funzione di sistema \funcd{socketpair}, introdotta da BSD ma supportata in
genere da qualunque sistema che fornisca l'interfaccia dei socket ed inclusa
in POSIX.1-2001, consente infatti di creare una coppia di file descriptor
connessi fra loro (tramite un socket, appunto) senza dover ricorrere ad un
-\index{file!speciali} file speciale sul filesystem. I descrittori sono del
-tutto analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con
-la sola differenza è che in questo caso il flusso dei dati può essere
-effettuato in entrambe le direzioni. Il prototipo della funzione è:
+file speciale sul filesystem. I descrittori sono del tutto analoghi a quelli
+che si avrebbero con una chiamata a \func{pipe}, con la sola differenza è che
+in questo caso il flusso dei dati può essere effettuato in entrambe le
+direzioni. Il prototipo della funzione è:
\begin{funcproto}{
\fhead{sys/types.h}
Poi, per verificare che l'argomento specifichi effettivamente una directory,
si esegue (\texttt{\small 24-26}) su di esso una \func{chdir}, uscendo
immediatamente in caso di errore. Questa funzione serve anche per impostare
-la \index{directory~di~lavoro} directory di lavoro del programma nella
-directory da tenere sotto controllo, in vista del successivo uso della
-funzione \func{daemon}. Si noti come si è potuta fare questa scelta,
-nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
-particolare scopo del programma, che necessita comunque di restare all'interno
-di una directory.
+la directory di lavoro del programma nella directory da tenere sotto
+controllo, in vista del successivo uso della funzione \func{daemon}. Si noti
+come si è potuta fare questa scelta, nonostante le indicazioni illustrate in
+sez.~\ref{sec:sess_daemon}, per il particolare scopo del programma, che
+necessita comunque di restare all'interno di una directory.
Infine (\texttt{\small 27-29}) si installano i gestori per i vari segnali di
terminazione che, avendo a che fare con un programma che deve essere eseguito
Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
con l'esecuzione in background come si conviene ad un programma demone; si
noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-\index{directory~di~lavoro} directory di lavoro corrente. Una volta che il
-programma è andato in background l'esecuzione prosegue all'interno di un ciclo
-infinito (\texttt{\small 42-48}).
+directory di lavoro corrente. Una volta che il programma è andato in
+background l'esecuzione prosegue all'interno di un ciclo infinito
+(\texttt{\small 42-48}).
Si inizia (\texttt{\small 43}) bloccando il mutex con \func{MutexLock} per
poter accedere alla memoria condivisa (la funzione si bloccherà
\item gli identificatori per il controllo di sessione: il
\itindex{process~group} \textit{process group-ID} e il \textit{session id}
ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
-\item la \index{directory~di~lavoro} directory di lavoro e la directory radice
- (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
+\item la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la
+ directory radice (vedi sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
\item la maschera dei segnali bloccati (vedi
\item i segmenti di memoria condivisa agganciati al processo (vedi
sez.~\ref{sec:ipc_sysv_shm});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
-\item il valori di \textit{nice}, le priorità real-time e le affinità di
- processore (vedi sez.~\ref{sec:proc_sched_stand},
+\item il valori di \textit{nice}, le priorità \textit{real-time} e le affinità
+ di processore (vedi sez.~\ref{sec:proc_sched_stand},
sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
\item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
(\ids{PPID});
\item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item la directory radice e la \index{directory~di~lavoro} directory di lavoro
- corrente (vedi sez.~\ref{sec:file_work_dir});
+\item la directory radice e la directory di lavoro corrente (vedi
+ sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
rilanciare un'altra istanza di \cmd{getty}.
Se invece la password corrisponde \cmd{login} esegue \func{chdir} per
-impostare come \index{directory~di~lavoro} directory di lavoro la \textit{home
- directory} dell'utente, cambia i diritti di accesso al terminale (con
-\func{chown} e \func{chmod}) per assegnarne la titolarità all'utente ed al suo
-gruppo principale, assegnandogli al contempo i diritti di lettura e
-scrittura.\footnote{oggi queste operazioni, insieme ad altre relative alla
- contabilità ed alla tracciatura degli accessi, vengono gestite dalle
- distribuzioni più recenti in una maniera generica appoggiandosi a servizi di
- sistema come \textit{ConsoleKit}, ma il concetto generale resta
- sostanzialmente lo stesso.} Inoltre il programma provvede a costruire gli
-opportuni valori per le variabili di ambiente, come \envvar{HOME},
-\envvar{SHELL}, ecc. Infine attraverso l'uso di \func{setuid}, \func{setgid}
-e \func{initgroups} verrà cambiata l'identità del proprietario del processo,
-infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo invocato tali
-funzioni con i privilegi di amministratore, tutti gli \ids{UID} ed i \ids{GID}
-(reali, effettivi e salvati) saranno impostati a quelli dell'utente.
+impostare come directory di lavoro la \textit{home directory} dell'utente,
+cambia i diritti di accesso al terminale (con \func{chown} e \func{chmod}) per
+assegnarne la titolarità all'utente ed al suo gruppo principale, assegnandogli
+al contempo i diritti di lettura e scrittura.\footnote{oggi queste operazioni,
+ insieme ad altre relative alla contabilità ed alla tracciatura degli
+ accessi, vengono gestite dalle distribuzioni più recenti in una maniera
+ generica appoggiandosi a servizi di sistema come \textit{ConsoleKit}, ma il
+ concetto generale resta sostanzialmente lo stesso.} Inoltre il programma
+provvede a costruire gli opportuni valori per le variabili di ambiente, come
+\envvar{HOME}, \envvar{SHELL}, ecc. Infine attraverso l'uso di \func{setuid},
+\func{setgid} e \func{initgroups} verrà cambiata l'identità del proprietario
+del processo, infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo
+invocato tali funzioni con i privilegi di amministratore, tutti gli \ids{UID}
+ed i \ids{GID} (reali, effettivi e salvati) saranno impostati a quelli
+dell'utente.
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
non potrà ottenere automaticamente un terminale di controllo.
-\item Eseguire una \func{chdir} per impostare la \index{directory~di~lavoro}
- directory di lavoro del processo (su \file{/} o su una directory che
- contenga dei file necessari per il programma), per evitare che la directory
- da cui si è lanciato il processo resti in uso e non sia possibile rimuoverla
- o smontare il filesystem che la contiene.
+\item Eseguire una \func{chdir} per impostare la directory di lavoro del
+ processo (su \file{/} o su una directory che contenga dei file necessari per
+ il programma), per evitare che la directory da cui si è lanciato il processo
+ resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
+ contiene.
\item Impostare la \itindex{umask} maschera dei permessi (di solito con
\code{umask(0)}) in modo da non essere dipendenti dal valore ereditato da
chi ha lanciato originariamente il processo.
padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
\func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
-\index{directory~di~lavoro} directory di lavoro su \file{/},
-se \param{noclose} è nullo i file standard vengono rediretti su
-\file{/dev/null} (corrispondenti ai passi 4 e 6); in caso di valori non nulli
-non viene eseguita nessuna altra azione.
+directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
+vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
+di valori non nulli non viene eseguita nessuna altra azione.
Dato che un programma demone non può più accedere al terminale, si pone il
problema di come fare per la notifica di eventuali errori, non potendosi più
La funzione restituisce il puntatore alla stringa contenente il nome del file
di dispositivo del terminale associato a \param{fd}, che però è allocata
staticamente e può essere sovrascritta da successive chiamate. Per questo
-della funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \funcd{ttyname\_r}, che non presenta il problema dell'uso di una
-zona di memoria statica; il suo prototipo è:
+della funzione esiste anche una versione rientrante, \funcd{ttyname\_r}, che
+non presenta il problema dell'uso di una zona di memoria statica; il suo
+prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
presenta questa situazione è il seguente:
\begin{itemize*}
\item la lettura da file che possono bloccarsi in attesa di dati non ancora
- presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
- socket o le \textit{pipe});
+ presenti (come per certi file di dispositivo, i socket o le \textit{pipe});
\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente (di nuovo comune per i socket);
\item l'apertura di un file di dispositivo che richiede operazioni non
Le funzioni illustrate finora hanno un difetto: utilizzando una area di
memoria interna per allocare i contenuti della struttura \struct{hostent} non
-possono essere\index{funzioni!rientranti} rientranti. Questo comporta anche
-che in due successive chiamate i dati potranno essere sovrascritti. Si tenga
-presente poi che copiare il contenuto della sola struttura non è sufficiente
-per salvare tutti i dati, in quanto questa contiene puntatori ad altri dati,
-che pure possono essere sovrascritti; per questo motivo, se si vuole salvare
-il risultato di una chiamata, occorrerà eseguire quella che si chiama una
-\itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così quella tecnica
- per cui, quando si deve copiare il contenuto di una struttura complessa (con
- puntatori che puntano ad altri dati, che a loro volta possono essere
- puntatori ad altri dati) si deve copiare non solo il contenuto della
- struttura, ma eseguire una scansione per risolvere anche tutti i puntatori
- contenuti in essa (e così via se vi sono altre sotto-strutture con altri
- puntatori) e copiare anche i dati da questi referenziati.}
+possono essere rientranti. Questo comporta anche che in due successive
+chiamate i dati potranno essere sovrascritti. Si tenga presente poi che
+copiare il contenuto della sola struttura non è sufficiente per salvare tutti
+i dati, in quanto questa contiene puntatori ad altri dati, che pure possono
+essere sovrascritti; per questo motivo, se si vuole salvare il risultato di
+una chiamata, occorrerà eseguire quella che si chiama una \itindex{deep~copy}
+\textit{deep copy}.\footnote{si chiama così quella tecnica per cui, quando si
+ deve copiare il contenuto di una struttura complessa (con puntatori che
+ puntano ad altri dati, che a loro volta possono essere puntatori ad altri
+ dati) si deve copiare non solo il contenuto della struttura, ma eseguire una
+ scansione per risolvere anche tutti i puntatori contenuti in essa (e così
+ via se vi sono altre sotto-strutture con altri puntatori) e copiare anche i
+ dati da questi referenziati.}
Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
-versioni \index{funzioni!rientranti} rientranti delle precedenti funzioni, al
-solito queste sono caratterizzate dall'avere un suffisso \texttt{\_r},
-pertanto avremo le due funzioni \funcd{gethostbyname\_r} e
-\funcd{gethostbyname2\_r} i cui prototipi sono:
+versioni rientranti delle precedenti funzioni, al solito queste sono
+caratterizzate dall'avere un suffisso \texttt{\_r}, pertanto avremo le due
+funzioni \funcd{gethostbyname\_r} e \funcd{gethostbyname2\_r} i cui prototipi
+sono:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/socket.h}
altrimenti restituiscono un codice di errore negativo e all'indirizzo puntato
da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
\param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
-essere \index{funzioni!rientranti} rientrante la funzione non può la variabile
-globale \var{h\_errno}. In questo caso il codice di errore, oltre ai valori di
+essere rientrante la funzione non può la variabile globale \var{h\_errno}. In
+questo caso il codice di errore, oltre ai valori di
tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
qualora il buffer allocato su \param{buf} non sia sufficiente a contenere i
dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
restituito un puntatore ad una apposita struttura \struct{servent} contenente
tutti i risultati, altrimenti viene restituito un puntatore nullo. Si tenga
presente che anche in questo caso i dati vengono mantenuti in una area di
-memoria statica e che quindi la funzione non è \index{funzioni!rientranti}
-rientrante.
+memoria statica e che quindi la funzione non è rientrante.
\begin{figure}[!htb]
\footnotesize \centering
variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
utilizzata dalla funzione per riportare (come \itindex{value~result~argument}
\textit{value result argument}) i propri risultati. La funzione infatti è
-\index{funzioni!rientranti} rientrante, ed alloca autonomamente tutta la
-memoria necessaria in cui verranno riportati i risultati della risoluzione.
-La funzione scriverà all'indirizzo puntato da \param{res} il puntatore
-iniziale ad una \itindex{linked~list} \textit{linked list} di strutture di
-tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
+rientrante, ed alloca autonomamente tutta la memoria necessaria in cui
+verranno riportati i risultati della risoluzione. La funzione scriverà
+all'indirizzo puntato da \param{res} il puntatore iniziale ad una
+\itindex{linked~list} \textit{linked list} di strutture di tipo
+\struct{addrinfo} contenenti tutte le informazioni ottenute.
\begin{figure}[!htb]
\footnotesize \centering
dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
alla stringa che contiene l'espressione in formato dotted decimal. Si deve
tenere presente che la stringa risiede in memoria statica, per cui questa
-funzione non è \index{funzioni!rientranti} rientrante.
+funzione non è rientrante.
\subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
motivo viene sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la
memoria dove sono scritte le stringhe a cui i puntatori in essa contenuti
fanno riferimento. Ovviamente questo implica che dette funzioni non possono
-essere \index{funzioni!rientranti} rientranti; per questo motivo ne esistono
-anche due versioni alternative (denotate dalla solita estensione \code{\_r}),
-i cui prototipi sono:
+essere rientranti; per questo motivo ne esistono anche due versioni
+alternative (denotate dalla solita estensione \code{\_r}), i cui prototipi
+sono:
\begin{funcproto}{
\fhead{pwd.h}
\end{funcproto}
Come per le precedenti per gli utenti esistono anche le analoghe versioni
-\index{funzioni!rientranti} rientranti che di nuovo utilizzano la stessa
-estensione \code{\_r}; i loro prototipi sono:
+rientranti che di nuovo utilizzano la stessa estensione \code{\_r}; i loro
+prototipi sono:
\begin{funcproto}{
\fhead{grp.h}
\hline
\funcm{fgetpwent} & Legge una voce dal file di registro degli utenti
specificato.\\
- \funcm{fgetpwent\_r}& Come la precedente, ma \index{funzioni!rientranti}
- rientrante.\\
+ \funcm{fgetpwent\_r}& Come la precedente, ma 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{getpwent\_r} & Come la precedente, ma 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.\\
- \funcm{fgetgrent\_r}& Come la precedente, ma \index{funzioni!rientranti}
- rientrante.\\
+ \funcm{fgetgrent\_r}& Come la precedente, ma 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{getgrent\_r} & Come la precedente, ma rientrante.\\
\funcm{setgrent} & Ritorna all'inizio di \conffile{/etc/group}.\\
\funcm{endgrent} & Chiude \conffile{/etc/group}.\\
\hline
Come già visto in sez.~\ref{sec:sys_user_group}, l'uso di strutture allocate
staticamente rende le funzioni di lettura dei dati appena illustrate non
-\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 intero e prendono due argomenti
-aggiuntivi, i rispettivi prototipi sono:
+rientranti. Per questo motivo le \acr{glibc} forniscono anche delle versioni
+rientranti: \func{getutent\_r}, \func{getutid\_r}, \func{getutline\_r}, che
+invece di restituire un puntatore restituiscono un intero e prendono due
+argomenti aggiuntivi, i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{utmp.h}
\end{funcproto}
Le funzioni si comportano esattamente come le precedenti analoghe non
-\index{funzioni!rientranti} rientranti, solo che restituiscono il risultato
-all'indirizzo specificato dal primo argomento aggiuntivo \param{buffer} mentre
-il secondo, \param{result)} viene usato per restituire il puntatore al buffer
-stesso.
+rientranti, solo che restituiscono il risultato all'indirizzo specificato dal
+primo argomento aggiuntivo \param{buffer} mentre il secondo, \param{result)}
+viene usato per restituire il puntatore al buffer stesso.
Infine le \acr{glibc} forniscono altre due funzioni, \funcd{updwtmp} e
\funcd{logwtmp}, come estensione per scrivere direttamente delle voci nel file
del fuso orario. In realtà \func{ctime} è banalmente definita in termini di
\func{asctime} come \code{asctime(localtime(t)}.
-Dato che l'uso di una stringa statica rende le funzioni non
-\index{funzioni!rientranti} rientranti POSIX.1c e SUSv2 prevedono due
-sostitute \index{funzioni!rientranti} rientranti, il cui nome è al solito
+Dato che l'uso di una stringa statica rende le funzioni non rientranti
+POSIX.1c e SUSv2 prevedono due sostitute rientranti, il cui nome è al solito
ottenuto aggiungendo un \code{\_r}, che prendono un secondo argomento
\code{char *buf}, in cui l'utente deve specificare il buffer su cui la stringa
deve essere copiata (deve essere di almeno 26 caratteri).
Anche in questo caso le due funzioni restituiscono l'indirizzo di una
struttura allocata staticamente, per questo sono state definite anche altre
-due versioni \index{funzioni!rientranti} rientranti (con la solita estensione
-\code{\_r}), che prevedono un secondo argomento \code{struct tm *result},
-fornito dal chiamante, che deve preallocare la struttura su cui sarà
-restituita la conversione. La versione rientrante di \func{localtime} però non
-effettua la chiamata preventiva a \func{tzset} che deve essere eseguita a cura
-dell'utente.
+due versioni rientranti (con la solita estensione \code{\_r}), che prevedono
+un secondo argomento \code{struct tm *result}, fornito dal chiamante, che deve
+preallocare la struttura su cui sarà restituita la conversione. La versione
+rientrante di \func{localtime} però non effettua la chiamata preventiva a
+\func{tzset} che deve essere eseguita a cura dell'utente.
Infine \func{mktime} esegue la conversione di un \textit{broken-down time} a
partire da una struttura \struct{tm} restituendo direttamente un valore di
modificata dal programma; essa è utilizzabile solo fino ad una chiamata
successiva a \func{strerror} o \func{perror} e nessun'altra funzione di
libreria tocca questa stringa. In ogni caso l'uso di una stringa statica rende
-la funzione non \index{funzioni!rientranti} rientrante, per cui nel caso si
-usino i \itindex{thread} \textit{thread} la \acr{glibc} fornisce una apposita
-versione \index{funzioni!rientranti} rientrante \funcd{strerror\_r}, il cui
-prototipo è:
+la funzione non rientrante, per cui nel caso si usino i \itindex{thread}
+\textit{thread} la \acr{glibc} fornisce una apposita versione rientrante
+\funcd{strerror\_r}, il cui prototipo è:
\begin{funcproto}{
\fhead{string.h}
projects / gapil.git / commitdiff