feat(mapper): add MappedPageTable::display
#574
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.
Hi everyone! :)
In Hermit, we found it useful to be able to print our page tables for debugging. We've had several iterations of such debugging functions but are now happy with the current compact range-based table formatting introduced in hermit-os/kernel#1818.
It can be used as follows:
This results in the following output on a fresh QEMU Multiboot page table:
We found that this compact display of the current page tables makes related debugging much easier.
To implement this on our side, we had to duplicate some non-public items from this crate:
PhysOffsetandPageTableWalker.This PR is an upstreaming effort and incrementally adds the required functionality for displaying the page table to this crate.
It is best reviewed commit by commit.
The code is not documented yet, since I wanted to discuss the API in general first.
The commits do the following:
PhysOffsetpublic. This straightforwardPageTableFrameMappingimplementation makesMappedPageTableusable as anOffsetPageTable, which is useful for generic code that otherwise would need to distinguish between the two.Clone,CopyforPhysOffset. This is required to be able to clone thePageTableFrameMappingin the eventualMappedPageTableDisplay::fmt(&self)method without moving out ofself.OffsetPageTablea type alias. This one is not strictly necessary, but being able to handleOffsetPageTableas anMappedPageTableavoids having to distinguish between the two. User migration should be as easy as replacingOffsetPageTable::newwithOffsetPageTable::new_offset. We could even think about deprecating the type alias.PageTableWalkerpublic. This is required to iterate over the page tables efficiently.Clone,CopyforPageTableWalker. This is also required for cloning inDisplay::fmt.MappedPageTable::range_iterviaMappedPageTable::iterMappedPageRangeInclusive,MappedPageItem, andMappedPageRangeInclusiveItem. This allows iterating over all mappings of a page table.MappedPageTable::displayviaMappedPageRangeInclusiveItem::displayandMappedPageRangeInclusive::display.Alternatively, we could avoid making
PhysOffsetandPageTableWalkerpublic and do everything internally. Having these types available might make implementing such endeavors externally easier, though.Another alternative would be avoiding exposing all of these new types for iterating and instead only providing an opaque type for displaying.
Of course, we could also not upstream step six or seven if this is deemed too opinionated or too much new API.
You can see a draft PR migrating our code iteratively to this upstreaming effort here: hermit-os/kernel#2165
Please let me know what you think.
Thanks as always for your great work! :)
This currently includes #575 for CI.