unix, è anzitutto opportuno fornire un'introduzione dettagliata su come essi
vengono trattati dal sistema. In particolare occorre tenere presente dov'è che
si situa il limite fondamentale fra kernel space e user space che tracciavamo
-al Cap.~\ref{cha:intro_unix}.
+al \capref{cha:intro_unix}.
Partiamo allora da come viene strutturata nel sistema la disposizione dei
file: per potervi accedere il kernel usa una apposita interfaccia che permetta
Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
memorizzati all'interno del disco stesso, strutturando l'informazione in files
e directory (su questo aspetto torneremo con maggiori dettagli in
-\ref{sec:filedir_filesystem}). Per poter accedere ai file contenuti in un
+\secref{sec:filedir_filesystem}). 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).
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 \ref{sec:fileunix_fd}). Un elenco delle operazioni
+torneremo in dettaglio in \secref{sec:fileunix_fd}). Un elenco delle operazioni
previste dal kernel è riportato in \ntab.
\begin{table}[htb]
In unix è implementata da qualunque filesystem standard una forma elementare
(ma adatta alla maggior parte delle esigenze) di controllo di accesso ai
files. Torneremo sull'argomento in dettaglio più avanti (vedi
-\ref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei
+\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei
concetti essenziali.
Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix,
Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto
\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e
-gid accennato in Sez.~\ref{sec:intro_usergroup}, e un insieme di permessi che
+gid accennato in \secref{sec:intro_usergroup}, e un insieme di permessi che
sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario,
a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti
gli altri utenti.
lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
\textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al
proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari
-permessi associati ai file è riportata in \ref{sec:filedir_suid_sgid}). I
+permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}). I
restanti tre bit sono usati per indicare alcune caratteristiche più complesse
(\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in
-seguito (vedi \ref{sec:filedir_suid_sgid} e \ref{sec:filedir_stiky}).
+seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_stiky}).
Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un
processo cerca l'accesso al file esso controlla i propri uid e gid
In realtà il procedimento è più complesso di quanto descritto in maniera
elementare qui; inoltre ad un processo sono associati diversi identificatori,
-torneremo su questo in maggiori dettagli in seguito in \ref{sec:proc_perms}.
+torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
\subsection{I tipi di files}
\label{sec:fileintr_file_types}
usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
devono essere usati i file descriptor se si vuole ricorrere a modalità
speciali di I/O come il polling o il non-bloccante (vedi
-\ref{sec:file_bohhhhh}).
+\secref{sec:file_bohhhhh}).
Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
dei file descriptor, che tratta tutti i file nello stesso modo, con
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 (e pratica
-comune) 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.
+chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+in dettaglio in \secref{sec:filedir_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, quando tratteremo l'input/output sui file,
esaminando in dettaglio come tutto ciò viene realizzato.
projects / gapil.git / blobdiff