3 ms·

Maybe these containers should be build for wasm-wasi instead of x86 from the beginning? Then there would be no need to emulate x86 in wasm

by txdv 3y ago

jedisct1 3y ago
Because "wasm-wasi" is not a CPU that Linux runs on.
- traverseda 3y ago
  But, if docker is running on WASM-WASI like it is here, maybe it's possible to do a full build toolchain as well?
  - jedisct1 3y ago
    Docker is not running on wasm. There's a wasm app, that is a x86_64 CPU emulator, used to run a Linux VM, on top of which anything can run. Including existing Docker images for x86_64.
    - traverseda 3y ago
      Sure, fine, if an largely-compliant OCI runtime is running in a wasm-wasi context, then I see no reason you couldn't stub out syscalls to reduce dependence on linux-kernel syscalls, and gradually replace the kernel with a minimal set of stub syscalls that make sense, sort of like how gvisor has implemented 200+ linux syscalls in GO and presents an alternative OCI runtime for docker containers. Gradually reduce dependence on an emulated linux-kernel in favour of an alternative lightweight POSIX implementation that runs in pure WASM. This is something that is already done with other OCI runtimes like sysbox and gvisor.
- charcircuit 3y ago
  Why is that relevant? txdv was suggesting to ditch Linux, so what CPUs Linux supports is not relevant.
  - jedisct1 3y ago
    If you ditch Linux, you now have to write a kernel, not an application.
benno128 3y ago
There is support in Docker to run wasm-wasi binaries directly (see: https://wasmlabs.dev/articles/docker-without-containers/ https://wasmlabs.dev/articles/docker-without-containers/). The downside compared to OP's approach is that whatever you're running has to have already been compiled to wasm-wasi. The upside would be much faster execution time (no emulation overhead for x86).

3 ms·

Maybe these containers should be build for wasm-wasi instead of x86 from the beginning? Then there would be no need to emulate x86 in wasm

by txdv 3y ago

Maybe these containers should be build for wasm-wasi instead of x86 from the beginning? Then there would be no need to emulate x86 in wasm

jedisct1 3y ago
Because "wasm-wasi" is not a CPU that Linux runs on.
- traverseda 3y ago
  But, if docker is running on WASM-WASI like it is here, maybe it's possible to do a full build toolchain as well?
  - jedisct1 3y ago
    Docker is not running on wasm. There's a wasm app, that is a x86_64 CPU emulator, used to run a Linux VM, on top of which anything can run. Including existing Docker images for x86_64.
    - traverseda 3y ago
      Sure, fine, if an largely-compliant OCI runtime is running in a wasm-wasi context, then I see no reason you couldn't stub out syscalls to reduce dependence on linux-kernel syscalls, and gradually replace the kernel with a minimal set of stub syscalls that make sense, sort of like how gvisor has implemented 200+ linux syscalls in GO and presents an alternative OCI runtime for docker containers. Gradually reduce dependence on an emulated linux-kernel in favour of an alternative lightweight POSIX implementation that runs in pure WASM. This is something that is already done with other OCI runtimes like sysbox and gvisor.
- charcircuit 3y ago
  Why is that relevant? txdv was suggesting to ditch Linux, so what CPUs Linux supports is not relevant.
  - jedisct1 3y ago
    If you ditch Linux, you now have to write a kernel, not an application.
benno128 3y ago
There is support in Docker to run wasm-wasi binaries directly (see: https://wasmlabs.dev/articles/docker-without-containers/ https://wasmlabs.dev/articles/docker-without-containers/). The downside compared to OP's approach is that whatever you're running has to have already been compiled to wasm-wasi. The upside would be much faster execution time (no emulation overhead for x86).