X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=intro.tex;h=0e24abdcae8ac88f61b91758135def140c0f2c05;hp=1dfaaf92f7d4da2fa3eedac8fa5b57f7c31adbf8;hb=6f8e0ca42d3d0b97b5e5747798a1eaffb44e8521;hpb=f67bf0a685d61f70c3536e1f258b96a658162f9e diff --git a/intro.tex b/intro.tex index 1dfaaf9..0e24abd 100644 --- a/intro.tex +++ b/intro.tex @@ -1,3 +1,13 @@ +%% intro.tex +%% +%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to +%% copy, distribute and/or modify this document under the terms of the GNU Free +%% Documentation License, Version 1.1 or any later version published by the +%% Free Software Foundation; with the Invariant Sections being "Un preambolo", +%% 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} @@ -27,7 +37,7 @@ Il concetto base di un sistema unix-like 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 +dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano alle risorse hardware tramite delle richieste a quest'ultimo. Fin dall'inizio uno Unix si presenta come un sistema operativo @@ -52,18 +62,19 @@ all'hardware, mentre i programmi normali vengono eseguiti in modalit (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{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. +Una parte del kernel, lo \textit{scheduler}\itindex{scheduler}, si occupa di +stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle +priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il +cosiddetto \textit{prehemptive + multitasking}\itindex{prehemptive~multitasking}). 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 +\textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a +ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi +sez.~\ref{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. @@ -71,13 +82,13 @@ 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}, su cui torneremo in dettaglio in -\capref{cha:file_intro}, (questo non è vero per le interfacce di rete, che +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). +il lavoro di accesso e gestione a basso livello è effettuato dal kernel. -\subsection{User space e kernel space} -\label{sec:intro_user_kernel_space} +\subsection{Il kernel e il sistema} +\label{sec:intro_kern_and_sys} Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è quello della distinzione fra il cosiddetto \textit{user space}, che @@ -99,20 +110,22 @@ all'hardware non pu kernel il programmatore deve usare le opportune interfacce che quest'ultimo fornisce allo user space. - -\subsection{Il kernel e il sistema} -\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-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. +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 appunto perché + in realtà c'è un programma iniziale, che è appunto 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 @@ -154,7 +167,17 @@ 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}. +standard, che esamineremo brevemente in sez.~\ref{sec:intro_standard}. Uno +schema elementare della struttura del sistema è riportato in +fig.~\ref{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 @@ -171,17 +194,22 @@ programma. Quanto appena illustrato mette in evidenza il fatto che nella stragrande maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie - del C, come le \textit{libc5} o le \textit{uclib}, che non derivano dal - progetto GNU, ma oggi sono, tranne casi particolari, completamente - soppiantate dalle \acr{glibc}.} 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. + 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 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 +\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 @@ -205,7 +233,7 @@ danneggiarsi a vicenda o danneggiare il sistema. 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 +(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 @@ -222,21 +250,25 @@ Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto \textit{default group}), ma può essere associato ad altri gruppi (i \textit{supplementary group}), questo permette di gestire i permessi di accesso ai file e quindi anche alle periferiche, in maniera più flessibile, -definendo gruppi di lavoro, di accesso a determinate risorse, etc. +definendo gruppi di lavoro, di accesso a determinate risorse, ecc. -L'utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad +L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad 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. +\file{/etc/groups}.\footnote{in realtà negli sistemi più moderni, come vedremo + in sez.~\ref{sec:sys_user_group} queste informazioni possono essere + mantenute, con l'uso del \textit{Name Service Switch}, su varie tipologie di + supporti, compresi server centralizzati come LDAP.} +\itindex{Name~Service~Switch} Questi numeri sono l'\textit{user identifier}, +detto in breve \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il +\textit{group identifier}, detto in breve \textsl{group-ID}, 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 -esso. Inoltre con questo sistema viene anche garantita una forma base di -sicurezza interna in quanto anche l'accesso ai file (vedi -\secref{sec:file_access_control}) è regolato da questo meccanismo di +In questo modo il sistema è in grado di tenere traccia dell'utente a cui +appartiene ciascun processo ed impedire ad altri utenti di interferire con +quest'ultimo. Inoltre con questo sistema viene anche garantita una forma base +di sicurezza interna in quanto anche l'accesso ai file (vedi +sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di identificazione. Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto @@ -245,7 +277,7 @@ Infine in ogni Unix 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) \{ ... \}}} + del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.} \section{Gli standard} @@ -283,36 +315,50 @@ 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 quindici header file -(anch'essi provvisti dalla \acr{glibc}), uno per ciascuna delle quindici aree -in cui è stata suddivisa una libreria standard. In -\tabref{tab:intro_posix_header} si sono riportati questi header, insieme a -quelli definiti negli altri standard descritti nelle sezioni successive. +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. \begin{table}[htb] \footnotesize \centering - \begin{tabular}[c]{|l|l|} + \begin{tabular}[c]{|l|c|c|l|} \hline - \textbf{Standard} & \textbf{Contenuto} \\ + \multirow{2}{*}{\textbf{Header}}& + \multicolumn{2}{|c|}{\textbf{Standard}}& + \multirow{2}{*}{\textbf{Contenuto}} \\ + \cline{2-3} + & ANSI C& POSIX& \\ \hline \hline - \file{assert.h}& Verifica le asserzioni fatte in un programma.\\ - \file{cpio.h} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{} & .\\ - \file{stdio.h} & I/O bufferizzato in standard ANSI C.\\ - \file{stdlib.h}& definizioni della libreria standard.\\ + \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$& & .\\ + \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 file di include definiti dallo standard POSIX.} + \caption{Elenco dei vari header file definiti dallo standard POSIX.} \label{tab:intro_posix_header} \end{table} @@ -331,16 +377,20 @@ usare le varie estensioni al linguaggio e al preprocessore da esso supportate. 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. +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 +\textit{tipi elementari}\index{tipo!elementare} 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 +associati ad alcune variabili nei sistemi Unix, dando per scontata la +dimensione. Ad esempio la posizione corrente all'interno di un file è sempre +stata associata ad un intero a 32 bit, mentre il numero di dispositivo è +sempre stato associato ad un intero a 16 bit. Storicamente questi erano +definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte +che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi +tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad +una infinita serie di problemi di portabilità. \begin{table}[htb] \footnotesize @@ -350,11 +400,11 @@ tipi si sono rivelati inadeguati, e se ne \textbf{Tipo} & \textbf{Contenuto} \\ \hline \hline - \type{caddr\_t} & core address.\\ - \type{clock\_t} & contatore del tempo di sistema.\\ + \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{ino\_t} & Numero di \textit{inode}\index{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.\\ @@ -363,8 +413,8 @@ tipi si sono rivelati inadeguati, e se ne \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{size\_t} & Dimensione di un oggetto.\\ + \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\ \type{ptrdiff\_t}& Differenza fra due puntatori.\\ \type{time\_t} & Numero di secondi (in tempo di calendario).\\ \type{uid\_t} & Identificatore di un utente.\\ @@ -375,10 +425,11 @@ tipi si sono rivelati inadeguati, e se ne \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 +riferimento ai tipi elementari dello standard del linguaggio C, ma ad una +serie di \textsl{tipi primitivi}\index{tipo!primitivo} del sistema, riportati +in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file +\file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi +utilizzati dalle funzioni di sistema dai tipi elementari supportati dal compilatore C. @@ -400,21 +451,20 @@ 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 +i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i +thread (1003.1d e 1003.1c) e vari altri. In tab.~\ref{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 inoltre che nuove specifiche e proposte di standardizzazione +si aggiungono continuamente, mentre le versioni precedenti vengono riviste; +talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le denominazioni usate diventa particolarmente faticoso; una pagina dove si -possono recuperare varie (e di norma piuttosto intricate) informazioni è: +possono recuperare varie (e di norma piuttosto intricate) informazioni è \href{http://www.pasc.org/standing/sd11.html} -{http://www.pasc.org/standing/sd11.html}. - +{\textsf{http://www.pasc.org/standing/sd11.html}}. \begin{table}[htb] \footnotesize @@ -429,27 +479,27 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni 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.4a& 1003.1c & --- & Thread \\ 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 \\ + POSIX.9 & 1003.9 & --- & Interfaccia per il Fortran-77 \\ + POSIX.12& 1003.1g& 9945-1& Socket \\ \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 +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. +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 @@ -459,11 +509,11 @@ 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 +\textit{thread} (vedi cap.~\ref{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}). +(sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del +tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O +asincrono (sez.~\ref{sec:file_asyncronous_io}). @@ -474,12 +524,12 @@ 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). +con l'abbreviazione XPG$n$ con $n$ che indica la versione). -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. +Nel 1989 il consorzio 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 @@ -514,33 +564,34 @@ 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 + Specification}, nota con la sigla SUSv2, in questa 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} +\subsection{Lo ``\textsl{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 +versioni allora 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 +API di grande rilievo, come i link simbolici, la funzione \code{select} ed 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. +commerciali come SunOS. Il kernel Linux e le \acr{glibc} provvedono tutte +queste estensioni che sono state in gran parte incorporate negli standard +successivi. \subsection{Lo standard System V} @@ -574,7 +625,7 @@ 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 +V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia \func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni matematiche. @@ -587,8 +638,9 @@ 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. +si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere +utilizzata 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 @@ -606,14 +658,15 @@ Le macro disponibili per i vari standard sono le seguenti: \item[\macro{\_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. + funzionalità. Se è uguale a ``\texttt{1}'' vengono attivate le funzionalità + specificate nella edizione del 1990 (IEEE Standard 1003.1-1990), valori + maggiori o uguali a ``\texttt{2}'' attivano le funzionalità POSIX.2 + specificate nell'edizione del 1992 (IEEE Standard 1003.2-1992). Un valore + maggiore o uguale a ``\texttt{199309L}'' attiva le funzionalità POSIX.1b + specificate nell'edizione del 1993 (IEEE Standard 1003.1b-1993). Un valore + maggiore o uguale a ``\texttt{199506L}'' attiva le funzionalità POSIX.1 + specificate nell'edizione del 1996 (ISO/IEC 9945-1: 1996). Valori superiori + abiliteranno ulteriori estensioni. \item[\macro{\_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 @@ -627,15 +680,15 @@ Le macro disponibili per i vari standard sono le seguenti: compatibilità prima di quelle normali. \item[\macro{\_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. + standard ISO C, POSIX.1, POSIX.2, e X/Open. \item[\macro{\_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 + sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che \macro{\_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. + disponibili in BSD e SVID. Se il valore della macro è posto a + ``\texttt{500}'' questo include anche le nuove definizioni introdotte con la + \textit{Single UNIX Specification, version 2}, cioè Unix98. \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio \textit{X/Open Unix}. @@ -660,10 +713,10 @@ esplicitamente definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header file. -\subsection{Gli standard di GNU/Linux} -\label{sec:intro_linux_std} +%% \subsection{Gli standard di GNU/Linux} +%% \label{sec:intro_linux_std} -Da fare (o cassare, a seconda del tempo e della voglia). +% TODO Da fare (o cassare, a seconda del tempo e della voglia).