From c5edb60b9b9100e2020295e53a632fa1a9f785aa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Franke?= Date: Sun, 29 Sep 2024 20:24:48 +0200 Subject: [PATCH] feat: change target wasm32-wasi to wasm32-wasip1 --- .github/workflows/build.yml | 6 +++--- README.md | 10 +++++----- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index a497f18..3591619 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -26,7 +26,7 @@ jobs: mkdir -p $CARGO_HOME curl https://sh.rustup.rs -sSf | sh -s -- -y rustup install $RUSTUP_TOOLCHAIN - rustup target add wasm32-wasi --toolchain $RUSTUP_TOOLCHAIN + rustup target add wasm32-wasip1 --toolchain $RUSTUP_TOOLCHAIN rustup target add wasm32-unknown-unknown --toolchain $RUSTUP_TOOLCHAIN - name: Configure Rust and display version run: | @@ -36,10 +36,10 @@ jobs: - name: Build Rust Wasm Study run: | cd wasm-module1 - cargo build --release --target wasm32-wasi + cargo build --release --target wasm32-wasip1 cd .. cd wasm-module2 - cargo build --release --target wasm32-wasi + cargo build --release --target wasm32-wasip1 cd .. cd wasm-app cargo build --release \ No newline at end of file diff --git a/README.md b/README.md index e1d3a5a..e592539 100644 --- a/README.md +++ b/README.md @@ -75,7 +75,7 @@ The study here is a very simple application written in Rust that loads dynamical * [wasm-module2](./wasm-module2/) - an example module that has a functions with two parameters: a pointer to serialized data in Arrow IPC format and the size of the serializeed data. Return is a pointer n the WASM module memory to the processed serialized data by the function in Arrow IPC format and the size of the serialized data. We can implement in Arrow mandatory attributes of a document (e.g. id etc.) and also more flexible dictionaries by having an Array of the struct(key,value), e.g. [{key: "category",value:"news"}] -We compile in Rust the module to the target "wasm32-wasi" (see [here](https://doc.rust-lang.org/stable/nightly-rustc/rustc_target/spec/wasm32_wasi/index.html)). +We compile in Rust the module to the target "wasm32-wasip1" (see [here](https://dev-doc.rust-lang.org/stable/rustc/platform-support/wasm32-wasip1.html)). Note: We also link the WASI modules dynamically into the module. However, WASI is still experimental and standardization not finalized. We could also circumwent the use of WASI (e.g. by not relying on std etc.), but since WASI will anyway be needed for the use case of ZuSearch (e.g. file, network accesss as well as corresponding permissions) we included it also in the study. @@ -116,14 +116,14 @@ The concept works for the exchange of Arrow serialized data similarly. In this c # Build and run You can build the modules by executing the following command in their folder: ``` -cargo build --release --target wasm32-wasi +cargo build --release --target wasm32-wasip1 ``` The reason for building a release is that otherwise the module2 containing a wasi runtime and the Arrow library becomes very large and loading it in the application takes ages. You can build the application by running the following command: ``` -cargo build +cargo build ``` You can then run the application by executing target/debug/wasm-app @@ -133,8 +133,8 @@ Note: The application itself is not compiled to WASM. This is at the moment not # Observations -* The application cannot be compiled to wasm32-wasi yet (although desired for the future to leverage WASM also in the ZuSearch core), because wasmtime or more specifically WASI does not seem to support this yet. -* The modules can be compiled to wasm32-wasi and loaded by the application. +* The application cannot be compiled to wasm32-wasip1 yet (although desired for the future to leverage WASM also in the ZuSearch core), because wasmtime or more specifically WASI does not seem to support this yet. +* The modules can be compiled to wasm32-wasip1 and loaded by the application. * We use cdylib annoation to create the WASM, but cdylib itself is not needed - this is needed because the WASM Interface Type (WIT), ie the WASM component model is not yet fully specified and implemented * Including the wasmtime runtime in the application leads to a larger single binary (ca. 14 MB wasmtime 0.38.1 compiled as release). While the size is not very large, it limits the type of embedded device where to deploy it. However, the use case of ZuSearch also does not justify to embed it on any device (e.g. Arduino would be out of scope). * While there is a WASM Component Example (cf. [here](https://github.com/radu-matei/wasm-components-example)) - it only describes static linking at compile time and it is unclear yet if this works at runtime as well. As mentioned, for our use case probably exchanging data via Arrow is the better choice in any case and we can do it already now.