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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#230864):
https://lists.openembedded.org/g/openembedded-core/message/230864
Mute This Topic: https://lists.openembedded.org/mt/117715350/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
