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
12 \chapter{L'architettura del sistema}
13 \label{cha:intro_unix}
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.
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.
26 \section{Una panoramica}
27 \label{sec:intro_unix_struct}
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.
34 \subsection{Concetti base}
35 \label{sec:intro_base_concept}
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.
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
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.
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).
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
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.
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.
91 \subsection{Il kernel e il sistema}
92 \label{sec:intro_kern_and_sys}
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.
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.
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.
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
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.
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.
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.
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
155 \subsection{Chiamate al sistema e librerie di funzioni}
156 \label{sec:intro_syscall}
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.
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}.
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}
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.
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
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.
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.
221 \subsection{Un sistema multiutente}
222 \label{sec:intro_multiuser}
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.
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.
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.}
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.
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.
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
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
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\ \}}''.}
284 \section{Gli standard}
285 \label{sec:intro_standard}
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.
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}).
301 \subsection{Lo standard ANSI C}
302 \label{sec:intro_ansiC}
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.
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.
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
333 \begin{tabular}[c]{|l|c|c|l|}
335 \multirow{2}{*}{\textbf{Header}}&
336 \multicolumn{2}{|c|}{\textbf{Standard}}&
337 \multirow{2}{*}{\textbf{Contenuto}} \\
342 \file{assert.h}&$\bullet$& & Verifica le asserzioni fatte in un
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.\\
362 \caption{Elenco dei vari header file definiti dallo standard POSIX.}
363 \label{tab:intro_posix_header}
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.
376 \subsection{I tipi di dati primitivi}
377 \label{sec:intro_data_types}
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 \index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
384 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
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à.
399 \begin{tabular}[c]{|l|l|}
401 \textbf{Tipo} & \textbf{Contenuto} \\
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 \index{inode} \textit{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.\\
424 \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.}
425 \label{tab:intro_primitive_types}
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 \index{tipo!primitivo} \textsl{tipi primitivi} 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
438 \subsection{Lo standard IEEE -- POSIX}
439 \label{sec:intro_posix}
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.
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.
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).
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}}.
473 \begin{tabular}[c]{|l|l|l|l|}
475 \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
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 \\
492 \caption{Elenco dei vari standard POSIX e relative denominazioni.}
493 \label{tab:intro_posix_std}
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.
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.
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}).
521 \subsection{Lo standard X/Open}
522 \label{sec:intro_xopen}
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).
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.
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).
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).
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}.
554 \subsection{Gli standard Unix}
555 \label{sec:intro_opengroup}
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.
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à
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.
575 \subsection{Lo ``\textsl{standard}'' BSD}
576 \label{sec:intro_bsd}
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
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
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
598 \subsection{Lo standard System V}
599 \label{sec:intro_sysv}
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
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.
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.
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.
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
634 \subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}}
635 \label{sec:intro_gcc_glibc_std}
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.
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
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
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.
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
717 %% \subsection{Gli standard di GNU/Linux}
718 %% \label{sec:intro_linux_std}
720 % TODO Da fare (o cassare, a seconda del tempo e della voglia).
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'
745 %%% TeX-master: "gapil"