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
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
+\ref{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
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 \ref{sec:fileunix_fd}). Un elenco delle operazioni
+previste dal kernel è riportato in \ntab.
\begin{table}[htb]
\centering
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
+\ref{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
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 Sez.~\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.
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
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
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.
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.
+