fileunix.tex

   1 \chapter{L'interfaccia unix di I/O con i file}
   2 \label{cha:file_unix_interface}
   3
   4 Esamineremo in questo capitolo la prima delle due interfacce di programmazione
   5 per i file, quella dei \textit{file descriptor}, nativa di unix. Questa è
   6 l'interfaccia di basso livello, che non prevede funzioni evolute come la
   7 bufferizzazione o funzioni di lettura o scrittura formattata, ma è su questa
   8 che è costruita anche l'interfaccia standard dei file definita dallo standard
   9 ANSI C.
  10
  11
  12
  13 \section{L'architettura di base}
  14 \label{sec:file_base_arch}
  15
  16 In questa sezione faremo una breve introduzione sulla architettura su cui è
  17 basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con
  18 differenze di implementazione, è comune ad ogni implementazione di unix.
  19 Vedremo cosa comporti questa architettura in caso di accesso contemporaneo ai
  20 file da parte di più processi.
  21
  22
  23 \subsection{L'architettura dei \textit{file descriptors}}
  24 \label{sec:file_fd}
  25
  26 Per poter accedere al contenuto di un file occorre creare un canale di
  27 comunicazione con il kernel che renda possibile operare su di esso (si ricordi
  28 quanto visto in \secref{sec:file_vfs_work}). Questo si fa aprendo il file con
  29 la funzione \func{open} che provvederà a localizzare l'inode del file e
  30 inizializzare le funzioni che il VFS mette a disposizione (riportate in
  31 \tabref{tab:file_file_operations}). Una volta terminate le operazioni, il file
  32 dovrà essere chiuso, e questo chiuderà il canale di comunicazione impedendo
  33 ogni ulteriore operazione.
  34
  35 All'interno di ogni processo i file aperti sono identificati da un intero non
  36 negativo, chiamato appunto \textit{file descriptors}, quando un file viene
  37 aperto la funzione restituisce il file descriptor, e tutte le successive
  38 operazioni devono passare il \textit{file descriptors} come argomento.
  39
  40 Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
  41 che il kernel gestisce l'interazione fra processi e file.  Il kernel mantiene
  42 sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
  43 ed un elenco dei file aperti nella \textit{file table}.
  44
  45 La \textit{process table} è una tabella che contiene una voce per ciascun
  46 processo attivo nel sistema. In Linux la tabella è costituita da strutture di
  47 tipo \var{task\_struct} nelle quali sono raccolte tutte le informazioni
  48 relative ad un singolo processo; fra queste informazioni c'è anche il
  49 puntatore ad una ulteriore struttura di tipo \var{files\_struct} in cui sono
  50 contenute le informazioni relative ai file che il processo ha aperto, ed in
  51 particolare:
  52 \begin{itemize*}
  53 \item i flag relativi ai file descriptor.
  54 \item il numero di file aperti.
  55 \item una tabella che contiene un puntatore alla relativa voce nella
  56   \textit{file table} per ogni file aperto.
  57 \end{itemize*}
  58 il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
  59 questa tabella.
  60
  61 La \textit{file table} è una tabella che contiene una voce per ciascun file
  62 che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
  63 \var{file}; in ciascuna di esse sono tenute varie informazioni relative al
  64 file, fra cui:
  65 \begin{itemize*}
  66 \item lo stato del file (lettura, scrittura, append, etc.).
  67 \item il valore della posizione corrente (l'\textit{offset}) nel file.
  68 \item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
  69     ad un puntatore ad una struttura \var{dentry} che punta a sua volta
  70     all'inode passando per la nuova struttura del VFS} del file.
  71 %\item un puntatore alla tabella delle funzioni \footnote{la struttura
  72 %    \var{f\_op} descritta in \secref{sec:file_vfs_work}} che si possono usare
  73 %  sul file.
  74 \end{itemize*}
  75
  76 In \figref{fig:file_proc_file} si è riportato uno schema in cui è illustrata
  77 questa architettura, in cui si sono evidenziate le interrelazioni fra le varie
  78 strutture di dati sulla quale essa è basata.
  79 \begin{figure}[htb]
  80   \centering
  81   \includegraphics[width=14cm]{img/procfile.eps}
  82   \caption{Schema della architettura dell'accesso ai file attraverso
  83   l'interfaccia dei \textit{file descroptor}}
  84   \label{fig:file_proc_file}
  85 \end{figure}
  86 Ritorneremo su questo schema più volte, dato che esso è fondamentale per
  87 capire i dettagli del funzionamento delle dell'interfaccia dei \textit{file
  88   descriptor}.
  89
  90
  91 \subsection{I file standard}
  92 \label{sec:file_std_descr}
  93
  94 Come accennato i \textit{file descriptor} non sono altro che un indice nella
  95 tabella dei file aperti di ciascun processo; per questo motivo essi vengono
  96 assegnati in successione tutte le volte che si apre un nuovo file (se non se
  97 ne è chiuso nessuno in precedenza).
  98
  99 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 100 processo viene lanciato con almeno tre file aperti. Questi, per quanto
 101 dicevamo prima, avranno come \textit{file descriptor} i valori 0, 1 e 2.
 102 Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
 103 delle applicazioni, e non aderirvi potrebbe portare a gravi problemi di
 104 interoperabilità.
 105
 106 Il primo file è sempre associato a quello che viene chiamato \textit{standard
 107   input}, è cioè il file da cui il processo si aspetta di ricevere i dati in
 108 ingresso (nel caso della shell, è associato alla lettura della tastiera); il
 109 secondo file è il cosiddetto \textit{standard output}, cioè il file su cui ci
 110 si aspetta debbano essere inviati i dati in uscita (sempre nel caso della
 111 shell, è il terminale su cui si sta scrivendo), il terzo è lo \textit{standard
 112   error}, su cui viene inviato l'output relativo agli errori.
 113
 114 Lo standard POSIX.1 provvede tre costanti simboliche, definite nell'header
 115 \file{unistd.h}, al posto di questi valori numerici:
 116 \begin{table}[htb]
 117   \centering
 118   \begin{tabular}[c]{|l|l|}
 119     \hline
 120     \textbf{Costante} & \textbf{Significato} \\
 121     \hline
 122     \hline
 123     \macro{STDIN\_FILENO}  & \textit{file descriptor} dello \textit{standard
 124       input} \\
 125     \macro{STDOUT\_FILENO} & \textit{file descriptor} dello \textit{standard
 126       output} \\
 127     \macro{STDERR\_FILENO} & \textit{file descriptor} dello \textit{standard
 128       error}\\
 129     \hline
 130   \end{tabular}
 131   \caption{Costanti definite in \file{unistd.h} per i file standard aperti
 132     alla creazione di ogni processo.}
 133   \label{tab:file_std_files}
 134 \end{table}
 135
 136 In \curfig\ si è utilizzata questa situazione come esempio, facendo
 137 riferimento ad un programma in cui lo \textit{standard input} è associato ad
 138 un file mentre lo \textit{standard output} e lo \textit{standard error} sono
 139 entrambi associati ad un altro file (e quindi utilizzano lo stesso inode).
 140
 141 Nelle vecchie versioni di unix (ed anche in Linux fino al kernel 2.0.x) il
 142 numero di file aperti era anche soggetto ad un limite massimo dato dalle
 143 dimensioni del vettore di puntatori con cui era realizzata la tabella dei file
 144 descriptor dentro \var{file\_struct}; questo limite intrinseco non sussiste
 145 più, dato che si è passati ad una linked list, restano i limiti imposti
 146 dall'amministratore (vedi \secref{sec:sys_limits}).
 147
 148
 149
 150 \section{Le funzioni base}
 151 \label{sec:file_base_func}
 152
 153 L'interfaccia standard unix per l'input/output sui file è basata su cinque
 154 funzioni fondamentali \func{open}, \func{read}, \func{write}, \func{lseek} e
 155 \func{close}, usate rispettivamente per aprire, leggere, scrivere, spostarsi e
 156 chiudere un file.
 157
 158 La gran parte delle operazioni sui file si effettua attraverso queste cinque
 159 funzioni, esse vengono chiamate anche funzioni di I/O non bufferizzato, per
 160 contrapporle alle analoghe previste dallo standard ANSI C (che vedremo in
 161 \secref{sec:file_ansi_base_func}), dato che effettuano le operazioni di lettura
 162 e scrittura usando direttamente le system call del kernel.
 163
 164
 165 \subsection{La funzione \func{open}}
 166 \label{sec:file_open}
 167
 168 La funzione \func{open} è la funzione fondamentale per accedere ai file, ed è
 169 quella che crea l'associazione fra un pathname ed un file descriptor; il suo
 170 prototipo è:
 171
 172 \begin{functions}
 173   \headdecl{sys/types.h}
 174   \headdecl{sys/stat.h}
 175   \headdecl{fcntl.h}
 176   \funcdecl{int open(const char *pathname, int flags)}
 177   \funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
 178   Apre il file indicato da \var{pathname} nella modalità indicata da
 179   \var{flags}, e, nel caso il file sia creato, con gli eventuali permessi
 180   specificati da \var{mode}.
 181
 182   La funzione ritorna il file descriptor in caso di successo e -1 in caso di
 183   errore. In questo caso la variabile \var{errno} viene settata ad uno dei
 184   valori:
 185
 186   \begin{errlist}
 187   \item \macro{EEXIST} \var{pathname} esiste e si è specificato
 188     \macro{O\_CREAT} e \macro{O\_EXCL}.
 189   \item \macro{EISDIR} \var{pathname} indica una directory e si è tentato
 190     l'accesso in scrittura.
 191   \item \macro{ENOTDIR} un componente di \var{pathname} non è una directory o
 192     si è specificato \macro{O\_DIRECTORY} e \var{pathname} non è una
 193     directory.
 194   \item \macro{ENXIO} si sono settati \macro{O\_NOBLOCK} o \macro{O\_WRONLY}
 195     ed il file è una fifo che non viene letta da nessun processo o
 196     \var{pathname} è un file di dispositivo ma il dispositivo è assente.
 197   \item \macro{ENODEV} \var{pathname} si riferisce a un file di dispositivo
 198     che non esiste.
 199   \item \macro{ETXTBSY} si è cercato di accedere in scrittura all'immagine di
 200     un programma in esecuzione.
 201   \item \macro{ELOOP} si sono incotrati troppi link simbolici nel risolvere
 202     pathname o si è indicato \macro{O\_NOFOLLOW} e \var{pathname} è un link
 203     simbolico.
 204   \end{errlist}
 205   ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOENT},
 206   \macro{EROFS}, \macro{EFAULT}, \macro{ENOSPC}, \macro{ENOMEM},
 207   \macro{EMFILE} e \macro{ENFILE}.
 208 \end{functions}
 209
 210
 211
 212
 213
 214 \subsection{La funzione \func{creat}}
 215 \label{sec:file_creat}
 216
 217 \subsection{La funzione \func{close}}
 218 \label{sec:file_close}
 219
 220 \subsection{La funzione \func{lseek}}
 221 \label{sec:file_lseek}
 222
 223 \subsection{La funzione \func{read}}
 224 \label{sec:file_read}
 225
 226 \subsection{La funzione \func{write}}
 227 \label{sec:file_write}
 228
 229
 230 \section{Funzioni avanzate}
 231 \label{sec:file_adv_func}
 232
 233 \subsection{La condivisione dei files}
 234 \label{sec:file_sharing}
 235
 236 \subsection{Operazioni atomiche coi file}
 237 \label{sec:file_atomic}
 238
 239
 240 \subsection{La funzioni \func{dup} e \func{dup2}}
 241 \label{sec:file_dup}
 242
 243 \subsection{La funzione \func{fcntl}}
 244 \label{sec:file_fcntl}
 245
 246 \subsection{La funzione \func{ioctl}}
 247 \label{sec:file_ioctl}
 248
 249
 250
 251
 252