\section{Una panoramica}
\label{sec:intro_unix_struct}
-In questa prima sezione faremo una breve panoramica sull'architettura del
-sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
-saltare questa sezione.
+In questa prima sezione faremo una breve panoramica sull'architettura di un
+sistema tipo Unix come GNU/Linux, e della relazione fra le varie parti che lo
+compongono. Chi avesse già una conoscenza di questa materia può
+tranquillamente saltare questa sezione ad eccezione di
+sez.~\ref{sec:intro_syscall} dove introdotti alcuni concetti fondamentali
+relativi alle funzioni di libreria.
\subsection{Concetti base}
\label{sec:intro_base_concept}
-Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
-cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
+Il concetto base di un sistema unix-like è quello di un nucleo del sistema, il
+cosiddetto \textit{kernel} (nel nostro caso Linux) a cui si demanda la
gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
-dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano
-alle risorse hardware tramite delle richieste a quest'ultimo.
+dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano alle
+risorse hardware tramite opportune richieste a quest'ultimo.
Fin dall'inizio uno Unix si presenta come un sistema operativo
\textit{multitasking}, cioè in grado di eseguire contemporaneamente più
programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
-una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà,
+una macchina eseguendo più programmi ``\textsl{in contemporanea}''. In realtà,
almeno per macchine a processore singolo, i programmi vengono eseguiti
singolarmente a rotazione.
astratta che permette di trattarle come fossero file, secondo il concetto per
cui \textit{everything is a file}, su cui torneremo in dettaglio in
cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
-hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
-il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
+non rispondendo bene a detta astrazione hanno un'interfaccia diversa, ma resta
+valido anche per loro il concetto generale che tutto il lavoro di accesso e
+gestione delle periferiche a basso livello è effettuato dal kernel.
\subsection{Il kernel e il sistema}
Per questa separazione non è possibile ad un singolo programma disturbare
l'azione di un altro programma o del sistema e questo è il principale motivo
della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
-i processi non hanno di questi limiti, o che vengono per vari motivi eseguiti
-al livello del kernel. Pertanto deve essere chiaro a chi programma in Unix che
-l'accesso diretto all'hardware non può avvenire se non all'interno del kernel;
-al di fuori dal kernel il programmatore deve usare le opportune interfacce che
-quest'ultimo fornisce allo user space.
-
-Per capire meglio la distinzione fra kernel space e user space si può prendere
-in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
-in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
-avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
- un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
- stringhe delle scarpe'', per indicare il compito, almeno apparentemente
- impossibile, di far eseguire un programma a partire da un computer appena
- acceso che appunto non ne contiene nessuno; non è impossibile perché in
- realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
-caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
-dopo aver inizializzato le periferiche, farà partire il primo processo,
-\cmd{init}, che è quello che a sua volta farà partire tutti i processi
-successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
-tastiera e lo schermo della console, e quello che mette a disposizione
-dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
-inviare i comandi.
-
-E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
-sistema, non abbia in realtà niente a che fare con il kernel, ma sia
-effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
-qualunque programma di scrittura o di disegno, in user space.
-
-Questo significa, ad esempio, che il sistema di per sé non dispone di
-primitive per tutta una serie di operazioni (come la copia di un file) che
+i processi non hanno di questi limiti, o in cui vengono per vari motivi
+eseguiti al livello del kernel. Pertanto deve essere chiaro a chi programma in
+Unix che l'accesso diretto all'hardware non può avvenire se non all'interno
+del kernel; al di fuori dal kernel il programmatore deve usare le opportune
+interfacce che quest'ultimo fornisce allo \textit{user space}.
+
+Per capire meglio la distinzione fra \textit{kernel space} e \textit{user
+ space} si può prendere in esame la procedura di avvio di un sistema
+unix-like; all'avvio il BIOS (o in generale il software di avvio posto nelle
+EPROM) eseguirà la procedura di avvio del sistema (il cosiddetto
+\textit{bootstrap}\footnote{il nome deriva da un'espressione gergale che
+ significa ``sollevarsi da terra tirandosi per le stringhe delle scarpe'',
+ per indicare il compito, almeno apparentemente impossibile, di far eseguire
+ un programma a partire da un computer appena acceso che appunto non ne
+ contiene nessuno; non è impossibile perché in realtà c'è un programma
+ iniziale, che è il BIOS.}), incaricandosi di caricare il kernel in memoria e
+di farne partire l'esecuzione; quest'ultimo, dopo aver inizializzato le
+periferiche, farà partire il primo processo, \cmd{init}, che è quello che a
+sua volta farà partire tutti i processi successivi. Fra questi ci sarà pure
+quello che si occupa di dialogare con la tastiera e lo schermo della console,
+e quello che mette a disposizione dell'utente che si vuole collegare, un
+terminale e la \textit{shell} da cui inviare i comandi.
+
+E' da rimarcare come tutto ciò che riguarda l'interazione con l'utente, che
+usualmente viene visto come parte del sistema, non abbia in realtà niente a
+che fare con il kernel, ma sia effettuato da opportuni programmi che vengono
+eseguiti, allo stesso modo di un qualunque programma di scrittura o di disegno
+e della stessa interfaccia grafica, in \textit{user space}.
+
+Questo significa ad esempio che il sistema di per sé non dispone di primitive
+per tutta una serie di operazioni (ad esempio come la copia di un file) che
altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona
parte delle operazioni di normale amministrazione di un sistema, come quella
in esempio, sono implementate come normali programmi.
Per questo motivo quando ci si riferisce al sistema nella sua interezza è
corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
-di tutta una serie di librerie e programmi di utilità (che di norma sono
+di tutta una serie di librerie e programmi di utilità (i più diffusi sono
quelli realizzati dal progetto GNU della Free Software Foundation) che
permettono di eseguire le normali operazioni che ci si aspetta da un sistema
operativo.
% \includegraphics[width=10cm]{img/struct_sys}
\begin{tikzpicture}
\filldraw[fill=black!20] (0,0) rectangle (7.5,1);
- \draw (3.75,0.5) node {System Call Interface};
+ \draw (3.75,0.5) node {\textsl{System Call Interface}};
\filldraw[fill=black!35] (0,1) rectangle (7.5,4);
- \draw (3.75,2.5) node {\huge{kernel}};
+ \draw (3.75,2.5) node {\huge{\textsf{kernel}}};
\filldraw[fill=black!20] (0,4) rectangle (2.5,5);
- \draw (1.25,4.5) node {scheduler};
+ \draw (1.25,4.5) node {\textsf{scheduler}};
\filldraw[fill=black!20] (2.5,4) rectangle (5,5);
- \draw (3.75,4.5) node {VM};
+ \draw (3.75,4.5) node {\textsf{VM}};
\filldraw[fill=black!20] (5,4) rectangle (7.5,5);
- \draw (6.25,4.5) node {driver};
+ \draw (6.25,4.5) node {\textsf{driver}};
- \draw (1.25,7) node(cpu) [ellipse,draw] {CPU};
- \draw (3.75,7) node(mem) [ellipse,draw] {memoria};
- \draw (6.25,7) node(disk) [ellipse,draw] {disco};
+ \draw (1.25,7) node(cpu) [ellipse,draw] {\textsf{CPU}};
+ \draw (3.75,7) node(mem) [ellipse,draw] {\textsf{memoria}};
+ \draw (6.25,7) node(disk) [ellipse,draw] {\textsf{disco}};
\draw[<->] (cpu) -- (1.25,5);
\draw[<->] (mem) -- (3.75,5);
\draw[<->] (disk) -- (6.25,5);
- \draw (7.5,0) node [anchor=base west] {kernel space};
- \draw (7.5,-1) node [anchor=west] {user space};
+ \draw (7.5,0) node [anchor=base west] {\textit{kernel space}};
+ \draw (7.5,-1) node [anchor=west] {\textit{user space}};
\draw (-1,-0.5) -- (8.5, -0.5);
\draw (0,-2) rectangle (7.5,-1);
- \draw (3.75, -1.5) node {GNU C Library};
+ \draw (3.75, -1.5) node {\textsl{GNU C Library}};
\draw[->] (1.25,-1) -- (1.25,0);
\draw[->] (3.75,-1) -- (3.75,0);
\draw[->] (6.25,-1) -- (6.25,0);
- \draw (1.25,-3) node(proc1) [rectangle,draw] {processo};
- \draw (3.75,-3) node(proc2) [rectangle,draw] {processo};
- \draw (6.25,-3) node(proc3) [rectangle,draw] {processo};
+ \draw (1.25,-3) node(proc1) [rectangle,draw] {\textsf{processo}};
+ \draw (3.75,-3) node(proc2) [rectangle,draw] {\textsf{processo}};
+ \draw (6.25,-3) node(proc3) [rectangle,draw] {\textsf{processo}};
\draw[->] (1.25,-2) -- (proc1);
\draw[->] (3.75,-2) -- (proc2);
\end{figure}
Normalmente ciascuna di queste chiamate al sistema fornite dal kernel viene
-rimappata in opportune funzioni con lo stesso nome definite dentro la Libreria
-Standard del C, che, oltre alle interfacce alle \textit{system call}, contiene
-anche tutta la serie delle ulteriori funzioni definite dai vari standard, che
-sono comunemente usate nella programmazione.
+rimappata in opportune funzioni con lo stesso nome definite dentro la libreria
+fondamentale del sistema, chiamata \textsl{Libreria Standard del C} (\textit{C
+ Standard Library}) in ragione del fatto che il primo Unix venne scritto con
+il linguaggio C ed usando le librerie ad esso associato. Detta libreria, oltre
+alle interfacce alle \textit{system call}, contiene anche tutta la serie delle
+ulteriori funzioni di base definite nei vari standard, che sono comunemente
+usate nella programmazione.
Questo è importante da capire perché programmare in Linux significa anzitutto
-essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C implementano direttamente
-operazioni comuni come l'allocazione dinamica della memoria, l'input/output
-bufferizzato sui file o la manipolazione delle stringhe, presenti in qualunque
-programma.
+essere in grado di usare le varie funzioni fornite dalla \textsl{Libreria
+ Standard del C}, in quanto né il kernel, né il linguaggio C implementano
+direttamente operazioni comuni come l'allocazione dinamica della memoria,
+l'input/output bufferizzato sui file o la manipolazione delle stringhe,
+presenti in qualunque programma.
Quanto appena illustrato mette in evidenza il fatto che nella stragrande
maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie
dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
- 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 \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 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.
-
-Le librerie standard del C 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
+ 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}
realizzati dal kernel stesso ed attengono alle operazioni più varie, e
torneremo su di essi in dettaglio più avanti.
-Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
-viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
-(descritta in dettaglio in sez.~\ref{sec:sess_login}). Questa procedura si
-incarica di verificare 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.} 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.
+Normalmente l;utente è identificato da un nome (il cosiddetto
+\textit{username}), che ad esempio è quello che viene richiesto all'ingresso
+nel sistema dalla procedura di \textit{login} (torneremo su questo in
+sez.~\ref{sec:sess_login}). Questa procedura si incarica di verificare
+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.
Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
\textit{default group}), ma può essere associato ad altri gruppi (i
In questa sezione faremo una breve panoramica relativa ai vari standard che
nel tempo sono stati formalizzati da enti, associazioni, consorzi e
-organizzazioni varie al riguardo del sistema o alle caratteristiche che si
-sono stabilite come standard di fatto in quanto facenti parte di alcune
-implementazioni molto diffuse come BSD o System V.
+organizzazioni varie al riguardo ai sistemi operativi di tipo Unix o alle
+caratteristiche che si sono stabilite come standard di fatto in quanto facenti
+parte di alcune implementazioni molto diffuse come BSD o System V.
Ovviamente prenderemo in considerazione solo gli standard riguardanti
interfacce di programmazione e le altre caratteristiche di un sistema
di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
moderni, provvede la compatibilità con questo standard, fornendo le funzioni
di libreria da esso previste. Queste sono dichiarate in una serie di
-\textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
- funzioni, usati normalmente da un compilatore C. Per poter accedere alle
- funzioni occorre includere con la direttiva \code{\#include} questi file nei
- propri programmi; per ciascuna funzione che tratteremo in seguito
- indicheremo anche gli \textit{header file} necessari ad usarla.} (anch'essi
-provvisti dalla \acr{glibc}), In tab.~\ref{tab:intro_posix_header} si sono
-riportati i principali \textit{header file} definiti nello standard POSIX ed
-ANSI C, che sono anche quelli definiti negli altri standard descritti nelle
-sezioni successive.
+\textit{header file}\footnote{si chiamano così i file di dichiarazione di
+ variabili, tipi e funzioni, usati normalmente da un compilatore C; per poter
+ accedere alle funzioni occorre includere con la direttiva \code{\#include}
+ questi file nei propri programmi ed in seguito per ciascuna funzione che
+ tratteremo indicheremo anche gli \textit{header file} necessari ad usarla.}
+(anch'essi provvisti dalla \acr{glibc}); in tab.~\ref{tab:intro_posix_header}
+si sono riportati i principali \textit{header file} definiti negli standard
+POSIX ed ANSI C, che sono anche quelli definiti negli altri standard descritti
+nelle sezioni successive.
\begin{table}[htb]
\footnotesize
& ANSI C& POSIX& \\
\hline
\hline
- \file{assert.h}&$\bullet$& & Verifica le asserzioni fatte in un
+ \file{assert.h}&$\bullet$& -- & Verifica le asserzioni fatte in un
programma.\\
- \file{ctype.h} &$\bullet$& & Tipi standard.\\
- \file{dirent.h}& &$\bullet$& Manipolazione delle directory.\\
- \file{errno.h} & &$\bullet$& Errori di sistema.\\
- \file{fcntl.h} & &$\bullet$& Controllo sulle opzioni dei file.\\
- \file{limits.h}& &$\bullet$& Limiti e parametri del sistema.\\
- \file{malloc.h}&$\bullet$& & Allocazione della memoria.\\
- \file{setjmp.h}&$\bullet$& & Salti non locali.\\
- \file{signal.h}& &$\bullet$& Gestione dei segnali.\\
- \file{stdarg.h}&$\bullet$& & Gestione di funzioni a argomenti
+ \file{ctype.h} &$\bullet$& -- & Tipi standard.\\
+ \file{dirent.h}& -- &$\bullet$& Manipolazione delle directory.\\
+ \file{errno.h} & -- &$\bullet$& Errori di sistema.\\
+ \file{fcntl.h} & -- &$\bullet$& Controllo sulle opzioni dei file.\\
+ \file{limits.h}& -- &$\bullet$& Limiti e parametri del sistema.\\
+ \file{malloc.h}&$\bullet$& -- & Allocazione della memoria.\\
+ \file{setjmp.h}&$\bullet$& -- & Salti non locali.\\
+ \file{signal.h}& -- &$\bullet$& Gestione dei segnali.\\
+ \file{stdarg.h}&$\bullet$& -- & Gestione di funzioni a argomenti
variabili.\\
- \file{stdio.h} &$\bullet$& & I/O bufferizzato in standard ANSI C.\\
- \file{stdlib.h}&$\bullet$& & Definizioni della libreria standard.\\
- \file{string.h}&$\bullet$& & Manipolazione delle stringhe.\\
- \file{time.h} & &$\bullet$& Gestione dei tempi.\\
- \file{times.h} &$\bullet$& & Gestione dei tempi.\\
- \file{unistd.h}& &$\bullet$& Unix standard library.\\
- \file{utmp.h} & &$\bullet$& Registro connessioni utenti.\\
+ \file{stdio.h} &$\bullet$& -- & I/O bufferizzato in standard ANSI C.\\
+ \file{stdlib.h}&$\bullet$& -- & Definizioni della libreria standard.\\
+ \file{string.h}&$\bullet$& -- & Manipolazione delle stringhe.\\
+ \file{time.h} & -- &$\bullet$& Gestione dei tempi.\\
+ \file{times.h} &$\bullet$& -- & Gestione dei tempi.\\
+ \file{unistd.h}& -- &$\bullet$& Unix standard library.\\
+ \file{utmp.h} & -- &$\bullet$& Registro connessioni utenti.\\
\hline
\end{tabular}
\caption{Elenco dei vari header file definiti dallo standard POSIX.}
\label{tab:intro_posix_header}
\end{table}
-In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
-funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
-standard ANSI C. È possibile ottenere una conformità stretta allo standard
-(scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
-\cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
-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.
+In realtà le \acr{glibc} ed i relativi \textit{header file} definiscono un
+insieme di funzionalità in cui sono incluse come sottoinsieme anche quelle
+previste dallo standard ANSI C. È possibile ottenere una conformità stretta
+allo standard (scartando le funzionalità addizionali) usando il \cmd{gcc} con
+l'opzione \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei
+vari 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.
\subsection{I tipi di dati primitivi}
dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
anche da una architettura ad un'altra (ad esempio passando da macchine con
processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
-\index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
+\index{tipo!elementare} \textit{tipi elementari} del linguaggio C (come
\ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
A questo standard sono stati aggiunti due documenti di correzione e
perfezionamento denominati \textit{Technical Corrigenda}, il TC1 del 2003 ed
il TC2 del 2004, e talvolta si fa riferimento agli stessi con le sigle
-POSIX.1-2003 e POSIX.1-2004.
+POSIX.1-2003 e POSIX.1-2004.
-Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che
-dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente
-sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce
-opzionali dentro le specifiche di base, oltre che le solite precisazioni ed
+Una ulteriore revisione degli standard POSIX e SUS è stata completata e
+ratificata nel 2008, cosa che ha portato al rilascio di una nuova versione
+sotto il nome di POSIX.1-2008 (e SUSv4), con l'incorporazione di alcune nuove
+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.
-% vedi anche man standards
+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
+corrente del supporto degli standard è allegato alla documentazione delle
+\acr{glibc} e si può ottenere con il comando \texttt{man standards}.
+
\subsection{Gli standard X/Open -- Opengroup -- Unix}
\label{sec:intro_xopen}
comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del
marchio UNIX 03 se conformi ad esso.
-Infine con la prossima revisione dello standard POSIX.1 è previsto che, come
-avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno
-le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova
-versione delle \textit{Single UNIX Specification} che verranno chiamate SUSv4.
+Infine, come avvenuto per POSIX.1-2001, anche con la successiva revisione
+dello standard POSIX.1 (la POSIX.1-2008) è stato stabilito che la conformità
+completa a tutte quelle che sono le nuove estensioni XSI previste
+dall'aggiornamento vada a definire la quarta versione delle \textit{Single
+ UNIX Specification}, chiamata appunto SUSv4.
\subsection{Il controllo di aderenza agli standard}
\label{sec:intro_gcc_glibc_std}
-In Linux, grazie alle \acr{glibc}, la conformità agli standard appena
+In Linux, se si usano le \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 dichiarazione (gli \textit{header file}) che
% LocalWords: ftello fseek ftell lseek FORTIFY REENTRANT SAFE overflow memcpy
% LocalWords: mempcpy memmove memset stpcpy strcpy strncpy strcat strncat gets
% LocalWords: sprintf snprintf vsprintf vsnprintf syscall number calendar BITS
+% LocalWords: pathname Google Android standards
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: pathname
e delle funzionalità che sono previste; ma gli errori devono normalmente
essere notificati all'amministratore del sistema.
+\itindbeg{syslog}
+
Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
Per questo in BSD4.2 venne introdotto un servizio di sistema, il
-\textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
-ai demoni di inviare messaggi all'amministratore in una maniera
-standardizzata.
+\textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permette ai
+demoni di inviare messaggi all'amministratore in una maniera
+standardizzata.
Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
-in un sistema unix-like, viene gestito attraverso un apposito programma,
-\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
-errore vengono raccolti dal file speciale \file{/dev/log}, un socket locale
-(vedi sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con
-un socket UDP, o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
-kernel.\footnote{i messaggi del kernel sono tenuti in un buffer circolare e
- scritti tramite la funzione \func{printk}, analoga alla \func{printf} usata
- in user space; una trattazione eccellente dell'argomento si trova in
- \cite{LinDevDri}, nel quarto capitolo.}
-
-Il servizio permette poi di trattare i vari messaggi classificandoli
-attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
-diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
-da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
-(kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
-\textit{priority}, identifica l'importanza dei vari messaggi, e permette di
-classificarli e differenziare le modalità di notifica degli stessi.
-
-Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
-riportare i messaggi all'amministratore attraverso una serie differenti
-meccanismi come:
+in un sistema unix-like, viene gestito attraverso un apposito programma, che è
+anch'esso un \textsl{demone}. In generale i messaggi di errore vengono
+raccolti dal file speciale \file{/dev/log}, un socket locale (vedi
+sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con un
+socket UDP e trattati dal demone che gestisce il servizio. Il più comune di
+questi è \texttt{syslogd}, che consente un semplice smistamento dei messaggi
+sui file in base alle informazioni in esse presenti.\footnote{ad oggi però
+ \texttt{syslogd} è in sostanziale disuso, sostituito da programmi più
+ sofisticati come \texttt{rsyslog} o \texttt{syslog-ng}.}
+
+Il servizio del \textit{syslog} permette infatti di trattare i vari messaggi
+classificandoli attraverso due indici; il primo, chiamato \textit{facility},
+suddivide in diverse categorie i messaggi in modo di raggruppare quelli
+provenienti da operazioni che hanno attinenza fra loro, ed è organizzato in
+sottosistemi (kernel, posta elettronica, demoni di stampa, ecc.). Il secondo,
+chiamato \textit{priority}, identifica l'importanza dei vari messaggi, e
+permette di classificarli e differenziare le modalità di notifica degli
+stessi.
+
+Il sistema del \textit{syslog} attraverso il proprio demone di gestione
+provvede poi a riportare i messaggi all'amministratore attraverso una serie
+differenti meccanismi come:
\begin{itemize*}
\item scrivere sulla console.
\item inviare via mail ad uno specifico utente.
\item inviare ad un altro demone (anche via rete).
\item scartare.
\end{itemize*}
-secondo le modalità che questo preferisce e che possono essere impostate
-attraverso il file di configurazione \conffile{/etc/syslog.conf} (maggiori
-dettagli si possono trovare sulle pagine di manuale per questo file e per
-\cmd{syslogd}).
+le modalità dipendono ovviamente dal demone di gestione che si usa, per la
+gestione del quale si rimanda ad un testo di amministrazione di
+sistema.\footnote{l'argomento è ad esempio coperto dal capitolo 3.2.3 si
+ \cite{AGL}.}
Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
può accedere in maniera generica al servizio di \textit{syslog}, che però
\begin{prototype}{syslog.h}{void openlog(const char *ident, int option,
int facility)}
-Apre una connessione al sistema di \textit{syslog}.
+Apre una connessione al sistema del \textit{syslog}.
\bodydesc{La funzione non restituisce nulla.}
\end{prototype}
\const{LOG\_CRON} & Messaggi dei demoni di gestione dei comandi
programmati (\cmd{cron} e \cmd{at}).\\
\const{LOG\_DAEMON} & Demoni di sistema.\\
- \const{LOG\_FTP} & Server FTP.\\
+ \const{LOG\_FTP} & Servizio FTP.\\
\const{LOG\_KERN} & Messaggi del kernel.\\
\const{LOG\_LOCAL0} & Riservato all'amministratore per uso locale.\\
- --- & \\
+ \hspace{.5cm}--- & \hspace{3cm} ...\\
\const{LOG\_LOCAL7} & Riservato all'amministratore per uso locale.\\
\const{LOG\_LPR} & Messaggi del sistema di gestione delle stampanti.\\
\const{LOG\_MAIL} & Messaggi del sistema di posta elettronica.\\
\const{LOG\_NEWS} & Messaggi del sistema di gestione delle news
(USENET).\\
- \const{LOG\_SYSLOG} & Messaggi generati dallo stesso \cmd{syslogd}.\\
+ \const{LOG\_SYSLOG} & Messaggi generati dal demone di gestione del
+ \textit{syslog}.\\
\const{LOG\_USER} & Messaggi generici a livello utente.\\
- \const{LOG\_UUCP} & Messaggi del sistema UUCP.\\
+ \const{LOG\_UUCP} & Messaggi del sistema UUCP (\textit{Unix to Unix
+ CoPy}, ormai in disuso).\\
\hline
\end{tabular}
\caption{Valori possibili per l'argomento \param{facility} di \func{openlog}.}
\textbf{Valore}& \textbf{Significato}\\
\hline
\hline
-\const{LOG\_CONS} & Scrive sulla console quando. \\
-\const{LOG\_NDELAY} & Sostituisce \const{LOG\_AUTH}.\\
-\const{LOG\_NOWAIT} & Messaggi dei demoni di gestione dei comandi
- programmati (\cmd{cron} e \cmd{at}).\\
-\const{LOG\_ODELAY} & \\
-\const{LOG\_PERROR} & Stampa anche su \file{stderr}.\\
+\const{LOG\_CONS} & Scrive sulla console in caso di errore nell'invio del
+ messaggio al sistema del \textit{syslog}. \\
+\const{LOG\_NDELAY} & Apre la connessione al sistema del \textit{syslog}
+ subito invece di attendere l'invio del primo messaggio.\\
+\const{LOG\_NOWAIT} & Non usato su Linux, su altre piattaforme non attende i
+ processi figli creati per inviare il messaggio.\\
+\const{LOG\_ODELAY} & Attende il primo messaggio per aprire la connessione al
+ sistema del \textit{syslog}.\\
+\const{LOG\_PERROR} & Stampa anche su \file{stderr} (non previsto in
+ POSIX.1-2001).\\
\const{LOG\_PID} & Inserisce nei messaggi il \acr{pid} del processo
chiamante.\\
\hline
\macro{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
priorità fino ad un certo valore.
+\itindend{syslog}
+
+
+Oltre ai vari demoni, il servizio viene utilizzato anche dal kernel per
+comunicare messaggi in user space, in questo caso
+
+
+ o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
+kernel.\footnote{i messaggi del kernel sono tenuti in un buffer circolare e
+ scritti tramite la funzione \func{printk}, analoga alla \func{printf} usata
+ in user space; una trattazione eccellente dell'argomento si trova in
+ \cite{LinDevDri}, nel quarto capitolo.}
+
\section{L'I/O su terminale}
projects / gapil.git / commitdiff