X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=intro.tex;h=f3b65754937c36a0b2e2240419b9b7e3f4bf5143;hp=9ae1f14432f3987fe351b7297c90ff3d6510b3d4;hb=5a59e67204ff436dceb6a13ed39e876aea3945a8;hpb=74b2dc2662eb6e3c6e64b4b284eeb77afab48c60 diff --git a/intro.tex b/intro.tex index 9ae1f14..f3b6575 100644 --- a/intro.tex +++ b/intro.tex @@ -1,97 +1,111 @@ -\chapter{L'architettura di GNU/Linux} +%% intro.tex +%% +%% Copyright (C) 2000-2002 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 "Prefazione", +%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the +%% license is included in the section entitled "GNU Free Documentation +%% License". +%% +\chapter{L'architettura del sistema} \label{cha:intro_unix} In questo primo capitolo sarà fatta un'introduzione ai concetti generali su -cui è basato un sistema di tipo unix come GNU/Linux, per fornire una base di -comprensione mirata a sottolineare le peculiarità che saranno poi importanti -per quello che riguarda la programmazione. +cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo +potremo fornire una base di comprensione mirata a sottolineare le peculiarità +del sistema che sono più rilevanti per quello che riguarda la programmazione. -Dopo un introduzione sulle caratteristiche principali di un sistema di tipo -unix passeremo ad illustrare alcuni dei concetti basi dell'architettura di -Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed -introdurremo alcuni degli standard princincipali a cui si fa riferimento. +Dopo un'introduzione sulle caratteristiche principali di un sistema di tipo +Unix passeremo ad illustrare alcuni dei concetti base dell'architettura di +GNU/Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed +introdurremo alcuni degli standard principali a cui viene fatto riferimento. -\section{Una panoramica sulla struttura} +\section{Una panoramica} \label{sec:intro_unix_struct} -In questa prima sezione faremo una panoramica sulla struttura di un sistema -\textit{unix-like} come GNU/Linux. Chi avesse già una conoscenza di questa -materia può tranquillamente saltare questa sezione. +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. -Il concetto base di un sistema unix-like é quello di un nucleo del sistema (il -cosiddetto \textit{kernel}) 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, deve venire realizzato -tramite programmi eseguiti dal kernel e che accedano alle risorse hardware -tramite delle richieste a quest'ultimo. -Fin dall'inizio unix si presenta come un sistema operativo +\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 +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, +deve venire realizzato tramite programmi eseguiti dal kernel e che accedano +alle risorse hardware tramite delle 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 +programmi, e multiutente, in cui è possibile che più utenti siano connessi ad una macchina eseguendo più programmi ``in contemporanea'' (in realtà, almeno per macchine a processore singolo, i programmi vengono eseguiti singolarmente a rotazione). -% Questa e' una distinzione essenziale da capire, +% Questa e` una distinzione essenziale da capire, %specie nei confronti dei sistemi operativi successivi, nati per i personal %computer (e quindi per un uso personale), sui quali l'hardware (allora %limitato) non consentiva la realizzazione di un sistema evoluto come uno unix. -Gli unix più recenti, come Linux, sono stati realizzati usando alcune +I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune caratteristiche dei processori moderni come la gestione hardware della memoria e la modalità protetta. In sostanza con i processori moderni si può disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe -zone di memoria fisica. Quello che succede é che il kernel é il solo +zone di memoria fisica. Quello che succede è che il kernel è il solo programma ad essere eseguito in modalità privilegiata, con il completo accesso all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta -(e non possono accedere direttamente alle zone di memoria riservate -o alle porte di input/output). - -Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, ad -intervalli fissi e sulla base di un opportuno calcolo delle priorità, quale -``processo'' deve essere posto in esecuzione (il cosiddetto -\textit{prehemptive scheduling}). Questo verrà comunque eseguito in modalità -protetta; quando necessario il processo potrà accedere alle risorse hardware -soltanto attraverso delle opportune chiamate al sistema che restituiranno il -controllo al kernel. - -La memoria viene sempre gestita del kernel attraverso il meccanismo della -memoria virtuale, che consente di assegnare a ciascun processo uno spazio di -indirizzi ``virtuale'' (vedi \secref{sec:proc_memory}) che il kernel stesso, -con l'ausilio della unità di gestione della memoria, si incaricherà di -rimappare automaticamente sulla memoria disponibile, salvando quando -necessario su disco (nella cosiddetta \textit{swap}) le pagine di memoria in -eccedenza. +(e non possono accedere direttamente alle zone di memoria riservate o alle +porte di input/output). + +Una parte del kernel, lo \textit{scheduler}\index{scheduler}, si occupa di +stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle +priorità, quale ``processo'' deve essere posto in esecuzione (il cosiddetto +\textit{preemptive scheduling}\index{preemptive scheduling}). Questo verrà +comunque eseguito in modalità protetta; quando necessario il processo potrà +accedere alle risorse hardware soltanto attraverso delle opportune chiamate al +sistema che restituiranno il controllo al kernel. + +La memoria viene sempre gestita dal kernel attraverso il meccanismo della +\textsl{memoria virtuale}\index{memoria virtuale}, che consente di assegnare a +ciascun processo uno spazio di indirizzi ``virtuale'' (vedi +\secref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di +gestione della memoria, si incaricherà di rimappare automaticamente sulla +memoria disponibile, salvando su disco quando necessario (nella cosiddetta +area di \textit{swap}) le pagine di memoria in eccedenza. Le periferiche infine vengono viste in genere attraverso un'interfaccia astratta che permette di trattarle come fossero file, secondo il concetto per -cui \textit{everything is a file}, vedi \capref{cha:files_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). +cui \textit{everything is a file}, su cui torneremo in dettaglio in +\capref{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). -\section{User space e kernel space} +\subsection{User space e kernel space} \label{sec:intro_user_kernel_space} -Uno dei concetti fondamentale su cui si basa l'architettura dei sistemi unix è +Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è quello della distinzione fra il cosiddetto \textit{user space}, che contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il -\textit{kernel space} che é l'ambiente in cui viene eseguito il kernel. Ogni -programma vede se stesso come se avesse la piena disponibilità della CPU e +\textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni +programma vede sé stesso come se avesse la piena disponibilità della CPU e della memoria ed è, salvo i meccanismi di comunicazione previsti -dall'architettura completamente ignaro del fatto che altri programmi possono +dall'architettura, completamente ignaro del fatto che altri programmi possono essere messi in esecuzione dal kernel. 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 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. +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 +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. @@ -100,36 +114,38 @@ fornisce allo user space. \label{sec:intro_kern_and_sys} Per capire meglio la distinzione fra kernel space e user space si può prendere -in esame la procedura di avvio di un sistema unix; all'avvio il BIOS (o in -generale il software di avvio posto nelle EPROM) eseguirà il \textit{boot} -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, \textit{init} che è quello che si incaricherà di -far partire tutti i processi successivi, come quello che si occupa di -dialogare con la tastiera e lo schermo della console, mettendo a disposizione -dell'utente che si vuole collegare un terminale e la stessa \textit{shell} da -cui inviare i comandi. +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{boot}), 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 -programma di scrittura o di disegno, in user space. +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 altri sistemi -(come Windows) hanno invece al loro interno. Per questo può capitare che -alcune operazioni, come quella in esempio, siano implementate come normali -programmi. +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 +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. %Una delle caratteristiche base di unix \`e perci\`o che \`e possibile %realizzare un sistema di permessi e controlli che evitano che i programmi %eseguano accessi non autorizzati. -Per questo motivo è più corretto parlare di sistema GNU/Linux, in quanto 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 permettono di eseguire le normali operazioni che ci -si aspetta da un sistema operativo. +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 +quelli realizzati dal progetto GNU della Free Software Foundation) che +permettono di eseguire le normali operazioni che ci si aspetta da un sistema +operativo. \subsection{Chiamate al sistema e librerie di funzioni} @@ -137,68 +153,94 @@ si aspetta da un sistema operativo. Come accennato le interfacce con cui i programmi possono accedere all'hardware vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system - call}), si tratta di un insieme di routine che un programma può chiamare per -le quali viene generata una interruzione e il controllo è passato dal -programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie di -operazioni interne come la gestione del multitaskin e il l'allocazione della -memoria) eseguirà la funzione richiesta in kernel space restituendo i + call}), si tratta di un insieme di funzioni che un programma può chiamare, +per le quali viene generata un'interruzione del processo passando il controllo +dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie +di operazioni interne come la gestione del multitasking e l'allocazione della +memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i risultati al chiamante. -Ogni versione unix ha storicamente sempre avuto un certo numero di queste -chiamate, che sono riportate nella seconda sezione del \textsl{Manuale della - programmazione di unix} (quella che si accede con il comando \texttt{man 2}) -e linux non fa eccezione. Queste sono poi state codificate da vari standard, -che esamineremo brevemente in \secref{sec:intro_standard}. +Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste +chiamate, che sono riportate nella seconda sezione del \textsl{Manuale di + programmazione di Unix} (quella cui si accede con il comando \cmd{man 2 + }) e Linux non fa eccezione. Queste sono poi state codificate da vari +standard, che esamineremo brevemente in \secref{sec:intro_standard}. Uno +schema elementare della struttura del sistema è riportato in +\figref{fig:intro_sys_struct}. + +\begin{figure}[htb] + \centering + \includegraphics[width=10cm]{img/struct_sys} + \caption{Schema di massima della struttura di interazione fra processi, + kernel e dispositivi in Linux.} + \label{fig:intro_sys_struct} +\end{figure} Normalmente ciascuna di queste chiamate al sistema viene rimappata in opportune funzioni con lo stesso nome definite dentro la Libreria Standard del -C, che oltre alle interfacce alle system call contiene anche tutta una serie -di ulteriori funzioni usate comunemente nella programmazione. +C, che, oltre alle interfacce alle system call, contiene anche tutta la serie +delle ulteriori funzioni definite dai vari standard, che sono comunemente +usate nella programmazione. Questo è importante da capire perché programmare in Linux significa anzitutto -essere in grado di usare la Libreria Standard del C, in quanto né il kernel né -il linguaggio C implementano direttamente operazioni comuni come la -allocazione dinamica della memoria, l'input/output bufferizzato o la -manipolazione delle stringhe presenti in qualunque programma. - -Per questo in Linux è in effetti GNU/Linux, in quanto una parte essenziale del -sistema (senza la quale niente può funzionare) è la realizzazione fatta dalla -Free Software Foundation della suddetta libreria (la GNU Standard C Library, -in breve \textit{glibc}), in cui sono state implementate tutte le funzioni -essenziali definite negli standard POSIX e ANSI C, e che viene utilizzata da -qualunque programma. +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 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 + Standard del C, come le \textit{libc5} o le \textit{uClib}, che non derivano + 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 di dimensioni ridotte (e soprattutto la possibilità di + togliere le parti non necessearie), 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 -Manuale di Programmazione di Unix, 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 -relizzazione di normali programmi non si hanno differenze pratiche fra l'uso -di una funzione di libreria e quello di una chiamata al sistema. +\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando +\cmd{man 3 }) 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. \subsection{Un sistema multiutente} \label{sec:intro_multiuser} -Linux, come gli altri unix, nasce fin dall'inizio come sistema multiutente, -cioè in grado di fare lavorare più persone in contemporanea. Per questo -esistono una serie di meccanismi di sicurezza che non sono previsti in sistemi -operativi monoutente e che occorre tenere presente. +Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema +multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per +questo esistono una serie di meccanismi di sicurezza, che non sono previsti in +sistemi operativi monoutente, e che occorre tenere presente. -Il concetto base è quello di utente (\textit{user}) del sistema, utente che ha -dei ben definiti limiti e capacità rispetto a quello che può fare. 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 +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. -Ad ogni utente è dato un nome \textit{username}, che è quello che viene -richiesto all'ingresso nel sistema dalla procedura di \textit{login}. Questa -procedura si incarica di verificare la identità dell'utente (in genere -attraverso la richiesta di una parola d'ordine, anche se sono possibili -meccanismi diversi). +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 \secref{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 una interfaccia grafica) che mette a disposizione dell'utente un +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 @@ -208,10 +250,12 @@ accesso ai file e quindi anche alle periferiche, in maniera pi definendo gruppi di lavoro, di accesso a determinate risorse, etc. L'utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad -un nome in espresso in caratteri è inserita nei due files \file{/etc/passwd} -e \file{/etc/groups}). Questi numeri sono l'\textit{user identifier}, detto -in breve \acr{uid} e il \textit{group identifier}, detto in breve \acr{gid} -che sono quelli che identificano l'utente di fronte al sistema. +un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e +\file{/etc/groups}). Questi numeri sono l'\textit{user identifier}, detto in +breve \textsl{userid}, ed indicato dall'acronimo \acr{uid}, e il \textit{group + identifier}, detto in breve \textsl{groupid}, ed identificato dall'acronimo +\acr{gid}, e sono quelli che vengono usati dal kernel per identificare +l'utente. In questo modo il sistema è in grado di tenere traccia per ogni processo dell'utente a cui appartiene ed impedire ad altri utenti di interferire con @@ -220,217 +264,443 @@ sicurezza interna in quanto anche l'accesso ai file (vedi \secref{sec:file_access_control}) è regolato da questo meccanismo di identificazione. -Un utente speciale del sistema è \textit{root}, il cui \acr{uid} è zero. Esso -identifica l'amministratore del sistema, che deve essere in grado di fare -qualunque operazione; pertanto per l'utente \textit{root} i meccanismi di -controllo descritti in precedenza sono disattivati. +Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto +\textit{superuser}, il cui username è di norma \textit{root}, ed il cui +\acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve +essere in grado di fare qualunque operazione; per l'utente \textit{root} +infatti i meccanismi di controllo descritti in precedenza sono +disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice + del tipo \code{if (uid) \{ ... \}}} -\section{Gli standard di unix e GNU/Linux} +\section{Gli standard} \label{sec:intro_standard} -In questa sezione prenderemo in esame alcune caratteristiche generali del -sistema e gli standard adottati per le funzioni, i prototipi, gli errori, i -tipi di dati. - -\subsection{Prototipi e puntatori} -\label{sec:intro_function} - -\subsection{La misura del tempo in unix} -\label{sec:intro_unix_time} - -Storicamente i sistemi unix-like hanno sempre mantenuto due distinti valori -per i tempi all'interno del sistema, chiamati rispettivamente \textit{calendar - time} e \textit{process time}, secondo le definizioni: -\begin{itemize} -\item \textit{calendar time}: è il numero di secondi dalla mezzanotte del - primo gennaio 1970, in tempo universale coordinato (o UTC, data che viene - usualmente indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata \textit{the - Epoch}). Viene chiamato anche GMT (Greenwich Mean Time) dato che l'UTC - corrisponde all'ora locale di Greenwich. E' il tempo su cui viene mantenuto - l'orologio del calcolatore, e viene usato ad esempio per indicare le date di - modifica dei file o quelle di avvio dei processi. Per memorizzare questo - tempo è stato riservato il tipo primitivo \func{time\_t}. -\item \textit{process time}: talvolta anche detto tempo di CPU. Viene misurato - in \textit{clock tick}, corripondenti al numero di interruzioni effettuate - dal timer di sistema, e che per Linux sono ogni centesimo di secondo - (eccetto per la piattaforma alpha). Il dato primitivo usato per questo tempo - è \func{clock\_t}, inoltre la costante \macro{HZ} restituisce la frequenza - di operazione del timer, e corrisponde dunque al numero di tick al secondo - (Posix definisce allo stesso modo la costante \macro{CLK\_TCK}); questo - valore può comunque essere ottenuto con \func{sysconf} (vedi - \secref{sec:intro_limits}). -\end{itemize} - -In genere si usa il \textit{calendar time} per tenere le date dei file e le -informazioni analoghe che riguardano i tempi di ``orologio'' (usati ad esempio -per i demoni che compiono lavori amministrativi ad ore definite, come -\cmd{cron}). Di solito questo vene convertito automaticamente dal valore in -UTC al tempo locale, utilizzando le opportune informazioni di localizzazione -(specificate in \file{/etc/timezone}). E da tenere presente che questo tempo è -mantenuto dal sistema e non corrisponde all'orologio hardware del calcolatore. - -Il \textit{process time} di solito si esprime in secondi e viene usato appunto -per tenere conto dei tempi di esecuzione dei processi. Per ciascun processo il -kernel tiene tre di questi tempi: -\begin{itemize} -\item \textit{clock time} -\item \textit{user time} -\item \textit{system time} -\end{itemize} -il primo è il tempo ``reale'' (viene anche chiamato \textit{wall clock time}) -dall'avvio del processo, e misura il tempo trascorso fino alla sua -conclusione; chiaramente un tale tempo dipede anche dal carico del sistema e -da quanti altri processi stavano girando nello stesso periodo. Il secondo -tempo è quello che la CPU ha speso nell'esecuzione delle istruzioni del -processo in user space. Il terzo è il tempo impiegato dal kernel per eseguire -delle system call per conto del processo medesimo (tipo quello usato per -eseguire una \func{write} su un file). In genere la somma di user e system -time viene chiamato \textit{CPU time}. - -\subsection{Lo standard ANSI C} -\label{sec:intro_ansiC} +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 SVr4. -\subsection{Lo standard POSIX} -\label{sec:intro_posix} +Ovviamente prenderemo in considerazione solo gli standard riguardanti +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 le librerie del C (con una +particolare attenzione alle \acr{glibc}). -\subsection{Valori e limiti del sistema} -\label{sec:intro_limits} +\subsection{Lo standard ANSI C} +\label{sec:intro_ansiC} -\subsection{Tipi di dati primitivi} +Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National + Standard Institute}, come standard del linguaggio C ed è stato +successivamente adottato dalla \textit{International Standard Organisation} +come standard internazionale con la sigla ISO/IEC 9899:1990, e va anche sotto +il nome di standard ISO C. + +Scopo dello standard è quello di garantire la portabilità dei programmi C fra +sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del +linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede +anche una libreria di funzioni che devono poter essere implementate su +qualunque sistema operativo. + +Per questo motivo, anche se lo standard non ha alcun riferimento ad 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 \tabref{tab:intro_posix_header} si sono +riportati i principali \textit{header file} definiti nello standard POSIX, +insieme a quelli definiti negli altri standard descritti nelle sezioni +successive. + +\begin{table}[htb] + \footnotesize + \centering + \begin{tabular}[c]{|l|c|c|l|} + \hline + \multirow{2}{*}{\textbf{Header}}& + \multicolumn{2}{|c|}{\textbf{Standard}}& + \multirow{2}{*}{\textbf{Contenuto}} \\ + \cline{2-3} + & ANSI C& POSIX& \\ + \hline + \hline + \file{assert.h}&$\bullet$&$\bullet$& Verifica le asserzioni fatte in un + programma.\\ + \file{errno.h} &$\bullet$&$\bullet$& Errori di sistema.\\ + \file{fcntl.h} &$\bullet$&$\bullet$& Controllo sulle opzioni dei file.\\ + \file{limits.h}&$\bullet$&$\bullet$& Limiti e parametri del sistema.\\ + \file{} &$\bullet$&$\bullet$& .\\ + \file{} &$\bullet$&$\bullet$& .\\ + \file{} &$\bullet$&$\bullet$& .\\ + \file{} &$\bullet$&$\bullet$& .\\ + \file{} &$\bullet$&$\bullet$& .\\ + \file{stdio.h} &$\bullet$&$\bullet$& I/O bufferizzato in standard ANSI C.\\ + \file{stdlib.h}&$\bullet$&$\bullet$& definizioni della libreria standard.\\ + \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. + + +\subsection{I tipi di dati primitivi} \label{sec:intro_data_types} +Uno dei problemi di portabilità del codice più comune è quello dei tipi di +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). +Storicamente alcuni tipi di dati definiti dallo standard ANSI C sono sempre +stati associati ad alcune variabili nei sistemi Unix, ad esempio la posizione +corrente all'interno di un file è sempre stato associato ad un intero a 32 +bit, mentre il numero di dispositivo è sempre stato associato ad un intero a +16 bit. Tutto questo ovviamente costituisce un incubo per la portabilità tutte +le volte che, con l'evolversi delle piattaforme hardware, alcuni di questi +tipi si sono rivelati inadeguati, e se ne è dovuto cambiare la dimensione. - -\section{La gestione degli errori} -\label{sec:intro_errors} - -La gestione degli errori è in genere una materia complessa. Inoltre il modello -utilizzato dai sistema unix-like è basato sull'architettura a processi, e -presenta una serie di problemi nel caso lo si debba usare con i thread. -Esamineremo in questa sezione le sue caratteristiche principali. - - -\subsection{La variabile \func{errno}} -\label{sec:intro_errno} - -Quasi tutte le funzioni delle librerie del C sono in grado di individuare e -riportare condizioni di errore, ed è una buona norma di programmazione -controllare sempre che le funzioni chiamate si siano concluse correttamente. - -In genere le funzioni di libreria usano un valore speciale per indicare che -c'è stato un errore. Di solito questo valore è -1 o un puntatore nullo o la -costante \macro{EOF} (a seconda della funzione); ma questo valore segnala solo -che c'è stato un errore, non il tipo di errore. - -Per riportare il tipo di errore il sistema usa la variabile globale -\var{errno}\footnote{L'uso di una variabile globale può comportare alcuni - problemi (ad esempio nel caso dei thread) ma lo standard ISO C consente - anche di definire \var{errno} come un \textit{modifiable lvalue}, quindi si - può anche usare una macro, e questo è infatti il modo usato da Linux per - renderla locale ai singoli thread }, definita nell'header \file{errno.h}, la -variabile è in genere definita come \var{volatile} dato che può essere -cambiata in modo asincrono da un segnale (per una descrizione dei segnali si -veda \secref{cha:signals}), ma dato che un manipolatore di segnale scritto -bene salva e ripristina il valore della variabile, di questo non è necessario -preoccuparsi nella programmazione normale. - -I valori che può assumere \var{errno} sono riportati in \capref{cha:errors}, -nell'header \file{errno.h} sono anche definiti i nomi simbolici per le -costanti numeriche che identificano i vari errori; essi iniziano tutti per -\macro{E} e si possono considerare come nomi riservati. In seguito faremo -sempre rifermento a tali valori, quando descriveremo i possibili errori -restituiti dalle funzioni. Il programma di esempio \cmd{errcode} stampa il -codice relativo ad un valore numerico con l'opzione \cmd{-l}. - -Il valore di \var{errno} viene sempre settato a zero all'avvio di un -programma, gran parte delle funzioni di libreria settano \var{errno} ad un -valore diverso da zero in caso di errore. Il valore è invece indefinito in -caso di successo, perché anche se una funzione ha successo, può chiamarne -altre al suo interno che falliscono, modificando così \var{errno}. - -Pertanto un valore non nullo di \var{errno} non è sintomo di errore (potrebbe -essere il risultato di un errore precedente) e non lo si può usare per -determinare \textsl{quando} una chiamata a funzione è fallita. La procedura -da seguire è sempre quella di controllare \var{errno} immediatamente dopo aver -verificato il fallimento della funzione dal suo codice di ritorno. - - -\subsection{Le funzioni \func{strerror} e \func{perror}} -\label{sec:intro_strerror} - -Benché gli errori siano identificati univocamente dal valore numerico di -\var{errno} le librerie provvedono alcune funzioni e variabili utili per -riportare in opportuni messaggi le condizioni di errore verificatesi. La -prima funzione che si può usare per ricavare i messaggi di errore è -\func{strerror}, il cui prototipo è: -\begin{prototype}{string.h}{char * strerror(int errnum)} - La funzione ritorna una stringa (statica) che descrive l'errore il cui - codice è passato come parametro. -\end{prototype} - -In generale \func{strerror} viene usata passando \var{errno} come parametro; -nel caso si specifichi un codice sbagliato verrà restituita un messaggio di -errore sconosciuto. - -Il problema con \func{strerror} è che la funzione utilizza una stringa statica -che non deve essere modificata dal programma e che è utilizzabile solo fino ad -una chiamata successiva a \func{strerror}; nel caso si usino i thread è -provvista\footnote{questa funzione è una estensione GNU, non fa parte dello - standard POSIX} una versione apposita: -\begin{prototype}{string.h} -{char * strerror_r(int errnum, char * buff, size\_t size)} - La funzione è analoga a \func{strerror} ma ritorna il messaggio in un buffer - specificato da \var{buff} di lunghezza massima (compreso il terminatore) - \var{size}. -\end{prototype} -che utilizza un buffer che il singolo thread deve allocare, per evitare i -problemi connessi alla condivisione del buffer statico. Infine, per completare -la caratterizzazione dell'errore, si può usare anche la variabile globale -\var{program_invocation_short_name} che riporta il nome del programma -attualmente in esecuzione. - -Una seconda funzione usata per riportare i codici di errore in maniera -automatizzata sullo standard error (vedi \secref{sec:file_stdfiles}) è -\func{perror}, il cui prototipo è: -\begin{prototype}{stdio.h}{void perror (const char *message)} - La funzione stampa il messaggio di errore relativo al valore corrente di - \var{errno} sullo standard error; preceduto dalla stringa \var{message}. -\end{prototype} -i messaggi di errore stampati sono gli stessi di \func{strerror}, (riportati -in \capref{cha:errors}), e, usando il valore corrente di \var{errno}, si -riferiscono all'ultimo errore avvenuto. La stringa specificata con -\var{message} viene stampato prime del messaggio d'errore, seguita dai due -punti e da uno spazio, il messaggio è terminato con un a capo. - -Il messaggio può essere riportato anche usando altre variabili globali -dichiarate in \file{errno.h}: -\begin{verbatim} - const char *sys_errlist[]; - int sys_nerr; -\end{verbatim} -la prima contiene i puntatori alle stringhe di errore indicizzati da -\var{errno}; la seconda esprime il valore più alto per un codice di errore, -l'utilizzo di questa stringa è sostanzialmente equivalente a quello di -\func{strerror}. - -In \nfig\ si sono riportate le sezioni attineti del codice del programma -\cmd{errcode}, il sorgente completo del programma è allegato nel file -\file{ErrCode.c} e contiene pure la gestione delle opzioni e tutte le -definizioni necessarie a stampare l'etichetta simbolica dell'errore. - -le sezioni che -illustrano l'utilizzo delle due funzioni suddette - -\begin{figure}[!htb] +\begin{table}[htb] \footnotesize - \begin{lstlisting}{} - - + \centering + \begin{tabular}[c]{|l|c|c|l|} + \hline + \textbf{Tipo} & \textbf{Contenuto} \\ + \hline + \hline + \type{caddr\_t} & core address.\\ + \type{clock\_t} & contatore del tempo di sistema.\\ + \type{dev\_t} & Numero di dispositivo.\\ + \type{gid\_t} & Identificatore di un gruppo.\\ + \type{ino\_t} & Numero di \textit{inode}.\\ + \type{key\_t} & Chiave per il System V IPC.\\ + \type{loff\_t} & Posizione corrente in un file.\\ + \type{mode\_t} & Attributi di un file.\\ + \type{nlink\_t} & Contatore dei link su un file.\\ + \type{off\_t} & Posizione corrente in un file.\\ + \type{pid\_t} & Identificatore di un processo.\\ + \type{rlim\_t} & Limite sulle risorse.\\ + \type{sigset\_t}& Insieme di segnali.\\ + \type{ssize\_t} & Dimensione di un oggetto.\\ + \type{ssize\_t} & Dimensione in numero byte ritornata dalle funzioni.\\ + \type{ptrdiff\_t}& Differenza fra due puntatori.\\ + \type{time\_t} & Numero di secondi (in tempo di calendario).\\ + \type{uid\_t} & Identificatore di un utente.\\ + \hline + \end{tabular} + \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.} + \label{tab:intro_primitive_types} +\end{table} + +Per questo motivo tutte le funzioni di libreria di solito non fanno +riferimento ai tipi standard del linguaggio C, ma ad una serie di \textsl{tipi + primitivi}, riportati in \tabref{tab:intro_primitive_types}, caratteristici +di ogni sistema, definiti nell'header file \file{sys/types.h}, che associano i +tipi utilizzati dalle funzioni di sistema ai tipi elementari supportati dal +compilatore C. + + + +\subsection{Lo standard IEEE -- POSIX} +\label{sec:intro_posix} - \end{lstlisting} - \caption{Codice per la stampa del messaggio di errore standard.} - \label{fig:proc_fork_code} -\end{figure} +Uno standard più attinente al sistema nel suo complesso (e che concerne sia il +kernel che le librerie) è lo standard POSIX. Esso prende origine dallo +standard ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità +per le funzioni in esso definite, ed aggiungendone di nuove. + +In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da +Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la +X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal +lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers}) +che ne produsse una prima versione, nota come IEEE 1003.1-1988, mirante a +standardizzare l'interfaccia con il sistema operativo. + +Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di +libreria, e in seguito sono stati prodotti anche altri standard per la shell e +i comandi di sistema (1003.2), per le estensioni realtime e per i thread +(1003.1d e 1003.1c) e vari altri. In \tabref{tab:intro_posix_std} è riportata +una classificazione sommaria dei principali documenti prodotti, e di come sono +identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa +l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio si può parlare +di POSIX.4 come di POSIX.1b). + +Si tenga presente però che nuove specifiche e proposte di standardizzazione si +aggiungono continuamente, mentre le versioni precedenti vengono riviste; +talvolta poi i riferimenti cambiamo 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 è: +\href{http://www.pasc.org/standing/sd11.html} +{http://www.pasc.org/standing/sd11.html}. + + +\begin{table}[htb] + \footnotesize + \centering + \begin{tabular}[c]{|l|l|l|l|} + \hline + \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\ + \hline + \hline + POSIX.1 & 1003.1 & 9945-1& Interfacce di base \\ + POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1 \\ + POSIX.2 & 1003.2 & 9945-2& Comandi \\ + POSIX.3 & 2003 &TR13210& Metodi di test \\ + POSIX.4 & 1003.1b & --- & Estensioni real-time \\ + POSIX.4a& 1003.1c & --- & Threads \\ + POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time \\ + POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA \\ + POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza \\ + POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete \\ + POSIX.9 & 1003.9 & --- & Intercaccia per il Fortran-77 \\ + POSIX.12& 1003.1g& 9945-1& Sockets \\ + \hline + \end{tabular} + \caption{Elenco dei vari standard POSIX e relative denominazioni.} + \label{tab:intro_posix_std} +\end{table} + +Benché l'insieme degli standard POSIX siano basati sui sistemi Unix essi +definiscono comunque un'interfaccia di programmazione generica e non fanno +riferimento ad una implementazione specifica (ad esempio esiste +un'implementazione di POSIX.1 anche sotto Windows NT). Lo standard principale +resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui +gran parte delle implementazioni fanno riferimento, e che costituisce una base +per molti altri tentativi di standardizzazione, è stata rilasciata anche come +standard internazionale con la sigla ISO/IEC 9945-1:1996. + +Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard +POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per +funzioni di \textit{pattern matching} e per la manipolazione delle +\textit{regular expression}), che vengono usate dalla shell e dai comandi di +sistema e che sono definite nello standard POSIX.2. + +Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate +ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i +\textit{thread} (vedi \capref{cha:threads}), e dallo standard POSIX.1b per +quanto riguarda i segnali e lo scheduling real-time +(\secref{sec:sig_real_time} e \secref{sec:proc_real_time}), la misura del +tempo, i meccanismi di intercomunicazione (\secref{sec:ipc_posix}) e l'I/O +asincrono (\secref{sec:file_asyncronous_io}). + + + +\subsection{Lo standard X/Open -- XPG3} +\label{sec:intro_xopen} + +Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi +Unix per giungere ad un'armonizzazione delle varie implementazioni. Per far +questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il +nome di \textit{X/Open Portability Guide} (a cui di norma si fa riferimento +con l'abbreviazione XPGn). + +Nel 1989 produsse una terza versione di questa guida particolarmente +voluminosa (la \textit{X/Open Portability Guide, Issue 3}), contenente +un'ulteriore standardizzazione dell'interfaccia di sistema di 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 (\textit{Application Programmable Interface}) +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 + Transport Interface}) mirante a soppiantare (senza molto successo) +l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu +rilasciata nel 1994, questa è nota con il nome di Spec 1170 (dal numero delle +interfacce, header e comandi definiti). + +Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo +aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue +specifiche sotto il nome di \textit{Single UNIX Specification}, l'ultima +versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX + Specification}, SUSv1, più comunemente nota come \textit{Unix 95}. + + +\subsection{Gli standard Unix -- Open Group} +\label{sec:intro_opengroup} + +Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata +da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò +alla costituzione dell'Open Group, un consorzio internazionale che raccoglie +produttori, utenti industriali, entità accademiche e governative. + +Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue +il lavoro di standardizzazione delle varie implementazioni, rilasciando +periodicamente nuove specifiche e strumenti per la verifica della conformità +alle stesse. + +Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX + Specification}, nota con la sigla SUSv2, in queste versione le interfacce +specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro +grafiche, per le quali sono inserite pure le interfacce usate da CDE che +richiede sia X11 che Motif). La conformità a questa versione permette l'uso +del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. + + +\subsection{Lo ``standard'' BSD} +\label{sec:intro_bsd} + +Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università +di Berkley e la AT\&T generò una delle prime e più importanti fratture del +mondo Unix. L'Università di Berkley proseguì nello sviluppo della base di +codice di cui disponeva, e che presentava parecchie migliorie rispetto alle +allora versioni disponibili, fino ad arrivare al rilascio di una versione +completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice +della AT\&T. + +Benché BSD non sia uno standard formalizzato, l'implementazione di Unix +dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e +API di grande rilievo, come il link simbolici, la funzione \code{select}, i +socket. + +Queste estensioni sono state via via aggiunte al sistema nelle varie versioni +del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati +commerciali come SunOS. Il kernel e le \acr{glibc} provvedono tutte queste +estensioni che sono state in gran parte incorporate negli standard successivi. + + +\subsection{Lo standard System V} +\label{sec:intro_sysv} + +Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come +marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la +versione supportata ufficialmente venne rilasciata al pubblico con il nome di +Unix System V. Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando +varie versioni con aggiunte e integrazioni; nel 1989 un accordo fra vari +venditori (AT\&T, Sun, HP, e altro) portò ad una versione che provvedeva +un'unificazione delle interfacce comprendente Xenix e BSD, la System V release +4. + +L'interfaccia di questa ultima release è descritta in un documento dal titolo +\textit{System V Interface Description}, o SVID; spesso però si fa riferimento +a questo standard con il nome della sua implementazione, usando la sigla SVr4. + +Anche questo costituisce un sovrainsieme delle interfacce definite dallo +standard POSIX. Nel 1992 venne rilasciata una seconda versione del sistema: +la SVr4.2. L'anno 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. + +Linux e le \acr{glibc} implementano le principali funzionalità richieste da +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 +presenti neanche in System V) sono state tralasciate. + +Le funzionalità implementate sono principalmente il meccanismo di +intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System +V IPC, che vedremo in \secref{sec:ipc_sysv}) le funzioni della famiglia +\func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni +matematiche. + + +\subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}} +\label{sec:intro_gcc_glibc_std} + +In Linux, grazie alle \acr{glibc}, gli standard appena descritti sono +ottenibili sia attraverso l'uso di opzioni del compilatore (il \cmd{gcc}) che +definendo opportune costanti prima dell'inclusione dei file degli header. + +Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C +si può usare l'opzione \cmd{-ansi} del compilatore, e non sarà riconosciuta +nessuna funzione non riconosciuta dalle specifiche standard ISO per il C. + +Per attivare le varie opzioni è possibile definire le macro di preprocessore, +che controllano le funzionalità che le \acr{glibc} possono mettere a +disposizione: questo può essere fatto attraverso l'opzione \cmd{-D} del +compilatore, ma è buona norma inserire gli opportuni \code{\#define} nei +propri header file. + +Le macro disponibili per i vari standard sono le seguenti: +\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}} +\item[\const{\_POSIX\_SOURCE}] definendo questa macro si rendono disponibili + tutte le funzionalità dello standard POSIX.1 (la versione IEEE Standard + 1003.1) insieme a tutte le funzionalità dello standard ISO C. Se viene anche + definita con un intero positivo la macro \const{\_POSIX\_C\_SOURCE} lo stato + di questa non viene preso in considerazione. +\item[\const{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero + positivo si controlla quale livello delle funzionalità specificate da POSIX + viene messa a disposizione; più alto è il valore maggiori sono le + funzionalità. Se è uguale a '1' vengono attivate le funzionalità specificate + nella edizione del 1990 (IEEE Standard 1003.1-1990), valori maggiori o + uguali a '2' attivano le funzionalità POSIX.2 specificate nell'edizione del + 1992 (IEEE Standard 1003.2-1992). Un valore maggiore o uguale a `199309L' + attiva le funzionalità POSIX.1b specificate nell'edizione del 1993 (IEEE + Standard 1003.1b-1993). Un valore maggiore o uguale a `199506L' attiva le + funzionalità POSIX.1 specificate nell'edizione del 1996 (ISO/IEC 9945-1: + 1996). Valori superiori abiliteranno ulteriori estensioni. +\item[\const{\_BSD\_SOURCE}] definendo questa macro si attivano le + funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard + ISO C, POSIX.1 e POSIX.2. Alcune delle funzionalità previste da BSD sono + però in conflitto con le corrispondenti definite nello standard POSIX.1, in + questo caso le definizioni previste da BSD4.3 hanno la precedenza rispetto a + POSIX. A causa della natura dei conflitti con POSIX per ottenere una piena + compatibilità con BSD4.3 è necessario anche usare una libreria di + compatibilità, dato che alcune funzioni sono definite in modo diverso. In + questo caso occorre pertanto anche usare l'opzione \cmd{-lbsd-compat} con il + compilatore per indicargli di utilizzare le versioni nella libreria di + compatibilità prima di quelle normali. +\item[\const{\_SVID\_SOURCE}] definendo questa macro si attivano le + funzionalità derivate da SVID. Esse comprendono anche quelle definite negli + standard ISO C, POSIX.1, POSIX.2, and X/Open. +\item[\const{\_XOPEN\_SOURCE}] definendo questa macro si attivano le + funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste + sono un soprainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti + sia \const{\_POSIX\_SOURCE} che \const{\_POSIX\_C\_SOURCE} vengono + automaticamente definite. Sono incluse anche ulteriori funzionalità + disponibili in BSD e SVID. Se il valore della macro è posto a 500 questo + include anche le nuove definizioni introdotte con la \textit{Single UNIX + Specification, version 2}, cioè Unix98. +\item[\const{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le + ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio + \textit{X/Open Unix}. +\item[\const{\_ISOC99\_SOURCE}] definendo questa macro si attivano le + funzionalità previste per la revisione delle librerie standard del C + denominato ISO C99. Dato che lo standard non è ancora adottato in maniera + ampia queste non sono abilitate automaticamente, ma le \acr{glibc} hanno già + un'implementazione completa che può essere attivata definendo questa macro. +\item[\const{\_LARGEFILE\_SOURCE}] definendo questa macro si attivano le + funzionalità per il supporto dei file di grandi dimensioni (il \textit{Large + File Support} o LFS) con indici e dimensioni a 64 bit. +\item[\const{\_GNU\_SOURCE}] definendo questa macro si attivano tutte le + funzionalità disponibili: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, + X/Open, LFS più le estensioni specifiche GNU. Nel caso in cui BSD e POSIX + confliggano viene data la precedenza a POSIX. +\end{basedescript} + +In particolare è da sottolineare che le \acr{glibc} supportano alcune +estensioni specifiche GNU, che non sono comprese in nessuno degli +standard citati. Per poterle utilizzare esse devono essere attivate +esplicitamente definendo la macro \const{\_GNU\_SOURCE} prima di +includere i vari header file. + + +\subsection{Gli standard di GNU/Linux} +\label{sec:intro_linux_std} + +Da fare (o cassare, a seconda del tempo e della voglia). + + + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: