From: Simone Piccardi Date: Mon, 18 Mar 2002 17:20:08 +0000 (+0000) Subject: Correzioni secondo i suggerimenti di Alessio X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=117a739ee3013118cfa864628d4b41288a9d1dc9;p=gapil.git Correzioni secondo i suggerimenti di Alessio --- diff --git a/ChangeLog b/ChangeLog index 26d9895..ae3d058 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2002-03-18 Simone Piccardi + + * fileintro.tex: Correzioni varie su suggerimenti di A. Frusciante. + 2002-03-02 Simone Piccardi * prochand.tex: Aggiunte info sui limiti superiore ed inferiore diff --git a/fileintro.tex b/fileintro.tex index 15e2fd8..2dce07e 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -47,21 +47,24 @@ 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. Un file viene identificato dall'utente usando quello che viene chiamato -\textit{pathname}\footnote{anche se il manuale della \acr{glibc} depreca - questa nomenclatura, 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 - mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè -il percorso che si deve fare per accedere al file a partire dalla \textit{root - directory}, che è composto da una serie di nomi separati da una \file{/}. - -All'avvio del sistema, comletata 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 filesystem che possono -essere su altri dispositivi dovranno poi essere inseriti nell'albero -montandoli su opportune directory del filesystem montato come radice. +\textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa + nomenclatura, che genererebbe confusione poiché \textit{path} indica anche + un insieme di directory su cui effettuare una ricerca (come quello in cui si + cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e + di componente per il nome del file all'interno della directory. Non + seguiremo questa scelta dato che l'uso della parola \textit{pathname} è + ormai così comune che mantenerne l'uso è senz'altro più chiaro + dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere +al file a partire dalla \textit{root directory}, che è composto da una serie +di nomi separati da una \file{/}. + +All'avvio del sistema, completata 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 filesystem +che possono essere su altri dispositivi dovranno poi essere inseriti +nell'albero montandoli su opportune directory del filesystem montato come +radice. Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad alcune strutture interne del kernel) sono generati automaticamente dal kernel @@ -141,9 +144,9 @@ dati) in base al loro contenuto, o tipo di accesso. \textit{symbolic link} & \textsl{collegamento simbolico} & un file che contiene un riferimento ad un altro file/directory \\ \textit{char device} & \textsl{dispositivo a caratteri} & - un file che identifica una periferica ad accesso sequenziale \\ + un file che identifica una periferica ad accesso a caratteri \\ \textit{block device} & \textsl{dispositivo a blocchi} & - un file che identifica una periferica ad accesso diretto \\ + un file che identifica una periferica ad accesso a blocchi \\ \textit{fifo} & \textsl{``coda''} & un file speciale che identifica una linea di comunicazione software (unidirezionale) \\ @@ -162,9 +165,10 @@ un flusso continuo di byte. Non esiste cio dal sistema file di diverso contenuto o formato (come nel caso di quella fra file di testo e binari che c'è in Windows) né c'è una strutturazione a record per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i - kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi - (il \textit{raw access}) attraverso dei device file appositi, che però non - ha nulla a che fare con questo.} + kernel della serie 2.4 è disponibile, attraverso dei device file appositi, + una forma di accesso diretto ai dischi (il \textit{raw access}) che però non + ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza + passare attraverso un filesystem.} Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è codificata in maniera diversa da Windows o Mac, in particolare il fine riga è @@ -192,7 +196,7 @@ accedere al loro contenuto. La prima è l'interfaccia standard di Unix, quella che il manuale delle \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file - descriptor}). È un'interfaccia specifica dei sistemi unix-like e provvede + descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce un accesso non bufferizzato; la tratteremo in dettaglio in \capref{cha:file_unix_interface}. @@ -205,7 +209,7 @@ rappresentati da numeri interi (cio L'interfaccia è definita nell'header \file{unistd.h}. La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli -\textit{stream}\index{stream}. Essa provvede funzioni più evolute e un accesso +\textit{stream}\index{stream}. Essa fornisce funzioni più evolute e un accesso bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la tratteremo in dettaglio nel \capref{cha:files_std_interface}. @@ -216,18 +220,19 @@ librerie del C; si accede ad essi sempre in maniera indiretta utilizzando il tipo \type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}. Entrambe le interfacce possono essere usate per l'accesso ai file come agli -altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio -a tempo opportuno), ma per poter accedere alle operazioni di controllo su un -qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix -con i \textit{file descriptor}. Allo stesso modo devono essere usati i -\textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come -il polling o il non-bloccante (vedi \capref{cha:file_advanced}). +altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio +a tempo opportuno), ma per poter accedere alle operazioni di controllo +(descritte in \ref{sec:file_fcntl} e \ref{sec:file_ioctl}) su un qualunque +tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix con i +\textit{file descriptor}. Allo stesso modo devono essere usati i \textit{file + descriptor} se si vuole ricorrere a modalità speciali di I/O come il polling +o il non-bloccante (vedi \capref{cha:file_advanced}). Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra quella dei \textit{file descriptor}, che permette di poter scegliere tra diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream} è che l'interfaccia per le operazioni di input/output è enormemente più ricca -di quella dei \textit{file descriptor}, che provvedono solo funzioni +di quella dei \textit{file descriptor}, che forniscono solo funzioni elementari per la lettura/scrittura diretta di blocchi di byte. In particolare gli \textit{stream} dispongono di tutte le funzioni di formattazione per l'input e l'output adatte per manipolare anche i dati in @@ -327,7 +332,7 @@ Linux, l'\acr{ext2}. In Linux il concetto di \textit{everything is a file} è stato implementato attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno strato intermedio che il kernel usa per accedere ai più svariati filesystem -mantenendo la stessa interfaccia per i programmi in user space. Esso provvede +mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce un livello di indirezione che permette di collegare le operazioni di manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di queste ultime nei vari modi in cui diversi filesystem le effettuano,