Aggiunta spiegazione sui file di dispositivo, figura sui terminali.

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index 0a7bb94adc735105e3e06f5d715c6d464b8d1287..359a1e26391e07f38de5b5186c64638d215997e8 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -122,11 +122,26 @@ Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal

-\textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
+\textit{Virtual File System}\index{Virtual File System} è riportato in
+\tabref{tab:file_file_types}.

 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con

-la classificazione sui tipi di file (che in questo caso sono sempre file di
-dati) in base al loro contenuto, o tipo di accesso.
+la classificazione dei file (che in questo caso sono sempre file di dati) in
+base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
+oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
+Alcuni di essi, come le \textit{fifo} (che tratteremo in
+\secref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
+\capref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
+delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
+\textsl{file di dispositivo} (o \textit{device file}) che costituiscono una
+interfaccia diretta per leggere e scrivere sui dispositivi fisici; essi
+vengono suddivisi in due grandi categorie, \textsl{a blocchi} e \textsl{a
+  caratteri} a seconda delle modalità in cui il dispositivo sottostante
+effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi
+  (ad esempio i dischi) corrispondono a periferiche per le quali è richiesto
+  che l'I/O venga effettuato per blocchi di dati di dimensioni fissate (ad
+  esempio le dimensioni di un settore), mentre nei dispositivi a caratteri
+  l'I/O viene effettuato senza nessuna particolare struttura.}

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


@@ -136,7 +151,7 @@ dati) in base al loro contenuto, o tipo di accesso.
     \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
     \hline
     \hline
     \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
     \hline
     \hline

-      \textit{regular file} & \textsl{file normale} &
+      \textit{regular file} & \textsl{file regolare} &

       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       un file che contiene una lista di nomi associati a degli \textit{inodes}
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       un file che contiene una lista di nomi associati a degli \textit{inodes}


@@ -159,16 +174,20 @@ dati) in base al loro contenuto, o tipo di accesso.
     \label{tab:file_file_types}
 \end{table}
 
     \label{tab:file_file_types}
 \end{table}
 

-Infatti una delle differenze principali con altri sistemi operativi (come il
-VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
-un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
-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.\footnote{con i
-  kernel della serie 2.4 è disponibile, attraverso dei device file appositi,
-  una forma di accesso diretto ai dischi (il \textit{raw access}) che però non
-  ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
-  passare attraverso un filesystem.}
+Una delle differenze principali con altri sistemi operativi (come il VMS o
+Windows) è che per Unix tutti i file di dati sono identici e contengono un
+flusso continuo di byte. Non esiste cioè differenza per come vengono visti 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.\footnote{questo vale
+  anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di
+  dimensione fissa avviene solo all'interno del kernel, ed è completamente
+  trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
+    diretto} riferendosi alla capacità, che non ha niente a che fare con tutto
+  ciò, di effettuare, attraverso degli appositi file di dispositivo,
+  operazioni di I/O direttamente sui dischi senza passare attraverso un
+  filesystem (il cosiddetto \textit{raw access}, introdotto coi kernel della
+  serie 2.4.x).}

 
 Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
 
 Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è


@@ -179,12 +198,21 @@ del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 
 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 riga.
 

-Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
-dati e che non c'è nessun supporto del sistema per le estensioni come parte
-del filesystem. Ciò nonostante molti programmi adottano delle convenzioni per
-i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
-universale, solo una convenzione.
+Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
+tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
+estensioni come parte del filesystem.\footnote{non è così ad esempio nel
+  filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
+  che specificano fra l'altro il contenuto ed il programma da usare per
+  leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la
+  possibilità di associare delle risorse ai file, ma è una caratteristica
+  tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei
+  file in un sistema Unix.} Ciò nonostante molti programmi adottano delle
+convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
+in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di
+utilizzare i primi 4 byte del file per memorizzare un \textit{magic number}
+che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed
+accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
+demandato alle applicazioni stesse.

 
 
 \subsection{Le due interfacce ai file}
 
 
 \subsection{Le due interfacce ai file}


@@ -515,7 +543,7 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=12cm]{img/disk_struct}
+  \includegraphics[width=14cm]{img/disk_struct}

   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}
   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}


@@ -529,7 +557,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=12cm]{img/filesys_struct}
+  \includegraphics[width=14cm]{img/filesys_struct}

   \caption{Strutturazione dei dati all'interno di un filesystem.}
   \label{fig:file_filesys_detail}
 \end{figure}
   \caption{Strutturazione dei dati all'interno di un filesystem.}
   \label{fig:file_filesys_detail}
 \end{figure}


@@ -547,10 +575,10 @@ ricordare sempre che:
   fisici che contengono i dati e così via; le informazioni che la funzione
   \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
   troverà solo il nome del file e il numero dell'\textit{inode} ad esso
   fisici che contengono i dati e così via; le informazioni che la funzione
   \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
   troverà solo il nome del file e il numero dell'\textit{inode} ad esso

-  associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
-  (traduzione approssimata dell'inglese \textit{directory entry}, che non
-  useremo anche per evitare confusione con le \textit{dentry} del kernel di
-  cui si parlava in \secref{sec:file_vfs}).
+  associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
+  traduzione dell'inglese \textit{directory entry}, che non useremo anche per
+  evitare confusione con le \textit{dentry} del kernel di cui si parlava in
+  \secref{sec:file_vfs}).

 
 \item Come mostrato in \curfig\ si possono avere più voci che puntano allo
   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
 
 \item Come mostrato in \curfig\ si possono avere più voci che puntano allo
   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il


@@ -583,7 +611,7 @@ abbiamo aggiunto dei numeri di inode.
 
 \begin{figure}[htb]
   \centering 
 
 \begin{figure}[htb]
   \centering 

-  \includegraphics[width=12cm]{img/dir_links}
+  \includegraphics[width=14cm]{img/dir_links}

   \caption{Organizzazione dei link per le directory.}
   \label{fig:file_dirs_link}
 \end{figure}
   \caption{Organizzazione dei link per le directory.}
   \label{fig:file_dirs_link}
 \end{figure}


@@ -610,7 +638,7 @@ Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
 non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
 non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del

-  kernel quando agisce su gruppi di file. Possono essere settati su file e
+  kernel quando agisce su gruppi di file. Possono essere impostati su file e

   directory e in quest'ultimo caso i nuovi file creati nella directory
   ereditano i suoi attributi.
 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
   directory e in quest'ultimo caso i nuovi file creati nella directory
   ereditano i suoi attributi.
 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di


@@ -618,7 +646,7 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SVr4 comporta che i file vengono creati con l'identificatore del
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SVr4 comporta che i file vengono creati con l'identificatore del
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit

-  di \acr{sgid} settato (per una descrizione dettagliata del significato di
+  di \acr{sgid} impostato (per una descrizione dettagliata del significato di

   questi termini si veda \secref{sec:file_access_control}), nel qual caso file
   e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   questi termini si veda \secref{sec:file_access_control}), nel qual caso file
   e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem