[GSoC 2026][Discussion] mkfs.erofs: manifest-based filesystem generation support

[Shailesh Kumar]

Hello,

I am Shailesh Kumar, a CSE student preparing a GSoC 2026 proposal for
erofs-utils.

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.

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.

The idea is to introduce a new --manifest option, where:
- manifest files describe the filesystem tree (paths, metadata, file types)
- file contents are resolved using a separate data directory (--data-dir)
- parsed entries are converted into erofs_inode structures
- the existing layout and write pipeline (lib/compress.c, lib/super.c)
remains unchanged

A simplified flow would be:

    manifest file → parser → manifest entries → inode construction →
existing pipeline → image

I plan to:
- add a manifest parsing layer (lib/manifest.c)
- implement parsers for composefs-dump and BSD mtree formats
- reuse existing inode construction logic instead of stat()-based directory
scanning

Before finalizing the design, I wanted to confirm a few points:

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?

2. For composefs-dump, is resolving file data via --data-dir/<digest> an
acceptable approach?

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?

4. Are there preferred conventions or locations for adding new mkfs.erofs
tests?

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.

Thanks for your time.

Best regards,
Shailesh Kumar
GitHub: https://github.com/SKM2227229725
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20260321/387245ea/attachment.htm>