witx: a wasi_unstable description based on module types. #74
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This sketches out a description of the current wasi_unstable API, using a syntax which anticipates the "module types" syntax [recently proposed to the CG](https://github.com/WebAssembly/meetings/blob/master/2019/CG-08-06.md#discuss-new-proposal-that-introduces-types-for-modules-and-instances-and-text-format-thereof-as-initially-discussed-in-design1289), though it does use a few extensions which can be easily lowered, and which mostly anticipate the [Interface Types](WebAssembly/interface-types#47 (comment)) proposal. This is derived from [the WatIDL proposal](WebAssembly#64), though it differs in a few ways: - It doesn't yet do anything special for capabilities, for now. File descriptors are just integers, for now. But the idea is that we could add OCAP concepts later. - It uses a new `(flags ...)` construct in place of structs of Bool fields, to describe flags values. This allows us to explicitly declare the underlying wasm type for flags values. - Types used by the API are declared outside of the moduletype, because we're using wat syntax as much as possible, and there, `(type ...)` inside a module declares an entry in the type section, which isn't what's intended here. The extensions to module types are: - It uses `string`, `array`, and `{s,u}{8,16,32,64}` types, which are expected to be provided in some form by the Interface Types proposal. For now though, they can all be lowered in straightforward ways, by assuming that `string` is always just UTF-8. - It adds `typename` declarations, which can name any wasm type, and of the extra types mentioned in the previous item, or `struct`, `enum`, or `flags`. - It declares functions with multiple return values, which for now will need to be lowered to output (pointer) parameters.
steveej
reviewed
Aug 15, 2019
Co-Authored-By: Stefan Junker <[email protected]>
This replaces the "data" type. It'll be desirable to use higher-level types to describe what iovec/ciovec do, however to avoid getting into IDL design questions, for now just use explicit pointer and length values to keep things simple.
Only use `(typename ...)` to declare named types; don't use it for inline types.
…s to a separate file.
It isn't logically part of the `wasi_unstable` module. It's part of the platform-level ABI.
We're not currently using a method-oriented API, so instead of saying "self", say "fd", which is what these parameters are.
sunfishcode
changed the title
cjihrig
reviewed
Sep 9, 2019
| (param $fd $fd_t) | ||
| (result $error $errno_t) | ||
| ;; The buffer where the description is stored. | ||
| (result $buf $prestat_t) |
There was a problem hiding this comment.
It looks like prestat_t is not defined (related to #51).
There was a problem hiding this comment.
Good spot! I've now added it.
|
There are a handful of fixes in https://github.com/fastly/lucet/pull/275/files#diff-1ac8557cf1c286d69d13ccaa4b21d291 that get these files to "validate", at least as far as lucet-idl is concerned. Most of the changes were either typo fixes, or changing the ordering of We don't necessarily have to enforce that names are defined before use, but it does make implementation a bit easier, and it has precedent in wasm. |
The wat format allows forward references to '$' identifiers, so we'll probably have to support this eventually too, but for now, reorder things to make it easy to process.
|
@pchickey Thanks! I've now made an attempt to merge your changes into the PR here. The wat format does allow '$' names to be used before defined in the file, so we should eventually support that. That said, it's not urgent, and I've incorporated your reordering changes in the PR here as well for now. |
cjihrig
added a commit
to nodejs/uvwasi
that referenced
this pull request
Sep 11, 2019
The type schema was confirmed in WebAssembly/WASI#74
sunfishcode
added a commit
that referenced
this pull request
Sep 12, 2019
This PR takes the `witx` concept from #74 and creates a directory structure around it for enabling phased development of new APIs and changes to existing APIs. See the README.md changes for details.
|
Ok, I've addressed all the feedback so far. I'm taking the liberty of merging this now, so that we can more easily continue iterating on it. |
sunfishcode
added a commit
to sunfishcode/WASI
that referenced
this pull request
Sep 13, 2019
This PR takes the `witx` concept from WebAssembly#74 and creates a directory structure around it for enabling phased development of new APIs and changes to existing APIs. See the README.md changes for details.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This sketches out a description of the current wasi_unstable API, using a syntax which anticipates the "module types" syntax recently proposed to the CG, though it does use a few extensions which can be easily lowered, and which mostly anticipate the Interface Types proposal.
This is derived from the WatIDL proposal, though it differs in a few ways:
It doesn't yet do anything special for capabilities, for now. File descriptors are just integers, for now. But the idea is that we could add OCAP concepts later.
It uses a new
(flags ...)construct in place of structs of Bool fields, to describe flags values. This allows us to explicitly declare the underlying wasm type for flags values.Types used by the API are declared outside of the moduletype, because we're using wat syntax as much as possible, and there,
(type ...)inside a module declares an entry in the type section, which isn't what's intended here.The extensions to module types are:
It uses
string,array, and{s,u}{8,16,32,64}types, which are expected to be provided in some form by the Interface Types proposal. For now though, they can all be lowered in straightforward ways, by assuming thatstringis always just UTF-8.It adds
typenamedeclarations, which can name any wasm type, and of the extra types mentioned in the previous item, orstruct,enum, orflags.It declares functions with multiple return values, which for now will need to be lowered to output (pointer) parameters.