X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=intro.tex;h=e8d8a1f75c0bc11ffa3348772b082ad8a892e65f;hp=43efa10e4dcaa9a2151b6fa3557dcf5cb7bc3f22;hb=7090500d79c488db306ed0c065b90bb0c0505430;hpb=a2ac131d4c65656c87e4998f13845cce2213d324 diff --git a/intro.tex b/intro.tex index 43efa10..e8d8a1f 100644 --- a/intro.tex +++ b/intro.tex @@ -6,7 +6,7 @@ cui fornire una base di comprensione mirata a sottolineare le peculiarità del sistema che sono più rilevanti per quello che riguarda la programmazione. -Dopo una introduzione sulle caratteristiche principali di un sistema di tipo +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. @@ -51,7 +51,7 @@ 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à +\textit{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. @@ -67,19 +67,19 @@ 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:files_intro}, (questo non è vero per le interfacce di rete, che +\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 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 +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 essere messi in esecuzione dal kernel. @@ -138,9 +138,9 @@ 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 funzioni, che un programma può chiamare, -per le quali viene generata una interruzione processo ed il controllo passa -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 +per le quali viene generata un'interruzione processo ed il controllo passa 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. @@ -193,16 +193,16 @@ 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 +procedura si incarica di verificare l'identità dell'utente, in genere attraverso la richiesta di una parola d'ordine, anche se sono possibili -meccanismi diversi\footnote{Ad esempio usando la libreria PAM +meccanismi diversi.\footnote{Ad esempio usando la libreria PAM (\textit{Pluggable Autentication Methods}) è possibile astrarre completamente i meccanismi di autenticazione e sostituire ad esempio l'uso - delle password con meccanismi di identificazione biometrica}. + 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 @@ -212,7 +212,7 @@ 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 espresso in caratteri è inserita nei due files \file{/etc/passwd} e +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 \acr{uid}, e il \textit{group identifier}, detto in breve \acr{gid}, che sono quelli che poi vengono usati dal kernel per identificare l'utente. @@ -229,8 +229,8 @@ Infine in ogni unix \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 \texttt{if (uid) \{ ... \}}}. +disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice + del tipo \texttt{if (uid) \{ ... \}}} \section{Gli standard di unix e GNU/Linux} @@ -253,7 +253,7 @@ GNU/Linux (sia per quanto riguarda il kernel che le \acr{glibc}). Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National Standard Institute}, come standard del linguaggio C ed è stato -successivamente adottatto dalla \textit{International Standard Organisation} +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. @@ -266,7 +266,7 @@ 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 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 files +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 \ntab\ si sono riportati questi header, insieme a quelli definiti negli altri standard descritti nelle @@ -275,7 +275,7 @@ sezioni successive. 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à adizionali) usando il \cmd{gcc} con l'opzione +(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. @@ -285,29 +285,28 @@ usare le varie estensioni al linguaggio e al preprocessore da esso supportate. \label{sec:intro_posix} Uno standard più attinente al sistema nel suo complesso (e che concerne sia il -kernel che le librerie e` 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. Le estensioni -principali sono +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 +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 -le utilities di sistema (1003.2), per le estensioni realtime e per i thread +le utility di sistema (1003.2), per le estensioni realtime e per i thread (1003.1d e 1003.1c) e vari altri. -Benché lo standard POSIX sia basato sui sistemi unix esso definisce comunque -una interfaccia e non fa riferimento ad una specifica implementazione (ad -esempio esiste anche una implementazione di questo standard pure sotto Windows -NT). Lo standard si è evoluto nel tempo ed una versione più aggiornata (quella -che viene normalmente denominata POSIX.1) è stata rilasciata come standard -internazionale con la sigla ISO/IEC 9945-1:1996. +Benché lo standard POSIX sia basato sui sistemi Unix esso definisce comunque +un'interfaccia e non fa riferimento ad una specifica implementazione (ad +esempio esiste un'implementazione di questo standard anche sotto Windows NT). +Lo standard si è evoluto nel tempo ed una versione più aggiornata (quella che +viene normalmente denominata POSIX.1) è stata rilasciata come standard +internazionale con la sigla ISO/IEC 9945-1:1996. Le \acr{glibc} implementano tutte le funzioni definite nello standard POSIX.1, e Linux; @@ -317,50 +316,202 @@ e Linux; \label{sec:intro_xopen} Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi -unix per giungere ad una armonizzazione dele varie implementazioni di unix. -Per far questo iniziò a pubblicare una serie di documentazioni e specifiche -sotto il nome di \textit{X/Open Portability Guide} (che chiameremo XPGn). +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 della sua guida particolarmente -voluminosa (la \textit{X/Open Portability Guide, Issue 3}), che venne presa -come riferimento da vari produttori, e al cui interno definiva una ulteriore -standardizzazione dell'interfaccia ad un sistema unix. +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 sistema 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 per l'interfaccia grafica (X11). -Nel 1992 lo standard venne rivisto con una nuova versione della guida (XPG4) -che aggiungeva l'interfaccia XTI (\textit{X transport Interface}) mirante a -soppiantare (senza molto successo) quella l'interfaccia dei socket derivata da -BSD. +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}, SUSv2, più comunemente nota come \textit{Unix 95}. \subsection{Gli standard UNIX -- Open Group} \label{sec:intro_opengroup} -Nel 1993 il marchi 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}, - - - - - -\subsection{Il comportamento standard del \cmd{gcc}} -\label{sec:intro_gcc_behaviuor} - - - - - -\subsection{Prototipi e puntatori} -\label{sec:intro_function} - - -\subsection{Tipi di dati primitivi} -\label{sec:intro_data_types} - - - +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 +di API 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. 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 dell 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 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. + +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 gli standard appena descritti sono ottenibili sia attraverso l'uso di +opzioni del compilatore (il \cmd{gcc}) che definendo opportune costanti prima +della 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[\macro{\_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 \macro{\_POSIX\_C\_SOURCE} lo stato + di questa non viene preso in considerazione. +\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. +\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 + 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[\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. +\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 + 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. +\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}. +\item[\macro{\_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[\macro{\_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[\macro{\_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 \macro{\_GNU\_SOURCE} prima di +includere i vari header file. + + +\subsection{Gli standard di 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: