Segregate kernel/memory.hpp into meaningful parts
#2343
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The old
kernel/memory.hpphad several responsibilities, and albeit not being super long it felt hard to read. It comprised at least two fairly different parts:mem/vmap.hpp)mem/alloc.hpp)Furthermore, I've also created
mem/flags.hppsince it doesn't quite fit either of them entirely, and it facilitates plans going forward.Currently, we're assuming architecture-specific/hardware protection flags match IncludeOS-allocation flags. While this is currently the case, I do intend to change this in the future for the sake of type safety.
src/arch/x86_64/paging.cppusesos::mem::Accessreferring to hardware flags, whilesrc/kernel/multiboot.cpporsrc/kernel/elf.cpprefers to IncludeOS semantics. I intend to create a per-architecture translation mapping for this (constexpr, so it won't affect any performance, of course).The responsibility separation between
mem/vmapandmem/allocseems to be represented in the usages across the code too (most of the results are non-overlapping):This PR essentially makes #2329 obsolete.