intro.tex

   1 %% intro.tex
   2 %%
   3 %% Copyright (C) 2000-2007 Simone Piccardi.  Permission is granted to
   4 %% copy, distribute and/or modify this document under the terms of the GNU Free
   5 %% Documentation License, Version 1.1 or any later version published by the
   6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
   7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
   8 %% license is included in the section entitled "GNU Free Documentation
   9 %% License".
  10 %%
  11
  12 \chapter{L'architettura del sistema}
  13 \label{cha:intro_unix}
  14
  15 In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
  16 cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
  17 potremo fornire una base di comprensione mirata a sottolineare le peculiarità
  18 del sistema che sono più rilevanti per quello che riguarda la programmazione.
  19
  20 Dopo un'introduzione sulle caratteristiche principali di un sistema di tipo
  21 Unix passeremo ad illustrare alcuni dei concetti base dell'architettura di
  22 GNU/Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed
  23 introdurremo alcuni degli standard principali a cui viene fatto riferimento.
  24
  25
  26 \section{Una panoramica}
  27 \label{sec:intro_unix_struct}
  28
  29 In questa prima sezione faremo una breve panoramica sull'architettura del
  30 sistema.  Chi avesse già una conoscenza di questa materia può tranquillamente
  31 saltare questa sezione.
  32
  33
  34 \subsection{Concetti base}
  35 \label{sec:intro_base_concept}
  36
  37 Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
  38 cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
  39 gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
  40 tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
  41 dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano
  42 alle risorse hardware tramite delle richieste a quest'ultimo.
  43
  44 Fin dall'inizio uno Unix si presenta come un sistema operativo
  45 \textit{multitasking}, cioè in grado di eseguire contemporaneamente più
  46 programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
  47 una macchina eseguendo più programmi ``in contemporanea'' (in realtà, almeno
  48 per macchine a processore singolo, i programmi vengono eseguiti singolarmente
  49 a rotazione).
  50
  51 % Questa e` una distinzione essenziale da capire,
  52 %specie nei confronti dei sistemi operativi successivi, nati per i personal
  53 %computer (e quindi per un uso personale), sui quali l'hardware (allora
  54 %limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
  55
  56 I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
  57 caratteristiche dei processori moderni come la gestione hardware della memoria
  58 e la modalità protetta. In sostanza con i processori moderni si può
  59 disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
  60 zone di memoria fisica.  Quello che succede è che il kernel è il solo
  61 programma ad essere eseguito in modalità privilegiata, con il completo accesso
  62 all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
  63 (e non possono accedere direttamente alle zone di memoria riservate o alle
  64 porte di input/output).
  65
  66 Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
  67 stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
  68 priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
  69 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
  70   multitasking}).  Questo verrà comunque eseguito in modalità protetta; quando
  71 necessario il processo potrà accedere alle risorse hardware soltanto
  72 attraverso delle opportune chiamate al sistema che restituiranno il controllo
  73 al kernel.
  74
  75 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
  76 \index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
  77 a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
  78 sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
  79 gestione della memoria, si incaricherà di rimappare automaticamente sulla
  80 memoria disponibile, salvando su disco quando necessario (nella cosiddetta
  81 area di \textit{swap}) le pagine di memoria in eccedenza.
  82
  83 Le periferiche infine vengono viste in genere attraverso un'interfaccia
  84 astratta che permette di trattarle come fossero file, secondo il concetto per
  85 cui \textit{everything is a file}, su cui torneremo in dettaglio in
  86 cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
  87 hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
  88 il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
  89
  90
  91 \subsection{Il kernel e il sistema}
  92 \label{sec:intro_kern_and_sys}
  93
  94 Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
  95 quello della distinzione fra il cosiddetto \textit{user space}, che
  96 contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
  97 \textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
  98 programma vede sé stesso come se avesse la piena disponibilità della CPU e
  99 della memoria ed è, salvo i meccanismi di comunicazione previsti
 100 dall'architettura, completamente ignaro del fatto che altri programmi possono
 101 essere messi in esecuzione dal kernel.
 102
 103 Per questa separazione non è possibile ad un singolo programma disturbare
 104 l'azione di un altro programma o del sistema e questo è il principale motivo
 105 della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
 106 i processi non hanno di questi limiti, o che vengono per vari motivi eseguiti
 107 al livello del kernel.
 108
 109 Pertanto deve essere chiaro a chi programma in Unix che l'accesso diretto
 110 all'hardware non può avvenire se non all'interno del kernel; al di fuori dal
 111 kernel il programmatore deve usare le opportune interfacce che quest'ultimo
 112 fornisce allo user space.
 113
 114 Per capire meglio la distinzione fra kernel space e user space si può prendere
 115 in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
 116 in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
 117 avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
 118   un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
 119   stringhe delle scarpe'', per indicare il compito, almeno apparentemente
 120   impossibile, di far eseguire un programma a partire da un computer appena
 121   acceso che appunto non ne contiene nessuno; non è impossibile perché in
 122   realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
 123 caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
 124 dopo aver inizializzato le periferiche, farà partire il primo processo,
 125 \cmd{init}, che è quello che a sua volta farà partire tutti i processi
 126 successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
 127 tastiera e lo schermo della console, e quello che mette a disposizione
 128 dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
 129 inviare i comandi.
 130
 131 E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
 132 sistema, non abbia in realtà niente a che fare con il kernel, ma sia
 133 effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
 134 qualunque programma di scrittura o di disegno, in user space.
 135
 136 Questo significa, ad esempio, che il sistema di per sé non dispone di
 137 primitive per tutta una serie di operazioni (come la copia di un file) che
 138 altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona
 139 parte delle operazioni di normale amministrazione di un sistema, come quella
 140 in esempio, sono implementate come normali programmi.
 141
 142 %Una delle caratteristiche base di unix \`e perci\`o che \`e possibile
 143 %realizzare un sistema di permessi e controlli che evitano che i programmi
 144 %eseguano accessi non autorizzati.
 145
 146 Per questo motivo quando ci si riferisce al sistema nella sua interezza è
 147 corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
 148 inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
 149 di tutta una serie di librerie e programmi di utilità (che di norma sono
 150 quelli realizzati dal progetto GNU della Free Software Foundation) che
 151 permettono di eseguire le normali operazioni che ci si aspetta da un sistema
 152 operativo.
 153
 154
 155 \subsection{Chiamate al sistema e librerie di funzioni}
 156 \label{sec:intro_syscall}
 157
 158 Come accennato le interfacce con cui i programmi possono accedere all'hardware
 159 vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system
 160   call}), si tratta di un insieme di funzioni che un programma può chiamare,
 161 per le quali viene generata un'interruzione del processo passando il controllo
 162 dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
 163 di operazioni interne come la gestione del multitasking e l'allocazione della
 164 memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i
 165 risultati al chiamante.
 166
 167 Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste
 168 chiamate, che sono riportate nella seconda sezione del \textsl{Manuale di
 169   programmazione di Unix} (quella cui si accede con il comando \cmd{man 2
 170   <nome>}) e Linux non fa eccezione. Queste sono poi state codificate da vari
 171 standard, che esamineremo brevemente in sez.~\ref{sec:intro_standard}. Uno
 172 schema elementare della struttura del sistema è riportato in
 173 fig.~\ref{fig:intro_sys_struct}.
 174
 175 \begin{figure}[htb]
 176   \centering
 177 %  \includegraphics[width=10cm]{img/struct_sys}
 178   \begin{tikzpicture}
 179     \filldraw[fill=black!20] (0,0) rectangle (7.5,1);
 180     \draw (3.75,0.5) node {System Call Interface};
 181     \filldraw[fill=black!35] (0,1) rectangle (7.5,4);
 182     \draw (3.75,2.5) node {\huge{kernel}};
 183     \filldraw[fill=black!20] (0,4) rectangle (2.5,5);
 184     \draw (1.25,4.5) node {scheduler};
 185     \filldraw[fill=black!20] (2.5,4) rectangle (5,5);
 186     \draw (3.75,4.5) node {VM};
 187     \filldraw[fill=black!20] (5,4) rectangle (7.5,5);
 188     \draw (6.25,4.5) node {driver};
 189
 190     \draw (1.25,7) node(cpu) [ellipse,draw] {CPU};
 191     \draw (3.75,7) node(mem) [ellipse,draw] {memoria};
 192     \draw (6.25,7) node(disk) [ellipse,draw] {disco};
 193
 194     \draw[<->] (cpu) -- (1.25,5);
 195     \draw[<->] (mem) -- (3.75,5);
 196     \draw[<->] (disk) -- (6.25,5);
 197
 198     \draw (7.5,0) node [anchor=base west] {kernel space};
 199     \draw (7.5,-1) node [anchor=west] {user space};
 200
 201     \draw (-1,-0.5) -- (8.5, -0.5);
 202
 203     \draw (0,-2) rectangle (7.5,-1);
 204     \draw (3.75, -1.5) node {GNU C Library};
 205     \draw[->] (1.25,-1) -- (1.25,0);
 206     \draw[->] (3.75,-1) -- (3.75,0);
 207     \draw[->] (6.25,-1) -- (6.25,0);
 208
 209     \draw (1.25,-3) node(proc1) [rectangle,draw] {processo};
 210     \draw (3.75,-3) node(proc2) [rectangle,draw] {processo};
 211     \draw (6.25,-3) node(proc3) [rectangle,draw] {processo};
 212
 213     \draw[->] (1.25,-2) -- (proc1);
 214     \draw[->] (3.75,-2) -- (proc2);
 215     \draw[->] (6.25,-2) -- (proc3);
 216   \end{tikzpicture}
 217   \caption{Schema di massima della struttura di interazione fra processi,
 218     kernel e dispositivi in Linux.}
 219   \label{fig:intro_sys_struct}
 220 \end{figure}
 221
 222 Normalmente ciascuna di queste chiamate al sistema viene rimappata in
 223 opportune funzioni con lo stesso nome definite dentro la Libreria Standard del
 224 C, che, oltre alle interfacce alle system call, contiene anche tutta la serie
 225 delle ulteriori funzioni definite dai vari standard, che sono comunemente
 226 usate nella programmazione.
 227
 228 Questo è importante da capire perché programmare in Linux significa anzitutto
 229 essere in grado di usare le varie interfacce contenute nella Libreria Standard
 230 del C, in quanto né il kernel, né il linguaggio C implementano direttamente
 231 operazioni comuni come l'allocazione dinamica della memoria, l'input/output
 232 bufferizzato o la manipolazione delle stringhe, presenti in qualunque
 233 programma.
 234
 235 Quanto appena illustrato mette in evidenza il fatto che nella stragrande
 236 maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie
 237   Standard del C, come le \textit{libc5} o le \textit{uClib}, che non derivano
 238   dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
 239   completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
 240   essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
 241   embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
 242   togliere le parti non necessarie), e pertanto costituiscono un valido
 243   rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
 244   richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
 245 GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
 246 sistema (senza la quale niente funzionerebbe) è la GNU Standard C Library (in
 247 breve \acr{glibc}), ovvero la libreria realizzata dalla Free Software
 248 Foundation nella quale sono state implementate tutte le funzioni essenziali
 249 definite negli standard POSIX e ANSI C, utilizzabili da qualunque programma.
 250
 251 Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
 252 \textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
 253 \cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al sistema del
 254 kernel; è importante avere presente questa distinzione, fondamentale dal punto
 255 di vista dell'implementazione, anche se poi, nella realizzazione di normali
 256 programmi, non si hanno differenze pratiche fra l'uso di una funzione di
 257 libreria e quello di una chiamata al sistema.
 258
 259
 260 \subsection{Un sistema multiutente}
 261 \label{sec:intro_multiuser}
 262
 263 Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
 264 multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
 265 questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
 266 sistemi operativi monoutente, e che occorre tenere presente.
 267
 268 Il concetto base è quello di utente (\textit{user}) del sistema, le cui
 269 capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
 270 Sono così previsti una serie di meccanismi per identificare i singoli utenti
 271 ed una serie di permessi e protezioni per impedire che utenti diversi possano
 272 danneggiarsi a vicenda o danneggiare il sistema.
 273
 274 Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
 275 viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
 276 (descritta in dettaglio in sez.~\ref{sec:sess_login}).  Questa procedura si
 277 incarica di verificare l'identità dell'utente, in genere attraverso la
 278 richiesta di una parola d'ordine (la \textit{password}), anche se sono
 279 possibili meccanismi diversi.\footnote{ad esempio usando la libreria PAM
 280   (\textit{Pluggable Autentication Methods}) è possibile astrarre
 281   completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso
 282   delle password con meccanismi di identificazione biometrica.}
 283
 284 Eseguita la procedura di riconoscimento in genere il sistema manda in
 285 esecuzione un programma di interfaccia (che può essere la \textit{shell} su
 286 terminale o un'interfaccia grafica) che mette a disposizione dell'utente un
 287 meccanismo con cui questo può impartire comandi o eseguire altri programmi.
 288
 289 Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
 290 \textit{default group}), ma può essere associato ad altri gruppi (i
 291 \textit{supplementary group}), questo permette di gestire i permessi di
 292 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
 293 definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
 294
 295 L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
 296 un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
 297 \conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
 298   vedremo in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
 299   mantenute, con l'uso del \itindex{Name~Service~Switch} \textit{Name Service
 300     Switch}, su varie tipologie di supporti, compresi server centralizzati
 301   come LDAP.}  Questi numeri sono l'\textit{user identifier}, detto in breve
 302 \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group
 303   identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
 304 \acr{gid}, e sono quelli che vengono usati dal kernel per identificare
 305 l'utente.
 306
 307 In questo modo il sistema è in grado di tenere traccia dell'utente a cui
 308 appartiene ciascun processo ed impedire ad altri utenti di interferire con
 309 quest'ultimo.  Inoltre con questo sistema viene anche garantita una forma base
 310 di sicurezza interna in quanto anche l'accesso ai file (vedi
 311 sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
 312 identificazione.
 313
 314 Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
 315 \textit{superuser}, il cui username è di norma \textit{root}, ed il cui
 316 \acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
 317 essere in grado di fare qualunque operazione; per l'utente \textit{root}
 318 infatti i meccanismi di controllo descritti in precedenza sono
 319 disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
 320   del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
 321
 322
 323 \section{Gli standard}
 324 \label{sec:intro_standard}
 325
 326 In questa sezione faremo una breve panoramica relativa ai vari standard che
 327 nel tempo sono stati formalizzati da enti, associazioni, consorzi e
 328 organizzazioni varie al riguardo del sistema o alle caratteristiche che si
 329 sono stabilite come standard di fatto in quanto facenti parte di alcune
 330 implementazioni molto diffuse come BSD o SVr4.
 331
 332 Ovviamente prenderemo in considerazione solo gli standard riguardanti
 333 interfacce di programmazione e le altre caratteristiche di un sistema
 334 unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
 335 ed in particolare ci concentreremo sul come ed in che modo essi sono
 336 supportati sia per quanto riguarda il kernel che le librerie del C (con una
 337 particolare attenzione alle \acr{glibc}).
 338
 339
 340 \subsection{Lo standard ANSI C}
 341 \label{sec:intro_ansiC}
 342
 343 Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
 344   Standard Institute}, come standard del linguaggio C ed è stato
 345 successivamente adottato dalla \textit{International Standard Organisation}
 346 come standard internazionale con la sigla ISO/IEC 9899:1990, e va anche sotto
 347 il nome di standard ISO C.
 348
 349 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
 350 sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
 351 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
 352 anche una libreria di funzioni che devono poter essere implementate su
 353 qualunque sistema operativo.
 354
 355 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
 356 di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
 357 moderni, provvede la compatibilità con questo standard, fornendo le funzioni
 358 di libreria da esso previste. Queste sono dichiarate in una serie di
 359 \textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
 360   funzioni, usati normalmente da un compilatore C. Per poter accedere alle
 361   funzioni occorre includere con la direttiva \code{\#include} questi file nei
 362   propri programmi; per ciascuna funzione che tratteremo in seguito
 363   indicheremo anche gli \textit{header file} necessari ad usarla.}  (anch'essi
 364 provvisti dalla \acr{glibc}), In tab.~\ref{tab:intro_posix_header} si sono
 365 riportati i principali \textit{header file} definiti nello standard POSIX ed
 366 ANSI C, che sono anche quelli definiti negli altri standard descritti nelle
 367 sezioni successive.
 368
 369 \begin{table}[htb]
 370   \footnotesize
 371   \centering
 372   \begin{tabular}[c]{|l|c|c|l|}
 373     \hline
 374     \multirow{2}{*}{\textbf{Header}}&
 375     \multicolumn{2}{|c|}{\textbf{Standard}}&
 376     \multirow{2}{*}{\textbf{Contenuto}} \\
 377     \cline{2-3}
 378     & ANSI C& POSIX& \\
 379     \hline
 380     \hline
 381     \file{assert.h}&$\bullet$&         & Verifica le asserzioni fatte in un
 382                                          programma.\\
 383     \file{ctype.h} &$\bullet$&         & Tipi standard.\\
 384     \file{dirent.h}&         &$\bullet$& Manipolazione delle directory.\\
 385     \file{errno.h} &         &$\bullet$& Errori di sistema.\\
 386     \file{fcntl.h} &         &$\bullet$& Controllo sulle opzioni dei file.\\
 387     \file{limits.h}&         &$\bullet$& Limiti e parametri del sistema.\\
 388     \file{malloc.h}&$\bullet$&         & Allocazione della memoria.\\
 389     \file{setjmp.h}&$\bullet$&         & Salti non locali.\\
 390     \file{signal.h}&         &$\bullet$& Gestione dei segnali.\\
 391     \file{stdarg.h}&$\bullet$&         & Gestione di funzioni a argomenti
 392                                          variabili.\\
 393     \file{stdio.h} &$\bullet$&         & I/O bufferizzato in standard ANSI C.\\
 394     \file{stdlib.h}&$\bullet$&         & Definizioni della libreria standard.\\
 395     \file{string.h}&$\bullet$&         & Manipolazione delle stringhe.\\
 396     \file{time.h}  &         &$\bullet$& Gestione dei tempi.\\
 397     \file{times.h} &$\bullet$&         & Gestione dei tempi.\\
 398     \file{unistd.h}&         &$\bullet$& Unix standard library.\\
 399     \file{utmp.h}  &         &$\bullet$& Registro connessioni utenti.\\
 400     \hline
 401   \end{tabular}
 402   \caption{Elenco dei vari header file definiti dallo standard POSIX.}
 403   \label{tab:intro_posix_header}
 404 \end{table}
 405
 406
 407 In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
 408 funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
 409 standard ANSI C. È possibile ottenere una conformità stretta allo standard
 410 (scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
 411 \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
 412 header file soltanto le funzionalità previste dallo standard ANSI C e a non
 413 usare le varie estensioni al linguaggio e al preprocessore da esso supportate.
 414
 415
 416 \subsection{I tipi di dati primitivi}
 417 \label{sec:intro_data_types}
 418
 419 Uno dei problemi di portabilità del codice più comune è quello dei tipi di
 420 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
 421 anche da una architettura ad un'altra (ad esempio passando da macchine con
 422 processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
 423 \index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
 424 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
 425
 426 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
 427 associati ad alcune variabili nei sistemi Unix, dando per scontata la
 428 dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
 429 stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
 430 sempre stato associato ad un intero a 16 bit. Storicamente questi erano
 431 definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte
 432 che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi
 433 tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
 434 una infinita serie di problemi di portabilità.
 435
 436 \begin{table}[htb]
 437   \footnotesize
 438   \centering
 439   \begin{tabular}[c]{|l|l|}
 440     \hline
 441     \textbf{Tipo} & \textbf{Contenuto} \\
 442     \hline
 443     \hline
 444     \type{caddr\_t} & Core address.\\
 445     \type{clock\_t} & Contatore del tempo di sistema.\\
 446     \type{dev\_t}   & Numero di dispositivo.\\
 447     \type{gid\_t}   & Identificatore di un gruppo.\\
 448     \type{ino\_t}   & Numero di \index{inode} \textit{inode}.\\
 449     \type{key\_t}   & Chiave per il System V IPC.\\
 450     \type{loff\_t}  & Posizione corrente in un file.\\
 451     \type{mode\_t}  & Attributi di un file.\\
 452     \type{nlink\_t} & Contatore dei link su un file.\\
 453     \type{off\_t}   & Posizione corrente in un file.\\
 454     \type{pid\_t}   & Identificatore di un processo.\\
 455     \type{rlim\_t}  & Limite sulle risorse.\\
 456     \type{sigset\_t}& Insieme di segnali.\\
 457     \type{size\_t}  & Dimensione di un oggetto.\\
 458     \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
 459     \type{ptrdiff\_t}& Differenza fra due puntatori.\\
 460     \type{time\_t}  & Numero di secondi (in tempo di calendario).\\
 461     \type{uid\_t}   & Identificatore di un utente.\\
 462     \hline
 463   \end{tabular}
 464   \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.}
 465   \label{tab:intro_primitive_types}
 466 \end{table}
 467
 468 Per questo motivo tutte le funzioni di libreria di solito non fanno
 469 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
 470 serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
 471 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file
 472 \file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
 473 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
 474 compilatore C.
 475
 476
 477
 478 \subsection{Lo standard IEEE -- POSIX}
 479 \label{sec:intro_posix}
 480
 481 Uno standard più attinente al sistema nel suo complesso (e che concerne sia il
 482 kernel che le librerie) è lo standard POSIX. Esso prende origine dallo
 483 standard ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità
 484 per le funzioni in esso definite, ed aggiungendone di nuove.
 485
 486 In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
 487 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
 488 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
 489 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
 490 che ne produsse una prima versione, nota come IEEE 1003.1-1988, mirante a
 491 standardizzare l'interfaccia con il sistema operativo.
 492
 493 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
 494 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
 495 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
 496 thread (1003.1d e 1003.1c) e vari altri.  In tab.~\ref{tab:intro_posix_std} è
 497 riportata una classificazione sommaria dei principali documenti prodotti, e di
 498 come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto
 499 spesso si usa l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio
 500 si può parlare di POSIX.4 come di POSIX.1b).
 501
 502 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
 503 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
 504 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
 505 denominazioni usate diventa particolarmente faticoso; una pagina dove si
 506 possono recuperare varie (e di norma piuttosto intricate) informazioni è
 507 \href{http://www.pasc.org/standing/sd11.html}
 508 {\textsf{http://www.pasc.org/standing/sd11.html}}.
 509
 510 \begin{table}[htb]
 511   \footnotesize
 512   \centering
 513   \begin{tabular}[c]{|l|l|l|l|}
 514     \hline
 515     \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
 516     \hline
 517     \hline
 518     POSIX.1 & 1003.1 & 9945-1& Interfacce di base                           \\
 519     POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1                         \\
 520     POSIX.2 & 1003.2 & 9945-2& Comandi                                      \\
 521     POSIX.3 & 2003   &TR13210& Metodi di test                               \\
 522     POSIX.4 & 1003.1b &  --- & Estensioni real-time                         \\
 523     POSIX.4a& 1003.1c &  --- & Thread                                       \\
 524     POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time               \\
 525     POSIX.5 & 1003.5  & 14519& Interfaccia per il linguaggio ADA            \\
 526     POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza                                 \\
 527     POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete                     \\
 528     POSIX.9 & 1003.9  &  --- & Interfaccia per il Fortran-77                \\
 529     POSIX.12& 1003.1g& 9945-1& Socket                                       \\
 530     \hline
 531   \end{tabular}
 532   \caption{Elenco dei vari standard POSIX e relative denominazioni.}
 533   \label{tab:intro_posix_std}
 534 \end{table}
 535
 536 Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
 537 definiscono comunque un'interfaccia di programmazione generica e non fanno
 538 riferimento ad una implementazione specifica (ad esempio esiste
 539 un'implementazione di POSIX.1 anche sotto Windows NT).  Lo standard principale
 540 resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui
 541 gran parte delle implementazioni fanno riferimento, e che costituisce una base
 542 per molti altri tentativi di standardizzazione, è stata rilasciata anche come
 543 standard internazionale con la sigla ISO/IEC 9945-1:1996.
 544
 545 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
 546 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
 547 funzioni di \textit{pattern matching} e per la manipolazione delle
 548 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
 549 sistema e che sono definite nello standard POSIX.2.
 550
 551 Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
 552 ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
 553 \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
 554 quanto riguarda i segnali e lo \itindex{scheduler} scheduling real-time
 555 (sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
 556 tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
 557 asincrono (sez.~\ref{sec:file_asyncronous_io}).
 558
 559
 560
 561 \subsection{Lo standard X/Open}
 562 \label{sec:intro_xopen}
 563
 564 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
 565 Unix per giungere ad un'armonizzazione delle varie implementazioni.  Per far
 566 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
 567 nome di \textit{X/Open Portability Guide} (a cui di norma si fa riferimento
 568 con l'abbreviazione XPG$n$ con $n$ che indica la versione).
 569
 570 Nel 1989 il consorzio produsse una terza versione di questa guida
 571 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
 572 contenente un'ulteriore standardizzazione dell'interfaccia di sistema di Unix,
 573 che venne presa come riferimento da vari produttori.
 574
 575 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
 576 basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive
 577 fra cui le specifiche delle API (\textit{Application Programmable Interface})
 578 per l'interfaccia grafica (X11).
 579
 580 Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
 581 Issue 4 (da cui la sigla XPG4) che aggiungeva l'interfaccia XTI (\textit{X
 582   Transport Interface}) mirante a soppiantare (senza molto successo)
 583 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
 584 rilasciata nel 1994, questa è nota con il nome di Spec 1170 (dal numero delle
 585 interfacce, header e comandi definiti).
 586
 587 Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
 588 aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
 589 specifiche sotto il nome di \textit{Single UNIX Specification}, l'ultima
 590 versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
 591   Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
 592
 593
 594 \subsection{Gli standard Unix}
 595 \label{sec:intro_opengroup}
 596
 597 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
 598 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
 599 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
 600 raccoglie produttori, utenti industriali, entità accademiche e governative.
 601
 602 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
 603 il lavoro di standardizzazione delle varie implementazioni, rilasciando
 604 periodicamente nuove specifiche e strumenti per la verifica della conformità
 605 alle stesse.
 606
 607 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
 608   Specification}, nota con la sigla SUSv2, in questa versione le interfacce
 609 specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro
 610 grafiche, per le quali sono inserite pure le interfacce usate da CDE che
 611 richiede sia X11 che Motif). La conformità a questa versione permette l'uso
 612 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard.
 613
 614
 615 \subsection{Lo ``\textsl{standard}'' BSD}
 616 \label{sec:intro_bsd}
 617
 618 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
 619 di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
 620 mondo Unix.  L'Università di Berkeley proseguì nello sviluppo della base di
 621 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
 622 versioni allora disponibili, fino ad arrivare al rilascio di una versione
 623 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 624 della AT\&T.
 625
 626 Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
 627 dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
 628 API di grande rilievo, come i link simbolici, la funzione \code{select} ed i
 629 socket.
 630
 631 Queste estensioni sono state via via aggiunte al sistema nelle varie versioni
 632 del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati
 633 commerciali come SunOS. Il kernel Linux e le \acr{glibc} provvedono tutte
 634 queste estensioni che sono state in gran parte incorporate negli standard
 635 successivi.
 636
 637
 638 \subsection{Lo standard System V}
 639 \label{sec:intro_sysv}
 640
 641 Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
 642 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
 643 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
 644 Unix System V. Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando
 645 varie versioni con aggiunte e integrazioni; nel 1989 un accordo fra vari
 646 venditori (AT\&T, Sun, HP, e altro) portò ad una versione che provvedeva
 647 un'unificazione delle interfacce comprendente Xenix e BSD, la System V release
 648 4.
 649
 650 L'interfaccia di questa ultima release è descritta in un documento dal titolo
 651 \textit{System V Interface Description}, o SVID; spesso però si fa riferimento
 652 a questo standard con il nome della sua implementazione, usando la sigla SVr4.
 653
 654 Anche questo costituisce un sovrainsieme delle interfacce definite dallo
 655 standard POSIX.  Nel 1992 venne rilasciata una seconda versione del sistema:
 656 la SVr4.2. L'anno successivo la divisione della AT\&T (già a suo tempo
 657 rinominata in Unix System Laboratories) venne acquistata dalla Novell, che poi
 658 trasferì il marchio Unix al consorzio X/Open; l'ultima versione di System V fu
 659 la SVr4.2MP rilasciata nel Dicembre 93.
 660
 661 Linux e le \acr{glibc} implementano le principali funzionalità richieste da
 662 SVID che non sono già incluse negli standard POSIX ed ANSI C, per
 663 compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
 664 includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
 665 presenti neanche in System V) sono state tralasciate.
 666
 667 Le funzionalità implementate sono principalmente il meccanismo di
 668 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
 669 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
 670 \func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
 671 matematiche.
 672
 673
 674 \subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}}
 675 \label{sec:intro_gcc_glibc_std}
 676
 677 In Linux, grazie alle \acr{glibc}, gli standard appena descritti sono
 678 ottenibili sia attraverso l'uso di opzioni del compilatore (il \cmd{gcc}) che
 679 definendo opportune costanti prima dell'inclusione dei file degli header.
 680
 681 Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
 682 si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere
 683 utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per
 684 il C.
 685
 686 Per attivare le varie opzioni è possibile definire le macro di preprocessore,
 687 che controllano le funzionalità che le \acr{glibc} possono mettere a
 688 disposizione: questo può essere fatto attraverso l'opzione \cmd{-D} del
 689 compilatore, ma è buona norma inserire gli opportuni \code{\#define} nei
 690 propri header file.
 691
 692 Le macro disponibili per i vari standard sono le seguenti:
 693 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
 694 \item[\macro{\_POSIX\_SOURCE}] definendo questa macro si rendono disponibili
 695   tutte le funzionalità dello standard POSIX.1 (la versione IEEE Standard
 696   1003.1) insieme a tutte le funzionalità dello standard ISO C. Se viene anche
 697   definita con un intero positivo la macro \macro{\_POSIX\_C\_SOURCE} lo stato
 698   di questa non viene preso in considerazione.
 699 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
 700   positivo si controlla quale livello delle funzionalità specificate da POSIX
 701   viene messa a disposizione; più alto è il valore maggiori sono le
 702   funzionalità. Se è uguale a ``\texttt{1}'' vengono attivate le funzionalità
 703   specificate nella edizione del 1990 (IEEE Standard 1003.1-1990), valori
 704   maggiori o uguali a ``\texttt{2}'' attivano le funzionalità POSIX.2
 705   specificate nell'edizione del 1992 (IEEE Standard 1003.2-1992). Un valore
 706   maggiore o uguale a ``\texttt{199309L}'' attiva le funzionalità POSIX.1b
 707   specificate nell'edizione del 1993 (IEEE Standard 1003.1b-1993).  Un valore
 708   maggiore o uguale a ``\texttt{199506L}'' attiva le funzionalità POSIX.1
 709   specificate nell'edizione del 1996 (ISO/IEC 9945-1: 1996). Valori superiori
 710   abiliteranno ulteriori estensioni.
 711 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si attivano le
 712   funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
 713   ISO C, POSIX.1 e POSIX.2. Alcune delle funzionalità previste da BSD sono
 714   però in conflitto con le corrispondenti definite nello standard POSIX.1, in
 715   questo caso le definizioni previste da BSD4.3 hanno la precedenza rispetto a
 716   POSIX.  A causa della natura dei conflitti con POSIX per ottenere una piena
 717   compatibilità con BSD4.3 è necessario anche usare una libreria di
 718   compatibilità, dato che alcune funzioni sono definite in modo diverso. In
 719   questo caso occorre pertanto anche usare l'opzione \cmd{-lbsd-compat} con il
 720   compilatore per indicargli di utilizzare le versioni nella libreria di
 721   compatibilità prima di quelle normali.
 722 \item[\macro{\_SVID\_SOURCE}] definendo questa macro si attivano le
 723   funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
 724   standard ISO C, POSIX.1, POSIX.2, e X/Open.
 725 \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le
 726   funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste
 727   sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti
 728   sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono
 729   automaticamente definite. Sono incluse anche ulteriori funzionalità
 730   disponibili in BSD e SVID. Se il valore della macro è posto a
 731   ``\texttt{500}'' questo include anche le nuove definizioni introdotte con la
 732   \textit{Single UNIX Specification, version 2}, cioè Unix98.
 733 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le
 734   ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio
 735   \textit{X/Open Unix}.
 736 \item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si attivano le
 737   funzionalità previste per la revisione delle librerie standard del C
 738   denominato ISO C99. Dato che lo standard non è ancora adottato in maniera
 739   ampia queste non sono abilitate automaticamente, ma le \acr{glibc} hanno già
 740   un'implementazione completa che può essere attivata definendo questa macro.
 741 \item[\macro{\_LARGEFILE\_SOURCE}] definendo questa macro si attivano le
 742   funzionalità per il supporto dei file di grandi dimensioni (il \textit{Large
 743     File Support} o LFS) con indici e dimensioni a 64 bit.
 744 \item[\macro{\_GNU\_SOURCE}] definendo questa macro si attivano tutte le
 745   funzionalità disponibili: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID,
 746   X/Open, LFS più le estensioni specifiche GNU. Nel caso in cui BSD e POSIX
 747   confliggano viene data la precedenza a POSIX.
 748 \end{basedescript}
 749
 750 In particolare è da sottolineare che le \acr{glibc} supportano alcune
 751 estensioni specifiche GNU, che non sono comprese in nessuno degli standard
 752 citati. Per poterle utilizzare esse devono essere attivate esplicitamente
 753 definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header
 754 file.
 755
 756
 757 %% \subsection{Gli standard di GNU/Linux}
 758 %% \label{sec:intro_linux_std}
 759
 760 % TODO Da fare (o cassare, a seconda del tempo e della voglia).
 761
 762
 763
 764 % LocalWords:  like kernel multitasking scheduler preemptive sez swap is cap
 765 % LocalWords:  everything bootstrap init shell Windows Foundation system call
 766 % LocalWords:  fig libc uClib glibc embedded Library POSIX username PAM Methods
 767 % LocalWords:  Pluggable Autentication group supplementary Name Service Switch
 768 % LocalWords:  LDAP identifier uid gid superuser root if BSD SVr dall' American
 769 % LocalWords:  National Institute International Organisation IEC header tab gcc
 770 % LocalWords:  assert ctype dirent errno fcntl limits malloc setjmp signal utmp
 771 % LocalWords:  stdarg stdio stdlib string times unistd library int short caddr
 772 % LocalWords:  address clock dev ino inode key IPC loff nlink off pid rlim size
 773 % LocalWords:  sigset ssize ptrdiff sys nell'header IEEE Richard Portable of TR
 774 % LocalWords:  Operating Interface dell'IEEE Electrical and Electronics thread
 775 % LocalWords:  Engeneers Socket NT matching regular expression scheduling l'I
 776 % LocalWords:  XPG Portability Issue Application Programmable XTI Transport AT
 777 % LocalWords:  socket Spec Novell Specification SUSv CDE Motif Berkley select
 778 % LocalWords:  SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
 779 % LocalWords:  drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
 780 % LocalWords:  LARGEFILE Support LFS dell'
 781
 782
 783 %%% Local Variables:
 784 %%% mode: latex
 785 %%% TeX-master: "gapil"
 786 %%% End: