- embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
- togliere le parti non necessarie), e pertanto costituiscono un valido
- rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
- richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
-GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
-sistema (senza la quale niente funzionerebbe) è la GNU Standard C Library (in
-breve \acr{glibc}), ovvero la libreria realizzata dalla Free Software
-Foundation nella quale sono state implementate tutte le funzioni essenziali
-definite negli standard POSIX e ANSI C, utilizzabili da qualunque programma.
-
-Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
-\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
-\cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al sistema del
-kernel; è importante avere presente questa distinzione, fondamentale dal punto
-di vista dell'implementazione, anche se poi, nella realizzazione di normali
-programmi, non si hanno differenze pratiche fra l'uso di una funzione di
-libreria e quello di una chiamata al sistema.
-
+ embedded per le loro dimensioni estremamente ridotte (e soprattutto per la
+ possibilità di togliere le parti non necessarie), e pertanto costituiscono
+ un valido rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati
+ che richiedono una minima occupazione di memoria, un'altra versione di
+ queste librerie è quella realizzata da Google per Android.} si dovrebbe
+usare il nome GNU/Linux (piuttosto che soltanto Linux) in quanto una parte
+essenziale del sistema (senza la quale niente funzionerebbe) è la \textit{GNU
+ Standard C Library} (in breve \acr{glibc}), ovvero la libreria realizzata
+dalla Free Software Foundation nella quale sono state implementate tutte le
+funzioni essenziali definite negli standard POSIX e ANSI C, utilizzate da
+qualunque programma.
+
+Le funzioni della libreria standard sono quelle riportate dalla terza sezione
+del \textsl{Manuale di Programmazione di Unix} (cioè accessibili con il
+comando \cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al
+sistema del kernel; è importante avere presente questa distinzione,
+fondamentale dal punto di vista dell'implementazione, anche se poi, nella
+realizzazione di normali programmi, non si hanno differenze pratiche fra l'uso
+di una funzione di libreria e quello di una chiamata al sistema.
+
+Le librerie standard del C GNU consentono comunque, nel caso non sia presente
+una specifica funzione di libreria corrispondente, di eseguire una
+\textit{system call} generica tramite la funzione \funcd{syscall}, il cui
+prototipo, accessibile se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) è:
+\begin{functions}
+ \headdecl{unistd.h}
+ \headdecl{sys/syscall.h}
+ \funcdecl{int syscall(int number, ...)}
+
+ Esegue la \textit{system call} indicata da \param{number}.
+\end{functions}
+
+La funzione richiede come primo argomento il numero della \textit{system call}
+da invocare, seguita dagli argomenti da passare alla stessa (che ovviamente
+dipendono da quest'ultima), e restituisce il codice di ritorno della
+\textit{system call} invocata. In generale un valore nullo indica il successo
+ed un valore negativo è un codice di errore che poi viene memorizzato nella
+variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
+sez.~\ref{sec:sys_errors}).
+
+Il valore di \param{number} dipende sia dalla versione di kernel che
+dall'architettura,\footnote{in genere le vecchie \textit{system call} non
+ vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
+ciascuna \textit{system call} viene in genere identificata da una costante
+nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
+corrisponde anche alla omonima funzione di libreria; queste costanti sono
+definite nel file \texttt{sys/syscall.h}, ma si possono anche usare
+direttamente valori numerici.
+
+%
+% TODO:trattare non so se qui o altrove vsyscall e vDSO, vedi
+% http://davisdoesdownunder.blogspot.com/2011/02/linux-syscall-vsyscall-and-vdso-oh-my.html
+% http://www.win.tue.nl/~aeb/linux/lk/lk-4.html
+%