\itindend{scheduler}
La memoria viene sempre gestita dal kernel attraverso il meccanismo della
-\index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
-a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
-sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
-gestione della memoria, si incaricherà di rimappare automaticamente sulla
-memoria fisica disponibile, con la possibilità ulteriore di spostare
-temporaneamente su disco (nella cosiddetta area di \textit{swap}) parte di
-detta memoria qualora ci si trovi nella necessità di liberare risorse.
+\textsl{memoria virtuale}, che consente di assegnare a ciascun processo uno
+spazio di indirizzi ``\textsl{virtuale}'' (vedi sez.~\ref{sec:proc_memory})
+che il kernel stesso, con l'ausilio della unità di gestione della memoria, si
+incaricherà di rimappare automaticamente sulla memoria fisica disponibile, con
+la possibilità ulteriore di spostare temporaneamente su disco (nella
+cosiddetta area di \textit{swap}) parte di detta memoria qualora ci si trovi
+nella necessità di liberare risorse.
Le periferiche infine vengono normalmente viste attraverso un'interfaccia
astratta che permette di trattarle come se fossero dei file, secondo uno dei
scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
che consenta di operare sui file, sia che questi corrispondano ai normali file
-di dati, o ai cosiddetti \index{file!speciali} ``\textsl{file speciali}'',
-come \index{file!di~dispositivo} i file di dispositivo (o \textit{device
- file}) che permettono di accedere alle periferiche o le fifo ed i socket che
-forniscono funzionalità di comunicazione fra processi.
+di dati, o ai cosiddetti ``\textsl{file speciali}'', come i file di
+dispositivo (o \textit{device file}) che permettono di accedere alle
+periferiche o le fifo ed i socket che forniscono funzionalità di comunicazione
+fra processi (torneremo su questo in sez.~\ref{sec:file_mknod}).
Il secondo aspetto è che per poter utilizzare dei normali file di dati il
kernel deve provvedere ad organizzare e rendere accessibile in maniera
``\textsl{montaggio}'' del filesystem nell'albero dei file, dove il contenuto
sarà accessibile nella forma ordinaria di file e directory.
-\itindbeg{Virtual~File~System}
+\itindbeg{Virtual~File~System~(VFS)}
In Linux il concetto di \textit{everything is a file} è stato implementato
attraverso il \textit{Virtual File System} (che da qui in poi abbrevieremo in
\textit{Virtual File System} eseguirà direttamente il codice del kernel che
permette di accedere alla periferica.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
Come accennato in precedenza una delle funzioni essenziali per il
funzionamento dell'interfaccia dei file è quella che consente di montare un
filesystem, compresa un'altra directory, si ottiene naturalmente
un'organizzazione ad albero inserendo nomi di directory dentro altre
directory. All'interno dello stesso albero si potranno poi inserire anche
-tutti gli altri oggetti previsti l'interfaccia del
-\itindex{Virtual~File~System} VFS (su cui torneremo in
+tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
socket e gli stessi file di dispositivo.
sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
directory radice dell'albero dei file montata dal kernel all'avvio del
sistema; in questo caso si parla di un \textsl{pathname assoluto}
-\itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla
-\index{directory~di~lavoro} directory di lavoro corrente del processo (su cui
-torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla directory di
+lavoro corrente del processo (su cui torneremo in
+sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
\itindsub{pathname}{relativo} \textsl{pathname relativo}.
Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
significa anzitutto chiarire il proprio vocabolario e sottolineare le
differenze che ci sono rispetto ad altri sistemi operativi.
+\index{file!di~dispositivo|(}
+\index{file!speciali|(}
+
Come accennato in sez.~\ref{sec:file_arch_overview} su Linux l'uso del
-\itindex{Virtual~File~System} \textit{Virtual File System} consente di
-trattare come file oggetti molto diversi fra loro. Oltre ai normali file di
-dati abbiamo già accennato ad altri due di questi oggetti, i file di
-dispositivo e le directory, ma ne esistono altri. In genere quando si parla di
-tipo di file su Linux si fa riferimento a questi, di cui si riportato l'elenco
-completo in tab.~\ref{tab:file_file_types}.
+\textit{Virtual File System} consente di trattare come file oggetti molto
+diversi fra loro. Oltre ai normali file di dati abbiamo già accennato ad altri
+due di questi oggetti, i file di dispositivo e le directory, ma ne esistono
+altri. In genere quando si parla di tipo di file su Linux si fa riferimento a
+questi, di cui si riportato l'elenco completo in
+tab.~\ref{tab:file_file_types}.
\begin{table}[htb]
\footnotesize
\multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
\hline
\hline
- \textit{regular file} & \textsl{file regolare} & 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
- \textit{inode} (vedi
- sez.~\ref{sec:file_vfs_work}).\\
- \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 \textsl{speciale}
- che identifica una periferica
- ad accesso a caratteri.\\
- \textit{block device} & \textsl{dispositivo a blocchi} & Un file \textsl{speciale}
- che identifica una periferica
- ad accesso a blocchi.\\
- \textit{fifo} & ``\textsl{coda}'' & Un file \textsl{speciale} che
- identifica una linea di comunicazione
- unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
- \textit{socket} & ``\textsl{presa}''& Un file \textsl{speciale} che identifica una linea di
- comunicazione bidirezionale (vedi
- cap.~\ref{cha:socket_intro}).\\
+ \textit{regular file}& \textsl{file regolare}
+ & 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 \textit{inode} (vedi
+ sez.~\ref{sec:file_vfs_work}).\\
+ \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 \textsl{speciale} che identifica una
+ periferica ad accesso a caratteri.\\
+ \textit{block device}& \textsl{dispositivo a blocchi}
+ & Un file \textsl{speciale} che identifica una
+ periferica ad accesso a blocchi.\\
+ \textit{fifo} & ``\textsl{coda}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione unidirezionale (vedi
+ sez.~\ref{sec:ipc_named_pipe}).\\
+ \textit{socket} & ``\textsl{presa}''
+ & Un file \textsl{speciale} che identifica una
+ linea di comunicazione bidirezionale (vedi
+ cap.~\ref{cha:socket_intro}).\\
\hline
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
niente a che fare neanche con le eventuali diverse modalità con cui si
potrebbe accedere al contenuto dei file di dati. La classificazione di
tab.~\ref{tab:file_file_types} riguarda il tipo di oggetti gestiti dal
-\itindex{Virtual~File~System} \textit{Virtual File System}, ed è da notare la
-presenza dei cosiddetti file ``\textsl{speciali}''.
+\textit{Virtual File System}, ed è da notare la presenza dei cosiddetti file
+``\textsl{speciali}''.
Alcuni di essi, come le \textit{fifo} (che tratteremo in
sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
alcune funzionalità di comunicazione fornite dal kernel. Gli altri sono
-proprio quei \index{file!di~dispositivo} \textsl{file di dispositivo} che
-costituiscono una interfaccia diretta per leggere e scrivere sui dispositivi
-fisici. Anche se finora li abbiamo chiamati genericamente così, essi sono
-tradizionalmente suddivisi in due grandi categorie, \textsl{a blocchi} e
-\textsl{a caratteri} a seconda delle modalità in cui il dispositivo
-sottostante effettua le operazioni di I/O.
+proprio quei \textsl{file di dispositivo} che costituiscono una interfaccia
+diretta per leggere e scrivere sui dispositivi fisici. Anche se finora li
+abbiamo chiamati genericamente così, essi sono tradizionalmente suddivisi in
+due grandi categorie, \textsl{a blocchi} e \textsl{a caratteri} a seconda
+delle modalità in cui il dispositivo sottostante effettua le operazioni di
+I/O.
I dispositivi a blocchi (ad esempio i dischi) sono quelli corrispondono a
periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi di
dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel,
ed è completamente trasparente all'utente; inoltre talvolta si parla di
\textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
- fare con tutto ciò, di effettuare, attraverso degli appositi
- \index{file!di~dispositivo} file di dispositivo, operazioni di I/O
- direttamente sui dischi senza passare attraverso un filesystem, il
- cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ma
- ormai in sostanziale disuso.}
+ fare con tutto ciò, di effettuare, attraverso degli appositi file di
+ dispositivo, operazioni di I/O direttamente sui dischi senza passare
+ attraverso un filesystem, il cosiddetto \textit{raw access}, introdotto coi
+ kernel della serie 2.4.x ma ormai in sostanziale disuso.}
+
+\index{file!di~dispositivo|}
+\index{file!speciali|)}
Una differenza che attiene ai contenuti di un file però esiste, ed è relativa
al formato dei file di testo. Nei sistemi unix-like la fine riga è codificata
tipo di processore o architettura è stato adottato da molti sistemi
unix-like e non solo.}
+\itindbeg{magic~number}
+
Nonostante l'assenza di supporto da parte del kernel per la classificazione
del contenuto dei file di dati, molti programmi adottano comunque delle
convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
in file con l'estensione \file{.c}. Inoltre una tecnica molto usata per
classificare i contenuti da parte dei programmi è quella di utilizzare i primi
-byte del file per memorizzare un \itindex{magic~number} ``\textit{magic
- number}''\footnote{il concetto è quello di un numero intero, solitamente fra
- 2 e 10 byte, che identifichi il contenuto seguente, dato che questi sono
- anche caratteri è comune trovare espresso tale numero con stringhe come
- ``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script.} che ne
-classifichi il contenuto. Entrambe queste tecniche, per quanto usate ed
-accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
-demandato alle applicazioni stesse.
+byte del file per memorizzare un ``\textit{magic number}'' che ne classifichi
+il contenuto. Il concetto è quello di un numero intero, solitamente fra 2 e 10
+byte, che identifichi il contenuto seguente, dato che questi sono anche
+caratteri è comune trovare espresso tale numero con stringhe come
+``\texttt{\%PDF}'' per i PDF o ``\texttt{\#!}'' per gli script. Entrambe
+queste tecniche, per quanto usate ed accettate in maniera diffusa, restano
+solo delle convenzioni il cui rispetto è demandato alle applicazioni stesse.
+
+\itindend{magic~number}
\subsection{Le due interfacce per l'accesso ai file}
(descritte in sez.~\ref{sec:file_fcntl_ioctl}) su un qualunque tipo di oggetto
del VFS occorre usare l'interfaccia standard di Unix con i file
descriptor. Allo stesso modo devono essere usati i file descriptor se si vuole
-ricorrere a modalità speciali di I/O come il \itindex{file~locking}
-\textit{file locking} o l'I/O non-bloccante (vedi
-cap.~\ref{cha:file_advanced}).
+ricorrere a modalità speciali di I/O come il \textit{file locking} o l'I/O
+non-bloccante (vedi cap.~\ref{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
Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
libreria, e in seguito sono stati prodotti anche altri standard per la shell e
i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
-\itindex{thread} \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i
-socket (1003.1g) e vari altri. In tab.~\ref{tab:intro_posix_std} è riportata
-una classificazione sommaria dei principali documenti prodotti, e di come sono
-identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
-l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
-parlare di POSIX.4 come di POSIX.1b.
+\textit{thread} (rispettivamente 1003.1d e 1003.1c) per i socket (1003.1g) e
+vari altri. In tab.~\ref{tab:intro_posix_std} è riportata una classificazione
+sommaria dei principali documenti prodotti, e di come sono identificati fra
+IEEE ed ISO; si tenga conto inoltre che molto spesso si usa l'estensione IEEE
+anche come aggiunta al nome POSIX; ad esempio è più comune parlare di POSIX.4
+come di POSIX.1b.
Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
POSIX.2 & 1003.2 & 9945-2& Comandi. \\
POSIX.3 & 2003 &TR13210& Metodi di test. \\
POSIX.4 & 1003.1b & --- & Estensioni real-time. \\
- POSIX.4a& 1003.1c & --- & \itindex{thread} Thread. \\
+ POSIX.4a& 1003.1c & --- & Thread. \\
POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time. \\
POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA. \\
POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza. \\
\item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
- dello standard POSIX.1c per i \itindex{thread} \textit{thread};
+ dello standard POSIX.1c per i \textit{thread};
\item a partire dalla versione 2.3.3 della \acr{glibc} un valore maggiore o
uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
\item[\macro{\_ATFILE\_SOURCE}] definendo questa macro si rendono disponibili
le estensioni delle funzioni di creazione, accesso e modifica di file e
directory che risolvono i problemi di sicurezza insiti nell'uso di
- \textit{pathname} relativi con programmi \itindex{thread}
- \textit{multi-thread} illustrate in sez.~\ref{sec:file_openat}.
+ \textit{pathname} relativi con programmi \textit{multi-thread} illustrate in
+ sez.~\ref{sec:file_openat}.
\item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente
\macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
- versioni \index{funzioni!rientranti} rientranti (vedi
- sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si
- usano i \itindex{thread} \textit{thread}. Alcune di queste funzioni sono
- anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
+ versioni rientranti (vedi sez.~\ref{sec:proc_reentrant}) di alcune funzioni,
+ necessarie quando si usano i \textit{thread}. Alcune di queste funzioni
+ sono anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
disponibili soltanto su alcuni sistemi, o specifiche della \acr{glibc}, e
possono essere utilizzate una volta definita la macro.
projects / gapil.git / blobdiff