From 2c682ba44f85eb183ddf75760b38bf048f89de53 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sat, 11 May 2002 12:03:06 +0000 Subject: [PATCH] Correzioni varie --- intro.tex | 50 ++++++++++++------------ process.tex | 28 +++++++------- prochand.tex | 2 +- signal.tex | 21 ++--------- system.tex | 105 ++++++++++++++++++++++++++++++++++++--------------- 5 files changed, 118 insertions(+), 88 deletions(-) diff --git a/intro.tex b/intro.tex index e8d8a1f..79b337f 100644 --- a/intro.tex +++ b/intro.tex @@ -2,12 +2,12 @@ \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. @@ -26,7 +26,7 @@ anche la parte che prevede l'interazione con l'utente, deve venire realizzato 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 @@ -38,7 +38,7 @@ a rotazione). %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 @@ -75,7 +75,7 @@ il lavoro di accesso e gestione a basso livello \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 @@ -86,11 +86,11 @@ essere messi in esecuzione dal kernel. 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. @@ -100,8 +100,8 @@ 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 @@ -144,9 +144,9 @@ 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 +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}. @@ -180,7 +180,7 @@ quello di una chiamata al sistema. \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. @@ -224,7 +224,7 @@ 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, 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} @@ -233,7 +233,7 @@ disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice 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 @@ -264,7 +264,7 @@ anche una libreria di funzioni che devono poter essere implementate su 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 @@ -316,15 +316,15 @@ e Linux; \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 @@ -341,10 +341,10 @@ Nel 1993 il marchio Unix pass 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 @@ -373,10 +373,10 @@ di Berkley e la AT/T gener 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. @@ -478,7 +478,7 @@ Le macro disponibili per i vari standard sono le seguenti: 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 diff --git a/process.tex b/process.tex index 4d02cbc..e3a4774 100644 --- a/process.tex +++ b/process.tex @@ -24,8 +24,8 @@ ciascun processo vedr 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}} @@ -50,10 +50,10 @@ Lo standard ISO C specifica che la funzione \func{main} pu 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 @@ -211,7 +211,7 @@ stream aperti, infine verr \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}). @@ -846,7 +846,7 @@ questo meccanismo \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 @@ -1336,12 +1336,12 @@ stack all'indirizzo dove sono stati salvati i parametri, 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}. @@ -1413,8 +1413,8 @@ un'altra funzione, per cui se l'errore avviene in una funzione e la sua 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 diff --git a/prochand.tex b/prochand.tex index a8be792..7e4c843 100644 --- a/prochand.tex +++ b/prochand.tex @@ -2303,7 +2303,7 @@ il suo prototipo 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 diff --git a/signal.tex b/signal.tex index 7904fa9..09f8325 100644 --- a/signal.tex +++ b/signal.tex @@ -1330,9 +1330,9 @@ Lo standard richiede che la funzione sia implementata in maniera del tutto 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 @@ -1349,21 +1349,6 @@ sia scarico ed il processa venga immediatamente rimesso in esecuzione); per 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 diff --git a/system.tex b/system.tex index fd0284d..01930a0 100644 --- a/system.tex +++ b/system.tex @@ -882,18 +882,18 @@ nome del filesystem stesso. \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 @@ -1455,10 +1455,10 @@ corrente e massimo. \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 @@ -1782,12 +1782,12 @@ struttura di tipo \var{tms}, la cui definizione \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 @@ -1812,11 +1812,43 @@ questi ``nipoti'' non potranno essere considerati nel calcolo di questi tempi. \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] @@ -1826,16 +1858,29 @@ quando necessita manipolare \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} -- 2.30.2