Document a plan for transitioning to preview 2 and beyond #476
Conversation
This document outlines how wasi-libc can manage the changes to WASI 0.2.0 as well as future 0.2.x releases. It's meant as a starting point for collaboration; I'm interested in your feedback.
| should be identical). Future releases of WASI, e.g., 0.2.1, 0.2.2, 0.2.x, | ||
| will result in new `wasm32-wasip2.*` subdirectories. |
There was a problem hiding this comment.
I might recommend avoiding having a directory-per-release and only having a wasm32-wasip2 directory. Per bytecodealliance/wasmtime#7860 and how other runtimes are expected to behave similarly it would be ok to take a wasi-libc compiled against WASI 0.2.2 and run it on a runtime that only supports WASI 0.2.0, so long as no new functionality from WASI 0.2.2 is actually used. C/Rust/etc are good at this since unused code can easily be statically removed, so I think that provides a smooth path to upgrade wasi-libc bindings here without disrupting the ecosystem.
| `__wasilibc_use_preview2` but (a) `...wasip*` lines up the names with the | ||
| targets, making "what gets compiled where" more clear and (b) we will likely | ||
| need the ability to specify which precise version a block applies to in a | ||
| fine-grained way (e.g., `#ifdef __wasilibc_wasip0.2.2`). |
There was a problem hiding this comment.
Sort of like above, I might recommend only __wasilibc_wasip2, but no further. (e.g. no per-point-release macros). Any one copy of the source of wasi-libc will have some version of WASI that it has bindings generated for, and the source would assume that (e.g. in theory there shouldn't need to be code for "if bigger than 0.2.1 add this code" since it would instead always be included once the WIT files are here)
This document outlines how wasi-libc can manage the changes to WASI 0.2.0 as well as future 0.2.x releases. It's meant as a starting point for collaboration; I'm interested in your feedback.
Rendered