2
2
Fork
You've already forked frugen
2

frugen: Support specify offset of area #19

Open
chnguyen-ampere wants to merge 1 commit from chnguyen-ampere/frugen:master_upstream_specify_fru_area_offset into master
pull from: chnguyen-ampere/frugen:master_upstream_specify_fru_area_offset
merge into: IPMITool:master
IPMITool:master
IPMITool:feature/add-psu-mr
IPMITool:pages
IPMITool:bugfix/refactor-area-sorting
IPMITool:feature/version-3.0-test
First-time contributor
Copy link

Specify absolute byte offsets for each area in the FRU file, and the library should
automatically calculate padding to fill the gap between the specified offset and the
actual data size.

Padding automatically fills the gap between actual data and the next offset.

Example: using the new --area-offset option

  1. General

frugen -j example.json
--area-offset chassis=0x08,board=0x40,product=0x100,multirecord=0x200
out.fru

  1. Chassis real data is ~20 bytes, but you try to cram it into 8 bytes
    before board at 16.

frugen -j example.json --area-offset chassis=8,board=16 out.fru

=> ERROR: Area data exceeds available space before next offset

Signed-off-by: Chanh Nguyen chanh@os.amperecomputing.com

Specify absolute byte offsets for each area in the FRU file, and the library should automatically calculate padding to fill the gap between the specified offset and the actual data size. Padding automatically fills the gap between actual data and the next offset. Example: using the new --area-offset option 1. General frugen -j example.json \ --area-offset chassis=0x08,board=0x40,product=0x100,multirecord=0x200 \ out.fru 2. Chassis real data is ~20 bytes, but you try to cram it into 8 bytes before board at 16. frugen -j example.json --area-offset chassis=8,board=16 out.fru => ERROR: Area data exceeds available space before next offset Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
Specify absolute byte offsets for each area in the FRU file, and the library should
automatically calculate padding to fill the gap between the specified offset and the
actual data size.
Padding automatically fills the gap between actual data and the next offset.
Example: using the new --area-offset option
1. General
frugen -j example.json \
 --area-offset chassis=0x08,board=0x40,product=0x100,multirecord=0x200 \
 out.fru
2. Chassis real data is ~20 bytes, but you try to cram it into 8 bytes
before board at 16.
frugen -j example.json --area-offset chassis=8,board=16 out.fru
=> ERROR: Area data exceeds available space before next offset
Signed-off-by: Chanh Nguyen <chanh@os.amperecomputing.com>
@ -598,6 +598,13 @@ typedef struct {
* order, please prefer using
* fru_move_area().
*/
size_t area_offset[FRU_TOTAL_AREAS]; /**< Fixed absolute byte offset for each area.

This must be off_t, not size_t

This must be `off_t`, not `size_t`
@ -601,0 +604,4 @@
* The gap between the current output position
* and this offset is filled with zero bytes.
* 0 means no fixed offset (automatic layout).
*/

Areas can't start at arbitrary byte-aligned addresses, they must be 8-byte (FRU_BLOCK_SZ) aligned.
I guess, offset in blocks would make more sense here or else you'd need to add a fru_error_code_t value for the bad alignment case or otherwise handle it somehow.

Areas can't start at arbitrary byte-aligned addresses, they must be 8-byte (`FRU_BLOCK_SZ`) aligned. I guess, offset in blocks would make more sense here or else you'd need to add a `fru_error_code_t` value for the bad alignment case or otherwise handle it somehow.
@ -556,0 +570,4 @@
size_t area_sizes[FRU_TOTAL_AREAS] = { 0 };
size_t hdr_size = sizeof(fru__file_t);
bool (* encode_area[FRU_TOTAL_AREAS])(void *, size_t *,

Honestly, I didn't read deep into this chunk, but it looks to me like it can be optimized to save the third call to the area encoders. They are already called twice for a save. Please think about it.

Honestly, I didn't read deep into this chunk, but it looks to me like it can be optimized to save the third call to the area encoders. They are already called twice for a save. Please think about it.

Also, please take in account that #15 is in active development and it will change the code heavily when finished. So, I'm not going to merge this before #15 is done to save myself the hassle of rebasing everything in there over your changes. Hence, you may want to delay addressing my review comments until #15 is merged.

Also, please take in account that #15 is in active development and it will change the code heavily when finished. So, I'm not going to merge this before #15 is done to save myself the hassle of rebasing everything in there over your changes. Hence, you may want to delay addressing my review comments until #15 is merged.
This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u master_upstream_specify_fru_area_offset:chnguyen-ampere-master_upstream_specify_fru_area_offset
git switch chnguyen-ampere-master_upstream_specify_fru_area_offset
Sign in to join this conversation.
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
IPMITool/frugen!19
Reference in a new issue
IPMITool/frugen
No description provided.
Delete branch "chnguyen-ampere/frugen:master_upstream_specify_fru_area_offset"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?