From 608bbf38416013dc331e1ef2e5dfe01855b6158b Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 6 Nov 2001 18:51:07 +0000 Subject: [PATCH 1/1] Correzioni varie piu qualce notizia in piu` sugli standard --- filedir.tex | 12 ----------- fileunix.tex | 61 +++++++++++++++++++++++++++------------------------- gapil.tex | 6 +++--- intro.tex | 51 ++++++++++++++++++++++++++++++------------- macro.tex | 2 ++ 5 files changed, 73 insertions(+), 59 deletions(-) diff --git a/filedir.tex b/filedir.tex index 19f347d..b985da1 100644 --- a/filedir.tex +++ b/filedir.tex @@ -108,7 +108,6 @@ funzione restituisce l'errore \macro{EPERM}. La rimozione di un file (o più precisamente della voce che lo referenzia all'interno di una directory) si effettua con la funzione \func{unlink}; il suo prototipo è il seguente: - \begin{prototype}{unistd.h}{int unlink(const char * pathname)} Cancella il nome specificato dal pathname nella relativa directory e decrementa il numero di riferimenti nel relativo inode. Nel caso di link @@ -173,7 +172,6 @@ funzione \func{remove}. Questa per cancellare un file o una directory (e funziona anche per i sistemi che non supportano i link diretti). Per i file è identica a \func{unlink} e per le directory è identica a \func{rmdir}: - \begin{prototype}{stdio.h}{int remove(const char *pathname)} Cancella un nome dal filesystem. Usa \func{unlink} per i file e \func{rmdir} per le directory. @@ -187,7 +185,6 @@ Per cambiare nome ad un file o a una directory (che devono comunque essere nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la funzione è definita dallo standard ANSI C solo per i file, POSIX estende la funzione anche alle directory}, il cui prototipo è: - \begin{prototype}{stdio.h} {int rename(const char *oldpath, const char *newpath)} @@ -276,7 +273,6 @@ funzioni di libreria (come \func{open} o \func{stat}) dare come parametro un link simbolico comporta l'applicazione della funzione al file da esso specificato. La funzione che permette di creare un nuovo link simbolico è \func{symlink}; il suo prototipo è: - \begin{prototype}{unistd.h} {int symlink(const char * oldpath, const char * newpath)} Crea un nuovo link simbolico di nome \func{newpath} il cui contenuto è @@ -355,7 +351,6 @@ Dato che, come indicato in \tabref{tab:file_symb_effect}, funzioni come la alle informazioni del link invece che a quelle del file a cui esso fa riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa la funzione \func{readlink}, il cui prototipo è: - \begin{prototype}{unistd.h} {int readlink(const char * path, char * buff, size\_t size)} Legge il contenuto del link simbolico indicato da \var{path} nel buffer @@ -436,7 +431,6 @@ Queste due funzioni servono per creare e cancellare delle directory e sono omonime degli analoghi comandi di shell. Per poter accedere ai tipi usati da queste funzioni si deve includere il file \file{sys/types.h}, il prototipo della prima è: - \begin{prototype}{sys/stat.h} {int mkdir (const char * dirname, mode\_t mode)} Crea una nuova directory vuota con il nome indicato da \var{dirname}, @@ -474,7 +468,6 @@ titolarit La seconda funzione serve ad eliminare una directory già vuota (la directory deve cioè contenere soltanto le due voci standard \file{.} e \file{..}); il suo prototipo è: - \begin{prototype}{sys/stat.h} {int rmdir (const char * dirname)} Cancella la directory \var{dirname}, che deve essere vuota. Il nome può essere indicato con il pathname assoluto o @@ -548,7 +541,6 @@ directory corrente di qualunque comando da essa lanciato. In genere il kernel tiene traccia per ciascun processo dell'inode della directory di lavoro corrente, per ottenere il pathname occorre usare una apposita funzione di libreria, \func{getcwd}, il cui prototipo è: - \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)} Restituisce il filename completo della directory di lavoro corrente nella stringa puntata da \var{buffer}, che deve essere precedentemente @@ -600,7 +592,6 @@ nome (che deriva da \textit{change directory}), per cambiare la directory di lavoro corrente. Dato che anche le directory sono file, è possibile riferirsi ad esse anche tramite il file descriptor dell'interfaccia a basso livello, e non solo tramite il filename, i prototipi di queste funzioni sono: - \begin{functions} \headdecl{unistd.h} \funcdecl{int chdir (const char * path)} @@ -1014,7 +1005,6 @@ esiste. I tempi di ultimo accesso e modifica possono essere cambiati usando la funzione \func{utime}, il cui prototipo è: - \begin{prototype}{utime.h} {int utime(const char * filename, struct utimbuf *times)} @@ -1393,7 +1383,6 @@ l'\acr{uid} dell'utente che ha lanciato il programma, che, come accennato in \secref{sec:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è detto sia uguale all'\textit{effective user id}). Per far questo si può usare la funzione \func{access}, il cui prototipo è: - \begin{prototype}{unistd.h} {int access(const char *pathname, int mode)} @@ -1420,7 +1409,6 @@ possa scrivere come in un file, e il fatto che un file abbia permesso di esecuzione non comporta che contenga un programma eseguibile. La funzione ritorna zero solo se tutte i permessi controllati sono disponibili, in caso contrario (o di errore) ritorna -1. - \begin{table}[htb] \centering \footnotesize diff --git a/fileunix.tex b/fileunix.tex index 9f02114..5734c43 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -16,11 +16,9 @@ ANSI C. In questa sezione faremo una breve introduzione sulla architettura su cui è basata dell'interfaccia dei \textit{file descriptor}, che, sia pure con differenze di implementazione, è comune ad ogni implementazione di unix. -Vedremo cosa comporti questa architettura in caso di accesso contemporaneo ai -file da parte di più processi. -\subsection{L'architettura dei \textit{file descriptors}} +\subsection{L'architettura dei \textit{file descriptor}} \label{sec:file_fd} Per poter accedere al contenuto di un file occorre creare un canale di @@ -33,7 +31,7 @@ dovr ogni ulteriore operazione. All'interno di ogni processo i file aperti sono identificati da un intero non -negativo, chiamato appunto \textit{file descriptors}, quando un file viene +negativo, chiamato appunto \textit{file descriptor}, quando un file viene aperto la funzione restituisce il file descriptor, e tutte le successive operazioni devono passare il \textit{file descriptors} come argomento. @@ -43,10 +41,10 @@ sempre un elenco dei processi attivi nella cosiddetta \textit{process table} ed un elenco dei file aperti nella \textit{file table}. La \textit{process table} è una tabella che contiene una voce per ciascun -processo attivo nel sistema. In Linux la tabella è costituita da strutture di -tipo \var{task\_struct} nelle quali sono raccolte tutte le informazioni -relative ad un singolo processo; fra queste informazioni c'è anche il -puntatore ad una ulteriore struttura di tipo \var{files\_struct} in cui sono +processo attivo nel sistema. In Linux ciascuna voce è costituita da una +struttura di tipo \var{task\_struct} nella quale sono raccolte tutte le +informazioni relative al processo; fra queste informazioni c'è anche il +puntatore ad una ulteriore struttura di tipo \var{files\_struct}, in cui sono contenute le informazioni relative ai file che il processo ha aperto, ed in particolare: \begin{itemize*} @@ -56,7 +54,7 @@ particolare: \textit{file table} per ogni file aperto. \end{itemize*} il \textit{file descriptor} in sostanza è l'intero positivo che indicizza -questa tabella. +quest'ultima tabella. La \textit{file table} è una tabella che contiene una voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da strutture di tipo @@ -64,7 +62,8 @@ che file, fra cui: \begin{itemize*} \item lo stato del file (nel campo \var{f\_flags}). -\item il valore della posizione corrente (l'\textit{offset}) nel file. +\item il valore della posizione corrente (l'\textit{offset}) nel file (nel + campo \var{f\_pos}). \item un puntatore all'inode\footnote{nel kernel 2.4.x si è in realtà passati ad un puntatore ad una struttura \var{dentry} che punta a sua volta all'inode passando per la nuova struttura del VFS} del file. @@ -142,8 +141,8 @@ Nelle vecchie versioni di unix (ed anche in Linux fino al kernel 2.0.x) il numero di file aperti era anche soggetto ad un limite massimo dato dalle dimensioni del vettore di puntatori con cui era realizzata la tabella dei file descriptor dentro \var{file\_struct}; questo limite intrinseco non sussiste -più, dato che si è passati ad una linked list, restano i limiti imposti -dall'amministratore (vedi \secref{sec:sys_limits}). +più, dato che si è passati da un vettore ad una linked list, ma restano i +limiti imposti dall'amministratore (vedi \secref{sec:sys_limits}). @@ -207,7 +206,7 @@ prototipo La funzione apre il file, usando il primo file descriptor libero, e crea l'opportuna voce (cioè la struttura \var{file}) nella file table. Viene usato -sempre il file descriptor con il valore più basso, questa caratteritica +sempre il file descriptor con il valore più basso, questa caratteristica permette di prevedere qual'è il valore che si otterrà e viene talvolta usata da alcune applicazioni per sostituire i file corrispondenti ai file standard di \secref{sec:file_std_descr}: se ad esempio si chiude lo standard input e si @@ -221,37 +220,40 @@ restare aperto attraverso una \func{exec} (come accennato in \secref{sec:proc_exec}) ed l'offset è settato all'inizio del file. Il parametro \var{mode} specifica i permessi con cui il file viene -eventualmente creato; i valori possibili gli stessi già visti in +eventualmente creato; i valori possibili sono gli stessi già visti in \secref{sec:file_perm_overview} e possono essere specificati come OR binario delle costanti descritte in \tabref{tab:file_bit_perm}. Questi permessi -filtrati dal valore di \file{umask} per il processo. +filtrati dal valore di \file{umask} (vedi \secref{sec:file_umask}) per il +processo. La funzione prevede diverse opzioni, che vengono specificate usando vari bit -del parametro \var{flags}. Alcuni di questi vanno anche a costituire lo il +del parametro \var{flags}. Alcuni di questi bit vanno anche a costituire il flag di stato del file (o \textit{file status flag}), che è mantenuto nel -campo \var{f\_flags} della struttura \var{file} (vedi \curfig). Questi -bit sono divisi in tre categorie principali: +campo \var{f\_flags} della struttura \var{file} (al solito si veda lo schema +di \curfig). Essi sono divisi in tre categorie principali: \begin{itemize} \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità - si accede al file: i valori possibili sono lettura, scrittura o + si accederà al file: i valori possibili sono lettura, scrittura o lettura/scrittura. Uno di questi bit deve essere sempre specificato quando si apre un file. Vengono settati alla chiamata da \func{open}, e possono essere riletti con una \func{fcntl} (fanno parte del \textit{file status flag}), ma non modificati. \item \textsl{i bit delle modalità di apertura}: permettono di specificare - alcuni dei modi di funzionamento di \func{open}. Hanno effetto solo al - momento della chiamata della funzione e non sono memorizzati nè possono - essere riletti. + alcune delle caratteristiche del comportamento di \func{open} quando viene + eseguita. Hanno effetto solo al momento della chiamata della funzione e non + sono memorizzati nè possono essere riletti. \item \textsl{i bit delle modalità di operazione}: permettono di specificare - alcuni effetti validi anche in seguito per il comportamento delle operazioni - sul file (come la \func{read} o la \func{write}). Anch'essi fanno parte del + alcune caratteristiche del comportamento delle future operazioni sul file + (come la \func{read} o la \func{write}). Anch'essi fanno parte del \textit{file status flag}. Il loro valore è settato alla chiamata di - \func{open}, ma possono essere riletti e modificati con una \func{fcntl}. + \func{open}, ma possono essere riletti e modificati (insieme alle + caratteristiche operative che controllano) con una \func{fcntl}. \end{itemize} In \ntab\ si sono riportate, ordinate e divise fra loro secondo le tre -modalità appena elencate, le costanti che identificano i vari bit, queste -possono essere combinate con un OR aritmetico per costruire il valore del +modalità appena elencate, le costanti mnemoniche associate a ciascuno di +questi bit, dette costanti possono essere combinate fra di loro con un OR +aritmetico per costruire il valore (in forma di maschera binaria) del parametro \var{flags} da passare alla \func{open} per specificarne il comportamento. @@ -344,8 +346,9 @@ comportamento. \end{table} Nelle prime versioni di unix i flag specificabili per \func{open} erano solo -quelli delle modalità di apertura. Per questo motivo per creare un file c'era -una system call apposita, \func{creat}, il cui prototipo è: +quelli relativi alle modalità di accesso del file. Per questo motivo per +creare un nuovo file c'era una system call apposita, \func{creat}, il cui +prototipo è: \begin{prototype}{fcntl.h} {int creat(const char *pathname, mode\_t mode)} diff --git a/gapil.tex b/gapil.tex index 1007fbc..b7e32c3 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Oct. 2000 @@ -36,8 +36,8 @@ %\includeonly{macro,pref,intro,fdl} -\title{\Huge \textbf{GaPiL}\\ -Guida alla Programmazione in Linux.} +\title{\Huge \textbf{\textsl{G}a\textsl{P}i\textsl{L}}\\ +\huge Guida alla Programmazione in Linux.} \author{Simone Piccardi} diff --git a/intro.tex b/intro.tex index 6e6fe60..cd878bf 100644 --- a/intro.tex +++ b/intro.tex @@ -236,13 +236,10 @@ disattivati\footnote{i controlli infatti vengono sempre eseguiti da un codice \section{Gli standard di unix e GNU/Linux} \label{sec:intro_standard} -In questa sezione prenderemo in esame alcune caratteristiche generali del -sistema e gli standard adottati per le funzioni, i prototipi, gli errori, i -tipi di dati. - -\subsection{Prototipi e puntatori} -\label{sec:intro_function} - +In questa sezione prenderemo faremo una breve panoramica yrelativi ai vari +standard che nel tempo sono stati formalizzati da enti, associazioni, e +organizzazioni varie riguardanti interfacce di programmazioni e +caratteristiche di un sistema unix-like. \subsection{Lo standard ANSI C} \label{sec:intro_ansiC} @@ -264,7 +261,7 @@ quindici header files, uno per ciascuna delle quindici aree in cui suddivisa la libreria. In \ntab\ si sono riportati questi header, insieme a quelli definiti negli altri standard descritti nelle sezioni successive. -\subsection{Lo standard POSIX} +\subsection{Lo standard IEEE -- POSIX} \label{sec:intro_posix} In realtà POSIX è una famiglia di standard diversi, il nome, suggerito da @@ -290,16 +287,40 @@ internazionale con la sigla ISO/IEC 9945-1:1990. \subsection{Lo standard X/Open -- XPG3} \label{sec:intro_xopen} -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. +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). + + +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. Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre -basato sullo standard POSIX.1, ma prevede una serie di funzionalità -aggiuntive. +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. + -Il consorzio +\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{Prototipi e puntatori} +\label{sec:intro_function} \subsection{Tipi di dati primitivi} diff --git a/macro.tex b/macro.tex index 05509cc..ad70c83 100644 --- a/macro.tex +++ b/macro.tex @@ -66,6 +66,7 @@ tab.~\thechapter.\theusercount} % \newenvironment{prototype}[2] {% defining what is done by \begin + \par \center \footnotesize \begin{minipage}[c]{14cm} @@ -97,6 +98,7 @@ tab.~\thechapter.\theusercount} \newcommand{\funcdecl}[1]{\item\texttt{#1}\par} \newenvironment{functions} {% defining what is done by \begin + \par \footnotesize \center \begin{minipage}[c]{14cm} -- 2.30.2