3 %% Copyright (C) 2000-2018 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 di un
30 sistema operativo di tipo Unix, come GNU/Linux, e della relazione fra le varie
31 parti che lo compongono. Chi avesse già una conoscenza di questa materia può
32 tranquillamente saltare questa sezione.
34 \subsection{Concetti base}
35 \label{sec:intro_base_concept}
37 Il concetto principale su cui è basata l'architettura di un sistema unix-like
38 è quello di un nucleo del sistema, il cosiddetto \textit{kernel} (nel nostro
39 caso Linux) a cui si demanda la gestione delle risorse della propria macchina
40 (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi anche la
41 parte che prevede l'interazione con l'utente, dev'essere realizzato tramite
42 programmi eseguiti dal kernel, che accedano alle risorse tramite opportune
43 richieste a quest'ultimo.
45 Fin dai suoi albori Unix nasce come sistema operativo \textit{multitasking},
46 cioè in grado di eseguire contemporaneamente più programmi, e multiutente, in
47 cui è possibile che più utenti siano connessi ad una macchina eseguendo più
48 programmi ``\textsl{in contemporanea}''. In realtà, almeno per le macchine a
49 processore singolo, i programmi vengono semplicemente eseguiti uno alla volta
50 in una opportuna \textsl{rotazione}.\footnote{anche se oggi, con la presenza
51 di sistemi multiprocessore, si possono avere più processi eseguiti in
52 contemporanea, il concetto di ``\textsl{rotazione}'' resta comunque valido,
53 dato che in genere il numero di processi da eseguire eccede il numero dei
54 precessori disponibili. }
56 % Questa e` una distinzione essenziale da capire,
57 %specie nei confronti dei sistemi operativi successivi, nati per i personal
58 %computer (e quindi per un uso personale), sui quali l'hardware (allora
59 %limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
61 I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
62 caratteristiche dei processori moderni come la gestione hardware della memoria
63 e la modalità protetta. In sostanza con i processori moderni si può
64 disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
65 zone di memoria fisica. Quello che succede è che il kernel è il solo
66 programma ad essere eseguito in modalità privilegiata, con il completo accesso
67 a tutte le risorse della macchina, mentre i programmi normali vengono eseguiti
68 in modalità protetta senza accesso diretto alle risorse. Uno schema
69 elementare della struttura del sistema è riportato in
70 fig.~\ref{fig:intro_sys_struct}.
74 \includegraphics[width=11cm]{img/struct_sys}
76 % \filldraw[fill=black!20] (0,0) rectangle (7.5,1);
77 % \draw (3.75,0.5) node {\textsl{System Call Interface}};
78 % \filldraw[fill=black!35] (0,1) rectangle (7.5,4);
79 % \draw (3.75,2.5) node {\huge{\textsf{kernel}}};
80 % \filldraw[fill=black!20] (0,4) rectangle (2.5,5);
81 % \draw (1.25,4.5) node {\textsf{scheduler}};
82 % \filldraw[fill=black!20] (2.5,4) rectangle (5,5);
83 % \draw (3.75,4.5) node {\textsf{VM}};
84 % \filldraw[fill=black!20] (5,4) rectangle (7.5,5);
85 % \draw (6.25,4.5) node {\textsf{driver}};
87 % \draw (1.25,7) node(cpu) [ellipse,draw] {\textsf{CPU}};
88 % \draw (3.75,7) node(mem) [ellipse,draw] {\textsf{memoria}};
89 % \draw (6.25,7) node(disk) [ellipse,draw] {\textsf{disco}};
91 % \draw[<->] (cpu) -- (1.25,5);
92 % \draw[<->] (mem) -- (3.75,5);
93 % \draw[<->] (disk) -- (6.25,5);
95 % \draw (7.5,0) node [anchor=base west] {\textit{kernel space}};
96 % \draw (7.5,-1) node [anchor=west] {\textit{user space}};
98 % \draw (-1,-0.5) -- (8.5, -0.5);
100 % \draw (0,-2) rectangle (7.5,-1);
101 % \draw (3.75, -1.5) node {\textsl{GNU C Library}};
102 % \draw[->] (1.25,-1) -- (1.25,0);
103 % \draw[->] (3.75,-1) -- (3.75,0);
104 % \draw[->] (6.25,-1) -- (6.25,0);
106 % \draw (1.25,-3) node(proc1) [rectangle,draw] {\textsf{processo}};
107 % \draw (3.75,-3) node(proc2) [rectangle,draw] {\textsf{processo}};
108 % \draw (6.25,-3) node(proc3) [rectangle,draw] {\textsf{processo}};
110 % \draw[->] (1.25,-2) -- (proc1);
111 % \draw[->] (3.75,-2) -- (proc2);
112 % \draw[->] (6.25,-2) -- (proc3);
114 \caption{Schema di massima della struttura di interazione fra processi,
115 kernel e dispositivi in Linux.}
116 \label{fig:intro_sys_struct}
121 Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, sulla
122 base di un opportuno calcolo delle priorità e con una suddivisione appropriata
123 del tempo di processore, quali fra i vari ``\textsl{processi}'' presenti nel
124 sistema deve essere eseguito, realizzando il cosiddetto
125 \itindex{preemptive~multitasking} \textit{preemptive
126 multitasking}.\footnote{si chiama così quella gestione del
127 \textit{multitasking} in cui è il kernel a decidere a chi assegnare l'uso
128 della CPU, potendo interrompere l'esecuzione di un processo in qualunque
129 momento.} Ogni processo verrà comunque eseguito in modalità protetta;
130 quando necessario esso potrà accedere alle risorse della macchina soltanto
131 attraverso delle ``\textsl{chiamate al sistema}'' (vedi
132 sez.~\ref{sec:intro_syscall}) che restituiranno il controllo al kernel per
133 eseguire le operazioni necessarie.
137 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
138 \textsl{memoria virtuale}, che consente di assegnare a ciascun processo uno
139 spazio di indirizzi ``\textsl{virtuale}'' (vedi sez.~\ref{sec:proc_memory})
140 che il kernel stesso, con l'ausilio della unità di gestione della memoria, si
141 incaricherà di rimappare automaticamente sulla memoria fisica disponibile, con
142 la possibilità ulteriore di spostare temporaneamente su disco (nella
143 cosiddetta area di \textit{swap}) parte di detta memoria qualora ci si trovi
144 nella necessità di liberare risorse.
146 Le periferiche infine vengono normalmente viste attraverso un'interfaccia
147 astratta che permette di trattarle come se fossero dei file, secondo uno dei
148 concetti base della architettura di Unix, per cui ``\textsl{tutto è in file}''
149 (\textit{everything is a file}) su cui torneremo in
150 sez.~\ref{sec:intro_file_dir}. In realtà questo non è sempre vero (ad esempio
151 non lo è per le interfacce di rete) dato che ci sono periferiche che non
152 rispondendo bene a questa astrazione richiedono un'interfaccia diversa. Anche
153 in questo caso però resta valido il concetto generale che tutto il lavoro di
154 accesso e gestione delle periferiche a basso livello viene effettuato dal
155 kernel tramite l'opportuno codice di gestione delle stesse, che in
156 fig.~\ref{fig:intro_sys_struct} si è indicato come \textit{driver}.
159 \subsection{Il kernel e il sistema}
160 \label{sec:intro_kern_and_sys}
162 Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
163 quello della distinzione fra il cosiddetto \textit{user space}, che
164 contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
165 \textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
166 programma vede sé stesso come se avesse la piena disponibilità della CPU e
167 della memoria ed è, salvo i meccanismi di comunicazione previsti dal sistema,
168 completamente ignaro del fatto che altri programmi possono essere messi in
169 esecuzione dal kernel.
171 Per questa separazione non è possibile ad un singolo programma disturbare
172 l'azione di un altro programma o del kernel stesso, e questo è il principale
173 motivo della stabilità di un sistema unix-like nei confronti di altri sistemi
174 in cui i processi non hanno di questi limiti o in cui essi vengono eseguiti
175 allo stesso livello del kernel. Pertanto deve essere chiaro a chi programma in
176 un sistema unix-like che l'accesso diretto all'hardware non può avvenire se
177 non all'interno del kernel; al di fuori dal kernel il programmatore deve usare
178 le opportune interfacce che quest'ultimo fornisce per i programmi in
181 Per capire meglio la distinzione fra \textit{kernel space} e \textit{user
182 space} si può prendere in esame la procedura di avvio di un sistema
183 unix-like. All'accensione il \textit{firmware} presente nella EPROM della
184 propria macchina (per i PC compatibili il BIOS), eseguirà la procedura di
185 avvio del sistema, il cosiddetto \textit{bootstrap},\footnote{il nome deriva
186 da un'espressione gergale che significa ``sollevarsi da terra tirandosi per
187 le stringhe delle scarpe'', per indicare il compito, almeno apparentemente
188 impossibile, di far eseguire un programma a partire da un computer appena
189 acceso che appunto non ne contiene nessuno; non è impossibile perché in
190 realtà c'è un programma iniziale, che è il BIOS.} incaricandosi di caricare
191 il kernel in memoria e di farne partire l'esecuzione.
193 A questo punto il controllo passerà al kernel, il quale però da parte sua, una
194 volta inizializzato opportunamente l'hardware, si limiterà a due sole
195 operazioni, montare il filesystem radice (torneremo su questo in
196 sez.~\ref{sec:file_arch_overview}) e lanciare il primo processo che eseguirà
197 il programma di inizializzazione del sistema, che in genere, visto il suo
198 scopo, si chiama \cmd{init}.
200 Una volta lanciato \cmd{init} tutto il lavoro successivo verrà eseguito
201 \textit{user space} da questo programma, che sua volta si incaricherà di
202 lanciare tutti gli altri programmi, fra cui ci sarà quello che si occupa di
203 dialogare con la tastiera e lo schermo della console, quello che mette a
204 disposizione un terminale e la \textit{shell} da cui inviare i comandi
205 all'utente che si vuole collegare, ed in generale tutto quanto necessario ad
206 avere un sistema utilizzabile.
208 E' da rimarcare come tutto ciò che riguarda l'interazione con l'utente, che
209 usualmente viene visto come parte del sistema, non abbia in realtà niente a
210 che fare con il kernel, ma sia effettuato da opportuni programmi che vengono
211 eseguiti, allo stesso modo di un qualunque programma di scrittura o di disegno
212 e della stessa interfaccia grafica, in \textit{user space}.
214 Questo significa ad esempio che il sistema di per sé non dispone di primitive
215 per tutta una serie di operazioni (ad esempio come la copia di un file) che
216 altri sistemi (come Windows) hanno invece al loro interno. Questo perché tutte
217 le operazioni di normale amministrazione di un sistema, sono effettuata
218 attraverso dei normali programmi utilizzando le interfacce di programmazione
219 che il kernel mette a disposizione.
221 È per questo motivo che quando ci si riferisce al sistema nella sua interezza
222 viene spesso sottolineato come sia corretto parlare di ``GNU/Linux'' e non di
223 Linux; da solo infatti il kernel non è sufficiente, quello che costruisce un
224 sistema operativo utilizzabile è la presenza di tutta una serie di librerie e
225 programmi di utilità, ed i più comuni sono appunto quelli realizzati dal
226 progetto GNU della Free Software Foundation, grazie ai quali si possono
227 eseguire le normali operazioni che ci si aspetta da un sistema operativo.
230 \subsection{\textit{System call} e funzioni di libreria}
231 \label{sec:intro_syscall}
233 Come illustrato in fig.~\ref{fig:intro_sys_struct} i programmi possono
234 accedere ai servizi forniti dal kernel tramite opportune interfacce dette
235 \textit{system call} (\textsl{chiamate al sistema}, appunto). Si tratta di un
236 insieme di funzioni che un programma può invocare, per le quali viene generata
237 un'interruzione nell'esecuzione del codice del processo, passando il controllo
238 al kernel. Sarà quest'ultimo che eseguirà in le operazioni relative alla
239 funzione richiesta in \textit{kernel space}, restituendo poi i risultati al
242 Ogni versione di Unix ha storicamente sempre avuto un certo numero di
243 \textit{system call}, che sono documentate nella seconda sezione del
244 \textsl{Manuale di programmazione di Unix}, quella cui si accede con il
245 comando \cmd{man 2 <nome>}, ed anche Linux non fa eccezione. Queste
246 \textit{system call} sono poi state codificate da vari standard, che
247 esamineremo brevemente in sez.~\ref{sec:intro_standard}.
249 Normalmente ciascuna \textit{system call} fornita dal kernel viene associata
250 ad una funzione con lo stesso nome definita all'interno della libreria
251 fondamentale del sistema, quella che viene chiamata \textsl{Libreria Standard
252 del C} (\textit{C Standard Library}) in ragione del fatto che il primo
253 kernel Unix e tutti i programmi eseguiti su di esso vennero scritti in questo
254 linguaggio, usando le sue librerie. In seguito faremo riferimento alle
255 funzioni di questa libreria che si interfacciano alle \textit{system call}
256 come ``\textsl{funzioni di sistema}''.
258 Questa libreria infatti, oltre alle chiamate alle \textit{system call},
259 contiene anche tutta una serie di ulteriori funzioni di utilità che vengono
260 comunemente usate nella programmazione e sono definite nei vari standard che
261 documentano le interfacce di programmazione di un sistema unix-like. Questo
262 concetto è importante da tener presente perché programmare in Linux significa
263 anche essere in grado di usare le funzioni fornite dalla libreria Standard del
264 C, in quanto né il kernel né il linguaggio C implementano direttamente
265 operazioni ordinarie come l'allocazione dinamica della memoria, l'input/output
266 bufferizzato sui file, la manipolazione delle stringhe, la matematica in
267 virgola mobile, che sono comunemente usate da qualunque programma.
269 Tutto ciò mette nuovamente in evidenza il fatto che nella stragrande
270 maggioranza dei casi si dovrebbe usare il nome GNU/Linux in quanto una parte
271 essenziale del sistema, senza la quale niente funzionerebbe, è appunto la
272 \textit{GNU Standard C Library} (a cui faremo da qui in avanti riferimento
273 come \acr{glibc}), la libreria standard del C realizzata dalla Free Software
274 Foundation nella quale sono state implementate tutte le funzioni essenziali
275 definite negli standard POSIX e ANSI C (e molte altre), che vengono utilizzate
276 da qualunque programma.
278 Si tenga comunque presente che questo non è sempre vero, dato che esistono
279 implementazioni alternative della libreria standard del C, come la
280 \textit{libc5} o la \textit{uClib}, che non derivano dal progetto GNU. La
281 \textit{libc5}, che era usata con le prime versioni del kernel Linux, è oggi
282 ormai completamente soppiantata dalla \acr{glibc}. La \textit{uClib} invece,
283 pur non essendo completa come la \acr{glibc}, resta molto diffusa nel mondo
284 dei dispositivi \textit{embedded} per le sue dimensioni estremamente ridotte,
285 e soprattutto per la possibilità di togliere le parti non necessarie. Pertanto
286 costituisce un valido rimpiazzo della \acr{glibc} in tutti quei sistemi
287 specializzati che richiedono una minima occupazione di memoria. Infine per lo
288 sviluppo del sistema Android è stata realizzata da Google un'altra libreria
289 standard del C, utilizzata principalmente per evitare l'uso della \acr{glibc}.
291 Tradizionalmente le funzioni specifiche della libreria standard del C sono
292 riportate nella terza sezione del \textsl{Manuale di Programmazione di Unix}
293 (cioè accessibili con il comando \cmd{man 3 <nome>}) e come accennato non sono
294 direttamente associate ad una \textit{system call} anche se, ad esempio per la
295 gestione dei file o della allocazione dinamica della memoria, possono farne
296 uso nella loro implementazione. Nonostante questa distinzione, fondamentale
297 per capire il funzionamento del sistema, l'uso da parte dei programmi di una
298 di queste funzioni resta lo stesso, sia che si tratti di una funzione interna
299 della libreria che di una \textit{system call}.
302 \subsection{Un sistema multiutente}
303 \label{sec:intro_multiuser}
305 Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
306 multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
307 questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
308 sistemi operativi monoutente, e che occorre tenere presenti. In questa sezione
309 parleremo brevemente soltanto dei meccanismi di sicurezza tradizionali di un
310 sistema unix-like, oggi molti di questi sono stati notevolmente estesi
311 rispetto al modello tradizionale, ma per il momento ignoreremo queste
314 Il concetto base è quello di utente (\textit{user}) del sistema, le cui
315 capacità sono sottoposte a limiti precisi. Sono così previsti una serie di
316 meccanismi per identificare i singoli utenti ed una serie di permessi e
317 protezioni per impedire che utenti diversi possano danneggiarsi a vicenda o
318 danneggiare il sistema. Questi meccanismi sono realizzati dal kernel stesso ed
319 attengono alle operazioni più varie, e torneremo su di essi in dettaglio più
322 Normalmente l'utente è identificato da un nome (il cosiddetto
323 \textit{username}), che ad esempio è quello che viene richiesto all'ingresso
324 nel sistema dalla procedura di \textit{login} (torneremo su questo in
325 sez.~\ref{sec:sess_login}). Questa procedura si incarica di verificare
326 l'identità dell'utente, in genere attraverso la richiesta di una parola
327 d'ordine (la \textit{password}), anche se sono possibili meccanismi
328 diversi.\footnote{ad esempio usando la libreria PAM (\textit{Pluggable
329 Autentication Methods}) è possibile generalizzare i meccanismi di
330 autenticazione e sostituire ad esempio l'uso delle password con meccanismi
331 di identificazione biometrica; per un approfondimento dell'argomento si
332 rimanda alla sez.~4.3.7 di \cite{AGL}.} Eseguita la procedura di
333 riconoscimento in genere il sistema manda in esecuzione un programma di
334 interfaccia (che può essere la \textit{shell} su terminale o un'interfaccia
335 grafica) che mette a disposizione dell'utente un meccanismo con cui questo può
336 impartire comandi o eseguire altri programmi.
338 Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
339 \textit{default group}), ma può essere associato ad altri gruppi (i
340 \textit{supplementary group}), questo permette di gestire i permessi di
341 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
342 definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
344 L'utente e il gruppo sono identificati dal kernel un identificativo numerico,
345 la cui corrispondenza ad un nome espresso in caratteri è inserita nei due file
346 \conffile{/etc/passwd} e \conffile{/etc/group}.\footnote{in realtà negli
347 sistemi più moderni, come vedremo in sez.~\ref{sec:sys_user_group} queste
348 informazioni possono essere mantenute, con l'uso del \textit{Name Service
349 Switch}, su varie tipologie di supporti, compresi server centralizzati
350 come LDAP.} Questi identificativi sono l'\textit{user identifier}, detto in
351 breve \textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il
352 \textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato
353 dall'acronimo \ids{GID}, torneremo in dettaglio su questo argomento in
354 sez.~\ref{sec:proc_perms}. Il kernel conosce ed utilizza soltanto questi
355 valori numerici, i nomi ad essi associati sono interamente gestiti in
356 \textit{user space} con opportune funzioni di libreria, torneremo su questo
357 argomento in sez.~\ref{sec:sys_user_group}.
359 Grazie a questi identificativi il sistema è in grado di tenere traccia
360 dell'utente a cui appartiene ciascun processo ed impedire ad altri utenti di
361 interferire con quest'ultimo. Inoltre con questo sistema viene anche
362 garantita una forma base di sicurezza interna in quanto anche l'accesso ai
363 file (vedi sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo
366 Infine in ogni sistema unix-like è presente uno speciale utente privilegiato,
367 il cosiddetto \textit{superuser}, il cui username è di norma \textit{root}, ed
368 il cui \ids{UID} è zero. Esso identifica l'amministratore del sistema, che
369 deve essere in grado di fare qualunque operazione; per l'utente \textit{root}
370 infatti i meccanismi di controllo cui si è accennato in precedenza sono
371 disattivati.\footnote{i controlli infatti vengono eseguiti da uno pseudo-codice
372 del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
375 \section{L'architettura di file e directory}
376 \label{sec:intro_file_dir}
378 Come accennato in sez.~\ref{sec:intro_base_concept} uno dei concetti
379 fondamentali dell'architettura di un sistema Unix è il cosiddetto
380 \textit{everything is a file} (\textsl{tutto è un file}), cioè il fatto che
381 l'accesso ai vari dispositivi di input/output del computer viene effettuato
382 attraverso un'interfaccia astratta che tratta le periferiche allo stesso modo
383 dei normali file di dati.
385 In questa sezione forniremo una descrizione a grandi linee dell'architettura
386 della gestione dei file in Linux, partendo da una introduzione ai concetti di
387 base, per poi illustrare la struttura dell'albero dei file ed il significato
388 dei tipi di file, concludendo con una panoramica sulle caratteristiche
389 principali delle due interfacce con cui i processi possono effettuare l'I/O su
393 \subsection{Una panoramica generale}
394 \label{sec:file_arch_overview}
396 Per poter accedere ai file, il kernel deve mettere a disposizione dei
397 programmi delle opportune \textit{system call} che consentano di leggere e
398 scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
399 il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
400 che consenta di operare sui file, sia che questi corrispondano ai normali file
401 di dati, o ai cosiddetti ``\textsl{file speciali}'', come i file di
402 dispositivo (o \textit{device file}) che permettono di accedere alle
403 periferiche o le \textit{fifo} ed i socket che forniscono funzionalità di
404 comunicazione fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
406 Il secondo aspetto è che per poter utilizzare dei normali file di dati il
407 kernel deve provvedere ad organizzare e rendere accessibile in maniera
408 opportuna l'informazione in essi contenuta memorizzandola sullo spazio grezzo
409 disponibile sui dischi. Questo viene fatto strutturando l'informazione sul
410 disco attraverso quello che si chiama un
411 ``\textit{filesystem}''. L'informazione così strutturata poi viene resa
412 disponibile ai processi attraverso quello che viene chiamato il
413 ``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
414 sarà accessibile nella forma ordinaria di file e directory.
416 \itindbeg{Virtual~File~System~(VFS)}
418 In Linux il concetto di \textit{everything is a file} è stato implementato
419 attraverso il cosiddetto \textit{Virtual File System} (da qui in avanti VFS)
420 che è uno strato intermedio che il kernel usa per accedere ai più svariati
421 filesystem mantenendo la stessa interfaccia per i programmi in \textit{user
422 space}. Il VFS fornisce quel livello di astrazione che permette di
423 collegare le operazioni interne del kernel per la manipolazione sui file con
424 le \textit{system call} relative alle operazioni di I/O, e gestisce poi
425 l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem
426 le effettuano, permettendo la coesistenza di filesystem differenti all'interno
427 dello stesso albero delle directory. Approfondiremo il funzionamento di
428 interfaccia generica fornita dal VFS in sez.~\ref{sec:file_vfs_work}.
430 In sostanza quello che accade è che quando un processo esegue una
431 \textit{system call} che opera su un file, il kernel chiama sempre una
432 funzione implementata nel VFS. La funzione eseguirà le manipolazioni sulle
433 strutture generiche e utilizzerà poi delle chiamate alle opportune funzioni
434 del filesystem specifico a cui si fa riferimento. Saranno queste infine a
435 chiamare le funzioni di più basso livello che eseguono le operazioni di I/O
436 sul dispositivo fisico, secondo lo schema riportato in
437 fig.~\ref{fig:file_VFS_scheme}.
441 \includegraphics[width=8cm]{img/vfs}
442 \caption{Schema delle operazioni del VFS.}
443 \label{fig:file_VFS_scheme}
446 Questa interfaccia resta la stessa anche quando, invece che a dei normali
447 file, si accede alle periferiche coi citati file di dispositivo, solo che in
448 questo caso invece di usare il codice del filesystem che accede al disco, il
449 \textit{Virtual File System} eseguirà direttamente il codice del kernel che
450 permette di accedere alla periferica.
452 \itindend{Virtual~File~System~(VFS)}
454 Come accennato in precedenza una delle funzioni essenziali per il
455 funzionamento dell'interfaccia dei file è quella che consente di montare un
456 filesystem nell'albero dei file, e rendere così visibili i suoi contenuti. In
457 un sistema unix-like infatti, a differenza di quanto avviene in altri sistemi
458 operativi, tutti i file vengono mantenuti all'interno di un unico albero la
459 cui radice (quella che viene chiamata \textit{root directory}) viene montata
460 all'avvio direttamente dal kernel.
462 Come accennato in sez.~\ref{sec:intro_kern_and_sys}) montare la radice è,
463 insieme al lancio di \cmd{init},\footnote{l'operazione è ovviamente anche
464 preliminare al lancio di \cmd{init}, dato il kernel deve poter accedere al
465 file che contiene detto programma.} l'unica operazione che viene effettuata
466 direttamente dal kernel in fase di avvio. Il kernel infatti, completata la
467 fase di inizializzazione, utilizza l'indicazione passatagli dal
468 \textit{bootloader} su quale sia il dispositivo che contiene il filesystem da
469 usare come punto di partenza, lo monta come radice dell'albero dei file.
471 Tutti gli ulteriori filesystem che possono essere disponibili su altri
472 dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli in
473 altrettante directory del filesystem radice, su quelli che vengono chiamati
474 \textit{mount point}. Questo comunque avverrà sempre in un secondo tempo, a
475 cura dei programmi eseguiti nella procedura di inizializzazione del sistema,
476 grazie alle funzioni che tratteremo in sez.~\ref{sec:filesystem_mounting}.
479 \subsection{La risoluzione del nome di file e directory}
480 \label{sec:file_pathname}
484 Come appena illustrato sez.~\ref{sec:file_arch_overview} una delle
485 caratteristiche distintive di un sistema unix-like è quella di avere un unico
486 albero dei file. Un file deve essere identificato dall'utente usando quello
487 che viene chiamato il suo \textit{pathname},\footnote{il manuale della
488 \acr{glibc} depreca questa nomenclatura, che genererebbe confusione poiché
489 \textit{path} indica anche un insieme di directory su cui effettuare una
490 ricerca (come quello in cui la shell cerca i comandi). Al suo posto viene
491 proposto l'uso di \textit{filename} e di componente per il nome del file
492 all'interno della directory. Non seguiremo questa scelta dato che l'uso
493 della parola \textit{pathname} è ormai così comune che mantenerne l'uso è
494 senz'altro più chiaro dell'alternativa proposta.} vale a dire tramite il
495 ``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
496 \textit{pathname}) che si deve fare per accedere al file a partire da una
497 certa ``\textit{directory}''.
499 Una directory in realtà è anch'essa un file, nel senso che è anch'essa un
500 oggetto di un filesystem, solo che è un file particolare che il kernel
501 riconosce appositamente come tale per poterlo utilizzare come directory. Il
502 suo scopo è quello di contenere una lista di nomi di file e le informazioni
503 che associano ciascuno di questi nomi al relativo contenuto (torneremo su
504 questo in sez.~\ref{sec:file_arch_func}).
506 Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
507 filesystem, compresa un'altra directory, si ottiene naturalmente
508 un'organizzazione ad albero inserendo nomi di directory dentro altre
509 directory. All'interno dello stesso albero si potranno poi inserire anche
510 tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
511 sez.~\ref{sec:file_file_types}), come le \textit{fifo}, i collegamenti
512 simbolici, i socket e gli stessi file di dispositivo.
514 La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
515 dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
516 nomi che indicano le directory che lo compongono. Dato che la directory radice
517 sta in cima all'albero, essa viene indicata semplicemente con il
518 \textit{pathname} ``\file{/}''.
520 \itindbeg{pathname~resolution}
522 Un file può essere indicato rispetto ad una directory semplicemente
523 specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
524 nelle directory ``componenti'' (in inglese \textit{file name components}), noi
525 li chiameremo più semplicemente \textsl{nomi} o \textsl{voci}, riservando la
526 parola \textsl{componenti} ai nomi che, separati da una ``\texttt{/}'',
527 costituiscono il \textit{pathname}. Questi poi dovranno corrispondere, perché
528 il \textit{pathname} sia valido, a voci effettivamente presenti nelle
529 directory, ma non è detto che un \textit{pathname} debba per forza risultare
532 Il procedimento con cui dato un \textit{pathname} si individua il file a cui
533 esso fa riferimento, è chiamato \textsl{risoluzione del percorso}
534 (\textit{filename resolution} o \textit{pathname resolution}). Lo stesso
535 procedimento ci può anche dire che il \textit{pathname} usato non è valido.
536 La risoluzione viene eseguita esaminando il \textit{pathname} da sinistra a
537 destra e localizzando ogni componente dello stesso come nome in una directory
538 a partire dalla directory iniziale, usando il carattere ``\texttt{/}'' come
539 separatore per scendere dall'una all'altra. Nel caso si indichi un componente
540 vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
543 Ovviamente perché la risoluzione abbia successo occorre che i componenti
544 intermedi esistano e siano effettivamente directory, e che il file o la
545 directory indicata dall'ultimo componente esista. Inoltre i permessi relativi
546 alle directory indicate nel \textit{pathname} (torneremo su questo
547 sez.~\ref{sec:file_access_control}) dovranno consentire l'accesso all'intero
550 \itindsubbeg{pathname}{assoluto}
551 \itindsubbeg{pathname}{relativo}
553 Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
554 parte dalla directory radice del processo. Questa, a meno di non avere
555 eseguito una \func{chroot} (funzione su cui torneremo in
556 sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
557 directory radice dell'albero dei file montata dal kernel all'avvio del
558 sistema; in questo caso si parla di un \textsl{pathname assoluto}. Altrimenti
559 la ricerca parte dalla directory di lavoro corrente del processo (su cui
560 torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
561 \textsl{pathname relativo}.
563 \itindsubend{pathname}{assoluto}
564 \itindsubend{pathname}{relativo}
566 Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
567 speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
568 sez.~\ref{sec:file_dir_creat_rem}). Il primo fa riferimento alla directory
569 corrente e il secondo alla directory \textsl{genitrice} (o \textit{parent
570 directory}) cioè la directory che contiene il riferimento alla directory
573 In questo modo con ``\file{..}'' si può usare un \textit{pathname} relativo
574 per indicare un file posto al di sopra della directory corrente, tornando
575 all'indietro nell'albero dei file. Questa retromarcia però su fermerà una
576 volta raggiunta la directory radice, perché non esistendo in questo caso una
577 directory superiore, il nome ``\file{..}'' farà riferimento alla radice
581 \itindend{pathname~resolution}
584 \subsection{I tipi di file}
585 \label{sec:file_file_types}
587 Parlare dei tipi di file su Linux, come per qualunque sistema unix-like,
588 significa anzitutto chiarire il proprio vocabolario e sottolineare le
589 differenze che ci sono rispetto ad altri sistemi operativi.
591 \index{file!di~dispositivo|(}
592 \index{file!speciali|(}
594 Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
595 \textit{Virtual File System} consente di trattare come file oggetti molto
596 diversi fra loro. Oltre ai normali file di dati abbiamo già accennato ad altri
597 due di questi oggetti, i file di dispositivo e le directory, ma ne esistono
598 altri. In genere quando si parla di tipo di file su Linux si fa riferimento a
599 questi diversi tipi, di cui si riportato l'elenco completo in
600 tab.~\ref{tab:file_file_types}.
605 \begin{tabular}[c]{|l|l|p{6cm}|}
607 \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
610 \textit{regular file}& \textsl{file regolare}
611 & Un file che contiene dei dati (l'accezione
613 \textit{directory} &\textsl{cartella o direttorio}
614 & Un file che contiene una lista di nomi associati
615 a degli \textit{inode} (vedi
616 sez.~\ref{sec:file_vfs_work}).\\
617 \textit{symbolic link}&\textsl{collegamento simbolico}
618 & Un file che contiene un riferimento ad un altro
620 \textit{char device} &\textsl{dispositivo a caratteri}
621 & Un file \textsl{speciale} che identifica una
622 periferica ad accesso a caratteri.\\
623 \textit{block device}& \textsl{dispositivo a blocchi}
624 & Un file \textsl{speciale} che identifica una
625 periferica ad accesso a blocchi.\\
626 \textit{fifo} & ``\textsl{coda}''
627 & Un file \textsl{speciale} che identifica una
628 linea di comunicazione unidirezionale (vedi
629 sez.~\ref{sec:ipc_named_pipe}).\\
630 \textit{socket} & ``\textsl{presa}''
631 & Un file \textsl{speciale} che identifica una
632 linea di comunicazione bidirezionale (vedi
633 cap.~\ref{cha:socket_intro}).\\
636 \caption{Tipologia dei file definiti nel VFS}
637 \label{tab:file_file_types}
640 Si tenga ben presente che questa classificazione non ha nulla a che fare con
641 una classificazione dei file in base al loro contenuto, dato che in tal caso
642 si avrebbe a che fare sempre e solo con dei file di dati. E non ha niente a
643 che fare neanche con le eventuali diverse modalità con cui si possa accedere
644 al contenuto dei file di dati. La classificazione di
645 tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
646 \textit{Virtual File System}, ed è da notare la presenza dei cosiddetti file
647 ``\textsl{speciali}''.
649 Alcuni di essi, come le \textit{fifo} (che tratteremo in
650 sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
651 cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
652 alcune funzionalità di comunicazione fornite dal kernel. Gli altri sono
653 proprio quei \textsl{file di dispositivo} che costituiscono una interfaccia
654 diretta per leggere e scrivere sui dispositivi fisici. Anche se finora li
655 abbiamo chiamati genericamente così, essi sono tradizionalmente suddivisi in
656 due grandi categorie, \textsl{a blocchi} e \textsl{a caratteri}, a seconda
657 delle modalità in cui il dispositivo sottostante effettua le operazioni di
660 I dispositivi a blocchi (ad esempio i dischi) sono quelli corrispondono a
661 periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi di
662 dati di dimensioni fissate (nel caso dei dischi le dimensioni di un settore),
663 mentre i dispositivi a caratteri sono quelli per cui l'I/O può essere
664 effettuato senza nessuna particolare struttura, ed in generale anche un byte
665 alla volta, da cui il nome.
667 Una delle differenze principali con altri sistemi operativi come il VMS o
668 Windows è che per Unix tutti i file di dati sono identici e contengono un
669 flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
670 sistema file di diverso contenuto o formato, come nel caso di quella fra file
671 di testo e binari che c'è in Windows. Non c'è neanche una strutturazione a
672 record per il cosiddetto ``\textsl{accesso diretto}'' come nel caso del
673 VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
674 dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
675 ed è completamente trasparente all'utente; inoltre talvolta si parla di
676 \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
677 fare con tutto ciò, di effettuare attraverso degli appositi file di
678 dispositivo delle operazioni di I/O direttamente sui dischi senza passare
679 attraverso un filesystem, il cosiddetto \textit{raw access}, introdotto coi
680 kernel della serie 2.4.x ma ormai in sostanziale disuso.}
682 \index{file!di~dispositivo|)}
683 \index{file!speciali|)}
685 Una differenza che attiene ai contenuti di un file però esiste, ed è relativa
686 al formato dei file di testo. Nei sistemi unix-like la fine riga è codificata
687 in maniera diversa da Windows o dal vecchio MacOS, in particolare il fine riga
688 è il carattere \texttt{LF} (\verb|\n|) al posto del \texttt{CR} (\verb|\r|)
689 del vecchio MacOS e del \texttt{CR LF} (\verb|\r\n|) di Windows. Questo può
690 causare alcuni problemi qualora nei programmi si facciano assunzioni sul
691 terminatore della riga e per questo esistono dei programmi come \cmd{unix2dos}
692 e \cmd{dos2unix} che effettuano una conversione fra questi due formati di
695 Si ricordi comunque che un kernel unix-like non fornisce nessun supporto per
696 la tipizzazione dei file di dati in base al loro contenuto e che non c'è
697 nessun supporto per una qualche interpretazione delle estensioni (nel nome del
698 file) da parte del kernel,\footnote{non è così ad esempio nel filesystem HFS
699 dei Mac, che supporta delle risorse associate ad ogni file, che specificano
700 fra l'altro il contenuto ed il programma da usare per leggerlo; in realtà
701 per alcuni filesystem esiste la possibilità di associare delle risorse ai
702 file con gli \textit{extended attributes} (vedi sez.~\ref{sec:file_xattr}),
703 ma è una caratteristica tutt'ora poco utilizzata, dato che non corrisponde
704 al modello classico dei file in un sistema Unix.} ogni classificazione di
705 questo tipo avviene sempre in \textit{user space}. Gli unici file di cui il
706 kernel deve essere in grado di capire il contenuto sono i binari dei
707 programmi, per i quali sono supportati solo alcuni formati, anche se oggi
708 viene usato quasi esclusivamente
709 \itindex{Executable~and~Linkable~Format~(ELF)} l'ELF.\footnote{il nome è
710 l'acronimo di \textit{Executable and Linkable Format}, un formato per
711 eseguibili binari molto flessibile ed estendibile definito nel 1995 dal
712 \textit{Tool Interface Standard} che per le sue caratteristiche di non
713 essere legato a nessun tipo di processore o architettura è stato adottato da
714 molti sistemi unix-like e non solo.}
716 \itindbeg{magic~number}
718 Nonostante l'assenza di supporto da parte del kernel per la classificazione
719 del contenuto dei file di dati, molti programmi adottano comunque delle
720 convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
721 in file con l'estensione ``\file{.c}''. Inoltre una tecnica molto usata per
722 classificare i contenuti da parte dei programmi è quella di utilizzare i primi
723 byte del file per memorizzare un ``\textit{magic number}'' che ne classifichi
724 il contenuto. Il concetto è quello di un numero intero, solitamente fra 2 e 10
725 byte, che identifichi il contenuto seguente, dato che questi sono anche
726 caratteri è comune trovare espresso tale numero con stringhe come
727 ``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script. Entrambe
728 queste tecniche, per quanto usate ed accettate in maniera diffusa, restano
729 solo delle convenzioni il cui rispetto è demandato alle applicazioni stesse.
731 \itindend{magic~number}
734 \subsection{Le due interfacce per l'accesso ai file}
735 \label{sec:file_io_api}
738 \itindbeg{file~descriptor}
740 In Linux le interfacce di programmazione per l'I/O su file due. La prima è
741 l'interfaccia nativa del sistema, quella che il manuale della \textsl{glibc}
742 chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
743 \textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
744 sistemi unix-like che fornisce un accesso non bufferizzato.
746 L'interfaccia è essenziale, l'accesso viene detto non bufferizzato in quanto
747 la lettura e la scrittura vengono eseguite chiamando direttamente le
748 \textit{system call} del kernel, anche se in realtà il kernel effettua al suo
749 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
750 dispositivi. L'accesso viene gestito attraverso i \textit{file descriptor} che
751 sono rappresentati da numeri interi (cioè semplici variabili di tipo
752 \ctyp{int}). L'interfaccia è definita nell'\textit{header file}
753 \headfile{unistd.h} e la tratteremo in dettaglio in
754 sez.~\ref{sec:file_unix_interface}.
756 \itindbeg{file~stream}
758 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama dei
759 \textit{file stream} o più semplicemente degli \textit{stream}.\footnote{in
760 realtà una interfaccia con lo stesso nome è stata introdotta a livello di
761 kernel negli Unix derivati da \textit{System V}, come strato di astrazione
762 per file e socket; in Linux questa interfaccia, che comunque ha avuto poco
763 successo, non esiste, per cui facendo riferimento agli \textit{stream}
764 useremo il significato adottato dal manuale della \acr{glibc}.} Essa
765 fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
766 implementazione fatta nella \acr{glibc}. Questa è l'interfaccia specificata
767 dallo standard ANSI C e perciò si trova anche su tutti i sistemi non Unix. Gli
768 \textit{stream} sono oggetti complessi e sono rappresentati da puntatori ad un
769 opportuna struttura definita dalle librerie del C, a cui si accede sempre in
770 maniera indiretta utilizzando il tipo \code{FILE *}; l'interfaccia è definita
771 nell'\textit{header file} \headfile{stdio.h} e la tratteremo in dettaglio in
772 sez.~\ref{sec:files_std_interface}.
774 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
775 altri oggetti del VFS, ma per poter accedere alle operazioni di controllo
776 (descritte in sez.~\ref{sec:file_fcntl_ioctl}) su un qualunque tipo di oggetto
777 del VFS occorre usare l'interfaccia standard di Unix con i file
778 descriptor. Allo stesso modo devono essere usati i file descriptor se si vuole
779 ricorrere a modalità speciali di I/O come il \textit{file locking} o l'I/O
780 non-bloccante (vedi cap.~\ref{cha:file_advanced}).
782 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
783 quella dei \textit{file descriptor}, che permette di poter scegliere tra
784 diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
785 è che l'interfaccia per le operazioni di input/output è molto più ricca di
786 quella dei \textit{file descriptor}, che forniscono solo funzioni elementari
787 per la lettura/scrittura diretta di blocchi di byte. In particolare gli
788 \textit{stream} dispongono di tutte le funzioni di formattazione per l'input e
789 l'output adatte per manipolare anche i dati in forma di linee o singoli
792 In ogni caso, dato che gli \textit{stream} sono implementati sopra
793 l'interfaccia standard di Unix, è sempre possibile estrarre il \textit{file
794 descriptor} da uno \textit{stream} ed eseguirvi sopra operazioni di basso
795 livello, o associare in un secondo tempo uno \textit{stream} ad un
796 \textit{file descriptor} per usare l'interfaccia più sofisticata.
798 In generale, se non necessitano specificatamente le funzionalità di basso
799 livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
800 portabilità, essendo questi ultimi definiti nello standard ANSI C;
801 l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
802 POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
804 \itindend{file~descriptor}
805 \itindend{file~stream}
807 \section{Gli standard}
808 \label{sec:intro_standard}
810 In questa sezione faremo una breve panoramica relativa ai vari standard che
811 nel tempo sono stati formalizzati da enti, associazioni, consorzi e
812 organizzazioni varie al riguardo ai sistemi operativi di tipo Unix o alle
813 caratteristiche che si sono stabilite come standard di fatto in quanto facenti
814 parte di alcune implementazioni molto diffuse come BSD o System V.
816 Ovviamente prenderemo in considerazione solo gli standard riguardanti
817 interfacce di programmazione e le altre caratteristiche di un sistema
818 unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
819 ed in particolare ci concentreremo sul come ed in che modo essi sono
820 supportati sia per quanto riguarda il kernel che la libreria standard del C,
821 con una particolare attenzione alla \acr{glibc}.
824 \subsection{Lo standard ANSI C}
825 \label{sec:intro_ansiC}
828 Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
829 Standard Institute} come prima standardizzazione del linguaggio C e per
830 questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
831 adottato dalla ISO (\textit{International Standard Organisation}) come
832 standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
833 anche sotto il nome di standard ISO C, o ISO C90. Nel 1999 è stata pubblicata
834 una revisione dello standard C89, che viene usualmente indicata come C99,
835 anche questa è stata ratificata dalla ISO con la sigla ISO/IEC 9899:1990, per
836 cui vi si fa riferimento anche come ISO C99.
838 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
839 sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
840 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
841 anche una libreria di funzioni che devono poter essere implementate su
842 qualunque sistema operativo.
844 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
845 di tipo Unix, GNU/Linux (per essere precisi la \acr{glibc}), come molti Unix
846 moderni, provvede la compatibilità con questo standard, fornendo le funzioni
847 di libreria da esso previste. Queste sono dichiarate in una serie di
848 \textit{header file} anch'essi forniti dalla \acr{glibc} (tratteremo
849 l'argomento in sez.~\ref{sec:proc_syscall}).
851 In realtà la \acr{glibc} ed i relativi \textit{header file} definiscono un
852 insieme di funzionalità in cui sono incluse come sottoinsieme anche quelle
853 previste dallo standard ANSI C. È possibile ottenere una conformità stretta
854 allo standard (scartando le funzionalità addizionali) usando il \cmd{gcc} con
855 l'opzione \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei
856 vari \textit{header file} soltanto le funzionalità previste dallo standard
857 ANSI C e a non usare le varie estensioni al linguaggio e al preprocessore da
862 \subsection{I tipi di dati primitivi}
863 \label{sec:intro_data_types}
865 Uno dei problemi di portabilità del codice più comune è quello dei tipi di
866 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
867 anche da una architettura ad un'altra (ad esempio passando da macchine con
868 processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
869 \index{tipo!elementare} \textit{tipi elementari} del linguaggio C (come
870 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
872 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
873 associati ad alcune variabili nei sistemi Unix, dando per scontata la
874 dimensione. Ad esempio la posizione corrente all'interno di un file è stata
875 associata ad un intero a 32 bit, mentre il numero di dispositivo è stato
876 associato ad un intero a 16 bit. Storicamente questi erano definiti
877 rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte che, con
878 l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi tipi si
879 sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad una
880 infinita serie di problemi di portabilità.
885 \begin{tabular}[c]{|l|l|}
887 \textbf{Tipo} & \textbf{Contenuto} \\
890 \typed{caddr\_t} & Core address.\\
891 \typed{clock\_t} & Contatore del \textit{process time} (vedi
892 sez.~\ref{sec:sys_cpu_times}.\\
893 \typed{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
894 \typed{gid\_t} & Identificatore di un gruppo (vedi
895 sez.~\ref{sec:proc_access_id}).\\
896 \typed{ino\_t} & Numero di \textit{inode}
897 (vedi sez.~\ref{sec:file_vfs_work}).\\
898 \typed{key\_t} & Chiave per il System V IPC (vedi
899 sez.~\ref{sec:ipc_sysv_generic}).\\
900 \typed{loff\_t} & Posizione corrente in un file.\\
901 \typed{mode\_t} & Attributi di un file.\\
902 \typed{nlink\_t} & Contatore dei collegamenti su un file.\\
903 \typed{off\_t} & Posizione corrente in un file.\\
904 \typed{pid\_t} & Identificatore di un processo (vedi
905 sez.~\ref{sec:proc_pid}).\\
906 \typed{rlim\_t} & Limite sulle risorse.\\
907 \typed{sigset\_t}& Insieme di segnali (vedi sez.~\ref{sec:sig_sigset}).\\
908 \typed{size\_t} & Dimensione di un oggetto.\\
909 \typed{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
910 \typed{ptrdiff\_t}& Differenza fra due puntatori.\\
911 \typed{time\_t} & Numero di secondi (in \textit{calendar time}, vedi
912 sez.~\ref{sec:sys_time}).\\
913 \typed{uid\_t} & Identificatore di un utente (vedi
914 sez.~\ref{sec:proc_access_id}).\\
917 \caption{Elenco dei tipi primitivi, definiti in \headfile{sys/types.h}.}
918 \label{tab:intro_primitive_types}
921 Per questo motivo tutte le funzioni di libreria di solito non fanno
922 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
923 serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
924 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'\textit{header file}
925 \headfiled{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
926 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
930 \subsection{Lo standard System V}
931 \label{sec:intro_sysv}
933 Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
934 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
935 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
936 Unix System V, e si fa rifermento a questa implementazione con la sigla SysV o
939 Negli anni successivi l'AT\&T proseguì lo sviluppo del sistema rilasciando
940 varie versioni con aggiunte e integrazioni, ed in particolare la
941 \textit{release 2} nel 1985, a cui si fa riferimento con il nome SVr2 e la
942 \textit{release 3} nel 1986 (denominata SVr3). Le interfacce di programmazione
943 di queste due versioni vennero descritte formalmente in due documenti
944 denominati \itindex{System~V~Interface~Definition~(SVID)} \textit{System V
945 Interface Definition} (o SVID), pertanto nel 1985 venne rilasciata la
946 specifica SVID 1 e nel 1986 la specifica SVID 2.
948 Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
949 versione di System V che provvedeva un'unificazione delle interfacce
950 comprendente anche Xenix e BSD, questa venne denominata \textit{release 4} o
951 SVr4. Anche le relative interfacce vennero descritte in un documento dal
952 titolo \textit{System V Interface Description}, venendo a costituire lo
953 standard SVID 3, che viene considerato la specifica finale di System V, ed a
954 cui spesso si fa riferimento semplicemente con SVID. Anche SVID costituisce un
955 sovrainsieme delle interfacce definite dallo standard POSIX.
957 Nel 1992 venne rilasciata una seconda versione del sistema, la SVr4.2; l'anno
958 successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
959 Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
960 al consorzio X/Open. L'ultima versione di System V fu la SVr4.2MP rilasciata
961 nel dicembre 1993. Infine nel 1995 è stata rilasciata da SCO, che aveva
962 acquisito alcuni diritti sul codice di System V, una ulteriore versione delle
963 \textit{System V Interface Description}, che va sotto la denominazione di SVID
966 Linux e la \acr{glibc} implementano le principali funzionalità richieste dalle
967 specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
968 compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
969 includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
970 presenti neanche in System V) sono state tralasciate.
972 Le funzionalità implementate sono principalmente il meccanismo di
973 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
974 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
975 \funcm{hsearch} e \funcm{drand48}, \funcm{fmtmsg} e svariate funzioni
979 \subsection{Lo ``\textsl{standard}'' BSD}
980 \label{sec:intro_bsd}
982 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
983 di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
984 mondo Unix. L'università di Berkeley proseguì nello sviluppo della base di
985 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
986 versioni allora disponibili, fino ad arrivare al rilascio di una versione
987 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
990 Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
991 dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
992 serie di estensioni e interfacce di grandissima rilevanza, come i collegamenti
993 simbolici, la funzione \code{select} ed i socket di rete. Per questo motivo si
994 fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni
995 dello Unix di Berkeley con una apposita sigla.
997 Nel 1983, con il rilascio della versione 4.2 di BSD, venne definita una
998 implementazione delle funzioni di interfaccia a cui si fa riferimento con la
999 sigla 4.2BSD. Per fare riferimento alle precedenti versioni si usano poi le
1000 sigle 3BSD e 4BSD (per le due versioni pubblicate nel 1980), e 4.1BSD per
1001 quella pubblicata nel 1981.
1003 Le varie estensioni ideate a Berkeley sono state via via aggiunte al sistema
1004 nelle varie versioni succedutesi negli anni, che vanno sotto il nome di
1005 4.3BSD, per la versione rilasciata nel 1986 e 4.4BSD, per la versione
1006 rilasciata nel 1993, che costituisce l'ultima release ufficiale
1007 dell'università di Berkeley. Si tenga presente che molte di queste interfacce
1008 sono presenti in derivati commerciali di BSD come SunOS. Il kernel Linux e la
1009 \acr{glibc} forniscono tutte queste estensioni che sono state in gran parte
1010 incorporate negli standard successivi.
1013 \subsection{Gli standard IEEE -- POSIX}
1014 \label{sec:intro_posix}
1016 Lo standard ufficiale creato da un organismo indipendente più attinente alle
1017 interfacce di un sistema unix-like nel suo complesso (e che concerne sia il
1018 kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
1019 origine dallo standard ANSI C, che contiene come sottoinsieme, prevedendo
1020 ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
1023 In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
1024 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
1025 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
1026 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
1027 che ne produsse una prima versione, nota come \textsl{IEEE 1003.1-1988},
1028 mirante a standardizzare l'interfaccia con il sistema operativo.
1030 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
1031 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
1032 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
1033 \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i socket (1003.1g) e
1034 vari altri. In tab.~\ref{tab:intro_posix_std} è riportata una classificazione
1035 sommaria dei principali documenti prodotti, e di come sono identificati fra
1036 IEEE ed ISO; si tenga conto inoltre che molto spesso si usa l'estensione IEEE
1037 anche come aggiunta al nome POSIX; ad esempio è più comune parlare di POSIX.4
1040 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
1041 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
1042 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
1043 denominazioni usate diventa particolarmente faticoso.
1048 \begin{tabular}[c]{|l|l|l|l|}
1050 \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
1053 POSIX.1 & 1003.1 & 9945-1& Interfacce di base. \\
1054 POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1. \\
1055 POSIX.2 & 1003.2 & 9945-2& Comandi. \\
1056 POSIX.3 & 2003 &TR13210& Metodi di test. \\
1057 POSIX.4 & 1003.1b & --- & Estensioni real-time. \\
1058 POSIX.4a& 1003.1c & --- & Thread. \\
1059 POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time. \\
1060 POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA. \\
1061 POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza. \\
1062 POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete. \\
1063 POSIX.9 & 1003.9 & --- & Interfaccia per il Fortran-77. \\
1064 POSIX.12& 1003.1g& 9945-1& Socket. \\
1067 \caption{Elenco dei vari standard POSIX e relative denominazioni.}
1068 \label{tab:intro_posix_std}
1071 Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
1072 definiscono comunque un'interfaccia di programmazione generica e non fanno
1073 riferimento ad una implementazione specifica (ad esempio esiste
1074 un'implementazione di POSIX.1 anche sotto Windows NT).
1076 Linux e la \acr{glibc} implementano tutte le funzioni definite nello standard
1077 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
1078 funzioni di \textit{pattern matching} e per la manipolazione delle
1079 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
1080 sistema e che sono definite nello standard POSIX.2.
1082 Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
1083 ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
1084 \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
1085 quanto riguarda i segnali e lo scheduling real-time
1086 (sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
1087 tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
1088 asincrono (sez.~\ref{sec:file_asyncronous_io}).
1090 Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la
1091 versione più nota, cui gran parte delle implementazioni fanno riferimento, e
1092 che costituisce una base per molti altri tentativi di standardizzazione, è
1093 stata rilasciata anche come standard internazionale con la sigla
1094 \textsl{ISO/IEC 9945-1:1996} ed include i precedenti POSIX.1b e POSIX.1c. In
1095 genere si fa riferimento ad essa come POSIX.1-1996.
1097 Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
1098 SUSv3 (vedi sez.~\ref{sec:intro_xopen}) in un unico documento, redatto sotto
1099 gli auspici del cosiddetto gruppo Austin che va sotto il nome di POSIX.1-2001.
1100 Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
1101 presenti solo le interfacce di base, e quello XSI che richiede la presenza di
1102 una serie di estensioni opzionali per lo standard POSIX, riprese da SUSv3.
1103 Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
1104 nella definizione delle interfacce.
1106 A questo standard sono stati aggiunti due documenti di correzione e
1107 perfezionamento denominati \textit{Technical Corrigenda}, il TC1 del 2003 ed
1108 il TC2 del 2004, e talvolta si fa riferimento agli stessi con le sigle
1109 POSIX.1-2003 e POSIX.1-2004.
1111 Una ulteriore revisione degli standard POSIX e SUS è stata completata e
1112 ratificata nel 2008, cosa che ha portato al rilascio di una nuova versione
1113 sotto il nome di POSIX.1-2008 (e SUSv4), con l'incorporazione di alcune nuove
1114 interfacce, la obsolescenza di altre, la trasformazione da opzionali a
1115 richieste di alcune specifiche di base, oltre alle solite precisazioni ed
1116 aggiornamenti. Anche in questo caso è prevista la suddivisione in una
1117 conformità di base, e delle interfacce aggiuntive. Una ulteriore revisione è
1118 stata pubblicata nel 2017 come POSIX.1-2017.
1120 Le procedure di aggiornamento dello standard POSIX prevedono comunque un
1121 percorso continuo, che prevede la possibilità di introduzione di nuove
1122 interfacce e la definizione di precisazioni ed aggiornamenti, per questo in
1123 futuro verranno rilasciate nuove versioni. Alla stesura di queste note
1124 l'ultima revisione approvata resta POSIX.1-2017, uno stato della situazione
1125 corrente del supporto degli standard è allegato alla documentazione della
1126 \acr{glibc} e si può ottenere con il comando \texttt{man standards}.
1129 \subsection{Gli standard X/Open -- Opengroup -- Unix}
1130 \label{sec:intro_xopen}
1132 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
1133 Unix per giungere ad un'armonizzazione delle varie implementazioni. Per far
1134 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
1135 nome di \textit{X/Open Portability Guide} a cui di norma si fa riferimento con
1136 l'abbreviazione XPG$n$, con $n$ che indica la versione.
1138 Nel 1989 il consorzio produsse una terza versione di questa guida
1139 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
1140 contenente una dettagliata standardizzazione dell'interfaccia di sistema di
1141 Unix, che venne presa come riferimento da vari produttori. Questo standard,
1142 detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
1143 POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
1144 delle API (sigla che sta per \textit{Application Programmable Interface}, in
1145 italiano interfaccia di programmazione) per l'interfaccia grafica (X11).
1147 Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
1148 Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{X
1149 Transport Interface}) mirante a soppiantare (senza molto successo)
1150 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
1151 rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
1152 interfacce, intestazioni e comandi definiti) ma si fa riferimento ad essa
1155 Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
1156 aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
1157 specifiche sotto il nome di \textit{Single UNIX Specification} o SUS, l'ultima
1158 versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
1159 Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
1162 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
1163 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
1164 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
1165 raccoglie produttori, utenti industriali, entità accademiche e governative.
1166 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
1167 il lavoro di standardizzazione delle varie implementazioni, rilasciando
1168 periodicamente nuove specifiche e strumenti per la verifica della conformità
1171 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
1172 Specification}, nota con la sigla SUSv2, in questa versione le interfacce
1173 specificate salgono a 1434, e addirittura a 3030 se si considerano le stazioni
1174 di lavoro grafiche, per le quali sono inserite pure le interfacce usate da CDE
1175 che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
1176 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. Un
1177 altro nome alternativo di queste specifiche, date le origini, è XPG5.
1179 Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
1180 effettuato uno sforzo di sintesi in cui sono state comprese, nella parte di
1181 interfacce estese, anche le interfacce definite nelle \textit{Single UNIX
1182 Specification}, pertanto si può fare riferimento a detto standard, quando
1183 comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del
1184 marchio UNIX 03 se conformi ad esso.
1186 Infine, come avvenuto per POSIX.1-2001, anche con la successiva revisione
1187 dello standard POSIX.1 (la POSIX.1-2008) è stato stabilito che la conformità
1188 completa a tutte quelle che sono le nuove estensioni XSI previste
1189 dall'aggiornamento vada a definire la quarta versione delle \textit{Single
1190 UNIX Specification}, chiamata appunto SUSv4.
1193 \subsection{Il controllo di aderenza agli standard}
1194 \label{sec:intro_gcc_glibc_std}
1196 In Linux, se si usa la \acr{glibc}, la conformità agli standard appena
1197 descritti può essere richiesta sia attraverso l'uso di alcune opzioni del
1198 compilatore (il \texttt{gcc}) che con la definizione di opportune costanti
1199 prima dell'inclusione dei file di intestazione (gli \textit{header file}, vedi
1200 sez.~\ref{sec:proc_syscall}) in cui le varie funzioni di libreria vengono
1203 Ad esempio se si vuole che i programmi seguano una stretta attinenza allo
1204 standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
1205 potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
1206 standard ISO per il C. Il \texttt{gcc} possiede inoltre una specifica opzione
1207 per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
1208 dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
1209 (vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
1210 allo standard C99 o \texttt{c11} per indicare la conformità allo standard C11
1211 (revisione del 2011).\footnote{esistono anche le possibilità di usare i valori
1212 \texttt{gnu89}, che indica l'uso delle estensioni GNU al C89, riprese poi
1213 dal C99, \texttt{gnu99} che indica il dialetto GNU del C99, o \texttt{gnu11}
1214 che indica le estensioni GNU al C11, lo standard adottato di default dipende
1215 dalla versione del \texttt{gcc}, ed all'agosto 2018 con la versione 8.2 è
1218 Per attivare le varie opzioni di controllo di aderenza agli standard è poi
1219 possibile definire delle macro di preprocessore che controllano le
1220 funzionalità che la \acr{glibc} può mettere a disposizione:\footnote{le macro
1221 sono definite nel file di dichiarazione \file{<features.h>}, ma non è
1222 necessario includerlo nei propri programmi in quanto viene automaticamente
1223 incluso da tutti gli altri file di dichiarazione che utilizzano le macro in
1224 esso definite; si tenga conto inoltre che il file definisce anche delle
1225 ulteriori macro interne, in genere con un doppio prefisso di \texttt{\_},
1226 che non devono assolutamente mai essere usate direttamente. } questo può
1227 essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
1228 norma farlo inserendo gli opportuni \code{\#define} prima della inclusione dei
1229 propri \textit{header file} (vedi sez.~\ref{sec:proc_syscall}).
1231 Le macro disponibili per controllare l'aderenza ai vari standard messi a
1232 disposizione della \acr{glibc}, che rendono disponibili soltanto le funzioni
1233 in essi definite, sono illustrate nel seguente elenco:
1234 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
1235 \item[\macrod{\_\_STRICT\_ANSI\_\_}] richiede l'aderenza stretta allo standard
1236 C ISO; viene automaticamente predefinita qualora si invochi il \texttt{gcc}
1237 con le opzione \texttt{-ansi} o \texttt{-std=c99}.
1239 \item[\macrod{\_POSIX\_SOURCE}] definendo questa macro (considerata obsoleta)
1240 si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
1241 versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
1242 standard ISO C. Se viene anche definita con un intero positivo la macro
1243 \macro{\_POSIX\_C\_SOURCE} lo stato di questa non viene preso in
1246 \item[\macrod{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
1247 positivo si controlla quale livello delle funzionalità specificate da POSIX
1248 viene messa a disposizione; più alto è il valore maggiori sono le
1251 \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
1252 specificate nella edizione del 1990 (IEEE Standard 1003.1-1990);
1253 \item valori maggiori o uguali a ``\texttt{2}'' rendono disponibili le
1254 funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
1255 1992 (IEEE Standard 1003.2-1992),
1256 \item un valore maggiore o uguale a ``\texttt{199309L}'' rende disponibili
1257 le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
1258 del 1993 (IEEE Standard 1003.1b-1993);
1259 \item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
1260 le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
1261 del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
1262 dello standard POSIX.1c per i \textit{thread};
1263 \item a partire dalla versione 2.3.3 della \acr{glibc} un valore maggiore o
1264 uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
1265 previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
1266 \item a partire dalla versione 2.10 della \acr{glibc} un valore maggiore o
1267 uguale a ``\texttt{200809L}'' rende disponibili le funzionalità di base
1268 previste dallo standard POSIX.1-2008, escludendo le estensioni XSI;
1269 \item in futuro valori superiori potranno abilitare ulteriori estensioni.
1272 \item[\macrod{\_BSD\_SOURCE}] definendo questa macro si rendono disponibili le
1273 funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
1274 ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
1275 però in conflitto con le corrispondenti definite nello standard POSIX.1, in
1276 questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
1277 la precedenza rispetto a POSIX.
1279 A causa della natura dei conflitti con POSIX per ottenere una piena
1280 compatibilità con BSD4.3 può essere necessario anche usare una libreria di
1281 compatibilità, dato che alcune funzioni sono definite in modo diverso. In
1282 questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
1283 compilatore per indicargli di utilizzare le versioni nella libreria di
1284 compatibilità prima di quelle normali.
1286 Si tenga inoltre presente che la preferenza verso le versioni delle funzioni
1287 usate da BSD viene mantenuta soltanto se nessuna delle ulteriori macro di
1288 specificazione di standard successivi (vale a dire una fra
1289 \macro{\_POSIX\_C\_SOURCE}, \macro{\_POSIX\_SOURCE}, \macro{\_SVID\_SOURCE},
1290 \macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o
1291 \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
1292 hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
1293 definito una di queste macro, l'effetto sarà quello di dare la precedenza
1294 alle funzioni in forma BSD. Questa macro, essendo ricompresa in
1295 \macro{\_DEFAULT\_SOURCE} che è definita di default, è stata deprecata a
1296 partire dalla \acr{glibc} 2.20.
1298 \item[\macrod{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
1299 funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
1300 standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
1301 precedenza. Questa macro, essendo ricompresa in \macro{\_DEFAULT\_SOURCE}
1302 che è definita di default, è stata deprecata a partire dalla \acr{glibc}
1305 \item[\macrod{\_DEFAULT\_SOURCE}] questa macro abilita le definizioni
1306 considerate il \textit{default}, comprese quelle richieste dallo standard
1307 POSIX.1-2008, ed è sostanzialmente equivalente all'insieme di
1308 \macro{\_SVID\_SOURCE}, \macro{\_BSD\_SOURCE} e
1309 \macro{\_POSIX\_C\_SOURCE}. Essendo predefinita non è necessario usarla a
1310 meno di non aver richiesto delle definizioni più restrittive sia con altre
1311 macro che con i flag del compilatore, nel qual caso abilita le funzioni che
1312 altrimenti sarebbero disabilitate. Questa macro è stata introdotta a partire
1313 dalla \acr{glibc} 2.19 e consente di deprecare \macro{\_SVID\_SOURCE} e
1314 \macro{\_BSD\_SOURCE}.
1316 \item[\macrod{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
1317 le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
1318 queste sono un sovrainsieme di quelle definite negli standard POSIX.1 e
1319 POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che
1320 \macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse
1321 anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
1322 estensioni a secondo dei seguenti valori:
1324 \item la definizione della macro ad un valore qualunque attiva le
1325 funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
1326 \item un valore di ``\texttt{500}'' o superiore rende disponibili anche le
1327 funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
1328 \item a partire dalla versione 2.2 della \acr{glibc} un valore uguale a
1329 ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
1330 introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
1332 \item a partire dalla versione 2.10 della \acr{glibc} un valore uguale a
1333 ``\texttt{700}'' o superiore rende disponibili anche le funzionalità
1334 introdotte con SUSv4, corrispondenti allo standard POSIX.1-2008 più le
1338 \item[\macrod{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono
1339 disponibili le ulteriori funzionalità necessarie la conformità al
1340 rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard
1341 Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene
1342 definita implicitamente tutte le volte che si imposta
1343 \macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale a 500.
1345 \item[\macrod{\_ISOC99\_SOURCE}] definendo questa macro si rendono disponibili
1346 le funzionalità previste per la revisione delle librerie standard del C
1347 introdotte con lo standard ISO C99. La macro è definita a partire dalla
1348 versione 2.1.3 della \acr{glibc}.
1350 Le versioni precedenti la serie 2.1.x riconoscevano le stesse estensioni con
1351 la macro \macro{\_ISOC9X\_SOURCE}, dato che lo standard non era stato
1352 finalizzato, ma la \acr{glibc} aveva già un'implementazione completa che
1353 poteva essere attivata definendo questa macro. Benché questa sia obsoleta
1354 viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per
1357 \item[\macrod{\_ISOC11\_SOURCE}] definendo questa macro si rendono disponibili
1358 le funzionalità previste per la revisione delle librerie standard del C
1359 introdotte con lo standard ISO C11, e abilita anche quelle previste dagli
1360 standard C99 e C95. La macro è definita a partire dalla versione 2.16 della
1363 \item[\macrod{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili
1364 tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
1365 specifiche presenti solo nella \acr{glibc} ed in Linux. Gli standard coperti
1366 sono: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, SUS.
1368 L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
1369 delle macro: \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
1370 \macro{\_POSIX\_SOURCE}, \macro{\_ISOC99\_SOURCE}, e inoltre di
1371 \macro{\_POSIX\_C\_SOURCE} con valore ``\texttt{200112L}'' (o
1372 ``\texttt{199506L}'' per le versioni della \acr{glibc} precedenti la 2.5),
1373 \macro{\_XOPEN\_SOURCE\_EXTENDED} e \macro{\_XOPEN\_SOURCE} con valore 600
1374 (o 500 per le versioni della \acr{glibc} precedenti la 2.2); oltre a queste
1375 vengono pure attivate le ulteriori due macro \macro{\_ATFILE\_SOURCE} e
1376 \macrod{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste
1377 esclusivamente dalla \acr{glibc}.
1381 Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
1382 comunque delle estensioni e funzionalità specifiche, non presenti in altri
1383 standard e lo stesso vale per la \acr{glibc}, che definisce anche delle
1384 ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità deve
1385 essere evitato se si ha a cuore la portabilità, ma qualora questo non sia un
1386 requisito esse possono rivelarsi molto utili.
1388 Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
1389 essere rese esplicitamente disponibili tramite la definizione di opportune
1390 macro di preprocessore, alcune di queste vengono attivate con la definizione
1391 di \macro{\_GNU\_SOURCE}, mentre altre devono essere attivate esplicitamente,
1392 inoltre alcune estensioni possono essere attivate indipendentemente tramite
1393 una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
1395 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
1397 \item[\macrod{\_LARGEFILE\_SOURCE}] definendo questa macro si rendono
1398 disponibili alcune funzioni che consentono di superare una inconsistenza
1399 presente negli standard con i file di grandi dimensioni, ed in particolare
1400 definire le due funzioni \func{fseeko} e \func{ftello} che al contrario
1401 delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato
1402 specifico \type{off\_t} (vedi sez.~\ref{sec:file_io}).
1404 \item[\macrod{\_LARGEFILE64\_SOURCE}] definendo questa macro si rendono
1405 disponibili le funzioni di una interfaccia alternativa al supporto di valori
1406 a 64 bit nelle funzioni di gestione dei file (non supportati in certi
1407 sistemi), caratterizzate dal suffisso \texttt{64} aggiunto ai vari nomi di
1408 tipi di dato e funzioni (come \typed{off64\_t} al posto di \type{off\_t} o
1409 \funcm{lseek64} al posto di \func{lseek}).
1411 Le funzioni di questa interfaccia alternativa sono state proposte come una
1412 estensione ad uso di transizione per le \textit{Single UNIX Specification},
1413 per consentire la gestione di file di grandi dimensioni anche nei sistemi a
1414 32 bit, in cui la dimensione massima, espressa con un intero, non poteva
1415 superare i 2Gb. Nei nuovi programmi queste funzioni devono essere evitate,
1416 a favore dell'uso macro \macro{\_FILE\_OFFSET\_BITS}, che definita al valore
1417 di \texttt{64} consente di usare in maniera trasparente le funzioni
1418 dell'interfaccia classica.
1420 \item[\macrod{\_FILE\_OFFSET\_BITS}] la definizione di questa macro al valore
1421 di \texttt{64} consente di attivare la conversione automatica di tutti i
1422 riferimenti a dati e funzioni a 32 bit nelle funzioni di interfaccia ai file
1423 con le equivalenti a 64 bit, senza dover utilizzare esplicitamente
1424 l'interfaccia alternativa appena illustrata. In questo modo diventa
1425 possibile usare le ordinarie funzioni per effettuare operazioni a 64 bit sui
1426 file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
1427 dopo averla definita, e saranno usate in modo trasparente le funzioni a 64
1430 Se la macro non è definita o è definita con valore \texttt{32} questo
1431 comportamento viene disabilitato, e sui sistemi a 32 bit verranno usate le
1432 ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
1433 dimensioni. Su sistemi a 64 bit invece, dove il problema non sussiste, la
1434 macro non ha nessun effetto.
1436 \item[\macrod{\_ATFILE\_SOURCE}] definendo questa macro si rendono disponibili
1437 le estensioni delle funzioni di creazione, accesso e modifica di file e
1438 directory che risolvono i problemi di sicurezza insiti nell'uso di
1439 \textit{pathname} relativi con programmi \textit{multi-thread} illustrate in
1440 sez.~\ref{sec:file_openat}. Dalla \acr{glibc} 2.10 questa macro viene
1441 definita implicitamente se si definisce \macro{\_POSIX\_C\_SOURCE} ad un
1442 valore maggiore o uguale di ``\texttt{200809L}''.
1444 \item[\macrod{\_REENTRANT}] definendo questa macro, o la equivalente
1445 \macrod{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili
1446 le versioni rientranti (vedi sez.~\ref{sec:proc_reentrant}) di alcune
1447 funzioni, necessarie quando si usano i \textit{thread}. Alcune di queste
1448 funzioni sono anche previste nello standard POSIX.1c, ma ve ne sono altre
1449 che sono disponibili soltanto su alcuni sistemi, o specifiche della
1450 \acr{glibc}, e possono essere utilizzate una volta definita la macro. Oggi
1451 la macro è obsoleta, già dalla \acr{glibc} 2.3 le funzioni erano già
1452 completamente rientranti e dalla \acr{glibc} 2.25 la macro è equivalente ad
1453 definire \macro{\_POSIX\_C\_SOURCE} con un valore di ``\texttt{199606L}''
1454 mentre se una qualunque delle altre macro che richiede un valore di
1455 conformità più alto è definita, la sua definizione non ha alcun effetto.
1457 \item[\macrod{\_FORTIFY\_SOURCE}] definendo questa macro viene abilitata
1458 l'inserimento di alcuni controlli per alcune funzioni di allocazione e
1459 manipolazione di memoria e stringhe che consentono di rilevare
1460 automaticamente alcuni errori di \textit{buffer overflow} nell'uso delle
1461 stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
1462 della \acr{glibc} e richiede anche il supporto da parte del compilatore, che
1463 è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
1465 Le funzioni di libreria che vengono messe sotto controllo quando questa
1466 funzionalità viene attivata sono, al momento della stesura di queste note,
1467 le seguenti: \funcm{memcpy}, \funcm{mempcpy}, \funcm{memmove},
1468 \funcm{memset}, \funcm{stpcpy}, \funcm{strcpy}, \funcm{strncpy},
1469 \funcm{strcat}, \funcm{strncat}, \func{sprintf}, \func{snprintf},
1470 \func{vsprintf}, \func{vsnprintf}, e \func{gets}.
1472 La macro prevede due valori, con \texttt{1} vengono eseguiti dei controlli
1473 di base che non cambiano il comportamento dei programmi se si richiede una
1474 ottimizzazione di livello uno o superiore,\footnote{vale a dire se si usa
1475 l'opzione \texttt{-O1} o superiore del \texttt{gcc}.} mentre con il
1476 valore \texttt{2} vengono aggiunti maggiori controlli. Dato che alcuni dei
1477 controlli vengono effettuati in fase di compilazione l'uso di questa macro
1478 richiede anche la collaborazione del compilatore, disponibile dalla
1479 versione 4.0 del \texttt{gcc}.
1483 Se non è stata specificata esplicitamente nessuna di queste macro il default
1484 assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
1485 \macro{\_POSIX\_SOURCE} e, con le versioni della \acr{glibc} più recenti, che
1486 la macro \macro{\_POSIX\_C\_SOURCE} abbia il valore ``\texttt{200809L}'', per
1487 versioni precedenti della \acr{glibc} il valore assegnato a
1488 \macro{\_POSIX\_C\_SOURCE} era di ``\texttt{200112L}'' prima delle 2.10, di
1489 ``\texttt{199506L}'' prima delle 2.4, di ``\texttt{199506L}'' prima delle
1490 2.1. Si ricordi infine che perché queste macro abbiano effetto devono essere
1491 sempre definite prima dell'inclusione dei file di dichiarazione.
1494 % vedi anche man feature_test_macros
1496 % TODO: forse può essere interessante trattare i tunables delle glibc, vedi:
1497 % https://siddhesh.in/posts/the-story-of-tunables.html e
1498 % https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=README.tunables;h=0e9b0d7a470aabc2344ad997fca03c7663de0419;hb=HEAD
1501 % LocalWords: like kernel multitasking scheduler preemptive sez swap is cap VM
1502 % LocalWords: everything bootstrap init shell Windows Foundation system call
1503 % LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods
1504 % LocalWords: Pluggable Autentication group supplementary Name Service Switch
1505 % LocalWords: LDAP identifier uid gid superuser root if BSD SVr dall' American
1506 % LocalWords: National Institute International Organisation IEC header tab gcc
1507 % LocalWords: assert ctype dirent errno fcntl limits malloc setjmp signal utmp
1508 % LocalWords: stdarg stdio stdlib string times unistd library int short caddr
1509 % LocalWords: address clock dev ino inode key IPC loff nlink off pid rlim size
1510 % LocalWords: sigset ssize ptrdiff sys IEEE Richard Portable of TR filesystem
1511 % LocalWords: Operating Interface dell'IEEE Electrical and Electronics thread
1512 % LocalWords: Engeneers Socket NT matching regular expression scheduling l'I
1513 % LocalWords: XPG Portability Issue Application Programmable XTI Transport AT
1514 % LocalWords: socket Spec Novell Specification SUSv CDE Motif Berkley select
1515 % LocalWords: SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
1516 % LocalWords: drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
1517 % LocalWords: LARGEFILE Support LFS dell' black rectangle node fill cpu draw
1518 % LocalWords: ellipse mem anchor west proc SysV SV Definition SCO Austin XSI
1519 % LocalWords: Technical TC SUS Opengroup features STRICT std ATFILE fseeko VFS
1520 % LocalWords: ftello fseek ftell lseek FORTIFY REENTRANT SAFE overflow memcpy
1521 % LocalWords: mempcpy memmove memset stpcpy strcpy strncpy strcat strncat gets
1522 % LocalWords: sprintf snprintf vsprintf vsnprintf syscall number calendar BITS
1523 % LocalWords: pathname Google Android standards device Virtual bootloader path
1524 % LocalWords: filename fifo name components resolution chroot parent symbolic
1525 % LocalWords: char block VMS raw access MacOS LF CR dos HFS Mac attributes
1526 % LocalWords: Executable Linkable Format Tool magic descriptor stream locking
1527 % LocalWords: process mount point ELF
1529 %%% Local Variables:
1531 %%% TeX-master: "gapil"