Revise Partition in-memory storage mechanism #2564
Merged
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.
This PR makes some changes to the way partition tables are constructed internally.
The changes are intended to make the system more intuitive, flexible, and to pave the way for external disk (SD card) storage interfaces.
Use linked list to store partition tables
Currently the partition table is allocated using a fixed array of
Partition::Info
structures.This means any additional information would cause all partition entries to increase in size.
This has been changed to a linked list so that future extensions can be accommodated.
It also avoids having a fixed limit on the partition table size.
Replace
CustomDevice::createPartition
methods withpartitions().add()
'create' was a poor naming choice as it doesn't write anything to storage, just updates the partition table.
These methods have been removed in favour of operating on the
partitions()
property directly.The default
Device::partitions()
is read-only (const) but it is overridden in custom devices to support writes, etc.Add
Partition::FullType
for better type/subtype handlingPartition types consist of a
type
andsubtype
component, however standard subtypes can be referred to using just the subtype as these are defined using strong enums from which the type can be inferred.When explicitly providing both a type and subtype, this must now be provided as a
FullType
structure,e.g.
{
Storage::Partition::Type::Data, 100}
. This simplifies the API and removes any ambiguity between overloaded method parameters.