%% intro.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% 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 "Prefazione",
+%% 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".
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
(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
+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{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.
+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
+\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
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
-cap.~\ref{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
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
\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{user-ID}, ed indicato dall'acronimo \acr{uid}, e il
+\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.
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}
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,
-insieme a quelli definiti negli altri standard descritti nelle sezioni
-successive.
+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
& 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.\\
+ \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 header file definiti dallo standard POSIX.}
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
+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.
\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}\index{inode}.\\
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 tab.~\ref{tab:intro_posix_std} è
+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 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
\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
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
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
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}
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
\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
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}.
%% \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).
projects / gapil.git / blobdiff