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{prehemptive~multitasking} \textit{prehemptive
  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 \textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a
  77 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   \caption{Schema di massima della struttura di interazione fra processi,
 179     kernel e dispositivi in Linux.}
 180   \label{fig:intro_sys_struct}
 181 \end{figure}
 182
 183 Normalmente ciascuna di queste chiamate al sistema viene rimappata in
 184 opportune funzioni con lo stesso nome definite dentro la Libreria Standard del
 185 C, che, oltre alle interfacce alle system call, contiene anche tutta la serie
 186 delle ulteriori funzioni definite dai vari standard, che sono comunemente
 187 usate nella programmazione.
 188
 189 Questo è importante da capire perché programmare in Linux significa anzitutto
 190 essere in grado di usare le varie interfacce contenute nella Libreria Standard
 191 del C, in quanto né il kernel, né il linguaggio C implementano direttamente
 192 operazioni comuni come l'allocazione dinamica della memoria, l'input/output
 193 bufferizzato o la manipolazione delle stringhe, presenti in qualunque
 194 programma.
 195
 196 Quanto appena illustrato mette in evidenza il fatto che nella stragrande
 197 maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie
 198   Standard del C, come le \textit{libc5} o le \textit{uClib}, che non derivano
 199   dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
 200   completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
 201   essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
 202   embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
 203   togliere le parti non necessarie), e pertanto costituiscono un valido
 204   rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
 205   richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
 206 GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
 207 sistema (senza la quale niente funzionerebbe) è la GNU Standard C Library (in
 208 breve \acr{glibc}), ovvero la libreria realizzata dalla Free Software
 209 Foundation nella quale sono state implementate tutte le funzioni essenziali
 210 definite negli standard POSIX e ANSI C, utilizzabili da qualunque programma.
 211
 212 Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
 213 \textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
 214 \cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al sistema del
 215 kernel; è importante avere presente questa distinzione, fondamentale dal punto
 216 di vista dell'implementazione, anche se poi, nella realizzazione di normali
 217 programmi, non si hanno differenze pratiche fra l'uso di una funzione di
 218 libreria e quello di una chiamata al sistema.
 219
 220
 221 \subsection{Un sistema multiutente}
 222 \label{sec:intro_multiuser}
 223
 224 Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
 225 multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
 226 questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
 227 sistemi operativi monoutente, e che occorre tenere presente.
 228
 229 Il concetto base è quello di utente (\textit{user}) del sistema, le cui
 230 capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
 231 Sono così previsti una serie di meccanismi per identificare i singoli utenti
 232 ed una serie di permessi e protezioni per impedire che utenti diversi possano
 233 danneggiarsi a vicenda o danneggiare il sistema.
 234
 235 Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
 236 viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
 237 (descritta in dettaglio in sez.~\ref{sec:sess_login}).  Questa procedura si
 238 incarica di verificare l'identità dell'utente, in genere attraverso la
 239 richiesta di una parola d'ordine (la \textit{password}), anche se sono
 240 possibili meccanismi diversi.\footnote{Ad esempio usando la libreria PAM
 241   (\textit{Pluggable Autentication Methods}) è possibile astrarre
 242   completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso
 243   delle password con meccanismi di identificazione biometrica.}
 244
 245 Eseguita la procedura di riconoscimento in genere il sistema manda in
 246 esecuzione un programma di interfaccia (che può essere la \textit{shell} su
 247 terminale o un'interfaccia grafica) che mette a disposizione dell'utente un
 248 meccanismo con cui questo può impartire comandi o eseguire altri programmi.
 249
 250 Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
 251 \textit{default group}), ma può essere associato ad altri gruppi (i
 252 \textit{supplementary group}), questo permette di gestire i permessi di
 253 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
 254 definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
 255
 256 L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
 257 un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e
 258 \file{/etc/groups}.\footnote{in realtà negli sistemi più moderni, come vedremo
 259   in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
 260   mantenute, con l'uso del \textit{Name Service Switch}, su varie tipologie di
 261   supporti, compresi server centralizzati come LDAP.}
 262 \itindex{Name~Service~Switch} Questi numeri sono l'\textit{user identifier},
 263 detto in breve \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il
 264 \textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato
 265 dall'acronimo \acr{gid}, e sono quelli che vengono usati dal kernel per
 266 identificare l'utente.
 267
 268 In questo modo il sistema è in grado di tenere traccia dell'utente a cui
 269 appartiene ciascun processo ed impedire ad altri utenti di interferire con
 270 quest'ultimo.  Inoltre con questo sistema viene anche garantita una forma base
 271 di sicurezza interna in quanto anche l'accesso ai file (vedi
 272 sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
 273 identificazione.
 274
 275 Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
 276 \textit{superuser}, il cui username è di norma \textit{root}, ed il cui
 277 \acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
 278 essere in grado di fare qualunque operazione; per l'utente \textit{root}
 279 infatti i meccanismi di controllo descritti in precedenza sono
 280 disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
 281   del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
 282
 283
 284 \section{Gli standard}
 285 \label{sec:intro_standard}
 286
 287 In questa sezione faremo una breve panoramica relativa ai vari standard che
 288 nel tempo sono stati formalizzati da enti, associazioni, consorzi e
 289 organizzazioni varie al riguardo del sistema o alle caratteristiche che si
 290 sono stabilite come standard di fatto in quanto facenti parte di alcune
 291 implementazioni molto diffuse come BSD o SVr4.
 292
 293 Ovviamente prenderemo in considerazione solo gli standard riguardanti
 294 interfacce di programmazione e le altre caratteristiche di un sistema
 295 unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
 296 ed in particolare ci concentreremo sul come ed in che modo essi sono
 297 supportati sia per quanto riguarda il kernel che le librerie del C (con una
 298 particolare attenzione alle \acr{glibc}).
 299
 300
 301 \subsection{Lo standard ANSI C}
 302 \label{sec:intro_ansiC}
 303
 304 Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
 305   Standard Institute}, come standard del linguaggio C ed è stato
 306 successivamente adottato dalla \textit{International Standard Organisation}
 307 come standard internazionale con la sigla ISO/IEC 9899:1990, e va anche sotto
 308 il nome di standard ISO C.
 309
 310 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
 311 sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
 312 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
 313 anche una libreria di funzioni che devono poter essere implementate su
 314 qualunque sistema operativo.
 315
 316 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
 317 di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
 318 moderni, provvede la compatibilità con questo standard, fornendo le funzioni
 319 di libreria da esso previste. Queste sono dichiarate in una serie di
 320 \textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
 321   funzioni, usati normalmente da un compilatore C. Per poter accedere alle
 322   funzioni occorre includere con la direttiva \code{\#include} questi file nei
 323   propri programmi; per ciascuna funzione che tratteremo in seguito
 324   indicheremo anche gli \textit{header file} necessari ad usarla.}  (anch'essi
 325 provvisti dalla \acr{glibc}), In tab.~\ref{tab:intro_posix_header} si sono
 326 riportati i principali \textit{header file} definiti nello standard POSIX ed
 327 ANSI C, che sono anche quelli definiti negli altri standard descritti nelle
 328 sezioni successive.
 329
 330 \begin{table}[htb]
 331   \footnotesize
 332   \centering
 333   \begin{tabular}[c]{|l|c|c|l|}
 334     \hline
 335     \multirow{2}{*}{\textbf{Header}}&
 336     \multicolumn{2}{|c|}{\textbf{Standard}}&
 337     \multirow{2}{*}{\textbf{Contenuto}} \\
 338     \cline{2-3}
 339     & ANSI C& POSIX& \\
 340     \hline
 341     \hline
 342     \file{assert.h}&$\bullet$&         & Verifica le asserzioni fatte in un
 343                                          programma.\\
 344     \file{ctype.h} &$\bullet$&         & Tipi standard.\\
 345     \file{dirent.h}&         &$\bullet$& Manipolazione delle directory.\\
 346     \file{errno.h} &         &$\bullet$& Errori di sistema.\\
 347     \file{fcntl.h} &         &$\bullet$& Controllo sulle opzioni dei file.\\
 348     \file{limits.h}&         &$\bullet$& Limiti e parametri del sistema.\\
 349     \file{malloc.h}&$\bullet$&         & Allocazione della memoria.\\
 350     \file{setjmp.h}&$\bullet$&         & Salti non locali.\\
 351     \file{signal.h}&         &$\bullet$& Gestione dei segnali.\\
 352     \file{stdarg.h}&$\bullet$&         & .\\
 353     \file{stdio.h} &$\bullet$&         & I/O bufferizzato in standard ANSI C.\\
 354     \file{stdlib.h}&$\bullet$&         & definizioni della libreria standard.\\
 355     \file{string.h}&$\bullet$&         & Manipolazione delle stringhe.\\
 356     \file{time.h}  &         &$\bullet$& Gestione dei tempi.\\
 357     \file{times.h} &$\bullet$&         & Gestione dei tempi.\\
 358     \file{unistd.h}&         &$\bullet$& Unix standard library.\\
 359     \file{utmp.h}  &         &$\bullet$& Registro connessioni utenti.\\
 360     \hline
 361   \end{tabular}
 362   \caption{Elenco dei vari header file definiti dallo standard POSIX.}
 363   \label{tab:intro_posix_header}
 364 \end{table}
 365
 366
 367 In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
 368 funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
 369 standard ANSI C. È possibile ottenere una conformità stretta allo standard
 370 (scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
 371 \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
 372 header file soltanto le funzionalità previste dallo standard ANSI C e a non
 373 usare le varie estensioni al linguaggio e al preprocessore da esso supportate.
 374
 375
 376 \subsection{I tipi di dati primitivi}
 377 \label{sec:intro_data_types}
 378
 379 Uno dei problemi di portabilità del codice più comune è quello dei tipi di
 380 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
 381 anche da una architettura ad un'altra (ad esempio passando da macchine con
 382 processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
 383 \textit{tipi elementari}\index{tipo!elementare} del linguaggio C (come
 384 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
 385
 386 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
 387 associati ad alcune variabili nei sistemi Unix, dando per scontata la
 388 dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
 389 stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
 390 sempre stato associato ad un intero a 16 bit. Storicamente questi erano
 391 definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte
 392 che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi
 393 tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
 394 una infinita serie di problemi di portabilità.
 395
 396 \begin{table}[htb]
 397   \footnotesize
 398   \centering
 399   \begin{tabular}[c]{|l|l|}
 400     \hline
 401     \textbf{Tipo} & \textbf{Contenuto} \\
 402     \hline
 403     \hline
 404     \type{caddr\_t} & Core address.\\
 405     \type{clock\_t} & Contatore del tempo di sistema.\\
 406     \type{dev\_t}   & Numero di dispositivo.\\
 407     \type{gid\_t}   & Identificatore di un gruppo.\\
 408     \type{ino\_t}   & Numero di \textit{inode}\index{inode}.\\
 409     \type{key\_t}   & Chiave per il System V IPC.\\
 410     \type{loff\_t}  & Posizione corrente in un file.\\
 411     \type{mode\_t}  & Attributi di un file.\\
 412     \type{nlink\_t} & Contatore dei link su un file.\\
 413     \type{off\_t}   & Posizione corrente in un file.\\
 414     \type{pid\_t}   & Identificatore di un processo.\\
 415     \type{rlim\_t}  & Limite sulle risorse.\\
 416     \type{sigset\_t}& Insieme di segnali.\\
 417     \type{size\_t}  & Dimensione di un oggetto.\\
 418     \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
 419     \type{ptrdiff\_t}& Differenza fra due puntatori.\\
 420     \type{time\_t}  & Numero di secondi (in tempo di calendario).\\
 421     \type{uid\_t}   & Identificatore di un utente.\\
 422     \hline
 423   \end{tabular}
 424   \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.}
 425   \label{tab:intro_primitive_types}
 426 \end{table}
 427
 428 Per questo motivo tutte le funzioni di libreria di solito non fanno
 429 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
 430 serie di \textsl{tipi primitivi}\index{tipo!primitivo} del sistema, riportati
 431 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file
 432 \file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
 433 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
 434 compilatore C.
 435
 436
 437
 438 \subsection{Lo standard IEEE -- POSIX}
 439 \label{sec:intro_posix}
 440
 441 Uno standard più attinente al sistema nel suo complesso (e che concerne sia il
 442 kernel che le librerie) è lo standard POSIX. Esso prende origine dallo
 443 standard ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità
 444 per le funzioni in esso definite, ed aggiungendone di nuove.
 445
 446 In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
 447 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
 448 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
 449 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
 450 che ne produsse una prima versione, nota come IEEE 1003.1-1988, mirante a
 451 standardizzare l'interfaccia con il sistema operativo.
 452
 453 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
 454 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
 455 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
 456 thread (1003.1d e 1003.1c) e vari altri.  In tab.~\ref{tab:intro_posix_std} è
 457 riportata una classificazione sommaria dei principali documenti prodotti, e di
 458 come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto
 459 spesso si usa l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio
 460 si può parlare di POSIX.4 come di POSIX.1b).
 461
 462 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
 463 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
 464 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
 465 denominazioni usate diventa particolarmente faticoso; una pagina dove si
 466 possono recuperare varie (e di norma piuttosto intricate) informazioni è
 467 \href{http://www.pasc.org/standing/sd11.html}
 468 {\textsf{http://www.pasc.org/standing/sd11.html}}.
 469
 470 \begin{table}[htb]
 471   \footnotesize
 472   \centering
 473   \begin{tabular}[c]{|l|l|l|l|}
 474     \hline
 475     \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
 476     \hline
 477     \hline
 478     POSIX.1 & 1003.1 & 9945-1& Interfacce di base                           \\
 479     POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1                         \\
 480     POSIX.2 & 1003.2 & 9945-2& Comandi                                      \\
 481     POSIX.3 & 2003   &TR13210& Metodi di test                               \\
 482     POSIX.4 & 1003.1b &  --- & Estensioni real-time                         \\
 483     POSIX.4a& 1003.1c &  --- & Thread                                       \\
 484     POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time               \\
 485     POSIX.5 & 1003.5  & 14519& Interfaccia per il linguaggio ADA            \\
 486     POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza                                 \\
 487     POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete                     \\
 488     POSIX.9 & 1003.9  &  --- & Interfaccia per il Fortran-77                \\
 489     POSIX.12& 1003.1g& 9945-1& Socket                                       \\
 490     \hline
 491   \end{tabular}
 492   \caption{Elenco dei vari standard POSIX e relative denominazioni.}
 493   \label{tab:intro_posix_std}
 494 \end{table}
 495
 496 Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
 497 definiscono comunque un'interfaccia di programmazione generica e non fanno
 498 riferimento ad una implementazione specifica (ad esempio esiste
 499 un'implementazione di POSIX.1 anche sotto Windows NT).  Lo standard principale
 500 resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui
 501 gran parte delle implementazioni fanno riferimento, e che costituisce una base
 502 per molti altri tentativi di standardizzazione, è stata rilasciata anche come
 503 standard internazionale con la sigla ISO/IEC 9945-1:1996.
 504
 505 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
 506 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
 507 funzioni di \textit{pattern matching} e per la manipolazione delle
 508 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
 509 sistema e che sono definite nello standard POSIX.2.
 510
 511 Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
 512 ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
 513 \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
 514 quanto riguarda i segnali e lo \itindex{scheduler} scheduling real-time
 515 (sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
 516 tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
 517 asincrono (sez.~\ref{sec:file_asyncronous_io}).
 518
 519
 520
 521 \subsection{Lo standard X/Open}
 522 \label{sec:intro_xopen}
 523
 524 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
 525 Unix per giungere ad un'armonizzazione delle varie implementazioni.  Per far
 526 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
 527 nome di \textit{X/Open Portability Guide} (a cui di norma si fa riferimento
 528 con l'abbreviazione XPG$n$ con $n$ che indica la versione).
 529
 530 Nel 1989 il consorzio produsse una terza versione di questa guida
 531 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
 532 contenente un'ulteriore standardizzazione dell'interfaccia di sistema di Unix,
 533 che venne presa come riferimento da vari produttori.
 534
 535 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
 536 basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive
 537 fra cui le specifiche delle API (\textit{Application Programmable Interface})
 538 per l'interfaccia grafica (X11).
 539
 540 Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
 541 Issue 4 (da cui la sigla XPG4) che aggiungeva l'interfaccia XTI (\textit{X
 542   Transport Interface}) mirante a soppiantare (senza molto successo)
 543 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
 544 rilasciata nel 1994, questa è nota con il nome di Spec 1170 (dal numero delle
 545 interfacce, header e comandi definiti).
 546
 547 Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
 548 aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
 549 specifiche sotto il nome di \textit{Single UNIX Specification}, l'ultima
 550 versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
 551   Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
 552
 553
 554 \subsection{Gli standard Unix}
 555 \label{sec:intro_opengroup}
 556
 557 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
 558 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
 559 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
 560 raccoglie produttori, utenti industriali, entità accademiche e governative.
 561
 562 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
 563 il lavoro di standardizzazione delle varie implementazioni, rilasciando
 564 periodicamente nuove specifiche e strumenti per la verifica della conformità
 565 alle stesse.
 566
 567 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
 568   Specification}, nota con la sigla SUSv2, in questa versione le interfacce
 569 specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro
 570 grafiche, per le quali sono inserite pure le interfacce usate da CDE che
 571 richiede sia X11 che Motif). La conformità a questa versione permette l'uso
 572 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard.
 573
 574
 575 \subsection{Lo ``\textsl{standard}'' BSD}
 576 \label{sec:intro_bsd}
 577
 578 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
 579 di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
 580 mondo Unix.  L'Università di Berkley proseguì nello sviluppo della base di
 581 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
 582 versioni allora disponibili, fino ad arrivare al rilascio di una versione
 583 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 584 della AT\&T.
 585
 586 Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
 587 dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
 588 API di grande rilievo, come i link simbolici, la funzione \code{select} ed i
 589 socket.
 590
 591 Queste estensioni sono state via via aggiunte al sistema nelle varie versioni
 592 del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati
 593 commerciali come SunOS. Il kernel Linux e le \acr{glibc} provvedono tutte
 594 queste estensioni che sono state in gran parte incorporate negli standard
 595 successivi.
 596
 597
 598 \subsection{Lo standard System V}
 599 \label{sec:intro_sysv}
 600
 601 Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
 602 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
 603 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
 604 Unix System V. Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando
 605 varie versioni con aggiunte e integrazioni; nel 1989 un accordo fra vari
 606 venditori (AT\&T, Sun, HP, e altro) portò ad una versione che provvedeva
 607 un'unificazione delle interfacce comprendente Xenix e BSD, la System V release
 608 4.
 609
 610 L'interfaccia di questa ultima release è descritta in un documento dal titolo
 611 \textit{System V Interface Description}, o SVID; spesso però si fa riferimento
 612 a questo standard con il nome della sua implementazione, usando la sigla SVr4.
 613
 614 Anche questo costituisce un sovrainsieme delle interfacce definite dallo
 615 standard POSIX.  Nel 1992 venne rilasciata una seconda versione del sistema:
 616 la SVr4.2. L'anno successivo la divisione della AT\&T (già a suo tempo
 617 rinominata in Unix System Laboratories) venne acquistata dalla Novell, che poi
 618 trasferì il marchio Unix al consorzio X/Open; l'ultima versione di System V fu
 619 la SVr4.2MP rilasciata nel Dicembre 93.
 620
 621 Linux e le \acr{glibc} implementano le principali funzionalità richieste da
 622 SVID che non sono già incluse negli standard POSIX ed ANSI C, per
 623 compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
 624 includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
 625 presenti neanche in System V) sono state tralasciate.
 626
 627 Le funzionalità implementate sono principalmente il meccanismo di
 628 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
 629 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
 630 \func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
 631 matematiche.
 632
 633
 634 \subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}}
 635 \label{sec:intro_gcc_glibc_std}
 636
 637 In Linux, grazie alle \acr{glibc}, gli standard appena descritti sono
 638 ottenibili sia attraverso l'uso di opzioni del compilatore (il \cmd{gcc}) che
 639 definendo opportune costanti prima dell'inclusione dei file degli header.
 640
 641 Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
 642 si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere
 643 utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per
 644 il C.
 645
 646 Per attivare le varie opzioni è possibile definire le macro di preprocessore,
 647 che controllano le funzionalità che le \acr{glibc} possono mettere a
 648 disposizione: questo può essere fatto attraverso l'opzione \cmd{-D} del
 649 compilatore, ma è buona norma inserire gli opportuni \code{\#define} nei
 650 propri header file.
 651
 652 Le macro disponibili per i vari standard sono le seguenti:
 653 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
 654 \item[\macro{\_POSIX\_SOURCE}] definendo questa macro si rendono disponibili
 655   tutte le funzionalità dello standard POSIX.1 (la versione IEEE Standard
 656   1003.1) insieme a tutte le funzionalità dello standard ISO C. Se viene anche
 657   definita con un intero positivo la macro \macro{\_POSIX\_C\_SOURCE} lo stato
 658   di questa non viene preso in considerazione.
 659 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
 660   positivo si controlla quale livello delle funzionalità specificate da POSIX
 661   viene messa a disposizione; più alto è il valore maggiori sono le
 662   funzionalità. Se è uguale a ``\texttt{1}'' vengono attivate le funzionalità
 663   specificate nella edizione del 1990 (IEEE Standard 1003.1-1990), valori
 664   maggiori o uguali a ``\texttt{2}'' attivano le funzionalità POSIX.2
 665   specificate nell'edizione del 1992 (IEEE Standard 1003.2-1992). Un valore
 666   maggiore o uguale a ``\texttt{199309L}'' attiva le funzionalità POSIX.1b
 667   specificate nell'edizione del 1993 (IEEE Standard 1003.1b-1993).  Un valore
 668   maggiore o uguale a ``\texttt{199506L}'' attiva le funzionalità POSIX.1
 669   specificate nell'edizione del 1996 (ISO/IEC 9945-1: 1996). Valori superiori
 670   abiliteranno ulteriori estensioni.
 671 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si attivano le
 672   funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
 673   ISO C, POSIX.1 e POSIX.2. Alcune delle funzionalità previste da BSD sono
 674   però in conflitto con le corrispondenti definite nello standard POSIX.1, in
 675   questo caso le definizioni previste da BSD4.3 hanno la precedenza rispetto a
 676   POSIX.  A causa della natura dei conflitti con POSIX per ottenere una piena
 677   compatibilità con BSD4.3 è necessario anche usare una libreria di
 678   compatibilità, dato che alcune funzioni sono definite in modo diverso. In
 679   questo caso occorre pertanto anche usare l'opzione \cmd{-lbsd-compat} con il
 680   compilatore per indicargli di utilizzare le versioni nella libreria di
 681   compatibilità prima di quelle normali.
 682 \item[\macro{\_SVID\_SOURCE}] definendo questa macro si attivano le
 683   funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
 684   standard ISO C, POSIX.1, POSIX.2, e X/Open.
 685 \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le
 686   funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste
 687   sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti
 688   sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono
 689   automaticamente definite. Sono incluse anche ulteriori funzionalità
 690   disponibili in BSD e SVID. Se il valore della macro è posto a
 691   ``\texttt{500}'' questo include anche le nuove definizioni introdotte con la
 692   \textit{Single UNIX Specification, version 2}, cioè Unix98.
 693 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le
 694   ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio
 695   \textit{X/Open Unix}.
 696 \item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si attivano le
 697   funzionalità previste per la revisione delle librerie standard del C
 698   denominato ISO C99. Dato che lo standard non è ancora adottato in maniera
 699   ampia queste non sono abilitate automaticamente, ma le \acr{glibc} hanno già
 700   un'implementazione completa che può essere attivata definendo questa macro.
 701 \item[\macro{\_LARGEFILE\_SOURCE}] definendo questa macro si attivano le
 702   funzionalità per il supporto dei file di grandi dimensioni (il \textit{Large
 703     File Support} o LFS) con indici e dimensioni a 64 bit.
 704 \item[\macro{\_GNU\_SOURCE}] definendo questa macro si attivano tutte le
 705   funzionalità disponibili: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID,
 706   X/Open, LFS più le estensioni specifiche GNU. Nel caso in cui BSD e POSIX
 707   confliggano viene data la precedenza a POSIX.
 708 \end{basedescript}
 709
 710 In particolare è da sottolineare che le \acr{glibc} supportano alcune
 711 estensioni specifiche GNU, che non sono comprese in nessuno degli standard
 712 citati. Per poterle utilizzare esse devono essere attivate esplicitamente
 713 definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header
 714 file.
 715
 716
 717 %% \subsection{Gli standard di GNU/Linux}
 718 %% \label{sec:intro_linux_std}
 719
 720 % TODO Da fare (o cassare, a seconda del tempo e della voglia).
 721
 722
 723
 724 % LocalWords:  like kernel multitasking scheduler prehemptive sez swap is cap
 725 % LocalWords:  everything bootstrap init shell Windows Foundation system call
 726 % LocalWords:  fig libc uClib glibc embedded Library POSIX username PAM Methods
 727 % LocalWords:  Pluggable Autentication group supplementary Name Service Switch
 728 % LocalWords:  LDAP identifier uid gid superuser root if BSD SVr dall' American
 729 % LocalWords:  National Institute International Organisation IEC header tab gcc
 730 % LocalWords:  assert ctype dirent errno fcntl limits malloc setjmp signal utmp
 731 % LocalWords:  stdarg stdio stdlib string times unistd library int short caddr
 732 % LocalWords:  address clock dev ino inode key IPC loff nlink off pid rlim size
 733 % LocalWords:  sigset ssize ptrdiff sys nell'header IEEE Richard Portable of TR
 734 % LocalWords:  Operating Interface dell'IEEE Electrical and Electronics thread
 735 % LocalWords:  Engeneers Socket NT matching regular expression scheduling l'I
 736 % LocalWords:  XPG Portability Issue Application Programmable XTI Transport AT
 737 % LocalWords:  socket Spec Novell Specification SUSv CDE Motif Berkley select
 738 % LocalWords:  SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
 739 % LocalWords:  drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
 740 % LocalWords:  LARGEFILE Support LFS dell'
 741
 742
 743 %%% Local Variables:
 744 %%% mode: latex
 745 %%% TeX-master: "gapil"
 746 %%% End: