Now that wasm32-freestanding is gone, it’s a good time to explore a freestanding design that could help make things easier to run not just in wasm but in other backends.
hyperlight introduced the idea to a bunch of people. A microvm can get sandboxing where there’s a default of no access to system resources like in WASM, but on the system’s CPU with the OS’s virtualization.
I would want the application developer to be able to control how data flowing through libc is handed to the host platform, like LLVM’s libc for GPUs has RPC. Unlike with GPUs WebAssembly it’s common to hold onto data rather than transfer it - you might have a virtual filesystem inside of the memory.
Ideally it would get so good that WASI apps could be built from it, however, it would be nice. Then it would be easier to say where data goes, for instance printing to stdout could go to the host’s stdout, to a file on the host, to another guest VM, to memory inside itself, or disappear, and could be transformed.
Currently I am working on getting quickjs compiled with foundation-libc.
An obvious goal that could create a virtuous cycle would be to get zig itself building code freestanding.
Another idea is to build wasmedge which is implemented in C with Zig, so that WebAssembly can be run within Zig in a way that feels integrated.
Are you specifically looking for libc support? In the PR linked above, I interpreted this paragraph:
Clearly, a freestanding-capable libc of sorts is a useful thing as evidenced by newlib, picolibc, etc existing. However, calling it “musl” is misleading when it isn’t actually musl-compatible, nor can it ever be because the musl API surface is inextricably tied to the Linux kernel. In the discussion on #20690, there was agreement that once we split up the API and ABI components in the target string, the API component should be about compatibility, not whether you literally get a particular implementation of it. Also, we decided that Linux musl and wasi-libc musl shouldn’t use the same API tag precisely because they’re not actually compatible.
to mean that wasm32-freestanding-musl is going to be replaced by wasi-libc.
But obviously, that’s different to full virtualisation.
Another idea is to build wasmedge which is implemented in C with Zig, so that WebAssembly can be run within Zig in a way that feels integrated.
Yeah, that’s what I mean, is that wasm32-freestanding-musl is gone.
I know wasm-libc is related and it’s something I’m investigating in addition to foundation-libc.
Yes, I am specifically looking for at least partial libc support. Currently I think I’m looking more for adding things to non-musl wasm32-freestanding than a direct alternative to what wasm32-freestanding-musl looked like (having the full musl headers). wasi-libc would be closer to a replacement of wasm32-freestanding-musl because it’s adapted from musl - though an alternative libc could still be adapted from musl instead.
That’s pretty similar to what I’m looking for. I especially like the forwarding the c style allocator calls to the allocator from Zig. The aliasing is also more intuitive, but I wonder if it could be made optional, in case I’m including code that’s already been compiled, or if it could be handled while linking.