From 00c2fb226b0ad73a87d5d86a25a149b61c5f9a53 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 23 Oct 2001 21:55:13 +0000 Subject: [PATCH] Correzioni varie. --- filedir.tex | 66 ++++++++++++++++++++++----------------------- fileintro.tex | 75 ++++++++++++++++++++++++++------------------------- 2 files changed, 71 insertions(+), 70 deletions(-) diff --git a/filedir.tex b/filedir.tex index 4585831..4ae79e6 100644 --- a/filedir.tex +++ b/filedir.tex @@ -95,8 +95,8 @@ campo \var{st\_mode} sono riportate in \ntab. Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda che si riferiscano a file, link simbolici o directory, qui ci -limiteremo ad un riassunto delle regole generali, entrando nei -dettagli più avanti. +limiteremo ad un riassunto delle regole generali, entrando nei dettagli più +avanti. La prima regola è che per poter accedere ad un file attraverso il suo pathname occorre il permesso di esecuzione in ciascuna delle directory che compongono @@ -607,13 +607,13 @@ generali relative alle caratteristiche di ciascun file, a partire dalle informazioni relative al controllo di accesso, sono mantenute nell'inode. Vedremo in questa sezione come sia possibile leggere tutte queste informazioni -usando la funzione \texttt{stat}, che permette l'accesso a tutti i dati +usando la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare tutte queste informazioni (eccetto quelle che riguardano la gestione del -controllo di accesso, già trattate in in \secref{sec:file_access_control}). +controllo di accesso, trattate in in \secref{sec:file_access_control}). -\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}} +\subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}} \label{sec:file_stat} La lettura delle informazioni relative ai file è fatta attraverso la famiglia @@ -643,7 +643,7 @@ funzioni sono i seguenti: \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}. \end{functions} -La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in +La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in generale dipende dall'implementazione, la versione usata da Linux è mostrata in \nfig, così come riportata dalla man page (in realtà la definizione effettivamente usata nel kernel dipende dall'architettura e ha altri campi @@ -679,7 +679,7 @@ struct stat { Si noti come i vari membri della struttura siano specificati come tipi nativi del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in -\texttt{sys/types.h}). +\file{sys/types.h}). \subsection{I tipi di file} @@ -687,14 +687,14 @@ del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e alle directory esistono vari altri oggetti che possono stare su un filesystem; -il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode} +il tipo di file è ritornato dalla \func{stat} nel campo \var{st\_mode} (che è quello che contiene anche le informazioni relative ai permessi). Dato che il valore numerico può variare a seconda delle implementazioni, lo standard POSIX definisce un insieme di macro per verificare il tipo di files, queste vengono usate anche da Linux che supporta pure le estensioni per link -simbolici e socket definite da BSD, l'elenco completo di tutte le macro -definite in GNU/Linux è riportato in \ntab. +simbolici e socket definite da BSD, l'elenco completo di tutte le macro è +riportato in \ntab. \begin{table}[htb] \centering \footnotesize @@ -982,7 +982,7 @@ creazione del file, usato da molti altri sistemi operativi, che in unix non esiste. -\subsection{La funzione \texttt{utime}} +\subsection{La funzione \func{utime}} \label{sec:file_utime} I tempi di ultimo accesso e modifica possono essere cambiati usando la @@ -998,8 +998,8 @@ questa La funzione restituisce zero in caso di successo e -1 in caso di errore, nel qual caso \var{errno} è settata opportunamente. \begin{errlist} -\item \texttt{EACCESS} non si ha il permesso di scrittura sul file. -\item \texttt{ENOENT} \var{filename} non esiste. +\item \macro{EACCESS} non si ha il permesso di scrittura sul file. +\item \macro{ENOENT} \var{filename} non esiste. \end{errlist} \end{prototype} @@ -1030,14 +1030,14 @@ molto pi \section{La manipolazione di file e directory} -Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like -i file hanno delle caratteristiche specifiche dipendenti dall'architettura del +Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like i +file hanno delle caratteristiche specifiche dipendenti dall'architettura del sistema, esamineremo qui allora le funzioni usate per la creazione di link -simbolici e diretti e per la gestione delle directory, approfondendo quanto +simbolici e diretti e per la gestione delle directory, approfondendo quanto già accennato in precedenza. -\subsection{Le funzioni \texttt{link} e \texttt{unlink}} +\subsection{Le funzioni \func{link} e \func{unlink}} \label{sec:file_link} Una delle caratteristiche comuni a vari sistemi operativi è quella di poter @@ -1055,27 +1055,27 @@ stesso file pu altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una particolare preferenza rispetto agli altri. -Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si +Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si suole chiamare questo tipo di associazione un collegamento diretto (o \textit{hard link}). Il prototipo della funzione e le sue caratteristiche principali, come risultano dalla man page, sono le seguenti: \begin{prototype}{unistd.h} {int link(const char * oldpath, const char * newpath)} - Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath} - dandogli nome \texttt{newpath}. + Crea un nuovo collegamento diretto al file indicato da \var{oldpath} + dandogli nome \var{newpath}. La funzione restituisce zero in caso di successo e -1 in caso di errore. La - variabile \texttt{errno} viene settata opportunamente, i principali codici + variabile \var{errno} viene settata opportunamente, i principali codici di errore sono: \begin{errlist} - \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo + \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo stesso filesystem. - \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e - \texttt{newpath} non supporta i link diretti o è una directory. - \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di + \item \macro{EPERM} il filesystem che contiene \var{oldpath} e + \macro{newpath} non supporta i link diretti o è una directory. + \item \macro{EEXIST} un file (o una directory) con quel nome esiste di già. - \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il - numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi + \item \macro{EMLINK} ci sono troppi link al file \vat{oldpath} (il + numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi \secref{sec:xxx_limits}). \end{errlist} @@ -1090,20 +1090,20 @@ diverse directory. Per quanto dicevamo in \secref{sec:file_filesystem} la creazione del collegamento diretto è possibile solo se entrambi i pathname sono nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è -il caso ad esempio del filesystem \texttt{vfat} di Windows). +il caso ad esempio del filesystem \acr{vfat} di Windows). La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, in alcuni filesystem solo l'amministratore è in grado di creare un collegamento diretto ad un'altra directory, questo lo si fa perché in questo caso è possibile creare dei circoli nel filesystem (vedi -\secref{sec:file_symlink}) che molti programmi non sono in grado di -gestire e la cui rimozione diventa estremamente complicata (in genere occorre -far girare il programma \texttt{fsck} per riparare il filesystem); data la sua +\secref{sec:file_symlink}) che molti programmi non sono in grado di gestire e +la cui rimozione diventerebbe estremamente complicata (in genere occorre far +girare il programma \cmd{fsck} per riparare il filesystem); data la sua pericolosità in generale nei filesystem usati in Linux questa caratteristica è -stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}. +stata disabilitata, e la funzione restituisce l'errore \macro{EPERM}. La rimozione di un file (o più precisamente della voce che lo referenzia) si -effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: +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 diff --git a/fileintro.tex b/fileintro.tex index 479ff86..330f812 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -391,32 +391,34 @@ file gi \label{sec:file_vfs_work} La funzione più fondamentale implementata dal VFS è la system call -\texttt{open} che permette di aprire un file. Dato un pathname viene eseguita +\func{open} che permette di aprire un file. Dato un pathname viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve \textit{dcache}), una tabella di hash che contiene tutte le \textit{directory entry} (in breve \textit{dentry}) che permette di associare in maniera rapida ed efficiente il pathname a una specifica dentry. -Una singola dentry contiene in genere il puntatore ad un \textit{inode}; -quest'ultimo è la struttura base che sta sul disco e che identifica un singolo -oggetto del VFS sia esso un file ordinario, una directory, una FIFO, un file -di dispositivo, o una qualsiasi altra cosa che possa essere rappresentata dal -VFS (sui tipi di ``file'' possibili torneremo in seguito). A ciascuno di essi -è associata pure una struttura che sta in memoria, e che oltre alle -informazioni sullo specifico file contiene pure il riferimento alle funzioni -(i \textsl{metodi}) da usare per poterlo manipolare. - -Le dentry ``vivono'' in memoria e non vengono mai salvate su disco, vengono -usate per motivi di velocità, gli inode invece stanno su disco e vengono -copiati in memoria quando serve, ed ogni cambiamento viene copiato -all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS -ed è ad essi che puntano le singole dentry. - -La dcache costituisce perciò una sorta di vista completa di tutto l'albero dei -file, ovviamente per non riempire tutta la memoria questa vista è parziale -(la dcache cioè contiene solo le dentry per i file per i quali è stato -richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve -creare una nuova dentry e caricare l'inode corrispondente in memoria. +Una singola \textit{dentry} contiene in genere il puntatore ad un +\textit{inode}; quest'ultimo è la struttura base che sta sul disco e che +identifica un singolo oggetto del VFS sia esso un file ordinario, una +directory, un link simbolico, una FIFO, un file di dispositivo, o una +qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di +``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure +una struttura che sta in memoria, e che oltre alle informazioni sullo +specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi}) +da usare per poterlo manipolare. + +Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco, +vengono usate per motivi di velocità, gli inode invece stanno su disco e +vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato +all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed +è ad essi che puntano le singole \textit{dentry}. + +La \textit{dcache} costituisce perciò una sorta di vista completa di tutto +l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è +parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file +per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo +pathname il VFS deve creare una nuova \textit{dentry} e caricare l'inode +corrispondente in memoria. Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode della directory che contiene il file; questo viene installato nelle relative @@ -430,12 +432,12 @@ dell'inode e passarli in user space. L'apertura di un file richiede comunque un'altra operazione, l'allocazione di una struttura di tipo \var{file} in cui viene inserito un puntatore alla -dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che -implementano le operazioni disponibili sul file. In questo modo i processi in -user space possono accedere alle operazioni attraverso detti metodi, che -saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo -torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle operazioni -previste dal kernel è riportato in \ntab. +\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai +metodi che implementano le operazioni disponibili sul file. In questo modo i +processi in user space possono accedere alle operazioni attraverso detti +metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto +(su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle +operazioni previste dal kernel è riportato in \ntab. \begin{table}[htb] \centering @@ -469,12 +471,12 @@ previste dal kernel In questo modo per ciascun file diventano utilizzabili una serie di operazioni (non è dette che tutte siano disponibili), che costituiscono l'interfaccia astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad -utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo +utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo di file in questione. Così sarà possibile scrivere sulla porta seriale come su un file di dati normale; ovviamente certe operazioni (nel caso della seriale ad esempio la -\textit{seek}) non saranno disponibili, però con questo sistema l'utilizzo di +\func{seek}) non saranno disponibili, però con questo sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è immediato e (relativamente) trasparente per l'utente ed il programmatore. @@ -494,9 +496,9 @@ comuni di un qualunque filesystem standard unix. Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni partizione può contenere un filesystem; la strutturazione tipica dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento -alla struttura del filesystem ext2, che prevede una separazione dei dati in -\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di -ext2 torneremo in \secref{sec:file_ext2}). È comunque caratteristica +alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati +in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche +di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica comune di tutti i filesystem unix, indipendentemente da come poi viene strutturata nei dettagli questa informazione, prevedere una divisione fra la lista degli inodes e lo spazio a disposizione per i dati e le directory. @@ -586,7 +588,7 @@ adesso sar \label{sec:file_ext2} Il filesystem standard usato da Linux è il cosiddetto \textit{second extended - filesystem}, identificato dalla sigla \textsl{ext2}. Esso supporta tutte le + filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le caratteristiche di un filesystem standard unix, è in grado di gestire filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb. @@ -604,9 +606,9 @@ seguenti: con lo stesso identificatore di gruppo della directory che li contiene. La semantica SYSV comporta che i file vengono creati con l'identificatore del gruppo primario del processo, eccetto il caso in cui la directory ha il bit - di sgid settato (per una descrizione dettagliata del significato di questi - termini si veda \secref{sec:file_access_control}), nel qual caso file e - sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}. + di \acr{sgid} settato (per una descrizione dettagliata del significato di + questi termini si veda \secref{sec:file_access_control}), nel qual caso file + e sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione, a seconda delle sue esigenze (blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco). @@ -631,7 +633,6 @@ filesystem (superblock e descrittore del filesystem sono quindi ridondati) per una maggiore affidabilità e possibilità di recupero in caso di corruzione del superblock principale. - \begin{figure}[htb] \centering \includegraphics[width=9cm]{img/dir_struct.eps} -- 2.30.2