board: add multi-storage board model with composition - #163
Open
Igor Opaniuk (igoropaniuk) wants to merge 5 commits into
Open
board: add multi-storage board model with composition#163Igor Opaniuk (igoropaniuk) wants to merge 5 commits into
Igor Opaniuk (igoropaniuk) wants to merge 5 commits into
Conversation
Introduce the board format from [1]: a board declares a platform and a list of storage devices, each with partitions. board.py resolves the three composition mechanisms into a ResolvedBoard - board-level `extends:` (inherit one base board, override by storage id / partition name), storage-level `includes:` (concatenate shared _common fragments, transitively), and variant overlays (--hlos / --boot-fw) applied last. Merges are deep and field-by-field, matched by stable identifier, with unmatched entries appended in file order; resolution order is base board -> derived board -> storage includes -> variant overlays. There is no partition deletion in v1. Cycles in extends or includes are rejected. Input files are validated structurally against board.schema.json (and include.schema.json for fragments), which stay permissive because overrides are partial. Each fully-resolved storage is then validated strictly against the existing partitions.schema.json and reduced to a LoadedSpec through the same normalisation helpers the YAML loader uses, so a resolved board emits XML byte-identical to an equivalent hand-written single-storage file. [1] qualcomm-linux#124 Signed-off-by: Igor Opaniuk <[email protected]>
Pin the composition contract: extends inheritance with field-by-field overrides and appends, storage includes with transitivity, variant overlays applied last (overriding an included partition in place and appending new ones), the deterministic partition ordering, cycle rejection for both extends and includes, strict validation of the resolved storage, and a byte-identical-XML check against the equivalent single-storage YAML. Signed-off-by: Igor Opaniuk <[email protected]>
Extend the CLI with --board / --hlos / --boot-fw (and --root) so a whole board resolves and emits one partitions.xml per storage, in declared order, from a single invocation. Outputs are given as one -o per storage; a count mismatch is reported with the storage ids. The board resolver is imported lazily so the legacy -i single-storage path never pulls in PyYAML or jsonschema, and that path is unchanged. Signed-off-by: Igor Opaniuk <[email protected]>
Derived boards and heavy includes make the effective layout impossible to read from one file. `qcom-ptool show --board <f> [--hlos ..] [--boot-fw ..]` resolves the full composition chain and prints the result as YAML, so reviewers can see exactly what will be emitted without chasing extends/includes by hand. Signed-off-by: Igor Opaniuk <[email protected]>
Assert that --board emits one XML per storage in order, that an output count mismatch fails, that exactly one source (-i or --board) is required, that the legacy single-storage path still works, and that show prints the resolved spec with variant overlays applied. Signed-off-by: Igor Opaniuk <[email protected]>
Igor Opaniuk (igoropaniuk)
requested review from
Dmitry Baryshkov (lumag),
Nicolas Dechesne (ndechesne) and
Viswanath Kraleti (vkraleti)
as code owners
August 25, 2026 09:19
Viswanath Kraleti (vkraleti)
approved these changes
Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Third step of the partition-source rework [1]: a board file that declares a platform with multiple storages, and the composition layer on top of it.
The per-(board, storage) directory convention cannot say "this board has these two storages", cannot share common partition groups except by copy-paste, and cannot express variants (Debian vs QLI rootfs, boot-firmware versions) at all - adding a variant today means duplicating a directory and editing it by hand.
board.pyresolves a board file through three mechanisms, applied in a fixed order: board-levelextends:inherits a single base board; storage-levelincludes:concatenates shared partition fragments;--hlos/--boot-fwoverlays apply last.Merges are deep and field-by-field, matched by stable identifier (storage id, partition name); unmatched entries append in file order, and same-name overrides merge in place so partition order - which determines GPT offsets - stays deterministic. Each resolved storage is validated against the strict schema from [2] and reduced to the same
LoadedSpec, so a resolved board emits byte-identical XML to the equivalent hand-written file. gen_partition--boardemits onepartitions.xmlper storage; qcom-ptool show--boardprints the fully-resolved layout so reviewers never have to chase the composition chain by hand.[1] #124
[2] #155