View source for *Mview management of mmap

Unfortunately mmap access to the file systems cannot be captured by ptrace (or by utrace). We are studying patches and extensions to the utrace support for this purpose.

In the meanwhile we have developed a way to give a limited support for mmap, expecially for the support of dynamic libraries. Only read_only, ''MAP_PRIVATE'' calls are currently supported on virtual files.
The ''trick'' is based on a hidden file opened by umview or kmview and inherited through all the fork and exec calls. 

All the mmap support code is in the '''um_mmap.c''' source file.

If a process under *Mview control tries to execute a system call on that hidden file gets an error.

When a process executes a mmap on a virtual file, the file gets copied in a section of the hidden file. The support system take trace of the mapping between virtual files and sections of the file. Each section of the file is shared by all the process using the same file in mmap mode. This is quite common when dealing with dynamic libraries. The garbage collector delays the deallocation of sections using a LRU approximation. This avoids loading and unloading libraries and files when frequently used.

The data structure used is a list, the head is '''mmap_sf_head''' and each section (or chunk) information is stored in a '''struct mmap_sf_entry''' element.

LRU approximation uses the '''lastuse''' field, its MSB is set at each use and right shifted at any allocation.
when more than '''sizeof(long)''' files get allocated and a chuck is still unused, it is unloaded and the space freed.

mmap call arguments get changed to use the hidden file in the right position.