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 (nel campo \var{f\_flags}).
  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 Lo standard POSIX.1 provvede tre costanti simboliche, definite nell'header
 114 \file{unistd.h}, al posto di questi valori numerici:
 115 \begin{table}[htb]
 116   \centering
 117   \footnotesize
 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 dato
 160 che effettuano le operazioni di lettura e scrittura usando direttamente le
 161 system call del kernel.
 162
 163
 164 \subsection{La funzione \func{open}}
 165 \label{sec:file_open}
 166
 167 La funzione \func{open} è la funzione fondamentale per accedere ai file, ed è
 168 quella che crea l'associazione fra un pathname ed un file descriptor; il suo
 169 prototipo è:
 170
 171 \begin{functions}
 172   \headdecl{sys/types.h}
 173   \headdecl{sys/stat.h}
 174   \headdecl{fcntl.h}
 175   \funcdecl{int open(const char *pathname, int flags)}
 176   \funcdecl{int open(const char *pathname, int flags, mode\_t mode)}
 177   Apre il file indicato da \var{pathname} nella modalità indicata da
 178   \var{flags}, e, nel caso il file sia creato, con gli eventuali permessi
 179   specificati da \var{mode}.
 180
 181   La funzione ritorna il file descriptor in caso di successo e -1 in caso di
 182   errore. In questo caso la variabile \var{errno} viene settata ad uno dei
 183   valori:
 184
 185   \begin{errlist}
 186   \item \macro{EEXIST} \var{pathname} esiste e si è specificato
 187     \macro{O\_CREAT} e \macro{O\_EXCL}.
 188   \item \macro{EISDIR} \var{pathname} indica una directory e si è tentato
 189     l'accesso in scrittura.
 190   \item \macro{ENOTDIR} si è specificato \macro{O\_DIRECTORY} e \var{pathname}
 191     non è una directory.
 192   \item \macro{ENXIO} si sono settati \macro{O\_NOBLOCK} o \macro{O\_WRONLY}
 193     ed il file è una fifo che non viene letta da nessun processo o
 194     \var{pathname} è un file di dispositivo ma il dispositivo è assente.
 195   \item \macro{ENODEV} \var{pathname} si riferisce a un file di dispositivo
 196     che non esiste.
 197   \item \macro{ETXTBSY} si è cercato di accedere in scrittura all'immagine di
 198     un programma in esecuzione.
 199   \item \macro{ELOOP} si sono incotrati troppi link simbolici nel risolvere
 200     pathname o si è indicato \macro{O\_NOFOLLOW} e \var{pathname} è un link
 201     simbolico.
 202   \end{errlist}
 203   ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOENT},
 204   \macro{EROFS}, \macro{EFAULT}, \macro{ENOSPC}, \macro{ENOMEM},
 205   \macro{EMFILE} e \macro{ENFILE}.
 206 \end{functions}
 207
 208 La funzione apre il file, usando il primo file descriptor libero, e crea
 209 l'opportuna voce (cioè la struttura \var{file}) nella file table.  Viene usato
 210 sempre il file descriptor con il valore più basso, questa caratteritica
 211 permette di prevedere qual'è il valore che si otterrà e viene talvolta usata
 212 da alcune applicazioni per sostituire i file corrispondenti ai file standard
 213 di \secref{sec:file_std_descr}: se ad esempio si chiude lo standard input e si
 214 apre subito dopo un nuovo file questo diventerà il nuovo standard input (avrà
 215 cioè il file descriptor 0).
 216
 217 Il nuovo file descriptor non è condiviso con nessun altro processo, (torneremo
 218 sulla condivisione dei file, in genere accessibile dopo una \func{fork}, in
 219 \secref{sec:file_sharing}). Il nuovo file descriptor è settato di default per
 220 restare aperto attraverso una \func{exec} (come accennato in
 221 \secref{sec:proc_exec}) ed l'offset è settato all'inizio del file.
 222
 223 La funzione prevede diverse modalità di apertura di un file, che vengono
 224 specificate dal parametro \var{flags}, questo parametro viene settato come
 225 maschera binaria attraverso OR aritmetico delle costanti che identificano i
 226 vari flag. Questi ultimi sono poi divisibili in tre categorie principali:
 227 \begin{itemize}
 228 \item \textsl{le modalità di accesso}, che specificano con quale modalità si
 229   accede al file: lettura, scrittura o lettura/scrittura.  Uno di questi
 230   valori deve essere sempre specificato, vengono settati alla chiamata da
 231   \func{open}, e possono essere riletti con una \func{fcntl}, ma non
 232   modificati.
 233 \item \textsl{le modalità di apertura}, che permettono di specificare alcuni
 234   dei modi di funzionamento di \func{open}. Hanno effetto solo al momento
 235   della chiamata e non sono memorizzati nè possono essere riletti.
 236 \item \textsl{le modalità di operazione}, che permettono di specificare alcuni
 237   effetti del comportamento delle operazioni sul file (come la \func{read} o
 238   la \func{write}). Sono settati alla chiamata da \func{open}, ma possono
 239   essere riletti e modificati con una una \func{fcntl}.
 240 \end{itemize}
 241
 242 In \ntab\ si sono riportate, come definite in \file{fcntl.h}, le costanti che
 243 identificano i vari flag di stato (ed i relativi valori numerici), da usare
 244 per specificare il valore di \var{flags}, alcuni di questi poi andranno a
 245 costituire lo stato del file (il cosiddetto \textit{file status flag}), tenuto
 246 nel campo \var{f\_flags} di \var{file}.
 247
 248 \begin{table}[htb]
 249   \centering
 250   \begin{tabular}[c]{|l|p{10cm}|}
 251     \hline
 252     \textbf{Flag} & \textbf{Descrizione} \\
 253     \hline
 254     \hline % modailtà di accesso
 255     \macro{O\_RDONLY} & apre il file in sola lettura\\
 256     \macro{O\_WRONLY} & apre il file in sola scrittura\\
 257     \macro{O\_RDWR} & apre il file lettura/scrittura\\
 258     \hline % modalita di apertura
 259     \macro{O\_CREAT} & Se il file non esiste verrà creato, con le regole di
 260     titolarità del file viste in \secref{sec:file_ownership}.  \\
 261     \macro{O\_EXCL} & usato in congiunzione con \macro{O\_CREAT} fa sì che
 262     l'esistenza del file diventi un errore\footnote{la man page di \func{open}
 263     segnala che questa opzione è difettosa su NFS, e che i programmi che la
 264     usano per stabilire un file di lock possono incorrere in una race
 265     condition.  Si consiglia come alternativa di usare un file con un nome
 266     univoco e la funzione \func{link} per verificarne l'esistenza.} che fa
 267     fallire \func{open} con \macro{EEXIST}.\\
 268     \macro{O\_NOCTTY} & Se \var{pathname} si riferisce ad un device di
 269     terminale, questo non diventerà il terminale di controllo, anche se il
 270     processo non ne ha ancora uno (si veda \secref{sec:sess_xxx}).\\
 271     \macro{O\_SHLOCK} & \\
 272     \macro{O\_EXLOCK} & \\
 273     \macro{O\_TRUNC} & \\
 274     \macro{O\_NOFOLLOW} & \\
 275     \macro{O\_DIRECTORY} & \\
 276     \macro{O\_LARGEFILE} & \\
 277     \hline  % modalità di operazione
 278     \macro{O\_APPEND} & \\
 279     \macro{O\_NONBLOCK} & Apre il file in modalità non bloccante, questo
 280     comporta che \func{open} ritorna immediatamente anche nei casi in cui si
 281     sarebbe bloccata. inoltre tutte le operazioni di I/O successive restano
 282     in modalità non bloccante, il che significa il fallimento di una
 283     \func{read} in assenza di dati da leggere e quello di una \func{write} in
 284     caso di impossibilità di scrivere immediatamente.  \\
 285     \macro{O\_NDELAY} & sinonimo di \macro{O\_NONBLOCK}\\
 286     \macro{O\_ASYNC} & \\
 287     \macro{O\_FSYNC} & \\
 288     \macro{O\_SYNC} & \\
 289     \macro{O\_NOATIME} & \\
 290     \hline
 291   \end{tabular}
 292   \caption{Costanti che identificano i vari flag di stato del file specificati
 293     alla sua aprertura tramite il parametro \var{flags} di \func{open}.}
 294   \label{tab:file_open_flags}
 295 \end{table}
 296
 297
 298 \subsection{La funzione \func{creat}}
 299 \label{sec:file_creat}
 300
 301 \subsection{La funzione \func{close}}
 302 \label{sec:file_close}
 303
 304 \subsection{La funzione \func{lseek}}
 305 \label{sec:file_lseek}
 306
 307 \subsection{La funzione \func{read}}
 308 \label{sec:file_read}
 309
 310 \subsection{La funzione \func{write}}
 311 \label{sec:file_write}
 312
 313
 314 \section{Funzioni avanzate}
 315 \label{sec:file_adv_func}
 316
 317 \subsection{La condivisione dei files}
 318 \label{sec:file_sharing}
 319
 320
 321 Si noti che i flag di stato del file, quelli settati dal parametro \var{flag}
 322 di \func{open}, essendo tenuti nella vode sulla file table, vengono condivisi,
 323 ai file sono però associati anche altri flag, (tenuti invece nella struttura
 324 \var{file\_struct} interna alla process table) che sono unici per ciascun file
 325 descriptor, e sono pertanto detti \textit{file descriptor flags} (l'unico
 326 usato al momento è \macro{FD\_CLOEXEC}).
 327
 328
 329 \subsection{Operazioni atomiche coi file}
 330 \label{sec:file_atomic}
 331
 332
 333 \subsection{La funzioni \func{dup} e \func{dup2}}
 334 \label{sec:file_dup}
 335
 336 \subsection{La funzione \func{fcntl}}
 337 \label{sec:file_fcntl}
 338
 339 \subsection{La funzione \func{ioctl}}
 340 \label{sec:file_ioctl}
 341
 342
 343
 344
 345