Conversation
Import ext4-view-rs as a vendored subtree under gibblox/ext4-view-rs. git-subtree-dir: gibblox/ext4-view-rs git-subtree-split: 7b9cc2d364e9df362c929bdbb362e7bd2dd80659 Signed-off-by: Sam Day <me@samcday.com> Assisted-by: opencode:gpt-5.3-codex
Add an async read trait and Ext4::load_async bridge so ext4-view can be used by async-first gibblox pipelines while preserving the existing synchronous parser internals. Signed-off-by: Sam Day <me@samcday.com> Assisted-by: opencode:gpt-5.3-codex
Introduce gibblox-ext4 with an async Ext4Fs wrapper over BlockReader plus Ext4FileBlockReader for composing reads of files inside ext4 images through the gibblox pipeline. Signed-off-by: Sam Day <me@samcday.com> Assisted-by: opencode:gpt-5.3-codex
Add fastboop-rootfs-ext4, a RootfsProvider backed by the async-friendly gibblox-ext4 API, and register it in the workspace. Signed-off-by: Sam Day <me@samcday.com> Assisted-by: opencode:gpt-5.3-codex
Wire CLI stage0 and boot flows to try EROFS first and fall back to ext4 providers, so stage0 generation works from either rootfs format without changing fastboop-stage0-generator semantics. Signed-off-by: Sam Day <me@samcday.com> Assisted-by: opencode:gpt-5.3-codex
|
@codex gaze upon your exploits. provide critique. compose a short haiku that captures the essence of our v i b e sssss |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da59770f84
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let mut scratch = vec![0u8; aligned_len]; | ||
| let mut filled = 0usize; | ||
| while filled < scratch.len() { | ||
| let lba = (aligned_start as usize + filled) / self.block_size; |
There was a problem hiding this comment.
Casting aligned_start to usize before computing lba can truncate offsets on 32-bit targets (including wasm32), so reads beyond 4 GiB can wrap and fetch the wrong blocks. In that scenario, ext4 metadata/data reads become corrupted even though the source image is valid, which can break stage0 generation for larger rootfs images. Keep this arithmetic in u64 until the final read_blocks call to avoid architecture-dependent truncation.
Useful? React with 👍 / 👎.
1 participant
No description provided.