Hi,
On Sun, 2026-02-08 at 22:12 -0800, AshishKumar Mishra via lists.openembedded.org wrote:
Hello Community Members ,
I would like to propose a change to how we handle sparse image generation for ext* file-systems in OpenEmbedded,
specifically moving away from the generic img2simg tool toward the specialised ext2simg in the e2fsprogs [contrib/android]
Firstly, you should probably mention that image_types_sparse is in meta-oe, not oe-core. You should therefore probably mention this on the list where meta-oe is maintained too.
1) Problem
Currently, image_types_sparse.bbclass uses img2simg for all file-system types.
img2simg is a tool that reads the raw image to find zero-filled blocks.
For ext* file-systems, this is inefficient compared to ext2simg from e2fsprogs [contrib/android]
which understands the file-system structure and uses the block bitmap to determine sparse areas.
That seems reasonable.
2) History
Previously, 'ext2simg' was bundled within android-tools (v5.1 and older).
The utility has since migrated to the e2fsprogs project (contrib/android).
However, upstream e2fsprogs does not provide a build system for this tool,
and it requires libsparse from android-tools to compile.
3) Proposed Changes
To implement this, I am looking at a cross-layer approach:
a. meta-oe (android-tools):
Export libsparse, libbase, and liblog headers and libraries to the sysroot. Currently, these are often internal to the build.
Reorganise header installation to ${includedir}/sparse to match the expected include paths for e2fsprogs contrib tools.
b. oe-core (e2fsprogs):
Add a conditional compilation step in e2fsprogs-native to build the ext4sparse utility located in contrib/android/.
This would link against the exported libsparse from android-tools-native.
c. meta-oe (image_types_sparse.bbclass):
Update CONVERSION_CMD:sparse to detect ext* types.
Use ext2simg from the e2fsprogs [contrib/android] for these types while falling back to img2simg for others (like f2fs).
4) Points for Discussion / Feasibility
I am seeking feedback on the following:
a. Layer Dependency:
This introduces a tighter coupling between oe-core and meta-oe.
Is it acceptable for e2fsprogs-native (core) to optionally depend on android-tools-native (meta-oe),
or i can create an bbapend file in meta-oe called e2fsprogs_%.bbappend.
oe-core cannot depend on meta-oe.
The bbappend is one approach but it means e2fsprogs would rebuild whenever a layer is added/removed and it would likely fail the yocto-check-layer tests. It would also mean anything depending on e2fsprogs would also rebuild and sstate would not be reused. None of this is particularly good.
Instead, how about a separate recipe, e2fsprogs-ext4sparse which just builds this utility?
Cheers,
Richard