[wasi] Add new RID for WASI

[pavelsavara]

The initial proposal is wasi-wasm

https://learn.microsoft.com/en-us/dotnet/core/rid-catalog
https://github.com/dotnet/designs/blob/main/accepted/2021/architecture-targeting.md
https://github.com/dotnet/designs/blob/main/accepted/2019/targeting-packs-and-runtime-packs.md

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The initial proposal is wasi-wasm

https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-Infrastructure-mono
Milestone:	8.0.0

[pavelsavara]

This is how it's done https://github.com/dotnet/runtime/pull/76600/files or https://github.com/dotnet/runtime/pull/52907/files

[pavelsavara]

cc @lewing @radical @SteveSandersonMS what are the considerations for naming RID ?
Does it matter which WASM runtime we are targeting ? (wasmtime, wasmer, ...)
Does it matter if we want to support WASI on browser in the future ? (our own JS shim or wasmer-js)
Does it matter which features are enabled on the runtime ? (SIMD, threads, FS, network)
Do engine specific extra APIs matter ? (cloudflare's API)

Also for some reason the browser wasm is not really RID. I'm confused about it, could you please help me understand ? And do the same reasons apply here too ?

[marek-safar]

I think wasi-wasm RID makes sense, and it'd also serve as a parent for any future wasi extension RIDs (e.g. wasmer-wasm). What you need is

runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtimeGroups.props

Lines 43 to 46 in 9a138bf

	<RuntimeGroup Include="browser">
	<Parent>any</Parent>
	<Architectures>wasm</Architectures>
	</RuntimeGroup>

for wasi.

We probably also want to add OperatingSystem property for WASI detection at the same time.

[SteveSandersonMS]

Does it matter which WASM runtime we are targeting ? (wasmtime, wasmer, ...)

In most cases we should target the WASI spec, not a particular runtime implementation.

There will be a few edge cases where we want to take account of the practical realities of different runtimes rather than just the spec. For example, sock_accept is in the WASI spec now and wasmtime supports it, but some other runtimes might still not do because it's relatively new. So if possible we'd want applications only to end up with a sock_accept import if the developer is doing something that requires it, rather than always depending on that import (as that could prohibit the use of other runtimes).

Does it matter if we want to support WASI on browser in the future ? (our own JS shim or wasmer-js)

In theory we shouldn't have to do anything to enable this. If a developer chooses to load their WASI-compliant module in a browser, then as long as they supply WASI-compliant import implementations, it should just work. And that does match up with what I've experienced: I've been able to run both ASP.NET Core and Blazor inside the browser after compiling them using dotnet-wasi-sdk and supplying a minimal JS WASI shim.

Does it matter which features are enabled on the runtime ? (SIMD, threads, FS, network)

Ideally in the long run we'd support as much as can be supported. For features that map to specific standard runtime features, such as FS and SIMD, we'd ideally want to emit binaries that naturally work with the standard.

For other features where there isn't a standard WASI API (e.g., threads today) we could choose to wait longer to see if a standard emerges, or we could choose to have an experimental-level implementation that lines up with the functionality on a particular runtime. I'd deprioritize things that aren't standardized though.

Do engine specific extra APIs matter ? (cloudflare's API)

We'd want to support defining arbitrary wasm imports/exports so that people can integrate with these 3rd-party APIs. I already have half of an implementation of doing this from C# by enhancing the existing pinvoke generator :)

Further out, we should look into creating a C# source generator for WIT/WITX so that any API defined as WIT/WITX can be used to generate C# bindings that builds on our support for arbitrary wasm imports/exports.

What do you think? Does that all sound reasonable?

[pavelsavara]

Does it matter if we want to support WASI on browser in the future ?

WASI-compliant module in a browser, then as long as they supply WASI-compliant import implementations, it should just work.

It would be impractical to implement sock_accept on top of fetch and then create managed HttpMessageHandler on top of it. I imagine that dealing directly with the underlying JS is way to go.
Also the (the new) JS interop would be good to have available there.

Such build of the runtime would have not only WASI imports, but also those dotnet specific JS interop imports.

Does it matter which features are enabled on the runtime ? (SIMD, threads, FS, network)

Ideally in the long run we'd support as much as can be supported.

The problem is that you need to compile for specific feature set.
If your .wasm contains instructions which are not supported in the current engine, it will fail to load whole .wasm. Not just the offending function.
See https://web.dev/webassembly-feature-detection/

[SteveSandersonMS]

It would be impractical to implement sock_accept on top of fetch

Yeah, sock_accept is the opposite direction - it's for inbound networking (TCP listeners), not for outbound networking. I wasn't suggesting anything about implementing sock_accept on top of anything else. When running in a browser there isn't any possible implementation of sock_accept, but it's not something people would expect to work.

I imagine that dealing directly with the underlying JS is way to go.

Running in the browser is a bit of a niche so I wouldn't focus on that much. In general we should be prioritizing native interop (like mapping pinvoke to a webassembly import), not JS interop.

Totally reasonable for our JS interop mechanism to work if you happen to be in a browser, but that's a small fraction of the use cases for WASI.

If your .wasm contains instructions which are not supported in the current engine, it will fail to load whole .wasm. Not just the offending function.

Absolutely. In terms of wasm features (like bulk memory etc), we would have to expose build flags to control the kind of binary output we produce.