update from feedback

This commit is contained in:
Mark McCaskey 2019-04-29 11:27:19 -07:00
parent 7e38664fce
commit 4f4473c84e
2 changed files with 19 additions and 4 deletions

View File

@ -11,7 +11,7 @@ See the `wasmer/examples/plugin.rs` file for the source code of the host system.
# Add the target # Add the target
rustup target add wasm32-unknown-wasi rustup target add wasm32-unknown-wasi
# build it # build it
cargo build --release --target=wasm32-unknown-wasi cargo +nightly build --release --target=wasm32-unknown-wasi
# copy it to examples folder # copy it to examples folder
cp ../../target/wasm32-unknown-wasi/release/plugin-for-example.wasm ../ cp ../../target/wasm32-unknown-wasi/release/plugin-for-example.wasm ../
``` ```
@ -24,10 +24,20 @@ cd ..
cargo run --example plugin cargo run --example plugin
``` ```
## Inspecting the plugin
```
# Install wabt via wapm; installed globally with the `g` flag
wapm install -g wabt
# Turn the binary WASM file in to a readable WAT text file
wapm run wasm2wat examples/plugin-for-example.wasm
```
At the top of the file we can see which functions this plugin expects. Most are covered by WASI, but we handle the rest.
## Explanation ## Explanation
In this example, we instantiate a system with an extended (WASI)[wasi] ABI, allowing our program to rely on Wasmer's implementation of the syscalls defined by WASI as well as our own that we made. This allows us to use the full power of an existing ABI, like WASI, and give it super-powers for our specific use case. In this example, we instantiate a system with an extended (WASI)[wasi] ABI, allowing our program to rely on Wasmer's implementation of the syscalls defined by WASI as well as our own that we made. This allows us to use the full power of an existing ABI, like WASI, and give it super-powers for our specific use case.
Because the Rust WASI doesn't support the crate type of `cdylib`, we have to include a main function which we don't use. Because the Rust WASI doesn't support the crate type of `cdylib`, we have to include a main function which we don't use. This is being discussed [here](https://github.com/WebAssembly/WASI/issues/24).
[wasi]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ [wasi]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

View File

@ -2,7 +2,7 @@ use wasmer_runtime::{func, imports, instantiate};
use wasmer_runtime_core::vm::Ctx; use wasmer_runtime_core::vm::Ctx;
use wasmer_wasi::generate_import_object; use wasmer_wasi::generate_import_object;
static PLUGIN_WASM: &'static [u8] = include_bytes!("plugin-for-example.wasm"); static PLUGIN_LOCATION: &'static str = "examples/plugin-for-example.wasm";
fn it_works(_ctx: &mut Ctx) -> i32 { fn it_works(_ctx: &mut Ctx) -> i32 {
println!("Hello from outside WASI"); println!("Hello from outside WASI");
@ -10,6 +10,11 @@ fn it_works(_ctx: &mut Ctx) -> i32 {
} }
fn main() { fn main() {
let wasm_bytes = std::fs::read(PLUGIN_LOCATION).expect(&format!(
"Could not read in WASM plugin at {}",
PLUGIN_LOCATION
));
// WASI imports // WASI imports
let mut base_imports = generate_import_object(vec![], vec![], vec![]); let mut base_imports = generate_import_object(vec![], vec![], vec![]);
// env is the default namespace for extern functions // env is the default namespace for extern functions
@ -20,7 +25,7 @@ fn main() {
}; };
base_imports.extend(custom_imports); base_imports.extend(custom_imports);
let instance = let instance =
instantiate(PLUGIN_WASM, &base_imports).expect("failed to instantiate wasm module"); instantiate(&wasm_bytes[..], &base_imports).expect("failed to instantiate wasm module");
let entry_point = instance.func::<(i32), i32>("plugin_entrypoint").unwrap(); let entry_point = instance.func::<(i32), i32>("plugin_entrypoint").unwrap();
let result = entry_point.call(2).expect("failed to execute plugin"); let result = entry_point.call(2).expect("failed to execute plugin");