-
Notifications
You must be signed in to change notification settings - Fork 824
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
feat(wasi) Add the “floating” WasiVersion::Latest
version.
#1029
Conversation
In addition to `Snapshot0` and `Snapshot1`, I believe it is an interesting API to provide the `Latest` version, so that the user can write: ```rust generate_import_object_for_version(WasiVersion::Latest, …); ``` This is a way to ensure that modules will run only if they come with the latest WASI version (in case of security issues for instance), by just updating the runtime. Note that it can be dangerous if not used carefully, but we assume the user knows what it does by sticking on a specific “floating” version. Also note that the `Latest` version is never returned by any API. It is provided only by the user.
WasiVersion::Latest
version.WasiVersion::Latest
version.
bors try |
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.
This seems reasonable to me! It'd be good to add what you said in this PR here to the comments, it'd be nice if we could assert that it's never returned too, like an attribute #[user_supplied]
-- I doubt it's possible or worth the effort if we have to make it now, but it'd be nice
tryBuild succeeded |
It would be nice yeah, but I didn't find an easy to do that… Let skip that part for the moment. |
bors r+ |
1029: feat(wasi) Add the “floating” `WasiVersion::Latest` version. r=Hywan a=Hywan In addition to `Snapshot0` and `Snapshot1`, I believe it is an interesting API to provide the `Latest` version, so that the user can write: ```rust generate_import_object_for_version(WasiVersion::Latest, …); ``` This is a way to ensure that modules will run only if they come with the latest WASI version (in case of security issues for instance), by just updating the runtime. Note that it can be dangerous if not used carefully, but we assume the user knows what it does by sticking on a specific “floating” version. Also note that the `Latest` version is never returned by any API. It is provided only by the user. Co-authored-by: Ivan Enderlin <[email protected]>
Build succeeded |
92: feat(wasi) Support `WasiGetVersion` & other `*ForVersion` WASI API r=Hywan a=Hywan Fix #90. Fix #77.⚠️ Depends on wasmerio/wasmer#1028, wasmerio/wasmer#1029, and wasmerio/wasmer#1030. They must be merged before merging this PR! Marking this PR as a draft to be sure (the shared libraries must be updated too). This patch updates `bridge.go` and `wasmer.h` to support the new `wasmer_wasi_generate_import_object_for_version` and `wasmer_wasi_get_version` functions. After that, this patch updates `wasi.go` to implement the new `NewDefaultWasiImportObjectForVersion`, `NewWasiImportObjectForVersion` and the `WasiGetVersion` functions. In addition to that, we create a new `WasiVersion` type. Finally, this patch updates the tests to test this new API. And it works like a charm 👌. Co-authored-by: Ivan Enderlin <[email protected]>
92: feat(wasi) Support `WasiGetVersion` & other `*ForVersion` WASI API r=Hywan a=Hywan Fix #90. Fix #77.⚠️ Depends on wasmerio/wasmer#1028, wasmerio/wasmer#1029, and wasmerio/wasmer#1030. They must be merged before merging this PR! Marking this PR as a draft to be sure (the shared libraries must be updated too). This patch updates `bridge.go` and `wasmer.h` to support the new `wasmer_wasi_generate_import_object_for_version` and `wasmer_wasi_get_version` functions. After that, this patch updates `wasi.go` to implement the new `NewDefaultWasiImportObjectForVersion`, `NewWasiImportObjectForVersion` and the `WasiGetVersion` functions. In addition to that, we create a new `WasiVersion` type. Finally, this patch updates the tests to test this new API. And it works like a charm 👌. Co-authored-by: Ivan Enderlin <[email protected]>
92: feat(wasi) Support `WasiGetVersion` & other `*ForVersion` WASI API r=Hywan a=Hywan Fix #90. Fix #77.⚠️ Depends on wasmerio/wasmer#1028, wasmerio/wasmer#1029, and wasmerio/wasmer#1030. They must be merged before merging this PR! Marking this PR as a draft to be sure (the shared libraries must be updated too). This patch updates `bridge.go` and `wasmer.h` to support the new `wasmer_wasi_generate_import_object_for_version` and `wasmer_wasi_get_version` functions. After that, this patch updates `wasi.go` to implement the new `NewDefaultWasiImportObjectForVersion`, `NewWasiImportObjectForVersion` and the `WasiGetVersion` functions. In addition to that, we create a new `WasiVersion` type. Finally, this patch updates the tests to test this new API. And it works like a charm 👌. Co-authored-by: Ivan Enderlin <[email protected]>
In addition to
Snapshot0
andSnapshot1
, I believe it is aninteresting API to provide the
Latest
version, so that the user canwrite:
This is a way to ensure that modules will run only if they come with
the latest WASI version (in case of security issues for instance), by
just updating the runtime.
Note that it can be dangerous if not used carefully, but we assume the
user knows what it does by sticking on a specific “floating” version.
Also note that the
Latest
version is never returned by any API. Itis provided only by the user.