Rivisto parte dell'introduzione ai file, aggiunte le variabili locali per
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 28 Dec 2001 23:30:33 +0000 (23:30 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 28 Dec 2001 23:30:33 +0000 (23:30 +0000)
emacs ad uso di reftex e auctex

22 files changed:
Makefile
elemtcp.tex
errors.tex
fdl.tex
fileadv.tex
filedir.tex
fileintro.tex
filestd.tex
fileunix.tex
intro.tex
ipc.tex
ipprot.tex
network.tex
pref.tex
process.tex
prochand.tex
session.tex
signal.tex
simpltcp.tex
socket.tex
system.tex
tcpprot.tex

index af51df5..21ca364 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -16,5 +16,6 @@ install:
        scp -r gapil*  piccardi@firenze.linux.it:public_html
 
 clean: 
-       rm -f *.dvi *.log *.ps *.html *.aux *.toc *.rel *~
+       rm -f *.dvi *.log *.ps *.html *.aux *.toc *.rel *.ilg *.rip *.ind \
+       *.pdf  *.out *.idx *~
 
index 46bffaf..ce44d1d 100644 (file)
@@ -1266,3 +1266,8 @@ come prima dello standard perch
 questa assunzione.
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index b0e75dd..239d3ba 100644 (file)
@@ -383,3 +383,8 @@ call (TODO verificare i dettagli, eventualmente cassare).
 \end{description}
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
diff --git a/fdl.tex b/fdl.tex
index 16231dc..ef4a538 100644 (file)
--- a/fdl.tex
+++ b/fdl.tex
@@ -336,3 +336,8 @@ Free Software Foundation.  If the Document does not specify a version
 number of this License, you may choose any version ever published (not
 as a draft) by the Free Software Foundation.
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index ffd7f2a..b930909 100644 (file)
@@ -36,3 +36,8 @@
 \label{sec:file_memory_map}
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 5d1c21e..6bbdb18 100644 (file)
@@ -1895,12 +1895,18 @@ programma ad una sezione limitata del filesystem, per cui ne parleremo in
 questa sezione.
 
 Come accennato in \secref{sec:proc_fork} ogni processo oltre ad una directory
-di lavoro corrente, ha anche una directory radice, cioè una directory che per
-il processo costituisce la radice dell'albero del filesystem. Questa viene
-eredidata dal padre per ogni processo figlio, (come si può vedere da
-\figref{fig:proc_task_struct} è tenuta nella struttura \type{fs\_struct}
-insieme alla directory di lavoro corrente e alla \var{umask}) e quindi di
-norma coincide con la \file{/} del sistema.
+di lavoro corrente, ha anche una directory radice, che è la directory che per
+il processo costituisce la radice dell'albero dei file e rispetto alla quale
+vengono risolti i pathname assoluti (si ricordi quanto detto in
+\secref{sec:file_file_struct})
+
+
+La radice viene eredidata dal padre per ogni processo figlio; come si può
+vedere da \figref{fig:proc_task_struct} è tenuta nella struttura
+\type{fs\_struct} insieme alla directory di lavoro corrente e alla
+\var{umask}, e quindi di norma coincide con la \file{/} del sistema.
+
+
 
 In certe situazioni però per motivi di sicurezza non si vuole che un processo
 possa accedere a tutto il filesystem; per questo si può cambiare la directory
@@ -1930,3 +1936,8 @@ ftp che dovrebbe limitarsi
 Il sistema però consente di cambiare questa directory con la funzione
 \func{chroot}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 3715f89..c69acba 100644 (file)
@@ -1,10 +1,11 @@
 \chapter{L'architettura dei file}
 \label{cha:file_intro}
 
-Uno dei concetti fondamentali della architettura di unix è il cosiddetto
-\textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi
-di input/output del computer viene effettuato attraverso un'interfaccia
-astratta che tratta le periferiche allo stesso modo degli usuali file di dati.
+Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
+cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
+dispositivi di input/output del computer viene effettuato attraverso
+un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
+file di dati.
 
 Questo significa che si può accedere a qualunque periferica del computer,
 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
@@ -13,53 +14,45 @@ speciali agendo sui quali i programmi possono leggere, scrivere e compiere
 operazioni direttamente sulle periferiche, usando le stesse funzioni che si
 usano per i normali file di dati.
 
-In questo capitolo forniremo un'introduzione all'architettura della gestione
-dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che
-nelle particolarità che ha la specifica implementazione usata da Linux. Al
-contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
-varie caratteristiche distintive.
+In questo capitolo forniremo una panoramica dell'architettura dei file, sia
+nelle sue caratteristiche generali, comuni a tutti gli Unix, che nelle
+particolarità che ha la specifica implementazione usata da Linux.
 
 
 
-\section{L'organizzazione di file e directory}
-\label{sec:file_organization}
+\section{L'architettura dell'accesso ai file}
+\label{sec:file_access_arch}
 
-Il primo passo nella trattazione dell'architettura della gestione dei file in
-un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
-di quale è la struttura che hanno all'interno del sistema.
+Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
+le opportune interfacce che consentano di leggerne il contenuto; il sistema
+cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
+l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
+fatto strutturando l'informazione sul disco attraverso quello che si chiama un
+\textit{filesystem}, essa poi viene resa disponibile attraverso quello che
+viene chiamato il \textsl{montaggio} del filesystem.
+% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
 
+In questa sezione faremo una panormamica generica su come il sistema presenta
+i file ai processi, trattando l'organizzazione di file e directory, i tipi di
+file ed introducendo le interfacce disponibili, che saranno approfondite nei
+capitoli seguenti. 
 
-\subsection{La struttura di file e directory}
+
+\subsection{L'organizzazione di file e directory}
 \label{sec:file_file_struct}
 
-Partiamo allora da come viene strutturata nel sistema la disposizione dei
-file: per potervi accedere il kernel usa una apposita interfaccia che permetta
-di accedere all'informazione tenuta sullo spazio grezzo disponibile sui
-dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
-  brevità questo nome al posto della più prolissa traduzione italiana sistema
-  di file}, che descriveremo in dettaglio in \secref{sec:file_vfs}.
-
-Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
-memorizzati all'interno del disco stesso, strutturando l'informazione in file
-e directory.  Per poter accedere ai file contenuti in un disco occorrerà
-perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco
-(o la partizione del disco).
-
-%In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
-%informazioni riservate che tengono conto degli inodes allocati, di quelli
-%liberi, e delle posizioni fisiche su disco dei dati contenuti nei file, per
-
-In unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
-file vengono tenuti all'interno di un unico albero la cui radice (la directory
-di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato
-dall'utente usando quello che viene chiamato \textit{pathname}, cioè il
-percorso che si deve fare per accedere al file.
+In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
+file vengono tenuti all'interno di un unico albero la cui radice (quella che
+viene chiamata \textit{root directory}) viene montata all'avvio. Pertanto
+un file viene identificato dall'utente usando quello che viene chiamato
+\textit{pathname}, cioè il percorso che si deve fare per accedere al file.
 
 Dopo la fase di inizializzazione il kernel riceve dal boot loader
 l'indicazione di quale dispositivo contiene il filesystem da usare come punto
 di partenza e questo viene montato come radice dell'albero (cioè nella
-directory \file{/}); tutti gli ulteriori dischi devono poi essere inseriti
-nell'albero utilizzando opportune subdirectory.
+directory \file{/}); tutti gli ulteriori filesystem che possono essere su
+altri dispositivi devono poi essere inseriti nell'albero utilizzando opportune
+subdirectory.
 
 Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
 alcune strutture interne del kernel) sono generati automaticamente dal kernel
@@ -71,15 +64,15 @@ link, i socket e gli stessi i file di dispositivo (questi ultimi, per
 convenzione, sono inseriti nella directory \file{/dev}).
 
 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
-medesimi nell'albero descritto in precedenza; una directory comunque, come già
-specificato in \secref{sec:file_vfs}, è solo un particolare tipo di file
-che contiene le informazioni che associano un nome al contenuto.
+medesimi nell'albero descritto in precedenza; una directory comunque, come
+vedremo in \secref{sec:file_vfs_work}, è solo un particolare tipo di file che
+contiene le informazioni che associano un nome al contenuto.
 
 % Per questo, anche se è usuale parlare di ``file in una directory'' in realtà
 % una directory contiene solo delle etichette per fare riferimento ai file
 % stessi.
 
-I manuale delle glibc chiama i nomi contenuti nelle directory
+I 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}. Un file può essere indicato
 rispetto alla directory corrente semplicemente specificando il nome da essa
@@ -89,22 +82,22 @@ directory; l'albero viene appunto creato inserendo directory in altre
 directory.
 
 Il nome completo di file generico è composto da una serie di nomi separati da
-una \file{/} (in Linux più \file{/} consecutive sono considerate
-equivalenti ad una sola). Il nome completo di un file viene usualmente
-chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo
-nome (poiché genererebbe confusione, dato che con \textit{path} si indica
-anche un insieme di directory su cui effettuare una ricerca, come quello in
-cui si cercano i comandi); non seguiremo questa scelta dato che l'uso della
-parola \textit{pathname} è ormai così comune che è senz'altro più chiaro
-dell'alternativa proposta.
-
-Il processo con cui si associa ad un pathname uno specifico file è chiamato
-risoluzione del nome (\textit{file name resolution} o \textit{pathname
-  resolution}).  La risoluzione viene fatta esaminando il pathname da destra a
-sinistra e localizzando ogni nome nella directory indicata dal nome
-precedente: ovviamente perché il procedimento funzioni occorre che i nomi
-indicati come directory esistano e siano effettivamente directory, inoltre i
-permessi devono consentire l'accesso.
+una \file{/} (in Linux più \file{/} consecutive sono considerate equivalenti
+ad una sola). Il nome completo di un file viene usualmente chiamato
+\textit{pathname}, e anche se il manuale della \acr{glibc} depreca questa
+nomenclatura\footnote{poiché genererebbe confusione, dato che con
+  \textit{path} si indica anche un insieme di directory su cui effettuare una
+  ricerca, come quello in cui si cercano i comandi}; non seguiremo questa
+scelta dato che l'uso della parola \textit{pathname} è ormai così comune che è
+senz'altro più chiaro dell'alternativa proposta.
+
+Il procedimento con cui si associa ad un pathname uno specifico file è
+chiamato risoluzione del nome (\textit{file name resolution} o
+\textit{pathname resolution}).  La risoluzione viene fatta esaminando il
+pathname da destra a sinistra e localizzando ogni nome nella directory
+indicata dal nome precedente: ovviamente perché il procedimento funzioni
+occorre che i nomi indicati come directory esistano e siano effettivamente
+directory, inoltre i permessi devono consentire l'accesso.
 
 Se il pathname comincia per \file{/} la ricerca parte dalla directory radice
 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
@@ -127,7 +120,7 @@ sia la directory radice allora il riferimento 
 
 Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
-\secref{sec:file_vfs}) e sono presenti in tutti i filesystem unix-like
+\secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual
 File System è riportato in \ntab.
 
@@ -146,7 +139,8 @@ dati) in base al loro contenuto, o tipo di accesso.
       \textit{regular file} & \textsl{file normale} &
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
-      un file che contiene una lista di nomi associati a degli inodes \\
+      un file che contiene una lista di nomi associati a degli \textit{inodes}
+      (vedi \secref{sec:file_vfs}).  \\
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &
@@ -298,7 +292,7 @@ questa 
 
 
 \section{L'architettura della gestione dei file}
-\label{sec:file_architecture}
+\label{sec:file_arch_func}
 
 Per capire fino in fondo le proprietà di file e directory in un sistema
 unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
@@ -352,9 +346,10 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.
 \end{figure}
 
 Il VFS definisce un insieme di funzioni che tutti i filesystem devono
-implementare. L'interfaccia comprende tutte le funzioni che riguardano i
-file; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode
-e file, corrispondenti a tre apposite strutture definite nel kernel.
+implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
+le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
+\textit{inode} e \textit{file}, corrispondenti a tre apposite strutture
+definite nel kernel.
 
 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
 filesystem supportato: quando si vuole inserire il supporto di un nuovo
@@ -363,7 +358,6 @@ filesystem tutto quello che occorre 
 (\var{file\_system\_type}) che contiene i dettagli per il riferimento
 all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
 
-
 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
 (o qualunque altro \textit{block device} che può contenere un filesystem), il
 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
@@ -489,7 +483,7 @@ diversi filesystem (come quelli usati da Windows o MacOs) 
 
 Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
 in generale) organizza i dati che tiene su disco attraverso l'uso di un
-filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
+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 non entreremo nei dettagli di un filesystem specifico, ma
@@ -656,3 +650,8 @@ in questo modo 
 
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 0070226..8a0f2c7 100644 (file)
@@ -1527,3 +1527,8 @@ della funzione \func{\_\_fsetlocking}, il cui prototipo 
   di blocco dello stream.
 \end{basedescript}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index c3938d9..f692aeb 100644 (file)
@@ -1067,3 +1067,8 @@ con le funzioni esaminate finora. Per questo motivo non 
 che darne una descrizione generica; torneremo ad esaminarla in seguito, quando
 si tratterà di applicarla ad alcune problematiche specifiche.
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index d6e2a45..5e9ade0 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -510,3 +510,8 @@ includere i vari header file.
 Da fare (o cassare, a seconda del tempo e della voglia).
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
diff --git a/ipc.tex b/ipc.tex
index f3de1c8..f86a851 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -53,3 +53,8 @@ sistema \textit{SystemV IPC}.
 \subsection{Memoria condivisa}
 \label{sec:ipc_shar_mem}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index c366d89..4618a30 100644 (file)
@@ -1346,3 +1346,8 @@ fino al vettore di inizializzazione, il resto 
 \section{Autoconfigurazione}
 \label{sec:IP_ipv6_autoconf}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 8240d45..12d5c88 100644 (file)
@@ -600,3 +600,8 @@ all'altro capo la dimensione massima del segmento di dati.
 
 %\subsection{Il passaggio dei dati in UDP}
 %\label{sec:net_udp_pass}
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index c68ee81..0c80fe8 100644 (file)
--- a/pref.tex
+++ b/pref.tex
@@ -71,3 +71,8 @@ Il testo sar
 
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 24935da..a574eb3 100644 (file)
@@ -1425,3 +1425,8 @@ suo prototipo 
   \bodydesc{La funzione non ritorna.}
 \end{functions}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 579ab48..7eb71cc 100644 (file)
@@ -1954,3 +1954,8 @@ varie funzioni di libreria, che sono identificate aggiungendo il suffisso
 \code{\_r} al nome della versione normale.
 
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 634a5f7..d852e84 100644 (file)
@@ -39,3 +39,8 @@
 \subsection{La shell e i programmi}
 \label{sec:sess_shell}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index e67985b..d0f68b3 100644 (file)
@@ -760,3 +760,8 @@ intercettati).
 \subsection{La funzione \func{sigpending}}
 \label{sec:sig_sigpending}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index f7260cf..c119df0 100644 (file)
@@ -411,3 +411,8 @@ processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando il
 segnale, per questo installeremo un manipolatore usando la funzione
 \func{Signal} (trattata in dettaglio in \secref{sec:sig_signal}).
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index a563c35..36f1f3e 100644 (file)
@@ -1069,3 +1069,8 @@ scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
 attiva e il terminale da cui lo si è lanciato è stato sconnesso),
 occorrerebbero delle opportune modifiche.
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index e8bd370..fca6545 100644 (file)
@@ -290,3 +290,8 @@ o la macro (\texttt{\small 15--17}) associate a quel codice.
 \section{La gestione di utenti e gruppi}
 \label{sec:sys_user_group}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: 
index 48d2dd8..1625b62 100644 (file)
@@ -1,3 +1,8 @@
 \chapter{Il protocollo TCP}
 \label{cha:tcp_protocol}
 
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: