Thanks Richard Will rework on this approach W.r.t e2fsprogs-ext4sparse , would approach to be singularly in meta-oe
Please feel free to share comments / feedback . I will try to incorporate them - Ashish ________________________________ From: Richard Purdie <[email protected]> Sent: 10 February 2026 14:09 To: AshishKumar Mishra <[email protected]>; [email protected] <[email protected]> Subject: Re: [OE-core] [RFC] Improving ext* sparse image generation: migrating from img2simg to ext4sparse for ext* filesystem You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Caution: "External email, be cautious especially with link(s), attachment(s) or QR code(s)". 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 (#230865): https://lists.openembedded.org/g/openembedded-core/message/230865 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]] -=-=-=-=-=-=-=-=-=-=-=-
