* Add definitions of tiers-of-support for Wasmtime
This commit adds documentation of a Tiers-based system for classifying
how supported a component is within Wasmtime. This was somewhat
pioneered in the [Wasmtime 1.0 RFC][rfc] but the documentation here is
expanded to include more than just API stability but additionally other
components. Inspiration for this is drawn from Rust's definition of
[support tiers][rust] as well.
The motivation for this is to help clarify what exactly it means to live
at each tier and what is expected. For example one thing this document
clarifies is the requirements necessary for landing new major changes in
Wasmtime at all. Additionally this helps clarify what it means to have
the highest level of support vs "otherwise well supported".
[rfc]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-one-dot-oh.md#tier-1---api-stable-production-quality
[rust]: https://doc.rust-lang.org/rustc/target-tier-policy.html
* Review comments
* Review comments
* Improve the `wasmtime` crate's README
This commit is me finally getting back to #2688 and improving the README
of the `wasmtime` crate. Currently we have a [pretty drab README][drab]
that doesn't really convey what we want about Wasmtime.
While I was doing this I opted to update the feature list of Wasmtime as
well in the main README (which is mirrored into the crate readme),
namely adding a bullet point for "secure" which I felt was missing
relative to how we think about Wasmtime.
Naturally there's a lot of ways to paint this shed, so feedback is of
course welcome on this! (I'm not the best writer myself)
[drab]: https://crates.io/crates/wasmtime/0.37.0
* Expand the "Fast" bullet a bit more
* Reference the book from the wasmtime crate
* Update more security docs
Also merge the sandboxing security page with the main security page to
avoid the empty security page.
The previous documentation only covers how to enable debug info when
embedding Wasmtime. This change should cover the commonly-asked
question: how do I debug in Wasmtime?
* Start a high-level architecture document for Wasmtime
This commit cleands up some existing documentation by removing a number
of "noop README files" and starting a high-level overview of the
architecture of Wasmtime. I've placed this documentation under the
contributing section of the book since it seems most useful for possible
contributors.
I've surely left some things out in this pass, and am happy to add more!
* Review comments
* More rewording
* typos
Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread.
* Document guidance around multithreading and Wasmtime
This commit writes a page of documentation for the Wasmtime book to
serve as guidance for embedders looking to add multithreading with
Wasmtime support. As always with any safe Rust API this reading is
optional because you can't mis-use Wasmtime without `unsafe`, but I'm
hoping that this documentation can serve as a point of reference for
folks who want to add multithreading but are confused/annoyed that
Wasmtime's types do not implement the `Send` and `Sync` traits.
Closes#793
* I can type
* Add documentation for building programs using AssemblyScript.
* Add the assemblyscript hello world as an example and display it inline.
* Move the AssemblyScript hello world into the docs directory.
That way Cargo doesn't try to run it like a Rust example.
This patch adds initial support for ittapi which is an open
source profiling api for instrumentation and tracing and profiling
of jitted code. Result files can be read by VTune for analysis
Build:
cargo build --features=vtune
Profile: // Using amplxe-cl from VTune
amplxe-cl -v -collect hostpost target/debug/wasmtime --vtune test.wasm
* Add examples of linking and WASI
This commit adds two example programs, one for linking two modules
together and one for instantiating WASI. The linkage example
additionally uses WASI to get some meaningful output at this time.
cc #1272
* Add examples to the book as well
* More links!
* Ignore examples from rustdoc testsing
* More example updates
* More ignored
* Enable jitdump profiling support by default
This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:
* Pass in a list of finished functions instead of just a range to
ensure that we're emitting jit dump data for a specific module rather
than a whole `CodeMemory` which may have other modules.
* Define `ProfilingStrategy` in the `wasmtime` crate to have everything
locally-defined
* Add support to the C API to enable profiling
* Documentation added for profiling with jitdump to the book
* Split out supported/unsupported files in `jitdump.rs` to avoid having
lots of `#[cfg]`.
* Make dependencies optional that are only used for `jitdump`.
* Move initialization up-front to `JitDumpAgent::new()` instead of
deferring it to the first module.
* Pass around `Arc<dyn ProfilingAgent>` instead of
`Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>`
The `jitdump` Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!
* Spice up the project README, fill out more docs
This is an attempt to spruce up wasmtime's README.md file as well as
fill out more of the missing documentation in the `docs/` folder.
There's still a long way to go but I hoped here to mostly move around
existing information and add new information. As always happy to have
feedback!
* Tweak CLI wording
* Remove no-longer relevant clause
* Update sandboxing docs
* Handle comments
The `wasmtime` release procees seems like it's been a bit ad-hoc up to
this point, so I figured it'd be good to try to document what we do
today and codify what should be done as well as a form of release
checklist.
I've noticed that we have a number of releases (like v0.11.0) but the
`Cargo.toml` files in the repository don't reflect the current version
of `wasmtime`. Additionally I've noticed that the [most recent release]
ended up having failed tests because `Cargo.toml` was modified but
`Cargo.lock` wasn't updated. I'm hoping that by having a checklist we
can avoid these sorts of accidental issues in the future!
[release]: https://github.com/bytecodealliance/wasmtime/runs/434690272
This commit adds the skeleton of a new set of documentation for
`wasmtime` in the existing `docs` directory. This documentation is
organized and compiled with [mdbook] which the Rust project uses for
most of its own documentation as well. At a previous meeting we
brainstormed a rough skeleton of what the documentation in this book
would look like, and I've transcribed that here for an example of how
this is rendered and how it can be laid out. No actual documentation is
written yet.
This commit also additionally adds necessary support to auto-publish
both this book documentation and API documentation every time a commit
is pushed to the `master` branch. All HTML will be automatically pushed
to the `gh-pages` branch so long as the CI passes, and this should get
deployed to https://cranestation.github.io/wasmtime.
I've done a few dry-runs and I think this'll all work, but we'll likely
tweak a few things here and there after running this through CI to make
sure everything looks just as we'd like. My hope though is that after
this lands we can start actually filling out all the documentation and
being able to review it as well.
[mdbook]: https://crates.io/crates/mdbook
