3 %% Copyright (C) 2000-2015 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 \textit{system call} fornita dal kernel viene associata
246 ad 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. In seguito faremo riferimento alle
251 funzioni di questa libreria che si interfacciano alle \textit{system call}
252 come ``\textsl{funzioni di sistema}''.
254 Questa libreria infatti, oltre alle interfacce delle \textit{system call},
255 contiene anche tutta una serie di ulteriori funzioni di utilità che vengono
256 comunemente usate nella programmazione e sono definite nei vari standard che
257 documentano le interfacce di programmazione di un sistema unix-like. Questo
258 concetto è importante da tener presente perché programmare in Linux significa
259 anche essere in grado di usare le funzioni fornite dalla \textsl{Libreria
260 Standard del C}, in quanto né il kernel, né il linguaggio C implementano
261 direttamente operazioni ordinarie come l'allocazione dinamica della memoria,
262 l'input/output bufferizzato sui file o la manipolazione delle stringhe, la
263 matematica in virgola mobile, che sono comunemente usate da qualunque
266 Tutto ciò mette nuovamente in evidenza il fatto che nella stragrande
267 maggioranza dei casi si dovrebbe usare il nome GNU/Linux in quanto una parte
268 essenziale del sistema, senza la quale niente funzionerebbe, è appunto la
269 \textit{GNU Standard C Library} (a cui faremo da qui in avanti riferimento
270 come \acr{glibc}), ovvero la Libreria Standard del C realizzata dalla Free
271 Software Foundation, nella quale sono state implementate tutte le funzioni
272 essenziali definite negli standard POSIX e ANSI C (e molte altre), che vengono
273 utilizzate da qualunque programma.
275 Si tenga comunque presente che questo non è sempre vero, dato che esistono
276 implementazioni alternative della Libreria Standard del C, come la
277 \textit{libc5} o la \textit{uClib}, che non derivano dal progetto GNU. La
278 \textit{libc5}, che era usata con le prime versioni del kernel Linux, è oggi
279 ormai completamente soppiantata dalla \acr{glibc}. La \textit{uClib} invece,
280 pur non essendo completa come la \acr{glibc}, resta molto diffusa nel mondo
281 dei dispositivi \textit{embedded} per le sue dimensioni estremamente ridotte,
282 e soprattutto per la possibilità di togliere le parti non necessarie. Pertanto
283 costituisce un valido rimpiazzo della \acr{glibc} in tutti quei sistemi
284 specializzati che richiedono una minima occupazione di memoria. Infine per lo
285 sviluppo del sistema Android è stata realizzata da Google un'altra Libreria
286 Standard del C, utilizzata principalmente per evitare l'uso della \acr{glibc}.
288 Tradizionalmente le funzioni specifiche della Libreria Standard del C sono
289 riportate nella terza sezione del \textsl{Manuale di Programmazione di Unix}
290 (cioè accessibili con il comando \cmd{man 3 <nome>}) e come accennato non sono
291 direttamente associate ad una \textit{system call} anche se, ad esempio per la
292 gestione dei file o della allocazione dinamica della memoria, possono farne
293 uso nella loro implementazione. Nonostante questa questa distinzione,
294 fondamentale per capire il funzionamento del sistema, l'uso da parte dei
295 programmi di una di queste funzioni resta lo stesso, sia che si tratti di una
296 funzione interna della libreria che di una \textit{system call}.
299 \subsection{Un sistema multiutente}
300 \label{sec:intro_multiuser}
302 Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
303 multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
304 questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
305 sistemi operativi monoutente, e che occorre tenere presenti. In questa sezione
306 parleremo brevemente soltanto dei meccanismi di sicurezza tradizionali di un
307 sistema unix-like, oggi molti di questi sono stati notevolmente estesi
308 rispetto al modello tradizionale, ma per il momento ignoreremo queste
311 Il concetto base è quello di utente (\textit{user}) del sistema, le cui
312 capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
313 Sono così previsti una serie di meccanismi per identificare i singoli utenti
314 ed una serie di permessi e protezioni per impedire che utenti diversi possano
315 danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono
316 realizzati dal kernel stesso ed attengono alle operazioni più varie, e
317 torneremo su di essi in dettaglio più avanti.
319 Normalmente l'utente è identificato da un nome (il cosiddetto
320 \textit{username}), che ad esempio è quello che viene richiesto all'ingresso
321 nel sistema dalla procedura di \textit{login} (torneremo su questo in
322 sez.~\ref{sec:sess_login}). Questa procedura si incarica di verificare
323 l'identità dell'utente, in genere attraverso la richiesta di una parola
324 d'ordine (la \textit{password}), anche se sono possibili meccanismi
325 diversi.\footnote{ad esempio usando la libreria PAM (\textit{Pluggable
326 Autentication Methods}) è possibile astrarre completamente dai meccanismi
327 di autenticazione e sostituire ad esempio l'uso delle password con
328 meccanismi di identificazione biometrica, per un approfondimento
329 dell'argomento si rimanda alla sez.~4.3 di \cite{AGL}.} Eseguita la
330 procedura di riconoscimento in genere il sistema manda in esecuzione un
331 programma di interfaccia (che può essere la \textit{shell} su terminale o
332 un'interfaccia grafica) che mette a disposizione dell'utente un meccanismo con
333 cui questo può impartire comandi o eseguire altri programmi.
335 Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
336 \textit{default group}), ma può essere associato ad altri gruppi (i
337 \textit{supplementary group}), questo permette di gestire i permessi di
338 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
339 definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
341 L'utente e il gruppo sono identificati dal kernel un identificativo numerico,
342 la cui corrispondenza ad un nome espresso in caratteri è inserita nei due file
343 \conffile{/etc/passwd} e \conffile{/etc/group}.\footnote{in realtà negli
344 sistemi più moderni, come vedremo in sez.~\ref{sec:sys_user_group} queste
345 informazioni possono essere mantenute, con l'uso del
346 \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch}, su varie
347 tipologie di supporti, compresi server centralizzati come LDAP.} Questi
348 identificativi sono l'\textit{user identifier}, detto in breve
349 \textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il \textit{group
350 identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
351 \ids{GID}, torneremo in dettaglio su questo argomento in
352 sez.~\ref{sec:proc_perms}. Il kernel conosce ed utilizza soltanto questi
353 valori numerici, i nomi ad essi associati sono interamente gestiti in
354 \textit{user space} con opportune funzioni di libreria, torneremo su questo
355 argomento in sez.~\ref{sec:sys_user_group}.
357 Grazie a questi identificativi il sistema è in grado di tenere traccia
358 dell'utente a cui appartiene ciascun processo ed impedire ad altri utenti di
359 interferire con quest'ultimo. Inoltre con questo sistema viene anche
360 garantita una forma base di sicurezza interna in quanto anche l'accesso ai
361 file (vedi sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo
364 Infine in ogni sistema unix-like è presente uno speciale utente privilegiato,
365 il cosiddetto \textit{superuser}, il cui username è di norma \textit{root}, ed
366 il cui \ids{UID} è zero. Esso identifica l'amministratore del sistema, che
367 deve essere in grado di fare qualunque operazione; per l'utente \textit{root}
368 infatti i meccanismi di controllo cui si è accennato in precedenza sono
369 disattivati.\footnote{i controlli infatti vengono eseguiti da uno pseudo-codice
370 del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
374 % \section{L'architettura della gestione dei file}
375 % \label{sec:file_arch_func}
377 \section{L'architettura di file e directory}
378 \label{sec:intro_file_dir}
380 Come accennato in sez.~\ref{sec:intro_base_concept} uno dei concetti
381 fondamentali dell'architettura di un sistema Unix è il cosiddetto
382 \textit{everything is a file} (\textsl{tutto è un file}), cioè il fatto che
383 l'accesso ai vari dispositivi di input/output del computer viene effettuato
384 attraverso un'interfaccia astratta che tratta le periferiche allo stesso modo
385 dei normali file di dati.
387 In questa sezione forniremo una descrizione a grandi linee dell'architettura
388 della gestione dei file in Linux, partendo da una introduzione ai concetti di
389 base, per poi illustrare la struttura dell'albero dei file ed il significato
390 dei tipi di file, concludendo con una panoramica sulle caratteristiche
391 principali delle due interfacce con cui i processi possono effettuare l'I/O su
395 \subsection{Una panoramica generale}
396 \label{sec:file_arch_overview}
398 Per poter accedere ai file, il kernel deve mettere a disposizione dei
399 programmi delle opportune \textit{system call} che consentano di leggere e
400 scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
401 il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
402 che consenta di operare sui file, sia che questi corrispondano ai normali file
403 di dati, o ai cosiddetti \index{file!speciali} ``\textsl{file speciali}'',
404 come \index{file!di~dispositivo} i file di dispositivo (o \textit{device
405 file}) che permettono di accedere alle periferiche o le fifo ed i socket che
406 forniscono funzionalità di comunicazione fra processi.
408 Il secondo aspetto è che per poter utilizzare dei normali file di dati il
409 kernel deve provvedere ad organizzare e rendere accessibile in maniera
410 opportuna l'informazione in essi contenuta memorizzandola sullo spazio grezzo
411 disponibile sui dischi. Questo viene fatto strutturando l'informazione sul
412 disco attraverso quello che si chiama un
413 ``\textit{filesystem}''. L'informazione così strutturata poi viene resa
414 disponibile ai processi attraverso quello che viene chiamato il
415 ``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
416 sarà accessibile nella forma ordinaria di file e directory.
418 \itindbeg{Virtual~File~System}
420 In Linux il concetto di \textit{everything is a file} è stato implementato
421 attraverso il \textit{Virtual File System} (che da qui in poi abbrevieremo in
422 VFS) che è uno strato intermedio che il kernel usa per accedere ai più
423 svariati filesystem mantenendo la stessa interfaccia per i programmi in
426 Il VFS fornisce cioè quel livello di astrazione che permette di collegare le
427 operazioni interne del kernel per la manipolazione sui file con le
428 \textit{system call} relative alle operazioni di I/O, e gestisce poi
429 l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem
430 le effettuano, permettendo la coesistenza di filesystem differenti all'interno
431 dello stesso albero delle directory. Approfondiremo il funzionamento di
432 interfaccia generica fornita dal VFS in sez.~\ref{sec:file_vfs_work}.
434 In sostanza quello che accade è che quando un processo esegue una
435 \textit{system call} che opera su un file, il kernel chiama sempre una
436 funzione implementata nel VFS. La funzione eseguirà le manipolazioni sulle
437 strutture generiche e utilizzerà poi la chiamata alle opportune funzioni del
438 filesystem specifico a cui si fa riferimento. Saranno queste a chiamare le
439 funzioni di più basso livello che eseguono le operazioni di I/O sul
440 dispositivo fisico, secondo lo schema riportato in
441 fig.~\ref{fig:file_VFS_scheme}.
445 \includegraphics[width=7cm]{img/vfs}
446 \caption{Schema delle operazioni del VFS.}
447 \label{fig:file_VFS_scheme}
450 Questa interfaccia resta la stessa anche quando, invece che a dei normali
451 file, si accede alle periferiche coi citati \index{file!di~dispositivo} file
452 di dispositivo, solo che in questo caso invece di usare il codice del
453 filesystem che accede al disco, il \textit{Virtual File System} eseguirà
454 direttamente il codice del kernel che permette di accedere alla periferica.
456 \itindend{Virtual~File~System}
458 Come accennato in precedenza una delle funzioni essenziali per il
459 funzionamento dell'interfaccia dei file è quella che consente di montare un
460 filesystem nell'albero dei file, e rendere così visibili i suoi contenuti. In
461 un sistema unix-like infatti, a differenza di quanto avviene in altri sistemi
462 operativi, tutti i file vengono mantenuti all'interno di un unico albero la
463 cui radice (quella che viene chiamata \textit{root directory}) viene montata
464 all'avvio direttamente dal kernel.
466 Come accennato in sez.~\ref{sec:intro_kern_and_sys}) montare la radice è,
467 insieme al lancio di \cmd{init},\footnote{l'operazione è ovviamente anche
468 preliminare al lancio di \cmd{init}, dato il kernel deve poter accedere al
469 file che contiene detto programma.} l'unica operazione che viene effettuata
470 direttamente dal kernel in fase di avvio quando, completata la fase di
471 inizializzazione, esso riceve dal bootloader l'indicazione di quale
472 dispositivo contiene il filesystem da usare come punto di partenza e questo
473 viene posto alla radice dell'albero dei file.
475 Tutti gli ulteriori filesystem che possono essere disponibili su altri
476 dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli su
477 altrettante directory del filesystem radice, su quelli che vengono chiamati
478 \index{mount~point} \textit{mount point}. Questo comunque avverrà sempre in
479 un secondo tempo, in genere a cura dei programmi eseguiti nella procedura di
480 inizializzazione del sistema, grazie alle funzioni che tratteremo in
481 sez.~\ref{sec:filesystem_mounting}.
484 \subsection{La risoluzione del nome di file e directory}
485 \label{sec:file_pathname}
489 Come illustrato sez.~\ref{sec:file_arch_overview} una delle caratteristiche
490 distintive di un sistema unix-like è quella di avere un unico albero dei
491 file. Un file deve essere identificato dall'utente usando quello che viene
492 chiamato il suo \textit{pathname},\footnote{il manuale della \acr{glibc}
493 depreca questa nomenclatura, che genererebbe confusione poiché \textit{path}
494 indica anche un insieme di directory su cui effettuare una ricerca (come
495 quello in cui la shell cerca i comandi). Al suo posto viene proposto l'uso
496 di \textit{filename} e di componente per il nome del file all'interno della
497 directory. Non seguiremo questa scelta dato che l'uso della parola
498 \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più
499 chiaro dell'alternativa proposta.} vale a dire tramite il
500 ``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
501 \textit{pathname}) che si deve fare per accedere al file a partire da una
502 certa ``\textit{directory}''.
504 Una directory in realtà è anch'essa un file, nel senso che è anch'essa un
505 oggetto di un filesystem, solo che è un file particolare che il kernel
506 riconosce appositamente come tale per poterlo utilizzare come directory. Il
507 suo scopo è quello di contenere una lista di nomi di file e le informazioni
508 che associano ciascuno di questi nomi al relativo contenuto (torneremo su
509 questo in sez.~\ref{sec:file_arch_func}).
511 Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
512 filesystem, compresa un'altra directory, si ottiene naturalmente
513 un'organizzazione ad albero inserendo nomi di directory dentro altre
514 directory. All'interno dello stesso albero si potranno poi inserire anche
515 tutti gli altri oggetti previsti l'interfaccia del
516 \itindex{Virtual~File~System} VFS (su cui torneremo in
517 sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
518 socket e gli stessi \index{file!di~dispositivo} file di dispositivo.
520 La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
521 dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
522 nomi che indicano le directory che lo compongono. Dato che la directory radice
523 sta in cima all'albero, essa viene indicata semplicemente con il
524 \textit{pathname} \file{/}.
526 \itindbeg{pathname~resolution}
528 Un file può essere indicato rispetto ad una directory semplicemente
529 specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
530 nelle directory ``componenti'' (in inglese \textit{file name components}), noi
531 li chiameremo più semplicemente \textsl{nomi} o \textsl{voci}, riservando la
532 parola \textsl{componenti} ai nomi che, separati da una ``\texttt{/}'',
533 costituiscono il \textit{pathname}. Questi poi dovranno corrispondere, perché
534 il \textit{pathname} sia valido, a voci effettivamente presenti nelle
535 directory, ma non è detto che un \textit{pathname} debba per forza risultare
538 Il procedimento con cui dato un \textit{pathname} si individua il file a cui
539 esso fa riferimento, è chiamato \textsl{risoluzione del percorso}
540 (\textit{filename resolution} o \textit{pathname resolution}). Lo stesso
541 procedimento ci può anche dire che il \textit{pathname} usato non è valido.
542 La risoluzione viene eseguita esaminando il \textit{pathname} da sinistra a
543 destra e localizzando ogni componente dello stesso come nome in una directory
544 a partire dalla directory iniziale, usando il carattere ``\texttt{/}'' come
545 separatore per scendere dall'una all'altra. Nel caso si indichi un componente
546 vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
549 Ovviamente perché la risoluzione abbia successo occorre che i componenti
550 intermedi esistano e siano effettivamente directory, e che il file o la
551 directory indicata dall'ultimo componente esista. Inoltre i permessi relativi
552 alle directory indicate nel \textit{pathname} (torneremo su questo
553 sez.~\ref{sec:file_access_control}) dovranno consentire l'accesso all'intero
556 Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
557 parte dalla directory radice del processo. Questa, a meno di non avere
558 eseguito una \func{chroot} (funzione su cui torneremo in
559 sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
560 directory radice dell'albero dei file montata dal kernel all'avvio del
561 sistema; in questo caso si parla di un \textsl{pathname assoluto}
562 \itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla
563 \index{directory~di~lavoro} directory di lavoro corrente del processo (su cui
564 torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
565 \itindsub{pathname}{relativo} \textsl{pathname relativo}.
567 Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
568 speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
569 sez.~\ref{sec:file_dir_creat_rem}). Il primo fa riferimento alla directory
570 corrente e il secondo alla directory \textsl{genitrice} (o \textit{parent
571 directory}) cioè la directory che contiene il riferimento alla directory
574 In questo modo con ``\file{..}'' si può usare un \itindsub{pathname}{relativo}
575 \textit{pathname} relativo per indicare un file posto al di sopra della
576 directory corrente, tornando all'indietro nell'albero dei file. Questa
577 retromarcia però su fermerà una volta raggiunta la directory radice, perché
578 non esistendo in questo caso una directory superiore, il nome ``\file{..}''
579 farà riferimento alla radice stessa.
582 \itindend{pathname~resolution}
585 \subsection{I tipi di file}
586 \label{sec:file_file_types}
588 Parlare dei tipi di file su Linux, come per qualunque sistema unix-like,
589 significa anzitutto chiarire il proprio vocabolario e sottolineare le
590 differenze che ci sono rispetto ad altri sistemi operativi.
592 Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
593 \itindex{Virtual~File~System} \textit{Virtual File System} consente di
594 trattare come file oggetti molto diversi fra loro. Oltre ai normali file di
595 dati abbiamo già accennato ad altri due di questi oggetti, i file di
596 dispositivo e le directory, ma ne esistono altri. In genere quando si parla di
597 tipo di file su Linux si fa riferimento a questi, di cui si riportato l'elenco
598 completo in tab.~\ref{tab:file_file_types}.
603 \begin{tabular}[c]{|l|l|p{6cm}|}
605 \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
608 \textit{regular file} & \textsl{file regolare} &
609 Un file che contiene dei dati (l'accezione normale di file).\\
610 \textit{directory} & \textsl{cartella o direttorio} &
611 Un file che contiene una lista di nomi associati a degli
612 \itindex{inode} \textit{inode} (vedi sez.~\ref{sec:file_vfs_work}).\\
613 \textit{symbolic link} & \textsl{collegamento simbolico} &
614 Un file che contiene un riferimento ad un altro file/directory.\\
615 \textit{char device} & \textsl{dispositivo a caratteri} &
616 Un file \textsl{speciale} che identifica una periferica ad accesso a
618 \textit{block device} & \textsl{dispositivo a blocchi} &
619 Un file \textsl{speciale} che identifica una periferica ad accesso a
621 \textit{fifo} & ``\textsl{coda}'' &
622 Un file \textsl{speciale} che identifica una linea di comunicazione
623 unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
624 \textit{socket} & ``\textsl{presa}''&
625 Un file \textsl{speciale} che identifica una linea di comunicazione
626 bidirezionale (vedi cap.~\ref{cha:socket_intro}).\\
629 \caption{Tipologia dei file definiti nel VFS}
630 \label{tab:file_file_types}
633 Si tenga ben presente che questa classificazione non ha nulla a che fare con
634 una classificazione dei file in base al tipo loro del contenuto, dato che in
635 tal caso si avrebbe a che fare sempre e solo con dei file di dati. E non ha
636 niente a che fare neanche con le eventuali diverse modalità con cui si
637 potrebbe accedere al contenuto dei file di dati. La classificazione di
638 tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
639 \itindex{Virtual~File~System} \textit{Virtual File System}, ed è da notare la
640 presenza dei cosiddetti file ``\textsl{speciali}''.
642 Alcuni di essi, come le \textit{fifo} (che tratteremo in
643 sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
644 cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
645 alcune funzionalità di comunicazione fornite dal kernel. Gli altri sono
646 proprio quei \index{file!di~dispositivo} \textsl{file di dispositivo} che
647 costituiscono una interfaccia diretta per leggere e scrivere sui dispositivi
648 fisici. Anche se finora li abbiamo chiamati genericamente così, essi sono
649 tradizionalmente suddivisi in due grandi categorie, \textsl{a blocchi} e
650 \textsl{a caratteri} a seconda delle modalità in cui il dispositivo
651 sottostante effettua le operazioni di I/O.
653 I dispositivi a blocchi (ad esempio i dischi) sono quelli corrispondono a
654 periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi di
655 dati di dimensioni fissate (nel caso dei dischi le dimensioni di un settore),
656 mentre i dispositivi a caratteri sono quelli per cui l'I/O può essere
657 effettuato senza nessuna particolare struttura, ed in generale anche un byte
658 alla volta, da cui il nome.
660 Una delle differenze principali con altri sistemi operativi come il VMS o
661 Windows è che per Unix tutti i file di dati sono identici e contengono un
662 flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
663 sistema file di diverso contenuto o formato, come nel caso di quella fra file
664 di testo e binari che c'è in Windows. Non c'è neanche una strutturazione a
665 record per il cosiddetto ``\textsl{accesso diretto}'' come nel caso del
666 VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
667 dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
668 ed è completamente trasparente all'utente; inoltre talvolta si parla di
669 \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
670 fare con tutto ciò, di effettuare, attraverso degli appositi
671 \index{file!di~dispositivo} file di dispositivo, operazioni di I/O
672 direttamente sui dischi senza passare attraverso un filesystem, il
673 cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ma
674 ormai in sostanziale disuso.}
676 Una differenza che attiene ai contenuti di un file però esiste, ed è relativa
677 al formato dei file di testo. Nei sistemi unix-like la fine riga è codificata
678 in maniera diversa da Windows o dal vecchio MacOS, in particolare il fine riga
679 è il carattere \texttt{LF} (\verb|\n|) al posto del \texttt{CR} (\verb|\r|)
680 del vecchio MacOS e del \texttt{CR LF} (\verb|\r\n|) di Windows. Questo può
681 causare alcuni problemi qualora nei programmi si facciano assunzioni sul
682 terminatore della riga e per questo esistono dei programmi come \cmd{unix2dos}
683 e \cmd{dos2unix} che effettuano una conversione fra questi due formati di
686 Si ricordi comunque che un kernel unix-like non fornisce nessun supporto per
687 la tipizzazione dei file di dati in base al loro contenuto e che non c'è
688 nessun supporto per una qualche interpretazione delle estensioni (nel nome del
689 file) da parte del kernel,\footnote{non è così ad esempio nel filesystem HFS
690 dei Mac, che supporta delle risorse associate ad ogni file, che specificano
691 fra l'altro il contenuto ed il programma da usare per leggerlo; in realtà
692 per alcuni filesystem esiste la possibilità di associare delle risorse ai
693 file con gli \textit{extended attributes} (vedi sez.~\ref{sec:file_xattr}),
694 ma è una caratteristica tutt'ora poco utilizzata, dato che non corrisponde
695 al modello classico dei file in un sistema Unix.} ogni classificazione di
696 questo tipo avviene sempre in \textit{user-space}. Gli unici file di cui il
697 kernel deve essere in grado di capire il contenuto sono i binari dei
698 programmi, per i quali sono supportati solo alcuni formati, anche se oggi
699 viene usato quasi esclusivamente l'ELF.\footnote{il nome è l'acronimo di
700 \textit{Executable and Linkable Format}, un formato per eseguibili binari
701 molto flessibile ed estendibile definito nel 1995 dal \textit{Tool Interface
702 Standard} che per le sue caratteristiche di non essere legato a nessun
703 tipo di processore o architettura è stato adottato da molti sistemi
704 unix-like e non solo.}
706 Nonostante l'assenza di supporto da parte del kernel per la classificazione
707 del contenuto dei file di dati, molti programmi adottano comunque delle
708 convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
709 in file con l'estensione \file{.c}. Inoltre una tecnica molto usata per
710 classificare i contenuti da parte dei programmi è quella di utilizzare i primi
711 byte del file per memorizzare un \itindex{magic~number} ``\textit{magic
712 number}''\footnote{il concetto è quello di un numero intero, solitamente fra
713 2 e 10 byte, che identifichi il contenuto seguente, dato che questi sono
714 anche caratteri è comune trovare espresso tale numero con stringhe come
715 ``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script.} che ne
716 classifichi il contenuto. Entrambe queste tecniche, per quanto usate ed
717 accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
718 demandato alle applicazioni stesse.
721 \subsection{Le due interfacce per l'accesso ai file}
722 \label{sec:file_io_api}
725 \itindbeg{file~descriptor}
727 In Linux le interfacce di programmazione per l'I/O su file due. La prima è
728 l'interfaccia nativa del sistema, quella che il manuale delle \textsl{glibc}
729 chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
730 \textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
731 sistemi unix-like che fornisce un accesso non bufferizzato.
733 L'interfaccia è essenziale, l'accesso viene detto non bufferizzato in quanto
734 la lettura e la scrittura vengono eseguite chiamando direttamente le
735 \textit{system call} del kernel, anche se in realtà il kernel effettua al suo
736 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
737 dispositivi. L'accesso viene gestito attraverso i \textit{file descriptor} che
738 sono rappresentati da numeri interi (cioè semplici variabili di tipo
739 \ctyp{int}). L'interfaccia è definita nell'\textit{header file}
740 \headfile{unistd.h} e la tratteremo in dettaglio in
741 sez.~\ref{sec:file_unix_interface}.
743 \itindbeg{file~stream}
745 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama dei
746 \textit{file stream} o più semplicemente degli \textit{stream}.\footnote{in
747 realtà una interfaccia con lo stesso nome è stata introdotta a livello di
748 kernel negli Unix derivati da \textit{System V}, come strato di astrazione
749 per file e socket; in Linux questa interfaccia, che comunque ha avuto poco
750 successo, non esiste, per cui facendo riferimento agli \textit{stream}
751 useremo il significato adottato dal manuale delle \acr{glibc}.} Essa
752 fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
753 implementazione fatta nella \acr{glibc}. Questa è l'interfaccia standard
754 specificata dall'ANSI C e perciò si trova anche su tutti i sistemi non
755 Unix. Gli \textit{stream} sono oggetti complessi e sono rappresentati da
756 puntatori ad un opportuna struttura definita dalle librerie del C, ad essi si
757 accede sempre in maniera indiretta utilizzando il tipo \code{FILE *}.
758 L'interfaccia è definita nell'\textit{header file} \headfile{stdio.h} e la
759 tratteremo in dettaglio in sez.~\ref{sec:files_std_interface}.
761 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
762 altri oggetti del VFS, ma per poter accedere alle operazioni di controllo
763 (descritte in sez.~\ref{sec:file_fcntl_ioctl}) su un qualunque tipo di oggetto
764 del VFS occorre usare l'interfaccia standard di Unix con i file
765 descriptor. Allo stesso modo devono essere usati i file descriptor se si vuole
766 ricorrere a modalità speciali di I/O come il \itindex{file~locking}
767 \textit{file locking} o l'I/O non-bloccante (vedi
768 cap.~\ref{cha:file_advanced}).
770 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
771 quella dei \textit{file descriptor}, che permette di poter scegliere tra
772 diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
773 è che l'interfaccia per le operazioni di input/output è molto più ricca di
774 quella dei \textit{file descriptor}, che forniscono solo funzioni elementari
775 per la lettura/scrittura diretta di blocchi di byte. In particolare gli
776 \textit{stream} dispongono di tutte le funzioni di formattazione per l'input e
777 l'output adatte per manipolare anche i dati in forma di linee o singoli
780 In ogni caso, dato che gli \textit{stream} sono implementati sopra
781 l'interfaccia standard di Unix, è sempre possibile estrarre il \textit{file
782 descriptor} da uno \textit{stream} ed eseguirvi sopra operazioni di basso
783 livello, o associare in un secondo tempo uno \textit{stream} ad un
784 \textit{file descriptor} per usare l'interfaccia più sofisticata.
786 In generale, se non necessitano specificatamente le funzionalità di basso
787 livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
788 portabilità, essendo questi ultimi definiti nello standard ANSI C;
789 l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
790 POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
792 \itindend{file~descriptor}
793 \itindend{file~stream}
795 \section{Gli standard}
796 \label{sec:intro_standard}
798 In questa sezione faremo una breve panoramica relativa ai vari standard che
799 nel tempo sono stati formalizzati da enti, associazioni, consorzi e
800 organizzazioni varie al riguardo ai sistemi operativi di tipo Unix o alle
801 caratteristiche che si sono stabilite come standard di fatto in quanto facenti
802 parte di alcune implementazioni molto diffuse come BSD o System V.
804 Ovviamente prenderemo in considerazione solo gli standard riguardanti
805 interfacce di programmazione e le altre caratteristiche di un sistema
806 unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
807 ed in particolare ci concentreremo sul come ed in che modo essi sono
808 supportati sia per quanto riguarda il kernel che la Libreria Standard del C,
809 con una particolare attenzione alla \acr{glibc}.
812 \subsection{Lo standard ANSI C}
813 \label{sec:intro_ansiC}
815 Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
816 Standard Institute} come prima standardizzazione del linguaggio C e per
817 questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
818 adottato dalla ISO (\textit{International Standard Organisation}) come
819 standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
820 anche sotto il nome di standard ISO C, o ISO C90. Nel 1999 è stata pubblicata
821 una revisione dello standard C89, che viene usualmente indicata come C99,
822 anche questa è stata ratificata dalla ISO con la sigla ISO/IEC 9899:1990, per
823 cui vi si fa riferimento anche come ISO C99.
825 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
826 sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
827 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
828 anche una libreria di funzioni che devono poter essere implementate su
829 qualunque sistema operativo.
831 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
832 di tipo Unix, GNU/Linux (per essere precisi la \acr{glibc}), come molti Unix
833 moderni, provvede la compatibilità con questo standard, fornendo le funzioni
834 di libreria da esso previste. Queste sono dichiarate in una serie di
835 \textit{header file} anch'essi forniti dalla \acr{glibc} (tratteremo
836 l'argomento in sez.~\ref{sec:proc_syscall}).
838 In realtà la \acr{glibc} ed i relativi \textit{header file} definiscono un
839 insieme di funzionalità in cui sono incluse come sottoinsieme anche quelle
840 previste dallo standard ANSI C. È possibile ottenere una conformità stretta
841 allo standard (scartando le funzionalità addizionali) usando il \cmd{gcc} con
842 l'opzione \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei
843 vari \textit{header file} soltanto le funzionalità previste dallo standard
844 ANSI C e a non usare le varie estensioni al linguaggio e al preprocessore da
848 \subsection{I tipi di dati primitivi}
849 \label{sec:intro_data_types}
851 Uno dei problemi di portabilità del codice più comune è quello dei tipi di
852 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
853 anche da una architettura ad un'altra (ad esempio passando da macchine con
854 processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
855 \index{tipo!elementare} \textit{tipi elementari} del linguaggio C (come
856 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
858 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
859 associati ad alcune variabili nei sistemi Unix, dando per scontata la
860 dimensione. Ad esempio la posizione corrente all'interno di un file è stata
861 associata ad un intero a 32 bit, mentre il numero di dispositivo è stato
862 associato ad un intero a 16 bit. Storicamente questi erano definiti
863 rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte che, con
864 l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi tipi si
865 sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad una
866 infinita serie di problemi di portabilità.
871 \begin{tabular}[c]{|l|l|}
873 \textbf{Tipo} & \textbf{Contenuto} \\
876 \type{caddr\_t} & Core address.\\
877 \type{clock\_t} & Contatore del \textit{process time} (vedi
878 sez.~\ref{sec:sys_cpu_times}.\\
879 \type{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
880 \type{gid\_t} & Identificatore di un gruppo (vedi
881 sez.~\ref{sec:proc_access_id}).\\
882 \type{ino\_t} & Numero di \itindex{inode} \textit{inode}.\\
883 \type{key\_t} & Chiave per il System V IPC (vedi
884 sez.~\ref{sec:ipc_sysv_generic}).\\
885 \type{loff\_t} & Posizione corrente in un file.\\
886 \type{mode\_t} & Attributi di un file.\\
887 \type{nlink\_t} & Contatore dei collegamenti su un file.\\
888 \type{off\_t} & Posizione corrente in un file.\\
889 \type{pid\_t} & Identificatore di un processo (vedi
890 sez.~\ref{sec:proc_pid}).\\
891 \type{rlim\_t} & Limite sulle risorse.\\
892 \type{sigset\_t}& Insieme di segnali (vedi sez.~\ref{sec:sig_sigset}).\\
893 \type{size\_t} & Dimensione di un oggetto.\\
894 \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
895 \type{ptrdiff\_t}& Differenza fra due puntatori.\\
896 \type{time\_t} & Numero di secondi (in \itindex{calendar~time}
897 \textit{calendar time}, vedi
898 sez.~\ref{sec:sys_time}).\\
899 \type{uid\_t} & Identificatore di un utente (vedi
900 sez.~\ref{sec:proc_access_id}).\\
903 \caption{Elenco dei tipi primitivi, definiti in \headfile{sys/types.h}.}
904 \label{tab:intro_primitive_types}
907 Per questo motivo tutte le funzioni di libreria di solito non fanno
908 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
909 serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
910 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'\textit{header file}
911 \headfile{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
912 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
916 \subsection{Lo standard System V}
917 \label{sec:intro_sysv}
919 Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
920 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
921 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
922 Unix System V, e si fa rifermento a questa implementazione con la sigla SysV o
925 Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
926 con aggiunte e integrazioni, ed in particolare la \textit{release 2} nel 1985,
927 a cui si fa riferimento con SVr2 e la \textit{release 3} nel 1986 (denominata
928 SVr3). Le interfacce di programmazione di queste due versioni vennero
929 descritte formalmente in due documenti denominati \textit{System V Interface
930 Definition} (o SVID), pertanto nel 1995 venne rilasciata la specifica SVID 1
931 e nel 1986 la specifica SVID 2.
933 Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
934 versione di System V che provvedeva un'unificazione delle interfacce
935 comprendente anche Xenix e BSD, questa venne denominata \textit{release 4} o
936 SVr4. Anche le relative interfacce vennero descritte in un documento dal
937 titolo \textit{System V Interface Description}, venendo a costituire lo
938 standard SVID 3, che viene considerato la specifica finale di System V, ed a
939 cui spesso si fa riferimento semplicemente con SVID. Anche SVID costituisce un
940 sovrainsieme delle interfacce definite dallo standard POSIX.
942 Nel 1992 venne rilasciata una seconda versione del sistema, la SVr4.2; l'anno
943 successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
944 Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
945 al consorzio X/Open. L'ultima versione di System V fu la SVr4.2MP rilasciata
946 nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
947 acquisito alcuni diritti sul codice di System V, una ulteriore versione delle
948 \textit{System V Interface Description}, che va sotto la denominazione di SVID
951 Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
952 specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
953 compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
954 includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
955 presenti neanche in System V) sono state tralasciate.
957 Le funzionalità implementate sono principalmente il meccanismo di
958 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
959 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
960 \funcm{hsearch} e \funcm{drand48}, \funcm{fmtmsg} e svariate funzioni
964 \subsection{Lo ``\textsl{standard}'' BSD}
965 \label{sec:intro_bsd}
967 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
968 di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
969 mondo Unix. L'università di Berkeley proseguì nello sviluppo della base di
970 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
971 versioni allora disponibili, fino ad arrivare al rilascio di una versione
972 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
975 Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
976 dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
977 serie di estensioni e interfacce di grandissima rilevanza, come i collegamenti
978 simbolici, la funzione \code{select} ed i socket di rete. Per questo motivo si
979 fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni
980 dello Unix di Berkeley con una apposita sigla.
982 Nel 1983, con il rilascio della versione 4.2 di BSD, venne definita una
983 implementazione delle funzioni di interfaccia a cui si fa riferimento con la
984 sigla 4.2BSD. Per fare riferimento alle precedenti versioni si usano poi le
985 sigle 3BSD e 4BSD (per le due versioni pubblicate nel 1980), e 4.1BSD per
986 quella pubblicata nel 1981.
988 Le varie estensioni ideate a Berkeley sono state via via aggiunte al sistema
989 nelle varie versioni succedutesi negli anni, che vanno sotto il nome di
990 4.3BSD, per la versione rilasciata nel 1986 e 4.4BSD, per la versione
991 rilasciata nel 1993, che costituisce l'ultima release ufficiale
992 dell'università di Berkeley. Si tenga presente che molte di queste interfacce
993 sono presenti in derivati commerciali di BSD come SunOS. Il kernel Linux e la
994 \acr{glibc} forniscono tutte queste estensioni che sono state in gran parte
995 incorporate negli standard successivi.
998 \subsection{Gli standard IEEE -- POSIX}
999 \label{sec:intro_posix}
1001 Lo standard ufficiale creato da un organismo indipendente più attinente alle
1002 interfacce di un sistema unix-like nel suo complesso (e che concerne sia il
1003 kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
1004 origine dallo standard ANSI C, che contiene come sottoinsieme, prevedendo
1005 ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
1008 In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
1009 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
1010 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
1011 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
1012 che ne produsse una prima versione, nota come \textsl{IEEE 1003.1-1988},
1013 mirante a standardizzare l'interfaccia con il sistema operativo.
1015 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
1016 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
1017 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
1018 \itindex{thread} \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i
1019 socket (1003.1g) e vari altri. In tab.~\ref{tab:intro_posix_std} è riportata
1020 una classificazione sommaria dei principali documenti prodotti, e di come sono
1021 identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
1022 l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
1023 parlare di POSIX.4 come di POSIX.1b.
1025 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
1026 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
1027 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
1028 denominazioni usate diventa particolarmente faticoso; una pagina dove si
1029 possono recuperare varie (e di norma piuttosto intricate) informazioni è
1030 \url{http://www.pasc.org/standing/sd11.html}.
1035 \begin{tabular}[c]{|l|l|l|l|}
1037 \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
1040 POSIX.1 & 1003.1 & 9945-1& Interfacce di base. \\
1041 POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1. \\
1042 POSIX.2 & 1003.2 & 9945-2& Comandi. \\
1043 POSIX.3 & 2003 &TR13210& Metodi di test. \\
1044 POSIX.4 & 1003.1b & --- & Estensioni real-time. \\
1045 POSIX.4a& 1003.1c & --- & \itindex{thread} Thread. \\
1046 POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time. \\
1047 POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA. \\
1048 POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza. \\
1049 POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete. \\
1050 POSIX.9 & 1003.9 & --- & Interfaccia per il Fortran-77. \\
1051 POSIX.12& 1003.1g& 9945-1& Socket. \\
1054 \caption{Elenco dei vari standard POSIX e relative denominazioni.}
1055 \label{tab:intro_posix_std}
1058 Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
1059 definiscono comunque un'interfaccia di programmazione generica e non fanno
1060 riferimento ad una implementazione specifica (ad esempio esiste
1061 un'implementazione di POSIX.1 anche sotto Windows NT).
1063 Linux e la \acr{glibc} implementano tutte le funzioni definite nello standard
1064 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
1065 funzioni di \textit{pattern matching} e per la manipolazione delle
1066 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
1067 sistema e che sono definite nello standard POSIX.2.
1069 Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
1070 ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
1071 \itindex{thread} \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo
1072 standard POSIX.1b per quanto riguarda i segnali e lo \itindex{scheduler}
1073 scheduling real-time (sez.~\ref{sec:sig_real_time} e
1074 sez.~\ref{sec:proc_real_time}), la misura del tempo, i meccanismi di
1075 intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O asincrono
1076 (sez.~\ref{sec:file_asyncronous_io}).
1078 Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la
1079 versione più nota, cui gran parte delle implementazioni fanno riferimento, e
1080 che costituisce una base per molti altri tentativi di standardizzazione, è
1081 stata rilasciata anche come standard internazionale con la sigla
1082 \textsl{ISO/IEC 9945-1:1996} ed include i precedenti POSIX.1b e POSIX.1c. In
1083 genere si fa riferimento ad essa come POSIX.1-1996.
1085 Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
1086 SUSv3 (vedi sez.~\ref{sec:intro_xopen}) in un unico documento, redatto sotto
1087 gli auspici del cosiddetto gruppo Austin che va sotto il nome di POSIX.1-2001.
1088 Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
1089 presenti solo le interfacce di base, e quello XSI che richiede la presenza di
1090 una serie di estensioni opzionali per lo standard POSIX, riprese da SUSv3.
1091 Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
1092 nella definizione delle interfacce.
1094 A questo standard sono stati aggiunti due documenti di correzione e
1095 perfezionamento denominati \textit{Technical Corrigenda}, il TC1 del 2003 ed
1096 il TC2 del 2004, e talvolta si fa riferimento agli stessi con le sigle
1097 POSIX.1-2003 e POSIX.1-2004.
1099 Una ulteriore revisione degli standard POSIX e SUS è stata completata e
1100 ratificata nel 2008, cosa che ha portato al rilascio di una nuova versione
1101 sotto il nome di POSIX.1-2008 (e SUSv4), con l'incorporazione di alcune nuove
1102 interfacce, la obsolescenza di altre, la trasformazione da opzionali a
1103 richieste di alcune specifiche di base, oltre alle solite precisazioni ed
1104 aggiornamenti. Anche in questo caso è prevista la suddivisione in una
1105 conformità di base, e delle interfacce aggiuntive.
1107 Le procedure di aggiornamento dello standard POSIX prevedono comunque un
1108 percorso continuo, che prevede la possibilità di introduzione di nuove
1109 interfacce e la definizione di precisazioni ed aggiornamenti, per questo in
1110 futuro verranno rilasciate nuove versioni. Alla stesura di queste note
1111 l'ultima revisione approvata resta POSIX.1-2008, uno stato della situazione
1112 corrente del supporto degli standard è allegato alla documentazione della
1113 \acr{glibc} e si può ottenere con il comando \texttt{man standards}.
1116 \subsection{Gli standard X/Open -- Opengroup -- Unix}
1117 \label{sec:intro_xopen}
1119 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
1120 Unix per giungere ad un'armonizzazione delle varie implementazioni. Per far
1121 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
1122 nome di \textit{X/Open Portability Guide} a cui di norma si fa riferimento con
1123 l'abbreviazione XPG$n$, con $n$ che indica la versione.
1125 Nel 1989 il consorzio produsse una terza versione di questa guida
1126 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
1127 contenente una dettagliata standardizzazione dell'interfaccia di sistema di
1128 Unix, che venne presa come riferimento da vari produttori. Questo standard,
1129 detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
1130 POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
1131 delle API\footnote{le \textit{Application Programmable Interface}, in sostanze
1132 le interfacce di programmazione.} per l'interfaccia grafica (X11).
1134 Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
1135 Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{X
1136 Transport Interface}) mirante a soppiantare (senza molto successo)
1137 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
1138 rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
1139 interfacce, intestazioni e comandi definiti) ma si fa riferimento ad essa
1142 Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
1143 aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
1144 specifiche sotto il nome di \textit{Single UNIX Specification} o SUS, l'ultima
1145 versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
1146 Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
1149 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
1150 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
1151 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
1152 raccoglie produttori, utenti industriali, entità accademiche e governative.
1153 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
1154 il lavoro di standardizzazione delle varie implementazioni, rilasciando
1155 periodicamente nuove specifiche e strumenti per la verifica della conformità
1158 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
1159 Specification}, nota con la sigla SUSv2, in questa versione le interfacce
1160 specificate salgono a 1434, e addirittura a 3030 se si considerano le stazioni
1161 di lavoro grafiche, per le quali sono inserite pure le interfacce usate da CDE
1162 che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
1163 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. Un
1164 altro nome alternativo di queste specifiche, date le origini, è XPG5.
1166 Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
1167 effettuato uno sforzo di sintesi in cui sono state comprese, nella parte di
1168 interfacce estese, anche le interfacce definite nelle \textit{Single UNIX
1169 Specification}, pertanto si può fare riferimento a detto standard, quando
1170 comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del
1171 marchio UNIX 03 se conformi ad esso.
1173 Infine, come avvenuto per POSIX.1-2001, anche con la successiva revisione
1174 dello standard POSIX.1 (la POSIX.1-2008) è stato stabilito che la conformità
1175 completa a tutte quelle che sono le nuove estensioni XSI previste
1176 dall'aggiornamento vada a definire la quarta versione delle \textit{Single
1177 UNIX Specification}, chiamata appunto SUSv4.
1180 \subsection{Il controllo di aderenza agli standard}
1181 \label{sec:intro_gcc_glibc_std}
1183 In Linux, se si usa la \acr{glibc}, la conformità agli standard appena
1184 descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
1185 compilatore (il \texttt{gcc}) che definendo delle specifiche costanti prima
1186 dell'inclusione dei file di intestazione (gli \textit{header file}, vedi
1187 sez.~\ref{sec:proc_syscall}) che definiscono le funzioni di libreria.
1189 Ad esempio se si vuole che i programmi seguano una stretta attinenza allo
1190 standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
1191 potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
1192 standard ISO per il C. Il \texttt{gcc} possiede inoltre una specifica opzione
1193 per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
1194 dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
1195 (vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
1196 allo standard C99.\footnote{che non è al momento completa, esistono anche le
1197 possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
1198 l'uso delle estensioni GNU al C89, riprese poi dal C99, o \texttt{gnu89} che
1199 indica il dialetto GNU del C99, che diventerà il default quando la
1200 conformità a quest'ultimo sarà completa.}
1202 Per attivare le varie opzioni di controllo di aderenza agli standard è poi
1203 possibile definire delle macro di preprocessore che controllano le
1204 funzionalità che la \acr{glibc} può mettere a disposizione:\footnote{le macro
1205 sono definite nel file di dichiarazione \file{<features.h>}, ma non è
1206 necessario includerlo nei propri programmi in quanto viene automaticamente
1207 incluso da tutti gli altri file di dichiarazione che utilizzano le macro in
1208 esso definite; si tenga conto inoltre che il file definisce anche delle
1209 ulteriori macro interne, in genere con un doppio prefisso di \texttt{\_},
1210 che non devono assolutamente mai essere usate direttamente. } questo può
1211 essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
1212 norma farlo inserendo gli opportuni \code{\#define} prima della inclusione dei
1213 propri \textit{header file} (vedi sez.~\ref{sec:proc_syscall}).
1215 Le macro disponibili per controllare l'aderenza ai vari standard messi a
1216 disposizione della \acr{glibc}, che rendono disponibili soltanto le funzioni
1217 in essi definite, sono illustrate nel seguente elenco:
1218 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
1219 \item[\macro{\_\_STRICT\_ANSI\_\_}] richiede l'aderenza stretta allo standard
1220 C ISO; viene automaticamente predefinita qualora si invochi il \texttt{gcc}
1221 con le opzione \texttt{-ansi} o \texttt{-std=c99}.
1223 \item[\macro{\_POSIX\_SOURCE}] definendo questa macro (considerata obsoleta)
1224 si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
1225 versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
1226 standard ISO C. Se viene anche definita con un intero positivo la macro
1227 \macro{\_POSIX\_C\_SOURCE} lo stato di questa non viene preso in
1230 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
1231 positivo si controlla quale livello delle funzionalità specificate da POSIX
1232 viene messa a disposizione; più alto è il valore maggiori sono le
1235 \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
1236 specificate nella edizione del 1990 (IEEE Standard 1003.1-1990);
1237 \item valori maggiori o uguali a ``\texttt{2}'' rendono disponibili le
1238 funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
1239 1992 (IEEE Standard 1003.2-1992),
1240 \item un valore maggiore o uguale a ``\texttt{199309L}'' rende disponibili
1241 le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
1242 del 1993 (IEEE Standard 1003.1b-1993);
1243 \item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
1244 le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
1245 del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
1246 dello standard POSIX.1c per i \itindex{thread} \textit{thread};
1247 \item a partire dalla versione 2.3.3 della \acr{glibc} un valore maggiore o
1248 uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
1249 previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
1250 \item a partire dalla versione 2.10 della \acr{glibc} un valore maggiore o
1251 uguale a ``\texttt{200809L}'' rende disponibili le funzionalità di base
1252 previste dallo standard POSIX.1-2008, escludendo le estensioni XSI;
1253 \item in futuro valori superiori potranno abilitare ulteriori estensioni.
1256 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si rendono disponibili le
1257 funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
1258 ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
1259 però in conflitto con le corrispondenti definite nello standard POSIX.1, in
1260 questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
1261 la precedenza rispetto a POSIX.
1263 A causa della natura dei conflitti con POSIX per ottenere una piena
1264 compatibilità con BSD4.3 può essere necessario anche usare una libreria di
1265 compatibilità, dato che alcune funzioni sono definite in modo diverso. In
1266 questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
1267 compilatore per indicargli di utilizzare le versioni nella libreria di
1268 compatibilità prima di quelle normali.
1270 Si tenga inoltre presente che la preferenza verso le versioni delle funzioni
1271 usate da BSD viene mantenuta soltanto se nessuna delle ulteriori macro di
1272 specificazione di standard successivi (vale a dire una fra
1273 \macro{\_POSIX\_C\_SOURCE}, \macro{\_POSIX\_SOURCE}, \macro{\_SVID\_SOURCE},
1274 \macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o
1275 \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
1276 hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
1277 definito una di queste macro, l'effetto sarà quello di dare la precedenza
1278 alle funzioni in forma BSD. Questa macro è stata deprecata a partire dalle
1279 \acr{glibc} 2.20, essendo ricompresa in \macro{\_DEFAULT\_SOURCE} che è
1280 definita di default.
1282 \item[\macro{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
1283 funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
1284 standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
1285 precedenza. Questa macro è stata deprecata a partire dalle \acr{glibc} 2.20,
1286 essendo ricompresa in \macro{\_DEFAULT\_SOURCE} che è definita di default.
1288 \item[\macro{\_DEFAULT\_SOURCE}] questa macro abilita le definizioni
1289 considerate il \textit{default}, comprese quelle richieste dalla standard
1290 POSIX.1-2008, ed è sostanzialente equivalente a \macro{\_SVID\_SOURCE}
1291 \macro{\_BSD\_SOURCE}] e \macro{\_POSIX\_C\_SOURCE}. Essendo predefinita non
1292 è necessario usarla a meno di non aver richiesto delle definizioni più
1293 restrittive sia con altre macro che con i flag del compilatore, nel qual
1294 caso abilita le funzioni che altrimenti sarebbero disabilitate. Questa macro
1295 è stata introdotta a partire dalle \acr{glibc} 2.19 e consente di deprecare
1296 \macro{\_SVID\_SOURCE} e \macro{\_BSD\_SOURCE}].
1298 \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
1299 le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
1300 queste sono un sovrainsieme di quelle definite negli standard POSIX.1 e
1301 POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che
1302 \macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse
1303 anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
1304 estensioni a secondo dei seguenti valori:
1306 \item la definizione della macro ad un valore qualunque attiva le
1307 funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
1308 \item un valore di ``\texttt{500}'' o superiore rende disponibili anche le
1309 funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
1310 \item a partire dalla versione 2.2 della \acr{glibc} un valore uguale a
1311 ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
1312 introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
1314 \item a partire dalla versione 2.10 della \acr{glibc} un valore uguale a
1315 ``\texttt{700}'' o superiore rende disponibili anche le funzionalità
1316 introdotte con SUSv4, corrispondenti allo standard POSIX.1-2008 più le
1320 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono
1321 disponibili le ulteriori funzionalità necessarie ad essere conformi al
1322 rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard
1323 Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene
1324 definita implicitamente tutte le volte che si imposta
1325 \macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale a 500.
1327 \item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si rendono disponibili
1328 le funzionalità previste per la revisione delle librerie standard del C
1329 introdotte con lo standard ISO C99. La macro è definita a partire dalla
1330 versione 2.1.3 della \acr{glibc}.
1332 Le versioni precedenti la serie 2.1.x riconoscevano le stesse estensioni con
1333 la macro \macro{\_ISOC9X\_SOURCE}, dato che lo standard non era stato
1334 finalizzato, ma la \acr{glibc} aveva già un'implementazione completa che
1335 poteva essere attivata definendo questa macro. Benché questa sia obsoleta
1336 viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per
1339 \item[\macro{\_ISOC11\_SOURCE}] definendo questa macro si rendono disponibili
1340 le funzionalità previste per la revisione delle librerie standard del C
1341 introdotte con lo standard ISO C11, e abilita anche quelle previste dagli
1342 standard C99 e C95. La macro è definita a partire dalla versione 2.16 della
1345 \item[\macro{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili
1346 tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
1347 specifiche presenti solo nella \acr{glibc} ed in Linux. Gli standard coperti
1348 sono: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, SUS.
1350 L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
1351 delle macro: \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
1352 \macro{\_POSIX\_SOURCE}, \macro{\_ISOC99\_SOURCE}, e inoltre di
1353 \macro{\_POSIX\_C\_SOURCE} con valore ``\texttt{200112L}'' (o
1354 ``\texttt{199506L}'' per le versioni della \acr{glibc} precedenti la 2.5),
1355 \macro{\_XOPEN\_SOURCE\_EXTENDED} e \macro{\_XOPEN\_SOURCE} con valore 600
1356 (o 500 per le versioni della \acr{glibc} precedenti la 2.2); oltre a queste
1357 vengono pure attivate le ulteriori due macro \macro{\_ATFILE\_SOURCE} e
1358 \macro{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste
1359 esclusivamente dalla \acr{glibc}.
1363 Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
1364 comunque delle estensioni e funzionalità specifiche, non presenti in altri
1365 standard e lo stesso vale per la \acr{glibc}, che definisce anche delle
1366 ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità deve
1367 essere evitato se si ha a cuore la portabilità, ma qualora questo non sia un
1368 requisito esse possono rivelarsi molto utili.
1370 Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
1371 essere rese esplicitamente disponibili tramite la definizione di opportune
1372 macro di preprocessore, alcune di queste vengono attivate con la definizione
1373 di \macro{\_GNU\_SOURCE}, mentre altre devono essere attivate esplicitamente,
1374 inoltre alcune estensioni possono essere attivate indipendentemente tramite
1375 una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
1377 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
1379 \item[\macro{\_LARGEFILE\_SOURCE}] definendo questa macro si rendono
1380 disponibili alcune funzioni che consentono di superare una inconsistenza
1381 presente negli standard con i file di grandi dimensioni, ed in particolare
1382 definire le due funzioni \func{fseeko} e \func{ftello} che al contrario
1383 delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato
1384 specifico \type{off\_t} (vedi sez.~\ref{sec:file_io}).
1386 \item[\macro{\_LARGEFILE64\_SOURCE}] definendo questa macro si rendono
1387 disponibili le funzioni di una interfaccia alternativa al supporto di valori
1388 a 64 bit nelle funzioni di gestione dei file (non supportati in certi
1389 sistemi), caratterizzate dal suffisso \texttt{64} aggiunto ai vari nomi di
1390 tipi di dato e funzioni (come \type{off64\_t} al posto di \type{off\_t} o
1391 \funcm{lseek64} al posto di \func{lseek}).
1393 Le funzioni di questa interfaccia alternativa sono state proposte come una
1394 estensione ad uso di transizione per le \textit{Single UNIX Specification},
1395 per consentire la gestione di file di grandi dimensioni anche nei sistemi a
1396 32 bit, in cui la dimensione massima, espressa con un intero, non poteva
1397 superare i 2Gb. Nei nuovi programmi queste funzioni devono essere evitate,
1398 a favore dell'uso macro \macro{\_FILE\_OFFSET\_BITS}, che definita al valore
1399 di \texttt{64} consente di usare in maniera trasparente le funzioni
1400 dell'interfaccia classica.
1402 \item[\macro{\_FILE\_OFFSET\_BITS}] la definizione di questa macro al valore
1403 di \texttt{64} consente di attivare la conversione automatica di tutti i
1404 riferimenti a dati e funzioni a 32 bit nelle funzioni di interfaccia ai file
1405 con le equivalenti a 64 bit, senza dover utilizzare esplicitamente
1406 l'interfaccia alternativa appena illustrata. In questo modo diventa
1407 possibile usare le ordinarie funzioni per effettuare operazioni a 64 bit sui
1408 file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
1409 dopo averla definita, e saranno usate in modo trasparente le funzioni a 64
1412 Se la macro non è definita o è definita con valore \texttt{32} questo
1413 comportamento viene disabilitato, e sui sistemi a 32 bit verranno usate le
1414 ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
1415 dimensioni. Su sistemi a 64 bit invece, dove il problema non sussiste, la
1416 macro non ha nessun effetto.
1418 \item[\macro{\_ATFILE\_SOURCE}] definendo questa macro si rendono disponibili
1419 le estensioni delle funzioni di creazione, accesso e modifica di file e
1420 directory che risolvono i problemi di sicurezza insiti nell'uso di
1421 \textit{pathname} relativi con programmi \itindex{thread}
1422 \textit{multi-thread} illustrate in sez.~\ref{sec:file_openat}.
1424 \item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente
1425 \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
1426 versioni \index{funzioni!rientranti} rientranti (vedi
1427 sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si
1428 usano i \itindex{thread} \textit{thread}. Alcune di queste funzioni sono
1429 anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
1430 disponibili soltanto su alcuni sistemi, o specifiche della \acr{glibc}, e
1431 possono essere utilizzate una volta definita la macro.
1433 \item[\macro{\_FORTIFY\_SOURCE}] definendo questa macro viene abilitata
1434 l'inserimento di alcuni controlli per alcune funzioni di allocazione e
1435 manipolazione di memoria e stringhe che consentono di rilevare
1436 automaticamente alcuni errori di \textit{buffer overflow} nell'uso delle
1437 stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
1438 della \acr{glibc} e richiede anche il supporto da parte del compilatore, che
1439 è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
1441 Le funzioni di libreria che vengono messe sotto controllo quando questa
1442 funzionalità viene attivata sono, al momento della stesura di queste note,
1443 le seguenti: \funcm{memcpy}, \funcm{mempcpy}, \funcm{memmove},
1444 \funcm{memset}, \funcm{stpcpy}, \funcm{strcpy}, \funcm{strncpy},
1445 \funcm{strcat}, \funcm{strncat}, \func{sprintf}, \func{snprintf},
1446 \func{vsprintf}, \func{vsnprintf}, e \func{gets}.
1448 La macro prevede due valori, con \texttt{1} vengono eseguiti dei controlli
1449 di base che non cambiano il comportamento dei programmi se si richiede una
1450 ottimizzazione di livello uno o superiore,\footnote{vale a dire se si usa
1451 l'opzione \texttt{-O1} o superiore del \texttt{gcc}.} mentre con il
1452 valore \texttt{2} vengono aggiunti maggiori controlli. Dato che alcuni dei
1453 controlli vengono effettuati in fase di compilazione l'uso di questa macro
1454 richiede anche la collaborazione del compilatore, disponibile dalla
1455 versione 4.0 del \texttt{gcc}.
1459 Se non è stata specificata esplicitamente nessuna di queste macro il default
1460 assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
1461 \macro{\_POSIX\_SOURCE} e, con le versioni della \acr{glibc} più recenti, che
1462 la macro \macro{\_POSIX\_C\_SOURCE} abbia il valore ``\texttt{200809L}'', per
1463 versioni precedenti della \acr{glibc} il valore assegnato a
1464 \macro{\_POSIX\_C\_SOURCE} era di ``\texttt{200112L}'' prima delle 2.10, di
1465 ``\texttt{199506L}'' prima delle 2.4, di ``\texttt{199506L}'' prima delle
1466 2.1. Si ricordi infine che perché queste macro abbiano effetto devono essere
1467 sempre definite prima dell'inclusione dei file di dichiarazione.
1470 % vedi anche man feature_test_macros
1472 % LocalWords: like kernel multitasking scheduler preemptive sez swap is cap VM
1473 % LocalWords: everything bootstrap init shell Windows Foundation system call
1474 % LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods
1475 % LocalWords: Pluggable Autentication group supplementary Name Service Switch
1476 % LocalWords: LDAP identifier uid gid superuser root if BSD SVr dall' American
1477 % LocalWords: National Institute International Organisation IEC header tab gcc
1478 % LocalWords: assert ctype dirent errno fcntl limits malloc setjmp signal utmp
1479 % LocalWords: stdarg stdio stdlib string times unistd library int short caddr
1480 % LocalWords: address clock dev ino inode key IPC loff nlink off pid rlim size
1481 % LocalWords: sigset ssize ptrdiff sys IEEE Richard Portable of TR filesystem
1482 % LocalWords: Operating Interface dell'IEEE Electrical and Electronics thread
1483 % LocalWords: Engeneers Socket NT matching regular expression scheduling l'I
1484 % LocalWords: XPG Portability Issue Application Programmable XTI Transport AT
1485 % LocalWords: socket Spec Novell Specification SUSv CDE Motif Berkley select
1486 % LocalWords: SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
1487 % LocalWords: drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
1488 % LocalWords: LARGEFILE Support LFS dell' black rectangle node fill cpu draw
1489 % LocalWords: ellipse mem anchor west proc SysV SV Definition SCO Austin XSI
1490 % LocalWords: Technical TC SUS Opengroup features STRICT std ATFILE fseeko VFS
1491 % LocalWords: ftello fseek ftell lseek FORTIFY REENTRANT SAFE overflow memcpy
1492 % LocalWords: mempcpy memmove memset stpcpy strcpy strncpy strcat strncat gets
1493 % LocalWords: sprintf snprintf vsprintf vsnprintf syscall number calendar BITS
1494 % LocalWords: pathname Google Android standards device Virtual bootloader path
1495 % LocalWords: filename fifo name components resolution chroot parent symbolic
1496 % LocalWords: char block VMS raw access MacOS LF CR dos HFS Mac attributes
1497 % LocalWords: Executable Linkable Format Tool magic descriptor stream locking
1498 % LocalWords: process
1500 %%% Local Variables:
1502 %%% TeX-master: "gapil"