-\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
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
\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
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 sistema}
+\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
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}
-\label{sec:intro_usergroup}
-
-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 base di sicurezza che non sono previsti in sistemi operativi
-monoutente.
+\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{Un sistema multiutente}
+\label{sec:intro_multiuser}
+
+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.
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ì
accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
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 \`e inserita nei due files
-\texttt{/etc/passwd} e \texttt{/etc/groups}). Questi numeri sono
-l'\textit{user identifier}, detto in breve \textit{uid} e il \textit{group
- identifier}, detto in breve \textit{gid} che sono quelli che identificano
-l'utente di fronte al sistema.
+% L'utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad
+% un nome in espresso in caratteri \`e inserita nei due files
+% \texttt{/etc/passwd} e \texttt{/etc/groups}). Questi numeri sono
+% l'\textit{user identifier}, detto in breve \textit{uid} e il \textit{group
+% identifier}, detto in breve \textit{gid} che sono quelli che identificano
+% l'utente di fronte al sistema.
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
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}
+
+
+
+
projects / gapil.git / blobdiff