X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=intro.tex;h=4e97e31d6d93385fb1407b1faee49fdfad431dd6;hp=4e8dd690c553288de0a130874ccb3b4d888f0173;hb=55bb7b212e8a450f8c9c0f840d5cf0de4c428380;hpb=eb318a83679841eada97ff880e361b5a5f62bb02

diff --git a/intro.tex b/intro.tex
index 4e8dd69..4e97e31 100644
--- a/intro.tex
+++ b/intro.tex
@@ -1,18 +1,24 @@
-\chapter{Introduzione}
+\chapter{L'architettura di GNU/Linux}
 \label{cha:intro_unix}
 
 In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
-cui è basato un sistema di tipo unix, per fornire una base di comprensione
-mirata a sottolineare le peculiarità che saranno poi importanti per quello
-che riguarda la programmazione; in particolare faremo una panoramica sulla
-struttura di un sistema \textit{unix-like} come Linux.
+cui è basato un sistema di tipo unix come GNU/Linux, per fornire una base di
+comprensione mirata a sottolineare le peculiarità che saranno poi importanti
+per quello che riguarda la programmazione. 
 
-Chi avesse già una conoscenza di questa materia può tranquillamente saltare
-il capitolo.
+Dopo un introduzione sulle caratteristiche principali di un sistema di tipo
+unix passeremo ad illustrare alcuni dei concetti basi dell'architettura di
+Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed
+introdurremo alcunoi degli standard princincipali a cui si fa riferimento.
 
-\section{La struttura di un sistema Unix}
+
+\section{Una panoramica sulla struttura}
 \label{sec:intro_unix_struct}
 
+In questa prima sezione faremo una panoramica sulla struttura di un sistema
+\textit{unix-like} come Linux.  Chi avesse già una conoscenza di questa
+materia può tranquillamente saltare questa sezione.
+
 Il concetto base di un sistema unix-like é quello di un nucleo del sistema (il
 cosiddetto \textit{kernel}) a cui si demanda la gestione delle risorse
 essenziali (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi
@@ -44,12 +50,11 @@ o alle porte di input/output).
 
 Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, ad
 intervalli fissi e sulla base di un opportuno calcolo delle priorità, quale
-``processo'' (vedi \capref{cha:process}) deve essere posto in esecuzione (il
-cosiddetto \textit{prehemptive scheduling}). Questo verrà comunque eseguito
-in modalità protetta; quando necessario il processo potrà accedere alle
-risorse hardware soltanto attraverso delle opportune chiamate al sistema
-(\textit{system call}) con un'interfaccia ben definita e standardizzata che
-restituiranno il controllo al kernel.
+``processo'' deve essere posto in esecuzione (il cosiddetto
+\textit{prehemptive scheduling}). Questo verrà comunque eseguito in modalità
+protetta; quando necessario il processo potrà accedere alle risorse hardware
+soltanto attraverso delle opportune chiamate al sistema che restituiranno il
+controllo al kernel.
 
 La memoria viene sempre gestita del kernel attraverso il meccanismo della
 memoria virtuale, che consente di assegnare a ciascun processo uno spazio di
@@ -68,16 +73,16 @@ livello 
 
 
 \section{User space e kernel space}
-\label{sec:intro_userkernel}
+\label{sec:intro_user_kernel_space}
 
-L'architettura appena descritta fa sì che nei sistemi unix esista una
-distinzione essenziale fra il cosiddetto \textit{user space}, che
+Uno dei concetti fondamentale 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
 \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 (che esamineremo nel \capref{cha:IPC}) completamente ignaro
-del fatto che altri programmi possono essere messi in esecuzione dal kernel.
+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
+essere messi in esecuzione dal kernel.
 
 Per questa separazione non è possibile ad un singolo programma disturbare
 l'azione di un altro programma o del sistema e questo è il principale motivo
@@ -90,21 +95,9 @@ all'hardware non pu
 kernel il programmatore deve usare le opportune interfacce che quest'ultimo
 fornisce allo user space. 
 
-In genere queste vanno sotto il nome di chiamate al sistema (le cosiddette
-\textit{system call}), cioè un insieme di routine che un programma può
-chiamare per le quali viene generata una interruzione del medesimo e il
-controllo è passato dal programma al kernel, il quale (oltre a fare una serie
-di altre cose come controllare a quale processo tocca essere messo in
-esecuzione) eseguirà la funzione richiesta in kernel space passando indietro i
-risultati.
-
-È da chiarire poi che di solito i programmi non chiamano direttamente le
-singole system call, ma usano un insieme di funzioni standard (definite dallo
-standard internazionale POSIX1003.a(?)) che sono comuni a tutti gli unix.
-
 
-\section{Il kernel e il resto}
-\label{sec:intro_kernandlib}
+\subsection{Il kernel e il resto}
+\label{sec:intro_kern_and_sys}
 
 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
@@ -138,20 +131,52 @@ operativo utilizzabile 
 programmi di utilità che permettono di eseguire le normali operazioni che ci
 si aspetta da un sistema operativo.
 
-Questo è importante anche dal punto di vista della programmazione, infatti
-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 gestione della memoria, l'input/output
-o la manipolazione delle stringhe presenti in qualunque programma.
 
-Per questo in GNU/Linux una parte essenziale del sistema (senza la quale nulla
-funziona) è la realizzazione fatta dalla FSF della suddetta libreria (la
-\textit{glibc}), in cui sono state implementate tutte le funzioni essenziali
-definite negli standard POSIX e ANSI C, che viene utilizzata da qualunque
-programma.
-
-
-\section{Utenti e gruppi, permessi e protezioni}
+\subsection{Chiamate al sistema e librerie di funzioni}
+\label{sec:intro_syscall}
+
+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 routine che un programma può chiamare per
+le quali viene generata una interruzione e il controllo è passato dal
+programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie di
+operazioni interne come la gestione del multitaskin e il l'allocazione della
+memoria) eseguirà la funzione richiesta in 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
+  programmazione di unix} (quella che si accede con il comando \texttt{man 2})
+e 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
+C, che oltre alle interfacce alle system call contiene anche tutta una serie
+di ulteriori funzioni usate comunemente nella programmazione.
+
+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
+allocazione dinamica della memoria, l'input/output bufferizzato o la
+manipolazione delle stringhe presenti in qualunque programma.
+
+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 implementate tutte le funzioni
+essenziali definite negli standard POSIX e ANSI C, e che viene utilizzata da
+qualunque programma.
+
+Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
+Manuale di Programmazione di Unix, e sono costruite sulla base delle chiamate
+al sistema del kernel; è importante avere presente questa distinzione,
+fondamentale dal punto di vista dell'implementazione, anche se poi nella
+relizzazione di normali programmi non si hanno differenze pratiche fra l'uso
+di una funzione di libreria e quello di una chiamata al sistema.
+
+
+\subsection{Utenti e gruppi, permessi e protezioni}
 \label{sec:intro_usergroup}
 
 Unix nasce fin dall'inizio come sistema multiutente, cioè in grado di fare
@@ -201,5 +226,21 @@ qualunque operazione; pertanto per l'utente root i meccanismi di controllo
 descritti in precedenza sono disattivati.
 
 
+\section{Gli standard di unix e Linux}
+\label{sec:intro_standard}
+
+
+
+\subsection{Lo standard ANSI C}
+\label{sec:intro_ansiC}
+
+
+
+\subsection{Lo standard POSIX}
+\label{sec:intro_ansiC}
+
+
+
+