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

Consider CloudABI as the basis for the native API #178

Closed
lain-dono opened this issue Nov 1, 2018 · 7 comments
Closed

Consider CloudABI as the basis for the native API #178

lain-dono opened this issue Nov 1, 2018 · 7 comments

Comments

@lain-dono
Copy link

https://github.com/NuxiNL/cloudabi

I think that for most applications, this API (or similar) is sufficient. It was originally created to run native applications obtained from untrusted sources.

@sunfishcode
Copy link
Member

I like this idea. And I think it highlights the fact that there won't be one set of syscalls which will apply to all use cases. Some use cases will want to use a restricted set, such as CloudABI, while others won't want to be restricted.

@sunfishcode
Copy link
Member

I've been thinking about this more, and CloudABI seems like it could be a really nice fit. I'm envisioning a set of APIs layered like this:

  • basic argv/argc/etc.
  • CloudABI level
  • greater Posix API level

CloudABI fits in nicely with WebAssembly's sandboxing story; we could think of it as conceptually extending the sandbox to the syscall layer.

And then, for use cases which want more complete networking/filesystem/etc. support, we can add extra functions beyond that. There will be details to explore, but this general approach seems to have a lot of potential.

@lachlansneff
Copy link

I've been thinking about this as well. CloudABI's main issue is the need to specify files and sockets that it can open/access in a configuration file, which can be quite restricting (and also would completely kill any attempts to port language interpreters to wasm).

I foresee an API similar to POSIX that's designed to be run in lightweight containers or with whitelisted resources so that sandboxing is separate from the design of the API. And then go for an API similar to CloudABI if people would find it useful.

I think layering of APIs over time is a good idea though. We should attempt to get down the basic apis that don't really change much in use-case, like arguments and environment variables as soon as possible.

A CloudABI based system interface has a lot of progress, but I'm not sure it should be the first standardized api.

@syrusakbary
Copy link

CloudABI could be a great fit for WebAssembly, indeed.

We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9
Might be useful for anyone looking to get deeper context on the field 😊

@sunfishcode
Copy link
Member

sunfishcode commented Mar 27, 2019

I've been investigating CloudABI as I mentioned above. CloudABI has a lot to offer, but isn't quite the right shape for WebAssembly. I also investigated the "PWSIX" concept (for background on that term, see Mozilla's blog post here), we found there are significant parts of POSIX that don't fit well on WebAssembly, and so we believe that WASI, which takes much inspiration from those systems, but is also tailored to WebAssembly's unique needs, is the best way forward.

@syrusakbary
Copy link

syrusakbary commented Mar 27, 2019

That sounds good. We will be adapting the Wasmer WebAssembly runtime to support WASI as well.

Great work there!

@sunfishcode
Copy link
Member

The initial issue is now addressed. Please feel free to open new issues if there are any further questions or ideas here!

@sunfishcode sunfishcode transferred this issue from WebAssembly/wasi-libc-old Mar 3, 2020
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

No branches or pull requests

4 participants