Piccole correzioni e uniformati i font dei link esterni.
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 20 Mar 2005 22:45:12 +0000 (22:45 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 20 Mar 2005 22:45:12 +0000 (22:45 +0000)
fileintro.tex
ipc.tex
prochand.tex

index eaea00299a2791c92f303b953894e8af1972b059..78c2a714e4f652c00dfc270aec4234535ee9474a 100644 (file)
@@ -87,38 +87,38 @@ particolare che il kernel riconosce come tale. Il suo scopo 
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
-un'organizzazione ad albero inserendo directory in altre directory.
+un'organizzazione ad albero inserendo nomi di directory in altre directory.
 
 Un file può essere indicato rispetto alla directory corrente semplicemente
 specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
 
 Un file può essere indicato rispetto alla directory corrente semplicemente
 specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
-  contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
-    components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
-contenuto.  All'interno dello stesso albero si potranno poi inserire anche
-tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
-come le fifo, i link, i socket\index{socket} e gli stessi file di dispositivo
-\index{file!di~dispositivo} (questi
-ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
+contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
+components}), noi li chiameremo più semplicemente \textsl{nomi} o
+\textsl{voci}.}  da essa contenuto.  All'interno dello stesso albero si
+potranno poi inserire anche tutti gli altri oggetti visti attraverso
+l'interfaccia che manipola i file come le fifo, i link, i socket\index{socket}
+e gli stessi file di dispositivo \index{file!di~dispositivo} (questi ultimi,
+per convenzione, sono inseriti nella directory \file{/dev}).
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
-risoluzione del nome (\textit{file name resolution} o \textit{pathname
-  resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
+risoluzione del nome (\textit{filename resolution} o \textit{pathname
+resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
-precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
-  costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
+precedente usando \texttt{/} come separatore\footnote{nel caso di nome vuoto,
+il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
 perché il procedimento funzioni, occorre che i nomi indicati come directory
 esistano e siano effettivamente directory, inoltre i permessi (si veda
 sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero
 \textit{pathname}.
 
 perché il procedimento funzioni, occorre che i nomi indicati come directory
 esistano e siano effettivamente directory, inoltre i permessi (si veda
 sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero
 \textit{pathname}.
 
-Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
-radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
-sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
-directory radice dell'albero dei file: in questo caso si parla di un
-\textsl{pathname assoluto}\index{\textit{pathname}!assoluto}. Altrimenti la
-ricerca parte dalla directory corrente (su cui torneremo in
+Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla
+directory radice del processo; questa, a meno di un \func{chroot} (su cui
+torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed
+equivale alla directory radice dell'albero dei file: in questo caso si parla
+di un \textsl{pathname assoluto}\index{\textit{pathname}!assoluto}. Altrimenti
+la ricerca parte dalla directory corrente (su cui torneremo in
 sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
 sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
-  relativo}\index{\textit{pathname}!relativo}.
+relativo}\index{\textit{pathname}!relativo}.
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 in ogni directory: il primo fa riferimento alla directory corrente e il
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 in ogni directory: il primo fa riferimento alla directory corrente e il
@@ -297,53 +297,6 @@ infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed 
 portabilità più limitata.
 
 
 portabilità più limitata.
 
 
-% \subsection{Caratteristiche specifiche dei file in Unix}
-% \label{sec:fileint_unix_spec}
-
-% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-% specifiche di un sistema unix-like che devono essere tenute in conto
-% nell'accesso ai file. È infatti normale che più processi o programmi possano
-% accedere contemporaneamente allo stesso file e devono poter eseguire le loro
-% operazioni indipendentemente da quello che fanno gli altri processi.
-
-% Per questo motivo le strutture usate per all'accesso ai file sono relative al
-% processo che effettua l'accesso.  All'apertura di ogni file infatti viene
-% creata all'interno del processo una apposita struttura in cui sono memorizzati
-% tutti gli attributi del medesimo, che viene utilizzata per tutte le
-% operazioni. Questa è una struttura che resta locale al processo stesso; in
-% questo modo processi diversi possono usare le proprie strutture locali per
-% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
-% indipendente.
-
-% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
-% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
-% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
-% successiva. Essa è rappresentata da un numero intero che indica il numero di
-% byte dall'inizio del file, che viene (a meno che non si apra il file in
-% append) inizializzato a zero all'apertura del medesimo.
-
-% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
-% ogni processo avrà la sua posizione corrente nel file, che non sarà
-% influenzata da quello che altri processi possono fare. Anzi, aprire un file
-% significa appunto creare ed inizializzare una tale struttura, per cui se si
-% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
-% due file descriptor o due stream che avranno ancora una posizione corrente nel
-% file assolutamente indipendente.
-
-% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
-% accesso è un riferimento all'inode del file, pertanto anche se il file viene
-% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
-% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-% in dettaglio in sez.~\ref{sec:file_link}) aprire un file provvisorio per
-% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
-% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
-% saranno disponibili per tutto il tempo in cui il processo è attivo.
-
-% Ritorneremo su questo più avanti in sez.~\ref{sec:file_fd}, quando tratteremo
-% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
-% realizzato.
-
 
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
 
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
@@ -550,7 +503,7 @@ unix-like) organizza i dati che tiene su disco attraverso l'uso di un
 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
 quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
 quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
-proprie.  Per questo, per il momento non entreremo nei dettagli di un
+proprie.  Per questo per il momento non entreremo nei dettagli di un
 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
@@ -693,7 +646,7 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
 La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
 filesystem è composto da un insieme di blocchi, la struttura generale è quella
 riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
 La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
 filesystem è composto da un insieme di blocchi, la struttura generale è quella
 riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
-in gruppi di blocchi.\footnote{non si confonda la questa definizione con
+in gruppi di blocchi.\footnote{non si confonda questa definizione con
   quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
   riferimento alla struttura usata in user space per riportare i dati
   contenuti in una directory generica, questa fa riferimento alla struttura
   quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
   riferimento alla struttura usata in user space per riportare i dati
   contenuti in una directory generica, questa fa riferimento alla struttura
diff --git a/ipc.tex b/ipc.tex
index 503792b01d86cff85c8b45e1b8241972bd2059bf..bd5b25d985d6711aaf0ce043ffb5587ab0c6c312 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -3313,9 +3313,9 @@ processo che esegue la creazione).
 Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
 però una implementazione sperimentale di Michal Wronski e Krzysztof
 Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere
 Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
 però una implementazione sperimentale di Michal Wronski e Krzysztof
 Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere
-  trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
-  {http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}, questi sono stati
-  inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}.  In
+trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
+{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono
+stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}.  In
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
 più comodi, e che in casi più complessi la comunicazione può essere gestita
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
 più comodi, e che in casi più complessi la comunicazione può essere gestita
index a663b9f489550b48cafaf4839c7cfcc83ea84d58..ab71e822402b19a282731d6c70665f92848660b8 100644 (file)
@@ -400,8 +400,8 @@ degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
 distribuito insieme agli altri sorgenti degli esempi su
 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
 distribuito insieme agli altri sorgenti degli esempi su
-\href{http://gapil.firenze.linux.it/gapil_source.tgz}
-{\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
+\href{http://gapil.truelite.it/gapil_source.tgz}
+{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli