address-space is a non-recursive data structure, which contains a flat list of vm_areas representing
mapped vm-objects.
userspace programs can no longer create sub-address-spaces. instead, they can reserve portions of
the address space, and use that reserved space to create mappings.
the rules around acquiring locks have been strictly defined and
implemented, and general lock usage has been improved, to fix and
prevent several different issues.
a vm-region is now destroyed in two separate steps:
1. it is "killed": all mappings are unmapped and deleted, the
region is removed from its parent, and the region and all of
its sub-regions are marked as "dead", preventing any
further actions from being performed with the region.
2. it is "destroyed": the vm-region object is de-allocated when
the last reference/handle is closed. the references that this
region holds to any sub-regions are also released, meaning
these regions may also be de-allocated too.
all kernel headers have been moved from include/mango to include/kernel
and include definitions that are only relevant to kernel-space.
any definitions that are relevant to both kernel- and user-space
(i.e. type definitions, syscall IDs) have been moved to
include/mango within libmango.
vm-region supports creating nested regions of virtual memory, each with their
own memory protection restrictions.
vm-objects can be mapped into a vm-region, making the underlying memory
accessible. all mappings are lazy: page tables are not updated until the
mapped memory is accessed.
vm-object can be used to demand-allocate non-contiguous physical memory, and
will provide an api for userspace programs to do the same. unless a vm-object
is created in-place (i.e. to represent a specific area of physical memory),
its memory pages are only allocated when the object is mapped AND someone
attempts to access the memory.
