Re: [OE-core] [RFC] Improving ext* sparse image generation: migrating from img2simg to ext4sparse for ext* filesystem

[Richard Purdie <richard.purdie@linuxfoundation.org>]

[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5996 bytes --]