tutte le ulteriori operazioni saranno compiute specificando questo stesso
valore come argomento alle varie funzioni dell'interfaccia.
-Per capire come funziona il meccanismo occorre spiegare a grandi linee come è
-che il kernel gestisce l'interazione fra processi e file. Il kernel mantiene
-sempre un elenco dei processi attivi nella cosiddetta \textit{process table}
-ed un elenco dei file aperti nella \textit{file table}.
+Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
+kernel gestisce l'interazione fra processi e file. Il kernel mantiene 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 ciascuna voce è costituita da una
inviati i dati in uscita (sempre nel caso della shell, è associato all'uscita
del terminale, e quindi alla scrittura sullo schermo). Il terzo è lo
\textit{standard error}, su cui viene inviato l'output relativo agli errori,
-ed è anch'esso associato all'uscita del termininale. Lo standard POSIX.1
+ed è anch'esso associato all'uscita del terminale. Lo standard POSIX.1
provvede tre costanti simboliche, definite nell'header \file{unistd.h}, al
posto di questi valori numerici:
\begin{table}[htb]
\subsection{La funzione \func{open}}
\label{sec:file_open}
-La funzione \func{open} è la funzione fondamentale per accedere ai file, ed è
+La funzione \funcd{open} è la funzione fondamentale per accedere ai file, ed è
quella che crea l'associazione fra un pathname ed un file descriptor, il suo
prototipo è:
\begin{functions}
valore specifica anche una modalità di operazione (vedi sotto), e
comporta che \func{open} ritorni immediatamente (l'opzione ha senso
solo per le fifo, torneremo questo in \secref{sec:ipc_named_pipe}). \\
- \const{O\_NOCTTY} & se \param{pathname} si riferisce ad un device di
+ \const{O\_NOCTTY} & se \param{pathname} si riferisce ad un dispositivo di
terminale, questo non diventerà il terminale di controllo, anche se il
processo non ne ha ancora uno (si veda \secref{sec:sess_ctrl_term}). \\
\const{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
\func{write} bloccherà fino al completamento della scrittura di tutti dati
sul sull'hardware sottostante.\\
\const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\
- \const{O\_NOATIME} & blocca l'aggiornamento dei tempi dei di accesso dei
+ \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei
file (vedi \secref{sec:file_file_times}). In Linux questa opzione non è
disponibile per il singolo file ma come opzione per il filesystem in fase
di montaggio.\\
file con un nome univoco e la funzione \func{link} per verificarne
l'esistenza (vedi \secref{sec:ipc_file_lock}).}
-\footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti
- ad impedire un servizio causando una qualche forma di carico eccessivo per
- il sistema, che resta bloccato nelle risposte all'attacco.}
+\footnotetext[3]{\textit{Denial of Service}\index{DoS}, si chiamano così
+ attacchi miranti ad impedire un servizio causando una qualche forma di
+ carico eccessivo per il sistema, che resta bloccato nelle risposte
+ all'attacco.}
\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
il kernel deve simularla, ma questo comporta la possibilità di una race
Nelle prime versioni di Unix i valori di \param{flag} specificabili per
\func{open} erano solo 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 è:
+\funcd{creat}, il cui prototipo è:
\begin{prototype}{fcntl.h}
{int creat(const char *pathname, mode\_t mode)}
Crea un nuovo file vuoto, con i permessi specificati da \param{mode}. È del
\subsection{La funzione \func{close}}
\label{sec:file_close}
-La funzione \func{close} permette di chiudere un file, in questo modo il file
+La funzione \funcd{close} permette di chiudere un file, in questo modo il file
descriptor ritorna disponibile; il suo prototipo è:
\begin{prototype}{unistd.h}{int close(int fd)}
Chiude il descrittore \param{fd}.
In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa
posizione viene impostata a zero all'apertura del file. È possibile impostarla
-ad un valore qualsiasi con la funzione \func{lseek}, il cui prototipo è:
+ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
\funcdecl{off\_t lseek(int fd, off\_t offset, int whence)}
Imposta la posizione attuale nel file.
- \bodydesc{La funzione ritorna valore della posizione corrente in caso di
+ \bodydesc{La funzione ritorna il valore della posizione corrente in caso di
successo e -1 in caso di errore nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
\label{sec:file_read}
-Una volta che un file è stato aperto (con il permesso in lettura) su possono
-leggere i dati che contiene utilizzando la funzione \func{read}, il cui
+Una volta che un file è stato aperto (con il permesso in lettura) si possono
+leggere i dati che contiene utilizzando la funzione \funcd{read}, il cui
prototipo è:
\begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)}
aggiunto con la versione 2.1, in versioni precedenti sia del kernel che
delle librerie la funzione non è disponibile.} (quello che viene chiamato
normalmente Unix98, vedi \secref{sec:intro_opengroup}) è stata introdotta la
-definizione di un'altra funzione di lettura, \func{pread}, il cui prototipo è:
+definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è:
\begin{prototype}{unistd.h}
{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)}
\label{sec:file_write}
Una volta che un file è stato aperto (con il permesso in scrittura) su può
-scrivere su di esso utilizzando la funzione \func{write}, il cui prototipo è:
+scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo è:
\begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)}
Scrive \param{count} byte dal buffer \param{buf} sul file \param{fd}.
indicato da \param{count}, a meno di un errore. Negli altri casi si ha lo
stesso comportamento di \func{read}.
-Anche per \func{write} lo standard Unix98 definisce un'analoga \func{pwrite}
+Anche per \func{write} lo standard Unix98 definisce un'analoga \funcd{pwrite}
per scrivere alla posizione indicata senza modificare la posizione corrente
nel file, il suo prototipo è:
\begin{prototype}{unistd.h}
\label{fig:file_mult_acc}
\end{figure}
-Il primo caso è quello in cui due processi diversi che aprono lo stesso file
+Il primo caso è quello in cui due processi diversi aprono lo stesso file
su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una
situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun
processo avrà una sua voce nella \textit{file table} referenziata da un
questo dà la garanzia assoluta che i dati siano integri dopo la chiamata,
l'hardware dei dischi è in genere dotato di un suo meccanismo interno di
ottimizzazione per l'accesso al disco che può ritardare ulteriormente la
- scrittura effettiva.} La prima di queste funzioni è \func{sync} il cui
+ scrittura effettiva.} La prima di queste funzioni è \funcd{sync} il cui
prototipo è:
\begin{prototype}{unistd.h}{int sync(void)}
Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere
sicuri che i dati di un database sono stati registrati su disco) si possono
-usare le due funzioni \func{fsync} e \func{fdatasync}, i cui prototipi sono:
+usare le due funzioni \funcd{fsync} e \funcd{fdatasync}, i cui prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int fsync(int fd)}
Abbiamo già visto in \secref{sec:file_sharing} come un processo figlio
condivida gli stessi file descriptor del padre; è possibile però ottenere un
comportamento analogo all'interno di uno stesso processo \textit{duplicando}
-un file descriptor. Per far questo si usa la funzione \func{dup} il cui
+un file descriptor. Per far questo si usa la funzione \funcd{dup} il cui
prototipo è:
\begin{prototype}{unistd.h}{int dup(int oldfd)}
Crea una copia del file descriptor \param{oldfd}.
diventa così possibile associare un file (o una pipe) allo standard input o
allo standard output (torneremo sull'argomento in \secref{sec:ipc_pipe_use},
quando tratteremo le pipe). Per fare questo in genere occorre prima chiudere
-il file che si vuole sostituire, cossicché il suo file descriptor possa esser
+il file che si vuole sostituire, cosicché il suo file descriptor possa esser
restituito alla chiamata di \func{dup}, come primo file descriptor
disponibile.
Dato che questa è l'operazione più comune, è prevista una diversa versione
-della funzione, \func{dup2}, che permette di specificare esplicitamente qual'è
-il valore di file descriptor che si vuole avere come duplicato; il suo
+della funzione, \funcd{dup2}, che permette di specificare esplicitamente
+qual'è il valore di file descriptor che si vuole avere come duplicato; il suo
prototipo è:
\begin{prototype}{unistd.h}{int dup2(int oldfd, int newfd)}
la sintassi \code{fnctl(oldfd, F\_DUPFD, newfd)} e se si usa 0 come valore per
\param{newfd} diventa equivalente a \func{dup}.
-La sola differenza fra le due funzioni\footnote{a parte la sistassi ed i
+La sola differenza fra le due funzioni\footnote{a parte la sintassi ed i
diversi codici di errore.} è che \func{dup2} chiude il file descriptor
\param{newfd} se questo è già aperto, garantendo che la duplicazione sia
effettuata esattamente su di esso, invece \func{fcntl} restituisce il primo
descriptor, che non riguardano la normale lettura e scrittura di dati, ma la
gestione sia delle loro proprietà, che di tutta una serie di ulteriori
funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si
- gesticono con questa funzione l'I/O asincrono (vedi
+ gestiscono con questa funzione l'I/O asincrono (vedi
\secref{sec:file_asyncronous_io}) e il file locking\index{file!locking}
(vedi \secref{sec:file_locking}).}
Per queste operazioni di manipolazione e di controllo su proprietà e
-caratteristiche un file descriptor, viene usata la funzione \func{fcntl}, il
+caratteristiche un file descriptor, viene usata la funzione \funcd{fcntl}, il
cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro
valore (compreso lo stesso \const{SIGIO}) specifica il segnale voluto; l'uso
di un valore diverso da zero permette inoltre, se si è installato il
- manipolatore del segnale come \var{sa\_sigaction} usando
+ gestore del segnale come \var{sa\_sigaction} usando
\const{SA\_SIGINFO}, (vedi \secref{sec:sig_sigaction}), di rendere
- disponibili al manipolatore informazioni ulteriori informazioni riguardo il
+ disponibili al gestore informazioni ulteriori informazioni riguardo il
file che ha generato il segnale attraverso i valori restituiti in
\struct{siginfo\_t} (come vedremo in
\secref{sec:file_asyncronous_io}).\footnote{i due comandi \const{F\_SETSIG}
Si tenga presente infine che quando si usa la funzione per determinare le
modalità di accesso con cui è stato aperto il file (attraverso l'uso del
-comando \const{F\_GETFL}) è necessario estrarre i bit corripondenti nel
+comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel
\textit{file status flag} che si è ottenuto. Infatti la definizione corrente
di quest'ultimo non assegna bit separati alle tre diverse modalità
\const{O\_RDONLY}, \const{O\_WRONLY} e \const{O\_RDWR}.\footnote{in Linux
porta seriale, o le dimensioni di un framebuffer).
Per questo motivo nell'architettura del sistema è stata prevista l'esistenza
-di una funzione apposita, \func{ioctl}, con cui poter compiere le operazioni
+di una funzione apposita, \funcd{ioctl}, con cui poter compiere le operazioni
specifiche di ogni dispositivo particolare, usando come riferimento il solito
file descriptor. Il prototipo di questa funzione è:
\begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
projects / gapil.git / blobdiff