Updates documentation to clarify process freeing and resource groups.

docs/RESOURCE.md

@@ -1,6 +1,6 @@
 A Resource is a region of memory or some other entity that can be adequately and securely accessed via the virtual memory system. It is represented as a PML3, PML2, PML1, or as a single page depending on the needs and size of that resource. A Process has access to a Resource if and only if that Resource is accessible via a virtual address during the runtime of that Process. That is, the Resource is currently mapped into the page table hierarchy of the Process, which is itself represented by a PML4. The kernel keeps track of all Resources via them being mapped into the virtual address space of the kernel. A Resource is then identified via a 64-bit identifier that is exactly the virtual address within that mapping of the root page table structure (PML3, PML2, PML1, or single page via the recursive entry at `PML4[510]`) of that Resource. We often lovingly refer to these by another name: a Gib.
 
-A ResourceGroup is a set of resources that itself can be securely accessed via the virtual memory system. This is generally only ever a PML3 (which can contain one or more PML2, PML1, or single-page sized Resources), a PML2 (which can thus contain a set of PML1 or single-paged sized resources), or a very compact PML1 containing potentially a single-page Resource in one or more of its entries. A process can access a ResourceGroup if and only if it is accessible via a virtual address during the runtime of that Process. That is, if that ResourceGroup is currently mapped into the page table hierarchy of the Process. Consequentially, the one or more Resources that are themselves mapped into the ResourceGroup page table structure are themselves accessible by a Process if and only if that ResourceGroup itself is accessible. The access control and subsequent security is provided by the virtual memory hardware. There is nothing actually special about a ResourceGroup as it is just a Resource. It is just a useful concept that is given this special name for clarity. A Process can add a Resource to a ResourceGroup by simply allocating (or being granted) a Resource inside the address space of the ResourceGroup. The kernel does not see any distinction here. When a ResourceGroup is freed, however, the deallocation via walking the page table structure will also free any `Owner` marked Resource roots, which cascade the action by freeing these internal Resource objects along with their parent. This is abnormal behavior, however, since a competent application deallocates its own Resource objects page by page on its own.
+A ResourceGroup is a set of resources that itself can be securely accessed via the virtual memory system. This is generally only ever a PML3 (which can contain one or more PML2, PML1, or single-page sized Resources), a PML2 (which can thus contain a set of PML1 or single-paged sized resources), or a very compact PML1 containing potentially a single-page Resource in one or more of its entries. A process can access a ResourceGroup if and only if it is accessible via a virtual address during the runtime of that Process. That is, if that ResourceGroup is currently mapped into the page table hierarchy of the Process. Consequentially, the one or more Resources that are themselves mapped into the ResourceGroup page table structure are themselves accessible by a Process if and only if that ResourceGroup itself is accessible. The access control and subsequent security is provided by the virtual memory hardware. There is nothing actually special about a ResourceGroup as it is just a Resource. It is just a useful concept that is given this special name for clarity. A Process can add a Resource to a ResourceGroup by simply allocating (or being granted) a Resource inside the address space of the ResourceGroup. The kernel does not see any distinction here.
 
 A region of memory is the most obvious resource to encapsulate. This is just a set of pre-allocated and marked physical pages that are organized into a page table structure rooted by a PML3, PML2, or PML1 with the necessary leaves mapping to the aforementioned marked physical pages. When the root of this Resource is mapped into a Process, it is then accessible. If it is granted to a second Process, that memory is shared potentially with different access flags. Interestingly, the page table primitives allow for sections of the memory Resource to be marked independently readonly or no-execute in parts divisible by the page size of the architecture and its available access control flags. A Process can also map the Resource with particular flags that will take precedence. For instance, if the Process can only attach the Resource to itself read-only, the technically writable pages within will be inaccessible for writes when the root page table of the Resource is mapped into a page table entry within the Process page table with the read-only flag set. When granting a Resource as read-only, the target Process can read the data but not modify it with the same page tables as the owning Process, which can write to it freely. Only the owning Process can affect the page table flags of the intermediate page tables and entries within. It does this with the memory primitive function `CHMOD_PAGE` described in [MEMORY](MEMORY.md).