-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document a plan for transitioning to preview 2 and beyond #476
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
# WASI Preview Transition | ||
|
||
How will wasi-libc transition to WASI preview 2? This document outlines a plan | ||
and describes how to maintain preview 1 support at the same time. This document | ||
will _not_ discuss how and if and when preview 1 support could be dropped from | ||
the repository; the WASI subgroup is a better forum for that. | ||
|
||
There seem to be several parts to this: | ||
|
||
1. __new targets__: to avoid confusion, let's adopt the target names agreed to | ||
elsewhere: `wasm32-wasip1`, `wasm32-wasip2`. This means that new releases of | ||
wasi-libc/wasi-sdk would contain new `wasm32-wasip*` subdirectories and users | ||
could compile with `--target wasm32-wasip*`. The existing `wasm32-wasi` and | ||
`wasm32-wasi-threads` targets can continue to coexist until some undefined | ||
future date (note that the contents of `wasm32-wasip1` and `wasm32-wasi` | ||
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. | ||
|
||
2. __new internal macro definitions__: internally in wasi-libc, let's use | ||
`#ifdef __wasilibc_wasip*` blocks to conditionally compile code that depends | ||
on a specific version of WASI. The `wasip*` bit should match the target | ||
suffix. The preference should be to keep wasi-libc free from complicated | ||
version logic — ideally, most wasi-libc code should be generic across | ||
versions. The `__wasilibc_wasip*` macro definitions exist to clearly identify | ||
which parts belong to each preview (e.g., this should make maintenance easier | ||
for those interested in supporting preview 1). Since we expect ABI | ||
compatibility between previews, all prior versions should be defined; e.g., | ||
for target `wasip2.1`, both `__wasilibc_wasip2` and `__waslibc_wasip2.1` | ||
would be defined but `__wasilibc_wasip1` would not. PR [#449] proposed | ||
`__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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sort of like above, I might recommend only |
||
|
||
[#449]: https://github.com/WebAssembly/wasi-libc/pull/449 | ||
|
||
3. __new user-facing macro definitions__: externally, users of wasi-libc may | ||
want to conditionally compile their code based on the WASI version: let's | ||
define `__WASI_VERSION` as the preview version string, e.g., `"p1"` for | ||
preview 1, `"p2"` for initial preview 2 support, `"p2.x"` for future WASI | ||
releases. To avoid including this definition in multiple headers, we could | ||
(a) initially include it in `libc-bottom-half/headers/public/wasi/api.h`, | ||
requiring users to `#include <wasi/api.h>` and (b) discuss whether to | ||
upstream general support for this in Clang. | ||
|
||
4. __modified Clang ABI__: since the transition to preview 2 involves an ABI | ||
change (i.e., to the canonical ABI), this seems like a good point to | ||
introduce other Clang-level ABI changes. Let's allow the Clang ABI to use | ||
multi-value returns and discuss any other ABI changes during this time. | ||
|
||
Note that the preview 1 parts of this plan are hopefully temporary: Marcin Kolny | ||
has [plans] to attempt a preview2-to-preview1 adapter which might be able to | ||
avoid extra `#ifdef`s in this project. | ||
|
||
[plans]: https://github.com/loganek/wasi-snapshot-preview2-to-preview1-adapter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.