-Un file viene sempre mappato su multipli delle dimensioni di una pagina,
-qualora esso sia più corto la parte restante è riempita con zeri; eventuali
-scritture in quella zona di memoria non vengono riportate sul file. Se le
-dimensioni del file cambiano (esso viene esteso o troncato), non è specificato
-quale effetto viene a aversi sulle pagine di memoria che corrispondono alle
-regioni aggiunte o tolte.
-
-Si tenga presente che non tutti i file possono venire mappati in memoria, la
-mappatura infatti introduce una corrispondenza biunivoca fra una sezione di un
-file ed una sezione di memoria, pertanto si può parlare tanto di file mappato
-in memoria, quanto di memoria mappata su file. Questo comporta che ad esempio
-non è possibile mappare in memoria pipe, socket e fifo, per le quali non ha
-senso parlare di \textsl{sezione}. Lo stesso vale anche per alcuni file di
-dispositivo, che non dispongono della relativa operazione \var{mmap} (si
-ricordi quanto esposto in \secref{sec:file_vfs_work}), ma esistono anche casi
-(un esempio è l'interfaccia ponte PCI-VME del chip Universe) di dispositivi
-che sono utilizzabili praticamente solo con questa interfaccia.
-
-Passando attraverso una \func{fork} i file mappati in memoria vengono
-ereditati in maniera trasparente dal processo figlio, mantenendo gli stessi
-attributi avuti nel padre; così se si è usato \macro{MAP\_SHARED} padre e
-figlio accederanno allo stesso file in maniera condivisa, mentre se si è usato
-\macro{MAP\_PRIVATE} ciascuno di essi manterrà una sua versione privata
-indipendente. Non c'è invece nessun passaggio attraverso una \func{exec}, dato
-che quest'ultima sostituisce tutto lo spazio degli indirizzi di un processo
-con quello di un nuovo programma.
+Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
+piuttosto complessi, essi si possono comprendere solo tenendo presente che
+tutto quanto è comunque basato sul basato sul meccanismo della memoria
+virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che
+se si cerca di scrivere su una zona mappata in sola lettura si avrà
+l'emissione di un segnale di violazione di accesso (\macro{SIGSEGV}), dato che
+i permessi sul segmento di memoria relativo non consentono questo tipo di
+accesso.
+
+È invece assai diversa la questione relativa agli accessi al di fuori della
+regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
+ritenere che anch'essi debbano generare un segnale di violazione di accesso;
+questo però non tiene conto del fatto che, essendo basata sul meccanismo della
+paginazione, la mappatura in memoria non può che essere eseguita su un
+segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in
+generale queste potranno non corrispondere alle dimensioni effettive del file
+o della sezione che si vuole mappare. Il caso più comune è quello illustrato
+in \figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei
+confini di una pagina: in tal caso verrà il file sarà mappato su un segmento
+di memoria che si estende fino al bordo della pagina successiva.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/mmap_boundary}
+ \caption{Schema della mappatura in memoria di una sezione di file di
+ dimensioni non corrispondenti al bordo di una pagina.}
+ \label{fig:file_mmap_boundary}
+\end{figure}
+
+
+In questo caso è possibile accedere a quella zona di memoria che eccede le
+dimensioni specificate da \param{lenght}, senza ottenere un \macro{SIGSEGV}
+poiché essa è presente nello spazio di indirizzi del processo, anche se non è
+mappata sul file. Il comportamento del sistema è quello di restituire un
+valore nullo per quanto viene letto, e di non riportare su file quanto viene
+scritto.
+
+Un caso più complesso è quello che si viene a creare quando le dimensioni del
+file mappato sono più corte delle dimensioni della mappatura, oppure quando il
+file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
+quella della mappatura in memoria.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=13cm]{img/mmap_exceed}
+ \caption{Schema della mappatura in memoria di file di dimensioni inferiori
+ alla lunghezza richiesta.}
+ \label{fig:file_mmap_exceed}
+\end{figure}
+
+In questa situazione, per la sezione di pagina parzialmente coperta dal
+contenuto del file, vale esattamente quanto visto in precedenza; invece per la
+parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
+sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma
+\macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}.
+
+Non tutti i file possono venire mappati in memoria, dato che, come illustrato
+in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
+biunivoca fra una sezione di un file ed una sezione di memoria. Questo
+comporta che ad esempio non è possibile mappare in memoria file descriptor
+relativi a pipe, socket e fifo, per i quali non ha senso parlare di
+\textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
+dispongono della relativa operazione \var{mmap} (si ricordi quanto esposto in
+\secref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi di
+dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
+che sono utilizzabili solo con questa interfaccia.
+
+Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
+copiato integralmente, i file mappati in memoria verranno ereditati in maniera
+trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
+padre; così se si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo
+stesso file in maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE}
+ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
+invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
+sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
+nuovo programma.
projects / gapil.git / blobdiff