%% intro.tex
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\begin{figure}[htb]
\centering
- \includegraphics[width=10cm]{img/struct_sys}
+ \includegraphics[width=11cm]{img/struct_sys}
% \begin{tikzpicture}
% \filldraw[fill=black!20] (0,0) rectangle (7.5,1);
% \draw (3.75,0.5) node {\textsl{System Call Interface}};
ad una funzione con lo stesso nome definita all'interno della libreria
fondamentale del sistema, quella che viene chiamata \textsl{Libreria Standard
del C} (\textit{C Standard Library}) in ragione del fatto che il primo
-kernel Unix e tutti i programmi eseguiti su di esso vennero scritti in C,
-usando le librerie di questo linguaggio. In seguito faremo riferimento alle
+kernel Unix e tutti i programmi eseguiti su di esso vennero scritti in questo
+linguaggio, usando le sue librerie. In seguito faremo riferimento alle
funzioni di questa libreria che si interfacciano alle \textit{system call}
come ``\textsl{funzioni di sistema}''.
-Questa libreria infatti, oltre alle interfacce delle \textit{system call},
+Questa libreria infatti, oltre alle chiamate alle \textit{system call},
contiene anche tutta una serie di ulteriori funzioni di utilità che vengono
comunemente usate nella programmazione e sono definite nei vari standard che
documentano le interfacce di programmazione di un sistema unix-like. Questo
concetto è importante da tener presente perché programmare in Linux significa
-anche essere in grado di usare le funzioni fornite dalla \textsl{Libreria
- Standard del C}, in quanto né il kernel, né il linguaggio C implementano
-direttamente operazioni ordinarie come l'allocazione dinamica della memoria,
-l'input/output bufferizzato sui file o la manipolazione delle stringhe, la
-matematica in virgola mobile, che sono comunemente usate da qualunque
-programma.
+anche essere in grado di usare le funzioni fornite dalla libreria Standard del
+C, in quanto né il kernel né il linguaggio C implementano direttamente
+operazioni ordinarie come l'allocazione dinamica della memoria, l'input/output
+bufferizzato sui file, la manipolazione delle stringhe, la matematica in
+virgola mobile, che sono comunemente usate da qualunque programma.
Tutto ciò mette nuovamente in evidenza il fatto che nella stragrande
maggioranza dei casi si dovrebbe usare il nome GNU/Linux in quanto una parte
essenziale del sistema, senza la quale niente funzionerebbe, è appunto la
\textit{GNU Standard C Library} (a cui faremo da qui in avanti riferimento
-come \acr{glibc}), ovvero la Libreria Standard del C realizzata dalla Free
-Software Foundation, nella quale sono state implementate tutte le funzioni
-essenziali definite negli standard POSIX e ANSI C (e molte altre), che vengono
-utilizzate da qualunque programma.
+come \acr{glibc}), la libreria standard del C realizzata dalla Free Software
+Foundation nella quale sono state implementate tutte le funzioni essenziali
+definite negli standard POSIX e ANSI C (e molte altre), che vengono utilizzate
+da qualunque programma.
Si tenga comunque presente che questo non è sempre vero, dato che esistono
-implementazioni alternative della Libreria Standard del C, come la
+implementazioni alternative della libreria standard del C, come la
\textit{libc5} o la \textit{uClib}, che non derivano dal progetto GNU. La
\textit{libc5}, che era usata con le prime versioni del kernel Linux, è oggi
ormai completamente soppiantata dalla \acr{glibc}. La \textit{uClib} invece,
e soprattutto per la possibilità di togliere le parti non necessarie. Pertanto
costituisce un valido rimpiazzo della \acr{glibc} in tutti quei sistemi
specializzati che richiedono una minima occupazione di memoria. Infine per lo
-sviluppo del sistema Android è stata realizzata da Google un'altra Libreria
-Standard del C, utilizzata principalmente per evitare l'uso della \acr{glibc}.
+sviluppo del sistema Android è stata realizzata da Google un'altra libreria
+standard del C, utilizzata principalmente per evitare l'uso della \acr{glibc}.
-Tradizionalmente le funzioni specifiche della Libreria Standard del C sono
+Tradizionalmente le funzioni specifiche della libreria standard del C sono
riportate nella terza sezione del \textsl{Manuale di Programmazione di Unix}
(cioè accessibili con il comando \cmd{man 3 <nome>}) e come accennato non sono
direttamente associate ad una \textit{system call} anche se, ad esempio per la
gestione dei file o della allocazione dinamica della memoria, possono farne
-uso nella loro implementazione. Nonostante questa questa distinzione,
-fondamentale per capire il funzionamento del sistema, l'uso da parte dei
-programmi di una di queste funzioni resta lo stesso, sia che si tratti di una
-funzione interna della libreria che di una \textit{system call}.
+uso nella loro implementazione. Nonostante questa distinzione, fondamentale
+per capire il funzionamento del sistema, l'uso da parte dei programmi di una
+di queste funzioni resta lo stesso, sia che si tratti di una funzione interna
+della libreria che di una \textit{system call}.
\subsection{Un sistema multiutente}
estensioni.
Il concetto base è quello di utente (\textit{user}) del sistema, le cui
-capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
-Sono così previsti una serie di meccanismi per identificare i singoli utenti
-ed una serie di permessi e protezioni per impedire che utenti diversi possano
-danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono
-realizzati dal kernel stesso ed attengono alle operazioni più varie, e
-torneremo su di essi in dettaglio più avanti.
+capacità sono sottoposte a limiti precisi. Sono così previsti una serie di
+meccanismi per identificare i singoli utenti ed una serie di permessi e
+protezioni per impedire che utenti diversi possano danneggiarsi a vicenda o
+danneggiare il sistema. Questi meccanismi sono realizzati dal kernel stesso ed
+attengono alle operazioni più varie, e torneremo su di essi in dettaglio più
+avanti.
Normalmente l'utente è identificato da un nome (il cosiddetto
\textit{username}), che ad esempio è quello che viene richiesto all'ingresso
l'identità dell'utente, in genere attraverso la richiesta di una parola
d'ordine (la \textit{password}), anche se sono possibili meccanismi
diversi.\footnote{ad esempio usando la libreria PAM (\textit{Pluggable
- Autentication Methods}) è possibile astrarre completamente dai meccanismi
- di autenticazione e sostituire ad esempio l'uso delle password con
- meccanismi di identificazione biometrica, per un approfondimento
- dell'argomento si rimanda alla sez.~4.3 di \cite{AGL}.} Eseguita la
-procedura di riconoscimento in genere il sistema manda in esecuzione un
-programma di interfaccia (che può essere la \textit{shell} su terminale o
-un'interfaccia grafica) che mette a disposizione dell'utente un meccanismo con
-cui questo può impartire comandi o eseguire altri programmi.
+ Autentication Methods}) è possibile generalizzare i meccanismi di
+ autenticazione e sostituire ad esempio l'uso delle password con meccanismi
+ di identificazione biometrica; per un approfondimento dell'argomento si
+ rimanda alla sez.~4.3.7 di \cite{AGL}.} Eseguita la procedura di
+riconoscimento in genere il sistema manda in esecuzione un programma di
+interfaccia (che può essere la \textit{shell} su terminale o un'interfaccia
+grafica) che mette a disposizione dell'utente un meccanismo con cui questo può
+impartire comandi o eseguire altri programmi.
Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
\textit{default group}), ma può essere associato ad altri gruppi (i
del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
-%Rimosse
-% \section{L'architettura della gestione dei file}
-% \label{sec:file_arch_func}
-
\section{L'architettura di file e directory}
\label{sec:intro_file_dir}
che consenta di operare sui file, sia che questi corrispondano ai normali file
di dati, o ai cosiddetti ``\textsl{file speciali}'', come i file di
dispositivo (o \textit{device file}) che permettono di accedere alle
-periferiche o le fifo ed i socket che forniscono funzionalità di comunicazione
-fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
+periferiche o le \textit{fifo} ed i socket che forniscono funzionalità di
+comunicazione fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
Il secondo aspetto è che per poter utilizzare dei normali file di dati il
kernel deve provvedere ad organizzare e rendere accessibile in maniera
\itindbeg{Virtual~File~System~(VFS)}
In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual File System} (che da qui in poi abbrevieremo in
-VFS) che è uno strato intermedio che il kernel usa per accedere ai più
-svariati filesystem mantenendo la stessa interfaccia per i programmi in
-\textit{user space}.
-
-Il VFS fornisce cioè quel livello di astrazione che permette di collegare le
-operazioni interne del kernel per la manipolazione sui file con le
-\textit{system call} relative alle operazioni di I/O, e gestisce poi
+attraverso il cosiddetto \textit{Virtual File System} (da qui in avanti VFS)
+che è uno strato intermedio che il kernel usa per accedere ai più svariati
+filesystem mantenendo la stessa interfaccia per i programmi in \textit{user
+ space}. Il VFS fornisce quel livello di astrazione che permette di
+collegare le operazioni interne del kernel per la manipolazione sui file con
+le \textit{system call} relative alle operazioni di I/O, e gestisce poi
l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem
le effettuano, permettendo la coesistenza di filesystem differenti all'interno
dello stesso albero delle directory. Approfondiremo il funzionamento di
In sostanza quello che accade è che quando un processo esegue una
\textit{system call} che opera su un file, il kernel chiama sempre una
funzione implementata nel VFS. La funzione eseguirà le manipolazioni sulle
-strutture generiche e utilizzerà poi la chiamata alle opportune funzioni del
-filesystem specifico a cui si fa riferimento. Saranno queste a chiamare le
-funzioni di più basso livello che eseguono le operazioni di I/O sul
-dispositivo fisico, secondo lo schema riportato in
+strutture generiche e utilizzerà poi delle chiamate alle opportune funzioni
+del filesystem specifico a cui si fa riferimento. Saranno queste infine a
+chiamare le funzioni di più basso livello che eseguono le operazioni di I/O
+sul dispositivo fisico, secondo lo schema riportato in
fig.~\ref{fig:file_VFS_scheme}.
\begin{figure}[!htb]
\centering
- \includegraphics[width=7cm]{img/vfs}
+ \includegraphics[width=8cm]{img/vfs}
\caption{Schema delle operazioni del VFS.}
\label{fig:file_VFS_scheme}
\end{figure}
insieme al lancio di \cmd{init},\footnote{l'operazione è ovviamente anche
preliminare al lancio di \cmd{init}, dato il kernel deve poter accedere al
file che contiene detto programma.} l'unica operazione che viene effettuata
-direttamente dal kernel in fase di avvio quando, completata la fase di
-inizializzazione, esso riceve dal bootloader l'indicazione di quale
-dispositivo contiene il filesystem da usare come punto di partenza e questo
-viene posto alla radice dell'albero dei file.
+direttamente dal kernel in fase di avvio. Il kernel infatti, completata la
+fase di inizializzazione, utilizza l'indicazione passatagli dal
+\textit{bootloader} su quale sia il dispositivo che contiene il filesystem da
+usare come punto di partenza, lo monta come radice dell'albero dei file.
Tutti gli ulteriori filesystem che possono essere disponibili su altri
-dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli su
+dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli in
altrettante directory del filesystem radice, su quelli che vengono chiamati
-\textit{mount point}. Questo comunque avverrà sempre in un secondo tempo, in
-genere a cura dei programmi eseguiti nella procedura di inizializzazione del
-sistema, grazie alle funzioni che tratteremo in
-sez.~\ref{sec:filesystem_mounting}.
+\textit{mount point}. Questo comunque avverrà sempre in un secondo tempo, a
+cura dei programmi eseguiti nella procedura di inizializzazione del sistema,
+grazie alle funzioni che tratteremo in sez.~\ref{sec:filesystem_mounting}.
\subsection{La risoluzione del nome di file e directory}
\itindbeg{pathname}
-Come illustrato sez.~\ref{sec:file_arch_overview} una delle caratteristiche
-distintive di un sistema unix-like è quella di avere un unico albero dei
-file. Un file deve essere identificato dall'utente usando quello che viene
-chiamato il suo \textit{pathname},\footnote{il manuale della \acr{glibc}
- depreca questa nomenclatura, che genererebbe confusione poiché \textit{path}
- indica anche un insieme di directory su cui effettuare una ricerca (come
- quello in cui la shell cerca i comandi). Al suo posto viene proposto l'uso
- di \textit{filename} e di componente per il nome del file all'interno della
- directory. Non seguiremo questa scelta dato che l'uso della parola
- \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più
- chiaro dell'alternativa proposta.} vale a dire tramite il
+Come appena illustrato sez.~\ref{sec:file_arch_overview} una delle
+caratteristiche distintive di un sistema unix-like è quella di avere un unico
+albero dei file. Un file deve essere identificato dall'utente usando quello
+che viene chiamato il suo \textit{pathname},\footnote{il manuale della
+ \acr{glibc} depreca questa nomenclatura, che genererebbe confusione poiché
+ \textit{path} indica anche un insieme di directory su cui effettuare una
+ ricerca (come quello in cui la shell cerca i comandi). Al suo posto viene
+ proposto l'uso di \textit{filename} e di componente per il nome del file
+ all'interno della directory. Non seguiremo questa scelta dato che l'uso
+ della parola \textit{pathname} è ormai così comune che mantenerne l'uso è
+ senz'altro più chiaro dell'alternativa proposta.} vale a dire tramite il
``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
\textit{pathname}) che si deve fare per accedere al file a partire da una
certa ``\textit{directory}''.
un'organizzazione ad albero inserendo nomi di directory dentro altre
directory. All'interno dello stesso albero si potranno poi inserire anche
tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
-sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
-socket e gli stessi file di dispositivo.
+sez.~\ref{sec:file_file_types}), come le \textit{fifo}, i collegamenti
+simbolici, i socket e gli stessi file di dispositivo.
La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
nomi che indicano le directory che lo compongono. Dato che la directory radice
sta in cima all'albero, essa viene indicata semplicemente con il
-\textit{pathname} \file{/}.
+\textit{pathname} ``\file{/}''.
\itindbeg{pathname~resolution}
diversi fra loro. Oltre ai normali file di dati abbiamo già accennato ad altri
due di questi oggetti, i file di dispositivo e le directory, ma ne esistono
altri. In genere quando si parla di tipo di file su Linux si fa riferimento a
-questi, di cui si riportato l'elenco completo in
+questi diversi tipi, di cui si riportato l'elenco completo in
tab.~\ref{tab:file_file_types}.
\begin{table}[htb]
\textit{block device}& \textsl{dispositivo a blocchi}
& Un file \textsl{speciale} che identifica una
periferica ad accesso a blocchi.\\
- \textit{fifo} & ``\textsl{coda}''
+ \textit{fifo} & ``\textsl{coda}''
& Un file \textsl{speciale} che identifica una
linea di comunicazione unidirezionale (vedi
sez.~\ref{sec:ipc_named_pipe}).\\
- \textit{socket} & ``\textsl{presa}''
+ \textit{socket} & ``\textsl{presa}''
& Un file \textsl{speciale} che identifica una
linea di comunicazione bidirezionale (vedi
cap.~\ref{cha:socket_intro}).\\
\end{table}
Si tenga ben presente che questa classificazione non ha nulla a che fare con
-una classificazione dei file in base al tipo loro del contenuto, dato che in
-tal caso si avrebbe a che fare sempre e solo con dei file di dati. E non ha
-niente a che fare neanche con le eventuali diverse modalità con cui si
-potrebbe accedere al contenuto dei file di dati. La classificazione di
+una classificazione dei file in base al loro contenuto, dato che in tal caso
+si avrebbe a che fare sempre e solo con dei file di dati. E non ha niente a
+che fare neanche con le eventuali diverse modalità con cui si possa accedere
+al contenuto dei file di dati. La classificazione di
tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
\textit{Virtual File System}, ed è da notare la presenza dei cosiddetti file
``\textsl{speciali}''.
proprio quei \textsl{file di dispositivo} che costituiscono una interfaccia
diretta per leggere e scrivere sui dispositivi fisici. Anche se finora li
abbiamo chiamati genericamente così, essi sono tradizionalmente suddivisi in
-due grandi categorie, \textsl{a blocchi} e \textsl{a caratteri} a seconda
+due grandi categorie, \textsl{a blocchi} e \textsl{a caratteri}, a seconda
delle modalità in cui il dispositivo sottostante effettua le operazioni di
I/O.
dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
ed è completamente trasparente all'utente; inoltre talvolta si parla di
\textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
- fare con tutto ciò, di effettuare, attraverso degli appositi file di
- dispositivo, operazioni di I/O direttamente sui dischi senza passare
+ fare con tutto ciò, di effettuare attraverso degli appositi file di
+ dispositivo delle operazioni di I/O direttamente sui dischi senza passare
attraverso un filesystem, il cosiddetto \textit{raw access}, introdotto coi
kernel della serie 2.4.x ma ormai in sostanziale disuso.}
file con gli \textit{extended attributes} (vedi sez.~\ref{sec:file_xattr}),
ma è una caratteristica tutt'ora poco utilizzata, dato che non corrisponde
al modello classico dei file in un sistema Unix.} ogni classificazione di
-questo tipo avviene sempre in \textit{user-space}. Gli unici file di cui il
+questo tipo avviene sempre in \textit{user space}. Gli unici file di cui il
kernel deve essere in grado di capire il contenuto sono i binari dei
programmi, per i quali sono supportati solo alcuni formati, anche se oggi
-viene usato quasi esclusivamente l'ELF.\footnote{il nome è l'acronimo di
- \textit{Executable and Linkable Format}, un formato per eseguibili binari
- molto flessibile ed estendibile definito nel 1995 dal \textit{Tool Interface
- Standard} che per le sue caratteristiche di non essere legato a nessun
- tipo di processore o architettura è stato adottato da molti sistemi
- unix-like e non solo.}
+viene usato quasi esclusivamente
+\itindex{Executable~and~Linkable~Format~(ELF)} l'ELF.\footnote{il nome è
+ l'acronimo di \textit{Executable and Linkable Format}, un formato per
+ eseguibili binari molto flessibile ed estendibile definito nel 1995 dal
+ \textit{Tool Interface Standard} che per le sue caratteristiche di non
+ essere legato a nessun tipo di processore o architettura è stato adottato da
+ molti sistemi unix-like e non solo.}
\itindbeg{magic~number}
Nonostante l'assenza di supporto da parte del kernel per la classificazione
del contenuto dei file di dati, molti programmi adottano comunque delle
convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
-in file con l'estensione \file{.c}. Inoltre una tecnica molto usata per
+in file con l'estensione ``\file{.c}''. Inoltre una tecnica molto usata per
classificare i contenuti da parte dei programmi è quella di utilizzare i primi
byte del file per memorizzare un ``\textit{magic number}'' che ne classifichi
il contenuto. Il concetto è quello di un numero intero, solitamente fra 2 e 10
\itindbeg{file~descriptor}
In Linux le interfacce di programmazione per l'I/O su file due. La prima è
-l'interfaccia nativa del sistema, quella che il manuale delle \textsl{glibc}
+l'interfaccia nativa del sistema, quella che il manuale della \textsl{glibc}
chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
\textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
sistemi unix-like che fornisce un accesso non bufferizzato.
kernel negli Unix derivati da \textit{System V}, come strato di astrazione
per file e socket; in Linux questa interfaccia, che comunque ha avuto poco
successo, non esiste, per cui facendo riferimento agli \textit{stream}
- useremo il significato adottato dal manuale delle \acr{glibc}.} Essa
+ useremo il significato adottato dal manuale della \acr{glibc}.} Essa
fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
-implementazione fatta nella \acr{glibc}. Questa è l'interfaccia standard
-specificata dall'ANSI C e perciò si trova anche su tutti i sistemi non
-Unix. Gli \textit{stream} sono oggetti complessi e sono rappresentati da
-puntatori ad un opportuna struttura definita dalle librerie del C, ad essi si
-accede sempre in maniera indiretta utilizzando il tipo \code{FILE *}.
-L'interfaccia è definita nell'\textit{header file} \headfile{stdio.h} e la
-tratteremo in dettaglio in sez.~\ref{sec:files_std_interface}.
+implementazione fatta nella \acr{glibc}. Questa è l'interfaccia specificata
+dallo standard ANSI C e perciò si trova anche su tutti i sistemi non Unix. Gli
+\textit{stream} sono oggetti complessi e sono rappresentati da puntatori ad un
+opportuna struttura definita dalle librerie del C, a cui si accede sempre in
+maniera indiretta utilizzando il tipo \code{FILE *}; l'interfaccia è definita
+nell'\textit{header file} \headfile{stdio.h} e la tratteremo in dettaglio in
+sez.~\ref{sec:files_std_interface}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS, ma per poter accedere alle operazioni di controllo
interfacce di programmazione e le altre caratteristiche di un sistema
unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
ed in particolare ci concentreremo sul come ed in che modo essi sono
-supportati sia per quanto riguarda il kernel che la Libreria Standard del C,
+supportati sia per quanto riguarda il kernel che la libreria standard del C,
con una particolare attenzione alla \acr{glibc}.
\subsection{Lo standard ANSI C}
\label{sec:intro_ansiC}
+\itindbeg{ANSI~C}
Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
Standard Institute} come prima standardizzazione del linguaggio C e per
questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
vari \textit{header file} soltanto le funzionalità previste dallo standard
ANSI C e a non usare le varie estensioni al linguaggio e al preprocessore da
esso supportate.
+\itindend{ANSI~C}
\subsection{I tipi di dati primitivi}
\textbf{Tipo} & \textbf{Contenuto} \\
\hline
\hline
- \type{caddr\_t} & Core address.\\
- \type{clock\_t} & Contatore del \textit{process time} (vedi
+ \typed{caddr\_t} & Core address.\\
+ \typed{clock\_t} & Contatore del \textit{process time} (vedi
sez.~\ref{sec:sys_cpu_times}.\\
- \type{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
- \type{gid\_t} & Identificatore di un gruppo (vedi
+ \typed{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
+ \typed{gid\_t} & Identificatore di un gruppo (vedi
sez.~\ref{sec:proc_access_id}).\\
- \type{ino\_t} & Numero di \textit{inode}
+ \typed{ino\_t} & Numero di \textit{inode}
(vedi sez.~\ref{sec:file_vfs_work}).\\
- \type{key\_t} & Chiave per il System V IPC (vedi
+ \typed{key\_t} & Chiave per il System V IPC (vedi
sez.~\ref{sec:ipc_sysv_generic}).\\
- \type{loff\_t} & Posizione corrente in un file.\\
- \type{mode\_t} & Attributi di un file.\\
- \type{nlink\_t} & Contatore dei collegamenti su un file.\\
- \type{off\_t} & Posizione corrente in un file.\\
- \type{pid\_t} & Identificatore di un processo (vedi
+ \typed{loff\_t} & Posizione corrente in un file.\\
+ \typed{mode\_t} & Attributi di un file.\\
+ \typed{nlink\_t} & Contatore dei collegamenti su un file.\\
+ \typed{off\_t} & Posizione corrente in un file.\\
+ \typed{pid\_t} & Identificatore di un processo (vedi
sez.~\ref{sec:proc_pid}).\\
- \type{rlim\_t} & Limite sulle risorse.\\
- \type{sigset\_t}& Insieme di segnali (vedi sez.~\ref{sec:sig_sigset}).\\
- \type{size\_t} & Dimensione di un oggetto.\\
- \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
- \type{ptrdiff\_t}& Differenza fra due puntatori.\\
- \type{time\_t} & Numero di secondi (in \textit{calendar time}, vedi
+ \typed{rlim\_t} & Limite sulle risorse.\\
+ \typed{sigset\_t}& Insieme di segnali (vedi sez.~\ref{sec:sig_sigset}).\\
+ \typed{size\_t} & Dimensione di un oggetto.\\
+ \typed{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
+ \typed{ptrdiff\_t}& Differenza fra due puntatori.\\
+ \typed{time\_t} & Numero di secondi (in \textit{calendar time}, vedi
sez.~\ref{sec:sys_time}).\\
- \type{uid\_t} & Identificatore di un utente (vedi
+ \typed{uid\_t} & Identificatore di un utente (vedi
sez.~\ref{sec:proc_access_id}).\\
\hline
\end{tabular}
Unix System V, e si fa rifermento a questa implementazione con la sigla SysV o
SV.
-Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
-con aggiunte e integrazioni, ed in particolare la \textit{release 2} nel 1985,
-a cui si fa riferimento con SVr2 e la \textit{release 3} nel 1986 (denominata
-SVr3). Le interfacce di programmazione di queste due versioni vennero
-descritte formalmente in due documenti denominati \textit{System V Interface
- Definition} (o SVID), pertanto nel 1995 venne rilasciata la specifica SVID 1
-e nel 1986 la specifica SVID 2.
+Negli anni successivi l'AT\&T proseguì lo sviluppo del sistema rilasciando
+varie versioni con aggiunte e integrazioni, ed in particolare la
+\textit{release 2} nel 1985, a cui si fa riferimento con il nome SVr2 e la
+\textit{release 3} nel 1986 (denominata SVr3). Le interfacce di programmazione
+di queste due versioni vennero descritte formalmente in due documenti
+denominati \itindex{System~V~Interface~Definition~(SVID)} \textit{System V
+ Interface Definition} (o SVID), pertanto nel 1985 venne rilasciata la
+specifica SVID 1 e nel 1986 la specifica SVID 2.
Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
versione di System V che provvedeva un'unificazione delle interfacce
successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
al consorzio X/Open. L'ultima versione di System V fu la SVr4.2MP rilasciata
-nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
+nel dicembre 1993. Infine nel 1995 è stata rilasciata da SCO, che aveva
acquisito alcuni diritti sul codice di System V, una ulteriore versione delle
\textit{System V Interface Description}, che va sotto la denominazione di SVID
4.
-Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
+Linux e la \acr{glibc} implementano le principali funzionalità richieste dalle
specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
-denominazioni usate diventa particolarmente faticoso; una pagina dove si
-possono recuperare varie (e di norma piuttosto intricate) informazioni è
-\url{http://www.pasc.org/standing/sd11.html}.
+denominazioni usate diventa particolarmente faticoso.
\begin{table}[htb]
\footnotesize
interfacce, la obsolescenza di altre, la trasformazione da opzionali a
richieste di alcune specifiche di base, oltre alle solite precisazioni ed
aggiornamenti. Anche in questo caso è prevista la suddivisione in una
-conformità di base, e delle interfacce aggiuntive.
+conformità di base, e delle interfacce aggiuntive. Una ulteriore revisione è
+stata pubblicata nel 2017 come POSIX.1-2017.
Le procedure di aggiornamento dello standard POSIX prevedono comunque un
percorso continuo, che prevede la possibilità di introduzione di nuove
interfacce e la definizione di precisazioni ed aggiornamenti, per questo in
futuro verranno rilasciate nuove versioni. Alla stesura di queste note
-l'ultima revisione approvata resta POSIX.1-2008, uno stato della situazione
+l'ultima revisione approvata resta POSIX.1-2017, uno stato della situazione
corrente del supporto degli standard è allegato alla documentazione della
\acr{glibc} e si può ottenere con il comando \texttt{man standards}.
Unix, che venne presa come riferimento da vari produttori. Questo standard,
detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
-delle API\footnote{le \textit{Application Programmable Interface}, in sostanze
- le interfacce di programmazione.} per l'interfaccia grafica (X11).
+delle API (sigla che sta per \textit{Application Programmable Interface}, in
+italiano interfaccia di programmazione) per l'interfaccia grafica (X11).
Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{X
\label{sec:intro_gcc_glibc_std}
In Linux, se si usa la \acr{glibc}, la conformità agli standard appena
-descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
-compilatore (il \texttt{gcc}) che definendo delle specifiche costanti prima
-dell'inclusione dei file di intestazione (gli \textit{header file}, vedi
-sez.~\ref{sec:proc_syscall}) che definiscono le funzioni di libreria.
+descritti può essere richiesta sia attraverso l'uso di alcune opzioni del
+compilatore (il \texttt{gcc}) che con la definizione di opportune costanti
+prima dell'inclusione dei file di intestazione (gli \textit{header file}, vedi
+sez.~\ref{sec:proc_syscall}) in cui le varie funzioni di libreria vengono
+definite.
Ad esempio se si vuole che i programmi seguano una stretta attinenza allo
standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
(vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
-allo standard C99.\footnote{che non è al momento completa, esistono anche le
- possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
- l'uso delle estensioni GNU al C89, riprese poi dal C99, o \texttt{gnu89} che
- indica il dialetto GNU del C99, che diventerà il default quando la
- conformità a quest'ultimo sarà completa.}
+allo standard C99 o \texttt{c11} per indicare la conformità allo standard C11
+(revisione del 2011).\footnote{esistono anche le possibilità di usare i valori
+ \texttt{gnu89}, che indica l'uso delle estensioni GNU al C89, riprese poi
+ dal C99, \texttt{gnu99} che indica il dialetto GNU del C99, o \texttt{gnu11}
+ che indica le estensioni GNU al C11, lo standard adottato di default dipende
+ dalla versione del \texttt{gcc}, ed all'agosto 2018 con la versione 8.2 è
+ \texttt{gnu11}.}
Per attivare le varie opzioni di controllo di aderenza agli standard è poi
possibile definire delle macro di preprocessore che controllano le
definito una di queste macro, l'effetto sarà quello di dare la precedenza
alle funzioni in forma BSD. Questa macro, essendo ricompresa in
\macro{\_DEFAULT\_SOURCE} che è definita di default, è stata deprecata a
- partire dalle \acr{glibc} 2.20.
+ partire dalla \acr{glibc} 2.20.
\item[\macrod{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
precedenza. Questa macro, essendo ricompresa in \macro{\_DEFAULT\_SOURCE}
- che è definita di default, è stata deprecata a partire dalle \acr{glibc}
+ che è definita di default, è stata deprecata a partire dalla \acr{glibc}
2.20.
\item[\macrod{\_DEFAULT\_SOURCE}] questa macro abilita le definizioni
considerate il \textit{default}, comprese quelle richieste dallo standard
- POSIX.1-2008, ed è sostanzialente equivalente all'insieme di
+ POSIX.1-2008, ed è sostanzialmente equivalente all'insieme di
\macro{\_SVID\_SOURCE}, \macro{\_BSD\_SOURCE} e
\macro{\_POSIX\_C\_SOURCE}. Essendo predefinita non è necessario usarla a
meno di non aver richiesto delle definizioni più restrittive sia con altre
macro che con i flag del compilatore, nel qual caso abilita le funzioni che
altrimenti sarebbero disabilitate. Questa macro è stata introdotta a partire
- dalle \acr{glibc} 2.19 e consente di deprecare \macro{\_SVID\_SOURCE} e
+ dalla \acr{glibc} 2.19 e consente di deprecare \macro{\_SVID\_SOURCE} e
\macro{\_BSD\_SOURCE}.
\item[\macrod{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
\end{itemize}
\item[\macrod{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono
- disponibili le ulteriori funzionalità necessarie ad essere conformi al
+ disponibili le ulteriori funzionalità necessarie la conformità al
rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard
Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene
definita implicitamente tutte le volte che si imposta
presente negli standard con i file di grandi dimensioni, ed in particolare
definire le due funzioni \func{fseeko} e \func{ftello} che al contrario
delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato
- specifico \ctyp{off\_t} (vedi sez.~\ref{sec:file_io}).
+ specifico \type{off\_t} (vedi sez.~\ref{sec:file_io}).
\item[\macrod{\_LARGEFILE64\_SOURCE}] definendo questa macro si rendono
disponibili le funzioni di una interfaccia alternativa al supporto di valori
a 64 bit nelle funzioni di gestione dei file (non supportati in certi
sistemi), caratterizzate dal suffisso \texttt{64} aggiunto ai vari nomi di
- tipi di dato e funzioni (come \type{off64\_t} al posto di \type{off\_t} o
+ tipi di dato e funzioni (come \typed{off64\_t} al posto di \type{off\_t} o
\funcm{lseek64} al posto di \func{lseek}).
Le funzioni di questa interfaccia alternativa sono state proposte come una
le estensioni delle funzioni di creazione, accesso e modifica di file e
directory che risolvono i problemi di sicurezza insiti nell'uso di
\textit{pathname} relativi con programmi \textit{multi-thread} illustrate in
- sez.~\ref{sec:file_openat}.
+ sez.~\ref{sec:file_openat}. Dalla \acr{glibc} 2.10 questa macro viene
+ definita implicitamente se si definisce \macro{\_POSIX\_C\_SOURCE} ad un
+ valore maggiore o uguale di ``\texttt{200809L}''.
\item[\macrod{\_REENTRANT}] definendo questa macro, o la equivalente
- \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
- versioni rientranti (vedi sez.~\ref{sec:proc_reentrant}) di alcune funzioni,
- necessarie quando si usano i \textit{thread}. Alcune di queste funzioni
- sono anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
- disponibili soltanto su alcuni sistemi, o specifiche della \acr{glibc}, e
- possono essere utilizzate una volta definita la macro.
+ \macrod{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili
+ le versioni rientranti (vedi sez.~\ref{sec:proc_reentrant}) di alcune
+ funzioni, necessarie quando si usano i \textit{thread}. Alcune di queste
+ funzioni sono anche previste nello standard POSIX.1c, ma ve ne sono altre
+ che sono disponibili soltanto su alcuni sistemi, o specifiche della
+ \acr{glibc}, e possono essere utilizzate una volta definita la macro. Oggi
+ la macro è obsoleta, già dalla \acr{glibc} 2.3 le funzioni erano già
+ completamente rientranti e dalla \acr{glibc} 2.25 la macro è equivalente ad
+ definire \macro{\_POSIX\_C\_SOURCE} con un valore di ``\texttt{199606L}''
+ mentre se una qualunque delle altre macro che richiede un valore di
+ conformità più alto è definita, la sua definizione non ha alcun effetto.
\item[\macrod{\_FORTIFY\_SOURCE}] definendo questa macro viene abilitata
l'inserimento di alcuni controlli per alcune funzioni di allocazione e
% vedi anche man feature_test_macros
+% TODO: forse può essere interessante trattare i tunables delle glibc, vedi:
+% https://siddhesh.in/posts/the-story-of-tunables.html e
+% https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=README.tunables;h=0e9b0d7a470aabc2344ad997fca03c7663de0419;hb=HEAD
+
+
% LocalWords: like kernel multitasking scheduler preemptive sez swap is cap VM
% LocalWords: everything bootstrap init shell Windows Foundation system call
% LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods
% LocalWords: filename fifo name components resolution chroot parent symbolic
% LocalWords: char block VMS raw access MacOS LF CR dos HFS Mac attributes
% LocalWords: Executable Linkable Format Tool magic descriptor stream locking
-% LocalWords: process
+% LocalWords: process mount point ELF
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff