bytecodealliance / bytecodealliance/cap-std

Archiving cap-std

Open
#426 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
821
Forks
57
Avg merge
1h 16m
Merged PRs (30d)
4

Description

cap-std was originally built for the purpose of implementing the original vision for wasi-filesystem, for Wasmtime. Since it was first launched, we've learned several lessons.

One of the big ones was that the whole preopens design in wasi-filesystem and the `RESOLVE_BENEATH` filesystem semantics, that cap-std implements, and that were inspired by CloudABI and Fuchsia, have not turned out to be worthwhile for wasi-filesystem. They're too different from the kinds of filesystem APIs that the vast majority of developers and existing code are expecting. And at the same time, they're not different enough to deliver sufficiently compelling advantages for WASI's use cases. I believe there is now broad consensus to migrating wasi-filesystem to a different style of filesystem semantics. There are still some open questions about exactly how that will work, but in any case, I expect there will be a need to change the implementation code in a way that wouldn't make sense for cap-std as we currently know it.

Also, maintaining cap-std as an independent library has turned out to make the code more complex to maintain, because it has meant that wasi-filesystem semantics were awkwardly split, with part being handled by code in Wasmtime and part by code in cap-std.

And, just having two repositories instead of one made things like security updates more complex, because we have to release cap-std packages separately from Wasmtime packages.

So, the plan is to vendor the parts of cap-std's code that Wasmtime needs into the Wasmtime tree directly, no longer published as an independent library. With that, the Bytecode Alliance doesn't have a need for maintaining the independent cap-std repository anymore, so I'm considering marking the repository as archived.

But before I make any changes, I'm happy to answer any questions or concerns anyone might have here.

Contributor guide

Open the contributing guide

Research direction

No files, tests, or entry points are named, and the issue asks for questions or concerns rather than a defined implementation task. Read the migration and archiving plan first; completion is not specified for an independent contribution.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
operating-systems, security
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.