Skip to content
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 for Webassembly #3005

Closed
dnsco opened this issue Sep 22, 2019 · 7 comments · Fixed by #6441
Closed

WASI support for Webassembly #3005

dnsco opened this issue Sep 22, 2019 · 7 comments · Fixed by #6441

Comments

@dnsco
Copy link

dnsco commented Sep 22, 2019

I'd love to be able to use Deno as the glue for a bunch of backend wasm modules. The wasi interfaces is a systems interface for webassembly in non-web uses.

https://github.com/CraneStation/wasmtime is a wasi-implementing wasm runtime in rust, though It has a different sandboxing model than v8's.

I've seen WASI support mentioned in a few other issues, so I wanted to centralize that part of the discussion.

related: #2552 #672 #1325

@kitsonk
Copy link
Contributor

kitsonk commented Sep 22, 2019

Yes, agreed, though WASI is still real early in its development. I think we would want to keep it quite experimental in Deno, even Deno being experimental, as I suspect there will be a lot of churn. We might also want to consider getting involved in the working group as well.

@syrusakbary
Copy link

We will release soon a TypeScript package to run WASI modules very easily both in server-side and client-side. Perhaps Deno can be a great use case for integrating it!

Apart from this, the Wasmer runtime can also embedded easily in Rust. However it might make more sense to use v8 with a wrapper on top to be able to run WASI.

Either way, I'd love to help in any way!

@syrusakbary
Copy link

And here we go!

Here's the @wasmer/wasi package: https://github.com/wasmerio/wasmer-js/tree/master/packages/wasi (npm package)

The announcement is here: https://medium.com/wasmer/wasmer-js-9a53e837b80

Hope you can find it useful!!

@rsp
Copy link
Contributor

rsp commented Jan 20, 2020

Node already has an experimental WASI support in v13:

It may be useful to see how it is implemented and used. Example:

const wasi = new WASI({
  args: process.argv,
  env: process.env,
  preopens: {
    '/sandbox': '/some/real/path/that/wasm/can/access'
  }
});

@caspervonb
Copy link
Contributor

caspervonb commented May 22, 2020

Published https://deno.land/x/wasi yesterday, it is still a work in progress as not every syscall can be mapped efficiently at the moment, for example:

But everything should be implementable as plain modules as Deno matures to have a set of sound syscalls.

@caspervonb
Copy link
Contributor

caspervonb commented Jun 22, 2020

A little while later (exactly one month of work to be precise); the current implementation status of snapshot_preview1 looks something like this

Name Status Notes
args_get
args_sizes_get
environ_get
environ_sizes_get
clock_res_get
clock_time_get
fd_advise This has no obvious path to implementation at this time.
fd_allocate This has no obvious path to implementation at this time.
fd_close
fd_datasync This is blocking on getting fdatasync(2) implemented upstream in Deno.
fd_fdstat_get This currently does not write flags and rights as we do not track those at the moment.
fd_fdstat_set_flags This has no obvious path to implementation at this time.
fd_fdstat_set_rights
fd_filestat_get This is blocking on getting fstat implemented upstream in Deno.
fd_filestat_set_size This is blocking on getting ftruncate implemented upstream in Deno.
fd_filestat_set_times
fd_pread
fd_prestat_get
fd_prestat_dir_name
fd_pwrite
fd_read
fd_readdir
fd_renumber
fd_seek
fd_sync This is blocking on getting fsync(2) implemented upstream in Deno.
fd_tell
fd_write
path_create_directory
path_filestat_get
path_filestat_set_times
path_link
path_open Opening directories is not portable
path_readlink
path_remove_directory
path_rename
path_symlink
path_unlink_file
poll_oneoff
proc_exit
proc_raise
sched_yield
random_get
sock_recv
sock_send
sock_shutdown

Most of these blockers are in master already so will be working moving this into std soon.

@banocean
Copy link

A little while later (exactly one month of work to be precise); the current implementation status of snapshot_preview1 looks something like this
Name Status Notes
args_get
args_sizes_get
environ_get
environ_sizes_get
clock_res_get
clock_time_get
fd_advise This has no obvious path to implementation at this time.
fd_allocate This has no obvious path to implementation at this time.
fd_close
fd_datasync This is blocking on getting fdatasync(2) implemented upstream in Deno.
fd_fdstat_get ✓ This currently does not write flags and rights as we do not track those at the moment.
fd_fdstat_set_flags This has no obvious path to implementation at this time.
fd_fdstat_set_rights
fd_filestat_get This is blocking on getting fstat implemented upstream in Deno.
fd_filestat_set_size This is blocking on getting ftruncate implemented upstream in Deno.
fd_filestat_set_times
fd_pread
fd_prestat_get
fd_prestat_dir_name
fd_pwrite
fd_read
fd_readdir
fd_renumber
fd_seek
fd_sync ✓ This is blocking on getting fsync(2) implemented upstream in Deno.
fd_tell
fd_write
path_create_directory
path_filestat_get
path_filestat_set_times
path_link
path_open ✓ Opening directories is not portable
path_readlink
path_remove_directory
path_rename
path_symlink
path_unlink_file
poll_oneoff
proc_exit
proc_raise
sched_yield
random_get
sock_recv
sock_send
sock_shutdown

Most of these blockers are in master already so will be working moving this into std soon.

There us wasi preview 2 rn and it covers a more of apis

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants