Usate le nuove macro per le referenze, e trovato un formato sensato per

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index b0779a5cf7a2d2cc01efa4b8453199d8173453b1..c89f76be650e19c1b818b9bdde2d3f622bd4da1f 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -8,12 +8,11 @@ astratta che tratta le periferiche allo stesso modo degli usuali file di
 dati.
 
 Questo significa che si può accedere cioè a qualunque periferica del computer,
 dati.
 
 Questo significa che si può accedere cioè a qualunque periferica del computer,

-dalla seriale, alla parallela, alla console, e agli stessi dischi, (unica
-eccezione le interfacce di rete, che che non rientrano bene nell'astrazione)
-attraverso i cosiddetti file di dispositivo (i \textit{device files}). Questi
-sono dei file speciali agendo sui quali i programmi possono leggere, scrivere
-e compiere operazioni direttamente sulle perferiche, usando le stesse funzioni
-che si usano per i normali file di dati.
+dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
+cosiddetti file di dispositivo (i \textit{device files}). Questi sono dei file
+speciali agendo sui quali i programmi possono leggere, scrivere e compiere
+operazioni direttamente sulle perferiche, usando le stesse funzioni che si
+usano per i normali file di dati.

 
 In questo capitolo forniremo un'introduzione alle principali caratteristiche
 di questa interfaccia, su come essa viene implementata in linux e su come sono
 
 In questo capitolo forniremo un'introduzione alle principali caratteristiche
 di questa interfaccia, su come essa viene implementata in linux e su come sono


@@ -27,18 +26,20 @@ Visto il ruolo fondamentale che i files vengono ad assumere in un sistema
 unix, è anzitutto opportuno fornire un'introduzione dettagliata su come essi
 vengono trattati dal sistema. In particolare occorre tenere presente dov'è che
 si situa il limite fondamentale fra kernel space e user space che tracciavamo
 unix, è anzitutto opportuno fornire un'introduzione dettagliata su come essi
 vengono trattati dal sistema. In particolare occorre tenere presente dov'è che
 si situa il limite fondamentale fra kernel space e user space che tracciavamo

-al Cap.~\ref{cha:intro_unix}.
+al \capref{cha:intro_unix}.

 
 Partiamo allora da come viene strutturata nel sistema la disposizione dei
 file: per potervi accedere il kernel usa una apposita interfaccia che permetta
 di strutturare l'informazione tenuta sullo spazio grezzo disponibile sui
 
 Partiamo allora da come viene strutturata nel sistema la disposizione dei
 file: per potervi accedere il kernel usa una apposita interfaccia che permetta
 di strutturare l'informazione tenuta sullo spazio grezzo disponibile sui

-dischi, cioè quello che si chiama un \textit{filesystem}. 
+dischi, cioè quello che si chiama un \textit{filesystem} (useremo per brevità
+questo nome al posto della più prolissa traduzione italiana sistema di file). 

 
 Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
 memorizzati all'interno del disco stesso, strutturando l'informazione in files
 
 Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
 memorizzati all'interno del disco stesso, strutturando l'informazione in files

-e directory.  Per poter accedere ai file contenuti in un disco occorrerà
-perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco
-(o la partizione del disco).
+e directory (su questo aspetto torneremo con maggiori dettagli in
+\secref{sec:filedir_filesystem}).  Per poter accedere ai file contenuti in un
+disco occorrerà perciò attivare il filesystem, questo viene fatto
+\textsl{montando} il disco (o la partizione del disco).

 
 %In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
 %informazioni riservate che tengono conto degli inodes allocati, di quelli
 
 %In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
 %informazioni riservate che tengono conto degli inodes allocati, di quelli


@@ -128,8 +129,9 @@ una struttura di tipo \texttt{file} in cui viene inserito un puntatore alla
 dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che
 implementano le operazioni disponibili sul file. In questo modo i processi in
 user space possono accedere alle operazioni attraverso detti metodi, che
 dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che
 implementano le operazioni disponibili sul file. In questo modo i processi in
 user space possono accedere alle operazioni attraverso detti metodi, che

-saranno diversi a seconda del tipo di file (o dispositivo) aperto. Un elenco
-delle operazioni disponibili è riportato in \ntab.
+saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo
+torneremo in dettaglio in \secref{sec:fileunix_fd}). Un elenco delle operazioni
+previste dal kernel è riportato in \ntab.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -174,8 +176,9 @@ diversi filesystem (come quelli usati da Windows o MacOs) 
 
 In unix è implementata da qualunque filesystem standard una forma elementare
 (ma adatta alla maggior parte delle esigenze) di controllo di accesso ai
 
 In unix è implementata da qualunque filesystem standard una forma elementare
 (ma adatta alla maggior parte delle esigenze) di controllo di accesso ai

-files. Torneremo sull'argomento in dettaglio più avanti, qui ci limitiamo ad
-una introduzione dei concetti essenziali.
+files. Torneremo sull'argomento in dettaglio più avanti (vedi
+\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei
+concetti essenziali.

 
 Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix,
 e non è detto che sia applicabile (ed infatti non è vero per il filesystem di
 
 Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix,
 e non è detto che sia applicabile (ed infatti non è vero per il filesystem di


@@ -185,20 +188,20 @@ di controllo di accesso molto pi
 
 Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto
 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e
 
 Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto
 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e

-gid spiegato in \ref{sec:intro_usergroup}, e un insieme di permessi che sono
-divisi in tre classi, e cioè attribuiti rispettivamente al proprietario, a
-qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
-altri utenti.
+gid accennato in \secref{sec:intro_usergroup}, e un insieme di permessi che
+sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario,
+a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti
+gli altri utenti.

 
 I permessi sono espressi da un insieme di 12 bit: di questi i nove meno
 significativi sono usati a gruppi di tre per indicare i permessi base di
 lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
 \textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al
 proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari
 
 I permessi sono espressi da un insieme di 12 bit: di questi i nove meno
 significativi sono usati a gruppi di tre per indicare i permessi base di
 lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
 \textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al
 proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari

-permessi associati ai file è riportata in \ref{sec:filedir_suid_sgid}).  I
+permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}).  I

 restanti tre bit sono usati per indicare alcune caratteristiche più complesse
 (\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in
 restanti tre bit sono usati per indicare alcune caratteristiche più complesse
 (\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in

-seguito (vedi \ref{sec:filedir_suid_sgid} e \ref{sec:filedir_stiky}).
+seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_stiky}).

 
 Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un
 processo cerca l'accesso al file esso controlla i propri uid e gid
 
 Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un
 processo cerca l'accesso al file esso controlla i propri uid e gid


@@ -210,7 +213,7 @@ pertanto accesso senza restrizione a qualunque file del sistema.
 
 In realtà il procedimento è più complesso di quanto descritto in maniera
 elementare qui; inoltre ad un processo sono associati diversi identificatori,
 
 In realtà il procedimento è più complesso di quanto descritto in maniera
 elementare qui; inoltre ad un processo sono associati diversi identificatori,

-torneremo su questo in maggiori dettagli in seguito in \ref{sec:proc_perms}.
+torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.

 
 \subsection{I tipi di files}
 \label{sec:fileintr_file_types}
 
 \subsection{I tipi di files}
 \label{sec:fileintr_file_types}


@@ -255,6 +258,9 @@ un flusso continuo di bytes; non esiste cio
 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 file di testo e binari che c'è in windows) né c'è una strutturazione a record
 per il cosiddetto ``accesso diretto'' come nel caso del VMS.
 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 file di testo e binari che c'è in windows) né c'è una strutturazione a record
 per il cosiddetto ``accesso diretto'' come nel caso del VMS.

+%  (con i kernel
+% della serie 2.4 è disponibile una forma di accesso diretto ai dischi il
+% \textit{raw access} che però non ha nulla a che fare con questo).

 
 Una seconda differenza è nel formato dei file ascii; in Unix la fine riga è
 codificata in maniera diversa da Windows o MacIntosh, in particolare il fine
 
 Una seconda differenza è nel formato dei file ascii; in Unix la fine riga è
 codificata in maniera diversa da Windows o MacIntosh, in particolare il fine


@@ -304,7 +310,7 @@ operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
 usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
 devono essere usati i file descriptor se si vuole ricorrere a modalità
 speciali di I/O come il polling o il non-bloccante (vedi
 usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
 devono essere usati i file descriptor se si vuole ricorrere a modalità
 speciali di I/O come il polling o il non-bloccante (vedi

-\ref{sec:file_bohhhhh}).
+\secref{sec:file_bohhhhh}).

 
 Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
 dei file descriptor, che tratta tutti i file nello stesso modo, con
 
 Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
 dei file descriptor, che tratta tutti i file nello stesso modo, con


@@ -323,7 +329,7 @@ stream ad un file descriptor.
 
 In generale, se non necessitano specificatamente le funzionalità di basso
 livello, è opportuno usare sempre gli stream per la loro maggiore portabilità
 
 In generale, se non necessitano specificatamente le funzionalità di basso
 livello, è opportuno usare sempre gli stream per la loro maggiore portabilità

-essendo questi ultimi definito nello standard ISO C; l'interfaccia con i file
+essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file

 descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è
 pertanto di portabilità più limitata.
 
 descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è
 pertanto di portabilità più limitata.
 


@@ -364,12 +370,18 @@ Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
 accesso è un riferimento all'inode del file, pertanto anche se il file viene
 cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
 dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
 accesso è un riferimento all'inode del file, pertanto anche se il file viene
 cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
 dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà

-chiuso e l'ultimo riferimento cancellato. È pertanto possibile (e pratica
-comune) aprire un file provvisorio per cancellarlo immediatamente dopo; in
-questo modo all'uscita del programma il file scomparirà definitivamente dal
-disco, ma il file ed il suo contenuto saranno disponibili per tutto il tempo
-in cui il processo è attivo.
+chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+in dettaglio in \secref{sec:filedir_link}) aprire un file provvisorio per
+cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+saranno disponibili per tutto il tempo in cui il processo è attivo.

 
 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
 esaminando in dettaglio come tutto ciò viene realizzato.
 
 
 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
 esaminando in dettaglio come tutto ciò viene realizzato.
 

+Si ricordi infine che in unix non esistono i tipi di file e che non c'è nessun
+supporto per le estensioni come parte del filesystem. Ciò non ostante molti
+programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
+C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
+una convenzione.
+