-
Notifications
You must be signed in to change notification settings - Fork 197
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
Comments
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. |
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:
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. |
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. |
CloudABI could be a great fit for WebAssembly, indeed. We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9 |
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. |
That sounds good. We will be adapting the Wasmer WebAssembly runtime to support WASI as well. Great work there! |
The initial issue is now addressed. Please feel free to open new issues if there are any further questions or ideas here! |
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.
The text was updated successfully, but these errors were encountered: