Dreamacro：erofs-rs 先统一 workers 命名，CLI 与 composefs 输入另行演进

Dreamacro 认可 erofs-rs 方向，建议用 workers/--workers 与 mkfs.erofs 对齐；composefs-dump/mtree 输入另开议题，CLI 目前主要用于验证库，未来可能拆成 mkfs、fsck、dump；构建依赖待上游合并后回到 crates.io，重视 CLI 与库的可复现构建，先做同步 API。

作者原文@Dreamacro
Thanks for the write-up. The overall direction looks good to me.
One naming suggestion: how about workers instead of threads, e.g. Options::workers(n) / --workers? That's also what mkfs.erofs uses (--workers).
On the manifest input (composefs-dump / mtree): I'd be happy to support a composefs-dump-style input, but I see it as a separate piece of work, so a separate issue makes sense. Also, the current CLI is mostly a playground. It lets us check that the library is pleasant to use and that its features work. When we eventually ship the CLI for real, the subcommands will probably need a redesign, possibly even splitting into the familiar mkfs / fsck / dump style of separate commands. So I wouldn't put much effort into the CLI surface for now.
On your questions:
I don't think anyone else is working there. All of my changes in build/ are already committed. The only pending item is that lz4_flex and miniz_oxide are pinned to git revisions for now. I'll switch them to crates.io releases once my upstream PRs are merged.
Not specifically. That assertion mainly ensures the builder state stays Send, so AsyncBuilder futures can be spawned on multi-threaded runtimes. It should still help here, since encoders and state can already be moved across threads.
Yes, I'd treat reproducible builds as an important property: the same input should always produce the same output, and users should be able to get that through both the CLI and the library. (A counter-example is VHDX. I can't get reproducible builds with Microsoft's APIs short of writing my own VHDX implementation 😆)
Either is fine with me. Go with whichever turns out faster.
Agreed, let's start with sync only and figure out the async story later.
Feel free to go ahead and validate your ideas directly.

返回动态列表查看原文