X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=intro.tex;h=d6eefa583b8af41333ddad6c3b7553fd5f335c7c;hp=d2833478591e6539840f760e020d0ee240da36ae;hb=e9aa62ccbeefc114915aba31f257d55f6c19a05a;hpb=2567503eef2f6e35067c3795a744d04bc9317c91 diff --git a/intro.tex b/intro.tex index d283347..d6eefa5 100644 --- a/intro.tex +++ b/intro.tex @@ -6,8 +6,8 @@ cui 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 +Dopo una 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. @@ -28,7 +28,7 @@ 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). @@ -42,7 +42,7 @@ Gli unix pi 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 @@ -56,7 +56,7 @@ protetta; quando necessario il processo potr soltanto attraverso delle opportune chiamate al sistema che restituiranno il controllo al kernel. -La memoria viene sempre gestita del kernel attraverso il meccanismo della +La memoria viene sempre gestita dal kernel attraverso il meccanismo della \textsl{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 @@ -75,10 +75,10 @@ il lavoro di accesso e gestione a basso livello \section{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 +\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 della memoria ed è, salvo i meccanismi di comunicazione previsti dall'architettura, completamente ignaro del fatto che altri programmi possono @@ -102,31 +102,31 @@ fornisce allo user space. Per capire meglio la distinzione fra kernel space e user space si può prendere in esame la procedura di avvio di un sistema unix; 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 +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 i quali -c'è 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 stessa \textit{shell} da cui inviare i comandi. +inizializzato le periferiche, farà partire il primo processo, \cmd{init}, che +è quello che a sua volta farà partire tutti i processi successivi. Fra questi +ci sarà pure quello che si occupa di dialogare con la tastiera e lo schermo +della console, e quello che mette a disposizione dell'utente che si vuole +collegare, un terminale e la \textit{shell} da cui inviare i comandi. E' da rimarcare come tutto ciò, che usualmente viene visto come parte del sistema, non abbia in realtà niente a che fare con il kernel, ma sia effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un qualunque programma di scrittura o di disegno, in user space. -Questo significa ad esempio che il sistema di per sé non dispone di primitive -per tutta una serie di operazioni (come la copia di un file) che 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. +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 +Per questo motivo è più corretto parlare di un 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. @@ -138,41 +138,41 @@ 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 e il controllo è passato +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 il l'allocazione -della memoria) eseguirà la funzione richiesta in kernel space restituendo i +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 \cmd{man 2 - nome}) e GNU/Linux non fa eccezione. Queste sono poi state codificate da vari -standard, che esamineremo brevemente in \secref{sec:intro_standard}. + programmazione di unix} (quella cui si accede con il comando \cmd{man 2 + nome}) e GNU/Linux non fa eccezione. Queste sono poi state codificate da +vari standard, che esamineremo brevemente in \secref{sec:intro_standard}. 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 una serie +di ulteriori funzioni, 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 +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. +manipolazione delle stringhe, presenti in qualunque programma. Anche 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 +GNU Standard C Library, detta in breve \textit{glibc}), in cui sono state implementate tutte le funzioni essenziali definite negli standard POSIX e ANSI C, che vengono utilizzate da qualunque programma. Le funzioni di questa libreria sono quelle riportate dalla terza sezione del -Manuale di Programmazione di Unix (cioè accessibili con il comando \cmd{man 2 - nome}), e sono costruite sulla base delle chiamate al sistema del kernel; è +Manuale di Programmazione di Unix (cioè accessibili con il comando \cmd{man 3 + nome}) e sono costruite sulla base delle chiamate al sistema del kernel; è importante avere presente questa distinzione, fondamentale dal punto di vista -dell'implementazione, anche se poi nella realizzazione di normali programmi +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. @@ -182,18 +182,18 @@ quello di una chiamata al sistema. 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. +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 +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\footnote{Ad esempio usando la libreria PAM (\textit{Pluggable Autentication Methods}) è possibile astrarre @@ -212,10 +212,10 @@ 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 poi vengono usati dal kernel per riconoscere l'utente. +un nome 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 poi 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 @@ -224,12 +224,13 @@ sicurezza interna in quanto anche l'accesso ai file (vedi \secref{sec:file_access_control}) è regolato da questo meccanismo di identificazione. -Infine in ogni unix è presente un utente speciale privilegiato, di norma -chiamato \textit{root}, 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 \texttt{if (uid) \{ ... \}}}. +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 \texttt{if (uid) \{ ... \}}}. \section{Gli standard di unix e GNU/Linux} @@ -254,8 +255,8 @@ come standard internazionale con la sigla ISO/IEC 9899:1990. Scopo dello standard è quello di garantire la portabilità dei programmi C fra sistemi operativi diversi, ma oltre alla sintassi e alla semantica del linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede -anche una libreria di funzioni standard che devono poter essere implementate -su qualunque sistema operativo. +anche una libreria di funzioni che devono poter essere implementate su +qualunque sistema operativo. Linux, come molti unix moderni, provvede la compatibilità con questo standard, fornendo le funzioni di libreria da esso previste; queste sono dichiarate in @@ -270,18 +271,18 @@ In realt 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 ha prodotto un primo una prima versione, nota come IEEE 1003.1-1988, -mirante a standardizzare l'interfaccia con il sistema operativo. +che ne ha prodotto 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 -(1003.1d e 1003.1c) e molti altri. +(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 (per cui -esiste ad esempio anche una implementazione di questo standard pure sotto -Windows NT). Lo standard si è evoluto nel tempo ed una nuova versione (quella +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:1990. @@ -289,9 +290,9 @@ internazionale con la sigla ISO/IEC 9945-1:1990. \subsection{Lo standard X/Open -- XPG3} \label{sec:intro_xopen} -Il consorzio X/Open nasce come consorzio di venditori di sistemi unix, che nel -1989 produsse una voluminosa guida chiamata \textit{X/Open Portability Guide, - Issue 3} al cui interno definiva una ulteriore standardizzazione +Il consorzio X/Open nacque come consorzio di venditori di sistemi unix, che +nel 1989 produsse una voluminosa guida chiamata \textit{X/Open Portability + Guide, Issue 3} al cui interno definiva una ulteriore standardizzazione dell'interfaccia ad un sistema unix. Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre