Add --area-offset option for deterministic FRU area layout #18

chnguyen-ampere commented 2026年03月27日 04:07:14 +01:00

I would like to propose a new optional feature for frugen: --area-offset <area>=<offset>[,<area>=<offset>...]

Example: frugen --area-offset chassis=8,board=64,product=256 out.fru

Motivation

This feature would help address a layout stability problem similar to the one discussed in ipmitool issue 309

When a field is modified in one FRU area, the encoded size of that area may change. Because FRU areas are normally packed sequentially, this can shift the offsets of later areas even though their contents were not changed.

This has a few practical downsides:

• Unrelated areas move when only one field is updated
• Workflows that rely on fixed area placement may break
• Binary diffs become noisy
• Validation and manufacturing flows become harder to manage/tunning.

Proposed solution

The new --area-offset option would allow users to fix the absolute byte offset of selected FRU areas in the generated FRU image.

For example: frugen --area-offset chassis=8,board=64,product=256 out.fru

would mean:

• chassis area starts at byte 8
• board area starts at byte 64
• product area starts at byte 256

If there is unused space between the end of one area and the next fixed offset, frugen would automatically fill that gap with zero padding.

If a modified area no longer fits before the next fixed area, frugen should fail with a clear error instead of silently shifting later areas.

Suggested constraints

To keep behavior explicit and safe, I think the following rules would make sense:

• Offsets are absolute byte offsets from the start of the FRU file
• Offsets must be 8-byte aligned
• Offsets must not overlap
• If an area cannot fit before the next fixed area, return an explicit error.

Why this is useful

This would allow users to modify one area without affecting the start offsets of other areas, as long as the modified area still fits within the reserved space.

In practice, this provides:

• Stable offsets for unaffected areas
• More predictable FRU image layout
• Cleaner binary comparisons.
• Easier integration into manufacturing/programming workflows
• Better support for use cases where fixed layout is expected
• A clearer and safer alternative to manually tuning padding

Compatibility

This feature would be fully backward compatible because it is opt-in.
If --area-offset is not used, current behavior remains unchanged.

Summary

I think --area-offset would be a useful addition for users who need deterministic FRU layout and stable area positions across updates, while keeping the default behavior unchanged for everyone else.

Please feel free to comment on my proposal. I would be happy to discuss it further, and I will create a pull request once the proposal is approved.

I would like to propose a new optional feature for frugen: `--area-offset <area>=<offset>[,<area>=<offset>...]` **Example**: `frugen --area-offset chassis=8,board=64,product=256 out.fru` ### Motivation This feature would help address a layout stability problem similar to the one discussed in [ipmitool issue 309](https://github.com/ipmitool/ipmitool/issues/309) When a field is modified in one FRU area, the encoded size of that area may change. Because FRU areas are normally packed sequentially, this can shift the offsets of later areas even though their contents were not changed. This has a few practical downsides: - Unrelated areas move when only one field is updated - Workflows that rely on fixed area placement may break - Binary diffs become noisy - Validation and manufacturing flows become harder to manage/tunning. ### Proposed solution The new `--area-offset` option would allow users to fix the absolute byte offset of selected FRU areas in the generated FRU image. **For example**: `frugen --area-offset chassis=8,board=64,product=256 out.fru` would mean: - chassis area starts at byte 8 - board area starts at byte 64 - product area starts at byte 256 If there is unused space between the end of one area and the next fixed offset, frugen would automatically fill that gap with zero padding. If a modified area no longer fits before the next fixed area, frugen should fail with a clear error instead of silently shifting later areas. ### Suggested constraints To keep behavior explicit and safe, I think the following rules would make sense: - Offsets are absolute byte offsets from the start of the FRU file - Offsets must be 8-byte aligned - Offsets must not overlap - If an area cannot fit before the next fixed area, return an explicit error. ### Why this is useful This would allow users to modify one area without affecting the start offsets of other areas, as long as the modified area still fits within the reserved space. In practice, this provides: - Stable offsets for unaffected areas - More predictable FRU image layout - Cleaner binary comparisons. - Easier integration into manufacturing/programming workflows - Better support for use cases where fixed layout is expected - A clearer and safer alternative to manually tuning padding ### Compatibility **This feature would be fully backward compatible because it is opt-in.** If `--area-offset` is not used, current behavior remains unchanged. ### Summary I think `--area-offset` would be a useful addition for users who need deterministic FRU layout and stable area positions across updates, while keeping the default behavior unchanged for everyone else. Please feel free to comment on my proposal. I would be happy to discuss it further, and I will create a pull request once the proposal is approved.

AlexanderAmelkin commented 2026年03月31日 14:25:58 +02:00

This is an unsderstandable suggestion, although I would prefer that all FRU users would follow the specification and wouldn't rely on static positions of any data. Anyway, it's quite difficult to implement with the current design of libipmi. I promise to think about it, but I don't promise that this will be implemented in any way any time soon.

It must be noted that making area positions static would result in edited area not fitting the old position in some cases, which would result in either denial of modification or a sparse output file with the edited area moved to the very end (which also may not be desirable, especially if one has an infinitely spanning Internal Use Area at the end of their FRU).

What I mean is that there are too many pitfalls on the road of implementation of your suggestion. It's really much safer to never rely on a static FRU layout anywhere.

Also, diffing binaries is not the best idea. It is much better to diff JSON or text outputs from frugen.

Do you have a ready PR for this suggestion? I expect it to be quite a massive modification if done carefully.

This is an unsderstandable suggestion, although I would prefer that all FRU users would follow the specification and wouldn't rely on static positions of any data. Anyway, it's quite difficult to implement with the current design of `libipmi`. I promise to think about it, but I don't promise that this will be implemented in any way any time soon. It must be noted that making area positions static would result in edited area not fitting the old position in some cases, which would result in either denial of modification or a sparse output file with the edited area moved to the very end (which also may not be desirable, especially if one has an infinitely spanning Internal Use Area at the end of their FRU). What I mean is that there are too many pitfalls on the road of implementation of your suggestion. It's really much safer to never rely on a static FRU layout anywhere. Also, diffing binaries is not the best idea. It is much better to diff JSON or text outputs from `frugen`. Do you have a ready PR for this suggestion? I expect it to be quite a massive modification if done carefully.

chnguyen-ampere commented 2026年04月09日 08:41:08 +02:00

Hi @AlexanderAmelkin, I've prepared a patch for this suggestion [frugen: Support specify offset of area] and would appreciate your review. I look forward to your feedback!

Hi @AlexanderAmelkin, I've prepared a patch for this suggestion [frugen: Support specify offset of area] and would appreciate your review. I look forward to your feedback!

AlexanderAmelkin commented 2026年04月09日 19:12:25 +02:00

@nguyenchanh2201, could you please prepare it as a PR here? Home of frugen is on codeberg.org, the version on github is heavily outdated. Also, I'm banned from there and would like to minimize my interaction with github as they are clearly too much into politics and much less into the open-source spirit.

@nguyenchanh2201, could you please prepare it as a PR here? Home of frugen is on codeberg.org, the version on github is heavily outdated. Also, I'm banned from there and would like to minimize my interaction with github as they are clearly too much into politics and much less into the open-source spirit.

chnguyen-ampere commented 2026年04月21日 06:28:36 +02:00

Thank @AlexanderAmelkin , I created a PR at #19

Thank @AlexanderAmelkin , I created a PR at https://codeberg.org/IPMITool/frugen/pulls/19