1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
.. index::
   pair: VM for Digital Unix; design

.. _design-vmo1:


VM for Digital Unix
===================

.. mps:prefix:: design.mps.vmo1


.. warning::

    As of 2013-05-26, the MPS is no longer supported on Digital Unix,
    so this document is only of historical interest.


Introduction
------------

:mps:tag:`readership` Any MPS developer.

:mps:tag:`intro` This is the design of the VM Module for Digital UNIX (also
known as OSF/1 and Tru64 Unix; see os.o1). In general aspects
(including interface) the design is as for design.mps.vm.


Functions
---------

:mps:tag:`fun.unmap` :c:func:`VMUnmap()` "unmaps" a region by replacing the
existing mapping with a mapping using the ``vm->none_fd`` file
descriptor (see mumble mumble, :c:func:`VMCreate()`), and protection set to
:c:macro:`PROT_NONE` (that is, no access).

:mps:tag:`fun.unmap.justify` Replacing the mapping in this way means that
the address space is still reserved and will not be used by calls to
:c:func:`mmap()` (perhaps in other libraries) which specify
:c:macro:`MAP_VARIABLE`.

:mps:tag:`fun.unmap.offset` The offset for this mapping is the offset of the
region being unmapped in the VM; this gives the same effect as if
there was one mapping of the ``vm->none_fd`` from the base to the
limit of the VM (but "behind" all the other mappings that have been
created).

:mps:tag:`fun.unmap.offset.justify` If this is not done (if for example the
offset is always specified as 0) then the VM will cause the kernel to
create a new file reference for each mapping created with
:c:func:`VMUnmap()`; eventually the kernel refuses the :c:func:`mmap()` call because it
can't create a new file reference.