\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, in questo modo potremo
+cui è basato un sistema 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 base dell'architettura di
+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.
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
+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
una macchina eseguendo più programmi ``in contemporanea'' (in realtà, almeno
%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 realizzati sfruttando alcune
+Gli 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
\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 è
+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
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
+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.
\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à la procedura di
+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
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
+Ogni versione di 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 cui si accede con il comando \cmd{man 2
+ 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}.
\subsection{Un sistema multiutente}
\label{sec:intro_multiuser}
-Linux, come gli altri unix, nasce fin dall'inizio come sistema multiutente,
+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.
\secref{sec:file_access_control}) è regolato da questo meccanismo di
identificazione.
-Infine in ogni unix è presente un utente speciale privilegiato, il cosiddetto
+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}
del tipo \texttt{if (uid) \{ ... \}}}
-\section{Gli standard di unix e GNU/Linux}
+\section{Gli standard di Unix e GNU/Linux}
\label{sec:intro_standard}
In questa sezione faremo una breve panoramica relativa ai vari standard che
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
+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 file
(anch'essi provvisti dalla \acr{glibc}), uno per ciascuna delle quindici aree
\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
+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 sistema unix, che venne presa
-come riferimento da vari produttori.
+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
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}.
+ Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
-\subsection{Gli standard UNIX -- Open Group}
+\subsection{Gli standard Unix -- Open Group}
\label{sec:intro_opengroup}
Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
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
+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
+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.
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
+ 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
tutte le parti uguali siano condivise), avrà un suo spazio di indirizzi,
variabili proprie e sarà eseguito in maniera completamente indipendente da
tutti gli altri.\footnote{questo non è del tutto vero nel caso di un programma
- \textit{multi-thread}, ma sulla gestione dei \textit{thread} in Linux
- torneremo più avanti.}
+ \textit{multi-thread}, ma la gestione dei \textit{thread} in Linux sarà
+ trattata a parte.}
\subsection{La funzione \func{main}}
argomenti o prendere due argomenti che rappresentano gli argomenti passati da
linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
- int main (int argc, char *argv[])
+ int main (int argc, char *argv[])
\end{lstlisting}
-In realtà nei sistemi unix esiste un'altro modo per definire la funzione
+In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
\func{main}, che prevede la presenza di un terzo parametro, \var{char
*envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
\label{sec:proc_term_conclusion}
Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
-in un sistema unix l'unico modo in cui un programma può essere eseguito dal
+in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
una delle funzioni della famiglia \func{exec} che vedremo in
\secref{sec:proc_exec}).
\subsection{La gestione delle opzioni}
\label{sec:proc_opt_handling}
-In generale un programma unix riceve da linea di comando sia gli argomenti che
+In generale un programma Unix riceve da linea di comando sia gli argomenti che
le opzioni, queste ultime sono standardizzate per essere riconosciute come
tali: un elemento di \var{argv} che inizia con \texttt{-} e che non sia un
singolo \texttt{-} o un \texttt{--} viene considerato un'opzione. In genere
normale pensare di poter effettuare questa operazione.
In generale però possono esistere anche realizzazioni diverse, per questo
-motivo \macro{va\_list} è definito come tipo opaco e non può essere assegnato
-direttamente ad un altra variabile dello stesso tipo. Per risolvere questo
-problema lo standard ISO C99\footnote{alcuni sistemi che non hanno questa
- macro provvedono al suo posto \macro{\_\_va\_copy} che era il nome proposto
- in una bozza dello standard.} ha previsto una macro ulteriore che permette
-di eseguire la copia di un puntatore alla lista degli argomenti:
+motivo \macro{va\_list} è definito come \textsl{tipo opaco} e non può essere
+assegnato direttamente ad un altra variabile dello stesso tipo. Per risolvere
+questo problema lo standard ISO C99\footnote{alcuni sistemi che non hanno
+ questa macro provvedono al suo posto \macro{\_\_va\_copy} che era il nome
+ proposto in una bozza dello standard.} ha previsto una macro ulteriore che
+permette di eseguire la copia di un puntatore alla lista degli argomenti:
\begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)}
Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti
su \param{dest}.
gestione ordinaria è in un'altra occorre usare quello che viene chiamato un
\textsl{salto non-locale}. Il caso classico in cui si ha questa necessità,
citato sia da \cite{APUE} che da da \cite{glibc}, è quello di un programma nel
-cui corpo principale in cui viene letto un input del quale viene eseguita
-attraverso una serie di funzioni di analisi una scansione dei contenuti da cui
+cui corpo principale in cui viene letto un input del quale viene eseguita,
+attraverso una serie di funzioni di analisi, una scansione dei contenuti da cui
ottenere le indicazioni per l'esecuzione di opportune operazioni.
Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
La funzione restituisce il valore dell'intervallo di tempo usato per la
politica \textit{round robin} in una struttura \var{timespec}, (la cui
-definizione si può trovare in \secref{fig:sig_timespec_def}).
+definizione si può trovare in \figref{fig:sys_timeval_struct}).
Come accennato ogni processo che usa lo scheduling real-time può rilasciare
indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
interferenze con l'uso di \macro{SIGALRM}. La funzione prende come parametri
-delle strutture di tipo \var{timespec}, la cui definizione è riportata in
-\figref{fig:sig_timespec_def}, che permettono di specificare un tempo con una
-precisione (teorica) fino al nanosecondo.
+delle strutture di tipo \var{timespec}, la cui definizione è riportata in
+\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
+una precisione (teorica) fino al nanosecondo.
La funzione risolve anche il problema di proseguire l'attesa dopo
l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
questo motivo il valore restituito in \param{rem} è sempre arrotondato al
multiplo successivo di 1/\macro{HZ}.
-\begin{figure}[!htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct timespec {
- time_t tv_sec; /* seconds */
- long tv_nsec; /* nanoseconds */
-};
- \end{lstlisting}
- \end{minipage}
- \normalsize
- \caption{La struttura \var{timespec} di \func{nanosleep}.}
- \label{fig:sig_timespec_def}
-\end{figure}
-
In realtà è possibile ottenere anche pause più precise del centesimo di
secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o
\macro{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
\footnotesize \centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
- struct statfs {
- long f_type; /* tipo di filesystem */
- long f_bsize; /* dimensione ottimale dei blocchi di I/O */
- long f_blocks; /* blocchi totali nel filesystem */
- long f_bfree; /* blocchi liberi nel filesystem */
- long f_bavail; /* blocchi liberi agli utenti normali */
- long f_files; /* inodes totali nel filesystem */
- long f_ffree; /* inodes liberi nel filesystem */
- fsid_t f_fsid; /* filesystem id */
- long f_namelen; /* lunghezza massima dei nomi dei file */
- long f_spare[6]; /* riservati per uso futuro */
- };
+struct statfs {
+ long f_type; /* tipo di filesystem */
+ long f_bsize; /* dimensione ottimale dei blocchi di I/O */
+ long f_blocks; /* blocchi totali nel filesystem */
+ long f_bfree; /* blocchi liberi nel filesystem */
+ long f_bavail; /* blocchi liberi agli utenti normali */
+ long f_files; /* inodes totali nel filesystem */
+ long f_ffree; /* inodes liberi nel filesystem */
+ fsid_t f_fsid; /* filesystem id */
+ long f_namelen; /* lunghezza massima dei nomi dei file */
+ long f_spare[6]; /* riservati per uso futuro */
+};
\end{lstlisting}
\end{minipage}
\normalsize
\centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
- struct rlimit {
- rlim_t rlim_cur;
- rlim_t rlim_max;
- };
+struct rlimit {
+ rlim_t rlim_cur;
+ rlim_t rlim_max;
+};
\end{lstlisting}
\end{minipage}
\normalsize
\centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
- struct tms {
- clock_t tms_utime; /* user time */
- clock_t tms_stime; /* system time */
- clock_t tms_cutime; /* user time of children */
- clock_t tms_cstime; /* system time of children */
- };
+struct tms {
+ clock_t tms_utime; /* user time */
+ clock_t tms_stime; /* system time */
+ clock_t tms_cutime; /* user time of children */
+ clock_t tms_cstime; /* system time of children */
+};
\end{lstlisting}
\end{minipage}
\normalsize
\subsection{Le funzioni per il \textit{calendar time}}
\label{sec:sys_time_base}
-Normalmente il \textit{calendar time} è mantenuto in una variabile di tipo
-\type{time\_t}, che usualmente corrisponde ad un tipo nativo (in Linux è un
-intero a 32 bit). Le \acr{glibc} provvedono delle rappresentazioni
-alternative che consentono un suo utilizzo per diversi scopi; in particolare
-quando necessita manipolare
+Come anticipato in \secref{sec:sys_unix_time} il \textit{calendar time} è
+mantenuto dal kernel in una variabile di tipo \type{time\_t}, che usualmente
+corrisponde ad un tipo nativo (in Linux è un intero a 32 bit). Il valore
+corrente del \textit{calendar time} può essere ottenuto con la funzione
+\func{time} che lo restituisce in nel suddetto formato; il suo prototipo è:
+\begin{prototype}{time.h}{time\_t time(time\_t *t)}
+ Legge il valore corrente del \textit{calendar time}.
+
+ \bodydesc{La funzione ritorna valore del \textit{calendar time} in caso di
+ successo e -1 in caso di errore, che può essere solo \macro{EFAULT}.}
+\end{prototype}
+\noindent dove \param{t}, se non nullo, è l'indirizzo su cui salvare il valore
+di ritorno.
+
+Analoga a \func{time} è la funzione \func{stime} che serve per effettuare
+l'operazione inversa, e cioè per settare l'orologio di sistema; il suo
+prototipo è:
+\begin{prototype}{time.h}{int stime(time\_t *t)}
+ Setta a \param{t} il valore corrente del \textit{calendar time}.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
+ che può essere \macro{EFAULT} o \macro{EPERM}.}
+\end{prototype}
+
+Dato che modificare l'ora ha un impatto su tutto il sistema, la funzione può
+essere usata solo dall'ammninistratore.
+
+
+Dato che il tempo misurato in termini di\type{time\_t} ha comunque una
+risoluzione massima di un secondo le \acr{glibc} provvedono delle
+rappresentazioni alternative che consentono di indicare intervalli o tempi con
+precisioni maggiori del secondo, queste sono realizzate attraverso le
+strutture \var{timeval} e \var{timespec}, le cui definizioni sono riportate in
+\figref{fig:sys_timeval_struct}, che consentono rispettivamente precisioni del
+microsecondo e del nanosecondo\footnote{la precisione è solo astratta,
+ l'orologio di sistema normalmente non è in grado di misuare dei tempi con
+ precisioni simili.}.
\begin{figure}[!htb]
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct timeval
{
- long tv_sec; /* seconds */
- long tv_usec; /* microseconds */
+ long tv_sec; /* seconds */
+ long tv_usec; /* microseconds */
+};
+struct timespec {
+ time_t tv_sec; /* seconds */
+ long tv_nsec; /* nanoseconds */
};
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{timeval} per il calendar time.}
+ \caption{Le strutture \var{timeval} e \var{timespec} per il calendar time.}
\label{fig:sys_timeval_struct}
\end{figure}
+Data la scarsa precisione nell'uso di \type{time\_t} per le operazioni sui
+tempi di norma l'uso delle funzioni precedenti è di norma sconsigliato, ed
+esse sono di solito sostituite da \func{gettimeofday} e \func{settimeofday}
+
+
+
+
+\subsection{Le \textit{timezone} e la gestione delle date.}
+\label{sec:sys_time_base}
projects / gapil.git / commitdiff