<!--
     Copyright 2017, Data61, CSIRO (ABN 41 687 119 230)

     SPDX-License-Identifier: CC-BY-SA-4.0
-->

libsel4allocman
===============

libsel4allocman provides a way to allocate different kinds of resources from the
'base' resource type in seL4, which is untyped memory.

It provides by an implementation of the `vka_t` interface as well as a native
interface for accessing features not exposed by vka.

Allocation overview
-------------------

Allocation is complex due to the circular dependencies that exist on allocating resources. These dependencies
are loosely described as

  * Capability slots: Allocated from untypeds, book kept in memory
  * Untypeds / other objects (including frame objects): Allocated from other untypeds, into capability slots,
    book kept in memory
  * memory: Requires frame object

Note that these dependencies and complications only exist if you want to be able to track, book keep, free and reuse
all allocations. If you want a simpler 'allocate only' system, that does not require book keeping to support free,
then these problems don't exist.

Initially, because of these circular dependencies, nothing can be allocated. The static pool provides a way to inject
one of the dependencies and try and start the cycle.

The static and virtual pools can be thought of as just being another heap. Allocman uses these to allocate book
keeping data in preference to the regular C heap due to usage in environments where the C heap is either not
implemented or is implemented using allocman.

Two pools are needed, one static and one virtual, because the virtual pool (along with the rest of allocman) require
memory in order to bootstrap. Once bootstrapping is done then provided the system does not run out of memory enough
space in the virtual pool will also be reserved to ensure that if the virtual pool needs to grow, there is enough
memory for any book keeping required.