From: Simone Piccardi Date: Sat, 10 Oct 2015 00:17:05 +0000 (+0000) Subject: Reindicizzazione X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=88d22f4971adcbdb816c405a1375ae0a8d57bdde;p=gapil.git Reindicizzazione --- diff --git a/filedir.tex b/filedir.tex index 6e5abc5..37ca3b6 100644 --- a/filedir.tex +++ b/filedir.tex @@ -45,7 +45,7 @@ successori. % 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 @@ -224,7 +224,7 @@ tab.~\ref{tab:file_inode_operations} le più rilevanti. 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}).\\ @@ -351,7 +351,7 @@ file possono restare sempre le stesse nonostante le enormi differenze che 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 @@ -682,16 +682,16 @@ passaggio di un argomento di una funzione, si intende che questi devono essere 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 @@ -735,17 +735,16 @@ una operazione diversa (ad esempio un rimontaggio, invece che un montaggio). 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} @@ -767,12 +766,12 @@ nell'elenco seguente: 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 @@ -1110,9 +1109,9 @@ dispositivo in più punti. Nel caso più di un filesystem sia stato montato sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello che è stato montato per ultimo. Si tenga presente che la funzione fallisce 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 @@ -1128,13 +1127,11 @@ un filesystem anche quando questo risulti occupato; il suo prototipo è: \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} @@ -1200,16 +1197,16 @@ sez.~\ref{sec:link_symlink_rename}). Questa è una 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 \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 @@ -1699,12 +1696,11 @@ La funzione elimina il nome specificato dall'argomento \param{pathname} nella 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 @@ -1786,9 +1782,9 @@ sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C, 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 @@ -1881,11 +1877,11 @@ elenchi di nomi con riferimenti ai rispettivi \itindex{inode} \textit{inode}, 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} @@ -1943,9 +1939,8 @@ necessaria una specifica funzione di sistema, \funcd{rmdir}, il suo prototipo 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 @@ -1991,9 +1986,8 @@ leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo 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} @@ -2065,7 +2059,7 @@ La funzione restituisce il file descriptor associato al \textit{directory 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 è @@ -2138,9 +2132,9 @@ fig.~\ref{fig:file_dirent_struct}.\footnote{la definizione è quella usata da 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 @@ -2477,18 +2471,17 @@ voci di una directory. La funzione inizia con l'aprire (\texttt{\small 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 @@ -2886,7 +2879,7 @@ specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti \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 è: @@ -2902,7 +2895,7 @@ 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, @@ -2954,8 +2947,8 @@ modalità \code{w+b}, si veda sez.~\ref{sec:file_fopen}) e pronto per l'uso, 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 @@ -3653,12 +3646,11 @@ tutte le volte che si modifica \itindex{inode} l'\textit{inode}, e quindi 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 @@ -4710,10 +4702,9 @@ caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid}, 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 @@ -4884,25 +4875,23 @@ tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: 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} @@ -6895,8 +6884,7 @@ opportuno dettagliare maggiormente. \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.\\ @@ -7707,20 +7695,20 @@ programma ad una sezione limitata del filesystem, per cui ne parleremo in 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 @@ -7771,24 +7759,23 @@ processo, che potrebbe restare fuori dalla \textit{chroot jail}. 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 diff --git a/fileio.tex b/fileio.tex index a963c96..77769ec 100644 --- a/fileio.tex +++ b/fileio.tex @@ -29,13 +29,13 @@ ultime le caratteristiche più avanzate. 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}} @@ -53,10 +53,10 @@ comunicazione con il kernel che renda possibile operare su di esso. Questo si 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 @@ -834,9 +834,9 @@ per i tre casi citati nel prototipo, vale anche per tutti quei dispositivi che 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}|(} @@ -1490,8 +1490,8 @@ prototipi sono: {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.} @@ -1560,19 +1560,18 @@ Un problema generale che si pone con l'uso della funzione \func{open}, così 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 @@ -1599,7 +1598,7 @@ sarà la base della risoluzione dei \itindsub{pathname}{relativo} 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 @@ -1620,8 +1619,7 @@ esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo: \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 @@ -1641,11 +1639,11 @@ relativo questo sarà risolto rispetto alla directory indicata 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 @@ -2876,12 +2874,11 @@ sez.~\ref{sec:file_stream_thread}). 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 diff --git a/intro.tex b/intro.tex index 611bc37..dd52cd0 100644 --- a/intro.tex +++ b/intro.tex @@ -135,13 +135,13 @@ eseguire le operazioni necessarie. \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 @@ -403,10 +403,10 @@ programmi delle opportune \textit{system call} che consentano di leggere e 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 @@ -418,7 +418,7 @@ disponibile ai processi attraverso quello che viene chiamato il ``\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 @@ -456,7 +456,7 @@ questo caso invece di usare il codice del filesystem che accede al disco, il \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 @@ -515,8 +515,7 @@ Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del 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. @@ -562,9 +561,9 @@ eseguito una \func{chroot} (funzione su cui torneremo in 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 @@ -592,13 +591,16 @@ Parlare dei tipi di file su Linux, come per qualunque sistema unix-like, 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 @@ -608,27 +610,30 @@ completo in tab.~\ref{tab:file_file_types}. \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} @@ -641,19 +646,19 @@ tal caso si avrebbe a che fare sempre e solo con dei file di dati. E non ha 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 @@ -672,11 +677,13 @@ VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione 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 @@ -708,19 +715,22 @@ viene usato quasi esclusivamente l'ELF.\footnote{il nome è l'acronimo di 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} @@ -768,9 +778,8 @@ altri oggetti del VFS, ma per poter accedere alle operazioni di controllo (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 @@ -1020,12 +1029,12 @@ mirante a standardizzare l'interfaccia con il sistema operativo. 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; @@ -1047,7 +1056,7 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni è 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. \\ @@ -1247,7 +1256,7 @@ in essi definite, sono illustrate nel seguente elenco: \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; @@ -1422,15 +1431,14 @@ una opportuna macro; queste estensioni sono illustrate nel seguente elenco: \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. diff --git a/ipc.tex b/ipc.tex index abe229a..35095a4 100644 --- a/ipc.tex +++ b/ipc.tex @@ -514,10 +514,10 @@ a quello illustrato per le \textit{pipe} in sez.~\ref{sec:ipc_pipes}. 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 @@ -821,21 +821,21 @@ presenta il problema della unidirezionalità del flusso dei dati, è quello dei 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} @@ -3066,12 +3066,11 @@ con un messaggio di errore. 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 @@ -3100,9 +3099,9 @@ intercomunicazione il programma entra nel ciclo principale (\texttt{\small 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à diff --git a/prochand.tex b/prochand.tex index 2fed790..2fd1924 100644 --- a/prochand.tex +++ b/prochand.tex @@ -608,8 +608,8 @@ comune dopo l'esecuzione di una \func{fork} è la seguente: \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 @@ -618,8 +618,8 @@ comune dopo l'esecuzione di una \func{fork} è la seguente: \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 @@ -1539,8 +1539,8 @@ seguente: (\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}); diff --git a/session.tex b/session.tex index e3b5100..dd98e69 100644 --- a/session.tex +++ b/session.tex @@ -655,21 +655,21 @@ numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a 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) @@ -738,11 +738,11 @@ occorrerà predisporlo in modo che esso compia le seguenti azioni: 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. @@ -772,10 +772,9 @@ La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit}, nel 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ù @@ -1453,9 +1452,9 @@ associato ad un file descriptor; il suo prototipo è: 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} diff --git a/signal.tex b/signal.tex index 84c8ac5..b26cddf 100644 --- a/signal.tex +++ b/signal.tex @@ -936,8 +936,7 @@ prima che la \textit{system call} sia ritornata. Un elenco dei casi in cui si 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 diff --git a/sockctrl.tex b/sockctrl.tex index 33f0dfc..196c410 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -781,25 +781,25 @@ ci sono precauzioni particolari da prendere.\footnote{volendo essere pignoli 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} @@ -837,8 +837,8 @@ In caso di successo entrambe le funzioni restituiscono un valore nullo, 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 @@ -1103,8 +1103,7 @@ corrisponde agli argomenti specificati; se la risoluzione ha successo viene 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 @@ -1266,11 +1265,11 @@ Come ultimo argomento in \param{res} deve essere passato un puntatore ad una 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 diff --git a/socket.tex b/socket.tex index 92ffe95..43a5dbd 100644 --- a/socket.tex +++ b/socket.tex @@ -884,7 +884,7 @@ L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit 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}} diff --git a/system.tex b/system.tex index 127095d..228905e 100644 --- a/system.tex +++ b/system.tex @@ -774,9 +774,9 @@ La struttura usata da entrambe le funzioni è allocata staticamente, per questo 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} @@ -836,8 +836,8 @@ i loro prototipi sono: \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} @@ -898,23 +898,19 @@ di utenti e gruppi, con il formato classico di \conffile{/etc/passwd} e \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 @@ -1132,11 +1128,10 @@ hanno lo stesso identico comportamento. Per completezza viene definita anche 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} @@ -1156,10 +1151,9 @@ aggiuntivi, i rispettivi prototipi sono: \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 @@ -2722,9 +2716,8 @@ a \func{tzset} (che vedremo a breve), in modo che la data espressa tenga conto 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). @@ -2761,12 +2754,11 @@ effettua una chiamata preventiva a \func{tzset}. 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 @@ -3053,10 +3045,9 @@ La funzione \func{strerror} utilizza una stringa statica che non deve essere 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}