-\chapter{L'architettura di GNU/Linux}
+\chapter{L'architettura del sistema}
\label{cha:intro_unix}
In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
-cui è basato un sistema di tipo Unix come GNU/Linux, in questo modo potremo
-fornire una base di comprensione mirata a sottolineare le peculiarità del
-sistema che sono più rilevanti per quello che riguarda la programmazione.
+cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
+potremo 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 base dell'architettura di
sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
saltare questa sezione.
+
+\subsection{Concetti base}
+\label{sec:intro_base_concept}
+
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
-anche la parte che prevede l'interazione con l'utente, deve venire realizzato
-tramite programmi eseguiti dal kernel e che accedano alle risorse hardware
-tramite delle richieste a quest'ultimo.
+cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
+gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
+tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
+deve venire realizzato tramite programmi eseguiti dal kernel e che accedano
+alle risorse hardware 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ù
%computer (e quindi per un uso personale), sui quali l'hardware (allora
%limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
-Gli Unix più recenti, come Linux, sono realizzati sfruttando alcune
+I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
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
%realizzare un sistema di permessi e controlli che evitano che i programmi
%eseguano accessi non autorizzati.
-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.
+Per questo motivo quando ci si riferisce al sistema nella sua interezza è
+corretto parlare di un sistema GNU/Linux: 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 di norma sono
+quelli realizzati dal progetto GNU della Free Softwae Foundation) che
+permettono di eseguire le normali operazioni che ci si aspetta da un sistema
+operativo.
\subsection{Chiamate al sistema e librerie di funzioni}
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 un'interruzione processo ed il controllo passa dal
-programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie di
-operazioni interne come la gestione del multitasking e l'allocazione della
+ call}), si tratta di un insieme di funzioni che un programma può chiamare, w
+per le quali viene generata un'interruzione del processo ed il controllo passa
+dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
+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 di 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 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}.
+ nome}) e inux 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, comunemente usate nella programmazione.
+C, che, oltre alle interfacce alle system call, contiene anche tutta la serie
+delle ulteriori funzioni definite dai vari standard, che sono comunemente
+usate 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.
-
-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, 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.
+essere in grado di usare le varie interfacce contenute nella 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.
+
+Anche questo ci mostra in maniera evidente come nella stragrande magggioranza
+dei casi,\footnote{esistono implementazioni diverse delle librerie del C, come
+ le \textit{libc5}, che non derivano dal progetto GNU, ma oggi sono, tranne
+ casi particolari, completamente soppiantate dalle \acr{glibc}.} quello che
+si sta utilizzando è un sistema 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,
+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
Manuale di Programmazione di Unix (cioè accessibili con il comando \cmd{man 3
\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
+Linux, come gli altri kernel 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, le cui
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) \{ ... \}}}
+ del tipo \code{if (uid) \{ ... \}}}
-\section{Gli standard di Unix e GNU/Linux}
+\section{Gli standard}
\label{sec:intro_standard}
In questa sezione faremo una breve panoramica relativa ai vari standard che
sono stabilite come standard di fatto in quanto facenti parte di alcune
implementazioni molto diffuse come BSD o SVr4.
-Ovviamente prenderemo in considerazione solo gli aspetti riguardanti
+Ovviamente prenderemo in considerazione solo gli standard riguardanti
interfacce di programmazione e le altre caratteristiche di un sistema
-unix-like ed in particolare a come e in che modo essi sono supportati da
-GNU/Linux (sia per quanto riguarda il kernel che le \acr{glibc}).
+unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
+ed in particolare ci concentreremo sul come ed in che modo essi sono
+supportati sia per quanto riguarda il kernel che le librerie del C (con una
+particolare attenzione alle \acr{glibc}).
\subsection{Lo standard ANSI C}
qualunque sistema operativo.
Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
-di tipo Unix, GNU/Linux (per essere precisi le glibc), come molti Unix
+di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
moderni, provvede la compatibilità con questo standard, fornendo le funzioni
di libreria da esso previste. Queste sono dichiarate in quindici header file
(anch'essi provvisti dalla \acr{glibc}), uno per ciascuna delle quindici aree
-in cui è stata suddivisa una libreria standard. In \ntab\ si sono riportati
-questi header, insieme a quelli definiti negli altri standard descritti nelle
-sezioni successive.
+in cui è stata suddivisa una libreria standard. In (\ntab\ da fare) si sono
+riportati questi header, insieme a quelli definiti negli altri standard
+descritti nelle sezioni successive.
In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
\label{sec:intro_posix}
Uno standard più attinente al sistema nel suo complesso (e che concerne sia il
-kernel che le librerie è lo standard POSIX. Esso prende origine dallo standard
-ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità per le
-funzioni in esso definite, ed aggiungendone di nuove.
+kernel che le librerie) è lo standard POSIX. Esso prende origine dallo
+standard ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità
+per le funzioni in esso definite, ed aggiungendone di nuove.
In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
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 utility di sistema (1003.2), per le estensioni realtime e per i thread
-(1003.1d e 1003.1c) e vari altri.
+i comandi di sistema (1003.2), per le estensioni realtime e per i thread
+(1003.1d e 1003.1c) e vari altri.
Benché lo standard POSIX sia basato sui sistemi Unix esso definisce comunque
-un'interfaccia e non fa riferimento ad una specifica implementazione (ad
-esempio esiste un'implementazione di questo standard anche 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:1996.
+un'interfaccia di programmazione generica e non fa riferimento ad una
+implementazione specifica (ad esempio esiste un'implementazione di questo
+standard anche 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:1996.
Le \acr{glibc} implementano tutte le funzioni definite nello standard POSIX.1,
-e Linux;
+fornendo in più alcune ulteriori capacità (per funzioni di \textit{pattern
+ matching} e per la manipolazione delle \textit{regular expression}), che
+usate dalla shell e dai comandi di sistema e che sono definite nello standard
+POSIX.2.
\subsection{Lo standard X/Open -- XPG3}
completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
della AT/T.
-Benchè BSD non sia uno standard formalizzato, l'implementazione di Unix
+Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e
di API grande rilievo, come il link simbolici, la funzione \code{select}, i
socket.
\subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}}
\label{sec:intro_gcc_glibc_std}
-In Linux gli standard appena descritti sono ottenibili sia attraverso l'uso di
-opzioni del compilatore (il \cmd{gcc}) che definendo opportune costanti prima
-della inclusione dei file degli header.
+In Linux grazie alle \acr{glibc} gli standard appena descritti sono ottenibili
+sia attraverso l'uso di opzioni del compilatore (il \cmd{gcc}) che definendo
+opportune costanti prima della inclusione dei file degli header.
Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
si può usare l'opzione \cmd{-ansi} del compilatore, e non sarà riconosciuta
includere i vari header file.
-\subsection{Gli standard di Linux}
+\subsection{Gli standard di GNU/Linux}
\label{sec:intro_linux_std}
Da fare (o cassare, a seconda del tempo e della voglia).
projects / gapil.git / blobdiff