Correzioni e inizio architettura file

diff --git a/filestd.tex b/filestd.tex
index 7a87a37700925a52f08fa2d23b52542b60402188..55ad9c1c0b35f36f1f6016011491eef611e5cacc 100644 (file)
--- a/filestd.tex
+++ b/filestd.tex
@@ -22,12 +22,13 @@ del tipo \type{FILE *} (tanto che in certi caso il termine di puntatore a file
 è diventato sinonimo di stream).
 
 \subsection{Gli stream standard}
 è diventato sinonimo di stream).
 
 \subsection{Gli stream standard}

-\label{sec:file_stdfiles}
+\label{sec:file_std_stream}

 
 

-Quando un programma viene lanciato il processo ha sempre tre stream
-predefiniti aperti, che rappresentano i canali standard di input/output
-prestabiliti per il processo; anche questi tre stream sono definiti
-nell'header \file{stdio.h} e sono:
+
+Ai tre file standard (vedi \secref{sec:file_std_descr}) aperti per ogni
+processo, corrispondono altrettanti stream predefiniti per ogni processo, che
+rappresentano i canali standard di input/output prestabiliti; anche questi
+tre stream sono definiti nell'header \file{stdio.h} e sono:

 
 \begin{itemize}
 \item \var{FILE * stdin} Lo \textit{standard input} cioè lo stream da cui
 
 \begin{itemize}
 \item \var{FILE * stdin} Lo \textit{standard input} cioè lo stream da cui

diff --git a/fileunix.tex b/fileunix.tex
index 86652f3d57c6b1d09978ac9f680804135420cf01..b747a4d468233d20f7ab77fd2e497ce8d14d5fae 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -2,20 +2,20 @@
 \label{cha:file_unix_interface}
 
 Esamineremo in questo capitolo la prima delle due interfacce di programmazione
 \label{cha:file_unix_interface}
 
 Esamineremo in questo capitolo la prima delle due interfacce di programmazione

-per i file, quella dei file descriptor, nativa di unix. Questa è l'interfaccia
-di basso livello, che non prevede funzioni evolute come la bufferizzazione o
-funzioni di lettura o scrittura formattata, ma è su questa che è costruita
-anche l'interfaccia standard dei file definita dallo standard ANSI C.
+per i file, quella dei \textit{file descriptor}, nativa di unix. Questa è
+l'interfaccia di basso livello, che non prevede funzioni evolute come la
+bufferizzazione o funzioni di lettura o scrittura formattata, ma è su questa
+che è costruita anche l'interfaccia standard dei file definita dallo standard
+ANSI C.

 
 
 
 \section{L'architettura di base}
 \label{sec:file_base_arch}
 
 
 
 
 \section{L'architettura di base}
 \label{sec:file_base_arch}
 

-Iniziamo la trattazione con una panoramica sull'architettura base della
-intefaccia dei file descriptor. Esamineremo in questa sezione la struttura
-base dell'interfaccia con i file di unix, e le modalità con cui i processi
-ed il kernel interagiscono per operare sui file. 
+Esamineremo in questa sezione la architettura su cui è basata dell'interfaccia
+con cui i processi accedono ai file, che, pure nelle differenze di
+implementazione, è comune ad ogni implementazione di unix. 

 
 
 \subsection{L'architettura dei \textit{file descriptors}}
 
 
 \subsection{L'architettura dei \textit{file descriptors}}


@@ -23,61 +23,99 @@ ed il kernel interagiscono per operare sui file.
 
 Per poter accedere al contenuto di un file occorre creare un canale di
 comunicazione con il kernel che renda possibile operare su di esso (si ricordi
 
 Per poter accedere al contenuto di un file occorre creare un canale di
 comunicazione con il kernel che renda possibile operare su di esso (si ricordi

-quanto visto in \secref{sec:file_vfs_work}), questo si fa aprendo il file con
+quanto visto in \secref{sec:file_vfs_work}). Questo si fa aprendo il file con

 la funzione \func{open} che provvederà a localizzare l'inode del file e
 inizializzare le funzioni che il VFS mette a disposizione (riportate in
 \tabref{tab:file_file_operations}). Una volta terminate le operazioni, il file
 dovrà essere chiuso, e questo chiuderà il canale di comunicazione impedendo
 ogni ulteriore operazione.
 
 la funzione \func{open} che provvederà a localizzare l'inode del file e
 inizializzare le funzioni che il VFS mette a disposizione (riportate in
 \tabref{tab:file_file_operations}). Una volta terminate le operazioni, il file
 dovrà essere chiuso, e questo chiuderà il canale di comunicazione impedendo
 ogni ulteriore operazione.
 

-Per capire come funziona questo canale di comunicazione occorre spiegare
-brevemente qual'è architettura con cui il kernel gestisce l'interazione fra
-processi e file.  Il kernel mantiene sempre un elenco dei processi attivi
-nella cosiddetta \textit{process table} ed un elenco dei file aperti nella
-\textit{file table}. La relazione fra queste tabelle è mostrata in \nfig.
-
-
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=7cm]{img/procfile.eps}
-  \caption{Schema delle operazioni del VFS}
-  \label{fig:file_VFS_scheme}
-\end{figure}
-
-
-Ciascuna voce della \textit{process table}, che in Linux è costituita da una
-struttura \var{task\_struct}, contiene le informazioni relative ad ogni
-processo attivo nel sistema; fra queste c'è anche il puntatore ad una
-ulteriore struttura \var{files\_struct} in cui sono contenute le informazioni
-relative a ogni file che il processo ha aperto, ed in particolare:
+All'interno di ogni processo i file aperti sono identificati da un intero non
+negativo, chiamato appunto \textit{file descriptors}, quando un file viene
+aperto la funzione restituisce il file descriptor, e tutte le successive
+operazioni devono passare il \textit{file descriptors} come argomento.
+
+Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
+che il kernel gestisce l'interazione fra processi e file.  Il kernel mantiene
+sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
+ed un elenco dei file aperti nella \textit{file table}.
+
+La \textit{process table} è una tabella che contiene una voce per ciascun
+processo attivo nel sistema. In Linux la tabella è costituita da strutture di
+tipo \var{task\_struct} nelle quali sono raccolte tutte le informazioni
+relative ad un singolo processo; fra queste informazioni c'è anche il
+puntatore ad una ulteriore struttura di tipo \var{files\_struct} in cui sono
+contenute le informazioni relative ai file che il processo ha aperto, ed in
+particolare:

 \begin{itemize}
 \item i flag relativi ai file descriptor.
 \begin{itemize}
 \item i flag relativi ai file descriptor.

-\item un puntatore alla struttura \var{file} nella \textit{file table} per
-  ogni file aperto.
+\item il numero di file aperti.
+\item una tabella che contiene un puntatore alla relativa voce nella
+  \textit{file table} per ogni file aperto.

 \end{itemize}
 \end{itemize}

+il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
+questa tabella.

 
 

-Ciascuna voce della \textit{file table}, che in Linux è costituita da una
-struttura \var{file}, contiene le informazioni relative ad ogni file aperto
-nel sistema, fra queste ci sono:
+La \textit{file table} è una tabella che contiene una voce per ciascun file
+che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
+\var{file}; in ciascuna di esse sono tenute varie informazioni relative al
+file, fra cui:

 \begin{itemize}
 \item lo stato del file (lettura, scrittura, append, etc.).
 \begin{itemize}
 \item lo stato del file (lettura, scrittura, append, etc.).

-\item il valore della posizione corrente (l'\textit{offset}).
+\item il valore della posizione corrente (l'\textit{offset}) nel file.

 \item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
     ad un puntatore ad una struttura \var{dentry} che punta a sua volta
 \item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati
     ad un puntatore ad una struttura \var{dentry} che punta a sua volta

-    all'inode passando per la nuova struttura del VFS} del file (da cui si
-  accede all'inode).
-\item un puntatore alla tabella delle operazioni definite sul file (si ricordi
-  quanto detto a proposito di \tabref{tab:file_file_operations} nella
-  spiegazione del VFS di Linux).
+    all'inode passando per la nuova struttura del VFS} del file.
+\item un puntatore alla tabella delle funzioni \footnote{la struttura
+    \var{f\_op} descritta in \secref{sec:file_vfs_work}} che si possono usare
+  sul file.

 \end{itemize}
 \end{itemize}

+In \nfig\ si è riportato lo schema di questa architettura, con le
+interrelazioni fra tutti questi elementi.

 
 

+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=14cm]{img/procfile.eps}
+  \caption{Schema delle operazioni del VFS}
+  \label{fig:file_VFS_scheme}
+\end{figure}

 
 
 
 

+\subsection{I file standard}
+\label{sec:file_std_descr}

 
 

-All'interno di ogni processo i file aperti sono identificati da un intero non
-negativo, chiamato appunto \textit{file descriptors};
+Come accennato i \textit{file descriptor} non sono altro che un indice nella
+tabella dei file aperti di ciascun processo; per questo motivo normalmente
+essi vengono assegnati in successione tutte le volte che apre un nuovo file
+(senza averne chiuso nessuno in precedenza).  

 
 
 
 

+In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
+processo viene lanciato con almeno tre file aperti. Questi, per quanto
+dicevamo prima, avranno come \textit{file descriptor} i valori 0, 1 e 2.
+Benché questa sia soltanto una convenzione, essa è seguita dalla gran parte
+delle applicazioni, e non seguirla potrebbe portare a gravi problemi di
+incompatibilità.
+
+
+Il primo file è sempre associato a quello che viene chiamato \textit{standard
+  input}, è cioè il file da cui il processo si aspetta di ricevere i dati in
+ingresso (nel caso della shell, è associato alla lettura della tastiera); il
+secondo file è il cosiddetto \textit{standard output}, cioè il file su cui ci
+si aspetta debbano essere inviati i dati in uscita (sempre nel caso della
+shell, è il terminale su cui si sta scrivendo), il terzo è lo \textit{standard
+  error}, su cui viene inviato l'output relativo agli errori.
+
+Lo standard POSIX.1 provvede tre costanti simboliche, definite nell'header
+\file{unistd.h}, al posto di questi valori numerici: 
+\begin{itemize}
+\item \macro{STDIN\_FILENO} \textit{file descriptor} dello \textit{standard
+    input}
+\item \macro{STDOUT\_FILENO} \textit{file descriptor} dello \textit{standard
+    output}
+\item \macro{STDERR\_FILENO} \textit{file descriptor} dello \textit{standard
+    error}
+\end{itemize}

 
 
 
 
 
 

diff --git a/gapil.tex b/gapil.tex
index ff3e04b7b9cf696a10418b0ca4e0f84c8a02c391..1364419c8c16540dafaa72db3dc2f8ad84c8ff4c 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -1,4 +1,4 @@
-%%
+%% 

 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Oct. 2000 
 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Oct. 2000 


@@ -50,15 +50,14 @@
 \cleardoublepage}}
 
 \begin{quote}
 \cleardoublepage}}
 
 \begin{quote}

-
-      Copyright \copyright\ 2000-2001  Simone Piccardi.
-      Permission is granted to copy, distribute and/or modify this document
-      under the terms of the GNU Free Documentation License, Version 1.1
-      or any later version published by the Free Software Foundation;
-      with the Invariant Sections being ``Prefazione'', with no
-      Front-Cover Texts, and with no Back-Cover Texts.
-      A copy of the license is included in the section entitled ``GNU
-      Free Documentation License''.
+  
+  Copyright \copyright\ 2000-2001 Simone Piccardi.  Permission is granted to
+  copy, distribute and/or modify this document under the terms of the GNU Free
+  Documentation License, Version 1.1 or any later version published by the
+  Free Software Foundation; with the Invariant Sections being ``Prefazione'',
+  with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+  license is included in the section entitled ``GNU Free Documentation
+  License''.

 
 \end{quote}
 \clearemptydoublepage
 
 \end{quote}
 \clearemptydoublepage

diff --git a/img/procfile.dia b/img/procfile.dia
index ab2a92bdad0fe24dcfc107b47542a1a03ed5413a..cd8131c4763cf2910658f05075b4acd34d64777e 100644 (file)
Binary files a/img/procfile.dia and b/img/procfile.dia differ

diff --git a/intro.tex b/intro.tex
index d2833478591e6539840f760e020d0ee240da36ae..d6eefa583b8af41333ddad6c3b7553fd5f335c7c 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -6,8 +6,8 @@ cui 
 fornire una base di comprensione mirata a sottolineare le peculiarità del
 sistema che sono più rilevanti per quello che riguarda la programmazione.
 
 fornire una base di comprensione mirata a sottolineare le peculiarità del
 sistema che sono più rilevanti per quello che riguarda la programmazione.
 

-Dopo un introduzione sulle caratteristiche principali di un sistema di tipo
-unix passeremo ad illustrare alcuni dei concetti basi dell'architettura di
+Dopo una introduzione sulle caratteristiche principali di un sistema di tipo
+unix passeremo ad illustrare alcuni dei concetti base dell'architettura di

 GNU/Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed
 introdurremo alcuni degli standard principali a cui viene fatto riferimento.
 
 GNU/Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed
 introdurremo alcuni degli standard principali a cui viene fatto riferimento.
 


@@ -28,7 +28,7 @@ tramite delle richieste a quest'ultimo.
 
 Fin dall'inizio uno unix si presenta come un sistema operativo
 \textit{multitasking}, cioè in grado di eseguire contemporaneamente più
 
 Fin dall'inizio uno unix si presenta come un sistema operativo
 \textit{multitasking}, cioè in grado di eseguire contemporaneamente più

-programmi, e multiutente, in cui é possibile che più utenti siano connessi ad
+programmi, e multiutente, in cui è possibile che più utenti siano connessi ad

 una macchina eseguendo più programmi ``in contemporanea'' (in realtà, almeno
 per macchine a processore singolo, i programmi vengono eseguiti singolarmente
 a rotazione).
 una macchina eseguendo più programmi ``in contemporanea'' (in realtà, almeno
 per macchine a processore singolo, i programmi vengono eseguiti singolarmente
 a rotazione).


@@ -42,7 +42,7 @@ Gli unix pi
 caratteristiche dei processori moderni come la gestione hardware della memoria
 e la modalità protetta. In sostanza con i processori moderni si può
 disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
 caratteristiche dei processori moderni come la gestione hardware della memoria
 e la modalità protetta. In sostanza con i processori moderni si può
 disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe

-zone di memoria fisica.  Quello che succede é che il kernel é il solo
+zone di memoria fisica.  Quello che succede è che il kernel è il solo

 programma ad essere eseguito in modalità privilegiata, con il completo accesso
 all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
 (e non possono accedere direttamente alle zone di memoria riservate o alle
 programma ad essere eseguito in modalità privilegiata, con il completo accesso
 all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
 (e non possono accedere direttamente alle zone di memoria riservate o alle


@@ -56,7 +56,7 @@ protetta; quando necessario il processo potr
 soltanto attraverso delle opportune chiamate al sistema che restituiranno il
 controllo al kernel.
 
 soltanto attraverso delle opportune chiamate al sistema che restituiranno il
 controllo al kernel.
 

-La memoria viene sempre gestita del kernel attraverso il meccanismo della
+La memoria viene sempre gestita dal kernel attraverso il meccanismo della

 \textsl{memoria virtuale}, che consente di assegnare a ciascun processo uno
 spazio di indirizzi ``virtuale'' (vedi \secref{sec:proc_memory}) che il kernel
 stesso, con l'ausilio della unità di gestione della memoria, si incaricherà di
 \textsl{memoria virtuale}, che consente di assegnare a ciascun processo uno
 spazio di indirizzi ``virtuale'' (vedi \secref{sec:proc_memory}) che il kernel
 stesso, con l'ausilio della unità di gestione della memoria, si incaricherà di


@@ -75,10 +75,10 @@ il lavoro di accesso e gestione a basso livello 
 \section{User space e kernel space}
 \label{sec:intro_user_kernel_space}
 
 \section{User space e kernel space}
 \label{sec:intro_user_kernel_space}
 

-Uno dei concetti fondamentale su cui si basa l'architettura dei sistemi unix è
+Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi unix è

 quello della distinzione fra il cosiddetto \textit{user space}, che
 contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
 quello della distinzione fra il cosiddetto \textit{user space}, che
 contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il

-\textit{kernel space} che é l'ambiente in cui viene eseguito il kernel. Ogni
+\textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni

 programma vede se stesso come se avesse la piena disponibilità della CPU e
 della memoria ed è, salvo i meccanismi di comunicazione previsti
 dall'architettura, completamente ignaro del fatto che altri programmi possono
 programma vede se stesso come se avesse la piena disponibilità della CPU e
 della memoria ed è, salvo i meccanismi di comunicazione previsti
 dall'architettura, completamente ignaro del fatto che altri programmi possono


@@ -102,31 +102,31 @@ fornisce allo user space.
 Per capire meglio la distinzione fra kernel space e user space si può prendere
 in esame la procedura di avvio di un sistema unix; all'avvio il BIOS (o in
 generale il software di avvio posto nelle EPROM) eseguirà la procedura di
 Per capire meglio la distinzione fra kernel space e user space si può prendere
 in esame la procedura di avvio di un sistema unix; all'avvio il BIOS (o in
 generale il software di avvio posto nelle EPROM) eseguirà la procedura di

-avvio del sistema (il cosiddetto \textit{boot}) incaricandosi di caricare il
+avvio del sistema (il cosiddetto \textit{boot}), incaricandosi di caricare il

 kernel in memoria e di farne partire l'esecuzione; quest'ultimo, dopo aver
 kernel in memoria e di farne partire l'esecuzione; quest'ultimo, dopo aver

-inizializzato le periferiche farà partire il primo processo, \cmd{init} che è
-quello che a sua volta farà partire tutti i processi successivi,fra i quali
-c'è pure quello che si occupa di dialogare con la tastiera e lo schermo della
-console, e quello che mette a disposizione dell'utente che si vuole collegare
-un terminale e la stessa \textit{shell} da cui inviare i comandi.
+inizializzato le periferiche, farà partire il primo processo, \cmd{init}, che
+è quello che a sua volta farà partire tutti i processi successivi. Fra questi
+ci sarà pure quello che si occupa di dialogare con la tastiera e lo schermo
+della console, e quello che mette a disposizione dell'utente che si vuole
+collegare, un terminale e la \textit{shell} da cui inviare i comandi.

 
 E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
 sistema, non abbia in realtà niente a che fare con il kernel, ma sia
 effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
 qualunque programma di scrittura o di disegno, in user space.
 
 
 E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
 sistema, non abbia in realtà niente a che fare con il kernel, ma sia
 effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
 qualunque programma di scrittura o di disegno, in user space.
 

-Questo significa ad esempio che il sistema di per sé non dispone di primitive
-per tutta una serie di operazioni (come la copia di un file) che altri sistemi
-(come Windows) hanno invece al loro interno. Pertanto buona parte delle
-operazioni di normale amministrazione di un sistema, come quella in esempio,
-sono implementate come normali programmi.
+Questo significa, ad esempio, che il sistema di per sé non dispone di
+primitive per tutta una serie di operazioni (come la copia di un file) che
+altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona
+parte delle operazioni di normale amministrazione di un sistema, come quella
+in esempio, sono implementate come normali programmi.

 
 %Una delle caratteristiche base di unix \`e perci\`o che \`e possibile
 %realizzare un sistema di permessi e controlli che evitano che i programmi
 %eseguano accessi non autorizzati. 
 
 
 %Una delle caratteristiche base di unix \`e perci\`o che \`e possibile
 %realizzare un sistema di permessi e controlli che evitano che i programmi
 %eseguano accessi non autorizzati. 
 

-Per questo motivo è più corretto parlare di sistema GNU/Linux, in quanto da
-solo il kernel è assolutamente inutile, quello che costruisce un sistema
+Per questo motivo è più corretto parlare di un sistema GNU/Linux, in quanto da
+solo il kernel è assolutamente inutile; quello che costruisce un sistema

 operativo utilizzabile è la presenza di tutta una serie di librerie e
 programmi di utilità che permettono di eseguire le normali operazioni che ci
 si aspetta da un sistema operativo.
 operativo utilizzabile è la presenza di tutta una serie di librerie e
 programmi di utilità che permettono di eseguire le normali operazioni che ci
 si aspetta da un sistema operativo.


@@ -138,41 +138,41 @@ si aspetta da un sistema operativo.
 Come accennato le interfacce con cui i programmi possono accedere all'hardware
 vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system
   call}), si tratta di un insieme di funzioni, che un programma può chiamare,
 Come accennato le interfacce con cui i programmi possono accedere all'hardware
 vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system
   call}), si tratta di un insieme di funzioni, che un programma può chiamare,

-per le quali viene generata una interruzione processo e il controllo è passato
+per le quali viene generata una interruzione processo ed il controllo passa

 dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
 dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie

-di operazioni interne come la gestione del multitasking e il l'allocazione
-della memoria) eseguirà la funzione richiesta in kernel space restituendo i
+di operazioni interne come la gestione del multitasking e l'allocazione della
+memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i

 risultati al chiamante.
 
 Ogni versione unix ha storicamente sempre avuto un certo numero di queste
 chiamate, che sono riportate nella seconda sezione del \textsl{Manuale della
 risultati al chiamante.
 
 Ogni versione unix ha storicamente sempre avuto un certo numero di queste
 chiamate, che sono riportate nella seconda sezione del \textsl{Manuale della

-  programmazione di unix} (quella che si accede con il comando \cmd{man 2
-  nome}) e GNU/Linux non fa eccezione. Queste sono poi state codificate da vari
-standard, che esamineremo brevemente in \secref{sec:intro_standard}.
+  programmazione di unix} (quella cui si accede con il comando \cmd{man 2
+  nome}) e GNU/Linux non fa eccezione. Queste sono poi state codificate da
+vari standard, che esamineremo brevemente in \secref{sec:intro_standard}.

 
 Normalmente ciascuna di queste chiamate al sistema viene rimappata in
 opportune funzioni con lo stesso nome definite dentro la Libreria Standard del
 
 Normalmente ciascuna di queste chiamate al sistema viene rimappata in
 opportune funzioni con lo stesso nome definite dentro la Libreria Standard del

-C, che oltre alle interfacce alle system call contiene anche tutta una serie
-di ulteriori funzioni usate comunemente nella programmazione.
+C, che, oltre alle interfacce alle system call, contiene anche tutta una serie
+di ulteriori funzioni, comunemente usate nella programmazione.

 
 Questo è importante da capire perché programmare in Linux significa anzitutto
 
 Questo è importante da capire perché programmare in Linux significa anzitutto

-essere in grado di usare la Libreria Standard del C, in quanto né il kernel né
-il linguaggio C implementano direttamente operazioni comuni come la
+essere in grado di usare la Libreria Standard del C, in quanto né il kernel,
+né il linguaggio C, implementano direttamente operazioni comuni come la

 allocazione dinamica della memoria, l'input/output bufferizzato o la
 allocazione dinamica della memoria, l'input/output bufferizzato o la

-manipolazione delle stringhe presenti in qualunque programma.
+manipolazione delle stringhe, presenti in qualunque programma.

 
 Anche per questo in Linux è in effetti GNU/Linux, in quanto una parte
 essenziale del sistema (senza la quale niente può funzionare) è la
 realizzazione fatta dalla Free Software Foundation della suddetta libreria (la
 
 Anche per questo in Linux è in effetti GNU/Linux, in quanto una parte
 essenziale del sistema (senza la quale niente può funzionare) è la
 realizzazione fatta dalla Free Software Foundation della suddetta libreria (la

-GNU Standard C Library, in breve \textit{glibc}), in cui sono state
+GNU Standard C Library, detta in breve \textit{glibc}), in cui sono state

 implementate tutte le funzioni essenziali definite negli standard POSIX e ANSI
 C, che vengono utilizzate da qualunque programma.
 
 Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
 implementate tutte le funzioni essenziali definite negli standard POSIX e ANSI
 C, che vengono utilizzate da qualunque programma.
 
 Le funzioni di questa libreria sono quelle riportate dalla terza sezione del

-Manuale di Programmazione di Unix (cioè accessibili con il comando \cmd{man 2
-  nome}), e sono costruite sulla base delle chiamate al sistema del kernel; è
+Manuale di Programmazione di Unix (cioè accessibili con il comando \cmd{man 3
+  nome}) e sono costruite sulla base delle chiamate al sistema del kernel; è

 importante avere presente questa distinzione, fondamentale dal punto di vista
 importante avere presente questa distinzione, fondamentale dal punto di vista

-dell'implementazione, anche se poi nella realizzazione di normali programmi
+dell'implementazione, anche se poi, nella realizzazione di normali programmi,

 non si hanno differenze pratiche fra l'uso di una funzione di libreria e
 quello di una chiamata al sistema.
 
 non si hanno differenze pratiche fra l'uso di una funzione di libreria e
 quello di una chiamata al sistema.
 


@@ -182,18 +182,18 @@ quello di una chiamata al sistema.
 
 Linux, come gli altri unix, nasce fin dall'inizio come sistema multiutente,
 cioè in grado di fare lavorare più persone in contemporanea. Per questo
 
 Linux, come gli altri unix, nasce fin dall'inizio come sistema multiutente,
 cioè in grado di fare lavorare più persone in contemporanea. Per questo

-esistono una serie di meccanismi di sicurezza che non sono previsti in sistemi
-operativi monoutente e che occorre tenere presente.
+esistono una serie di meccanismi di sicurezza, che non sono previsti in
+sistemi operativi monoutente, e che occorre tenere presente.

 
 

-Il concetto base è quello di utente (\textit{user}) del sistema, utente che ha
-dei ben definiti limiti e capacità rispetto a quello che può fare. Sono così
-previsti una serie di meccanismi per identificare i singoli utenti ed una
-serie di permessi e protezioni per impedire che utenti diversi possano
+Il concetto base è quello di utente (\textit{user}) del sistema, le cui
+capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
+Sono così previsti una serie di meccanismi per identificare i singoli utenti
+ed una serie di permessi e protezioni per impedire che utenti diversi possano

 danneggiarsi a vicenda o danneggiare il sistema.
 
 Ad ogni utente è dato un nome \textit{username}, che è quello che viene
 richiesto all'ingresso nel sistema dalla procedura di \textit{login}. Questa
 danneggiarsi a vicenda o danneggiare il sistema.
 
 Ad ogni utente è dato un nome \textit{username}, che è quello che viene
 richiesto all'ingresso nel sistema dalla procedura di \textit{login}. Questa

-procedura si incarica di verificare la identità dell'utente (in genere
+procedura si incarica di verificare la identità dell'utente, in genere

 attraverso la richiesta di una parola d'ordine, anche se sono possibili
 meccanismi diversi\footnote{Ad esempio usando la libreria PAM
   (\textit{Pluggable Autentication Methods}) è possibile astrarre
 attraverso la richiesta di una parola d'ordine, anche se sono possibili
 meccanismi diversi\footnote{Ad esempio usando la libreria PAM
   (\textit{Pluggable Autentication Methods}) è possibile astrarre


@@ -212,10 +212,10 @@ accesso ai file e quindi anche alle periferiche, in maniera pi
 definendo gruppi di lavoro, di accesso a determinate risorse, etc.
 
 L'utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad
 definendo gruppi di lavoro, di accesso a determinate risorse, etc.
 
 L'utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad

-un nome in espresso in caratteri è inserita nei due files \file{/etc/passwd}
-e \file{/etc/groups}). Questi numeri sono l'\textit{user identifier}, detto
-in breve \acr{uid} e il \textit{group identifier}, detto in breve \acr{gid}
-che sono quelli che poi vengono usati dal kernel per riconoscere l'utente.
+un nome espresso in caratteri è inserita nei due files \file{/etc/passwd} e
+\file{/etc/groups}). Questi numeri sono l'\textit{user identifier}, detto in
+breve \acr{uid}, e il \textit{group identifier}, detto in breve \acr{gid}, che
+sono quelli che poi vengono usati dal kernel per identificare l'utente.

  
 In questo modo il sistema è in grado di tenere traccia per ogni processo
 dell'utente a cui appartiene ed impedire ad altri utenti di interferire con
  
 In questo modo il sistema è in grado di tenere traccia per ogni processo
 dell'utente a cui appartiene ed impedire ad altri utenti di interferire con


@@ -224,12 +224,13 @@ sicurezza interna in quanto anche l'accesso ai file (vedi
 \secref{sec:file_access_control}) è regolato da questo meccanismo di
 identificazione.
 
 \secref{sec:file_access_control}) è regolato da questo meccanismo di
 identificazione.
 

-Infine in ogni unix è presente un utente speciale privilegiato, di norma
-chiamato \textit{root}, il cui \acr{uid} è zero. Esso identifica
-l'amministratore del sistema, che deve essere in grado di fare qualunque
-operazione; per l'utente \textit{root} infatti i meccanismi di controllo
-descritti in precedenza sono disattivati\footnote{i controlli infatti vengono
-  sempre eseguiti da un codice del tipo \texttt{if (uid) \{ ... \}}}.
+Infine in ogni unix è presente un utente speciale privilegiato, il cosiddetto
+\textit{superuser}, il cui username è di norma \textit{root}, ed il cui
+\acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
+essere in grado di fare qualunque operazione; per l'utente \textit{root}
+infatti i meccanismi di controllo descritti in precedenza sono
+disattivati\footnote{i controlli infatti vengono sempre eseguiti da un codice
+  del tipo \texttt{if (uid) \{ ... \}}}.

 
 
 \section{Gli standard di unix e GNU/Linux}
 
 
 \section{Gli standard di unix e GNU/Linux}


@@ -254,8 +255,8 @@ come standard internazionale con la sigla ISO/IEC 9899:1990.
 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
 sistemi operativi diversi, ma oltre alla sintassi e alla semantica del
 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
 sistemi operativi diversi, ma oltre alla sintassi e alla semantica del
 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede

-anche una libreria di funzioni standard che devono poter essere implementate
-su qualunque sistema operativo.
+anche una libreria di funzioni che devono poter essere implementate su
+qualunque sistema operativo.

 
 Linux, come molti unix moderni, provvede la compatibilità con questo standard,
 fornendo le funzioni di libreria da esso previste; queste sono dichiarate in
 
 Linux, come molti unix moderni, provvede la compatibilità con questo standard,
 fornendo le funzioni di libreria da esso previste; queste sono dichiarate in


@@ -270,18 +271,18 @@ In realt
 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
 X finale denuncia la sua stretta relazione con i sistemi unix. Esso nasce dal
 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
 X finale denuncia la sua stretta relazione con i sistemi unix. Esso nasce dal
 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})

-che ne ha prodotto un primo una prima versione, nota come IEEE 1003.1-1988,
-mirante a standardizzare l'interfaccia con il sistema operativo.
+che ne ha prodotto una prima versione, nota come IEEE 1003.1-1988, mirante a
+standardizzare l'interfaccia con il sistema operativo.

 
 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
 le utilities di sistema (1003.2), per le estensioni realtime e per i thread
 
 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
 le utilities di sistema (1003.2), per le estensioni realtime e per i thread

-(1003.1d e 1003.1c) e molti altri. 
+(1003.1d e 1003.1c) e vari altri. 

 
 

-Benchè lo standard POSIX sia basato sui sistemi unix esso definisce comunque
-una interfaccia e non fa riferimento ad una specifica implementazione (per cui
-esiste ad esempio anche una implementazione di questo standard pure sotto
-Windows NT). Lo standard si è evoluto nel tempo ed una nuova versione (quella
+Benché lo standard POSIX sia basato sui sistemi unix esso definisce comunque
+una interfaccia e non fa riferimento ad una specifica implementazione (ad
+esempio esiste anche una implementazione di questo standard pure sotto Windows
+NT). Lo standard si è evoluto nel tempo ed una versione più aggiornata (quella

 che viene normalmente denominata POSIX.1) è stata rilasciata come standard
 internazionale con la sigla ISO/IEC 9945-1:1990.
 
 che viene normalmente denominata POSIX.1) è stata rilasciata come standard
 internazionale con la sigla ISO/IEC 9945-1:1990.
 


@@ -289,9 +290,9 @@ internazionale con la sigla ISO/IEC 9945-1:1990.
 \subsection{Lo standard X/Open -- XPG3}
 \label{sec:intro_xopen}
 
 \subsection{Lo standard X/Open -- XPG3}
 \label{sec:intro_xopen}
 

-Il consorzio X/Open nasce come consorzio di venditori di sistemi unix, che nel
-1989 produsse una voluminosa guida chiamata \textit{X/Open Portability Guide,
-  Issue 3} al cui interno definiva una ulteriore standardizzazione
+Il consorzio X/Open nacque come consorzio di venditori di sistemi unix, che
+nel 1989 produsse una voluminosa guida chiamata \textit{X/Open Portability
+  Guide, Issue 3} al cui interno definiva una ulteriore standardizzazione

 dell'interfaccia ad un sistema unix.
 
 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
 dell'interfaccia ad un sistema unix.
 
 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre

diff --git a/pref.tex b/pref.tex
index e21f38540de9af840a98570f69e72687a39caa60..fb592801d24fa69502d9e9142ae772410f132419 100644 (file)
--- a/pref.tex
+++ b/pref.tex
@@ -1,4 +1,5 @@
 \chapter{Prefazione}
 \chapter{Prefazione}

+\label{cha:preface}

 
 Nelle motivazioni in cui si introduce la GNU Free Documentation License (FDL)
 (reperibili su http://www.gnu.org/philosophy/free-doc.html) si dà una grande
 
 Nelle motivazioni in cui si introduce la GNU Free Documentation License (FDL)
 (reperibili su http://www.gnu.org/philosophy/free-doc.html) si dà una grande


@@ -18,7 +19,7 @@ un programma.
 
 Esiste però un altro campo, diverso dalla documentazione e dai manuali, in cui
 avere a disposizione testi liberi, aperti e modificabili è essenziale ed
 
 Esiste però un altro campo, diverso dalla documentazione e dai manuali, in cui
 avere a disposizione testi liberi, aperti e modificabili è essenziale ed

-estremamente utile, quello della didattica e dell'educazione.  E benché questo
+estremamente utile: quello della didattica e dell'educazione.  E benché questo

 sia citato dalla FDL non è altrettanto comune trovarlo messo in pratica.
 
 In particolare sarebbe di grande interesse poter disporre di testi didattici
 sia citato dalla FDL non è altrettanto comune trovarlo messo in pratica.
 
 In particolare sarebbe di grande interesse poter disporre di testi didattici


@@ -45,18 +46,18 @@ particolari dell'argomento in esame (in particolare il manuale delle glibc non
 brilla certo per chiarezza espositiva).
 
 Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
 brilla certo per chiarezza espositiva).
 
 Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di

-R. Stevens (in particolare Advanced Programming in the Unix Environment e Unix
-Network Programming) per rendere in una sequenza logica il più esplicativa
-possibile la trattazione dei vari argomenti.
+R. Stevens (in particolare \textit{Advanced Programming in the Unix
+  Environment} e \textit{Unix Network Programming}) per rendere la trattazione
+dei vari argomenti in una sequenza logica il più esplicativa possibile.

 
 Il progetto prevede il rilascio del testo sotto licenza FDL, ed una modalità
 di realizzazione aperta che permetta di accogliere i contributi di chiunque
 sia interessato.
 
 Dato che lo scopo del progetto è la produzione di un libro si è scelto di
 
 Il progetto prevede il rilascio del testo sotto licenza FDL, ed una modalità
 di realizzazione aperta che permetta di accogliere i contributi di chiunque
 sia interessato.
 
 Dato che lo scopo del progetto è la produzione di un libro si è scelto di

-usare latex come "ambiente di sviluppo" del medesimo, sia per l'impareggiabile
-qualità tipografica ottenibile, che per la congruenza dello strumento sia sul
-piano pratico che su quello filosofico.
+usare Latex come "ambiente di sviluppo" del medesimo, sia per l'impareggiabile
+qualità tipografica ottenibile, che per la congruenza dello strumento tanto sul
+piano pratico quanto su quello filosofico.

 
 Il testo sarà, almeno inizialmente, in italiano.
 
 
 Il testo sarà, almeno inizialmente, in italiano.