Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,11 @@ string, environment variables, program startup, and many other APIs.
`wasi-libc` is sufficiently stable and usable for many purposes, as most of the
POSIX-compatible APIs are stable, though it is continuing to evolve to better
align with wasm and WASI. For example, pthread support is experimentally
provided via the [wasi-threads] proposal.
provided via the [wasi-threads] proposal. As WASI transitions from preview 1 to
preview 2, reference the coming changes in the [transition plan].

[wasi-threads]: https://github.com/WebAssembly/wasi-threads
[transition plan]: docs/preview2-transition.md

## Usage

Expand Down
55 changes: 55 additions & 0 deletions docs/preview2-transition.md
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.
Comment on lines +16 to +17
Copy link
Collaborator

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.


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`).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)


[#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