WebAssembly System Interface

fleeting

• External reference: https://wasmlabs.dev/articles/docker-without-containers/
• External reference: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

WebAssembly needs a system interface for a conceptual operating system

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

This is what WASI is — a system interface for the WebAssembly platform.

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

need a way to control which programs and users can access which resources.

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

When a program needs to ask the kernel to do one of these things, it asks using a system call

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

only way that your code can access the system’s resources — through system calls

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

operating system makes the system calls available.

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

each operating system has its own system calls

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Most languages provide a standard library. While coding, the programmer doesn’t need to know what system they are targeting. They just use the interface

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

system interface comes in. For example, printf being compiled for a Windows machine could use the Windows API to interact with the machine. If it’s being compiled for Mac or Linux, it will use POSIX instead

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

WebAssembly needs a system interface for a conceptual operating system, not a real operating system

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Emscripten created its own implementation of libc. This implementation was split in two — part was compiled into the WebAssembly module, and the other part was implemented in JS glue code. This JS glue would then call into the browser, which would then talk to the OS.

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

when people started wanting to run WebAssembly without a browser, they started by making Emscripten-compiled code run. So these runtimes needed to create their own implementations for all of these functions that were in the JS glue code.

— https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing.

— https://wasmlabs.dev/articles/docker-without-containers/

WebAssembly as the ‘successor’ to containers and the next logical step in infrastructure deployment

— https://wasmlabs.dev/articles/docker-without-containers/

WebAssembly is as an alternative ‘backend’ for Docker tooling. You can use the same command line tools and workflows, but instead of using Linux containers, it is implemented using WebAssembly-based container equivalents.

— https://wasmlabs.dev/articles/docker-without-containers/

Permalink