<div dir="ltr">Hello,<br><br>I am Shailesh Kumar, a CSE student preparing a GSoC 2026 proposal for erofs-utils.<br><br>I have been going through the mkfs.erofs codebase, particularly mkfs/main.c, lib/inode.c, and the current directory/tar input pipeline, to understand how inodes are constructed and passed to the layout and write stages.<br><br>My proposal is to add support for generating EROFS images from manifest files (composefs-dump and BSD mtree), instead of relying only on source directories or tarballs.<br><br>The idea is to introduce a new --manifest option, where:<br>- manifest files describe the filesystem tree (paths, metadata, file types)<br>- file contents are resolved using a separate data directory (--data-dir)<br>- parsed entries are converted into erofs_inode structures<br>- the existing layout and write pipeline (lib/compress.c, lib/super.c) remains unchanged<br><br>A simplified flow would be:<br><br>    manifest file → parser → manifest entries → inode construction → existing pipeline → image<br><br>I plan to:<br>- add a manifest parsing layer (lib/manifest.c)<br>- implement parsers for composefs-dump and BSD mtree formats<br>- reuse existing inode construction logic instead of stat()-based directory scanning<br><br>Before finalizing the design, I wanted to confirm a few points:<br><br>1. Is introducing a separate manifest parsing layer (lib/manifest.c) aligned with the current structure, or would integration into existing inode paths be preferred?<br><br>2. For composefs-dump, is resolving file data via --data-dir/<digest> an acceptable approach?<br><br>3. For BSD mtree, is it reasonable to start with a common subset of keywords (type, uid, gid, mode, size, link, device) and expand later if needed?<br><br>4. Are there preferred conventions or locations for adding new mkfs.erofs tests?<br><br>I would really appreciate any feedback on whether this approach aligns with the project expectations, or if there are specific constraints I should consider before implementation.<br><br>Thanks for your time.<br><br>Best regards,  <br>Shailesh Kumar  <br>GitHub: <a href="https://github.com/SKM2227229725">https://github.com/SKM2227229725</a></div>