Various bpak improvements #30
Merged
Conversation
This file contains 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
…_id) combination There is no non-contrived use-case where two parts should have the same id, or two metadata hve same id and same part_ref_id. The code in core bpak_ APIs technically support it, however bpak_pkg for example does not have any sensible way of dealing with multiple parts with same id.
…adata These functions will remove the data from the parts and metadata header tables and remove any holes within the arrays. Also compacts the meta storage array after removing metadata.
Multiple places in the cli takes either a reference by name hashed into a bpak id, or a id specified as a hex number prefixed by 0x. Unify the parsing of these into a separate helper function
To make a clearer API with named types, introduce a bpak_id_t to represent numerical object (metadata / part) IDs. No functional change
The functionality to take a part and extract it binary to a file is useful to other library users, including the python wrapper. Move it from CLI to lib.
Add bpak_pkg_delete_part and bpak_pkg_delete_all_parts to remove one and all parts respectively. The functions can optionally remove all metadata associated with the parts being removed. Also add the equivalent functionality to bpak CLI tool, and a test using the CLI to verify bit-identical result between files with removed parts and files built without ever having the part added.
Probably no real impact, but required for strict conformance.
The offset parameter could theoretically be used for iterating over parts, however bpak_foreach_part provides a better interface. No code within the lib or CLI passed anythign other than NULL.
A number of problems have been identified with the bpak_add_meta and bpak_get_meta APIs. These include: - Not matching the _part APIs in terms of parameter types - Like _part APIs the _meta version had the uneccesary offset parameters, but it did refer to the offset of the metadata _data_ pointer (or offset) not the header. - Using part_ref_id == 0 was in some places an explicitly looked at value and in other places acted as a wildcard, which meant that bpak_get_meta with part_id_ref == 0 could return a meta-data pointer associated with an explicit partition, without any way for the calling code to query or find out that this is the case. The fix for all of these problem is to reduce and simplify the bpak_get_meta API to have a single method that always takes explicit part_ref_id and one that can match any, and then they return a bpak_meta_header instead of the meta-data pointer directly; same with bpak_add_meta. The data pointer can, in a somewhat type-safe way, be retrieved using bpak_get_meta_ptr.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.