From 7208522fd60468969d96dba5d8dd2cbd24b75b89 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sat, 10 Oct 2015 19:23:20 +0000 Subject: [PATCH] Ancora revisione degli indici, aggiunto CLONE_VM e paragrafo su multicast e broadcast. Riordinata l'inroduzione ai socket. --- fileadv.tex | 2 + filedir.tex | 725 +++++++++++++++++++++++++-------------------------- fileio.tex | 77 +++--- ipc.tex | 67 ++--- network.tex | 49 +++- prochand.tex | 111 +++++--- sockctrl.tex | 58 ++--- socket.tex | 75 +++--- tcpsock.tex | 2 +- 9 files changed, 618 insertions(+), 548 deletions(-) diff --git a/fileadv.tex b/fileadv.tex index 5982d8e..9c06b50 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -965,6 +965,7 @@ dell'operazione bloccata dipende da quanto si otterrebbe dal file descriptor \textit{deadlock}. \itindbeg{polling} + Abbiamo già accennato in sez.~\ref{sec:file_open_close} che è possibile prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file in \textsl{modalità non-bloccante}, attraverso l'uso del flag @@ -977,6 +978,7 @@ viene garantito. Ovviamente questa tecnica, detta \textit{polling}, è estremamente inefficiente: si tiene costantemente impiegata la CPU solo per eseguire in continuazione delle \textit{system call} che nella gran parte dei casi falliranno. + \itindend{polling} É appunto per superare questo problema è stato introdotto il concetto di diff --git a/filedir.tex b/filedir.tex index e6fc42e..076172a 100644 --- a/filedir.tex +++ b/filedir.tex @@ -266,7 +266,8 @@ questa è necessaria per le operazioni eseguite dai processi con l'interfaccia dei file descriptor. Ogni processo infatti mantiene il riferimento ad una struttura \kstruct{file} per ogni file che ha aperto, ed è tramite essa che esegue le operazioni di I/O. Inoltre il kernel mantiene un elenco di tutti i -file aperti nella \itindex{file~table} \textit{file table}. +file aperti nella \textit{file table} (torneremo su questo in +sez.~\ref{sec:file_fd}). Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad oggetti posti all'interno di un filesystem e vi si applicano quindi le @@ -372,17 +373,20 @@ proprie. Per questo non entreremo nei dettagli di un filesystem specifico, ma daremo una descrizione a grandi linee che si adatta alle caratteristiche comuni di qualunque filesystem di un sistema unix-like. +\itindbeg{superblock} + Una possibile strutturazione dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre partizioni. In essa per semplicità si è fatto riferimento alla struttura del filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block group}. All'interno di ciascun \textit{block group} viene anzitutto -replicato il cosiddetto \itindex{superblock} \textit{superblock}, (la -struttura che contiene l'indice iniziale del filesystem e che consente di -accedere a tutti i dati sottostanti) e creata una opportuna suddivisione dei -dati e delle informazioni per accedere agli stessi. Sulle caratteristiche di -\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}. +replicato il cosiddetto \textit{superblock}, (la struttura che contiene +l'indice iniziale del filesystem e che consente di accedere a tutti i dati +sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni +per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati +torneremo in sez.~\ref{sec:file_ext2}. +\itindend{superblock} \itindbeg{inode} È comunque caratteristica comune di tutti i filesystem per Unix, @@ -404,10 +408,9 @@ per i dati in essi contenuti. Se si va ad esaminare con maggiore dettaglio la strutturazione dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i dettagli relativi al funzionamento del filesystem stesso come la -strutturazione in gruppi dei blocchi, il \itindex{superblock} -\textit{superblock} e tutti i dati di gestione possiamo esemplificare la -situazione con uno schema come quello esposto in -fig.~\ref{fig:file_filesys_detail}. +strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di +gestione possiamo esemplificare la situazione con uno schema come quello +esposto in fig.~\ref{fig:file_filesys_detail}. \begin{figure}[!htb] \centering @@ -513,7 +516,6 @@ tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di \subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori} \label{sec:file_ext2} - Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina di più è la famiglia di filesystem evolutasi a partire dal \textit{second @@ -555,16 +557,16 @@ le seguenti: in fase di creazione, a seconda delle sue esigenze: blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco. \item il filesystem implementa collegamenti simbolici veloci, in cui il nome - del file non è salvato su un blocco, ma tenuto all'interno \itindex{inode} + del file non è salvato su un blocco, ma tenuto all'interno dell'\textit{inode} (evitando letture multiple e spreco di spazio), non tutti i nomi però possono essere gestiti così per limiti di spazio (il limite è 60 caratteri). -\item vengono supportati \itindex{file~attributes} i cosiddetti \textit{file - attributes} che attivano comportamenti specifici per i file su cui vengono - attivati come marcarli come immutabili (che possono cioè essere soltanto - letti) per la protezione di file di configurazione sensibili, o come - \textit{append-only} (che possono essere aperti in scrittura solo per - aggiungere dati) per la protezione dei file di log. +\item vengono supportati i cosiddetti \textit{file attributes} (vedi + sez.~\ref{sec:file_perm_overview}) che attivano comportamenti specifici per + i file su cui vengono attivati come marcarli come immutabili (che possono + cioè essere soltanto letti) per la protezione di file di configurazione + sensibili, o come \textit{append-only} (che possono essere aperti in + scrittura solo per aggiungere dati) per la protezione dei file di log. \end{itemize} La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un @@ -573,12 +575,11 @@ riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa in gruppi di blocchi. Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del -filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati) -per una maggiore affidabilità e possibilità di recupero in caso di corruzione -del \itindex{superblock} \textit{superblock} principale. L'utilizzo di -raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni -dato che viene ridotta la distanza fra i dati e la tabella degli -\itindex{inode} \textit{inode}. +filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore +affidabilità e possibilità di recupero in caso di corruzione del +\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha +inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la +distanza fra i dati e la tabella degli \textit{inode}. \begin{figure}[!htb] \centering @@ -587,12 +588,13 @@ dato che viene ridotta la distanza fra i dati e la tabella degli \label{fig:file_ext2_dirs} \end{figure} -Le directory sono implementate come una \itindex{linked~list} \textit{linked - list} con voci di dimensione variabile. Ciascuna voce della lista contiene -il numero di \itindex{inode} \textit{inode}, la sua lunghezza, il nome del -file e la sua lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; -in questo modo è possibile implementare nomi per i file anche molto lunghi -(fino a 1024 caratteri) senza sprecare spazio disco. + +Le directory sono implementate come una \textit{linked list} con voci di +dimensione variabile. Ciascuna voce della lista contiene il numero di +\textit{inode}, la sua lunghezza, il nome del file e la sua lunghezza, secondo +lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile +implementare nomi per i file anche molto lunghi (fino a 1024 caratteri) senza +sprecare spazio disco. Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse modifiche strutturali, la principale di queste è quella che \textit{ext3} è un @@ -610,9 +612,9 @@ della scrittura dei dati sul disco. Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare sia le prestazioni che la semplicità di gestione del filesystem, in particolare per le directory si è passato all'uso di alberi binari con -indicizzazione tramite hash al posto delle \textit{linked list} che abbiamo -illustrato, ottenendo un forte guadagno di prestazioni in caso di directory -contenenti un gran numero di file. +indicizzazione tramite \textit{hash} al posto delle \textit{linked list} che +abbiamo illustrato, ottenendo un forte guadagno di prestazioni in caso di +directory contenenti un gran numero di file. % TODO (bassa priorità) portare a ext3, ext4 e btrfs ed illustrare le % problematiche che si possono incontrare (in particolare quelle relative alla @@ -651,10 +653,10 @@ memorizzati. L'operazione di attivazione del filesystem è chiamata o non può essere montato su \param{target} perché la directory è ancora in uso. \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un - \itindex{superblock} \textit{superblock} non valido, o si è cercato di - rimontare un filesystem non ancora montato, o di montarlo senza - che \param{target} sia un \textit{mount point} o di spostarlo - quando \param{target} non è un \textit{mount point} o è la radice. + \textit{superblock} non valido, o si è cercato di rimontare un filesystem + non ancora montato, o di montarlo senza che \param{target} sia un + \textit{mount point} o di spostarlo quando \param{target} non è un + \textit{mount point} o è la radice. \item[\errcode{ELOOP}] si è cercato di spostare un \textit{mount point} su una sottodirectory di \param{source} o si sono incontrati troppi collegamenti simbolici nella risoluzione di un nome. @@ -665,7 +667,7 @@ memorizzati. L'operazione di attivazione del filesystem è chiamata configurato nel kernel. \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per \param{source} quando era richiesto. - \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del + \item[\errcode{ENXIO}] il \textit{major number} del dispositivo \param{source} è sbagliato. \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \end{errlist} @@ -760,12 +762,11 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: In sostanza quello che avviene è che in corrispondenza del \textit{pathname} indicato da \param{target} viene montato l'\textit{inode} di \param{source}, - così che la porzione di albero dei file presente sotto - \param{source} diventi visibile allo stesso modo sotto - \param{target}. Trattandosi esattamente dei dati dello stesso filesystem, - ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile - nell'altro, visto che entrambi faranno riferimento agli stessi - \textit{inode}. + così che la porzione di albero dei file presente sotto \param{source} + diventi visibile allo stesso modo sotto \param{target}. Trattandosi + esattamente dei dati dello stesso filesystem, ogni modifica fatta in uno + qualunque dei due rami di albero sarà visibile nell'altro, visto che + entrambi faranno riferimento agli stessi \textit{inode}. 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 @@ -805,7 +806,9 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: all'uso dei collegamenti simbolici (di cui parleremo in sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche all'intero di un \textit{chroot} (argomento su cui torneremo in - sez.~\ref{sec:file_chroot}). \itindend{bind~mount} + sez.~\ref{sec:file_chroot}). + +\itindend{bind~mount} \item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una directory venga immediatamente registrata su disco in maniera sincrona @@ -822,10 +825,10 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: fino all'arrivo dei dati sul disco prima che un programma possa proseguire. \item[\const{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking} - \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}) sui file - del filesystem. Per poterlo utilizzare effettivamente però esso dovrà essere - comunque attivato esplicitamente per i singoli file impostando i permessi - come illustrato in sez.~\ref{sec:file_mand_locking}. + (vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo + utilizzare effettivamente però esso dovrà essere comunque attivato + esplicitamente per i singoli file impostando i permessi come illustrato in + sez.~\ref{sec:file_mand_locking}. \item[\const{MS\_MOVE}] Effettua uno del spostamento del \textit{mount point} di un filesystem. La directory del \textit{mount point} originale deve @@ -908,19 +911,17 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: \item[\const{MS\_PRIVATE}] Marca un \textit{mount point} come privato. Si tratta di una delle nuove opzioni (insieme a \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti parte - dell'infrastruttura degli \itindex{shared~subtree} \textit{shared subtree} - introdotta a partire dal kernel 2.6.15, che estendono le funzionalità dei - \itindex{bind~mount} \textit{bind mount}. In questo caso - \param{target} dovrà fare riferimento al \textit{mount point} che si intende - marcare, e tutti gli altri argomenti verranno ignorati. + dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal + kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In + questo caso \param{target} dovrà fare riferimento al \textit{mount point} + che si intende marcare, e tutti gli altri argomenti verranno ignorati. Di default, finché non lo si marca altrimenti con una delle altre opzioni - dell'interfaccia \itindex{shared~subtree} \textit{shared subtree}, ogni - \textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un - \textit{mount point} di tipo \textit{private} si comporta come descritto - nella trattazione di \const{MS\_BIND}. Si usa questo flag principalmente per - revocare gli effetti delle altre opzioni e riportare il comportamento a - quello ordinario. + dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è + privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di + tipo \textit{private} si comporta come descritto nella trattazione di + \const{MS\_BIND}. Si usa questo flag principalmente per revocare gli effetti + delle altre opzioni e riportare il comportamento a quello ordinario. \item[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura, non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le @@ -931,12 +932,11 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: \item[\const{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point} presenti al di sotto del \textit{mount point} indicato gli effetti della - opzione degli \itindex{shared~subtree} \textit{shared subtree} - associata. Anche questo caso l'argomento \param{target} deve fare - riferimento ad un \textit{mount point} e tutti gli altri argomenti sono - ignorati, ed il flag deve essere indicato assieme ad una fra - \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e - \const{MS\_UNBINDABLE}. + opzione degli \textit{shared subtree} associata. Anche questo caso + l'argomento \param{target} deve fare riferimento ad un \textit{mount point} + e tutti gli altri argomenti sono ignorati, ed il flag deve essere indicato + assieme ad una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, + \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}. % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0, % vedi http://lwn.net/Articles/621046/ @@ -977,24 +977,28 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: \const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel 2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}. +\itindbeg{shared~subtree} + \item[\const{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared - mount}. Si tratta di una delle nuove opzioni (insieme a + mount}. Si tratta di una delle nuove opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti - parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared - subtree} introdotta a partire dal kernel 2.6.15, che estendono le - funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso - \param{target} dovrà fare riferimento al \textit{mount point} che si intende - marcare, e tutti gli altri argomenti verranno ignorati. - - Lo scopo dell'opzione è ottenere che tutti i successivi \itindex{bind~mount} - \textit{bind mount} effettuati da un \textit{mount point} marcato da essa - siano di tipo \textit{shared}, cioè ``\textsl{condividano}'' con l'originale - e fra di loro ogni ulteriore operazione di montaggio o smontaggio che - avviene su una directory al di sotto di uno qualunque di essi. Le operazioni - di montaggio e smontaggio effettuate al di sotto di un qualunque - \textit{mount point} così marcato verranno ``\textsl{propagate}'' a tutti i - \textit{mount point} della stessa condivisione, e la sezione di albero di - file vista al di sotto di ciascuno di essi sarà sempre identica. + parte dell'infrastruttura dei cosiddetti \textit{shared subtree} introdotta + a partire dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind + mount}. In questo caso \param{target} dovrà fare riferimento al + \textit{mount point} che si intende marcare, e tutti gli altri argomenti + verranno ignorati. + + Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount} + effettuati da un \textit{mount point} marcato da essa siano di tipo + \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro + ogni ulteriore operazione di montaggio o smontaggio che avviene su una + directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e + smontaggio effettuate al di sotto di un qualunque \textit{mount point} così + marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della + stessa condivisione, e la sezione di albero di file vista al di sotto di + ciascuno di essi sarà sempre identica. + +\itindbend{shared~subtree} \item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione @@ -1005,11 +1009,10 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: \item[\const{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave mount}. Si tratta di una delle nuove opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti - parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared - subtree} introdotta a partire dal kernel 2.6.15, che estendono le - funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso - \param{target} dovrà fare riferimento al \textit{mount point} che si intende - marcare, e tutti gli altri argomenti verranno ignorati. + parte dell'infrastruttura degli \textit{shared subtree} introdotta a partire + dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. + In questo caso \param{target} dovrà fare riferimento al \textit{mount point} + che si intende marcare, e tutti gli altri argomenti verranno ignorati. Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount} effettuati da un \textit{mount point} marcato da essa siano di tipo @@ -1042,19 +1045,17 @@ con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente: \item[\const{MS\_UNBINDABLE}] Marca un \textit{mount point} come \textit{unbindable mount}. Si tratta di una delle nuove opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_SLAVE}) facenti parte - dell'infrastruttura degli \itindex{shared~subtree} \textit{shared subtree} - introdotta a partire dal kernel 2.6.15, che estendono le funzionalità dei - \itindex{bind~mount} \textit{bind mount}. In questo caso - \param{target} dovrà fare riferimento al \textit{mount point} che si intende - marcare, e tutti gli altri argomenti verranno ignorati. + dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal + kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In + questo caso \param{target} dovrà fare riferimento al \textit{mount point} + che si intende marcare, e tutti gli altri argomenti verranno ignorati. Un \textit{mount point} marcato in questo modo disabilita la capacità di - eseguire dei \itindex{bind~mount} \textit{bind mount} del suo contenuto. Si - comporta cioè come allo stesso modo di un \textit{mount point} ordinario di - tipo \textit{private} con in più la restrizione che nessuna sua - sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere - utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind - mount}. + eseguire dei \textit{bind mount} del suo contenuto. Si comporta cioè come + allo stesso modo di un \textit{mount point} ordinario di tipo + \textit{private} con in più la restrizione che nessuna sua sottodirectory + (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un + come sorgente di un \textit{bind mount}. \end{basedescript} @@ -1315,18 +1316,17 @@ In sez.~\ref{sec:file_filesystem} abbiamo spiegato come la capacità di chiamare un file con nomi diversi sia connaturata con l'architettura di un filesystem per un sistema Unix, in quanto il nome del file che si trova in una directory è solo un'etichetta associata ad un puntatore che permette di -ottenere il riferimento ad un \itindex{inode} \textit{inode}, e che è -quest'ultimo che viene usato dal kernel per identificare univocamente gli -oggetti sul filesystem. +ottenere il riferimento ad un \textit{inode}, e che è quest'ultimo che viene +usato dal kernel per identificare univocamente gli oggetti sul filesystem. Questo significa che fintanto che si resta sullo stesso filesystem la realizzazione di un \textit{link} è immediata: uno stesso file può avere tanti nomi diversi, dati da altrettante associazioni diverse allo stesso -\itindex{inode} \textit{inode} effettuate tramite ``etichette'' diverse in -directory diverse. Si noti anche come nessuno di questi nomi possa assumere -una particolare preferenza o originalità rispetto agli altri, in quanto tutti -fanno comunque riferimento allo stesso \itindex{inode} \textit{inode} e quindi -tutti otterranno lo stesso file. +\textit{inode} effettuate tramite ``etichette'' diverse in directory +diverse. Si noti anche come nessuno di questi nomi possa assumere una +particolare preferenza o originalità rispetto agli altri, in quanto tutti +fanno comunque riferimento allo stesso \textit{inode} e quindi tutti +otterranno lo stesso file. Quando si vuole aggiungere ad una directory una voce che faccia riferimento ad un file già esistente nella modalità appena descritta, per ottenere quello che @@ -1415,7 +1415,6 @@ dall'implementazione, cosa che rende Linux conforme a questa versione successiva dello standard. \itindbeg{symbolic~link} - \index{collegamento!simbolico|(} La ragione di questa differenza rispetto al vecchio standard, presente anche @@ -1436,10 +1435,10 @@ simbolico è sempre possibile farlo direttamente.\footnote{ciò non toglie che questa differenza rispetto allo standard POSIX.} Dato che \func{link} crea semplicemente dei nomi che fanno riferimenti agli -\itindex{inode} \textit{inode}, essa può funzionare soltanto per file che -risiedono sullo stesso filesystem e solo per un filesystem di tipo Unix. -Inoltre abbiamo visto che in Linux non è consentito eseguire un collegamento -diretto ad una directory. +\textit{inode}, essa può funzionare soltanto per file che risiedono sullo +stesso filesystem e solo per un filesystem di tipo Unix. Inoltre abbiamo +visto che in Linux non è consentito eseguire un collegamento diretto ad una +directory. Per ovviare a queste limitazioni, come accennato all'inizio, i sistemi unix-like supportano un'altra forma di collegamento, detta @@ -1456,11 +1455,11 @@ anche a file che non esistono ancora. Il meccanismo funziona in quanto i \textit{symbolic link} sono riconosciuti come tali dal kernel\footnote{è uno dei diversi tipi di file visti in - tab.~\ref{tab:file_file_types}, contrassegnato come tale \itindex{inode} - nell'\textit{inode} e riconoscibile dal valore del campo \var{st\_mode} - della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).} e tutta una -serie di funzioni di sistema (come \func{open} o \func{stat}) quando ricevono -come argomento il \textit{pathname} di un collegamento simbolico vanno + tab.~\ref{tab:file_file_types}, contrassegnato come tale nell'\textit{inode} + e riconoscibile dal valore del campo \var{st\_mode} della struttura + \struct{stat} (vedi sez.~\ref{sec:file_stat}).} e tutta una serie di +funzioni di sistema (come \func{open} o \func{stat}) quando ricevono come +argomento il \textit{pathname} di un collegamento simbolico vanno automaticamente ad operare sul file da esso specificato. La funzione di sistema che permette di creare un nuovo collegamento simbolico è \funcd{symlink}, ed il suo prototipo è: @@ -1643,14 +1642,13 @@ otterremmo la creazione di \file{/tmp/tmp\_file} senza errori. \itindend{symbolic~link} \index{collegamento!simbolico|)} - Un'altra funzione relativa alla gestione dei nomi dei file, anche se a prima vista parrebbe riguardare un argomento completamente diverso, è quella che per la cancellazione di un file. In realtà una \textit{system call} che serva proprio a cancellare un file non esiste neanche perché, come accennato in sez.~\ref{sec:file_filesystem}, quando in un sistema unix-like si richiede la rimozione di un file quella che si va a cancellare è soltanto la voce che -referenzia il suo \itindex{inode} \textit{inode} all'interno di una directory. +referenzia il suo \textit{inode} all'interno di una directory. La funzione di sistema che consente di effettuare questa operazione, il cui nome come si può notare ha poco a che fare con il concetto di rimozione, è @@ -1670,9 +1668,8 @@ nome come si può notare ha poco a che fare con il concetto di rimozione, è \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory. \item[\errcode{EPERM}] il filesystem non consente l'operazione, o la - directory che contiene \param{pathname} ha lo \itindex{sticky~bit} - \textit{sticky bit} e non si è il proprietario o non si hanno privilegi - amministrativi. + directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si + è il proprietario o non si hanno privilegi amministrativi. \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato generico.} @@ -1689,36 +1686,36 @@ nome come si può notare ha poco a che fare con il concetto di rimozione, è 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 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. +\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 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 il diritto di esecuzione/attraversamento sulla directory che la contiene (affronteremo in dettaglio l'argomento dei permessi di file e directory in -sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit} -\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato -occorrerà anche essere proprietari del file o proprietari della directory o -avere i privilegi di amministratore. +sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi +sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere +proprietari del file o proprietari della directory o avere i privilegi di +amministratore. Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso sono stati cancellati: solo quando il numero di collegamenti mantenuto -\itindex{inode} nell'\textit{inode} diventa nullo, questo viene disallocato e -lo spazio occupato su disco viene liberato. Si tenga presente comunque che a -questo si aggiunge sempre un'ulteriore condizione e cioè che non ci siano -processi che abbiano il suddetto file aperto.\footnote{come vedremo in +nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio +occupato su disco viene liberato. Si tenga presente comunque che a questo si +aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che +abbiano il suddetto file aperto.\footnote{come vedremo in sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei file aperti nei vari processi, che a sua volta contiene i riferimenti agli - \itindex{inode} \textit{inode} ad essi relativi; prima di procedere alla - cancellazione dello spazio occupato su disco dal contenuto di un file il - kernel controlla anche questa tabella, per verificare che anche in essa non - ci sia più nessun riferimento all'\textit{inode} in questione.} + \textit{inode} ad essi relativi; prima di procedere alla cancellazione dello + spazio occupato su disco dal contenuto di un file il kernel controlla anche + questa tabella, per verificare che anche in essa non ci sia più nessun + riferimento all'\textit{inode} in questione.} Questa caratteristica del sistema può essere usata per essere sicuri di non lasciare file temporanei su disco in caso di crash di un programma. La tecnica @@ -1791,10 +1788,9 @@ sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C, directory o \param{oldpath} è una directory e \param{newpath} esiste e non è una directory. \item[\errval{EPERM}] la directory contenente \param{oldpath} o quella - contenente un \param{newpath} esistente hanno lo - \itindex{sticky~bit} \textit{sticky bit} e non si è i proprietari dei - rispettivi file (o non si hanno privilegi amministrativi) oppure il - filesystem non supporta l'operazione. + contenente un \param{newpath} esistente hanno lo \textit{sticky bit} e non + si è i proprietari dei rispettivi file (o non si hanno privilegi + amministrativi) oppure il filesystem non supporta l'operazione. \item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo stesso filesystem e sotto lo stesso \textit{mount point}. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{EMLINK}, @@ -1805,10 +1801,9 @@ sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C, La funzione rinomina in \param{newpath} il file o la directory indicati dall'argomento \param{oldpath}. Il nome viene eliminato nella directory originale e ricreato nella directory di destinazione mantenendo il riferimento -allo stesso \itindex{inode} \textit{inode}. Non viene spostato nessun dato e -\itindex{inode} l'\textit{inode} del file non subisce nessuna modifica in -quanto le modifiche sono eseguite sulle directory che -contengono \param{newpath} ed \param{oldpath}. +allo stesso \textit{inode}. Non viene spostato nessun dato e l'\textit{inode} +del file non subisce nessuna modifica in quanto le modifiche sono eseguite +sulle directory che contengono \param{newpath} ed \param{oldpath}. Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di \func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non @@ -1857,25 +1852,24 @@ In tutti i casi si dovranno avere i permessi di scrittura nelle directory contenenti \param{oldpath} e \param{newpath}, e nel caso \param{newpath} sia una directory vuota già esistente anche su di essa (perché dovrà essere aggiornata la voce ``\texttt{..}''). Se poi le directory -contenenti \param{oldpath} o \param{newpath} hanno lo \itindex{sticky~bit} -\textit{sticky bit} attivo (vedi sez.~\ref{sec:file_special_perm}) si dovrà -essere i proprietari dei file (o delle directory) che si vogliono rinominare, -o avere i permessi di amministratore. +contenenti \param{oldpath} o \param{newpath} hanno lo \textit{sticky bit} +attivo (vedi sez.~\ref{sec:file_special_perm}) si dovrà essere i proprietari +dei file (o delle directory) che si vogliono rinominare, o avere i permessi di +amministratore. \subsection{La creazione e la cancellazione delle directory} \label{sec:file_dir_creat_rem} Benché in sostanza le directory non siano altro che dei file contenenti -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 - 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 è: +elenchi di nomi con riferimenti ai rispettivi \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 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} @@ -1939,8 +1933,8 @@ necessaria una specifica funzione di sistema, \funcd{rmdir}, il suo prototipo di \param{dirname}. \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di directory, oppure la directory che contiene \param{dirname} ha lo - \itindex{sticky~bit} \textit{sticky bit} impostato e non si è i - proprietari della directory o non si hanno privilegi amministrativi. + \textit{sticky bit} impostato e non si è i proprietari della directory o + non si hanno privilegi amministrativi. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errcode{ENOTEMPTY} e @@ -1967,12 +1961,12 @@ chiusura di tutti questi ulteriori riferimenti. \label{sec:file_dir_read} Benché le directory alla fine non siano altro che dei file che contengono -delle liste di nomi associati ai relativi \itindex{inode} \textit{inode}, per -il ruolo che rivestono nella struttura del sistema non possono essere trattate -come dei normali file di dati. Ad esempio, onde evitare inconsistenze -all'interno del filesystem, solo il kernel può scrivere il contenuto di una -directory, e non può essere un processo a inserirvi direttamente delle voci -con le usuali funzioni di scrittura. +delle liste di nomi associati ai relativi \textit{inode}, per il ruolo che +rivestono nella struttura del sistema non possono essere trattate come dei +normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del +filesystem, solo il kernel può scrivere il contenuto di una directory, e non +può essere un processo a inserirvi direttamente delle voci con le usuali +funzioni di scrittura. Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del kernel, sono molte le situazioni in cui i processi necessitano di poterne @@ -2129,8 +2123,7 @@ Di questa funzione esiste anche una versione rientrante, 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 -prototipo è: +può essere utilizzata anche con i \textit{thread}, il suo prototipo è: \begin{funcproto}{ \fhead{sys/types.h} @@ -2173,10 +2166,10 @@ presenti nella directory. Sia BSD che SVr4 che POSIX.1-2001\footnote{il dall'implementazione.} prevedono che siano sempre presenti il campo \var{d\_name}, che contiene il nome del file nella forma di una stringa terminata da uno zero, ed il campo \var{d\_ino}, che contiene il numero di -\itindex{inode} \textit{inode} cui il file è associato e corrisponde al campo -\var{st\_ino} di \struct{stat}. La presenza di ulteriori campi opzionali -oltre i due citati è segnalata dalla definizione di altrettante macro nella -forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è il nome del relativo +\textit{inode} cui il file è associato e corrisponde al campo \var{st\_ino} di +\struct{stat}. La presenza di ulteriori campi opzionali oltre i due citati è +segnalata dalla definizione di altrettante macro nella forma +\code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è il nome del relativo campo. Come si può evincere da fig.~\ref{fig:file_dirent_struct} nel caso di Linux sono pertanto definite le macro \macro{\_DIRENT\_HAVE\_D\_TYPE}, \macro{\_DIRENT\_HAVE\_D\_OFF} e \macro{\_DIRENT\_HAVE\_D\_RECLEN}, mentre non @@ -2517,7 +2510,7 @@ resta la stessa quando viene creato un processo figlio (vedi sez.~\ref{sec:proc_fork}), la directory di lavoro della shell diventa anche la directory di lavoro di qualunque comando da essa lanciato. -Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode} +Dato che è il kernel che tiene traccia per ciascun processo dell'\textit{inode} della directory di lavoro, per ottenerne il \textit{pathname} occorre usare una apposita funzione, \funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call} @@ -2671,7 +2664,7 @@ funzione di sistema \funcd{mknod}, il cui prototipo è: \item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una fifo, un socket o un dispositivo. \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare - \itindex{inode} l'\texttt{inode}, o il filesystem su cui si è cercato di + l'\texttt{inode}, o il filesystem su cui si è cercato di creare \param{pathname} non supporta l'operazione. \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ELOOP}, @@ -2679,14 +2672,14 @@ funzione di sistema \funcd{mknod}, il cui prototipo è: \errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.} \end{funcproto} -La funzione permette di creare un \itindex{inode} \textit{inode} di tipo -generico sul filesystem, e viene in genere utilizzata per creare i file di -dispositivo, ma si può usare anche per creare qualunque tipo di file speciale -ed anche file regolari. L'argomento \param{mode} specifica sia il tipo di file -che si vuole creare che i relativi permessi, secondo i valori riportati in +La funzione permette di creare un \textit{inode} di tipo generico sul +filesystem, e viene in genere utilizzata per creare i file di dispositivo, ma +si può usare anche per creare qualunque tipo di file speciale ed anche file +regolari. L'argomento \param{mode} specifica sia il tipo di file che si vuole +creare che i relativi permessi, secondo i valori riportati in tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR aritmetico. I permessi sono comunque modificati nella maniera usuale dal valore di -\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}). +\textit{umask} (si veda sez.~\ref{sec:file_perm_management}). Per il tipo di file può essere specificato solo uno fra i seguenti valori: \const{S\_IFREG} per un file regolare (che sarà creato vuoto), @@ -2712,13 +2705,16 @@ dispositivo usando questa funzione (il processo deve avere la capacità specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di una fifo o di un socket è consentito anche agli utenti normali. -I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno -al proprietario e al gruppo del processo (usando \ids{UID} e \ids{GID} del -gruppo effettivo) che li ha creati a meno non sia presente il bit \acr{sgid} -per la directory o sia stata attivata la semantica BSD per il filesystem (si -veda sez.~\ref{sec:file_ownership_management}) in cui si va a creare -\itindex{inode} l'\textit{inode}, nel qual caso per il gruppo verrà usato il -\ids{GID} del proprietario della directory. +I nuovi \textit{inode} creati con \func{mknod} apparterranno al proprietario e +al gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che +li ha creati a meno non sia presente il bit \acr{sgid} per la directory o sia +stata attivata la semantica BSD per il filesystem (si veda +sez.~\ref{sec:file_ownership_management}) in cui si va a creare +l'\textit{inode}, nel qual caso per il gruppo verrà usato il \ids{GID} del +proprietario della directory. + +\itindbeg{major~number} +\itindbeg{minor~number} Nella creazione di un file di dispositivo occorre poi specificare correttamente il valore di \param{dev}; questo infatti è di tipo @@ -2726,28 +2722,25 @@ correttamente il valore di \param{dev}; questo infatti è di tipo tab.~\ref{tab:intro_primitive_types}) riservato per indicare un \textsl{numero} di dispositivo. Il kernel infatti identifica ciascun dispositivo con un valore numerico, originariamente questo era un intero a 16 -bit diviso in due parti di 8 bit chiamate rispettivamente -\itindex{major~number} \textit{major number} e \itindex{minor~number} -\textit{minor number}, che sono poi i due numeri mostrati dal comando -\texttt{ls -l} al posto della dimensione quando lo si esegue su un file di -dispositivo. - -Il \itindex{major~number} \textit{major number} identifica una classe di -dispositivi (ad esempio la seriale, o i dischi IDE) e serve in sostanza per -indicare al kernel quale è il modulo che gestisce quella classe di -dispositivi. Per identificare uno specifico dispositivo di quella classe (ad -esempio una singola porta seriale, o uno dei dischi presenti) si usa invece il -\itindex{minor~number} \textit{minor number}. L'elenco aggiornato di questi -numeri con le relative corrispondenze ai vari dispositivi può essere trovato -nel file \texttt{Documentation/devices.txt} allegato alla documentazione dei -sorgenti del kernel. +bit diviso in due parti di 8 bit chiamate rispettivamente \textit{major + number} e \textit{minor number}, che sono poi i due numeri mostrati dal +comando \texttt{ls -l} al posto della dimensione quando lo si esegue su un +file di dispositivo. + +Il \textit{major number} identifica una classe di dispositivi (ad esempio la +seriale, o i dischi IDE) e serve in sostanza per indicare al kernel quale è il +modulo che gestisce quella classe di dispositivi. Per identificare uno +specifico dispositivo di quella classe (ad esempio una singola porta seriale, +o uno dei dischi presenti) si usa invece il \textit{minor number}. L'elenco +aggiornato di questi numeri con le relative corrispondenze ai vari dispositivi +può essere trovato nel file \texttt{Documentation/devices.txt} allegato alla +documentazione dei sorgenti del kernel. Data la crescita nel numero di dispositivi supportati, ben presto il limite massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo -\type{dev\_t}, con delle dimensioni passate a 12 bit per il -\itindex{major~number} \textit{major number} e 20 bit per il -\itindex{minor~number} \textit{minor number}. La transizione però ha +\type{dev\_t}, con delle dimensioni passate a 12 bit per il \textit{major + number} e 20 bit per il \textit{minor number}. La transizione però ha comportato il fatto che \type{dev\_t} è diventato un tipo opaco, e la necessità di specificare il numero tramite delle opportune macro, così da non avere problemi di compatibilità con eventuali ulteriori estensioni. @@ -2756,42 +2749,41 @@ Le macro sono definite nel file \headfile{sys/sysmacros.h},\footnote{se si usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle versioni specifiche di questa libreria, \macro{gnu\_dev\_major}, \macro{gnu\_dev\_minor} e \macro{gnu\_dev\_makedev} che si possono usare - direttamente, al costo di una minore portabilità.} che viene -automaticamente incluso quando si include \headfile{sys/types.h}. Si possono -pertanto ottenere i valori del \itindex{major~number} \textit{major number} e -\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente -con le macro \macro{major} e \macro{minor}: + direttamente, al costo di una minore portabilità.} che viene automaticamente +incluso quando si include \headfile{sys/types.h}. Si possono pertanto ottenere +i valori del \textit{major number} e \textit{minor number} di un dispositivo +rispettivamente con le macro \macro{major} e \macro{minor}: {\centering \vspace{3pt} \begin{funcbox}{ \fhead{sys/types.h} \fdecl{int \macro{major}(dev\_t dev)} -\fdesc{Restituisce il \itindex{major~number} \textit{major number} del - dispositivo \param{dev}.} +\fdesc{Restituisce il \textit{major number} del dispositivo \param{dev}.} \fdecl{int \macro{minor}(dev\_t dev)} -\fdesc{Restituisce il \itindex{minor~number} \textit{minor number} del - dispositivo \param{dev}.} +\fdesc{Restituisce il \textit{minor number} del dispositivo \param{dev}.} } \end{funcbox} } -\noindent mentre una volta che siano noti \itindex{major~number} \textit{major - number} e \itindex{minor~number} \textit{minor number} si potrà costruire il -relativo identificativo con la macro \macro{makedev}: +\noindent mentre una volta che siano noti \textit{major number} e +\textit{minor number} si potrà costruire il relativo identificativo con la +macro \macro{makedev}: {\centering \vspace{3pt} \begin{funcbox}{ \fhead{sys/types.h} \fdecl{dev\_t \macro{makedev}(int major, int minor)} -\fdesc{Dati \itindex{major~number} \textit{major number} e - \itindex{minor~number} \textit{minor number} restituisce l'identificativo di - un dispositivo.} +\fdesc{Dati \textit{major number} e \textit{minor number} restituisce + l'identificativo di un dispositivo.} } \end{funcbox} } + +\itindend{major~number} +\itindend{minor~number} \index{file!di~dispositivo|)} Dato che la funzione di sistema \func{mknod} presenta diverse varianti nei @@ -2817,7 +2809,8 @@ prototipo è: La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve esistere (neanche come collegamento simbolico); al solito i permessi specificati da \param{mode} -vengono modificati dal valore di \itindex{umask} \textit{umask}. +vengono modificati dal valore di \textit{umask} (vedi +sez.~\ref{sec:file_perm_management}). \index{file!speciali|)} @@ -3056,13 +3049,12 @@ non si pongono. Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali relative alle caratteristiche di ciascun file, a partire dalle informazioni -relative al controllo di accesso, sono mantenute \itindex{inode} -nell'\textit{inode}. Vedremo in questa sezione come sia possibile leggere -tutte queste informazioni usando la funzione \func{stat}, che permette -l'accesso a tutti i dati memorizzati \itindex{inode} nell'\textit{inode}; -esamineremo poi le varie funzioni usate per manipolare tutte queste -informazioni, eccetto quelle che riguardano la gestione del controllo di -accesso, trattate in in sez.~\ref{sec:file_access_control}. +relative al controllo di accesso, sono mantenute nell'\textit{inode}. Vedremo +in questa sezione come sia possibile leggere tutte queste informazioni usando +la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati +nell'\textit{inode}; esamineremo poi le varie funzioni usate per manipolare +tutte queste informazioni, eccetto quelle che riguardano la gestione del +controllo di accesso, trattate in in sez.~\ref{sec:file_access_control}. \subsection{La lettura delle caratteristiche dei file} @@ -3141,16 +3133,16 @@ questa sezione: fanno riferimento al file (il cosiddetto \textit{link count}) di cui abbiamo già parlato in numerose occasioni. -\item Il campo \var{st\_ino} contiene il numero di \itindex{inode} - \textit{inode} del file, quello viene usato all'interno del filesystem per - identificarlo e che può essere usato da un programma per determinare se due - \textit{pathname} fanno riferimento allo stesso file. +\item Il campo \var{st\_ino} contiene il numero di \textit{inode} del file, + quello viene usato all'interno del filesystem per identificarlo e che può + essere usato da un programma per determinare se due \textit{pathname} fanno + riferimento allo stesso file. \item Il campo \var{st\_dev} contiene il numero del dispositivo su cui risiede il file (o meglio il suo filesystem). Si tratta dello stesso numero che si - usa con \func{mknod} e che può essere decomposto in \itindex{major~number} - \textit{major number} e \itindex{minor~number} \textit{minor number} con le - macro \macro{major} e \macro{minor} viste in sez.~\ref{sec:file_mknod}. + usa con \func{mknod} e che può essere decomposto in \textit{major number} e + \textit{minor number} con le macro \macro{major} e \macro{minor} viste in + sez.~\ref{sec:file_mknod}. \item Il campo \var{st\_rdev} contiene il numero di dispositivo associato al file stesso ed ovviamente ha un valore significativo soltanto quando il file @@ -3385,15 +3377,14 @@ Windows questo non è possibile. \label{sec:file_file_times} Il sistema mantiene per ciascun file tre tempi, che sono registrati -\itindex{inode} nell'\textit{inode} insieme agli altri attributi del -file. Questi possono essere letti tramite la funzione \func{stat}, che li -restituisce attraverso tre campi della struttura \struct{stat} di -fig.~\ref{fig:file_stat_struct}. Il significato di questi tempi e dei relativi -campi della struttura \struct{stat} è illustrato nello schema di -tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle -funzioni che effettuano cambiamenti su di essi. Il valore del tempo è espresso -nel cosiddetto \textit{calendar time}, su cui torneremo in dettaglio in -sez.~\ref{sec:sys_time}. +nell'\textit{inode} insieme agli altri attributi del file. Questi possono +essere letti tramite la funzione \func{stat}, che li restituisce attraverso +tre campi della struttura \struct{stat} di fig.~\ref{fig:file_stat_struct}. Il +significato di questi tempi e dei relativi campi della struttura \struct{stat} +è illustrato nello schema di tab.~\ref{tab:file_file_times}, dove è anche +riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il +valore del tempo è espresso nel cosiddetto \textit{calendar time}, su cui +torneremo in dettaglio in sez.~\ref{sec:sys_time}. \begin{table}[htb] \centering @@ -3421,10 +3412,10 @@ ultima modifica (il \textit{modification time}) riportato in \var{st\_mtime}, ed il tempo di ultimo cambiamento di stato (il \textit{change status time}) riportato in \var{st\_ctime}. Il primo infatti fa riferimento ad una modifica del contenuto di un file, mentre il secondo ad una modifica dei metadati -\itindex{inode} dell'\textit{inode}. Dato che esistono molte operazioni, come -la funzione \func{link} e altre che vedremo in seguito, che modificano solo le -informazioni contenute \itindex{inode} nell'\textit{inode} senza toccare il -contenuto del file, diventa necessario l'utilizzo di questo secondo tempo. +dell'\textit{inode}. Dato che esistono molte operazioni, come la funzione +\func{link} e altre che vedremo in seguito, che modificano solo le +informazioni contenute nell'\textit{inode} senza toccare il contenuto del +file, diventa necessario l'utilizzo di questo secondo tempo. Il tempo di ultima modifica viene usato ad esempio da programmi come \cmd{make} per decidere quali file necessitano di essere ricompilati perché @@ -3436,13 +3427,13 @@ lasso di tempo. Ad esempio un programma come \texttt{leafnode} lo usa per cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per marcare i messaggi di posta che risultano letti. -Il sistema non tiene mai conto dell'ultimo accesso \itindex{inode} -all'\textit{inode}, pertanto funzioni come \func{access} o \func{stat} non -hanno alcuna influenza sui tre tempi. Il comando \cmd{ls} (quando usato con le -opzioni \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema -riportato nell'ultima colonna di tab.~\ref{tab:file_file_times}. Si noti anche -come non esista, a differenza di altri sistemi operativi, un \textsl{tempo di - creazione} di un file. +Il sistema non tiene mai conto dell'ultimo accesso all'\textit{inode}, +pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza +sui tre tempi. Il comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o +\cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima +colonna di tab.~\ref{tab:file_file_times}. Si noti anche come non esista, a +differenza di altri sistemi operativi, un \textsl{tempo di creazione} di un +file. L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un difetto progettuale di Unix, questo infatti comporta la necessità di @@ -3635,15 +3626,15 @@ proprietà del file viene utilizzato l'\ids{UID} effettivo del processo. Si tenga presente che non è possibile modificare manualmente il tempo di cambiamento di stato del file, che viene aggiornato direttamente dal kernel -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 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.} +tutte le volte che si modifica 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 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 @@ -3755,8 +3746,8 @@ sono: (solo \func{utimensat}). \item[\errcode{EPERM}] si è richiesto un cambiamento nei tempi non al tempo corrente, ma non si è proprietari del file o non si hanno i privilegi di - amministratore; oppure il file è \itindex{file~attributes} immutabile o - \textit{append-only} (vedi sez.~\ref{sec:file_perm_overview}). + amministratore; oppure il file è immutabile o \textit{append-only} (vedi + sez.~\ref{sec:file_perm_overview}). \item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle componenti di \param{pathname} (solo \func{utimensat}) \end{errlist} @@ -3851,11 +3842,11 @@ sez.~\ref{sec:proc_access_id}.\footnote{questo è vero solo per filesystem di tipo Unix, ad esempio non è vero per il filesystem VFAT di Windows, che non fornisce nessun supporto per l'accesso multiutente, e per il quale queste proprietà vengono assegnate in maniera fissa con opportune opzioni di - montaggio.} Anche questi sono mantenuti \itindex{inode} sull'\textit{inode} -insieme alle altre proprietà e sono accessibili da programma tramite la -funzione \func{stat} (trattata in sez.~\ref{sec:file_stat}), che restituisce -l'utente proprietario nel campo \var{st\_uid} ed il gruppo proprietario nel -campo \var{st\_gid} della omonima struttura \struct{stat}. + montaggio.} Anche questi sono mantenuti sull'\textit{inode} insieme alle +altre proprietà e sono accessibili da programma tramite la funzione +\func{stat} (trattata in sez.~\ref{sec:file_stat}), che restituisce l'utente +proprietario nel campo \var{st\_uid} ed il gruppo proprietario nel campo +\var{st\_gid} della omonima struttura \struct{stat}. Il controllo di accesso ai file segue un modello abbastanza semplice che prevede tre permessi fondamentali strutturati su tre livelli di accesso. @@ -3901,10 +3892,10 @@ I restanti tre bit (noti come \textit{suid bit}, \textit{sgid bit}, e complesse del meccanismo del controllo di accesso su cui torneremo in seguito (in sez.~\ref{sec:file_special_perm}), lo schema di allocazione dei bit è riportato in fig.~\ref{fig:file_perm_bit}. Come tutte le altre proprietà di -un file anche i permessi sono memorizzati \itindex{inode} nell'\textit{inode}, -e come accennato in sez.~\ref{sec:file_types} essi sono vengono restituiti in -una parte del campo \var{st\_mode} della struttura \struct{stat} (si veda di -nuovo fig.~\ref{fig:file_stat_struct}). +un file anche i permessi sono memorizzati nell'\textit{inode}, e come +accennato in sez.~\ref{sec:file_types} essi sono vengono restituiti in una +parte del campo \var{st\_mode} della struttura \struct{stat} (si veda di nuovo +fig.~\ref{fig:file_stat_struct}). In genere ci si riferisce ai tre livelli dei privilegi usando le lettere \texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o} @@ -4001,8 +3992,8 @@ file a cui fa riferimento; per questo in genere il comando \cmd{ls} riporta per un collegamento simbolico tutti i permessi come concessi. Utente e gruppo a cui esso appartiene vengono pure ignorati quando il collegamento viene risolto, vengono controllati solo quando viene richiesta la rimozione del -collegamento e quest'ultimo è in una directory con lo \itindex{sticky~bit} -\textit{sticky bit} impostato (si veda sez.~\ref{sec:file_special_perm}). +collegamento e quest'ultimo è in una directory con lo \textit{sticky bit} +impostato (si veda sez.~\ref{sec:file_special_perm}). La procedura con cui il kernel stabilisce se un processo possiede un certo permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra @@ -4163,12 +4154,11 @@ con questi bit l'uso della semantica BSD nella creazione di nuovi file (si veda sez.~\ref{sec:file_ownership_management} per una spiegazione dettagliata al proposito). -Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata -da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo -sia anche il corrispondente bit di esecuzione viene utilizzato per attivare -per quel file il \itindex{mandatory~locking} \textit{mandatory locking} -(affronteremo questo argomento in dettaglio più avanti, in -sez.~\ref{sec:file_mand_locking}). +Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata da +SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo sia +anche il corrispondente bit di esecuzione viene utilizzato per attivare per +quel file il \textit{mandatory locking} (affronteremo questo argomento in +dettaglio più avanti, in sez.~\ref{sec:file_mand_locking}). \itindend{suid~bit} \itindend{sgid~bit} @@ -4306,10 +4296,10 @@ eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso l'uso del \textit{suid bit}) che vuole controllare se l'utente originale ha i permessi per accedere ad un certo file, ma eseguire questo controllo prima di aprire il file espone al rischio di una \textit{race condition} che apre ad un -possibile \itindex{symlink~attack} \textit{symlink attack} fra il controllo e -l'apertura del file. In questo caso è sempre opportuno usare invece la -funzione \func{faccessat} che tratteremo insieme alle altre -\textit{at-functions} in sez.~\ref{sec:file_openat}. +possibile \textit{symlink attack} fra il controllo e l'apertura del file. In +questo caso è sempre opportuno usare invece la funzione \func{faccessat} che +tratteremo insieme alle altre \textit{at-functions} in +sez.~\ref{sec:file_openat}. Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e \funcm{eaccess} che ripetono lo stesso controllo usando però gli @@ -4416,18 +4406,18 @@ limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file, non tutti i valori possibili di \param{mode} sono permessi o hanno effetto; in particolare accade che: \begin{enumerate*} -\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit} - \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso - viene automaticamente cancellato, senza notifica di errore, qualora sia - stato indicato in \param{mode}. +\item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se + l'\ids{UID} effettivo del processo non è zero esso viene automaticamente + cancellato, senza notifica di errore, qualora sia stato indicato + in \param{mode}. \item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la creazione dei nuovi file, si può avere il caso in cui il file creato da un processo è assegnato ad un gruppo per il quale il processo non ha privilegi. - Per evitare che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad - un file appartenente ad un gruppo per cui non si hanno diritti, questo viene - automaticamente cancellato da \param{mode}, senza notifica di errore, - qualora il gruppo del file non corrisponda a quelli associati al processo; - la cosa non avviene quando l'\ids{UID} effettivo del processo è zero. + Per evitare che si possa assegnare il bit \acr{sgid} ad un file appartenente + ad un gruppo per cui non si hanno diritti, questo viene automaticamente + cancellato da \param{mode}, senza notifica di errore, qualora il gruppo del + file non corrisponda a quelli associati al processo; la cosa non avviene + quando l'\ids{UID} effettivo del processo è zero. \end{enumerate*} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -4542,11 +4532,10 @@ utenti vi creano appartengano allo gruppo stesso. Questo non risolve però completamente i problemi di accesso da parte di altri utenti dello stesso gruppo, in quanto di default i permessi assegnati al gruppo non sono sufficienti per un accesso in scrittura; in questo caso si deve aver cura di -usare prima della creazione dei file un valore per \itindex{umask} -\textit{umask} lasci il permesso di scrittura.\footnote{in tal caso si può - assegnare agli utenti del gruppo una \textit{umask} di $002$, anche se la - soluzione migliore in questo caso è usare una ACL di default (vedi - sez.~\ref{sec:file_ACL}).} +usare prima della creazione dei file un valore per \textit{umask} lasci il +permesso di scrittura.\footnote{in tal caso si può assegnare agli utenti del + gruppo una \textit{umask} di $002$, anche se la soluzione migliore in questo + caso è usare una ACL di default (vedi sez.~\ref{sec:file_ACL}).} Come avviene nel caso dei permessi esistono anche delle appropriate funzioni di sistema, \funcd{chown} \funcd{fchown} e \funcd{lchown}, che permettono di @@ -4597,11 +4586,11 @@ rispetto allo standard POSIX è che specificando -1 come valore per \param{owner} e \param{group} i valori restano immutati. Quando queste funzioni sono chiamate con successo da un processo senza i -privilegi di amministratore entrambi i bit \acr{suid} e \itindex{sgid~bit} -\acr{sgid} vengono cancellati. Questo non avviene per il bit \acr{sgid} nel -caso in cui esso sia usato (in assenza del corrispondente permesso di -esecuzione) per indicare che per il file è attivo il \textit{mandatory - locking} (vedi sez.~\ref{sec:file_mand_locking}). +privilegi di amministratore entrambi i bit \acr{suid} e \acr{sgid} vengono +cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso sia +usato (in assenza del corrispondente permesso di esecuzione) per indicare che +per il file è attivo il \textit{mandatory locking} (vedi +sez.~\ref{sec:file_mand_locking}). \subsection{Un quadro d'insieme sui permessi} @@ -4632,8 +4621,7 @@ fornire un quadro d'insieme. \hline 1&-&-&-&-&1&-&-&-&-&-&-&Eseguito conferisce l'\ids{UID} effettivo dell'utente.\\ -&1&-&-&-&1&-&-&-&-&-&-&Eseguito conferisce il \ids{GID} effettivo del gruppo.\\ - -&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking} - \textit{mandatory locking} è abilitato.\\ + -&1&-&-&-&0&-&-&-&-&-&-&Il \textit{mandatory locking} è abilitato.\\ -&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato.\\ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per l'utente.\\ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per l'utente.\\ @@ -4716,15 +4704,14 @@ Linux. \itindbeg{Extended~Attributes} Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni -che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie -funzioni che permettono di modificarle. Si sarà notato come in realtà queste -informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix -origina negli anni '70, quando le risorse di calcolo e di spazio disco erano -minime. Con il venir meno di queste restrizioni è incominciata ad emergere -l'esigenza di poter associare ai file delle ulteriori informazioni astratte -(quelli che abbiamo chiamato genericamente \textsl{metadati}) che però non -potevano trovare spazio nei dati classici mantenuti negli \itindex{inode} -\textit{inode}. +che il sistema mantiene negli \textit{inode}, e le varie funzioni che +permettono di modificarle. Si sarà notato come in realtà queste informazioni +siano estremamente ridotte. Questo è dovuto al fatto che Unix origina negli +anni '70, quando le risorse di calcolo e di spazio disco erano minime. Con il +venir meno di queste restrizioni è incominciata ad emergere l'esigenza di +poter associare ai file delle ulteriori informazioni astratte (quelli che +abbiamo chiamato genericamente \textsl{metadati}) che però non potevano +trovare spazio nei dati classici mantenuti negli \textit{inode}. Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche Linux) hanno introdotto un meccanismo generico, detto \textit{Extended @@ -4748,10 +4735,10 @@ efficienti,\footnote{cosa molto importante, specie per le applicazioni che richiedono una gran numero di accessi, come le ACL.} e di garantire l'atomicità di tutte le operazioni. -In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode} -\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura -il valore corrente viene scritto su un buffer in memoria, mentre la scrittura -prevede che ogni valore precedente sia sovrascritto. +In Linux gli attributi estesi sono sempre associati al singolo \textit{inode} +e l'accesso viene sempre eseguito in forma atomica, in lettura il valore +corrente viene scritto su un buffer in memoria, mentre la scrittura prevede +che ogni valore precedente sia sovrascritto. Si tenga presente che non tutti i filesystem supportano gli \textit{Extended Attributes}; al momento della scrittura di queste dispense essi sono @@ -4885,10 +4872,10 @@ tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi di scrittura completi su directory come \texttt{/tmp}. Per questo motivo, - per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit} - \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended - user attributes} soltanto se si è proprietari della stessa, o si hanno i - privilegi amministrativi della capacità \const{CAP\_FOWNER}. + per evitare eventuali abusi, se una directory ha lo \textit{sticky bit} + attivo sarà consentito scrivere i suoi \textit{extended user attributes} + soltanto se si è proprietari della stessa, o si hanno i privilegi + amministrativi della capacità \const{CAP\_FOWNER}. \end{basedescript} Le funzioni per la gestione degli attributi estesi, come altre funzioni di @@ -5124,12 +5111,11 @@ di \textit{POSIX 1003.1e Draft 17}, che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix ACL}. A differenza di altri sistemi, come ad esempio FreeBSD, nel caso di Linux si è -scelto di realizzare le ACL attraverso l'uso degli -\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in -sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione -tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi -delle ACL e presenta ai programmi una interfaccia che fa riferimento allo -standard POSIX 1003.1e. +scelto di realizzare le ACL attraverso l'uso degli \textit{Extended + Attributes} (appena trattati in sez.~\ref{sec:file_xattr}), e fornire tutte +le relative funzioni di gestione tramite una libreria, \texttt{libacl} che +nasconde i dettagli implementativi delle ACL e presenta ai programmi una +interfaccia che fa riferimento allo standard POSIX 1003.1e. Anche in questo caso le funzioni di questa libreria non fanno parte della \acr{glibc} e devono essere installate a parte;\footnote{la versione corrente @@ -5211,9 +5197,8 @@ fosse specificato un permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa associata ad una \textit{Default ACL} su una directory, in quanto i permessi così specificati verranno ereditati da tutti i file creati -nella stessa directory. Si ottiene così una sorta di \itindex{umask} -\textit{umask} associata ad un oggetto sul filesystem piuttosto che a un -processo. +nella stessa directory. Si ottiene così una sorta di \textit{umask} associata +ad un oggetto sul filesystem piuttosto che a un processo. Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno dei problemi che si erano posti nella loro standardizzazione era appunto @@ -5222,9 +5207,8 @@ ordinari vengono mappati nelle tre voci di tipo \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in qualunque ACL; un cambiamento ad una di queste voci viene automaticamente riflesso sui permessi ordinari dei file e viceversa.\footnote{per permessi - ordinari si intende quelli mantenuti \itindex{inode} nell'\textit{inode}, - che devono restare dato che un filesystem può essere montato senza abilitare - le ACL.} + ordinari si intende quelli mantenuti nell'\textit{inode}, che devono restare + dato che un filesystem può essere montato senza abilitare le ACL.} In realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e \const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto @@ -5248,11 +5232,11 @@ quello relativo alla creazione di nuovi file,\footnote{o oggetti sul presenza di una \textit{Default ACL} sulla directory che andrà a contenerli. Se questa non c'è valgono le regole usuali illustrate in sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla -\itindex{umask} \textit{umask} del processo, e la sola differenza è che i -permessi ordinari da esse risultanti vengono automaticamente rimappati anche -su una ACL di accesso assegnata automaticamente al nuovo file, che contiene -soltanto le tre corrispondenti voci di tipo \const{ACL\_USER\_OBJ}, -\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}. +\textit{umask} del processo, e la sola differenza è che i permessi ordinari da +esse risultanti vengono automaticamente rimappati anche su una ACL di accesso +assegnata automaticamente al nuovo file, che contiene soltanto le tre +corrispondenti voci di tipo \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e +\const{ACL\_OTHER}. Se invece è presente una ACL di default sulla directory che contiene il nuovo file, essa diventerà automaticamente anche la ACL di accesso di quest'ultimo, @@ -5919,7 +5903,7 @@ conclude l'esecuzione. Quella delle quote disco è una funzionalità introdotta inizialmente da BSD e presente in Linux fino dai kernel dalla serie 2.0, che consente di porre dei tetti massimi al consumo delle risorse di un filesystem (spazio disco e -\itindex{inode} \textit{inode}) da parte di utenti e gruppi. +\textit{inode}) da parte di utenti e gruppi. Dato che la funzionalità ha senso solo per i filesystem su cui si mantengono i dati degli utenti\footnote{in genere la si attiva sul filesystem che contiene @@ -5976,7 +5960,7 @@ Si tenga presente infine che entrambi i tipi di limiti (\textit{soft limit} e \textit{hard limit}) possono essere disposti separatamente su entrambe le risorse di un filesystem, essi cioè possono essere presenti in maniera indipendente sia sullo spazio disco, con un massimo per il numero di blocchi, -che sui file, con un massimo per il numero di \itindex{inode} \textit{inode}. +che sui file, con un massimo per il numero di \textit{inode}. La funzione di sistema che consente di controllare tutti i vari aspetti della gestione delle quote è \funcd{quotactl}, ed il suo prototipo è: @@ -6159,18 +6143,18 @@ con \const{Q\_SETQUOTA} per effettuare modifiche ai limiti. Come si può notare ci sono alcuni campi (in sostanza \val{dqb\_curspace}, \val{dqb\_curinodes}, \val{dqb\_btime}, \val{dqb\_itime}) che hanno senso solo in lettura, in quanto riportano uno stato non modificabile da \func{quotactl} come l'uso corrente di -spazio disco ed \itindex{inode} \textit{inode}, o il tempo che resta nel caso -si sia superato un \textit{soft limit}. +spazio disco ed \textit{inode}, o il tempo che resta nel caso si sia superato +un \textit{soft limit}. Inoltre in caso di modifica di un limite si può voler operare solo su una -delle risorse (blocchi o \itindex{inode} \textit{inode}),\footnote{non è - possibile modificare soltanto uno dei limiti (\textit{hard} o \textit{soft}) - occorre sempre rispecificarli entrambi.} per questo la struttura prevede un -campo apposito, \val{dqb\_valid}, il cui scopo è quello di indicare quali sono -gli altri campi che devono essere considerati validi. Questo campo è una -maschera binaria che deve essere espressa nei termini di OR aritmetico delle -apposite costanti di tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il -significato di ciascuna di esse ed i campi a cui fanno riferimento. +delle risorse (blocchi o \textit{inode}),\footnote{non è possibile modificare + soltanto uno dei limiti (\textit{hard} o \textit{soft}) occorre sempre + rispecificarli entrambi.} per questo la struttura prevede un campo apposito, +\val{dqb\_valid}, il cui scopo è quello di indicare quali sono gli altri campi +che devono essere considerati validi. Questo campo è una maschera binaria che +deve essere espressa nei termini di OR aritmetico delle apposite costanti di +tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il significato di +ciascuna di esse ed i campi a cui fanno riferimento. \begin{table}[!htb] \centering @@ -6185,16 +6169,15 @@ significato di ciascuna di esse ed i campi a cui fanno riferimento. \val{dqb\_bsoftlimit}).\\ \const{QIF\_SPACE} & Uso corrente dello spazio disco (\val{dqb\_curspace}).\\ - \const{QIF\_ILIMITS}& Limiti sugli \itindex{inode} \textit{inode} + \const{QIF\_ILIMITS}& Limiti sugli \textit{inode} (\val{dqb\_ihardlimit} e \val{dqb\_isoftlimit}).\\ \const{QIF\_INODES} & Uso corrente degli \textit{inode} (\val{dqb\_curinodes}).\\ \const{QIF\_BTIME} & Tempo di sforamento del \textit{soft limit} sul numero di blocchi (\val{dqb\_btime}).\\ - \const{QIF\_ITIME} & Tempo di - sforamento del \textit{soft limit} sul numero di - \itindex{inode} \textit{inode} (\val{dqb\_itime}).\\ + \const{QIF\_ITIME} & Tempo di sforamento del \textit{soft limit} sul + numero di \textit{inode} (\val{dqb\_itime}).\\ \const{QIF\_LIMITS} & L'insieme di \const{QIF\_BLIMITS} e \const{QIF\_ILIMITS}.\\ \const{QIF\_USAGE} & L'insieme di \const{QIF\_SPACE} e @@ -6287,7 +6270,7 @@ significato di ciascuna di esse ed i campi a cui fanno riferimento. \const{IIF\_BGRACE}& Il \textit{grace period} per i blocchi (\val{dqi\_bgrace}).\\ \const{IIF\_IGRACE}& Il \textit{grace period} per gli \textit{inode} - \itindex{inode} (\val{dqi\_igrace}).\\ + (\val{dqi\_igrace}).\\ \const{IIF\_FLAGS} & I flag delle quote (\val{dqi\_flags}) (inusato ?).\\ \const{IIF\_ALL} & Tutti i precedenti.\\ \hline @@ -6342,7 +6325,7 @@ La funzione viene eseguita all'interno di un condizionale (\texttt{\small 5-16}) che in caso di successo provvede a costruire (\texttt{\small 6-12}) opportunamente una risposta restituendo tramite la opportuna funzione di interfaccia un oggetto Python contenente i dati della struttura \struct{dqblk} -relativi a uso corrente e limiti sia per i blocchi che per gli \itindex{inode} +relativi a uso corrente e limiti sia per i blocchi che per gli \textit{inode}. In caso di errore (\texttt{\small 13-15}) si usa un'altra funzione dell'interfaccia per passare il valore di \var{errno} come eccezione. @@ -6875,8 +6858,7 @@ opportuno dettagliare maggiormente. \const{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi sez.~\ref{sec:TCP_func_bind}).\\ \const{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in - \itindex{broadcast} \textit{broadcast} e - \itindex{multicast} \textit{multicast}.\\ + \textit{broadcast} e \textit{multicast}.\\ \const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\ \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle @@ -6958,7 +6940,7 @@ comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le impostazioni degli attributi dei file e delle ACL (vedi sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo -\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi +\textit{sticky bit} nella cancellazione dei file (vedi sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl_ioctl}) senza @@ -6967,9 +6949,9 @@ restrizioni. Una seconda capacità che copre diverse operazioni, in questo caso riguardanti la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare -il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle -interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la -tabella di instradamento. +il \textit{multicasting} (vedi sez.\ref{sec:sock_ipv4_options}), eseguire la +configurazione delle interfacce di rete (vedi +sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la tabella di instradamento. Una terza \textit{capability} con vasto campo di applicazione è \const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative, @@ -7659,11 +7641,6 @@ funzione. % sicurezza avanzate, con dentro chroot SELinux e AppArmor, Tomoyo, Smack, % cgroup o altro -% TODO: trattare la funzione setns e i namespace file descriptors (vedi -% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre -% informazioni su setns qui: http://lwn.net/Articles/532748/ -% http://lwn.net/Articles/531498/ - % TODO: spostare chroot e le funzioni affini relative ai container da qualche % parte diversa se è il caso. diff --git a/fileio.tex b/fileio.tex index 9e7e960..ba66a35 100644 --- a/fileio.tex +++ b/fileio.tex @@ -51,10 +51,10 @@ chiamata l'interfaccia dei \textit{file descriptor}. Per poter accedere al contenuto di un file occorre creare un canale di 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 VFS mette a disposizione (quelle di -tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il +sez.~\ref{sec:file_open_close}) che provvederà a localizzare l'\textit{inode} +del file e inizializzare i puntatori che rendono disponibili 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. @@ -98,10 +98,9 @@ particolare: \item la posizione corrente nel file, il cosiddetto \textit{offset}, nel campo \var{f\_pos}. \item un puntatore alla struttura \kstruct{inode} che identifica - \itindex{inode} l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in - realtà passati ad un puntatore ad una struttura \kstruct{dentry} che punta - a sua volta \itindex{inode} all'\textit{inode} passando per la nuova - struttura del VFS.} + l'\textit{inode} del file.\footnote{nel kernel 2.4.x si è in realtà passati + ad un puntatore ad una struttura \kstruct{dentry} che punta a sua volta + all'\textit{inode} passando per la nuova struttura del VFS.} \item un puntatore \var{f\_op} alla tabella delle funzioni che si possono usare sul file.\footnote{quelle della struttura \kstruct{file\_operation}, descritte sommariamente in tab.~\ref{tab:file_file_operations}.} @@ -120,6 +119,7 @@ In fig.~\ref{fig:file_proc_file} si è riportato uno schema semplificato in cui interrelazioni fra la \textit{file table}, la \textit{process table} e le varie strutture di dati che il kernel mantiene per ciascun file e ciascun processo. +\itindend{process~table} Come si può notare alla fine il collegamento che consente di porre in relazione i file ed i processi è effettuato attraverso i dati mantenuti nella @@ -130,7 +130,7 @@ essenziali come: \item il numero di file aperti dal processo. \item la \itindex{file~descriptor~table} \textit{file descriptor table}, una tabella con i puntatori, per ciascun file aperto, alla relativa voce nella - \itindex{file~table} \textit{file table}. + \textit{file table}. \end{itemize*} In questa infrastruttura un \textit{file descriptor} non è altro che l'intero @@ -141,25 +141,24 @@ processo a cui era stato assegnato questo indice. Una volta ottenuta grazie al voluto nella \textit{file table}, il kernel potrà usare le funzioni messe disposizione dal VFS per eseguire sul file tutte le operazioni necessarie. -\itindend{process~table} -\itindend{file~table} - - Il meccanismo dell'apertura dei file prevede che venga sempre fornito il primo \textit{file descriptor} libero nella tabella, e per questo motivo essi vengono assegnati in successione tutte le volte che si apre un nuovo file, posto che non ne sia stato chiuso nessuno in precedenza. +\itindbeg{standard~input} +\itindbeg{standard~output} +\itindbeg{standard~error} + In tutti i sistemi unix-like esiste una convenzione generale per cui ogni processo si aspetta di avere sempre tre file aperti che, per quanto appena detto, avranno come \itindex{file~descriptor} \textit{file descriptor} i valori 0, 1 e 2. Il primo file è sempre associato al cosiddetto -\itindex{standard~input} \textit{standard input}, è cioè il file da cui un -processo si aspetta di dover leggere i dati in ingresso. Il secondo file è il -cosiddetto \itindex{standard~output} \textit{standard output}, cioè quello su -cui ci si aspetta di dover scrivere i dati in uscita. Il terzo è lo -\itindex{standard~error} \textit{standard error}, su cui vengono scritti i -dati relativi agli errori. +\textit{standard input}, è cioè il file da cui un processo si aspetta di dover +leggere i dati in ingresso. Il secondo file è il cosiddetto \textit{standard + output}, cioè quello su cui ci si aspetta di dover scrivere i dati in +uscita. Il terzo è lo \textit{standard error}, su cui +vengono scritti i dati relativi agli errori. Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe portare a problemi di @@ -191,27 +190,28 @@ tab.~\ref{tab:file_std_files}. \label{tab:file_std_files} \end{table} +\itindend{standard~input} +\itindend{standard~output} +\itindend{standard~error} + In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa rispetto a quella usuale della shell, in cui tutti e tre questi file fanno riferimento al terminale su cui si opera. Nell'esempio invece viene illustrata -la situazione di un programma in cui lo \itindex{standard~input} -\textit{standard input} è associato ad un file mentre lo -\itindex{standard~output} \textit{standard output} e lo -\itindex{standard~error} \textit{standard error} sono associati ad un altro -file. Si noti poi come per questi ultimi le strutture \kstruct{file} nella -\itindex{file~table} \textit{file table}, pur essendo distinte, fanno -riferimento allo stesso \itindex{inode} \textit{inode}, dato che il file che è -stato aperto lo stesso. Questo è quello che avviene normalmente quando si apre -più volte lo stesso file. - -Si ritrova quindi anche con le voci della \itindex{file~table} \textit{file - table} una situazione analoga di quella delle voci di una directory, con la -possibilità di avere più voci che fanno riferimento allo stesso -\itindex{inode} \textit{inode}. L'analogia è in realtà molto stretta perché -quando si cancella un file, il kernel verifica anche che non resti nessun -riferimento in una una qualunque voce della \itindex{file~table} \textit{file +la situazione di un programma in cui lo \textit{standard input} è associato ad +un file mentre lo \textit{standard output} e lo \textit{standard error} sono +associati ad un altro file. Si noti poi come per questi ultimi le strutture +\kstruct{file} nella \textit{file table}, pur essendo distinte, fanno +riferimento allo stesso \textit{inode}, dato che il file che è stato aperto lo +stesso. Questo è quello che avviene normalmente quando si apre più volte lo +stesso file. + +Si ritrova quindi anche con le voci della \textit{file table} una situazione +analoga di quella delle voci di una directory, con la possibilità di avere più +voci che fanno riferimento allo stesso \textit{inode}. L'analogia è in realtà +molto stretta perché quando si cancella un file, il kernel verifica anche che +non resti nessun riferimento in una una qualunque voce della \textit{file table} prima di liberare le risorse ad esso associate e disallocare il -relativo \itindex{inode} \textit{inode}. +relativo \textit{inode}. Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il numero di file aperti era anche soggetto ad un limite massimo dato dalle @@ -221,6 +221,7 @@ più recenti non sussiste più, dato che si è passati da un vettore ad una lista, ma restano i limiti imposti dall'amministratore (vedi sez.~\ref{sec:sys_limits}). +\itindend{file~table} \subsection{Apertura, creazione e chiusura di un file} @@ -1566,8 +1567,8 @@ quando un \textit{pathname} relativo non fa riferimento ad un file posto 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 \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}). +c'è spazio per un \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 diff --git a/ipc.tex b/ipc.tex index 092d40f..33319a7 100644 --- a/ipc.tex +++ b/ipc.tex @@ -999,9 +999,8 @@ con i 16 bit meno significativi \itindex{inode} dell'inode del file \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori), e gli 8 bit meno significativi del numero del dispositivo su cui è il file. Diventa perciò relativamente facile ottenere delle -collisioni, specie se i file sono su dispositivi con lo stesso -\itindex{minor~number} \textit{minor number}, come \file{/dev/hda1} e -\file{/dev/sda1}. +collisioni, specie se i file sono su dispositivi con lo stesso \textit{minor + number}, come \file{/dev/hda1} e \file{/dev/sda1}. In genere quello che si fa è utilizzare un file comune usato dai programmi che devono comunicare (ad esempio un header comune, o uno dei programmi che devono @@ -1314,22 +1313,26 @@ l'uso di \func{sysctl} o scrivendo nei file \sysctlrelfile{kernel}{msgmax}, \sysctlrelfile{kernel}{msgmnb} e \sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}. -Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked - list}.\footnote{una \itindex{linked~list} \textit{linked list} è una tipica - struttura di dati, organizzati in una lista in cui ciascun elemento contiene - un puntatore al successivo. In questo modo la struttura è veloce - nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta - aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e - relativamente veloce da attraversare in ordine sequenziale (seguendo i - puntatori), è invece relativamente lenta nell'accesso casuale e nella - ricerca.} I nuovi messaggi vengono inseriti in coda alla lista e vengono -letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato uno schema -semplificato con cui queste strutture vengono mantenute dal kernel. Lo schema -illustrato in realtà è una semplificazione di quello usato fino ai kernel -della serie 2.2. A partire della serie 2.4 la gestione delle code di messaggi -è effettuata in maniera diversa (e non esiste una struttura \struct{msqid\_ds} -nel kernel), ma abbiamo mantenuto lo schema precedente dato che illustra in -maniera più che adeguata i principi di funzionamento delle code di messaggi. +\itindbeg{linked~list} + +Una coda di messaggi è costituita da una \textit{linked list}.\footnote{una + \itindex{linked~list} \textit{linked list} è una tipica struttura di dati, + organizzati in una lista in cui ciascun elemento contiene un puntatore al + successivo. In questo modo la struttura è veloce nell'estrazione ed + immissione dei dati dalle estremità dalla lista (basta aggiungere un + elemento in testa o in coda ed aggiornare un puntatore), e relativamente + veloce da attraversare in ordine sequenziale (seguendo i puntatori), è + invece relativamente lenta nell'accesso casuale e nella ricerca.} I nuovi +messaggi vengono inseriti in coda alla lista e vengono letti dalla cima, in +fig.~\ref{fig:ipc_mq_schema} si è riportato uno schema semplificato con cui +queste strutture vengono mantenute dal kernel. Lo schema illustrato in realtà +è una semplificazione di quello usato fino ai kernel della serie 2.2. A +partire della serie 2.4 la gestione delle code di messaggi è effettuata in +maniera diversa (e non esiste una struttura \struct{msqid\_ds} nel kernel), ma +abbiamo mantenuto lo schema precedente dato che illustra in maniera più che +adeguata i principi di funzionamento delle code di messaggi. + +\itindend{linked~list} \begin{figure}[!htb] \centering \includegraphics[width=13cm]{img/mqstruct} @@ -3323,7 +3326,7 @@ relativamente poco diffuso. \subsection{I \textsl{file di lock}} \label{sec:ipc_file_lock} -\index{file!di lock|(} +\index{file!di~lock|(} Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV-IPC} presentano una interfaccia inutilmente complessa e con alcuni difetti @@ -3396,23 +3399,23 @@ usa spesso per evitare interferenze sull'uso delle porte seriali da parte di più programmi: qualora si trovi un file di lock il programma che cerca di accedere alla seriale si limita a segnalare che la risorsa non è disponibile. -\index{file!di lock|)} +\index{file!di~lock|)} \subsection{La sincronizzazione con il \textit{file locking}} \label{sec:ipc_lock_file} -Dato che i \index{file!di lock} file di lock presentano gli inconvenienti -illustrati in precedenza, la tecnica alternativa di sincronizzazione più -comune è quella di fare ricorso al \itindex{file~locking} \textit{file - locking} (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un -file creato per l'occasione per ottenere un write lock. In questo modo potremo -usare il lock come un \textit{mutex}: per bloccare la risorsa basterà -acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta -fatta con un write lock metterà automaticamente il processo in stato di -attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per -determinare la disponibilità della risorsa, e al rilascio della stessa da -parte del processo che la occupava si otterrà il nuovo lock atomicamente. +Dato che i file di lock presentano gli inconvenienti illustrati in precedenza, +la tecnica alternativa di sincronizzazione più comune è quella di fare ricorso +al \itindex{file~locking} \textit{file locking} (trattato in +sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file creato per +l'occasione per ottenere un write lock. In questo modo potremo usare il lock +come un \textit{mutex}: per bloccare la risorsa basterà acquisire il lock, per +sbloccarla basterà rilasciare il lock. Una richiesta fatta con un write lock +metterà automaticamente il processo in stato di attesa, senza necessità di +ricorrere al \itindex{polling} \textit{polling} per determinare la +disponibilità della risorsa, e al rilascio della stessa da parte del processo +che la occupava si otterrà il nuovo lock atomicamente. Questo approccio presenta il notevole vantaggio che alla terminazione di un processo tutti i lock acquisiti vengono rilasciati automaticamente (alla diff --git a/network.tex b/network.tex index 7227fe8..490112b 100644 --- a/network.tex +++ b/network.tex @@ -158,6 +158,53 @@ questo modo si può distribuire il carico ed accedere in maniera efficiente i dati. +\subsection{Il modello \textit{broadcast}} +\label{sec:net_broadcast} + +Uno specifico modello relativo alla programmazione di rete è poi quello in cui +è possibile, invece della classica comunicazione uno ad uno comunque usata in +tutti i modelli precedenti (anche nel \texttt{peer to peer} la comunicazione è +comunque fra singoli ``\textit{peer}''), una comunicazione da uno a molti. + +\itindbeg{broadcast} + +Questo modello nasce dal fatto che molte tecnologie di rete (ed in particolare +la Ethernet, che è probabilmente la più diffusa) hanno il supporto per +effettuare una comunicazione in cui un nodo qualunque della rete più inviare +informazioni in contemporanea a tutti gli altri. In questo caso si parla di +\textit{broadcast}, utilizzando la nomenclatura usata per le trasmissioni +radio, anche se in realtà questo tipo di comunicazione è eseguibile da un nodo +qualunque per cui tutti quanti possono ricoprire sia il ruolo di trasmettitore +che quello di ricevitore. + +\itindbeg{multicast} + +In genere si parla di \textit{broadcast} quando la trasmissione uno a molti è +possibile fra qualunque nodo di una rete e gli altri, ed è supportata +direttamente dalla tecnologia di collegamento utilizzata. L'utilizzo di questa +forma di comunicazione da uno a molti però può risultare molto utile anche +quando questo tipo di supporto non è disponibile (come ad esempio su Internet, +dove non si possono contattare tutti i nodi presenti). + +\itindend{broadcast} + +In tal caso alcuni protocolli di rete (e quelli usati per Internet sono fra +questi) supportano una variante del\textit{broadcast}, detta +\textit{multicast}, in cui resta possibile fare una comunicazione uno a molti, +in cui una applicazione invia i pacchetti a molte altre, in genere passando +attraverso un opportuno supporto degli apparati ed una qualche forma di +registrazione che consente la distribuzione della cominicazione ai nodi +interessati. + +\itindend{multicast} + +Ovviamente i programmi che devono realizzare un tipo di comunicazione di +questo tipo (come ad esempio potrebbero essere quelli che effettuano uno +\textit{streaming} di informazioni) devono rispondere a delle problematiche +del tutto diverse da quelle classiche illustrate nei modelli precedenti, e +costituiscono pertanto un'altra classe completamente a parte. + + \section{I protocolli di rete} \label{sec:net_protocols} @@ -421,7 +468,7 @@ molti membri. In fig.~\ref{fig:net_tcpip_overview} si è riportato uno schema che mostra un panorama sui principali protocolli della famiglia, e delle loro relazioni reciproche e con alcune dalle principali applicazioni che li usano. -\begin{figure}[!htbp] +\begin{figure}[!htb] \centering \includegraphics[width=13cm]{img/tcpip_overview} \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.} diff --git a/prochand.tex b/prochand.tex index a16a9ae..eb37253 100644 --- a/prochand.tex +++ b/prochand.tex @@ -3629,7 +3629,7 @@ l'operazione, e deve essere specificato con l'uso di una delle costanti predefinite del seguente elenco, che illustra quelle disponibili al momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.} -\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} +\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}} \item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una @@ -3952,7 +3952,6 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. \end{basedescript} - \subsection{La \textit{system call} \func{clone}} \label{sec:process_clone} @@ -3977,12 +3976,21 @@ processi ordinari, abbiamo deciso di usare la nomenclatura \textit{task} per indicare la unità di esecuzione generica messa a disposizione del kernel che \texttt{sys\_clone} permette di creare. +\itindbeg{namespace} +\itindbeg{container} + Oltre a questo la funzione consente, ad uso delle nuove funzionalità di -virtualizzazione dei processi, di creare nuovi \textit{namespace} per una -serie di proprietà generali dei processi (come l'elenco dei \ids{PID}, -l'albero dei file, i \textit{mount point}, la rete, ecc.), che consentono di -creare gruppi di processi che vivono in una sorta di spazio separato dagli -altri, che costituisce poi quello che viene chiamato un \textit{container}. +virtualizzazione dei processi, di creare nuovi ``\textit{namespace}'' per una +serie di proprietà generali (come l'elenco dei \ids{PID}, l'albero dei file, i +\textit{mount point}, la rete, il sistema di IPC, ecc.). L'uso dei +``\textit{namespace}'' consente creare gruppi di processi che vedono le +suddette proprietà in maniera indipendente fra loro. I processi di ciascun +gruppo vengono così eseguiti come in una sorta di spazio separato da quello +degli altri gruppi, che costituisce poi quello che viene chiamato un +\textit{container}. + +\itindend{namespace} +\itindend{container} La \textit{system call} richiede soltanto due argomenti: il primo, \param{flags}, consente di controllare le modalità di creazione del @@ -4097,15 +4105,19 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa riferimento al momento della stesura di questa sezione, cioè con il kernel 3.2.} -\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} +\begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}} + +\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread + ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un + riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a + quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei + \textit{thread} ed è presente dal kernel 2.5.49. -\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID} - all'indirizzo dato dall'argomento \param{ctid}, eseguendo un riattivazione - del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a quell'indirizzo; questo - flag viene utilizzato dalla librerie di gestione dei \textit{thread}. \item[\const{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread} figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene - utilizzato dalla librerie di gestione dei \textit{thread}. + utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal + kernel 2.5.49. + \item[\const{CLONE\_FILES}] se impostato il nuovo processo condividerà con il padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}), questo significa che ogni \textit{file descriptor} aperto da un processo @@ -4129,12 +4141,39 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa informazioni, che saranno così indipendenti per i due processi, come avviene nel comportamento ordinario di un sistema unix-like. -\item[\const{CLONE\_IO}] -\item[\const{CLONE\_NEWIPC}] -\item[\const{CLONE\_NEWNET}] -\item[\const{CLONE\_NEWNS}] -\item[\const{CLONE\_NEWPID}] -\item[\const{CLONE\_NEWUTS}] +\item[\const{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo + processo condividerà con il padre il contesto dell'I/O, altrimenti, come + come avviene nel comportamento ordinario con una \func{fork} otterrà un suo + contesto dell'I/O. + + Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in + sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi + questi vengono trattati come se fossero lo stesso, condividendo il tempo per + l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di + questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto + dello stesso processo (ad esempio con le funzioni di I/O asincrono di + sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni. + +%TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella +%relativa sezione da creare a parte + +% \item[\const{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container}, +% introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo +% processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello +% di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code +% di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a +% tutti quegli oggetti che non vegono identificati con un \textit{pathname} +% sull'albero dei file. + +% L'uso di questo flag richiede privilegi di amministratore (più precisamente +% la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione +% con \const{CLONE\_SYSVSEM}. + +% \item[\const{CLONE\_NEWNET}] +% \item[\const{CLONE\_NEWNS}] +% \item[\const{CLONE\_NEWPID}] +% \item[\const{CLONE\_NEWUTS}] + \item[\const{CLONE\_PARENT}] \item[\const{CLONE\_PARENT\_SETTID}] \item[\const{CLONE\_PID}] @@ -4146,20 +4185,34 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa \item[\const{CLONE\_THREAD}] \item[\const{CLONE\_UNTRACED}] \item[\const{CLONE\_VFORK}] -\item[\const{CLONE\_VM}] +\item[\const{CLONE\_VM}] se questo flag viene impostato il nuovo processo + condividerà con il padre la stessa memoria virtuale, e le scritture in + memoria fatte da uno qualunque dei processi saranno visibili dall'altro, + così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}). + + Se non viene impostato il processo figlio otterrà una copia dello spazio + degli indirizzi e si otterrà il comportamento ordinario di un processo di un + sistema unix-like creato con la funzione \func{fork}. \end{basedescript} +%TODO sezione separata sui namespace + %TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/ +%TODO: trattare la funzione setns e i namespace file descriptors (vedi +% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre +% informazioni su setns qui: http://lwn.net/Articles/532748/ +% http://lwn.net/Articles/531498/ + %TODO trattare kcmp aggiunta con il kernel 3.5, vedi % https://lwn.net/Articles/478111/ -\subsection{La funzione \func{ptrace}} -\label{sec:process_ptrace} +%\subsection{La funzione \func{ptrace}} +%\label{sec:process_ptrace} -Da fare +%Da fare % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1 % TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi @@ -4169,18 +4222,18 @@ Da fare % TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi % http://lwn.net/Articles/656675/ -\subsection{La gestione delle operazioni in virgola mobile} -\label{sec:process_fenv} +%\subsection{La gestione delle operazioni in virgola mobile} +%\label{sec:process_fenv} -Da fare. +%Da fare. % TODO eccezioni ed arrotondamenti per la matematica in virgola mobile % consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater, % isnan, nan, INFINITY -\subsection{L'accesso alle porte di I/O} -\label{sec:process_io_port} +%\subsection{L'accesso alle porte di I/O} +%\label{sec:process_io_port} % % TODO l'I/O sulle porte di I/O @@ -4188,7 +4241,7 @@ Da fare. % non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in % fileintro ?) -Da fare +%Da fare %\subsection{La gestione di architetture a nodi multipli} diff --git a/sockctrl.tex b/sockctrl.tex index 429fdec..5906b98 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -2599,10 +2599,8 @@ Infine il quarto caso è quello in cui si vuole effettivamente ottenere un \func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un altro socket. Questo ovviamente non ha senso per il normale traffico di rete, in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma -quando un sistema supporta il traffico in \itindex{multicast} -\textit{multicast}, in cui una applicazione invia i pacchetti a molte altre -(vedi sez.~\ref{sec:xxx_multicast}), allora ha senso che su una macchina i -pacchetti provenienti dal traffico in \itindex{multicast} \textit{multicast} +quando un sistema supporta il traffico in \textit{multicast}, allora ha senso +che su una macchina i pacchetti provenienti dal traffico in \textit{multicast} possano essere ricevuti da più applicazioni\footnote{l'esempio classico di traffico in \textit{multicast} è quello di uno streaming di dati (audio, video, ecc.), l'uso del \textit{multicast} consente in tal caso di @@ -2611,7 +2609,6 @@ possano essere ricevuti da più applicazioni\footnote{l'esempio classico di questo caso è perfettamente logico aspettarsi che sulla stessa macchina più utenti possano lanciare un programma che permetta loro di ricevere gli stessi dati.} o da diverse istanze della stessa applicazione. -\itindex{multicast} In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da @@ -2619,10 +2616,10 @@ un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di applicazione è normale l'uso del protocollo UDP). La regola è che quando si hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di -tutti pacchetti destinati ad un indirizzo di \itindex{broadcast} -\textit{broadcast} o di \itindex{multicast} \textit{multicast} viene inviata -una copia a ciascuna applicazione. Non è definito invece cosa accade qualora -il pacchetto sia destinato ad un indirizzo normale (unicast). +tutti pacchetti destinati ad un indirizzo di \textit{broadcast} o di +\textit{multicast} viene inviata una copia a ciascuna applicazione. Non è +definito invece cosa accade qualora il pacchetto sia destinato ad un indirizzo +normale (unicast). Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta @@ -2787,17 +2784,15 @@ file. \const{IP\_ROUTER\_ALERT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& Imposta l'opzione \textit{IP router alert} sui pacchetti.\\ \const{IP\_MULTICAST\_TTL} &$\bullet$&$\bullet$& &\texttt{int}& - Imposta il TTL per i pacchetti \itindex{multicast} \textit{multicast}.\\ + Imposta il TTL per i pacchetti \textit{multicast}.\\ \const{IP\_MULTICAST\_LOOP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}& - Controlla il reinvio a se stessi dei dati di \itindex{multicast} - \textit{multicast}.\\ + Controlla il reinvio a se stessi dei dati di \textit{multicast}.\\ \const{IP\_ADD\_MEMBERSHIP} & &$\bullet$& &\struct{ip\_mreqn}& - Si unisce a un gruppo di \itindex{multicast} \textit{multicast}.\\ + Si unisce a un gruppo di \textit{multicast}.\\ \const{IP\_DROP\_MEMBERSHIP}& &$\bullet$& &\struct{ip\_mreqn}& Si sgancia da un gruppo di \textit{multicast}.\\ \const{IP\_MULTICAST\_IF} & &$\bullet$& &\struct{ip\_mreqn}& - Imposta l'interfaccia locale di un socket \itindex{multicast} - \textit{multicast}.\\ + Imposta l'interfaccia locale di un socket \textit{multicast}.\\ \hline \end{tabular} \caption{Le opzioni disponibili al livello \const{SOL\_IP}.} @@ -3028,7 +3023,6 @@ sez.~\ref{sec:net_sendmsg}). sez.~\ref{sec:IP_options}) che devono essere inoltrati al socket corrente. Può essere usata soltanto per socket di tipo raw. -\itindbeg{multicast} \item[\const{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il valore del campo TTL per i pacchetti \textit{multicast} in uscita associati al socket. È importante che questo valore sia il più basso possibile, ed il @@ -3085,7 +3079,6 @@ sez.~\ref{sec:net_sendmsg}). % TODO chiarire quale è la struttura \struct{ip\_mreq} -\itindend{multicast} \end{basedescript} @@ -3709,14 +3702,13 @@ Le costanti che identificano le operazioni disponibili sono le seguenti: pacchetti che vede passare, compresi quelli non direttamente indirizzati a lei).\\ \const{IFF\_NOTRAILERS}& Evita l'uso di \textit{trailer} nei pacchetti.\\ - \const{IFF\_ALLMULTI} & Riceve tutti i pacchetti di \itindex{multicast} - \textit{multicast}.\\ + \const{IFF\_ALLMULTI} & Riceve tutti i pacchetti di \textit{multicast}.\\ \const{IFF\_MASTER} & L'interfaccia è il master di un bundle per il bilanciamento di carico.\\ \const{IFF\_SLAVE} & L'interfaccia è uno slave di un bundle per il bilanciamento di carico.\\ \const{IFF\_MULTICAST} & L'interfaccia ha il supporto per il - \textit{multicast} \itindex{multicast} attivo.\\ + \textit{multicast} attivo.\\ \const{IFF\_PORTSEL} & L'interfaccia può impostare i suoi parametri hardware (con l'uso di \struct{ifmap}).\\ \const{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare @@ -3797,19 +3789,19 @@ Le costanti che identificano le operazioni disponibili sono le seguenti: struttura \struct{ifmap}, secondo la definizione di fig.~\ref{fig:netdevice_ifmap_struct}. -\item[\const{SIOCADDMULTI}] aggiunge un indirizzo di \itindex{multicast} - \textit{multicast} ai filtri del livello di collegamento associati - dell'interfaccia. Si deve usare un indirizzo hardware da specificare - attraverso il campo \var{ifr\_hwaddr}, che conterrà l'opportuna struttura - \struct{sockaddr}; l'operazione è privilegiata. Per una modalità alternativa - per eseguire la stessa operazione si possono usare i \textit{packet socket}, - vedi sez.~\ref{sec:packet_socket}. - -\item[\const{SIOCDELMULTI}] rimuove un indirizzo di \itindex{multicast} - \textit{multicast} ai filtri del livello di collegamento dell'interfaccia, - vuole un indirizzo hardware specificato come per \const{SIOCADDMULTI}. Anche - questa operazione è privilegiata e può essere eseguita in forma alternativa - con i \textit{packet socket}. +\item[\const{SIOCADDMULTI}] aggiunge un indirizzo di \textit{multicast} ai + filtri del livello di collegamento associati dell'interfaccia. Si deve usare + un indirizzo hardware da specificare attraverso il campo \var{ifr\_hwaddr}, + che conterrà l'opportuna struttura \struct{sockaddr}; l'operazione è + privilegiata. Per una modalità alternativa per eseguire la stessa operazione + si possono usare i \textit{packet socket}, vedi + sez.~\ref{sec:packet_socket}. + +\item[\const{SIOCDELMULTI}] rimuove un indirizzo di \textit{multicast} ai + filtri del livello di collegamento dell'interfaccia, vuole un indirizzo + hardware specificato come per \const{SIOCADDMULTI}. Anche questa operazione + è privilegiata e può essere eseguita in forma alternativa con i + \textit{packet socket}. \item[\const{SIOCGIFTXQLEN}] permette di leggere la lunghezza della coda di trasmissione del dispositivo associato all'interfaccia specificata nel campo diff --git a/socket.tex b/socket.tex index d3bbecc..7e79d39 100644 --- a/socket.tex +++ b/socket.tex @@ -9,7 +9,7 @@ %% License". %% -\chapter{Introduzione ai socket} +\chapter{I socket} \label{cha:socket_intro} In questo capitolo inizieremo a spiegare le caratteristiche salienti della @@ -22,16 +22,18 @@ come creare un socket e come collegarlo allo specifico protocollo di rete che si utilizzerà per la comunicazione. Per evitare un'introduzione puramente teorica concluderemo il capitolo con un primo esempio di applicazione. -\section{Una panoramica} +\section{Introduzione ai socket} \label{sec:sock_overview} -Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di -quali sono i concetti fondamentali da tenere presente quando si ha a che fare -con essi. +In questa sezione daremo descrizione essenziale di cosa sono i \textit{socket} +e di quali sono i concetti fondamentali da tenere presente quando si ha a che +fare con essi; ne illustreremo poi le caratteristiche e le differenti +tipologie presenti ed infine tratteremo le modalità con cui possono essere +creati. \index{socket!definizione|(} -\subsection{I \textit{socket}} +\subsection{Cosa sono \textit{socket}} \label{sec:sock_socket_def} I \textit{socket} (una traduzione letterale potrebbe essere \textsl{presa}, ma @@ -62,24 +64,20 @@ utilizzare i socket con i più disparati meccanismi di comunicazione, e non solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella di cui tratteremo in maniera più estesa. - -\subsection{Concetti base} -\label{sec:sock_gen} - Per capire il funzionamento dei socket occorre avere presente il funzionamento -dei protocolli di rete che su utilizzeranno (vedi cap.~\ref{cha:network}), ma -l'interfaccia è del tutto generale e benché le problematiche, e quindi le -modalità di risolvere i problemi, siano diverse a seconda del tipo di -protocollo di comunicazione usato, le funzioni da usare nella gestione dei -socket restano le stesse. +dei protocolli di rete che su utilizzeranno (ed in particolare quelli del +TCP/IP già illustrati in sez.~\ref{sec:net_tpcip}), ma l'interfaccia è del +tutto generale e benché le problematiche, e quindi le modalità di risolvere i +problemi, siano diverse a seconda del tipo di protocollo di comunicazione +usato, le funzioni da usare nella gestione dei socket restano le stesse. Per questo motivo una semplice descrizione dell'interfaccia è assolutamente inutile, in quanto il comportamento di quest'ultima e le problematiche da affrontare cambiano radicalmente a seconda del tipo di comunicazione usato. -La scelta di questo tipo (sovente anche detto \textsl{stile}) va infatti ad -incidere sulla semantica che verrà utilizzata a livello utente per gestire la -comunicazione cioè su come inviare e ricevere i dati e sul comportamento -effettivo delle funzioni utilizzate. +La scelta di questo tipo di comunicazione (sovente anche detto \textsl{stile}) +va infatti ad incidere sulla semantica che verrà utilizzata a livello utente +per gestire la comunicazione cioè su come inviare e ricevere i dati e sul +comportamento effettivo delle funzioni utilizzate. La scelta di uno \textsl{stile} dipende sia dai meccanismi disponibili, sia dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni tipi di @@ -100,18 +98,21 @@ cui essa avviene nei confronti dei corrispondenti, in certi casi essa può essere condotta con una connessione diretta con un solo corrispondente, come per una telefonata; altri casi possono prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su ogni pacchetto, altri ancora una -comunicazione \itindex{broadcast} \textit{broadcast} come per la radio, in cui -i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove chiunque si -collega possa riceverli. +comunicazione uno a molti come il \textit{broadcast} ed il \textit{multicast}, +in cui i pacchetti possono venire emessi su appositi ``\textsl{canali}'' dove +chiunque si collega possa riceverli. -É chiaro che ciascuno di questi diversi aspetti associato ad un tipo di -comunicazione comporta una modalità diversa di gestire la stessa, ad esempio -se è inaffidabile occorrerà essere in grado di gestire la perdita o il -rimescolamento dei dati, se è a pacchetti questi dovranno essere -opportunamente trattati, ecc. +É chiaro che ciascuno di questi diversi aspetti è associato ad un tipo di +comunicazione che comporta una modalità diversa di gestire la stessa, ad +esempio se la comunicazione è inaffidabile occorrerà essere in grado di +gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi +dovranno essere opportunamente trattati, se è uno a molti occorrerà tener +conto della eventuale unidirezionalità della stessa, ecc. + +\index{socket!definizione|)} -\section{La creazione di un socket} +\subsection{La creazione di un socket} \label{sec:sock_creation} Come accennato l'interfaccia dei socket è estremamente flessibile e permette @@ -119,9 +120,6 @@ di interagire con protocolli di comunicazione anche molto diversi fra di loro; in questa sezione vedremo come è possibile creare un socket e come specificare il tipo di comunicazione che esso deve utilizzare. -\subsection{La funzione \func{socket}} -\label{sec:sock_socket} - La creazione di un socket avviene attraverso l'uso della funzione di sistema \funcd{socket}; essa restituisce un \textit{file descriptor} (del tutto analogo a quelli che si ottengono per i file di dati e le \textit{pipe}, @@ -560,7 +558,7 @@ il loro uso è sperimentale. Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni -riguardanti il \itindex{multicast} \textit{multicasting}. Si noti infine che +riguardanti il \textit{multicasting}. Si noti infine che \struct{sockaddr\_in6} ha una dimensione maggiore della struttura \struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità @@ -744,12 +742,11 @@ pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i seguenti valori: \const{PACKET\_HOST} per un pacchetto indirizzato alla macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di -\itindex{broadcast} \textit{broadcast}, \const{PACKET\_MULTICAST} per un -pacchetto inviato ad un indirizzo fisico di \itindex{multicast} -\textit{multicast}, \const{PACKET\_OTHERHOST} per un pacchetto inviato ad -un'altra stazione (e ricevuto su un'interfaccia in \index{modo~promiscuo} modo -promiscuo), \const{PACKET\_OUTGOING} per un pacchetto originato dalla propria -macchina che torna indietro sul socket. +\textit{broadcast}, \const{PACKET\_MULTICAST} per un pacchetto inviato ad un +indirizzo fisico di \textit{multicast}, \const{PACKET\_OTHERHOST} per un +pacchetto inviato ad un'altra stazione (e ricevuto su un'interfaccia in +\index{modo~promiscuo} modo promiscuo), \const{PACKET\_OUTGOING} per un +pacchetto originato dalla propria macchina che torna indietro sul socket. Si tenga presente infine che in fase di ricezione, anche se si richiede il @@ -953,8 +950,6 @@ Il formato usato per gli indirizzi in formato di presentazione è la notazione \textit{dotted decimal} per IPv4 e quello descritto in sez.~\ref{sec:IP_ipv6_notation} per IPv6. -\index{socket!definizione|)} - diff --git a/tcpsock.tex b/tcpsock.tex index 5d0a01b..d0dea20 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -653,7 +653,7 @@ figlio e quelli che arrivano alla porta 21101 al secondo. In questa sezione descriveremo in maggior dettaglio le varie funzioni che vengono usate per la gestione di base dei socket TCP, non torneremo però sulla funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo -precedente in sez.~\ref{sec:sock_socket}. +precedente in sez.~\ref{sec:sock_creation}. \subsection{La funzione \func{bind}} -- 2.30.2