-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
wasm: support new WASI interface #31105
Comments
I'm already looking into this. Yes, this is likely to become the GOOS/GOARCH |
https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md this looks like a good list to reference. |
My WIP for WASI can be found here: https://github.com/neelance/go/tree/wasi There is no |
This is a very important thing. Wasmer git repo has it working for golang, python using a rust wasm / wasi engine currently btw. It's fast too. It seems that there is not IDL / RPC standard yet for WASI though. I looked but could not find. If anyone knows would be great. |
@gedw99 you should probably ask on the WASI repo instead. Not sure if WebAssembly/WASI#49 is what you're looking for. Either way WASI is still in active development so it is normal that certain things are lacking. |
It's great to see there's some interest here! How is the progress? I see a recent commit from Dec 26, 2019 and one before that on Mar 29, 2019 in the fork of @neelance. I recently stumbled on https://webassembly.sh, which drops you into a shell where you can execute WebAssembly binaries that were packaged with the WebAssembly Package Manager ( There are small command line programs like So naturally, I'd like to experiment with this new tech and create a WASI-targeting WASM file with Go, upload it to wapm and try it out on webassembly.sh :) |
@philippgille I've updated my fork and just successfully ran a Go program on webassembly.sh. Try |
@neelance can we get a status update on WASI support? What's still missing? Do you need help with anything? Very excited to get this working - combining the portability of WASI with the strength of Go will open up lots of opportunities. 😃 |
Any update on this? |
A reminder that this is open source and there are no ETAs, especially when it comes to external contributions such as Richard's. He hasn't posted any update in this thread since March, so that's the latest update. If you want to be notified of updates, subscribe to the thread. Aside from that, the best way to speed up progress is to check out his work, figure out how it works, and try to improve it. |
Open source doesn't mean there is no ETA. |
@inliquid That is true but I hope that the meaning is reasonably clear. Please be charitable in your understanding of what other people write. Thanks. |
See #38248 for what I was working on. No ETA though. Depends on how much time I get to spend on contributing to the Go project. |
Meaning is clear and it's not correct. At least in a form when someone replies to very reasonable question "this is open source". Open source doesn't mean work is not paid or not compensated in other ways. In most cases it's just one of the business models. So no one should feel like asking for ETA or just a progress is something wrong. |
@inliquid Just to be clear: I am not getting compensated for my work on WebAssembly/WASI in any way. I am not even using it at my day job. I just work on it because I believe it should exist. @icholy The phrasing of your comment is ambiguous, at least to me. |
Hello! 👋 So I noticed that in Go 1.16, Go for OpenBSD is using libc syscalls. I was curious after #38248 is merged, if WASI libc could be used as an easy(-er) way to bring Go to WASI? If not, what's missing from wasi-libc that could make this happen? 🤔 😄 |
This comment has been minimized.
This comment has been minimized.
It would be easier if Go could add support for WASI. We have many users reporting they try to run Go inside Go via WebAssembly, or even running Go in other environments (like Python, PHP, C, Rust and so on) via WebAssembly. Obviously we may be able to implement the Go JS ABI for all those hosts, but (i) there is no garantee that the JS ABI is stable and won't break, (ii) it's time consuming, (iii) it's a JS ABI, so it won't fit in all the other hosts, some stuff are deeply tied to the Web. Thank you for your efforts :-). |
Some TinyGo standard libraries do not support it, so there is still no way to compile golang to WASI at present. |
More of go's standard libraries compile and pass tests with each release of tinygo. |
I wonder if we should avoid focusing on specific interface implementations in the stdlib and instead offer an easy way to support any interface instead. My reasoning:
|
Perhaps a golang.org/x/wasi package would work for now, until the WASI spec
is stable? I feel like relying on outside tooling like witx doesn't fit
with Go's goals here.
…On Thu, 20 Jan 2022, 08:56 Michiel De Backker, ***@***.***> wrote:
I wonder if we should avoid focusing on specific interface implementations
in the stdlib and instead offer an easy way to support any interface
instead. My reasoning:
1. The WASI spec will likely keep evolving
<https://github.com/WebAssembly/WASI/blob/main/docs/Proposals.md>,
forming a moving target. De-coupling its evolution from the mainline
release schedule may be advisable.
2. It gives other runtime providers (embedded, serverless, smart
contracts, neural net and cryptography accelerators, plug-in systems, ...)
an idiomatic way to support their custom system interfaces. This seems like
an integral part of the WebAssembly ecosystem moving forward.
3. By building tooling around the witx
<https://github.com/WebAssembly/WASI/blob/main/docs/witx.md> interface
definition format, the guest interface, including the WASI interface, won't
have to be hand-crafted. It can be generated, E.g.: witx-codegen
<https://github.com/jedisct1/witx-codegen>. For reference: an example
of the WASI interface in witx
<https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/witx/wasi_snapshot_preview1.witx>
.
—
Reply to this email directly, view it on GitHub
<#31105 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHIZZ6BCAYRXC36UFMAMEOTUXAICHANCNFSM4HB6TJAQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I tried to make the argument in the I still believe the investment in witx-based code generation would not be wasted. We can write our own generator in Go if we don't want to rely on another community project. It will support the communities that target different host interfaces and it may support future work on things like module linking. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
I think, instead of supporting WASI, could Golang suport I think that would be the first step to support However, I think #42372 should be solved first, because exporting function is almost mandatory for WASM. |
To subscribers wanting an update on the progress of this, the current blocker is the implementation of this (accepted) proposal: #38248. It's a pretty big change so it will need some coordination from the compiler team to get it over the line, I think. |
Honestly, I don't think #38248 is the current blocker. Instead, #42372 is the real blocker, or both of them. Currently it's already possible to call imported functions: using Of course, the "ABI" is odd, and will not match perfectly with the WASM exported functions. So, yes, that should be also change. However, and for me most important: currently, it's not possible to export one function. So you can't have |
What about upper-case versus lower-case names of functions? Could that
native mechanism be used to map to exported and non-exported functions?
…On Thu, Nov 10, 2022 at 1:40 PM inkeliz ***@***.***> wrote:
Honestly, I don't think #38248 <#38248>
is the current blocker. Instead, #42372
<#42372> is the real blocker, or both
of them.
Currently it's already possible to call imported functions: using
CallImport magic assembly code, you can see that here for instance (
https://github.com/gioui/gio-x/blob/main/explorer/explorer_js.s,
https://github.com/gioui/gio-x/blob/main/explorer/explorer_js.js).
Of course, the "ABI" *is odd*, and will not match perfectly with the WASM
exported functions. So, yes, that should be also change.
However, and for me most important: currently, it's not possible to export
one function. So you can't have func Foo(i int) and the wasm-host (such
as Wasmer) call Foo. The export feature is mandatory for any WASI and
currently that is impossible. There's no equivalent of CallExport or even
//go:export. *TinyGo have such features (and also supports WASI).*
—
Reply to this email directly, view it on GitHub
<#31105 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJMERJMP2PVTARFMT5NZVC3WHU6QPANCNFSM4HB6TJAQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Now is time to send feedback If you hopes WASI support on Go!! |
Closing this in favor of #58141, where we will track the effort to implement the accepted proposal 🎉. |
For who concerns and clicked into this, golang is supporting wasi preview 1 in version 1.21. refer to this: https://tip.golang.org/doc/go1.21 |
Mozilla, Fastly and others have started work on a new standard interface for WASM to interact with system calls, they're calling it WASI, the WebAssembly System Interface.
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
I think we should consider supporting this in the Go WASM architecture, possibly under a new OS (GOOS=WASI).
This issue should track the development of such an effort.
Mozilla have invited interested parties to join the #wasi channel on the Mozilla IRC server (https://wiki.mozilla.org/IRC).
The text was updated successfully, but these errors were encountered: