Status of WASI Core API

[newpavlov]

Initially I've asked this questions relevant to libc here. I am not sure if i should ask them in WebAssembly/WASI repository, so I'll duplicate them here:

• WASI is defined in terms of Core API, but I don't quite understand the part about "wasi_unstable". Does it mean that it's not recommended to link to functions directly like it's done in libc?
• Why Core API is defined in libc instead of a separate crate, like cloudabi or Fuchsia crates? It's a bit strange to use libc for a target which, well, is not defined in terms of libc.

cc @sunfishcode @alexcrichton

[sunfishcode]

WASI is defined in terms of Core API, but I don't quite understand the part about "wasi_unstable". Does it mean that it's not recommended to link to functions directly like it's done in libc?

With "WASI Core" in its current form, most Rust code should continue to use Rust's standard library interfaces for working with files and directories, rather than call into WASI directly. Our goal is to make most of the Rust standard library interfaces for files and directories just work, rather than requiring you to write new code specific to WASI. The Rust standard library and, for people that need it, the libc crate, deal with WASI directly so that you don't have to :-).

Why Core API is defined in libc instead of a separate crate, like cloudabi or Fuchsia crates? It's a bit strange to use libc for a target which, well, is not defined in terms of libc.

The libc crate's WASI module is similar to its fuchsia and cloudabi modules.

If you're wondering why Rust's standard library uses libc for some things rather than always calling WASI directly, it's that WASI libc does more than a typical libc, such as special support for emulating absolute pathnames. Rust's standard library may eventually want to handle this itself, but for now, especially while WASI itself is still evolving, letting the libc handle such things makes it much easier to maintain.

[newpavlov]

In my understanding WASI should not be Rust specific, so defining a platform as "here set of core functions, but actually they link to functions in an unstable module, so existing software can break tomorrow" seems a bit strange. If WASI target right now is intended to be purely experimental, then it's a different deal of course.

My main motivation for those questions comes from work on getrandom. Right now we use libc to call a single function. While for other targets such as CloudABI, Fuchsia and Windows we link to functions directly.

The libc crate's WASI module is similar to its fuchsia and cloudabi modules.

Aren't they link to libc for those platforms? While WASI module links to core platform functions (in a certain sense to syscalls)? For example Fuscia has zx_cprng_draw and CloudABI has cloudabi_sys_random_get, both of which are not represented in libc modules for those targets.

In my opinion it would've been a bit more idiomatic to define Rust interface to WASI Core API in a separate crate (e.g. wasi-core), which will be used by other projects for low-level access to WASI platform.

[sunfishcode]

WASI itself is still evolving. We know that the current wasi_unstable API has fundamental limitations that we need to address. This is why we picked the name wasi_unstable. We're trying to balance the needs of people who want something effectively stable and available in popular tools so they can try it out, and the needs of WASI which desperately needs to keep evolving.

I agree that splitting out a wasi-core crate from the libc crate would be conceptually cleaner, straightforward to do, and we can still do it. I've now reserved wasi-core on crates.io for this purpose. The question is, when should we do this? Is it important to do it now, or can we wait and save ourselves some hassle every time we need to make changes while the API is still evolving?

[newpavlov]

Well, I think it will be easier and faster to change a smaller crate, than changing libc each time WASI API has changed. Plus you will be able to better communicate breaking changes (e.g. on removing of wasi_unstable) by bumping minor version of wasi-core and in future a general stability of Core API by releasing v1.0.

[sunfishcode]

I guess you're right; we'd just need to add wasi-core as a dependency for libstd, but perhaps we can do that.

I've now created https://github.com/CraneStation/wasi-core, which is published here to start experimenting with this. It has both a raw interface and the start of a slightly-more-idiomatic-Rust interface. Feedback welcome!

I should also point out that there's work toward an IDL for WASI, which should eventually let us auto-generate more of this code, rather than maintaining it manually.