Memory management

[Espen Skoglund]

[Julian Stecklina]
> Ok, after studying the Reference Manual I understand how to
> manipulate access rights and am seriously wondering why the name
> "Unmap" was chosen. ;)

  (1) for historical reasons, and
  (2) you "unmap" the access rights of a given mapping

> Btw, "Mapped fpages are considered inseparable objects. That is, if
> an fpage is mapped, the mapper can not later partially unmap the
> mapped page; the whole fpage must be unmapped in a single
> operation. The mappee can, however, separate the fpage and map
> fpages (objects) of smaller size."

> The manual is quite vague about how one would actually do this,
> though. :-/

A maps a 4MB page to B.  A can not later unmap a 4KB out of this page.
Similarly, B can not unmap (self) a 4KB mapping out of this page.  B
can however map a 4KB mapping to C and later unmap this mapping.  That
is, the following situation is allowed:

        4MB      4KB
     A -----> B -----> C
         X        Y

The mapping X from A to B can not be partially unmapped.  B can map a
smaller part Y of X to C, though.

> Is there any actual code to look at that does some interesting
> things with fpages? What I am looking for is the way one would
> implement a kind of mprotect(2).

Can't think of anything "interesting" to do with fpages, so I can't
really point you at any particular code.

For revoking rights using mprotect() you can simply use Unmap().
Extension of access rights would typically be handled lazily.  That
is, when the thread performs an illegal access (e.g., write access on
a read-only page) a page fault RPC is sent to the thread's pager who
will reply with a mapping having the appropriate rights.

	eSk