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