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 \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   \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 \conffile{/etc/passwd} e
 258 \conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
 259   vedremo in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
 260   mantenute, con l'uso del \itindex{Name~Service~Switch} \textit{Name Service
 261     Switch}, su varie tipologie di supporti, compresi server centralizzati
 262   come LDAP.}  Questi numeri sono l'\textit{user identifier}, detto in breve
 263 \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group
 264   identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
 265 \acr{gid}, e sono quelli che vengono usati dal kernel per identificare
 266 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$&         & Gestione di funzioni a argomenti
 353                                          variabili.\\
 354     \file{stdio.h} &$\bullet$&         & I/O bufferizzato in standard ANSI C.\\
 355     \file{stdlib.h}&$\bullet$&         & Definizioni della libreria standard.\\
 356     \file{string.h}&$\bullet$&         & Manipolazione delle stringhe.\\
 357     \file{time.h}  &         &$\bullet$& Gestione dei tempi.\\
 358     \file{times.h} &$\bullet$&         & Gestione dei tempi.\\
 359     \file{unistd.h}&         &$\bullet$& Unix standard library.\\
 360     \file{utmp.h}  &         &$\bullet$& Registro connessioni utenti.\\
 361     \hline
 362   \end{tabular}
 363   \caption{Elenco dei vari header file definiti dallo standard POSIX.}
 364   \label{tab:intro_posix_header}
 365 \end{table}
 366
 367
 368 In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
 369 funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
 370 standard ANSI C. È possibile ottenere una conformità stretta allo standard
 371 (scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
 372 \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
 373 header file soltanto le funzionalità previste dallo standard ANSI C e a non
 374 usare le varie estensioni al linguaggio e al preprocessore da esso supportate.
 375
 376
 377 \subsection{I tipi di dati primitivi}
 378 \label{sec:intro_data_types}
 379
 380 Uno dei problemi di portabilità del codice più comune è quello dei tipi di
 381 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
 382 anche da una architettura ad un'altra (ad esempio passando da macchine con
 383 processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
 384 \index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
 385 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
 386
 387 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
 388 associati ad alcune variabili nei sistemi Unix, dando per scontata la
 389 dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
 390 stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
 391 sempre stato associato ad un intero a 16 bit. Storicamente questi erano
 392 definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte
 393 che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi
 394 tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
 395 una infinita serie di problemi di portabilità.
 396
 397 \begin{table}[htb]
 398   \footnotesize
 399   \centering
 400   \begin{tabular}[c]{|l|l|}
 401     \hline
 402     \textbf{Tipo} & \textbf{Contenuto} \\
 403     \hline
 404     \hline
 405     \type{caddr\_t} & Core address.\\
 406     \type{clock\_t} & Contatore del tempo di sistema.\\
 407     \type{dev\_t}   & Numero di dispositivo.\\
 408     \type{gid\_t}   & Identificatore di un gruppo.\\
 409     \type{ino\_t}   & Numero di \index{inode} \textit{inode}.\\
 410     \type{key\_t}   & Chiave per il System V IPC.\\
 411     \type{loff\_t}  & Posizione corrente in un file.\\
 412     \type{mode\_t}  & Attributi di un file.\\
 413     \type{nlink\_t} & Contatore dei link su un file.\\
 414     \type{off\_t}   & Posizione corrente in un file.\\
 415     \type{pid\_t}   & Identificatore di un processo.\\
 416     \type{rlim\_t}  & Limite sulle risorse.\\
 417     \type{sigset\_t}& Insieme di segnali.\\
 418     \type{size\_t}  & Dimensione di un oggetto.\\
 419     \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
 420     \type{ptrdiff\_t}& Differenza fra due puntatori.\\
 421     \type{time\_t}  & Numero di secondi (in tempo di calendario).\\
 422     \type{uid\_t}   & Identificatore di un utente.\\
 423     \hline
 424   \end{tabular}
 425   \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.}
 426   \label{tab:intro_primitive_types}
 427 \end{table}
 428
 429 Per questo motivo tutte le funzioni di libreria di solito non fanno
 430 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
 431 serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
 432 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file
 433 \file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
 434 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
 435 compilatore C.
 436
 437
 438
 439 \subsection{Lo standard IEEE -- POSIX}
 440 \label{sec:intro_posix}
 441
 442 Uno standard più attinente al sistema nel suo complesso (e che concerne sia il
 443 kernel che le librerie) è lo standard POSIX. Esso prende origine dallo
 444 standard ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità
 445 per le funzioni in esso definite, ed aggiungendone di nuove.
 446
 447 In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
 448 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
 449 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
 450 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
 451 che ne produsse una prima versione, nota come IEEE 1003.1-1988, mirante a
 452 standardizzare l'interfaccia con il sistema operativo.
 453
 454 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
 455 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
 456 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
 457 thread (1003.1d e 1003.1c) e vari altri.  In tab.~\ref{tab:intro_posix_std} è
 458 riportata una classificazione sommaria dei principali documenti prodotti, e di
 459 come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto
 460 spesso si usa l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio
 461 si può parlare di POSIX.4 come di POSIX.1b).
 462
 463 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
 464 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
 465 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
 466 denominazioni usate diventa particolarmente faticoso; una pagina dove si
 467 possono recuperare varie (e di norma piuttosto intricate) informazioni è
 468 \href{http://www.pasc.org/standing/sd11.html}
 469 {\textsf{http://www.pasc.org/standing/sd11.html}}.
 470
 471 \begin{table}[htb]
 472   \footnotesize
 473   \centering
 474   \begin{tabular}[c]{|l|l|l|l|}
 475     \hline
 476     \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
 477     \hline
 478     \hline
 479     POSIX.1 & 1003.1 & 9945-1& Interfacce di base                           \\
 480     POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1                         \\
 481     POSIX.2 & 1003.2 & 9945-2& Comandi                                      \\
 482     POSIX.3 & 2003   &TR13210& Metodi di test                               \\
 483     POSIX.4 & 1003.1b &  --- & Estensioni real-time                         \\
 484     POSIX.4a& 1003.1c &  --- & Thread                                       \\
 485     POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time               \\
 486     POSIX.5 & 1003.5  & 14519& Interfaccia per il linguaggio ADA            \\
 487     POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza                                 \\
 488     POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete                     \\
 489     POSIX.9 & 1003.9  &  --- & Interfaccia per il Fortran-77                \\
 490     POSIX.12& 1003.1g& 9945-1& Socket                                       \\
 491     \hline
 492   \end{tabular}
 493   \caption{Elenco dei vari standard POSIX e relative denominazioni.}
 494   \label{tab:intro_posix_std}
 495 \end{table}
 496
 497 Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
 498 definiscono comunque un'interfaccia di programmazione generica e non fanno
 499 riferimento ad una implementazione specifica (ad esempio esiste
 500 un'implementazione di POSIX.1 anche sotto Windows NT).  Lo standard principale
 501 resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui
 502 gran parte delle implementazioni fanno riferimento, e che costituisce una base
 503 per molti altri tentativi di standardizzazione, è stata rilasciata anche come
 504 standard internazionale con la sigla ISO/IEC 9945-1:1996.
 505
 506 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
 507 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
 508 funzioni di \textit{pattern matching} e per la manipolazione delle
 509 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
 510 sistema e che sono definite nello standard POSIX.2.
 511
 512 Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
 513 ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
 514 \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
 515 quanto riguarda i segnali e lo \itindex{scheduler} scheduling real-time
 516 (sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
 517 tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
 518 asincrono (sez.~\ref{sec:file_asyncronous_io}).
 519
 520
 521
 522 \subsection{Lo standard X/Open}
 523 \label{sec:intro_xopen}
 524
 525 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
 526 Unix per giungere ad un'armonizzazione delle varie implementazioni.  Per far
 527 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
 528 nome di \textit{X/Open Portability Guide} (a cui di norma si fa riferimento
 529 con l'abbreviazione XPG$n$ con $n$ che indica la versione).
 530
 531 Nel 1989 il consorzio produsse una terza versione di questa guida
 532 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
 533 contenente un'ulteriore standardizzazione dell'interfaccia di sistema di Unix,
 534 che venne presa come riferimento da vari produttori.
 535
 536 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
 537 basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive
 538 fra cui le specifiche delle API (\textit{Application Programmable Interface})
 539 per l'interfaccia grafica (X11).
 540
 541 Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
 542 Issue 4 (da cui la sigla XPG4) che aggiungeva l'interfaccia XTI (\textit{X
 543   Transport Interface}) mirante a soppiantare (senza molto successo)
 544 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
 545 rilasciata nel 1994, questa è nota con il nome di Spec 1170 (dal numero delle
 546 interfacce, header e comandi definiti).
 547
 548 Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
 549 aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
 550 specifiche sotto il nome di \textit{Single UNIX Specification}, l'ultima
 551 versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
 552   Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
 553
 554
 555 \subsection{Gli standard Unix}
 556 \label{sec:intro_opengroup}
 557
 558 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
 559 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
 560 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
 561 raccoglie produttori, utenti industriali, entità accademiche e governative.
 562
 563 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
 564 il lavoro di standardizzazione delle varie implementazioni, rilasciando
 565 periodicamente nuove specifiche e strumenti per la verifica della conformità
 566 alle stesse.
 567
 568 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
 569   Specification}, nota con la sigla SUSv2, in questa versione le interfacce
 570 specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro
 571 grafiche, per le quali sono inserite pure le interfacce usate da CDE che
 572 richiede sia X11 che Motif). La conformità a questa versione permette l'uso
 573 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard.
 574
 575
 576 \subsection{Lo ``\textsl{standard}'' BSD}
 577 \label{sec:intro_bsd}
 578
 579 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
 580 di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
 581 mondo Unix.  L'Università di Berkley proseguì nello sviluppo della base di
 582 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
 583 versioni allora disponibili, fino ad arrivare al rilascio di una versione
 584 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 585 della AT\&T.
 586
 587 Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
 588 dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
 589 API di grande rilievo, come i link simbolici, la funzione \code{select} ed i
 590 socket.
 591
 592 Queste estensioni sono state via via aggiunte al sistema nelle varie versioni
 593 del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati
 594 commerciali come SunOS. Il kernel Linux e le \acr{glibc} provvedono tutte
 595 queste estensioni che sono state in gran parte incorporate negli standard
 596 successivi.
 597
 598
 599 \subsection{Lo standard System V}
 600 \label{sec:intro_sysv}
 601
 602 Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
 603 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
 604 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
 605 Unix System V. Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando
 606 varie versioni con aggiunte e integrazioni; nel 1989 un accordo fra vari
 607 venditori (AT\&T, Sun, HP, e altro) portò ad una versione che provvedeva
 608 un'unificazione delle interfacce comprendente Xenix e BSD, la System V release
 609 4.
 610
 611 L'interfaccia di questa ultima release è descritta in un documento dal titolo
 612 \textit{System V Interface Description}, o SVID; spesso però si fa riferimento
 613 a questo standard con il nome della sua implementazione, usando la sigla SVr4.
 614
 615 Anche questo costituisce un sovrainsieme delle interfacce definite dallo
 616 standard POSIX.  Nel 1992 venne rilasciata una seconda versione del sistema:
 617 la SVr4.2. L'anno successivo la divisione della AT\&T (già a suo tempo
 618 rinominata in Unix System Laboratories) venne acquistata dalla Novell, che poi
 619 trasferì il marchio Unix al consorzio X/Open; l'ultima versione di System V fu
 620 la SVr4.2MP rilasciata nel Dicembre 93.
 621
 622 Linux e le \acr{glibc} implementano le principali funzionalità richieste da
 623 SVID che non sono già incluse negli standard POSIX ed ANSI C, per
 624 compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
 625 includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
 626 presenti neanche in System V) sono state tralasciate.
 627
 628 Le funzionalità implementate sono principalmente il meccanismo di
 629 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
 630 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
 631 \func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
 632 matematiche.
 633
 634
 635 \subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}}
 636 \label{sec:intro_gcc_glibc_std}
 637
 638 In Linux, grazie alle \acr{glibc}, gli standard appena descritti sono
 639 ottenibili sia attraverso l'uso di opzioni del compilatore (il \cmd{gcc}) che
 640 definendo opportune costanti prima dell'inclusione dei file degli header.
 641
 642 Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
 643 si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere
 644 utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per
 645 il C.
 646
 647 Per attivare le varie opzioni è possibile definire le macro di preprocessore,
 648 che controllano le funzionalità che le \acr{glibc} possono mettere a
 649 disposizione: questo può essere fatto attraverso l'opzione \cmd{-D} del
 650 compilatore, ma è buona norma inserire gli opportuni \code{\#define} nei
 651 propri header file.
 652
 653 Le macro disponibili per i vari standard sono le seguenti:
 654 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
 655 \item[\macro{\_POSIX\_SOURCE}] definendo questa macro si rendono disponibili
 656   tutte le funzionalità dello standard POSIX.1 (la versione IEEE Standard
 657   1003.1) insieme a tutte le funzionalità dello standard ISO C. Se viene anche
 658   definita con un intero positivo la macro \macro{\_POSIX\_C\_SOURCE} lo stato
 659   di questa non viene preso in considerazione.
 660 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
 661   positivo si controlla quale livello delle funzionalità specificate da POSIX
 662   viene messa a disposizione; più alto è il valore maggiori sono le
 663   funzionalità. Se è uguale a ``\texttt{1}'' vengono attivate le funzionalità
 664   specificate nella edizione del 1990 (IEEE Standard 1003.1-1990), valori
 665   maggiori o uguali a ``\texttt{2}'' attivano le funzionalità POSIX.2
 666   specificate nell'edizione del 1992 (IEEE Standard 1003.2-1992). Un valore
 667   maggiore o uguale a ``\texttt{199309L}'' attiva le funzionalità POSIX.1b
 668   specificate nell'edizione del 1993 (IEEE Standard 1003.1b-1993).  Un valore
 669   maggiore o uguale a ``\texttt{199506L}'' attiva le funzionalità POSIX.1
 670   specificate nell'edizione del 1996 (ISO/IEC 9945-1: 1996). Valori superiori
 671   abiliteranno ulteriori estensioni.
 672 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si attivano le
 673   funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
 674   ISO C, POSIX.1 e POSIX.2. Alcune delle funzionalità previste da BSD sono
 675   però in conflitto con le corrispondenti definite nello standard POSIX.1, in
 676   questo caso le definizioni previste da BSD4.3 hanno la precedenza rispetto a
 677   POSIX.  A causa della natura dei conflitti con POSIX per ottenere una piena
 678   compatibilità con BSD4.3 è necessario anche usare una libreria di
 679   compatibilità, dato che alcune funzioni sono definite in modo diverso. In
 680   questo caso occorre pertanto anche usare l'opzione \cmd{-lbsd-compat} con il
 681   compilatore per indicargli di utilizzare le versioni nella libreria di
 682   compatibilità prima di quelle normali.
 683 \item[\macro{\_SVID\_SOURCE}] definendo questa macro si attivano le
 684   funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
 685   standard ISO C, POSIX.1, POSIX.2, e X/Open.
 686 \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le
 687   funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste
 688   sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti
 689   sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono
 690   automaticamente definite. Sono incluse anche ulteriori funzionalità
 691   disponibili in BSD e SVID. Se il valore della macro è posto a
 692   ``\texttt{500}'' questo include anche le nuove definizioni introdotte con la
 693   \textit{Single UNIX Specification, version 2}, cioè Unix98.
 694 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le
 695   ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio
 696   \textit{X/Open Unix}.
 697 \item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si attivano le
 698   funzionalità previste per la revisione delle librerie standard del C
 699   denominato ISO C99. Dato che lo standard non è ancora adottato in maniera
 700   ampia queste non sono abilitate automaticamente, ma le \acr{glibc} hanno già
 701   un'implementazione completa che può essere attivata definendo questa macro.
 702 \item[\macro{\_LARGEFILE\_SOURCE}] definendo questa macro si attivano le
 703   funzionalità per il supporto dei file di grandi dimensioni (il \textit{Large
 704     File Support} o LFS) con indici e dimensioni a 64 bit.
 705 \item[\macro{\_GNU\_SOURCE}] definendo questa macro si attivano tutte le
 706   funzionalità disponibili: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID,
 707   X/Open, LFS più le estensioni specifiche GNU. Nel caso in cui BSD e POSIX
 708   confliggano viene data la precedenza a POSIX.
 709 \end{basedescript}
 710
 711 In particolare è da sottolineare che le \acr{glibc} supportano alcune
 712 estensioni specifiche GNU, che non sono comprese in nessuno degli standard
 713 citati. Per poterle utilizzare esse devono essere attivate esplicitamente
 714 definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header
 715 file.
 716
 717
 718 %% \subsection{Gli standard di GNU/Linux}
 719 %% \label{sec:intro_linux_std}
 720
 721 % TODO Da fare (o cassare, a seconda del tempo e della voglia).
 722
 723
 724
 725 % LocalWords:  like kernel multitasking scheduler prehemptive sez swap is cap
 726 % LocalWords:  everything bootstrap init shell Windows Foundation system call
 727 % LocalWords:  fig libc uClib glibc embedded Library POSIX username PAM Methods
 728 % LocalWords:  Pluggable Autentication group supplementary Name Service Switch
 729 % LocalWords:  LDAP identifier uid gid superuser root if BSD SVr dall' American
 730 % LocalWords:  National Institute International Organisation IEC header tab gcc
 731 % LocalWords:  assert ctype dirent errno fcntl limits malloc setjmp signal utmp
 732 % LocalWords:  stdarg stdio stdlib string times unistd library int short caddr
 733 % LocalWords:  address clock dev ino inode key IPC loff nlink off pid rlim size
 734 % LocalWords:  sigset ssize ptrdiff sys nell'header IEEE Richard Portable of TR
 735 % LocalWords:  Operating Interface dell'IEEE Electrical and Electronics thread
 736 % LocalWords:  Engeneers Socket NT matching regular expression scheduling l'I
 737 % LocalWords:  XPG Portability Issue Application Programmable XTI Transport AT
 738 % LocalWords:  socket Spec Novell Specification SUSv CDE Motif Berkley select
 739 % LocalWords:  SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
 740 % LocalWords:  drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
 741 % LocalWords:  LARGEFILE Support LFS dell'
 742
 743
 744 %%% Local Variables:
 745 %%% mode: latex
 746 %%% TeX-master: "gapil"
 747 %%% End: