New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASI support? #10
Comments
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. |
@Widdershin @PerArneng , There are some technical questions though when we look at the current WASI api definition below: 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? |
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. |
There is a reference implementation of |
Are you referring to the libc APIs descriped here? If so, then yes, WASI libc does contain implementations of all of those functions. |
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. |
add support for AliOS Things (bytecodealliance#34)
supported on Linux now. |
While the issue was more general about WASI, is there plans for support to other hosts like Zephyr? |
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. |
@yiting16, do you have any plan to implement the WASI for Vxworks? |
Agreed, but as I understand it Zephyr includes a filesystem abstraction which could be leveraged! |
@beriberikix thanks for sending this reference! we didn't notice that! we will keep watching it. |
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>.
|
At least it's sometimes useful for nuttx sim. eg. ``` spacetanuki% lldb ./nuttx (lldb) target create "./nuttx" Current executable set to '/Users/yamamoto/git/nuttx/nuttx/nuttx' (x86_64). (lldb) settings set plugin.jit-loader.gdb.enable on (lldb) b foo Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) r Process 37011 launched: '/Users/yamamoto/git/nuttx/nuttx/nuttx' (x86_64) NuttShell (NSH) NuttX-10.4.0 nsh> mount -t hostfs -o fs=/tmp/wasm /mnt nsh> iwasm /mnt/test.aot 1 location added to breakpoint 1 Process 37011 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000105800673 JIT(0x1058002d4)`foo(exenv=0x0000000101284280) at test.c:5 2 3 __attribute__((noinline)) 4 void foo() -> 5 { 6 printf("hello from %s\n", __func__); 7 } 8 Target 0: (nuttx) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000105800673 JIT(0x1058002d4)`foo(exenv=0x0000000101284280) at test.c:5 frame #1: 0x000000010580077a JIT(0x1058002d4)`bar(exenv=0x0000000101284280) at test.c:12:2 frame bytecodealliance#2: 0x000000010580086a JIT(0x1058002d4)`baz(exenv=0x0000000101284280) at test.c:19:2 frame bytecodealliance#3: 0x0000000105800972 JIT(0x1058002d4)`__main_argc_argv(exenv=<unavailable>, argc=<unavailable>, argv=<unavailable>) at test.c:26:3 frame bytecodealliance#4: 0x00000001058061aa JIT(0x1058002d4)`aot_func#14 + 278 frame bytecodealliance#5: 0x00000001058005cd JIT(0x1058002d4)`aot_func#2 + 153 frame bytecodealliance#6: 0x00000001000e250f nuttx`push_args_end at invokeNative_em64.s:61 frame bytecodealliance#7: 0x000000010013851a nuttx`wasm_runtime_invoke_native(exec_env=0x0000000101284280, func_ptr=0x0000000105800534, func_type=0x00000001011e2e20, signature=0x0000000000000000, attachment=0x0000000000000000, argv=0x0000000000000000, argc=0, argv_ret=0x0000000000000000) at wasm_runtime_common.c:4631:9 frame bytecodealliance#8: 0x00000001000da1ae nuttx`aot_call_function(exec_env=0x0000000101284280, function=0x00000001011e1fb0, argc=0, argv=0x0000000000000000) at aot_runtime.c:1654:15 frame bytecodealliance#9: 0x0000000100134b56 nuttx`wasm_runtime_call_wasm(exec_env=0x0000000101284280, function=0x00000001011e1fb0, argc=0, argv=0x0000000000000000) at wasm_runtime_common.c:2048:15 frame bytecodealliance#10: 0x00000001000fbad4 nuttx`execute_main(module_inst=0x00000001011e3890, argc=1, argv=0x00000001011b63f8) at wasm_application.c:112:15 frame bytecodealliance#11: 0x00000001000fb995 nuttx`wasm_application_execute_main(module_inst=0x00000001011e3890, argc=1, argv=0x00000001011b63f8) at wasm_application.c:238:11 frame bytecodealliance#12: 0x00000001000ea1a0 nuttx`app_instance_main(module_inst=0x00000001011e3890) at main.c:113:5 frame bytecodealliance#13: 0x00000001000e9d60 nuttx`iwasm_main(argc=1, argv=0x00000001011b63f8) at main.c:947:21 frame bytecodealliance#14: 0x0000000100023275 nuttx`nxtask_startup(entrypt=(nuttx`iwasm_main at main.c:545), argc=2, argv=0x00000001011b63f0) at task_startup.c:70:8 frame bytecodealliance#15: 0x000000010001065a nuttx`nxtask_start at task_start.c:134:7 frame bytecodealliance#16: 0x000000010003a15f nuttx`pre_start at sim_initialstate.c:52:3 (lldb) ```
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 🙂
The text was updated successfully, but these errors were encountered: