X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=c89f76be650e19c1b818b9bdde2d3f622bd4da1f;hp=dfd3081dc67781aa9984a8052d20dc99818db1ea;hb=4826742c87d76af810c8a30e5495135fb43b8091;hpb=efd164169524125422cf9bb80ff70a0b037886a0

diff --git a/fileintro.tex b/fileintro.tex
index dfd3081..c89f76b 100644
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -26,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
-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
-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
-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
@@ -127,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
-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
@@ -173,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
-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
@@ -184,7 +188,7 @@ 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
-gid spiegato in Sez.~\ref{sec:intro_usergroup}, e un insieme di permessi che
+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.
@@ -194,10 +198,10 @@ 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
-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
@@ -209,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,
-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}
@@ -306,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
-\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
@@ -366,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à
-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.
 
+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.
+