WASI support?

[Widdershin]

Hi 👋

Excellent initiative, great to see more Wasm runtimes from experienced vendors.

I was hoping to find out what your feelings/plans are around supporting WASI, Mozilla’s proposed systems interface for Wasm applications.

Thanks again for this project 🙂

[PerArneng]

Agree. Its very important that standards are created at this time. If you build standards great things happen. Wasm itself is proof of that. Wasi is a good idea and its important that more organisations get behind it.

[xwang98]

@Widdershin @PerArneng ,
Thanks for bringing the WASI to us. We are interested in WASI and agree that it is important for enabling cross platforms support for wasm applications.

There are some technical questions though when we look at the current WASI api definition below:
https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md

It looks the definitions are more targeting file IO for the desktop and server platforms, not for embedded systems. For example, in an embedded controller usually there is no file system.

Maybe we can defined a profile of WASI for embedded environment?

[lukewagner]

One of the goals of WASi (described here) is to be modular, with APIs grouped into discrete modules so that a host environment can implement only the modules that make sense on that host. It's still very early in WASI's development, but I think it's likely that the WASI core will be partitioned so that file IO would be in a separate module that embedded environments could choose not to implement.

[beriberikix]

There is a reference implementation of wasi-libc. I believe it could replace the current subset implementation, based on the methods in common. That might be all that's needed to support WASI. @sunfishcode?

[sunfishcode]

Are you referring to the libc APIs descriped here? If so, then yes, WASI libc does contain implementations of all of those functions.

[Kevin0626]

This project is required to work within 300K memory budget, including the memory used for holding runtime binary. So the footprint and memory usage is a high priority design goal. To save the memory for holding those libc functions, we just selected to export the native string functions to WASM application rather than compiling them into the WASM bytecode.

@sunfishcode Hi Dan, we are working together with Josh. Maybe we can schedule a meeting for sharing the projects and discussing how to collaborate on WASI standard.

[xwang98]

supported on Linux now.

[beriberikix]

While the issue was more general about WASI, is there plans for support to other hosts like Zephyr?

[xwang98]

The problem for WASI support on Zephyr is that embedded OS like Zephyr doesn't have standard file IO implementation. It is usually project based decision on what fs middleware to be used.

[xwang98]

@yiting16, do you have any plan to implement the WASI for Vxworks?

[beriberikix]

Agreed, but as I understand it Zephyr includes a filesystem abstraction which could be leveraged!

[xwang98]

@beriberikix thanks for sending this reference! we didn't notice that! we will keep watching it.

[yiting16]

We are investigating WASI, no concrete plan at this point. From: Wang Xin <notifications@github.com> Sent: 2019年11月28日 8:49 To: bytecodealliance/wasm-micro-runtime <wasm-micro-runtime@noreply.github.com> Cc: Wang, Yiting <Yiting.Wang@windriver.com>; Mention <mention@noreply.github.com> Subject: Re: [bytecodealliance/wasm-micro-runtime] WASI support? (#10) @yiting16<https://github.com/yiting16>, do you have any plan to implement the WASI for Vxworks? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AKUINZ6NIWBMZJIVNIMWRR3QV4IOXA5CNFSM4HMCY54KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLDRYY#issuecomment-559298787>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKUINZ67SNJNXGUNBVTK4M3QV4IOXANCNFSM4HMCY54A>.